DBMS Tuning Get Started... von Daniel Nelle <d.nelle@dbtotal.de> dbtotal.de -1-
Ich stelle vor... Daniel Nelle (*1983) Oracle Datenbank Administrator seit 2004 Informatik-Student an der Hochschule für Technik und Wirtschaft in Karlsruhe z. Zt. DBA bei der mentasys GmbH Bachelor Thesis: Oracle Performance Tuning dbtotal.de 6-Köpfiges Consulting-Team (Stand Nov. 2007) Geleitet von Thomas Tretter -2-
Inhalt 1) Problemstellung 2) Allgemeines Merkzettel Dynamische v$views AWR 3) I/O-Tuning 4) Instanz-Tuning 5) Fazit -3-
Problemstellung -4-
Sprüche Sekretärin:... der Computer lahmt Vorstand:... we are experiencing some technical difficulties with our IT infrastructure Chef:... irgendein Server ist überlastet Developer:... die Datenbank hängt DBA: <geflohen> -5-
Umgebung Analyse und Tuning der Datenbank-Instanz hydra01 Problem der DB: Lange Wartezeiten auf Abfrage Ergebnisse Sehr große Ergebnismengen -6-
System Software RHE Linux 4 Oracle 10.2.0.2 Datenvolumen von c.a. 150 GB Hardware DELL PowerEdge 2x Intel Xenon, QuadCore, 64Bit 16GB RAM 2x DELL Storage mit je 15 SAS-Platten Hardware-RAID -7-
Allgemeines -8-
Merkzettel Verfügbarkeitsanalyse Hardware, Strom, Netzwerk Backup Recovery (getestet?). Datenbank Redundanz Kontinuierliche Pflege Wildwuchs vermeiden -9-
Dynamische v$views Dynamische In-Memory Views Mehr als 300 v$views Zustand von Speicher, Puffern und Pools Session-Status Metriken I/O-Informationen Datenbank Konfiguration etc. -10-
Dynamische v$views Vorgehensweise in der Performance-Analyse: 1.v$session untersuchen 2.Wait-Klassen untersuchen 3.Schlussfolgerungen ziehen -11-
AWR Automated Workload Repository Sammlung von Performance-Snapshots WRx-Tabellen liegen im SYSAUX-Tablespace DB-Analyse durch Direktes Abfragen des AWRs (dba_hist-views) Untersuchen des AWR-Reports -12-
I/O-Tuning -13-
Stellenwert von I/O Die Festplatte ist die langsamste Einheit der DB Problem: alle Daten liegen auf den Platten Also: Gute I/O ist das A und O -14-
-15- Performance- Übersicht im Enterprise- Manager
Analyse der v$session SELECT wait_class, count(username) PROCESS_COUNT from v$session GROUP BY wait_class; WAIT_CLASS PROCESS_COUNT --------------- ------------- Concurrency 3 User I/O 3 Configuration 1 Idle 177 Commit 1-16-
Analyse der Wait-Klassen SELECT e.wait_class, sum(s.total_waits) TOTAL_WAITS, sum(s.time_waited) "TIME_WAITED (SEC)" FROM v$event_name e, v$system_event s WHERE e.name = s.event GROUP BY e.wait_class; WAIT_CLASS TOTAL_WAITS TIME_WAITED (SEC) ---------------- -------------------- -------------------- Concurrency 50548177 12640044 User I/O 1802725932 621208283 System I/O 43479778 16111609 Administrative 30 458 Configuration 1006237 4384208 Other 3186256 5961858 Application 1069663 3062720 Idle 781380722 13877362166 Commit 29599145 15022850 Network 3933391182 9867948-17-
Analyse der Wait-Klassen SELECT e.wait_class, sum(s.total_waits) TOTAL_WAITS, sum(s.time_waited) "TIME_WAITED (SEC)" FROM v$event_name e, v$system_event s WHERE e.name = s.event GROUP BY e.wait_class; Wait-Klassen Wait-Klassen (ohne Idle) Concurrency User I/O System I/O Administrative Configuration Other Application Commit Network Idle Concurrency User I/O System I/O Administrative Configuration Other Application Commit Network -18-
Wait Classes im AWR-Report Wait Class s - second cs - centisecond - 100th of a second ms - millisecond - 1000th of a second us - microsecond - 1000000th of a second ordered by wait time desc, waits desc Wait Class Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn User I/O 620,313,602 0.01 1,778,128 3 60.00 Network 1,618,897,542 0.00 51,507 0 156.60 System I/O 15,006,108 0.00 48,962 3 1.45 Application 395,388 3.96 47,529 120 0.04 Concurrency 10,893,161 1.00 38,818 4 1.05 Commit 10,438,688 0.08 35,089 3 1.01 Other 950,491 34.50 23,069 24 0.09 Configuration 115,815 96.29 13,743 119 0.01 Administrative 8 25.00 12 1559 0.00-19-
Wait Classes im AWR-Report Wait-Klassen Wait Class s - second cs - centisecond - 100th of a second ms - millisecond - 1000th of a second us - microsecond - 1000000th of a second ordered by wait time desc, waits desc User I/O Network System I/O Wait Class Waits %Time -outs Total Wait Time (s) Avg wait Application (ms) Waits /txn User I/O 620,313,602 0.01 1,778,128 3 Concurrency60.00 Network 1,618,897,542 0.00 51,507 0 Commit 156.60 Other System I/O 15,006,108 0.00 48,962 3 1.45 Configuration Application 395,388 3.96 47,529 120 Administrative 0.04 Concurrency 10,893,161 1.00 38,818 4 1.05 Commit 10,438,688 0.08 35,089 3 1.01 Other 950,491 34.50 23,069 24 0.09 Configuration 115,815 96.29 13,743 119 0.01 Administrative 8 25.00 12 1559 0.00-20-
Review: In-Memory-Analyse Analyse von v$views v$session Analyse von historischen Daten (AWR-Report) Wait Classes verschafft einen Überblick Wait Events bietet mehr Details -21-
I/O-Tuning Tuningkonzept erstellen -22-
Idee Strategie: Last verteilen Concurrency beim Zugriff auf HDD verringern -23-
Historische Daten Hot Spots aufspüren Tablespace IO Stats aus dem AWR-Report -24-
Tablespace IO Stats... aus dem AWR-Report Tablespace IO Stats ordered by IOs (Reads + Writes) desc Tablespace Reads Av Reads/s Av Rd(ms) Av Blks/Rd Writes Av Writes/s Buffer Waits Av Buf Wt(ms) TBS01_DE 107,342,545 179 4.30 3.23 2,840,608 5 32,441,539 4.61 TBS04_DO* 84,474,931 141 3.14 2.42 1,248,807 2 254,666,564 1.77 TEMP 59,040,010 98 0.70 1.12 2,614,475 4 0 0.00 USERS 51,362,433 85 2.88 4.62 2,323,808 4 13,735 6.45 TBS11_UK 17,326,226 29 2.53 4.56 380,756 1 1,860,686 1.15 TBS02_FR 17,121,480 28 2.76 4.73 412,104 1 242,323 4.33 TBS10_IT 5,155,073 9 3.89 3.97 180,672 0 153,269 2.78 UNDOTBS1 1,319,510 2 3.55 1.00 1,045,540 2 96,058 5.36 TBS07_MSY 2,004,974 3 11.36 10.43 7,330 0 752,279 5.33 TBS05_CN* 1,511,031 3 10.29 7.66 74,527 0 2,399,043 4.57 INDX 831,300 1 46.88 1.55 531,039 1 8 296.25 INDEX_TBS01_DE 707,463 1 61.52 1.21 171,571 0 57,855 41.94 INDEX_TBS04_DO* 506,892 1 66.70 1.18 134,239 0 69,558 31.25 *) Enthält Kundeninformationen und wurde deshalb verkürzt. -25-
Historische Daten Hot Spots aufspüren Tablespace IO Stats aus dem AWR-Report File IO Stats aus dem AWR-Report -26-
File IO Stats... aus dem AWR-Report File IO Stats ordered by Tablespace, File Tablespace Filename Reads Av Reads/s Av Rd(ms) Av Blks/Rd TEMP /data/data0/oradata/hydra01/temp01.dbf 59,040,010 98 0.70 1.12 TBS04_DO* /data/data3/oradata/hydra01/tbs04_04.dbf 21,837,036 36 3.03 2.31 TBS04_DO* /data/data3/oradata/hydra01/tbs04_05.dbf 19,492,230 32 2.95 2.33 TBS04_DO* /data/data3/oradata/hydra01/tbs04_03.dbf 17,387,424 29 3.24 2.47 TBS01_DE /data/data1/oradata/hydra01/tbs01_03.dbf 17,027,268 28 4.37 3.13 TBS01_DE /data/data1/oradata/hydra01/tbs01_05.dbf 16,566,401 28 4.25 3.19 TBS01_DE /data/data1/oradata/hydra01/tbs01_04.dbf 15,356,982 26 4.13 3.40 TBS01_DE /data/data1/oradata/hydra01/tbs01_07.dbf 15,283,612 25 4.23 3.15 TBS01_DE /data/data1/oradata/hydra01/tbs01_06.dbf 14,808,101 25 4.31 3.40 TBS01_DE /data/data1/oradata/hydra01/tbs01_01.dbf 14,276,704 24 4.56 3.17 TBS01_DE /data/data1/oradata/hydra01/tbs01_02.dbf 14,023,477 23 4.26 3.22 TBS04_DO* /data/data3/oradata/hydra01/tbs04_01.dbf 13,256,312 22 3.37 2.57 TBS04_DO* /data/data3/oradata/hydra01/tbs04_02.dbf 12,501,929 21 3.23 2.54 USERS /data/data0/oradata/hydra01/users03.dbf 10,165,033 17 2.94 4.58 [...] [...] [...] [...] [...] [...] *) Enthält Kundeninformationen und wurde deshalb v erkürzt. -27-
Historische Daten Hot Spots aufspüren Tablespace IO Stats aus dem AWR-Report File IO Stats aus dem AWR-Report Segments by Physical Reads aus dem AWR- Report -28-
Segments by Physical Reads... aus dem AWR-Report Segments by Physical Reads Total Physical Reads: 1,075,129,515 Captured Segments account for 92.9% of Total Owner Tablespace Name Object Name Obj. Type Physical Reads %Total HCAT2 TBS01_DE OFF_DE_OFFER TABLE 347,177,331 32.29 HCAT2 USERS OFF_OFFER TABLE 233,437,359 21.71 DO* TBS04_DO* OFF_OFFER TABLE 202,491,066 18.83 HCAT2 TBS02_EU OFF_FR_OFFER TABLE 80,957,318 7.53 HCAT2 TBS11_UK OFF_UK_OFFER TABLE 78,960,389 7.34 *) Enthält Kundeninformationen und wurde deshalb v erkürzt. -29-
Review: I/O-Tuning Redo- und Archive-Logs von Datendateien trennen Hot Spots auf physikalisch getrennte Plattensysteme verteilen Hot Tables verteilen und ggf. partitionieren evtl. Indizes auslagern -30-
Instanz-Tuning -31-
Ein kleiner Anfang Allgemeine Speicherparameter SGA_MAX_SIZE und SGA_TARGET LOCK_SGA DB_FILE_MULTIBLOCK_READ FILESYSTEMIO_OPTIONS (mehr im Script) Optimieren des Speichers verbessert I/O Optimieren des Datenpuffers -32-
Cache Hits Trefferrate des Datenpuffers Optimal > 95% Mindestens > 90% Trefferrate des Datenpuffers muss optimiert werden! -33-
Datenpuffer Tuning mit KEEP- und RECYCLE-Puffer Datenpuffer arbeitet mit dem LRU-Prinzip Große Abfragen wirbeln den Datenpuffer durcheinander KEEP-Puffer Speichert häufig gelesene Objekte Objekte sind immer im Speicher -> richtige Größe RECYCLE-Puffer Speichert große Objekte, bei denen Buffer-Hits selten sind -34-
RECYCLE Pool Sehr große Objekte sollen in den RECYCLE- Pool geladen werden Segments by Physical Reads Total Physical Reads: 1,075,129,515 Captured Segments account for 92.9% of Total Owner Tablespace Name Object Name Obj. Type Physical Reads %Total HCAT2 TBS01_DE OFF_DE_OFFER TABLE 347,177,331 32.29 HCAT2 USERS OFF_OFFER TABLE 233,437,359 21.71 DO* TBS04_DO* OFF_OFFER TABLE 202,491,066 18.83 HCAT2 TBS02_EU OFF_FR_OFFER TABLE 80,957,318 7.53 HCAT2 TBS11_UK OFF_UK_OFFER TABLE 78,960,389 7.34 *) Enthält Kundeninformationen und wurde deshalb v erkürzt. -35-
So gehts RECYCLE-Pool Konfigurieren SPFILE sichern! Parameter im SPFILE anpassen: alter system set db_recycle_cache_size=1200m scope=spfile; Datenbank neu starten Tabellen anweisen, den RECYCLE-Pool zu verwenden: alter table hcat2.off_de_offer storage(buffer_pool RECYCLE); alter table HCAT2.OFF_DE_OFFER storage(buffer_pool RECYCLE);... -36-
Vergleich Trefferrate des Datenpuffers, vorher und nachher. nachher vorher -37-
Vergleich Trefferrate des Datenpuffers, vorher und nachher nachher vorher -38-
Fazit Die gegenseitige Abhängikeit der verschiedenen Koponenten macht Oracle Tuning zu einer Kunst, macht es aber auch so spannend! Oracle Tuning ist ein Fass ohne Boden Die Grundsätzliche Vorgehensweise ist aber immer die selbe -39-
Fragen Sie das ORACLE -40-