Automatisierung von Tabellen- und Index-Reorganisationen

Transkript

1 UB SERVICES ZIT P Automatisierung von Tabellen- und Index-Reorganisationen SAP/Oracle-Umfeld

2 2 Agenda 1. Wie Fragmentierung entsteht Objekt-Fragmentierung Tablespace-Fragmentierung 2. Problematik bei Fragmentierung (Beispiel SAP-Umfeld) Unterschiedliche Extent-Größen Nutzloser Speicherplatz 3. Die Lösung: Neuaufteilung der DB-Objekte Uniform Extents Zusätzliche Tablespaces 4. Die automatisierten Verfahren Index-Rebuild Table-Rebuild Move Table

3 3 1. Wie Fragmentierung entsteht Objekt-Fragmentierung: Tabellen Durch update und delete entstehen Lücken und chained rows Insert into... PCTFREE row 7 row 6 row 5 row 4 row 3 row 2 row 1 unfragment. Block delete from... where row>4 PCTFREE row 4 row 3 row 2 row 1 Block ist fragmentiert bis pctused erreicht update... set... where row=7 Block 1 Block n ptr 7 row 7 row 6 row 5 row 4 row 3 row 2 row 1 Chained rows

4 4 1. Wie Fragmentierung entsteht Objekt-Fragmentierung: Indexe Durch insert, update und delete werden Blöcke aufgespalten Insert: Block-Splitting Leaf-Block 1 10 RowID 12 RowID 11 RowID 13 RowID Update/Delete: unbenutzbarer Bereich entsteht 10 RowID 11 RowID 13 RowID Leaf-Block 1 Leaf-Block 2 10 RowID 12 RowID 11 RowID 13 RowID update Tabelle set ID=ID+50 where ID in (10,11) 13 RowID 60 RowID 61 RowID

5 5 1. Wie Fragmentierung entsteht Tablespace-Fragmentierung: Durch Create, Drop und Recreate von Datenbank-Objekten entstehen Lücken : INIT1 INIT2 INIT3 INIT4 NEXT3 Tabelle1 NEXT1 NEXT3 NEXT1 NE XT1 NEXT3 Tabelle2 NEXT4 NEXT2 NEXT1 Tabelle3 Tabelle4 create table Tabelle5 as select * from Tabelle3; drop table Tabelle3; alter table Tabelle5 rename to Tabelle3; INIT1 INIT2 INIT4 NEXT1 NEXT1 XT1 NEXT4 NEXT2 NEXT1 INIT3 NE

6 6 2. Problematik (Beispiel SAP-Umgebung): Unterschiedliche Extent-Größen SQL> select tablespace_name, count(distinct bytes) NUMDIST, count(distinct segment_name) 2 as NUMOBJ, min(bytes)/1024 as KBMIN, max(bytes)/1024 as KBMAX 3 from dba_extents where owner='sapr3' group by tablespace_name; TABLESPACE_NAME NUMDIST NUMOBJ KBMIN KBMAX PSAPBTABD PSAPBTABI PSAPCLUD PSAPCLUI PSAPDDICD PSAPDDICI PSAPDOCUD PSAPDOCUI PSAPPOOLD PSAPPOOLI PSAPPROTD PSAPPROTI PSAPSOURCED PSAPSOURCEI PSAPSTABD PSAPSTABI

7 7 2. Problematik So entsteht nutzloser Speicherbereich, d.h. viele kleine Lücken im Tablespace (dba_free_space): - Erreichen von Maxextents und anschließende manuelle Reorganisation - Verschieben von Tabellen in ein anderes Tablespace - Alter Index rebuild - Hinzufügen von kleinen Datenbank-Dateien

8 8 2. Problematik Weitere Gründe für Reorganisationen können sein: - Falsch dimensionierte Tabelle - Block-Fragmentierung - Viele Transaktionen => Erhöhung von INITTRANS-Parameter - Güte eines Index extrem schlecht => Neuaufbau Objekt-Reorganisationen und sind bei Datenbanken mittelfristig nicht vermeidbar!

9 9 3. Die Lösung: Neuaufteilen der DB-Objekte Neue Tablespaces: create tablespace PSAP40KB1D datafile... default storage (initial 40K next 40K maxextents 5000 pctincrease 0) miminum extent 40K; Alternativ bei 8i/9i: create tablespace PSAP40KB1D datafile... extent management local uniform size 40k; create tablespace PSAP640KB1D... create tablespace PSAP10MB1D... create tablespace PSAP50MB1D...

10 10 3. Die Lösung: Neuaufteilen der DB-Objekte Tabellen mit create table as select ohne storage-klausel verschoben Nur eine einzige Extent-Größe innerhalb eines Tablespace! PSAPBTABD PSAPCLUD PSAPDDICD PSAPDOCUD PSAPLOADD PSAPPOOLD PSAPPROTD PSAPSOURCED PSAPSTABD PSAPUSER1D <640KB >=640KB und <10MB >=10MB und <=1000MB >1000MB PSAP40KB1D PSAP640KB1D PSAP10MB1D PSAP50MB1D Standard-Tablespaces wurden gelöscht und leer mit 50MB Größe angelegt

11 11 3. Die Lösung: Neuaufteilen der DB-Objekte Select auf dba_extents: SQL> select tablespace_name, count(distinct bytes) NUMDIST, count(distinct segment_name) 2 as NUMOBJ, min(bytes)/1024 as KBMIN, max(bytes)/1024 as KBMAX 3 from dba_extents where owner='sapr3' group by tablespace_name; TABLESPACE_NAME NUMDIST NUMOBJ KBMIN KBMAX PSAP40KB1D PSAP40KB1I PSAP640KB1D PSAP640KB1I PSAP10MB1D PSAP10MB1I PSAP50MB1D PSAP50MB1I PSAPBTABD PSAPBTABI PSAPDDICD PSAPDDICI

