R12.1/R12.2 sind ziemlich große und zeitaufwändige Upgrades. Wir müssen alle lang laufenden SQLs finden, um die Leistungsprobleme des R12.2-Upgrades zu lösen. Da jede Iteration viel Zeit in Anspruch nimmt, ist es wichtig, dass wir versucht haben, die Leistungsprobleme in weniger Iterationen herauszufinden und sie entsprechend zu beheben
Hier sind die wichtigsten AWR-Abfragen zur Lösung von Leistungsproblemen bei R12.2-Upgrades
Wenn sich SQL noch im Speicher (Cursor-Cache) befindet, kann Folgendes verwendet werden, um lange laufende SQLs zu identifizieren, die möglicherweise noch nicht in das AWR geschrieben wurden (beim letzten Snapshot)
SELECT * FROM (SELECT ss.sql_id, ROUND(SUM(ss.elapsed_time/1000000),0) elapsed_time_secs, ROUND(SUM(ss.cpu_time/1000000),0) cpu_time_secs, SUM(ss.disk_reads) disk_reads, SUM(ss.direct_writes) direct_writes, SUM(ss.buffer_gets) buffer_gets, SUM(ss.px_servers_executions) px_server_execs, SUM(ss.rows_processed) rows_processed, SUM(ss.executions) executions, SUM(ss.application_wait_time) apwait_secs, SUM(ss.sharable_mem) sharable_mem, SUM(ss.total_sharable_mem) total_sharable_mem FROM v$sqlstats ss GROUP BY ss.sql_id ORDER BY 2 DESC) WHERE ROWNUM <= 100;
Das folgende SQL-Skript meldet die am längsten laufende SQL zwischen zwei AWR-Snapshots
SELECT * FROM (SELECT dhs.sql_id, ROUND(SUM(dhs.elapsed_time_delta/1000000),0) elapsed_time_secs, ROUND(SUM(dhs.cpu_time_delta/1000000),0) cpu_time_secs, SUM(dhs.disk_reads_delta) disk_reads, SUM(dhs.buffer_gets_delta) buffer_gets, SUM(dhs.px_servers_execs_delta) px_server_execs, SUM(dhs.rows_processed_delta) rows_processed, SUM(dhs.executions_delta) executions, ROUND(SUM(dhs.iowait_delta/1000000),0) iowait_secs, ROUND(SUM(dhs.clwait_delta/1000000),0) clwait_secs, ROUND(SUM(dhs.ccwait_delta/1000000),0) ccwait_secs, ROUND(SUM(dhs.apwait_delta/1000000),0) apwait_secs FROM dba_hist_sqlstat dhs ,v$database d WHERE dhs.dbid = d.dbid AND snap_id > &begin_snap and snap_id <= &end_snap GROUP BY dhs.sql_id ORDER BY 2 DESC) WHERE ROWNUM <= 100;
Wobei &begin_snap und &end_snap die Start- und End-Snapshot-IDs sind.
Die Ausgabe dieser Anweisung sieht etwa so aus:
SQL_ID ELAPSED_TIME_SECS CPU_TIME_SECS DISK_READS BUFFER_GETS…. ------------- ----------------- --------------- ---------- ----------- …. 5vaxut40xbrmr 367440 42999 34838244 3795838289 …. 943ra4b7zg28x 264369 170788 441127 562033013 …. fkkrk9frwqfdr 70370 6448 3599284 469639133 …. 4847s6dt6sds9 68298 38896 7125573 1327384554 …. 2k3uw8n473r30 63600 27402 20043712 587615960 ….
Hinweis:Die verstrichene Zeit ist die maximal verstrichene Zeit für alle Arbeiter eines Jobs.
Enterprise Manager kann auch verwendet werden, um teures SQL zu identifizieren, sobald es auftritt.
Anzeige-Cursor-Bericht für SQL mit langer Ausführung abrufen
Dafür STATISTICS_LEVEL=ALL und _rowsource_execution_statistics =TRUE. Es sollte ohne Verzögerung ausgeführt werden, um alle Informationen zu erhalten, da diese Informationen sonst aus SGA gelöscht werden
SET pages 0
SET lines 300
SET LONG 10000
SET LONGCHUNKSIZE 10000
SPOOL <report>.txt
SELECT * FROM TABLE(dbms_xplan.display_cursor('<SQL ID>', NULL, 'ALL +ALLSTATS'));
SPOOL OFF; Wenn sich das SQL nicht mehr im Arbeitsspeicher, aber im AWR befindet, verwenden Sie stattdessen den Bericht AWR anzeigen:
SET pages 0
SET lines 300
SET LONG 10000
SET LONGCHUNKSIZE 10000
SPOOL .txt
SELECT * FROM TABLE(dbms_xplan.display_awr('<SQL ID>', NULL, NULL, 'ALL'));
SPOOL OFF; Hinweis:Beachten Sie, dass der Bericht AWR anzeigen (DBMS_XPLAN.DISPLAY_AWR) keine Ist-Werte ausgibt:Er verfügt nicht über die Option +ALLSTATS, und es gibt keine Ist-Statistiken für Ausführungsplanschritte, die in AWR
gespeichert sindWichtiger Hinweis:Der Anzeigecursor und die AWR-Berichte zeigen nur den sql_text (die ersten 1000 Zeichen) und nicht den sql_fulltext. Führen Sie daher bei Bedarf das folgende SQL-Skript aus, um den vollständigen SQL-Text abzurufen
SET pages 0 SET lines 300 SET LONG 10000 SET LONGCHUNKSIZE 10000 SPOOL<report_name>.txt SELECT sql_id, sql_text, sql_fulltext FROM v$SQL WHERE sql_id = '<sql_id>'; SPOOL OFF;
SQL-Monitorbericht für SQL mit paralleler Abfrage/DML abrufen
Der Hauptvorteil davon ist, dass es einen guten Überblick darüber gibt, wie sich paralleles SQL/DML über die Phasen des Plans und parallele Slaves hinweg verhält
set trimspool on set trim on set pages 0 set long 10000000 set long chunksize 10000000 set linesize 200 set termout off spool sql_monitor_for_<sql_id>.htm variable my_rept CLOB; BEGIN :my_rept := dbms_sqltune.report_sql_monitor(sql_id => '<sql_id>', report_level => 'ALL', type => 'HTML'); END; / print :my_rept spool off; set termout on
Wobei &begin_snap und &end_snap und die Start- und End-Snapshot-IDs sind.
Wie man herausfindet, wann die jeweilige SQL ausgeführt wurde
SELECT dhs.sql_id, dsn.snap_id, dsn.begin_interval_time, dsn.end_interval_time, ROUND(SUM(dhs.elapsed_time_delta/1000000),0) elapsed_time_secs FROM dba_hist_sqlstat dhs ,v$database d ,dba_hist_snapshot dsn WHERE dhs.dbid = d.dbid AND dsn.snap_id = dhs.snap_id AND dsn.dbid = dhs.dbid AND dsn.instance_number = dhs.instance_number AND dhs.sql_id = '<SQL ID>' AND dsn.snap_id > &begin_snap and dsn.snap_id <= &end_snap GROUP BY dhs.sql_id, dsn.snap_id, dsn.begin_interval_time, dsn.end_interval_time ORDER BY dsn.snap_id;
Wobei &begin_snap und &end_snap die Start- und End-Snapshot-IDs sind.
Die Ausgabe dieser Anweisung sieht etwa so aus:
SQL_ID SNAP_ID BEGIN_INTERVAL_TIME END_INTERVAL_TIME ELAPSED_TIME_SECS 2k3uw8n473r30 8278 04-JAN-13 23.00.25.5560 05-JAN-13 00.00.21.1620 23123 2k3uw8n473r30 8279 05-JAN-13 00.00.21.1620 05-JAN-13 01.00.38.2680 37145
So finden Sie die CBO-Statistiken in Ebiz Environment
SELECT owner, table_name, num_rows, TO_CHAR(last_analyzed,'DD-MON-YYYY HH24:MI:SS') last_analyzed FROM all_tables WHERE owner IN (SELECT upper(oracle_username) sname FROM fnd_oracle_userid WHERE oracle_id BETWEEN 900 AND 999 AND read_only_flag = 'U' UNION ALL SELECT DISTINCT upper(oracle_username) sname FROM fnd_oracle_userid a,fnd_product_installations b WHERE a.oracle_id = b.oracle_id ) ORDER BY owner, table_name;
Die Ausgabe dieser Anweisung sieht etwa so aus:
OWNER TABLE_NAME NUM_ROWS LAST_ANALYZED --- --------- ---------- ------------------------ ABM ABM_ACC_MAP_SUM_REP 0 06-DEC-2016 08:46:33 ABM ABM_ACT_ACC_RU_DAT 0 06-DEC-2016 08:46:35 ABM ABM_ACT_STA_RU_DAT 0 06-DEC-2016 08:46:36
So erhalten Sie die AWR-Berichte nach dem Upgrade
AWR-Berichte können abgerufen werden für
• den gesamten Zeitraum, in dem das Upgrade ausgeführt wird.
• Für die Dauer lang andauernder Jobs (d. h. zwischen den Snapshots, die kurz vor dem Start des Jobs und kurz nach dessen Ende erstellt wurden). .
• Jeder einzelne Schnappschuss.
So generieren Sie die AWR-Berichte
(1) Gehen Sie zu $ORACLE_HOME/rdbms/admin
(2) Führen Sie awrrpt.sql aus, um die AWR-Berichte zu generieren.
(3) Wählen Sie immer den HTML-Berichtstyp.
(4) Auf einer Oracle RAC-Instanz reicht normalerweise awrrpti.sql aus, da das Upgrade nur auf einem Oracle RAC-Knoten ausgeführt wird.
AWR-Berichte können automatisiert werden. Dies ist nützlich, wenn Sie eine große Anzahl von AWR-Berichten erstellen, insbesondere für aufeinanderfolgende Snapshots. Siehe den Abschnitt „Automating AWR Reports“ im My Oracle Support-Dokument „Performance Diagnosis with Automatic Workload Repository (Document 1674086.1)“.
Beachten Sie, dass einige feste Objekte und Wörterbuchobjekte (insbesondere WRH$_LATCH_CHILDREN, besonders wenn oder es gibt einen langen Aufbewahrungszeitraum oder ein kurzes Snapshot-Intervall) während des Upgrades erheblich gewachsen sind. Daher müssen vor dem Ausführen von AWRs möglicherweise feste Objekt- und Wörterbuchstatistiken gesammelt werden.
Verwandte Artikel
Automatic Workload Repository
Oracle ASH (Active Session History)
Oracle Performance Tuning
So erstellen Sie eine ADDM-Aufgabe und überprüfen ihren Bericht
So finden Sie Sitzungsdetails in der Oracle-Datenbank
