Speicheroptimierung und DBMS Tuning 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) Dynamische v$views 3) AWR 4) Festplatten-Tuning 5) Instanz-Tuning 6) Fazit -3-
1 Problemstellung I Analyse und Tuning der Datenbank-Instanz hydra01 Problem der DB: Lange Wartezeiten auf Abfrage Ergebnisse Sehr große Ergebnismengen -4-
1 Software Problemstellung II 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 -5-
2 Dynamische v$views I Dynamische In-Memory Views Mehr als 300 v$views Zustand von Speicher, Puffern und Pools Session-Status Metriken I/O-Informationen Datenbank Konfiguration etc. -6-
2 Dynamische v$views II Vorgehensweise in der Performance-Analyse: 1.v$session untersuchen 2.Wait-Klassen untersuchen 3.Schlussfolgerungen ziehen -7-
3 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 -8-
4 Festplatten-Tuning I Die Festplatte ist die langsamste Einheit der DB Problem: alle Daten liegen auf den Platten Also: Gute I/O ist das A und O -9-
4 Festplatten-Tuning II Analyse -10- Performance- Übersicht im Enterprise- Manager
4 Festplatten-Tuning III Analyse der v$session: SELECT wait_class, count(username) PROCESS_COUNT from v$session GROUP BY wait_class; Analyse WAIT_CLASS PROCESS_COUNT --------------- ------------- Concurrency 3 User I/O 3 Configuration 1 Idle 177 Commit 1-11-
4 Festplatten-Tuning IV 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-12- Analyse
4 Festplatten-Tuning IV Analyse der Wait-Klassen: Analyse 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 -13-
Festplatten-Tuning V 4 Wait Classes aus dem AWR-Report Historische Analyse 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-14-
4 Festplatten-Tuning V Wait-Klassen Wait Classes aus dem AWR-Report Historische Analyse 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 Commit Network 1,618,897,542 0.00 51,507 0 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-15-
4 Festplatten-Tuning VI Analyse von v$views v$session Analyse von historischen Daten (AWR-Report) Wait Classes verschafft einen Überblick Wait Events bietet mehr Details Zusammenfassung der Analyse -16-
4 Festplatten-Tuning VII Strategie: Last verteilen Optimieren Concurrency beim Lesen von der HDD verringern -17-
4 Festplatten-Tuning VIII Hot Spots aufspüren Tuning-Maßnahme vorbereiten Tablespace IO Stats aus dem AWR-Report -18-
4 Tablespace IO Stats... aus dem AWR-Report Tuning-Maßnahme vorbereiten 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. -19-
4 Festplatten-Tuning VIII Hot Spots aufspüren Tuning-Maßnahme vorbereiten Tablespace IO Stats aus dem AWR-Report File IO Stats aus dem AWR-Report -20-
4 File IO Stats... aus dem AWR-Report Tuning-Maßnahme vorbereiten 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. -21-
4 Festplatten-Tuning VIII Hot Spots aufspüren Tuning-Maßnahme vorbereiten Tablespace IO Stats aus dem AWR-Report File IO Stats aus dem AWR-Report Segments by Physical Reads aus dem AWR- Report -22-
4 Segments by Physical Reads... aus dem AWR-Report Tuning-Maßnahme vorbereiten 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. -23-
4 Festplatten-Tuning IX Redo- und Archive-Logs von Datendateien trennen Hot Spots auf physikalisch getrennte Plattensysteme verteilen Hot Tables verteilen und ggf. partitionieren evtl. Indizes auslagern Tuning Zusammenfassung -24-
5 Instance-Tuning I 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 -25-
5 Instance-Tuning II Trefferrate des Datenpuffers Analyse Optimal > 95% Mindestens > 90% Trefferrate des Datenpuffers muss optimiert werden! -26-
5 Instance-Tuning III 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 KEEP- und RECYCLE-Pool Speichert große Objekte, bei denen Buffer-Hits selten sind -27-
5 Instance-Tuning IV 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. -28-
5 Instance-Tuning V RECYCLE-Pool Konfigurieren RECYCLE-Pool 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);... -29-
5 Instance-Tuning VI RECYCLE-Pool Vergleich: Trefferrate des Datenpuffers, vorher und nachher nachher vorher -30-
5 Instance-Tuning VI RECYCLE-Pool Vergleich: Trefferrate des Datenpuffers, vorher und nachher nachher vorher -31-
6 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 -32-
Fragen Sie das ORACLE -33-