À quelle fréquence les statistiques de la base de données Oracle doivent-elles être exécutées?

Question

Selon votre expérience, à quelle fréquence les statistiques de la base de données Oracle doivent-elles être exécutées? Notre équipe de développeurs a récemment découvert que les statistiques n’avaient pas été exécutées depuis plus de deux mois et demi. Cela me semble long, mais je ne suis pas administrateur de base de données.

Answer 1

Lors de mon dernier emploi, nous avons publié des statistiques une fois par semaine. Si je me souviens bien, nous les avons programmées un jeudi soir et vendredi, les administrateurs de base de données ont été très attentifs à la surveillance des requêtes les plus anciennes pour détecter tout imprévu. (Vendredi a été choisi parce que c'était souvent juste après la publication du code et avait tendance à être un jour de trafic relativement faible.) Quand ils voyaient une mauvaise requête, ils trouvaient un meilleur plan de requête et le sauvegardaient pour qu'il ne change plus inopinément. . (Oracle dispose d’outils pour le faire automatiquement, vous lui indiquez la requête à optimiser et c’est le cas.)

De nombreuses entreprises évitent d’exécuter des statistiques par crainte que de mauvais plans de requêtes ne surgissent de manière inattendue. Mais cela signifie généralement que leurs plans de requête s'aggravent de jour en jour. Et quand ils exécutent des statistiques, ils rencontrent un certain nombre de problèmes. Les difficultés qui en résultent pour résoudre ces problèmes confirment leurs craintes quant aux dangers de la publication de statistiques. Mais s’ils effectuaient des statistiques régulièrement, utilisaient les outils de contrôle comme ils étaient censés le faire et réglaient les problèmes au fur et à mesure, ils auraient moins de maux de tête et ils ne les rencontreraient pas tous en même temps.

Answer 2

Les statistiques Oracle 11g étant collectées automatiquement par défaut.

Deux fenêtres du planificateur sont prédéfinies lors de l'installation de la base de données Oracle:

• WEEKNIGHT_WINDOW commence à 22 heures. et se termine à 6 heures tous les lundis jusqu'au vendredi.
• WEEKEND_WINDOW couvre les journées entières samedi et dimanche.

Quand les statistiques ont-elles été rassemblées?

SELECT owner, table_name, last_analyzed FROM all_tables ORDER BY last_analyzed DESC NULLS LAST; --Tables.
SELECT owner, index_name, last_analyzed FROM all_indexes ORDER BY last_analyzed DESC NULLS LAST; -- Indexes.

Statut de la collecte automatique de statistiques?

SELECT * FROM dba_autotask_client WHERE client_name = 'auto optimizer stats collection';

Groupes Windows?

SELECT window_group_name, window_name FROM dba_scheduler_wingroup_members;

Horaires de la fenêtre?

SELECT window_name, start_time, duration FROM dba_autotask_schedule;

Collecter manuellement les statistiques de la base de données dans ce schéma:

EXEC dbms_stats.gather_schema_stats(ownname=>NULL, cascade=>TRUE); -- cascade=>TRUE means include Table Indexes too.

Collectez manuellement les statistiques de base de données dans tous les schémas!

-- Probably need to CONNECT / AS SYSDBA
EXEC dbms_stats.gather_database_stats;

Answer 3

Chaque fois que les données changent "de manière significative".

Si une table passe de 1 ligne à 200 lignes, cela représente un changement important. Lorsqu'un tableau passe de 100 000 lignes à 150 000 lignes, le changement n'est pas très significatif. Lorsqu'un tableau passe de 1 000 lignes, toutes avec des valeurs identiques dans la colonne X fréquemment interrogée, à 1 000 lignes avec des valeurs presque uniques dans la colonne X, il s'agit d'un changement important.

Informations de magasin de statistiques sur le nombre d’articles et les fréquences relatives - éléments qui le laisseront "deviner". à combien de lignes correspondra à un critère donné. Lorsqu'il devine mal, l'optimiseur peut choisir un plan de requête optimal . .

Answer 4

Quelle version d'Oracle utilisez-vous? Consultez cette page qui fait référence à Oracle 10:

http: //www.acs.ilstu. edu / docs / Oracle / server.101 / b10752 / stats.htm

Il est écrit:

  

L'approche recommandée pour la collecte de statistiques consiste à permettre à Oracle de collecter automatiquement les statistiques. Oracle collecte automatiquement les statistiques sur tous les objets de base de données et les maintient dans un travail de maintenance planifié régulièrement.

Answer 5

Lorsque je gérais un grand système de planification multi-utilisateurs soutenu par Oracle, notre administrateur de base de données effectuait un travail hebdomadaire rassemblant des statistiques. De plus, lorsque nous avons mis en place un changement important qui pourrait affecter les statistiques ou être affecté par les statistiques, nous obligerions le travail à être en fin de cycle pour rattraper son retard.

Answer 6

Avec la version 10g et ultérieure d’oracle, l’optimiseur a besoin de statistiques à jour sur les tables et les index pour rendre "bon" et "correct". décision du plan d'exécution. Combien de fois vous collectez des statistiques est un appel délicat. Cela dépend de votre application, du schéma, du débit de données et des pratiques de l'entreprise. Certaines applications tierces écrites pour être rétrocompatibles avec l'ancienne version d'Oracle ne fonctionnent pas bien avec le nouvel optimiseur. Ces applications exigent que les tables n'aient pas de statistiques afin que la base de données retourne au plan d'exécution de la base de règles. Or, en moyenne, Oracle recommande de collecter les statistiques sur des tables contenant des statistiques obsolètes. Vous pouvez configurer les tables pour qu'elles soient surveillées et vérifier leur état et leur demander d'analyser si / quand elles sont périmées. Cela suffit souvent, parfois non. Cela dépend vraiment de votre base de données. Pour ma base de données, nous avons un ensemble de tables OLTP qui nécessitent une collecte de statistiques nocturnes pour maintenir les performances. Les autres tableaux sont analysés une fois par semaine. Sur notre base de données volumineuse dw, nous analysons au besoin, car les tables sont trop grandes pour une analyse régulière sans affecter la charge et les performances globales de la base de données. La bonne réponse est donc, cela dépend de l'application, du changement de données et des besoins de l'entreprise.

Answer 7

Veillez à équilibrer le risque que de nouvelles statistiques entraînent des modifications indésirables dans les plans de requête par rapport au risque que des statistiques obsolètes puissent provoquer la modification des plans de requête.

Imaginez que vous ayez une base de données de bogues avec une table ISSUE et une colonne CREATE_DATE où les valeurs de la colonne augmentent plus ou moins monotonement. Supposons maintenant qu’il existe un histogramme dans cette colonne indiquant à Oracle que les valeurs de cette colonne sont uniformément réparties entre le 1er janvier 2008 et le 17 septembre 2008. Cela permet à l’optimiseur d’estimer de manière raisonnable le nombre de lignes pouvant être renvoyées. être retourné si vous recherchiez tous les numéros créés la semaine dernière (du 7 au 13 septembre). Si l'application continue à être utilisée et que les statistiques ne sont jamais mises à jour, cet histogramme sera de moins en moins précis. L’optimiseur attendra donc des requêtes pour les " problèmes créés la semaine dernière " être de moins en moins précis au fil du temps et pourrait éventuellement amener Oracle à modifier le plan de requête de manière négative.

Answer 8

Dans le cas d'un système de type entrepôt de données, vous pouvez ne collecter aucune statistique et vous appuyer sur un échantillonnage dynamique (définition de optimizer_dynamic_sampling sur le niveau 2 ou supérieur).

Answer 9

En règle générale, il n'est pas recommandé de collecter des statistiques aussi fréquentes sur l'ensemble de la base de données, à moins que vous n'ayez une justification solide, telle qu'une insertion en bloc ou des modifications de données volumineuses se produisent fréquemment dans la base de données. la collecte de statistiques sur la base de données à cette fréquence PEUT changer le plan d'exécution des requêtes en un nouveau plan d'exécution médiocre, cela peut vous prendre beaucoup de temps d'essayer de régler chaque requête affectée par les nouveaux plans pauvres, c'est pourquoi vous devez tester l'impact de la collecte de nouvelles statistiques sur une base de données de tests, ou au cas où vous n’auriez pas le temps ou le personnel nécessaire, au moins gardez un plan de secours en sauvegardant la statique d’origine avant de collecter de nouvelles statistiques, donc si vous collectez une les nouvelles statistiques et les requêtes ne fonctionnant pas comme prévu, vous pouvez facilement restaurer les statistiques d'origine.

Il existe un script très utile qui peut vous aider à sauvegarder les statistiques d'origine et à en rassembler de nouvelles et à vous fournir une commande SQL que vous pouvez utiliser pour restaurer les statistiques d'origine si les choses ne se passaient pas comme prévu après la collecte de nouvelles statistiques. Vous pouvez trouver le script dans ce lien: http: //dba-tips.blogspot .com / 2014/09 / script-à-facilité-collecte-statistiques-on.html