À quelle fréquence les statistiques de la base de données Oracle doivent-elles être exécutées?
D'après 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.
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 le vendredi, les administrateurs de base de données ont été très attentifs à la surveillance des requêtes les plus longues en cours pour détecter tout imprévu. (Vendredi a été choisi parce que c'était souvent juste après la publication du code et que le trafic était relativement bas.) Lorsqu'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.
Chaque fois que les données changent "de manière significative".
Si une table passe de 1 ligne à 200 lignes, il s'agit d'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.
Les statistiques stockent des informations sur le nombre d'éléments et les fréquences relatives - des éléments qui permettent de "deviner" le nombre de lignes correspondant à un critère donné. Lorsqu'il devine mal, l'optimiseur peut choisir un plan de requête très sous-optimal.
Depuis Oracle 11g, les statistiques sont recueillies 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 du matin tous les lundis .__ jusqu'à 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 automatisée 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;
Recueillir 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.
Recueillir 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;
Quelle version d'Oracle utilisez-vous? Vérifiez cette page qui fait référence à Oracle 10:
http://www.acs.ilstu.edu/docs/Oracle/server.101/b10752/stats.htm
Ça dit:
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.
Avec la version 10g et supérieure d’Oracle, l’optimiseur a besoin de statistiques à jour sur les tables et les index pour prendre une "bonne" décision de 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 votre entreprise. Certaines applications tierces écrites pour être rétro-compatibles 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. Mais en moyenne, Oracle recommande que les statistiques soient collectées 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 la 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 volumineuses 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.
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. En outre, lorsque nous introduisions 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 le retard.
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 de façon monotone. Supposons maintenant qu’un histogramme dans cette colonne indique à 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 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 s'attend donc à ce que les requêtes relatives aux "problèmes créés la semaine dernière" soient de moins en moins précises au fil du temps et que Oracle puisse éventuellement modifier le plan de requête de manière négative.
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 volumineuses se produisent fréquemment dans la base de données . Recueillir des statistiques sur la base de données à cette fréquence PEUT changer Si le plan d’exécution des requêtes correspond à de nouveaux plans d’exécution médiocres, vous risquez de perdre beaucoup de temps à essayer d’ajuster toutes les requêtes affectées par les nouveaux plans médiocres. C’est pourquoi vous devez tester l’impact de la collecte de nouvelles statistiques sur une base de données de test vous n’avez ni le temps ni la main-d’œuvre nécessaire pour cela, au moins gardez-vous un plan de repli en sauvegardant la statique d’origine avant de collecter de nouvelles statistiques, donc si vous collectez de nouvelles statistiques et que les requêtes n’exécutent 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 au cas où la situation ne se déroulerait 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-to-ease-gathering-statistics-on.html
Dans le cas d'un système de type entrepôt de données, vous pouvez ne collecter aucune statistique et recourir à un échantillonnage dynamique (définissez optimizer_dynamic_sampling sur le niveau 2 ou supérieur).