Automatisation de l'identification des requêtes de problèmes dans Oracle 11g

Question

Dans notre banc d'essai, un certain nombre de suites de tests sont exécutées à la suite (sans surveillance), produisant des rapports pour une consommation ultérieure. Je veux inclure dans ces rapports les requêtes qui sont susceptibles d'être approfondies, ainsi que les données qui justifient leur inclusion dans cette liste. Nous devrions être en mesure d'associer toute requête identifiée de cette façon à la suite de tests qui l'exposait comme une préoccupation. Lorsque nous utilisons SQL Server, ceci est relativement simple: un appel à DBCC FREEPROCCACHE efface tous les compteurs avant le démarrage d'une suite, puis à la fin du test, nous exécutons une requête sur sys.dm_exec_query_stats, ce qui nous donne accès à compte d'exécution et min/max/total time (s) de chaque plan de requête mis en cache, avec des hooks disponibles pour récupérer l'instruction SQL paramétrée (nous utilisons la paramétrisation FORCED dans nos instances mssql) et le plan de requête.

Ref: http://msdn.microsoft.com/en-us/library/ms189741%28SQL.90%29.aspx

Ma question: comment puis-je mettre en œuvre une approximation de ce que mon application cible a été connecté à Oracle 11g? Ma lecture jusqu'à présent suggère que tout ce que je veux est disponible via l'AWR, et qu'il devrait être possible d'accéder directement aux vues de support, mais je n'ai pas été capable de fermer le cercle par moi-même.

Answer 1

Pourquoi avez-vous besoin d'accéder directement aux vues prises en charge? Il me semble que la solution la plus simple serait

• Chaque suite de tests commence et se termine en générant explicitement un instantané de AWR il connaît le début et la fin ID d'instantané et de sorte que vous pouvez générer des rapports AWR pour chaque suite individuellement .
• Vous exécutez AWR rapports pour chaque suite
• Vous passez en revue test, les rapports AWR examinant notamment les différentes sections supérieures SQL

Il est absolument possible d'obtenir toutes les informations des vues sous-jacentes directement, mais si vous n'avez pas besoin de le faire, c'est évidemment plus facile.

Juste pour la santé mentale, je tiens à souligner que je suppose que vous êtes autorisé à utiliser AWR. Techniquement, même l'interrogation des vues AWR nécessite que vous ayez sous licence le pack Performance and Tuning. Si vous souhaitez afficher les vues directement plutôt que de générer des rapports AWR complets en raison de problèmes de licence, vous ne vous épargnez aucun problème de licence en cliquant sur les vues.

Answer 2

L'équivalent Oracle de DBCC FREEPROCCACHE est

SQL> alter system flush shared_pool; 

Answer 3

Le plus proche des compteurs SQL Server sont V$SYSSTAT et V$SYSTEM_EVENT. Toutefois, Oracle les suit également au niveau de la session dans v $ SESSION_WAIT, V $ SESSION_WAIT_CLASS et V $ SESSION_EVENT. Vous n'avez donc pas besoin de les réinitialiser au niveau du système. Et vous n'avez pas besoin des licences pack Diagnostic/Tuning pour y accéder.

Ils ne descendent pas au niveau SQL. Cela est disponible dans V $ SQL, mais ne serait pas spécifique à cette session. Vous pouvez utiliser session level tracing pour localiser les SQL individuels qui peuvent causer des problèmes.

Answer 4

La réponse de Justin était correcte, mais j'avais besoin de plus de détails sur l'implémentation.

• Chaque suite de tests commence et se termine en générant explicitement un instantané de AWR il connaît le début et la fin ID d'instantané et de sorte que vous pouvez générer des rapports AWR pour chaque suite individuellement.
• Vous exécutez AWR rapports pour chaque suite
• test Vous passez en revue les rapports AWR examinant notamment les différentes sections supérieures SQL

• je produis explicitement les clichés en appelant dbms_workload_repository.create_snapshot, le résultat est enregistré pour plus tard.

  select dbms_workload_repository.create_snapshot() comme snap_id de double

• Pour obtenir le rapport, je besoin de l'ID de base de données et le numéro d'instance. Ceux-ci sont facilement obtenus à partir de v $ database et v $ instance.

  sélectionnez d.DBID, i.instance_number comme inst_num base de données v $ d, v $ instance i

• Le rapport est disponible sous forme de texte (dbms_workload_repository.awr_report_text) ou html (dbms_workload_repository.awr_report_html). Les arguments sont les mêmes dans les deux cas, y compris un indicateur d'options qui comprendra des informations provenant de l'ADDM (Automatic Diagnostic Database Monitor). Il n'était pas immédiatement évident pour moi que je pouvais exploiter les résultats ADDM, alors je l'éteins. La valeur de retour est une colonne de VARCHAR, l'appel de fonction est enveloppé

  sortie select de la table (dbms_workload_repository.awr_report_html (1043611354,1,5539,5544,0))

• Ce résultat est facilement écrit à un fichier, qui est assemblé avec les autres artefacts du test.

Documentation of these methods is available online