Response Time Analyse unter Oracle 10g

Response Time Analyse 10g
11/2005
Response Time Analyse
unter Oracle 10g
Dr. Günter Unbescheid
Database Consult GmbH – Jachenau
Copyright Database Consult GmbH
1
Response Time Analyse 10g
11/2005
Prolog 1
Response Time Analyse 10g
Performanz bezeichnet in der Informatik den
Ressourcenverbrauch und die Qualität der Ausgabe
von Programmen und Hardware. Meistens ist mit
Performance die Datenrate gemeint, also die Menge
von Daten die innerhalb einer bestimmten Zeitspanne
verarbeitet werden kann
Wikipedia
Optimierung ist die Steigerung der Performance
Optimierung kein Troubleshooting – auch wenn sie
oftmals grosse „Erleichterung“ verschafft.
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 2 von 197
2
Response Time Analyse 10g
11/2005
Prolog 2
Response Time Analyse 10g
Performanz – Vorsorge
Maßnahmen zur pauschalen Vermeidung von
möglichen Engpässen – wie z.B. Verteilung von IO,
Steigerung der Treffenquote im Cache, Vermeidung von
Full Scans
Performanz – Planung
Systemanalyse und spezifische Implementierung
Performanz – Tuning
Maßnahmen zur Optimierung der Antworzeit im Kontext
eines konkreten Dialogs/Programms
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 3 von 197
3
Response Time Analyse 10g
11/2005
Agenda
Response Time Analyse 10g
• Die Methode im Überblick
• Die Werkzeuge im Überblick
–
–
–
–
Die V$-Welt
Tracing
Repositories
Diverse Hilfsmittel
• Die Methode in der Praxis
– Instance-Tuning
– Applikations-Tuning
Stand der Technik: Oracle Database 10g Release 2
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 4 von 197
4
Response Time Analyse 10g
11/2005
Response Time Analyse 10g
Die Methode im Überblick
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 5 von 197
5
Response Time Analyse 10g
11/2005
Warum Performance-Tuning?
Response Time Analyse 10g
• Akzeptable/schnelle Antwortzeiten (AZ)
• Sicherstellen der Skalierbarkeit (S)
• Erkennen von Performance-Trends
Methode
AZ = Servicezeit + Wartezeit
S durch geringe Konkurrenz
um zentrale Ressourcen (gute Synchronisation)
S = Synch-Bedarf * Synch-Kosten
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 6 von 197
6
Response Time Analyse 10g
11/2005
Wie optimieren wir?
Response Time Analyse 10g
Reduktion der Anwortzeiten durch Optimierung
massgeblicher Faktoren
Methode
Ermittlung der Faktoren durch Aufzeichnung von
Ressourcenprofilen
Ressourcenprofile listen CPU- und Wartezeiten von
Kontexten
Oracle Wait Events und Zeitmodelle ermöglichen Profile
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 7 von 197
7
Response Time Analyse 10g
11/2005
Oracle Wait Events
v$event_name
Name
Null?
--------------- -------EVENT#
NAME
PARAMETER1
PARAMETER2
PARAMETER3
Methode
– 9iR2 = 360 events
– 10g R1 = 812 events
– 10g R2 = 872 events
Response Time Analyse 10g
• Kernel erfasst Wartezustände – drei zusätzliche Parameter
• Erste Anfänge in 7.0 – als Basis die Instanz, Session, Call (Trace)
• Anzahl Ständig erweitert:
Typ
-----------NUMBER
VARCHAR2(64)
VARCHAR2(64)
VARCHAR2(64)
VARCHAR2(64)
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 8 von 197
8
Response Time Analyse 10g
11/2005
Zeitmodelle
Methode
– Statistiken für Instanz und Session
• „CPU used by this session“
• „parse time CPU“
• „parse time elapsed“ etc.
Response Time Analyse 10g
• Kernel misst Elapsed- und CPU-Zeiten
• Genauigkeit in der Regel im Mikrosekundenbereich
(millionstel Sekunde – 10-6)
• Kontexte
– Ab 10g genauere Kontexte – 19 verschiedene Zeitstatistiken
• V$SYS_TIME_MODEL
• V$SESS_TIME_MODEL
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 9 von 197
9
Response Time Analyse 10g
11/2005
Kontext
Response Time Analyse 10g
Methode
• Fokus auf
geschäftsrelevante Dialoge
mit kritischem
Antwortzeitverhalten
• Kenntnis des
technologischen Umfelds
• Kenntnis des konkreten
Dialogablaufs – z.B. über
Aktivitätsdiagramme
• Messung zum richtigen
Zeitpunkt in originalem
System
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 10 von 197
10
Response Time Analyse 10g
11/2005
Kontext
C D S S S C D D S C
Session 2
S D D C D D D C C S
Session 3
D C C C D D S S C D
Session 4
C D S S S S C C D D
Response Time Analyse 10g
Session 1
Methode
Zeit
Grafik nach C. Millsap
C = 32,5 %
D = 37,5 %
S = 30,0 %
C = 25 %
D = 75 %
S=0%
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 11 von 197
11
Response Time Analyse 10g
11/2005
Ressourcenprofile
Response Time Analyse 10g
•
•
•
•
Liste von Wait-Events und CPU-Events
Dauer ist entscheidend, nicht die Anzahl
Absteigend sortiert nach Dauer
Konzentration auf maßgebliche Faktoren!
Methode
EVENT
TIME_WAITED % total AVERAGE_WAIT
------------------------------------------ ----------- ------- -----------log file parallel write
42260
42,25
12,79
log file sync
41923
41,91
140,21
db file sequential read
9015
9,01
1,16
control file sequential read
1774
1,77
,47
control file parallel write
1074
1,07
,24
os thread startup
885
,88
3,99
db file scattered read
630
,63
,81
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 12 von 197
12
Response Time Analyse 10g
11/2005
Die Methode noch einmal…
1. Auswahl des problematischen Dialogs bzw.Programms
Response Time Analyse 10g
2. Erstellen des Lastprofils zum maßgeblichen Zeitpunkt
Methode
3. Optmierung der zeitintensivsten Profilkomponenten
4. Auswahl des nächsten Dialogs …
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 13 von 197
13
Response Time Analyse 10g
11/2005
… darüber hinaus
ng
e
Ne
t
bs
zw
er
k
Netzwerk
Betriebssystem
Datenbank
Entwicklung/Anwendung
• Organisationsstrukturen
sollten dies unterstützen!
• Tuning ist (leider) nur reaktiv
• Proaktives Tuning
Methode
u
nd
we
An
at
D
k
an
b
n
e
tri
e
B
em
st
y
s
–
–
–
–
Response Time Analyse 10g
• Tuning ist Teamarbeit
– Design
– Architektur
– Implementierung
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 14 von 197
14
Response Time Analyse 10g
11/2005
… darüber hinaus
Response Time Analyse 10g
• Tuning bei selbst-tunender Datenbank?
– Weniger, jedoch komplexere Tuningprobleme
– Performance-Faktoren werden unterschätzt
– Macht Systemanalyse nicht überflüssig!
Methode
• Die „Säulen“ effizienten Tunings
– Effiziente Methode
– Gute Systemkenntnisse
– Umfassende Teamarbeit
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 15 von 197
15
Response Time Analyse 10g
11/2005
Response Time Analyse 10g
Die Werkzeuge im Überblick
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 16 von 197
16
Response Time Analyse 10g
11/2005
Werkzeuge
Response Time Analyse 10g
V$-Tabellen - V$-Erweiterungen 10g
Automatic Worklod Repository (AWR)
ADDM – Diagnostic Monitor und Advisories
Diagnostic Events
DBMS_MONITOR
STATSPACK
Eigene Skripte
trcsess
TKPROF und Trace-Analyzer
Hammerdba und dbaman
Markierungen (z.B. DBMS_APPLICATION_INFO)
Werkzeuge
•
•
•
•
•
•
•
•
•
•
•
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 17 von 197
17
Response Time Analyse 10g
11/2005
Polling versus Tracing
Response Time Analyse 10g
Polling
Werkzeuge
t
Tracing
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 18 von 197
18
Response Time Analyse 10g
11/2005
Dynamische Performance-Tabellen
Basis X$-Objekte
Views als V_$-Objekte
Synonyme V$-Objekte
Gruppen: V$ und GV$ (global virtual table)
Werkzeuge
–
–
–
–
Response Time Analyse 10g
• Traditionell – ab der Version 6
• Diverse "virtuelle" Tabellen als Fenster in SGABereiche, Dateien.
• Informationsdichte abhängig von Polling-Rate und SQL
• Darstellung durch V$-(Pseudo-)Tabellen
• Flüchtig – Werte gültig für Instanzlauf, Session
– ab 10g „Mini-Historien“ z.B. v$session_wait_history (10
rows)
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 19 von 197
19
Response Time Analyse 10g
11/2005
Dynamische Performance-Tabellen
– teilweise grobe Zeitraster in Centisekunden – v$sysstat,
v$sesstat
– teilweise hochgerechnete Mikrosekunden: cpu_time in v$sql
und v$sqlarea bei Versionen < 10g
Response Time Analyse 10g
• Problematik
– Separate SQL-Abfragen ohne „Lesekonsistenz“ - siehe
folgende Folie
– nur instrumentierte Wait Events werden erfasst
• Version 7 – 104
• Version 10g R2 - 872
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 20 von 197
20
Response Time Analyse 10g
11/2005
Dynamische Performance-Tabellen
Response Time Analyse 10g
SELECT a.VALUE va, b.VALUE vb, c.VALUE vc, d.VALUE vd
FROM (SELECT SUM (bbwait) AS VALUE
FROM x$kcbwds) a,
(SELECT total_waits AS VALUE
FROM v$system_event
WHERE event = 'buffer busy waits') b,
(SELECT SUM (COUNT) AS VALUE
FROM v$waitstat) c,
(SELECT SUM (VALUE) AS VALUE
FROM v$segment_statistics
WHERE statistic_name = 'buffer busy waits') d
/
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 21 von 197
21
Response Time Analyse 10g
11/2005
Beispiele V$
Response Time Analyse 10g
Werkzeuge
• Sessiondetails über v$session
• Transaktionen über v$transaction
• Wartezeiten der Sessions über v$session_wait,
v$session_event
• Wartezeiten der Instanz über v$system_wait
• CPU-Zeiten über v$sys_time_model,
v$sess_time_model
• Kennzahlen über v$sysstat, v$sessstat
• Übersicht durch v$fixed_table
• Definitionen über v$fixed_view_definition
• Indizierung über v$indexed_fixed_column
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 22 von 197
22
Response Time Analyse 10g
11/2005
V$ Erweiterungen 10g
SGA
Historien/Klassen
Historien/Klassen
Vordef. Metriken
•
•
•
•
•
•
Werkzeuge
Kennzahlen
Response Time Analyse 10g
Summaries und Histogramme
Kontextinfos
Kennzahlen – v$sysstat, v$sessstat, v$mystat
Kontextinfos – v$session_wait, v$sql
Metriken – v$metricname, v$metric
Klassifizierungen – v$metricgroup, v$system_wait_class
Historien über zirkulären Buffer in der SGA – v$filemetric_history
Summaries fassen Historien zusammen – v$sysmetric_summary
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 23 von 197
23
Response Time Analyse 10g
11/2005
V$ Erweiterungen Beispiele
v$sysstat
v$metricname
Werkzeuge
v$metricgroup
Response Time Analyse 10g
v$statname (mit class)
v$metric
v$sysmetric
v$sysmetric_history
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 24 von 197
24
Response Time Analyse 10g
11/2005
DBA_HIST_xxx Views
AWR
Werkzeuge
Summaries und Histogramme
SGA
Response Time Analyse 10g
SYSAUX
10g – Automatic Workload Repository
Historien/Klassen
Historien/Klassen
Vordef. Metriken
Kennzahlen
Kontextinfos
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 25 von 197
25
Response Time Analyse 10g
11/2005
AWR
Response Time Analyse 10g
• Automatic Workload Repository enthält
– Sammelt und speichert wait events, active session history,
Systemstatistiken
– Aufwendige SQL-Statements etc.
Advisories
"Snapshots" im
SYSAUX-Tablespace
AWR
dbms_workload_repository
V$Views
Werkzeuge
ADDM
Background-Prozesse (MMON)
MMNL-Prozess
SGA-Memory
ASH etc.
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 26 von 197
26
Response Time Analyse 10g
11/2005
ASH
Response Time Analyse 10g
• Active Session History (ASH)
• Daten aktiver Sessions (waiting/on CPU)
Werkzeuge
– Wait event mit p1 – p3
– Modul, Action, Client-ID
– Cursor-ID
• Gesammelt jede Sekunde in zirkulärem Buffer des
shared pool
– ASH buffers von v$sgastat
• Details über v$active_session_history
• Historische Daten in AWR
DBA_HIST_ACTIVE_SESS_HISTORY
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 27 von 197
27
Response Time Analyse 10g
11/2005
ADDM
– automatisch im Anschluss an Snapshot
– explizit über EM oder API (DBMS_ADVISOR, addmrpt.sql)
– Probleme (root causes) : Symptome : Informationen (nonproblem areas)
Werkzeuge
• Ziel: Optimierung der Antwortzeit der Instanz (DB time)
• Empfehlungen über Views und Reports
Response Time Analyse 10g
• Automatic Database Diagnostic Monitor
• analysiert die Daten des AWR
• Views:
–
–
–
–
DBA_ADVISOR_TASKS
DBA_ADVISOR_LOG
DBA_ADVISOR_FINDINGS
DBA_ADVISOR_RECOMMENDATIONS
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 28 von 197
28
Response Time Analyse 10g
11/2005
AWR Konfiguration
Response Time Analyse 10g
_awr_restrict_mode = { TRUE | FALSE }
STATISTICS_LEVEL = { TYPICAL | ALL }
Werkzeuge
View DBA_HIST_WR_CONTROL
dbms_workload_repository.modify_snapshot_settings
(interval => 45 -- Minuten
,retention => 20160 –- Minuten = 2 Wochen);
_addm_auto_enable = { TRUE | FALSE }
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 29 von 197
29
Response Time Analyse 10g
11/2005
Advice
Werkzeuge
–
–
–
–
–
Response Time Analyse 10g
• Hilfsmittel bei der Konfiguration von Speichergrössen
• verfügbar ab statistics_level = TYPICAL
• V$-Views
v$shared_pool_advice
v$java_pool_advice
v$db_cache_advice
v$sga_target_advice
v$pga_target_advice
• DBA-Views
– DBA_HIST_SHARED_POOL_ADVICE
– etc.
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 30 von 197
30
Response Time Analyse 10g
11/2005
ATO
Werkzeuge
Automatic Tuning Optimizer
Synonym: SQL Tuning Advisor
Expertensystem zur Optimierung von SQL-Statements
Detaillierte Analyse erstellt Report mit
Verbesserungsvorschlägen
• Expliziter Aufruf über Schnittstelle:
Response Time Analyse 10g
•
•
•
•
– Paket DBMS_SQLTUNE oder
– Enterprise Manager – „Advisor Central“
– SQL-Vorlagen – einzeln oder in Sets
• manuelle Angabe
• Cursor-Cache oder AWR-Historie
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 31 von 197
31
Response Time Analyse 10g
11/2005
SQL Acess Advisor
Response Time Analyse 10g
–
–
–
–
Werkzeuge
• Analysiert Indizes und Materialized Views und
Materialized View Logs
• Nutzung über Enterprise Manager oder API
(DBMS_ADVISOR)
• Vorgehen
Task definieren
Workload neu definieren oder verlinken
Empfehlungen generieren
Ergebnisse evaluieren
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 32 von 197
32
Response Time Analyse 10g
11/2005
Diagnostische Events
Response Time Analyse 10g
Werkzeuge
• Generierung von zusätzlichen Debug- und TraceInformationen
• Level-Angaben zur Steuerung des Detailierungsgrades
• schreiben Informationen in ASCII-Trace-Dateien
• Dateien können „roh“ interpretiert oder über Tools
formatiert werden.
• Hier interessant:
– 10046 – (extended) SQL-Trace inkl. Waits und Binds
– 10053 – Optimizer-Internals
– 10031, 10032 – Sort Internals
• Zu Event 10046 existieren Alternativen
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 33 von 197
33
Response Time Analyse 10g
11/2005
Package DBMS_MONITOR
Response Time Analyse 10g
• „End to End Application Tracing“
– Statistik-Generierung
– SQL-Tracing
Werkzeuge
• Datensammlung auf unterschiedlichen Ebenen:
– Session
– Service, Modul und/oder Action - hierarchisch
– Client Identifier
• manche Filter sind kombinierbar
• SQL-Trace erzeugt „rohe“ Trace-Dateien zur
Weiterverarbeitung
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 34 von 197
34
Response Time Analyse 10g
11/2005
STATSPACK
Response Time Analyse 10g
• Verfügbar ab Version 8i
• Erweiterung von utlbstat/utlestat
• Snapshots von V$-Objekten
Werkzeuge
– Umfänge steuerbar über Level 0 bis 10
•
•
•
•
•
Reports über Delta-Werte
Geeignet zur Parametrierung der Instanz,
Nur bedingt geeignet für einzelne Anwendungen
Vorgeschaltete, strategische Analyse wichtig!
Braucht mehr Ressourcen als AWR
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 35 von 197
35
Response Time Analyse 10g
11/2005
STATSPACK
Response Time Analyse 10g
• Installiert über ?/rdbms/admin/spcreate.sql
Werkzeuge
– User PERFSTAT
– Hilfstabellen
– Package STATSPACK
• Arbeiten mit
– EXECUTE statspack.snap;
– Job über SPAUTO.SQL
– Auswertungen:
• Instanzreport über SPREPORT.SQL und SPREPINS.SQL
• SQL-Report über SPREPSQL.SQL und SPRSQINS.SQL
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 36 von 197
36
Response Time Analyse 10g
11/2005
Eigene Skripte
db file ... und direct path ... Events
latch free
enqueue und log file synch
Buffer busy waits und free buffer waits und library
chache pin
– v$sessstat mit CPU-Statistiken ggf. v$sql
–
–
–
–
•
•
•
•
Response Time Analyse 10g
• Gur geeignet für Versionen < 10g
• Strikte Beschränkung auf wichtige Kennzahlen und Wait events,
z.B.
über Logoff-Trigger für Zusammenfassungen
Prozedurale Snapshots für Details – Auflösung von p1, p2, p3
Hilfstabellen speichern Historien
vertretbarer Overhead
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 37 von 197
37
Response Time Analyse 10g
11/2005
TKPROF
Response Time Analyse 10g
• „transient kernel profiler“
• formatiert einzelne SQL-Trace-Dateien
• Trace-Dateien erzeugt über
Werkzeuge
– Event 10046. DBMS_MONITOR, sql_trace = true
• unterschiedliche Filter und Sortierungen verfügbar
Tkprof <trace> <output> <explain>
<insert> <sort> <sys> .....
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 38 von 197
38
Response Time Analyse 10g
11/2005
TRCSESS Werkzeug
Response Time Analyse 10g
• Konsolidieren von Trace-Dateien für
– Client-Identifier
– Module, Actions
– Sessions, Services
Werkzeuge
• Nötig für Shared-Server, Parallelisierungen, Connection Pooling
• Java-Werkzeug
trcsess [output=output_file_name]
[session=session_id]
[clientid=client_id]
[service=service_name]
[action=action_name]
[module=module_name]
[trace_files]
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 39 von 197
39
Response Time Analyse 10g
11/2005
Trace-Analyzer
Werkzeuge
– RDBMS > 8.1.6
Response Time Analyse 10g
• Erzeugt detailliertes Last- und Ressourcenprofil daher
sehr gut für Response Time Analyse
• Skriptsammlung zur formatierten Ausgaben von
10046er Traces
• Über Metalink: TRCANLZR.sql (Note 224270.1)
• Erweiterte Funktionalität und Reports – auch für 8i
funktionabel
• läuft vollständig in der Datenbank – Tabellen und
Prozeduren
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 40 von 197
40
Response Time Analyse 10g
11/2005
hammerora
Response Time Analyse 10g
• Open Source Tool
• verfügbar über www.sourceforge.net
• Generiert Lasttest-Skripte aus SQL-Tracedateien
Umwandlung der Tracedatei in Oratcl
Oracle-Instantclient muss auf Testmaschine vorhanden sein
Virtuelle Nutzer können eingerichtet werden
TCL-Skripte editierbar
Werkzeuge
–
–
–
–
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 41 von 197
41
Response Time Analyse 10g
11/2005
dbaman
Response Time Analyse 10g
• Erweiterung der TCL-Sprache für den Zugriff auf
Oracle-Datebank über OCI
• Parsing von Oracle-Tracedateien
Werkzeuge
– Generierung von Testskripten
– u.a. wirkungsvolle Simulation von Applikationen
• Entwickelt von James Morle für „Scaling Oracle8i“
– http://www.morle.com/dbaman/index.htm
– Shareware – getestet bis Oracle 8.1
– verfügbar für Unix
• Voraussetzungen
– TCL 8.0, C-Compiler, Oracle 7.3+, 8.x, > 8 ?
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 42 von 197
42
Response Time Analyse 10g
11/2005
Application Services
Response Time Analyse 10g
• Logische Bereiche zur
"group of applications with common attributes"
Verteilung der Arbeitslast, Job Scheduling
Performancemessung und Monitoring
Grenzwerte und Tuning
Werkzeuge
–
–
–
–
select name, network_name from v$services;
-NAME
NETWORK_NAME
---------------- ----------------T10G.NndaDevi.de T10G.NandaDevi.de
T10GXDB
T10GXDB
SYS$BACKGROUND
SYS$USERS
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 43 von 197
43
Response Time Analyse 10g
11/2005
Application Services
Response Time Analyse 10g
• Views:
– v$active_services
– v$service_events, v$service_metrics u.a.
– v$session, DBA_THRESHOLDS
Werkzeuge
• Konfiguration:
– service_names (init.ora)
– DBMS_SERVICE (auch disconnect_session)
BEGIN
DBMS_SERVICE.CREATE_SERVICE
(SERVICE_NAME => 'App1', NETWORK_NAME => 'App1');
DBMS_SERVICE.START_SERVICE
(SERVICE_NAME => 'App1', INSTANCE_NAME => 'T10G');
END;
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 44 von 197
44
Response Time Analyse 10g
11/2005
Identifizierung
Response Time Analyse 10g
• Generiert individuelles Infix für Trace-Dateien
• Dynamisch für die Session
• Immer dann, wenn Session mehrere Prozesse benutzt:
Werkzeuge
– Parallel Query
– Shared Server
ALTER SESSION SET
tracefile_identifier = 'GU02';
Format: <sid>_ora_<pid>_GU02.trc
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 45 von 197
45
Response Time Analyse 10g
11/2005
Application Info
Response Time Analyse 10g
• client_info, module, action über DBMS_APPLICATION_INFO
• client_id über DBMS_SESSION – „auditierbar“
• Filtern teilweise möglich über
Werkzeuge
– v$session,
– v$sqlarea, v$sql
– dbms_monitor
BEGIN
DBMS_APPLICATION_INFO.SET_CLIENT_INFO
( CLIENT_INFO => 'Test-Client');
DBMS_SESSION.SET_IDENTIFIER
(CLIENT_ID => 'Test-ID');
END;
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 46 von 197
46
Response Time Analyse 10g
11/2005
Markierungen
Response Time Analyse 10g
• Individuelles Schreiben in Trace- und Alert-Dateien
– Markierung relevanter Code-Kontexte
• Setzen von Zeitstempeln
Werkzeuge
BEGIN
-- schreibt Zeitstempel in TRACE-Datei
dbms_system.ksdddt;
-- Einzug mit Doppelpunkten ("::::")
dbms_system.ksdind(4);
dbms_system.ksdwrt (1, 'Output written to trace file');
dbms_system.ksdwrt (2, 'Output written to alert log');
dbms_system.ksdwrt
(3, 'Output written to both trace file and alert log');
END;
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 47 von 197
47
Response Time Analyse 10g
11/2005
Resumeé
Response Time Analyse 10g
Werkzeuge
Oracle bietet eine Fülle von Werkzeugen, Kennzahlen und
Statistiken.
Projekte müssen die für sie relevanten Werkzeuge und
Methoden festlegen, um optimal optimieren zu können.
Werkzeuge und Kennzahlen sollten so überschabar und
einfach wie möglich sein!
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 48 von 197
48
Response Time Analyse 10g
11/2005
Response Time Analyse 10g
Die Praxis
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 49 von 197
49
Response Time Analyse 10g
11/2005
Übersicht
Response Time Analyse 10g
Ist-Zustand der Instanz/Datenbank ermitteln
Performance-Vorsorge für die Instanz/Datenbank
Tuning Projekt formulieren
Last-Profile erstellen
Last-Profile verstehen und bewerten
Typische Tuning-Szenarien
Die Praxis
•
•
•
•
•
•
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 50 von 197
50
Response Time Analyse 10g
11/2005
Ist-Zustand ermitteln
Die Praxis – IST-Zusatnd
– Name, Version, Charactersets
– SGA-Verwaltung
– Tuning-Einstellungen, z.B. AWR etc.
• „Dynamische“ Attribute
–
–
–
–
Response Time Analyse 10g
• Report über maßgebliche Daten einer
Instanz/Datenbank – „Steckbrief“ für die Kurzanalyse
• „Statische“ Attribute
Laufzeit und aktuelle Buffergrössen
Trefferquoten
Redo- und Transaktionslast
IO-Verteilung und IO-Last
• Werkzeuge: Statspack (Ausschnitte), Table-Function...
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 51 von 197
51
Response Time Analyse 10g
11/2005
Ist-Zustand
– gezielte Auswahl relevanter Kennzahlen – Übersichtlichkeit
– keine zusätzlichen Abhängigkeiten durch Zielinstallation (Monitoring
Account)
Die Praxis – IST-Zusatnd
*************** DATENBANK Steckbrief ****************
generiert am: 28.10.2005 08:19
**************
Allgemeine Information ***************
Name: ORA102 Unique Name: ora102 ID: 192045336
Plattform: Microsoft Windows IA (32-bit) Rolle: PRIMARY
Log-Mode: NOARCHIVELOG Open-Mode: READ WRITE Force Logging:
Open Resetlogs: NOT ALLOWED RSL Time: 29.09.05
Created: 29.09.2005 09:00 Current SCN: 660690
Standard Blockgroesse: 8192
Response Time Analyse 10g
• Table-Function
NO
Global Name: ORA102.DBCONSULT.DE
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 52 von 197
52
Response Time Analyse 10g
11/2005
IST-Zustand
Response Time Analyse 10g
+++ Services:
ora102XDB
ora102.dbconsult.de
SYS$BACKGROUND
SYS$USERS
Die Praxis – IST-Zusatnd
+++ Instances:
Nr.: 1 Name: ora102 Version: 10.2.0.1.0 Role: PRIMARY_INSTANCE
Start: 24.10.2005 14:50:35 Laufzeit (Tage/Std.): +003 17:28:54
Host: DATTATREYA2
+++ SGA-Daten in MB:
sga_max_size
432
sga_target
432
Buffer Cache Size
Java Pool Size
Large Pool Size
Redo Buffers
Shared Pool Size
Streams Pool Size
284
12
4
3
128
0
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 53 von 197
53
Response Time Analyse 10g
11/2005
IST-Zustand
Response Time Analyse 10g
+++ Redo-Daten in MB:
Gruppe 1
50
Members 1
Gruppe 2
50
Members 1
Gruppe 3
50
Members 1
+++ IO-Kennzahlen:
Anzahl Datendateien: 4
Gesamtgroesse in GB: 1,14
Die Praxis – IST-Zusatnd
C:\ORACLE\ORADATA\ORA102\SYSTEM01.DBF
MinTime: 0
MaxRTime: 306 MaxWTime: 91
C:\ORACLE\ORADATA\ORA102\UNDOTBS01.DBF
MinTime: 0
MaxRTime: 120 MaxWTime: 34305
C:\ORACLE\ORADATA\ORA102\SYSAUX01.DBF
MinTime: 0
MaxRTime: 219 MaxWTime: 353
C:\ORACLE\ORADATA\ORA102\USERS01.DBF
MinTime: 0
MaxRTime: 7
MaxWTime: 20
+++ Undo Management:
undo_management
undo_tablespace
undo_retention
AUTO
UNDOTBS1
900
+++ Undo mit Snapshot too old oder Unexpired steals:
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 54 von 197
54
Response Time Analyse 10g
11/2005
IST-Zustand
Response Time Analyse 10g
+++ AWR, ADDM und Statistik-Historie:
statistics_level
TYPICAL
_awr_restrict_mode
FALSE
_addm_auto_enable
TRUE
Stats Historie ab: 29.09.05 09:03
Aufbewahrungszeit: 31
+00000 01:00:00.0
+00007 00:00:00.0
AWR Disk usage in MB:
ASH Pool usage in MB:
30,94
2
Die Praxis – IST-Zusatnd
AWR Interval (Day/Second):
AWR Aufbewahrungszeit (Day/Second):
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 55 von 197
55
Response Time Analyse 10g
11/2005
IST-Zustand
Response Time Analyse 10g
*************** Response Time Daten
+++ Zeitangaben in Minuten:
CPU (server + background): 8,65
Wait (non-idle)
: 76,12
****************
Percent CPU Time: 10,2%
Percent Wait Time: 89,8%
Die Praxis – IST-Zusatnd
+++ Massgebliche Elapsed Zeiten in Minuten:
77,19
background elapsed time
60,49
sql execute elapsed time
2,36
PL/SQL execution elapsed time
1,99
parse time elapsed
1,73
hard parse elapsed time
+++ Massgebliche Wartezeiten nach Klassen in Minuten:
40,44
System I/O
52,55%
28,1
Commit
36,51%
3,73
Concurrency
4,85%
2,9
User I/O
3,77%
1,76
Other
2,29%
,01
Application
,01%
,01
Network
,01%
,01
Configuration
,01%
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 56 von 197
56
Response Time Analyse 10g
11/2005
IST-Zustand
Response Time Analyse 10g
*WERT
100
100
1405,33
67
38,78
26,21
,99
0
0
0
0
,14
,09
,13
0
Die Praxis – IST-Zusatnd
******************
Metriken
********************
+++ Current Values:
*INTERVAL (Sek.)*METRIK
61
Buffer Cache Hit Ratio
61
Redo Allocation Hit Ratio
61
Redo Generated Per Txn
61
Logical Reads Per Txn
61
Cursor Cache Hit Ratio
61
Database Wait Time Ratio
61
Response Time Per Txn
600
Average File Read Time (Files-Long)
600
Average File Read Time (Files-Long)
600
Average File Read Time (Files-Long)
600
Average File Read Time (Files-Long)
600
Average File Write Time (Files-Long)
600
Average File Write Time (Files-Long)
600
Average File Write Time (Files-Long)
600
Average File Write Time (Files-Long)
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 57 von 197
57
Response Time Analyse 10g
11/2005
IST-Zustand
*MAXWERT
54,69
95,68
100
53754,67
46823,68
100
100
*AVG
6,53
21,03
25,01
1156,32
3703,59
100
99,78
Die Praxis – IST-Zusatnd
*MINWERT
0
0
0
0
0
0
0
Response Time Analyse 10g
+++ Historic Values:
*INTERVAL (Min) *METRIK
751
Response Time Per Txn
751
Database Wait Time Ratio
751
Cursor Cache Hit Ratio
751
Logical Reads Per Txn
751
Redo Generated Per Txn
751
Redo Allocation Hit Ratio
751
Buffer Cache Hit Ratio
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 58 von 197
58
Response Time Analyse 10g
11/2005
Statspack
Response Time Analyse 10g
•
•
•
•
gut geeignet zur Ermittlung allgemeiner Kennzahlen
zur „Performance“-Vorsorge und IST-Darstellung
Doku unter ?\rdbms\admin\spdoc.txt
Skripte lassen sich anpassen
Listing all Completed Snapshots
Snap
Instance
DB Name
Snap Id
Snap Started
Level Comment
------------ ------------ --------- ----------------- ----- -------------------ora102
ORA102
1 26 Okt 2005 12:06
5
11 26 Okt 2005 13:28
5
21 28 Okt 2005 08:41
5
22 28 Okt 2005 08:55
10
Die Praxis – IST-Zusatnd
SQL> exec statspack.snap
SQL> start ?\rdbms\admin\spreport.sql
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Geben Sie einen Wert f³r begin_snap ein:
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 59 von 197
59
Response Time Analyse 10g
11/2005
Statspack –Ausschnitte
Response Time Analyse 10g
Cache Sizes
Begin
End
---------- ---------Buffer Cache:
292M
284M
8K
Shared Pool Size:
2,828K
Std Block Size:
128M
Log Buffer:
Redo size:
Logical reads:
Block changes:
Physical reads:
Physical writes:
User calls:
Parses:
Hard parses:
.......
Per Second
--------------475.25
51.65
2.67
0.01
0.12
0.12
0.51
0.02
Per Transaction
--------------15,589.84
1,694.37
87.65
0.39
4.05
3.85
16.89
0.74
Die Praxis – IST-Zusatnd
Load Profile
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 60 von 197
60
Response Time Analyse 10g
11/2005
Statspack –Ausschnitte
%:
%:
%:
%:
%:
100.00
99.98
96.78
46.35
88.80
Redo NoWait %:
In-memory Sort %:
Soft Parse %:
Latch Hit %:
% Non-Parse CPU:
100.00
100.00
95.63
100.00
89.95
Top 5 Timed Events
Event
Waits
Time (s)
------------------------- ------------ ----------log file sync
1,518
1,635
log file parallel write
6,958
1,622
db file parallel write
12,178
366
CPU time
191
control file sequential read
20,046
121
AVG %Total
wait
Call
(ms)
Time
------ -----1077
39.3
233
39.0
30
8.8
4.6
6
2.9
Die Praxis – IST-Zusatnd
Buffer Nowait
Buffer Hit
Library Hit
Execute to Parse
Parse CPU to Parse Elapsd
Response Time Analyse 10g
Instance Efficiency Percentages
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 61 von 197
61
Response Time Analyse 10g
11/2005
Statspack Ausschnitte
....
....
Die Praxis – IST-Zusatnd
Background Wait Events DB/Inst: ORA102/ora102 Snaps: 1-21
-> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0
-> Only events with Total Wait Time (s) >= .001 are shown
-> ordered by Total Wait Time desc, Waits desc (idle events last)
Response Time Analyse 10g
Wait Events DB/Inst: ORA102/ora102 Snaps: 1-21
-> s - second, cs - centisecond, ms - millisecond, us - microsecond
-> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0
-> Only events with Total Wait Time (s) >= .001 are shown
-> ordered by Total Wait Time desc, Waits desc (idle events last)
Latch Activity DB/Inst: ORA102/ora102 Snaps: 1-21
->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for
willing-to-wait latch get requests
->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests
->"Pct Misses" for both should be very close to 0.0
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 62 von 197
62
Response Time Analyse 10g
11/2005
AWR-Report
Response Time Analyse 10g
• 10g produziert standardmässig Snapshots
• Skript ?\rdms\admin\awrreport.sql produziert Reports
ähnlich Statspack
– HTML- oder Textformat
• relevante Abschnitte:
Die Praxis – IST-Zusatnd
– „Load Profile“ – „Instance Efficiency“ – „Top 5 Timed Events“
– „Time Model Statistics“
SQL> start ?\rdbms\admin\awrrpt
Current Instance
~~~~~~~~~~~~~~~~
DB Id
DB Name
Inst Num Instance
----------- ------------ -------- -----------192045336 ORA102
1 ora102
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
...
Type Specified: html
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 63 von 197
63
Response Time Analyse 10g
11/2005
Performance-Vorsorge
– Optimierung/Monitoring von wichtigen Metriken
– nach Möglichkeit effizientes Applikationsdesign
– nach Möglichkeit effizientes Instanz Design
Response Time Analyse 10g
• Response Time Optimierung ist im Bereich der Instanz
nicht möglich, daher:
• Konzentration auf wenige, überschaubare Kennzahlen –
weniger ist mehr!
–
–
–
–
–
Buffer Cache Hit Ratio – ca. 90%
Library Cache Hit Ratio – >= 90%
Redo Log Allocation Retries – sehr gering
IO-Verteilung
Betriebssystem: IO, Paging Swapping, Filesystem/Rawdevice,
Blockgrössen
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 64 von 197
64
Response Time Analyse 10g
11/2005
Instanz Design
Automatic Undo Management
Locally Managed Tablespaces
Connectivity: MTS, dedicated server, connection pooling
ggf. ASSM für Segmentverwaltung
ggf. Session Cursor Cache
Statistiken über DBMS_STATS auch Systemstatistiken
Blockgrössen auswählen
Multiple Buffer Pools: Keep-Pool, Recycle-Pool
Large Pool – bei Shared Server, RMAN, Parallel Query
PGA_AGGREGATE_TARGET
Installationsplanung
Response Time Analyse 10g
•
•
•
•
•
•
•
•
•
•
•
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 65 von 197
65
Response Time Analyse 10g
11/2005
Systemstatistiken
-- laufende Kontrolle
STATID
C1
--------- ------------SYSTEM_01 AUTOGATHERING
...
SYSTEM_01 COMPLETED
Response Time Analyse 10g
BEGIN DBMS_STATS.GATHER_SYSTEM_STATS(
gathering_mode => 'INTERVAL', interval => 2
, stattab => 'STAT_TABLE' , statown => 'DEVELOPER'
, statid => 'SYSTEM_01'); END;
C2
C3
---------------- ---------------08-09-2003 16:29 08-11-2001 16:29
08-09-2001 16:41 08-09-2001 16:43
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 66 von 197
66
Response Time Analyse 10g
11/2005
Systemstatistiken
-- Übertragen in Dictionary = aktivieren
BEGIN DBMS_STATS.IMPORT_SYSTEM_STATS(
stattab => 'STAT_TABLE', statid => 'SYSTEM_01',
statown => 'DEVELOPER'); END;
SELECT * FROM sys.aux_stats$;
SNAME
-------------------SYSSTATS_INFO
SYSSTATS_INFO
SYSSTATS_INFO
SYSSTATS_INFO
SYSSTATS_MAIN
SYSSTATS_MAIN
SYSSTATS_MAIN
SYSSTATS_MAIN
SYSSTATS_MAIN
SYSSTATS_MAIN
PNAME
-----------------STATUS
DSTART
DSTOP
FLAGS
SREADTIM
MREADTIM
CPUSPEED
MBRC
MAXTHR
SLAVETHR
Response Time Analyse 10g
-- Löschen von Dictionary aux_stats$
BEGIN DBMS_STATS.DELETE_SYSTEM_STATS; END;
PVAL1
PVAL2
---------- -------------------COMPLETED
08-09-2001 16:40
08-09-2001 16:42
0
7.581
56.842
117
9
47104
-1
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 67 von 197
67
Response Time Analyse 10g
11/2005
Systemstatistiken
Response Time Analyse 10g
sreadtim : wait time to read single block, in
milliseconds
mreadtim : wait time to read a multiblock, in
milliseconds
cpuspeed : cycles per second, in millions
mbrc : mulitblock read count (average)
maxthr:maximum I/O system throughput, in bytes/sec
Slavethr:average slave I/O throughput, in bytes/sec
• PLAN_TABLE.CPU_COST: benötigte Maschinen-Zyklen
• PLAN_TABLE.IO_COST: gelesene Datenblöcke
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 68 von 197
68
Response Time Analyse 10g
11/2005
Performance Vorsorge
–
–
–
–
–
–
–
v$sysstat
v$sgastat
v$filestat
v$osstat
v$rollstat, v$undostat
v$pgastat
v$osstat
Response Time Analyse 10g
• relevonate Kennzahlen aus Reports (siehe vorne) oder
• Manuelle Auswertung der Instanz über
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 69 von 197
69
Response Time Analyse 10g
11/2005
Tuning-Projekt
–
–
–
–
Programmatisches Umfeld
Relevanz für das geschäftliche Umfeld
Ist- und Soll-Zahlen
Genaue Angaben zum Kontext des Performance-Problems
• Server, Instanz, Zeitrahmen
• Session, Modul, Schema, Service
– erwarteter (geschäftlicher) Nutzen
Response Time Analyse 10g
• Exakte Formulierungen, aus den folgenden Bereichen:
• Entscheidung zur Strategie und zu den Werkzeugen
– Polling versus Tracing
– Auswertungsverfahren
• Keine Parametervorgaben akzeptieren!
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 70 von 197
70
Response Time Analyse 10g
11/2005
Tuning-Projekt
–
–
–
–
–
–
Schnell einsetzbare V$Abfragen
genaue Synchronisierung erforderlich – manuell oder Trigger
unmittelbare Auswertung für Session oder Service
keine zusätzlichen Tools
lückenhafte Kennzahlen
Ungenaue Analysen bei diffusen Trends
Response Time Analyse 10g
• Polling
• Tracing
–
–
–
–
lückenlose Protokollierung, exakte Kontexte
alle Filter möglich: Session, Module, Service
Auswertung erfordert Tools
ggf. grosse Datenmenge und damit erschwerte Analysen
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 71 von 197
71
Response Time Analyse 10g
11/2005
Polling
– v$sess_time_model
– v$sessstat – diverse Statistiken
• Wartezeiten:
–
–
–
–
–
–
–
–
v$session_event – mit Historie der Session
v$session – mit aktuellen Wartezyklen
v$session_wait – aktuelle Wartezyklen
v$session_wait_history – die letzten 10 Wartezyklen
akt.S.
v$service_event – Zusammenfassungen per Service per
Event
v$session_wait_class – Zusammenfassung nach Klassen
v$service_wait_class – Zusammenfassung nach Klassen
v$active_session_history – Historie v.Wartezyklen akt.
Sessions
Response Time Analyse 10g
• CPU-Zeiten:
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 72 von 197
72
Response Time Analyse 10g
11/2005
CPU-Statistiken >= 10g
Response Time Analyse 10g
background cpu time
background elapsed time
connection management call elapsed time
DB CPU
DB time
failed parse elapsed time
failed parse (out of shared memory) elapsed time
hard parse (bind mismatch) elapsed time
hard parse elapsed time
hard parse (sharing criteria) elapsed time
inbound PL/SQL rpc elapsed time
Java execution elapsed time
parse time elapsed
PL/SQL compilation elapsed time
PL/SQL execution elapsed time
repeated bind elapsed time
RMAN cpu time (backup/restore)
sequence load elapsed time
sql execute elapsed time
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 73 von 197
73
Response Time Analyse 10g
11/2005
CPU Statistiken <= 10g
Response Time Analyse 10g
• Aus v$sysstat oder v$sysstat
• CPU Zeit im wesentlichen nötig für
– Parsing von SQL
– Logical IO/Blockzugriffe im Buffer
12
11
161
46
43
332
331
330
328
329
8
CPU used by this session
CPU used when call started
gc CPU used by this session
global enqueue CPU used by this session
IPC CPU used by this session
parse count (failures)
parse count (hard)
parse count (total)
parse time cpu
parse time elapsed
recursive cpu usage
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 74 von 197
74
Response Time Analyse 10g
11/2005
Tracing <= 10g
Response Time Analyse 10g
•
•
•
•
Event 10046
Session wird "getracet"
Session führt Aktionen aus
Tracing schreibt für Prozesse
– Trace-Datei in user_dump_dest (dynamisch)
– max_dump_file_size beachten!
• Session kann mehrere Prozesse nutzen
– MTS oder Parallel-Query
– tracefile_identifier nutzen (dynamisch)
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 75 von 197
75
Response Time Analyse 10g
11/2005
Tracing <= 10g
•
•
•
•
Response Time Analyse 10g
alter session set timed_statistics = true;
alter session set max_dump_file_size = unlimited;
alter session set events
'10046 trace name context forever, level 12'
alter session set events
'10046 trace name context off';
Level 1 – wie sql_trace = true
Level 4 – 1 + Bindevariablen
Level 8 – 1 + wait events
Level 12 – 1 + BV + WE
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 76 von 197
76
Response Time Analyse 10g
11/2005
Tracing <= 10g
Response Time Analyse 10g
dbms_system.set_bool_param_in_session
(72, 166, 'timed_statistics', true);
dbms_system.set_int_param_in_session
(72, 166, 'max_dump_file_size', 2147483647);
dbms_system.set_ev(72, 166, 10046, 8, '');
/* Tracing ausschalten */
dbms_system.set_ev(72, 166, 10046, 0, '');
-- ################
DBMS_SUPPORT.START_TRACE_IN_SESSION
(SID => 12, SERIAL => 77
, WAITS => TRUE, BINDS => TRUE);
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 77 von 197
77
Response Time Analyse 10g
11/2005
Tracing <= 10g
Response Time Analyse 10g
# ORADEBUG über SQLPlus
# für Prozess
ORADEBUG SETORAPID 8 –- verifizieren über v$process, oder
ORADEBUG SETMYPID –- fuer eigenen Prozess
ORADEBUG EVENT 10046 TRACE NAME CONTEXT FOREVER, LEVEL 12
# für die eigene Session
ORADEBUG SESSION_EVENT 10046 TRACE NAME CONTEXT FOREVER, LEVEL 12
ORADEBUG SESSION_EVENT event TRACE NAME CONTEXT OFF
# weitere Alternativen
EXECUTE dbms_system.set_ev (9,29,10046,8,'');
EXECUTE dbms_system.set_ev (9,29,10046,0,'');
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 78 von 197
78
Response Time Analyse 10g
11/2005
Tracing <= 10g
Response Time Analyse 10g
-- Logon-Trigger
CREATE OR REPLACE TRIGGER b4711_logon
AFTER LOGON ON b4711.SCHEMA
BEGIN
dbms_session.set_sql_trace (TRUE);
END;
CREATE OR REPLACE TRIGGER b4711_logoff
BEFORE LOGOFF ON b4711.SCHEMA
BEGIN
dbms_session.set_sql_trace (FALSE);
END;
-- Beliebig aktivieren
ALTER TRIGGER b4711 _logon ENABLE;
ALTER TRIGGER b4711 _logon DISABLE;
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 79 von 197
79
Response Time Analyse 10g
11/2005
Tracing <= 10g
Response Time Analyse 10g
•
•
•
•
Dauerhaftes Setzen der Events
Mehrfache Events immer in Folge oder über ":"!
Nicht für immediate dumps geeignet
Alert-Datei zeigt aktive Events
# SQL-Trace aktiviert am 12.08.2003 GU
EVENT='10046 trace name context forever, level 12'
# Interna des CBO-Optimizers aktiviert am 1.9.03
EVENT='10053 trace name context forever, level 1'
# alternativ mit :, \ für Zeilenumbruch
EVENT="\
10046 trace name context forever, level 12:\
10053 trace name context forever, level 1"
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 80 von 197
80
Response Time Analyse 10g
11/2005
Tracing <= 10g
Response Time Analyse 10g
• Lesen eingestellter Events und Level
• Zeigt Werte nur für die eigene Session
declare event_level number;
begin
for i in 10000..10999 loop
sys.dbms_system.read_ev(i,event_level);
if (event_level > 0) then
dbms_output.put_line('Event
'||to_char(i)||' set at level '
|| to_char(event_level));
end if;
end loop;
end;
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 81 von 197
81
Response Time Analyse 10g
11/2005
Tracing >= 10g
Response Time Analyse 10g
-- Erweitertes Tracing mit BV und WE
dbms_monitor.session_trace_enable (10,47,TRUE,TRUE);
-- einfaches Tracing
dbms_monitor.session_trace_enable (10,47);
-- Ausschalten
dbms_monitor.session_trace_disable (10,47);
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 82 von 197
82
Response Time Analyse 10g
11/2005
Session-Kontext
– set_module (<module>,<action>)
– set_client_info(<client_info>)
– hervorragendes Tracing von SQL-Code im Rahmen von Triggern,
Prozeduren, Packages
– Setzen des Session-Kontexts
set_module
set_client_info
Response Time Analyse 10g
• Paket DBMS_APPLICATION_INFO
v$sqlarea..
v$session
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 83 von 197
83
Response Time Analyse 10g
11/2005
Session-Kontext
Response Time Analyse 10g
BEGIN
dbms_application_info.SET_MODULE
('TestModul','TestAction'); END;
SELECT .....
INSERT ....
UPDATE ...
BEGIN
dbms_application_info.SET_MODULE('',''); END;
SELECT sql_text FROM v$sql
WHERE module = 'TestModul';
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 84 von 197
84
Response Time Analyse 10g
11/2005
Tracing >= 10g
Response Time Analyse 10g
•
•
•
•
Hierarchische Filter für Servicename, Modul und Action
Separater Filter für Client Identifier
Regeln wirken kumulativ
Ausgabe der definierten regeln über View
DBA_ENABLED_TRACES
dbms_monitor.serv_mod_act_trace_enable
('APP1', 'PACK_X', 'Proc_Y');
dbms_monitor.serv_mod_act_trace_disable
('APP1', 'PACK_X', 'Proc_Y');
dbms_monitor.client_id_trace_enable('GU');
dbms_monitor.client_id_trace_disable('GU');
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 85 von 197
85
Response Time Analyse 10g
11/2005
Tracefile ermitteln und öffnen
Response Time Analyse 10g
Rem ggf. an OS oder Ora-Version anpassen
SET SUFFIX TRC
COLUMN filename NEW_VALUE filename
SELECT p1.value||'\'||p2.value||'_ora_'||p.spid
||decode(p3.value,null,'','_'||p3.value) filename
FROM
v$process p,
v$session s,
v$parameter p1,
v$parameter p2,
v$parameter p3
WHERE p1.name = 'user_dump_dest'
AND p2.name = 'db_name'
AND p3.name = 'tracefile_identifier'
AND p.addr = s.paddr
AND s.audsid = USERENV ('SESSIONID');
EDIT &&filename
SET SUFFIX SQL
COLUMN filename CLEAR
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 86 von 197
86
Response Time Analyse 10g
11/2005
Tracing
Response Time Analyse 10g
• Mögliche weitere Arbeitsschritte:
–
–
–
–
–
ggf. zusammenführen verschiedener Tracde-Dateien
Verstehen der „rohen“ Trace-Datei
Formatierung über TKPROF
Formatierung über Trace Analyzer (trcanlzr.sql)
Tools von www.hotsos.com
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 87 von 197
87
Response Time Analyse 10g
11/2005
Tracing
Response Time Analyse 10g
• Zusammenführen von Trace-Dateien für
– Client-Identifier
– Module, Actions
– Sessions
trcsess [output=output_file_name]
[session=session_id]
[clientid=client_id]
[service=service_name]
[action=action_name]
[module=module_name]
[trace_files]
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 88 von 197
88
Response Time Analyse 10g
11/2005
Tracing – Rawtrace
Response Time Analyse 10g
• sinnvoll bei unvollständigen Auswertungen
• exakte Zuordnung von Wait Events zu Calls
• Gliederung
– Allgemeiner Header
– Identification:
*** ACTION NAME:(Action X) 2005-11-03 13:24:10.265
*** MODULE NAME:(Module A) 2005-11-03 13:24:10.265
*** SERVICE NAME:(SYS$USERS) 2005-11-03 13:24:10.265
*** CLIENT ID:(GU) 2005-11-03 13:24:10.265
*** SESSION ID:(16.1022) 2005-11-03 13:24:10.265
=====================
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 89 von 197
89
Response Time Analyse 10g
11/2005
Tracing – Rawtrace
Response Time Analyse 10g
•
•
•
•
•
•
•
•
•
Cursor Informationen direkt nach Parse Call oder später
Nummer nimmt Bezug auf nachfolgende Calls
len – Länge des Stmts,
uid – schema ID des parsenden Benutzers
oct – Oracle Call Type
lid – privileged user id
tim Zeitstempel in Mikrosekunden (>= 9i) z.B. gettimeofday
hv – hash value
ad - address
PARSING IN CURSOR #7 len=32 dep=0 uid=58 oct=3 lid=58
tim=22374257176 hv=2935929963 ad='1fd73f00'
select count(*) from dba_objects
END OF STMT
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 90 von 197
90
Response Time Analyse 10g
11/2005
Tracing – Rawtrace
Bindevariablen werden positionsbedingt aufgeführt
oacdty – external datatype (hier varchar) (entspricht dump-Ausgabe)
avl – Länge; value – Länge
Details über Note 39817.1 (Metalink)
Scl und pre = scale und precision
=====================
PARSING IN CURSOR #7 len=58 dep=1 uid=58 oct=3 lid=58
tim=535121950 hv=1332351685 ad='1fcb0338'
SELECT COUNT(*) FROM DBA_TABLES WHERE TABLE_NAME LIKE :B1
END OF STMT
...
BINDS #7:
kkscoacd
Bind#0
oacdty=01 mxl=32(30) mxlc=00 mal=00 scl=00 pre=00
oacflg=13 fl2=206001 frm=01 csi=178 siz=32 off=0
kxsbbbfp=0762442c bln=32 avl=04 flg=09
value="DBA%"
Response Time Analyse 10g
•
•
•
•
•
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 91 von 197
91
Response Time Analyse 10g
11/2005
Tracing – Rawtrace
Response Time Analyse 10g
• Wait Events
– im Kontext von DB-Calls (erscheinen vor diesen hier grün)
– zwischen DB-Calls (erscheinen separat hier blau)
• nam – Names des Events
• ela – elapsed time
• die letzten 3 entsprechen p1, p2, p3 von v$session_wait
EXEC #7:c=156250,e=153309,p=0,cr=2,cu=0,mis=1,r=0,dep=1,og=1,tim=535275386
WAIT #7: nam='db file sequential read' ela= 11988 file#=1 block#=10859
blocks=1 obj#=3 tim=535338348
FETCH #7:c=109375,e=123525,p=1,cr=2797,cu=0,mis=0,r=1,dep=1,og=1,tim=535398965
EXEC #10:c=265625,e=277739,p=1,cr=2799,cu=0,mis=0,r=1,dep=0,og=1,tim=535399206
WAIT #10: nam='SQL*Net message to client' ela= 6 driver id=1111838976 #bytes=1
p3=0 obj#=3 tim=535399302
WAIT #10: nam='SQL*Net message from client' ela= 459 driver id=1111838976
#bytes=1 p3=0 obj#=3 tim=535399827
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 92 von 197
92
Response Time Analyse 10g
11/2005
Tracing - Rawtrace
Response Time Analyse 10g
• STAT kennzeichnet Rowsources (Ausführungspläne) – ähnlich
plan_table
• id – identifier; cnt – rowcount ; pid – parent id
• obj – object id; op – operation, time – Zeit in Mikrosekunden
• cr – consisent reads; pr – physical reads; pw – physical writes
STAT #7 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=5248
pr=0 pw=0 time=407489 us)'
STAT #7 id=2 cnt=50337 pid=1 pos=1 obj=2371 op='VIEW DBA_OBJECTS
(cr=5248 pr=0 pw=0 time=1562536 us)'
STAT #7 id=3 cnt=50337 pid=2 pos=1 obj=0 op='UNION-ALL (cr=5248
pr=0 pw=0 time=1159833 us)'
STAT #7 id=4 cnt=50337 pid=3 pos=1 obj=0 op='FILTER (cr=5247 pr=0
pw=0 time=505435 us)'
STAT #7 id=5 cnt=51503 pid=4 pos=1 obj=0 op='HASH JOIN (cr=625
pr=0 pw=0 time=980596 us)'
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 93 von 197
93
Response Time Analyse 10g
11/2005
Tracing - Rawtrace
PARSING IN CURSOR #1 len=46 dep=1 uid=0 oct=3 lid=0 tim=3282021354
hv=1343089354 ad='2aac0994'
select node,owner,name from syn$ where obj#=:1
END OF STMT
PARSE #1:c=0,e=46,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=3282021346
PARSING IN CURSOR #1 len=179 dep=1 uid=0 oct=3 lid=0 tim=3282058960
hv=2812844157 ad='2aaf9d38'
select owner#,..... from dependency$ d, obj$ o where d_obj#=:1 and
p_obj#=obj#(+) order by order#
END OF STMT ...
=====================
PARSING IN CURSOR #7 len=32 dep=0 uid=58 oct=3 lid=58 tim=3282347867
hv=2935929963 ad='1fcc1024'
select count(*) from dba_objects
END OF STMT
PARSE #7:
c=328125,e=327028,p=0,cr=97,cu=0,mis=1,r=0,dep=0,og=1,tim=3282347858
Response Time Analyse 10g
• Rekursive Calls erscheinen vor ihren Parents
• Parents enthalten in elapsed time die Zeiten ihrer Kinder
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 94 von 197
94
Response Time Analyse 10g
11/2005
Tracing - Rawtrace
Response Time Analyse 10g
5
dep=0
2
3
4
dep=1
dep=1
dep=1
1
dep=2
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 95 von 197
95
Response Time Analyse 10g
11/2005
TKPROF
Response Time Analyse 10g
C:\oracle\admin\ora102\udump>tkprof
Usage: tkprof tracefile outputfile [explain= ] [table= ]
[print= ] [insert= ] [sys= ] [sort= ]
table=schema.tablename
Use 'schema.tablename' with 'explain=' option.
explain=user/password
Connect to ORACLE and issue EXPLAIN PLAN.
print=integer
List only the first 'integer' SQL statements.
aggregate=yes|no
insert=filename List SQL statements and data inside INSERT statements.
sys=no
TKPROF does not list SQL statements run as user SYS.
record=filename Record non-recursive statements found in the trace file.
waits=yes|no
Record summary for any wait events found in the trace
file.
sort=option
Set of zero or more of the following sort options:
prscnt number of times parse was called
prscpu cpu time parsing
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 96 von 197
96
Response Time Analyse 10g
11/2005
TKPROF Output
count
cpu
elapsed
disk
query
current
rows
Summaries
–
–
–
–
read consistency
kein Schema-Trap mehr!
Recursion-Trap
Time Trap (locking)
Response Time Analyse 10g
• Zeiten nur bei timed_statistics = true
• „Traps“ beachten
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 97 von 197
97
Response Time Analyse 10g
11/2005
TKPROF
call
count
------- -----Parse
1
Execute
1
Fetch
4
------- -----total
6
cpu
elapsed
disk
query
current
-------- ---------- ---------- ---------- ---------0.06
0.06
0
2
0
0.02
0.01
0
0
0
0.05
0.04
0
7
0
-------- ---------- ---------- ---------- ---------0.13
0.12
0
9
0
rows
---------0
0
45
---------45
Response Time Analyse 10g
***************************************************************************
select * from hr.employees where department_id = 50
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: SYS
Rows
------45
Row Source Operation
--------------------------------------------------TABLE ACCESS FULL EMPLOYEES (cr=7 r=0 w=0 time=672 us)
Elapsed times include waiting on following events:
Event waited on
Times
Max. Wait Total Waited
---------------------------------------Waited ---------- -----------SQL*Net message to client
4
0.00
0.00
SQL*Net message from client
4
20.91
20.93
********************************************************************************
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 98 von 197
98
Response Time Analyse 10g
11/2005
Nachteile TKPROF
Response Time Analyse 10g
• Eingeschränkte Übersicht der Wait Events
• Keine Unterscheidung der Calls in User/recursive und
Internal/recursive
• Zeigt keine aktuellen Werte von Bindevariablen!
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 99 von 197
99
Response Time Analyse 10g
11/2005
Trace-Analyzer
Response Time Analyse 10g
• Skriptsammlung zur formatierten Ausgaben von
10046er Traces
– RDBMS > 8.1.6
• Über Metalink: TRCA.zip
• Erweiterte Funktionalität und Reports – auch für 8i
funktionabel
• Arbeitet über Hilfstabellen und PL/SQL-Prozeduren
– Zugriff auf Trace mittels DIRECTORY
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 100 von 197
100
Response Time Analyse 10g
11/2005
Trace-Analyzer
– Nötige Grants erteilen (über SYS)
– Hilfstabellen (22) und Package (1) anlegen (unter user)
– Analyse starten:
• START TRCANLZR.sql UDUMP prod_ora_9105.trc;
• Wenn keine rekrusiven Statements, dann vorher
TRCAISYS.sql NO;
Response Time Analyse 10g
• Fokus: analysierender Benutzer (Generator von 10046)!
• Arbeitsweise:
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 101 von 197
101
Response Time Analyse 10g
11/2005
Trace-Analyzer (Report)
Response Time Analyse 10g
Introduction...
TOP SQL (SUMMARY OF CPU, ELAPSED AND WAITS PER TOP EXPENSIVE CURSOR)
GAPS OF NO TRACE ACTIVITY
SUMMARY OF CALLS BY USER (INTERNAL LAST) AND NON-RECURSIVE/RECURSIVE
SUMMARY OF CALLS BY COMMAND TYPE, USER (INTERNAL LAST) AND NONRECURSIVE/RECURSIVE
SUMMARY OF WAITS BY USER (INTERNAL LAST) AND NON-RECURSIVE/RECURSIVE
DETAIL OF NON-IDLE WAITS BY USER (INTERNAL LAST) AND NON-RECURSIVE/RECURSIVE
HOTTEST 5 BLOCKS (MOST TIMES WAITED FOR)
SUMMARY BY SQL STATEMENT (CURSOR)
*** Vorstellung der einzelnen Cursor mit Bindevariablen etc.
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 102 von 197
102
Response Time Analyse 10g
11/2005
Trace-Analyzer
Response Time Analyse 10g
********************************************************************************************
TRCANLZR.sql 115.9 NOTE:224270.1 2003-02-06 15:42:01
********************************************************************************************
TRACE_DIRECTORY..........: /amer/oracle/visus86/visus86ora/8.1.7/admin/visus86/udump
(ALIAS:UDUMP)
TRACE_FILENAME...........: visus86_ora_17714.trc (TRACE_ID:31)
INSTANCE_AND_RELEASE.... : VISUS86 (ON TDASOL3) 8.1.7.3.0 (SUNOS - PRODUCTION)
TRACE_SIZE...............: 1332588 BYTES (IN 25314 LINES)
TRACED_INTERVAL..........: STARTED ON 2003-02-04 11:03:13.545, AND LASTED 11.99 SECS
USER_ELAPSED_TIME........: 11.99 SECS GAPS_WITH_NO_ACTIVITY....: 0.00
EFFECTIVE_TRACED_INTERVAL: 11.99
ACCOUNTED_CPU_TIME.......: 6.68 SECS (TOTAL SERVICE TIME)
ACCOUNTED_ELAPSED_TIME...: 20.17 (RECURSIVE AND NON-RECURSIVE)
WAITED_NON-IDLE_TIME.....: 7.72 SECS
WAITED_IDLE_TIME.........: 0.90
********************************************************************************************
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 103 von 197
103
Response Time Analyse 10g
11/2005
Trace Analyzer
Response Time Analyse 10g
NUMBER_OF_CURSORS........: 231 (USER), 172 (INTERNAL <SYS>), 403 (TOTAL)
UNIQUE_SQL...............: 136 (USER), 44 (INTERNAL <SYS>), 180 (TOTAL)
***************************************************************************************
TOP SQL (SUMMARY OF CPU, ELAPSED AND WAITS PER TOP EXPENSIVE CURSOR)
====================================================================
cursor user
non-idle idle
id
id
command type
count cpu top elapsed top waits top waits top
------ ---- ----------------------- ------ ----- --- ------- --- ----- --- ----- --98.... 65.. pl/sql execute.........
2 0.71 1
2.21 2
0.00
0.00
99.... 65.. insert.................
2 0.69 2
2.19 3
1.81 2
0.00
18.... 65.. pl/sql execute.........
4 0.61 3
1.93 4
0.00
0.00
137... 0... insert.................
375 0.53 4
0.71 5
0.02
0.00
113... 65.. select.................
3 0.40 5
3.00 1
2.11 1
0.01
115... 65.. select.................
125 0.05
0.36
0.31 3
0.00
5..... 0... select.................
15 0.01
0.22
0.22 4
0.00
29.... 0... select.................
266 0.05
0.27
0.21 5
0.10 2
34.... 65.. select.................
3 0.24
0.38
0.00
0.11 1
130... 65.. select.................
63 0.01
0.01
0.00
0.05 3
133... 65.. select.................
17 0.06
0.24
0.20
0.05 4
12.... 65.. pl/sql execute.........
74 0.21
0.23
0.00
0.04 5
***************************************************************************************
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 104 von 197
104
Response Time Analyse 10g
11/2005
Trace-Analyzer
Response Time Analyse 10g
Details for wait event
Times Count
Max. Total
Blocks
'db file scattered read (multiblock full scan)'
Waited Zero Time Wait Waited Accessed
--------------------------------------------------- ------ --------- ---- ------ -------bom.bom_calendar_dates.............................
26
8 0.02
0.19
178
mrp.mrp_schedule_dates_n1..........................
2
0 0.04
0.06
21
mrp.mrp_load_parameters............................
2
0 0.02
0.03
6
--------------------------------------------------- ------ --------- ---- ------ -------total..............................................
30
8 0.04
0.28
205
• Sehr nützlich: Wait Events werden nach User und Segment
individuell gruppiert!
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 105 von 197
105
Response Time Analyse 10g
11/2005
Servicezeit - Parsing
– Syntaktische und semantische Überprüfung eines SQL-Befehls
– Ermittlung "identischer" Statements
– Ableitung eines "optimalen" Zugriffsplans
Response Time Analyse 10g
• Definition:
• Begriffe
– Hard parse – voller Umfang (aufwendig)
– Soft parse – authentifiziert bereits geladenes Statement
– Session Cursor Cache übernimmt bei parse call > 3
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 106 von 197
106
Response Time Analyse 10g
11/2005
Servicezeit - Parsing
Response Time Analyse 10g
• parse time cpu
– Zeit zum Parsen der SQL-Befehle
– Zwischen 10 und 40% der gesamten Servicezeit
• sonst:
• parse count und execute count
– Parse count: soft und hard
– Nicht über 20 – 30% von execute count
• recursive cpu usage
– Row cache und PL/SQL
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 107 von 197
107
Response Time Analyse 10g
11/2005
Parse-Zeiten 10g
Response Time Analyse 10g
parse time elapsed
hard parse elapsed time
failed parse elapsed time
failed parse (out of shared memory) elapsed time
hard parse (sharing criteria) elapsed time
hard parse (bind mismatch) elapsed time
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 108 von 197
108
Response Time Analyse 10g
11/2005
Servicezeit - Parsing
Response Time Analyse 10g
select * from v$sysstat
where name in
('parse time cpu','parse count (total)‚
,'parse count (hard)'
,'parse count (failures)'
,'execute count'
,'session cursor cache count'
, 'session cursor cache hits')
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 109 von 197
109
Response Time Analyse 10g
11/2005
Servicezeit - Parsing
Response Time Analyse 10g
select a.value "Total CPU",
b.value "Parse CPU",
c.value "Recursive CPU",
a.value - b.value - c.value "Other"
from v$sysstat a, v$sysstat b, v$sysstat c
where a.name = 'CPU used by this session'
and b.name = 'parse time cpu'
and c.name = 'recursive cpu usage';
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 110 von 197
110
Response Time Analyse 10g
11/2005
Untergliederung der Servicezeit
Response Time Analyse 10g
• Restliche Zeit verwendet für
– Lesen von Daten- und Indexblöchen
– Fetch-Operationen
– In der Regel der höchste Anteil
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 111 von 197
111
Response Time Analyse 10g
11/2005
Optimierung der Servicezeit
Response Time Analyse 10g
• Zu hohe Parse-Anteile
–
–
–
–
Open/close-Calls untersuchen
Bindevariablen verwenden
Ggf. cursor_sharing
Ggf. session_cursor_cache setzen
• Zu hohe recursive Anteile
– SQL in PL/SQL optimieren
– shared_pool erhöhen
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 112 von 197
112
Response Time Analyse 10g
11/2005
Optimierung der Servicezeit
Response Time Analyse 10g
• Hoher Restanteil
– SQL ausserhalb PL/SQL optimieren
– LIO und PIOs reduzieren
– Weitere Analysen über V$sql, v$sqlarea etc.
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 113 von 197
113
Response Time Analyse 10g
11/2005
cursor_sharing
Response Time Analyse 10g
• Dynamischer Init.ora Parameter
– Session- und System-Kontext
– Automatisiertes Ersetzen von Literalen durch
Bindevariablen bei sonst gleicher Syntax
• exact = nicht aktiviert, hard parse pro stmt.
• force = Literale werden immer ersetzt, wenn
Semantik nicht verändert wird
– Ggf. problematisch bei stored outlines
• similar – Literale werden nur dort ersetzt, wo
eine Änderung des Plans nicht zu erwarten ist,
ggf. wie exact
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 114 von 197
114
Response Time Analyse 10g
11/2005
bind variable peeking
optimizer_features_enable >= 9.0.1
Betrachtet Bind-Werte beim ersten Aufruf des Cursors!
Keine Evaluierung bei Folgeaufrufen
Sharing des Cursors ansonsten wie cursor_sharing
Response Time Analyse 10g
•
•
•
•
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 115 von 197
115
Response Time Analyse 10g
11/2005
Response Time Analyse 10g
Die Praxis: Kontext IO
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 116 von 197
116
Response Time Analyse 10g
11/2005
Basiswissen
– ORA-Daten in SGA und FS Cache
• Von Raw Device – Direct IO
• Reads
– physical reads oder logical reads – Statistik session logical
reads
– als p. direct reads in PGA – Statistik physical reads direct
– als p. cache reads in SGA – Statistik physical reads cache
– Gesamtstatistik physical reads
Response Time Analyse 10g
• Über File System Cache – Buffered IO
• Writes
– analog reads als cache oder direct write
– Statistiken physical writes, physical writes direct und
physical writes from cache
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 117 von 197
117
Response Time Analyse 10g
11/2005
Wait Events
Response Time Analyse 10g
•
•
•
•
•
•
•
db file sequential read – single block reads
db file scattered read – mulitblock reads
direct path read
direct path write
db file parallel write
log file parallel write
control file parallel write
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 118 von 197
118
Response Time Analyse 10g
11/2005
db file sequential read
– read()-Call – kontinuierliche Speicherung im Memory-Bereich
– entspricht Single-Block Read aus Sicht von Oracle
– Ausnahme: MB reds auf temporären Segmenten
• Verwendet für
–
–
–
–
Response Time Analyse 10g
• Wartezustände bei read()-Operationen (Unix)
Index Scans
Table Access by Rowid
Undo Zugriffe
Control File und Datafile Header
• Parameter
– p1 – file#
– p2 – block#
– p3 - blocks
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 119 von 197
119
Response Time Analyse 10g
11/2005
db file sequential read
– dadurch Reduzierung des LIO und dadurch Reduzierung
des PIO
– Implementierung, Indexstrukturen, Parameter
Response Time Analyse 10g
• Optimierung der zugehörigen SQL-Statements
• wenn nicht möglich dann IO-Durchsatz erhöhen
– Durchschnittliche Single Block Reads ca. 10ms oder ca. 68 ms (SAN) – siehe Tabelle aux_stats$
– IO-Verteilung: Platten und Controller – v$filestat
– Filesystem und Blockgrösse versus Rawdevice
– Raid Level
– Multiple Buffer Pools oder Cache-Klausel
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 120 von 197
120
Response Time Analyse 10g
11/2005
db file scattered read
– readv()-Call – verteilte Speicherung im Memory-Bereich
– entspricht Multi-Block Read aus Sicht von Oracle – maximal
db_file_mulitblock_read_count
• Verwendet für
Response Time Analyse 10g
• Wartezustände bei read()-Operationen (Unix)
– Full Table Scans
– Fast Full Scans auf Indizes (FFS)
• Parameter
– p1 – file#
– p2 – block#
– p3 – block count
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 121 von 197
121
Response Time Analyse 10g
11/2005
db file scattered read
–
–
–
–
„gecachte“ Blöcke
extent boundaries
Migrierte oder „gechainte“ Rows
Index-Pflege bei INSERTS über Subqueries mit Full Scans
Response Time Analyse 10g
• Gemischte db file waits bei full table Scans möglich:
• Optimierung ähnlich sequential reads:
– SQL-Optimierung
– wenn nicht möglich dann IO-Durchsatz erhöhen
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 122 von 197
122
Response Time Analyse 10g
11/2005
direct path read (temp)
Response Time Analyse 10g
• single oder multiblock rad in PGA
– entspricht Anzahl der read-requests für Synch-IO
– ungenau wegen Überlappungen bei Asynch-IO
• Ursachen
– Sorts auf Platte
– Hash-Joins > hash_area_size
– Parallelisierung von SQL – für Query Slaves (!!)
• für Parent der Event „PX Deq: Execute Reply“
• Parameter
– p1 – file#
– p2 – block#
– p3 – block count
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 123 von 197
123
Response Time Analyse 10g
11/2005
direct path read (temp)
– SQL Optimierung – sort_area_size, hash_area_size,
pga_aggregate_target
• Direct IO Buffer Size
Response Time Analyse 10g
• Tuning Massnahmen
– Grösse in Byte über _db_file_direct_io_count
– Trace über Event 10357 zeigt slots und slot size
– Einstellung von Sltos size über Event 10351
– Anzahl slots über Event 10353
• aktuelle Nutzung siehe über v$tempseg_usage
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 124 von 197
124
Response Time Analyse 10g
11/2005
direct path write (temp)
– direct load
– sorts und has joins
Response Time Analyse 10g
• Analog direct path read – Schreiben aus PGA-Puffer
• Ausgelöst durch
• Massnahmen wie bei direct path reads
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 125 von 197
125
Response Time Analyse 10g
11/2005
db file parallel write
Response Time Analyse 10g
• Wartezustand im Kontext des DBWR
• DBWR schreibt modifizierte Blöcke
–
–
–
–
alle 3 Sekunden
initialisiert durch Server-Prozess
bei Checkpoints
wenn Grenzwerte erreicht sind ...
• Begleitende Events bei den Serverprozessen
– free buffer waits
– write complete waits
• Massnahmen: DBWR Durchsatz erhöhen
– asynch IO
– db_writer_processes > 1 oder dbwr_io_slaves
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 126 von 197
126
Response Time Analyse 10g
11/2005
log file parallel write
Response Time Analyse 10g
• Wartezustand im Kontext des LGWR
• LGWR schreibt
– nach Zeitraster
– nach Füllraster
– zum Commit ...
• Begleitende Events für Serverprozesse
– log file synch
• Massnahmen
– bessere IO-Verteilung – Log-Dateien separieren
– Reduzierung des Redo-Volumens
• NOLOGGING
• Commit-Frequenz
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 127 von 197
127
Response Time Analyse 10g
11/2005
File IO
Response Time Analyse 10g
select file#, readtim, phyrds
, readtim/phyrds from v$filestat
order by 4;
select disk_reads, executions
, disk_reads/executions, sql_text
from v$sql
where executions != 0
order by 3;
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 128 von 197
128
Response Time Analyse 10g
11/2005
File IO
Response Time Analyse 10g
SELECT fs.file#, NAME, avgiotim
, PHYRDS, PHYWRTS, miniotim,lstiotim
, PHYBLKRD/phyrds Read_ratio
, PHYBLKWRT/phywrts Write_ratio
FROM V$DATAFILE df, V$FILESTAT fs
WHERE df.FILE# = fs.FILE#
order by PHYRDS + PHYWRTS desc
/
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 129 von 197
129
Response Time Analyse 10g
11/2005
Response Time Analyse 10g
Die Praxis: Kontext Latches
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 130 von 197
130
Response Time Analyse 10g
11/2005
Aufgabe von Latches
Response Time Analyse 10g
– Serialisierung der Zugriffe
• Schutz von Datenstrukturen in der SGA
• schüten shared memory allocations
– Serialisierung von Ausführungen (executions)
• Schutz von Korruption
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 131 von 197
131
Response Time Analyse 10g
11/2005
Latch Characteristics
Enqueues
Latches
Access
Several modes
Mostly exclusive
Acquisition
FIFO queue
Non-deterministic
Atomicity
No
Yes
Response Time Analyse 10g
– "Low level" Lock – atomare Operationen
– Latches unterscheiden sich darin von Locks (enqueues erfordern
multiple Operationen
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 132 von 197
132
Response Time Analyse 10g
11/2005
Latch Implementierung
Response Time Analyse 10g
• "schnelle" und billige Locks
• Exclusive latches = schreiben von einem Process
• Shared latches = concurrent reads auf einen MemoryBereich
• Regelwerk (Reihenfolge der Aquirierung) um Deadlocks
zu vermeiden.
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 133 von 197
133
Response Time Analyse 10g
11/2005
Latch Attribute
– latch set: parent und child latches
• Child latches werden dynamisch alloziert
• Parent und child latches tragen den gleichen Namen
• Latchlevel verhindern interne Deadlocks
Response Time Analyse 10g
• Latches: einzeln oder in Sets/Gruppen (latch set)
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 134 von 197
134
Response Time Analyse 10g
11/2005
Mechanismen
Prozeß B wartet
(spins + retries +
sleeps) * N
_SPIN_COUNT
Response Time Analyse 10g
SGA
Latch
Process
B
Process
A
CPU
1
CPU
2
Proceß A hält
den Latch
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 135 von 197
135
Response Time Analyse 10g
11/2005
No-Wait Modus
Response Time Analyse 10g
• Ein Versuch; kein spin oder sleep
• Für den Fall, dass mehrere latches verfügbar sind
– Wenn frei, wird Latch reserviert
– Wenn belegt, wird nächster Kandidat aquiriert
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 136 von 197
136
Response Time Analyse 10g
11/2005
Wait Modus
Response Time Analyse 10g
• Latch gets mit Warteschleifen
– Ein schneller get; kein spin
– wiederholte gets mit wachsenden Warteintervallen,
mit spin bei mehreren CPUs
• Wartet auf latch free wait event zwischen den
gets
• Schlafzeitzeit verdoppelt sich bei jedem zweiten
Versuch bis zu einer Maximalzeit
Fast get – spin_retr - sleep – spin_retr - sleep - spinretr - sleep …
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 137 von 197
137
Response Time Analyse 10g
11/2005
Latch Klassen
Response Time Analyse 10g
• Verfügbar ab 9iR2
• Jede Klasse kann eigenen _spin_count erhalten
-- Spin Count für Klassen ermitteln
SELECT indx, spin FROM x$ksllclass
/
-- Count für Klasse 2 anpassen
_latch_class_2 = 6000
-- Latch# ermitteln über v$latchname
-- Latch 97 Klasse 2 zuordnen
_latch_classes = ’97:2’
-- Kontrollieren
SELECT a.kslldnam, b.kslltnum, b.class_ksllt
FROM x$kslld a, x$ksllt b
WHERE a.kslldadr = b.addr AND b.class_ksllt > 0
/
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 138 von 197
138
Response Time Analyse 10g
11/2005
Relative Wartezeit
EVENT
------------latch free
CPU used when call started
.....
Response Time Analyse 10g
SELECT event, time_waited,
round(time_waited*100/ SUM (time_waited) OVER(),2) wait_pct
FROM (SELECT event, time_waited FROM v$system_event WHERE event NOT IN
('Null event','client message','rdbms ipc reply','smon timer',
'rdbms ipc message','PX Idle Wait','PL/SQL lock timer','file open',
'pmon timer','WMON goes to sleep','virtual circuit status',
'dispatcher timer','SQL*Net message from client',
'parallel query dequeue wait','pipe get')
UNION
(SELECT NAME, VALUE
FROM v$sysstat
WHERE NAME LIKE 'CPU used when call started'))
ORDER BY 2 DESC;
TIME_WAITED
WAIT_PCT
---------------- ----------40144
31.67
30341
23.94
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 139 von 197
139
Response Time Analyse 10g
11/2005
Deatillierung...
Response Time Analyse 10g
SELECT name, gets, sleeps
, sleeps*100/sum(sleeps) over() sleep_pct
, sleeps*100/gets sleep_rate
FROM v$latch where gets>0
ORDER BY sleeps desc;
NAME
GETS
SLEEPS SLEEP_PCT SLEEP_RATE
---------------------- ----------- ------------ --------- ---------cache buffers chains
13,863,552
38,071
99.48
.2746
session allocation
1,223,982
110
.29
.0090
checkpoint queue latch
1,461,039
39
.10
.0027
....
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 140 von 197
140
Response Time Analyse 10g
11/2005
Latch Waits unter 10g
Response Time Analyse 10g
• Neben latch free 28 weitere Latch Events
• Vereinfachte Analyse
latch: cache buffer handles
latch: cache buffers chains
latch: cache buffers lru chain
latch: checkpoint queue latch
latch: enqueue hash chains
latch free
latch: library cache
latch: library cache lock
latch: library cache pin
latch: parallel query alloc buffer
latch: redo allocation
latch: redo copy
latch: redo writing
latch: session allocation
latch: shared pool
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 141 von 197
141
Response Time Analyse 10g
11/2005
latch free
– Warten auf Latch – adress, latch number, tries als Parameter
– Feststellen welches Latch (v$latchname, v$latch,
v$latch_children)
Response Time Analyse 10g
• Latch free
– Aktion nach Art des Latch
• Shared pool latch & Library cache latch – bei space
allocation = Reduzieren von Parsing
• cache buffer hash chain latch – bei Anfrage und Änderung
eines Buffers
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 142 von 197
142
Response Time Analyse 10g
11/2005
Shared Pool Latches
Response Time Analyse 10g
• Komponente über v$sgastat
• Shared pool latch schützt Memory Operationen
– z. B. bei hard parse von SQL
– Version < 9i – 1 sahred pool latch
– danach bis zu 7 child latches möglich
• mindestens 4 CPUs und shared_pool_size > 250 MB
• Subpools einstellbar über _kghdsidx_count
• Library cache latch für Arbeit mit LC-Objekten
– Anzahl: kleinste Primzahl >= CPU_COUNT
– Einstellung über _kgl_latch_count
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 143 von 197
143
Response Time Analyse 10g
11/2005
Shared Pool Latches
Response Time Analyse 10g
• Massnahmen:
• Reduzierung von Hard Parse
– Bindevariablen oder cursor_sharing
– SQL-Aufbau
• Zu grosser Shared Pool
– lange Freilisten pro chunk size – siehe heapdump level 2
– Freiplatz über v$sgastat
• Hohe Anzahl von version_count (Variante von Hard
Parse)
– View v$sql_shared_cursor mit reason code
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 144 von 197
144
Response Time Analyse 10g
11/2005
LIO: Ablauf und Aufwand
Response Time Analyse 10g
• (Logisches) Lesen eines Buffers/Blocks im Buffer Cache
der SGA
• Hash-Table enthält buffer header in cache buffer chains
(verkettete Listen)
• Hashing eines Blocks nach
– DBA
– Tablespace Number
– Block Typ
• Geschützt durch Latches
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 145 von 197
145
Response Time Analyse 10g
11/2005
LIO: Ablauf und Aufwand
Response Time Analyse 10g
_db_block_hash_buckets
_db_block_hash_latches
• Z.B. Buffer = 3000 (v$buffer_pool)
• Hash Buckets = 6007 (Primzahl >= 2*buffer)
• Cache Buffers Chains Latches = 1024 (x$ksppstvl, x$ksppi)
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 146 von 197
146
Response Time Analyse 10g
11/2005
LIO: Ablauf und Aufwand
-
Response Time Analyse 10g
1. Hash-Funktion mit DBA etc. ergibt chain
2. Prüfung/"Lesen" der betreffenden chain – geschützt
durch buffer chain Latch
3. Falls Block vorhanden: lesen
4. CR-Modus: Rekonstruktion von Clone- Blöcken in
gleicher chain!
Zugriff auf Rollback-Segmente
5. Lesen der Rows des Blockes
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 147 von 197
147
Response Time Analyse 10g
11/2005
LIO: Ablauf und Aufwand
Response Time Analyse 10g
• 8i: pro latch 1 Benutzer – blockt auch als Leser
• Oracle 9i:
–
–
–
–
mehr buckets
1 Latch für mehrere buckets
mehere „Leser“ pro cache buffers chains latch
„Schreiber“ blockieren „Leser“ und umgekehrt
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 148 von 197
148
Response Time Analyse 10g
11/2005
LIO: Ablauf und Aufwand
– Einstellungen über x$ksppi und x$ksppcv
– Zugehörige Latches: v$latch und v$latch_children
– Bufferzuordnung: x$bh – über Spalte HLADDR Verknüpfung mit
v$latch_children
Response Time Analyse 10g
• Recherchemöglichkeiten:
SELECT n.ksppinm, v.ksppstvl
FROM x$ksppi n, x$ksppcv v
WHERE n.ksppinm
IN ('_db_block_hash_buckets',
'_db_block_hash_latches')
AND n.indx = v.indx
AND n.inst_id = v.Inst_id;
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 149 von 197
149
Response Time Analyse 10g
11/2005
LIO Aufwand
Response Time Analyse 10g
• Höher als angenommen wegen
– Latch-Synchronisierung
– Clone-Aufwand (Lesekonsistenz)
– Ggf. Grosse Anzahl aus Sorglosigkeit
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 150 von 197
150
Response Time Analyse 10g
11/2005
PIO: Ablauf
Response Time Analyse 10g
1. Prüfen der cache buffers chains
2. Physisches Lesen des/der Blöcke – ggf. von OS
gepuffert
3. Modifikation von buffer chains – ggf. löschen und
eintragen
4. Lesen des Inhalts wie bei LIO
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 151 von 197
151
Response Time Analyse 10g
11/2005
Cache buffers Chains Latch
–
–
–
–
Latches : Bucket = 1 : n
Parameter _db_blocks_hash_latches
default abhängig von Cache Size, < 1 GB = 1024
Default Hash Buckets abhängig von db_cache_size; Parameter
_db_block_hash_buckets
Response Time Analyse 10g
• auch unter dem Namen hash latches oder CBC latches
• schützen Operationen im Kontext der hash chains
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 152 von 197
152
Response Time Analyse 10g
11/2005
Cache buffers Chains Latch
Response Time Analyse 10g
• Ineffizientes SQL – unnötig viele Blöcke
• „heisse“ Blöcke
– Reduzierung der Datenfülle
• PCTFREE
• Blockgrösse
– Lange Hash Chains
• Anzahl der Blöcke pro Latch ermitteln:
SELECT hladdr, count(*) FROM x$bh GROUP by hladdr
/
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 153 von 197
153
Response Time Analyse 10g
11/2005
Buffer Pool Interna
Response Time Analyse 10g
• Puffer enthalten Datenblöcke
• Puffer werden über buffer header identifiziert
• Datenblöcke werden über Blockadressen identifiziert
(DBA/RDBA)
• Hash Buckets verweisen jeweils auf eine Kette von
buffer headern (hassh chain)
• Puffer werden über ihren Hash-Wert in der hash chain
und damit im Buffer Cache lokalisiert
• Working sets sind verkettete Listen von Puffern
• Working Sets gruppieren Puffer nach
Verwendungszwecken.
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 154 von 197
154
Response Time Analyse 10g
11/2005
Working Sets
Response Time Analyse 10g
List Name
Type of buffers on list
LRU
Replacement list
LRU-W
Write list; old dirty buffers
LRU-P
Ping list; RAC only
LRU-XO
Reuse object list; buffers to be written
for drop/truncate
LRU-XR
Reuse range list; buffers to be written
for reuse block range
Thread CKPT queue
Thread checkpoint buffers
File CKPT queue
Checkpoint buffers queued by file#
Recovery CKPT queue
Buffers for performing recovery
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 155 von 197
155
Response Time Analyse 10g
11/2005
Cache Buffers LRU Chain Latch
Response Time Analyse 10g
• CBLCL schützen Working Sets im Buffer Pool
– Anzahl der WS ermitteln über x$kcbwds
– Anzahl der Latches über v$latch_children
– Einstellbar über _db_block_lru_latches
• Ursachen
– intensive Block-Operationen, ggf. durch schlechtes SQL
– SQL entsprechend optimieren
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 156 von 197
156
Response Time Analyse 10g
11/2005
Blockgrösse in Oracle8i
Response Time Analyse 10g
Höhe
Höhe von
von
IndexIndexbäumen
bäumen
Zeilen
Zeilenpro
pro
Tablescan
Tablescan
Zeilen
Zeilenpro
pro
Block
Block
RowRowsplitting
splitting
db_block_size
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 157 von 197
157
Response Time Analyse 10g
11/2005
Blockgrössen in Oracle9i
Response Time Analyse 10g
• db_block_size = 4096
– Setzt primäre Blockgröße
– Standard- und SYSTEM-Größe
• db_cache_size = 50m
– Bestimmt Default-Bufferpool
• db_8k_cache_size = 80m
– Auch 2k/8K/16k/32K
– Bestimmt bis zu 4 weitere Buffer-Caches
• SGA insgesamt <= sga_max_size
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 158 von 197
158
Response Time Analyse 10g
11/2005
Blockgrössen
Response Time Analyse 10g
ALTER SYSTEM
SET db_4k_cache_size = 50m;
CREATE TABLESPACE b4k
DATAFILE
'/opt/oracle/oradata/o901/b4k.dbf'
SIZE 10M BLOCKSIZE 4096;
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 159 von 197
159
Response Time Analyse 10g
11/2005
Weitere Parameter
– Optimierung von Flüchtigen oder "permanenten" Objekten
– Keep-Klausel ersetzt CACHE-Klausel
– Für CREATE und ALTER
Response Time Analyse 10g
• Multipe Buffer Pools
• Angaben in Grössen
• db_keep_cache_size
• db_recycle_cache_size
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 160 von 197
160
Response Time Analyse 10g
11/2005
Multiple Buffer Pools
Response Time Analyse 10g
-- Nur für Standard-Blockgrössen
CREATE TABLE test
(c1 NUMBER,
c2 VARCHAR2(100))
STORAGE(INITIAL 100K NEXT 100K
BUFFER_POOL KEEP);
ALTER TABLE test2 STORAGE(BUFFER_POOL RECYCLE);
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 161 von 197
161
Response Time Analyse 10g
11/2005
Views
Response Time Analyse 10g
SELECT id,name, block_size,
current_size,buffers
FROM v$buffer_pool;
ID
-1
2
3
4
5
6
7
NAME
--------KEEP
RECYCLE
DEFAULT
DEFAULT
DEFAULT
DEFAULT
DEFAULT
BLOCK_SIZE
---------4096
4096
4096
2048
8192
16384
32768
CURRENT_SIZE
-----------16
8
28
8
4
16
4
BUFFERS
---------3932
1966
6881
3784
501
1012
127
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 162 von 197
162
Response Time Analyse 10g
11/2005
v$buffer_pool_statistics
Response Time Analyse 10g
ID
NAME
BLOCK_SIZE
SET_MSIZE
CNUM_REPL
CNUM_WRITE
CNUM_SET
BUF_GOT
SUM_WRITE
SUM_SCAN
FREE_BUFFER_WAIT
WRITE_COMPLETE_WAIT
BUFFER_BUSY_WAIT
FREE_BUFFER_INSPECTED
DIRTY_BUFFERS_INSPECTED
DB_BLOCK_CHANGE
DB_BLOCK_GETS
CONSISTENT_GETS
PHYSICAL_READS
PHYSICAL_WRITES
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 163 von 197
163
Response Time Analyse 10g
11/2005
V$buffer_pool_statistics
NAME
CONSISTENT_GETS
BLOCK_SIZE CONSISTENT_GETS DB_BLOCK_GETS
Response Time Analyse 10g
select name, block_size
,consistent_gets, db_block_gets,consistent_gets
from v$buffer_pool_statistics
------------------- ---------- --------------- ------------- -------------DEFAULT
379081
8192
379081
79133
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 164 von 197
164
Response Time Analyse 10g
11/2005
dynamische SGA
Response Time Analyse 10g
• Vorgeben der Maximalgrösse (statisch)
• Dynamik bei Buffer-Pool und Shared Pool
• Gerundet auf Granule
– Kleinste Einheit, abhängig von SGA-Größe
– 4MB (< 128MB) oder 16 MB >= 128MB
– Spalte resize_state in v$buffer_pool
SGA_MAX_SIZE = 800M
ALTER SYSTEM SET shared_pool_size =
100M;
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 165 von 197
165
Response Time Analyse 10g
11/2005
db_cache_advice
Response Time Analyse 10g
• Aktiviert Statistiken für Bufferpool
– Off: deaktiviert Statistikgenerierung
– On: reaktiviert v$db_cache_advice
– Ready: alloziert Speicher, erhält „alte“ Statistiken
• Overhead
– CPU
– Memory: 100 bytes pro Puffer alloziert vom Shared Pool
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 166 von 197
166
Response Time Analyse 10g
11/2005
v$db_cache_advice
Response Time Analyse 10g
• db_cache_advice = on
• Zeigt Statistiken von 10% - 200% der aktuellen Puffergröße
Estd Phys
Estd Phys
Cache Size (MB) Buffers
Read Factor Reads
---------------- ---------- ----------- -----------91
11,406
7.38
75,865,861
121
15,208
4.97
51,111,658
...
304
38,020
1.00
10,282,475
334
41,822
.93
9,515,878
364
45,624
.87
8,909,026
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 167 von 197
167
Response Time Analyse 10g
11/2005
v$db_cache_advice
NUMBER
VARCHAR2(20)
NUMBER
VARCHAR2(3)
NUMBER
NUMBER
NUMBER
NUMBER
Response Time Analyse 10g
ID
NAME
BLOCK_SIZE
ADVICE_STATUS
SIZE_FOR_ESTIMATE
BUFFERS_FOR_ESTIMATE
ESTD_PHYSICAL_READ_FACTOR
ESTD_PHYSICAL_READS
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 168 von 197
168
Response Time Analyse 10g
11/2005
Database Writer
Response Time Analyse 10g
• Schreibt modifizierte Blöcke
– Make free requests
– Checkpoints
• Checkpoint SCN
• Checkpoint RBA
• Thread that allocated the checkpoint
• Enabled thread bitmap
• Timestamp
– Ping writes
– Cleanout von "cold dirty buffers"
• Wait Events
– Free buffer waits, Buffer busy waits, Write complete waits
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 169 von 197
169
Response Time Analyse 10g
11/2005
Buffer Busy Waits
Response Time Analyse 10g
• Buffer busy waits verursacht durch:
– mehrere sessions lesen den selben Block
– mehrere sessions warten auf die Fertigstellung einer
Blockmodifikation
•
•
•
•
Analyse: Grund (reason Code) und Block-Klasse
P3 in V$SESSION_WAIT hat "reason code"
V$WAITSTAT zeigt waits gruppiert nach Blockklassen
X$KCBFWAIT zeigt waits gruppiert nach Dateien
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 170 von 197
170
Response Time Analyse 10g
11/2005
Buffer Busy Waits
Response Time Analyse 10g
• Reason Code gibt
– Ursache für das Warten (erste Ziffer)
– Anlass der Anforderung (zweite und dritte Ziffer)
• Erste Ziffer
– 1 – Buffer wurde gelesen
– 2 – Buffer genutzt in inkompatiblem Modus
• zweite Ziffer
–
–
–
–
–
00 – newing/reuse
10 – CU for inspection
20 – CU for modification
30 – CU oder CR zum consisten read
31 – CU oder CR zum CR prüfen
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 171 von 197
171
Response Time Analyse 10g
11/2005
Buffer Busy Waits - 220
Response Time Analyse 10g
• Zugriff auf Buffer mit dem Wunsch zu modifizieren –
Block war hierfür nicht verfügbar
• Ursachen und Maqssnahmen
– gleichzeitige Inserts auf identischen Blöcken
• Feilisten-Verwaltung, Reverse KEy
– Modifikationen auf Rows in identischen Blöcken
• Row-dichte reduzieren, PCTFREE etc.
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 172 von 197
172
Response Time Analyse 10g
11/2005
Biffer Busy Waits – 130, 230
Response Time Analyse 10g
• 130 – CR Anfrage für einen Buffer, der gerade
eingelesen wird
– ggf. KEEP Pool
• 230 – CR Anfrage eines Buffers der gerade modifiziert
wird
– ggf. geringere Row-Dichte/bessere Datenverteilung
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 173 von 197
173
Response Time Analyse 10g
11/2005
Buffer Cache Statistics
Response Time Analyse 10g
• Drei buffer cache Statistikgruppen:
– User statistics
– Background (DBWR) statistics
– RAC related statistics
• Details in Oracle9i Database Reference: Appendix C
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 174 von 197
174
Response Time Analyse 10g
11/2005
DBWR Statistics
Response Time Analyse 10g
• DBWR Statistiken werden kalkuliert, wenn DBWR die
buffers schreibt und die LRU-Listen scannt
• Die wichtigsten:
– DBWR timeouts
– “Make free” requests
– Checkpoints
• DBWR in der Regel selbsttunend!
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 175 von 197
175
Response Time Analyse 10g
11/2005
Buffer busy waits
Response Time Analyse 10g
• Buffer busy waits – Reaktion pro Klasse
– Segment Header:
• Freilisten/-gruppen erhöhen
• HWM-Bump (_BUMP_HIGHWATER_MARK_COUNT)
• Contention auf der Extent-Map des Headers
– Data Block
• Warten auf Leseoperation = mehr buffer
• Zu viele Rows pro Block = pctfree/pctused
• Zu viele Inserts/Block = mehr Freilisten
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 178 von 197
178
Response Time Analyse 10g
11/2005
Buffer busy waits
Response Time Analyse 10g
• Buffer busy waits – Reaktion pro Klasse
– Free List Block Waits:
• Freilisten/-gruppen erhöhen
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 179 von 197
179
Response Time Analyse 10g
11/2005
free buffer waits
– Warten beim Scan nach freien Puffern
– Verfeinert durch (v$sysstat, v$sessstat)
• Free buffers inspected („angefasste“ Buffer)
• Dirty buffers inspected („angefasste“ schmutzige
B.)
• Free buffers requested (angefordete B.)
Response Time Analyse 10g
• Free buffer waits
– Mgl. Geringe Zahl pro Scan
– Ggf. _db_block_write_batch erhöhen
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 180 von 197
180
Response Time Analyse 10g
11/2005
Diverses
Response Time Analyse 10g
• Log file sync
– Session wartet auf LGWR
– Ggf. log_buffer vergrößern
– Ggf. IO-Problem bei Online Redo
• Enqueue
– Session wartet auf Lock
– Verfeinert durch enqueue-Statistiken
– Abhängig von Lock-Type (v$lock)
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 181 von 197
181
Response Time Analyse 10g
11/2005
Diverses
Response Time Analyse 10g
• Write complete waits
– Warten auf Beenden des Schreibvorgangs
– Ggf. zu häufige Checkpoints
• SQL* Net more data from/to client
– Warten auf Netzwerk-Opertionen (latency)
– Reduzierung der Calls
– Reduzierung der Latenzzeit
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 182 von 197
182
Response Time Analyse 10g
11/2005
Buffer Cache Tabellen
Response Time Analyse 10g
•
•
•
•
V$WAITSTAT : Wait statistics pro Blockklasse
X$KCBFWAIT : Wait statistics proFileID
V$BUFFER_POOL : Buffer pool descriptors
X$KCBBHS
: DBWR Histogramme
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 183 von 197
183
Response Time Analyse 10g
11/2005
Response Time Analyse 10g
SQL Workareas
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 185 von 197
185
Response Time Analyse 10g
11/2005
PGA (dedicated)
Response Time Analyse 10g
PGA
session memory
private SQL area
persistent
run-time
Run-time area enthält SQL workareas
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 186 von 197
186
Response Time Analyse 10g
11/2005
SQL workarea
Response Time Analyse 10g
• Sortierbereiche
– sort_area_size
• Hash-Bereiche
– hash_area_size (für Hash-Joins)
• Bitmap-Bereiche
– bitmap_merge_area_size (bitmap-merge bei Index-RangeScans)
– create_bitmap_area_size (Bitmap Aufbau)
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 187 von 197
187
Response Time Analyse 10g
11/2005
SQL workarea
Response Time Analyse 10g
• Schwer zu optimieren wegen schwankender
Anforderungen
• Mögliche Operationen
– optimal
– one-pass
– multi-pass
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 188 von 197
188
Response Time Analyse 10g
11/2005
dynamische SQL Workareas
Response Time Analyse 10g
• Nur für dedizierte Serverprozesse
• Gesamtgröße aller PGAs der Instanz über dynamischen
Parameter
– pga_aggregate_target
– Zwischen 10MB und 4000GM
– Einfache Größenbestimmung
• workarea_size_policy
– auto – automatisiert Speicherallokation
– manual
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 189 von 197
189
Response Time Analyse 10g
11/2005
v$sysstat /v$sesstat
Response Time Analyse 10g
•
•
•
•
Zusätzliche Statistiken:
workarea memory allocated
workarea executions – optimal
workarea executions – onepass
– Anzahl der Speicherbereiche, die einen zusätzlichen Ladelauf
hatten
• workarea executions – multipass
– Anzahl der Speicherbereiche, die mehrere zusätzliche
Ladeläufe hatten.
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 190 von 197
190
Response Time Analyse 10g
11/2005
v$pgastat
– Für workareas aktuell verfügbarer Bereich
– pga_aggregate_target minus bereits verbrauchter
Bereich
Response Time Analyse 10g
• Statistiken der PGA-Nutzung u.a.:
• aggregate PGA auto target
• global memory bound
– Maximalgröße einer Workarea (>= 1MB)
• total PGA allocated
• total PGA used for auto workareas
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 191 von 197
191
Response Time Analyse 10g
11/2005
pga_used_mem, pga_alloc_mem, pga_max_mem
Response Time Analyse 10g
• v$sql_workarea
– Kumulative Statikstiken von deallozierten Workareas
– Join mit v$sql und v$sqlarea
• v$sql_workarea_active
– Statistiken augenblicklich aktiver Workareas
– Pro Session und Operation
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 192 von 197
192
Response Time Analyse 10g
11/2005
v$sql_workarea_active
Response Time Analyse 10g
SELECT operation, options, object_name name,
trunc(bytes/1024/1024) "input(MB)",
trunc(last_memory_used/1024) last_mem,
trunc(estimated_optimal_size/1024)optimal_mem,
trunc(estimated_onepass_size/1024)onepass_mem,
decode(optimal_executions, null, null,
optimal_executions||’/’||onepass_executions
||’/’|| multipasses_exections) "O/1/M„
FROM V$SQL_PLAN p, V$SQL_WORKAREA w
WHERE p.address=w.address(+)
AND p.hash_value=w.hash_value(+)
AND p.id=w.operation_id(+)
AND p.address=’88BB460C’;
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 193 von 197
193
Response Time Analyse 10g
11/2005
v$sql_workarea_active
OPTIMAL_ME ONEPASS_ME
---------- ---------SELECT STATE
SORT
GROUP BY
16
16
HASH JOIN
SEMI
5194
2187
TABLE ACCESS FULL
TABLE ACCESS FULL
O/1/M
-----4582
8
4582
5976
Response Time Analyse 10g
OPERATION
OPTIONS NAME
input(MB) LAST_MEM
------------ -------- -------- --------- --------
16/0/0
16/0/0
ORDERS
LINEITEM
51
1000
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 194 von 197
194
Response Time Analyse 10g
11/2005
v$sql_workarea_active
Response Time Analyse 10g
SELECT
to_number(decode(SID, 65535, NULL, SID)) sid,
operation_type OPERATION,
trunc(WORK_AREA_SIZE/1024) WSIZE,
trunc(EXPECTED_SIZE/1024) ESIZE,
trunc(ACTUAL_MEM_USED/1024) MEM,
trunc(MAX_MEM_USED/1024) "MAX MEM",
NUMBER_PASSES PASS
FROM V$SQL_WORKAREA_ACTIVE
ORDER BY 1,2;
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 195 von 197
195
Response Time Analyse 10g
11/2005
v$sql_workarea_active
Response Time Analyse 10g
SID
--27
44
71
OPERATION
WSIZE ESIZE
MEM MAX MEM PASS
--------------- ----- ------ ------ ------- ---GROUP BY (SORT)
73
73
64
64
0
HASH-JOIN
3148
3147
2437
2437
0
HASH-JOIN
13241 19200 12884
34684
1
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 196 von 197
196
Response Time Analyse 10g
11/2005
Literatur
Response Time Analyse 10g
James Morle – Scaling Oracle 8i
Cary Millsap with Jeff Hold – Optimizing Oracle Performance
R.Shee, K. Deshpande, K. Gopalakrishnan – Oracle Wait Interface
Diverse Metalink-Artikel
©Database Consult GmbH - Jachenau
Version 10/2005
Copyright Database Consult GmbH
Folie 197 von 197
197