12 12 3. Die Lösung: Neuaufteilen der DB-Objekte Durch Reorganisationen freigewordener Speicherplatz kann jederzeit wieder belegt werden: drop table Tabelle3; alter table Tabelle5 rename to Tabelle3; INIT1 INIT2 INIT3 INIT4 NEXT3 NEXT1 NEXT1 NEXT1 NEXT1 NEXT1 NEXT1 NEXT1 NEXT3 NEXT3 NEXT3 NEXT4 NEXT4 NEXT4 NEXT4 NEXT4 NEXT2 NEXT3 NEXT1 create table Tabelle5 as select * from Tabelle3; INIT1 INIT2 INIT4 NEXT1 NEXT1 NEXT1 NEXT1 NEXT1 NEXT1 NEXT1 NEXT4 NEXT4 NEXT4 NEXT4 NEXT4 NEXT2 NEXT1 INIT3 NEXT3 NEXT3 NEXT3 NEXT3 NEXT3 insert into Tabelle1... INIT1 INIT2 INIT3 INIT4 NEXT3 NEXT1 NEXT1 NEXT1 NEXT1 NEXT1 NEXT1 NEXT1 NEXT3 NEXT3 NEXT3 NEXT4 NEXT4 NEXT4 NEXT4 NEXT4 NEXT2 NEXT3 NEXT1 INIT5 NEXT5 NEXT5 NEXT5 NEXT5 NEXT5 INIT1 INIT2 NEXT1 INIT4 NEXT1 NEXT1 NEXT1 NEXT1 NEXT1 NEXT1 NEXT1 NEXT1 NEXT1 NEXT1 NEXT1 NEXT4 NEXT4 NEXT4 NEXT4 NEXT4 NEXT2 NEXT1 INIT3 NEXT3 NEXT3 NEXT3 NEXT3 NEXT3 NEXT1

13 13 4. Die automatisierten Verfahren Automatische Tabellen Reorganisationen: - Wöchentliches analyze table estimate statistics rows auf alle Tabellen - Während Downtime: In einer PL/SQL-Schleife create table as select /*+index(tab Tab~0)*/ -Statements absetzen für alle Tabellen mit num_rows*avg_row_len/(blocks*block_size)<0.5 - Tabellen mit LONG-Feldern werden mit exp/imp-utility reorganisiert - Zentrales Überwachen durch Abgleich mit einem zentralen Repository

14 14 4. Die automatisierten Verfahren Clustering Factor erhöhen: - Index-Hint /*+index(tab Tab~0)*/ bei CTAS-Statements - Datensätze werden sortiert wie der Primärschlüssel - Sequentiellen Lesen (Range-Scan) über Index erfordert wesentlich weniger Disk-I/O DB_BLOCK_BUFFER LB1 TB1 Leaf-Block 1 10 RowID 11 RowID 13 RowID Tabellen-Block 1 RowID RowID RowID

15 15 4. Die automatisierten Verfahren Move-Table Funktion: - Im Repository kann definiert werden, ob eine Tabellen-Reorganisation mit neuen storage-parametern forciert werden soll - Dadurch kann eine stark wachsende Tabelle z.b. in das Tablespace mit der nächsthöheren Extent-Größe verschoben werden - Beim wöchentlichen Reorg-Lauf werden die definierten Tabellen bevorzugt berücksichtigt

16 16 4. Die automatisierten Verfahren Move-Table Funktion: Eingabemaske

17 17 4. Die automatisierten Verfahren Automatischer Index-Rebuild: - wöchentliches analyze index validate structure auf jeden Index - Abspeichern der Ergebnisse in einer lokalen Tabelle - Erstellen von alter index rebuild -Statements für alle Indexes mit Height>3 und del_lf_rows_len/lf_rows_len>0.2 - Start des Index-Rebuild-Skripts - Zentrales Überwachen durch Abgleich mit einem zentralen Repository

18 18 4. Die automatisierten Verfahren Historisierung - Zweimal täglich werden die Daten aus v$parameter, dba_segments, dba_tablespaces und dba_free_space aller DB s mit der zentralen DB abgeglichen (historisiert) - Wenn sich ein beliebiger Wert in einem Datensatz zum Repository ändert, wird dort ein Datensatz erstellt - Täglich wird aus dem Repository eine Mail generiert mit Informationen, ob systemübergreifend z.b. - Eine Tabelle mehr als 500 Extents oder zu 90% maxextents erreicht hat - Tablespace mehr als 90% voll ist

19 19 4. Die automatisierten Verfahren Speicherplatzverlauf Tablespace PSAP10MB1D

20 20 Fazit - Verlagern der Administration vom Reagieren zum Agieren - Kalkulierbarer und berechenbarer Platz in allen Tablespaces - Höhere Verfügbarkeit, keine ORA Fehlermeldungen - Keine Wochenend-Aktionen für Reorganisationen - Automatisches Erkennen von fragmentierten Tabellen und Indexen - Optimaler Füllgrad der Datenbank-Blöcke - Optimale Speicherplatzausnutzung in den Tablespaces

21 21 Vielen Dank für Ihre Aufmerksamkeit! Q + A Rainer.Zerwes@commerzbank.com