Kapitel VIII: DB2 - Utilities, der Katalog und ToolsDB2 Reorg Plus Tabellen Reorganisdationswerkzeug von BMC Inc. DB/Auditor DB2 Audit-Reporting System von Systems Center Inc. DB/DASD

© S.K. Consulting Services München 08106 / 29977 Seite - 1 -

Kapitel IX: DB2-Utilities, der Katalog und Tools

Kapitel VIII:DB2 - Utilities, der Katalog und Tools

( Hilfen für den Umgang mit DB2 )





Inhaltsverzeichnis

1. Tools und Werkzeuge zu DB2 5

1.1 Möglichkeiten der formatierten Dateneingabe in DB2 81.2 Katalogverwaltung und -nutzung 91.2.1 Die Katalogstruktur von DB2 91.2.2 Die Systemtabellen von DB2 111.2.3 Die wichtigsten Systemtabelleninformationen 14

2. Utilities 16

2.1 Das CHECK - Utility 172.2 Das LOAD - “utility” 172.3 Das QUIESCE - “utility” 172.5 PENDING Status 20

3. Performanceverbesserungen an Utilities 21

3.1 PREFORMAT 213.2 SORTKEYS 213.2.1 Vorteile 233.2.2 Überlegungen 233.3 COPYDDN und RECOVERDDN 243.3.1 Überlegungen zum "inline copy" 253.3.2 Bemerkungen zum "inline copy" 253.4. RECOVER INDEX 263.5. COPY 273.5.1 Die COPY CHANGELIMIT Option und Report 273.5.2 Automatisieren des Image Copy Prozesses 293.6. RUNSTATS 303.6.1. Gründe für die Nutzung des RUNSTATS-Utility 303.6.2. Änderungen auf die Katalog-Tabellen 313.6.3. Schnellerer RUNSTATS mit "sampling" 313.6.4. Messungen zum RUNSTATS mit "sampling" 323.6.5. Korrelationsstatistiken 353.6.5.1 Korrelationsstatistiken - Empfehlung 363.6.5.2 Spalten für die Korrelationsstatistiken 373.7. Online REORG 383.7.1 Die Option SHRLEVEL 383.7.2 Die "shadow datasets" 393.7.3 Die Phasen des Online REORG Utility 403.7.4 Die Phasen des Online REORG und das Sperrverhalten 413.7.5 Die "mapping table" 443.7.6 Die Ausführung eines Online REORG 443.7.7 Die Messungen beim Online REORG 453.7.8 Die Empfehlungen zum Online REORG 46

Index 47





1. Tools und Werkzeuge zu DB2

Da DB2 Werkzeuge zur Verwaltung der Datenbanken, Entwicklung von Datenbankanwendungen undoberflächengestützten Benutzerabfragen vermissen läßt, haben sich in diese Nische eine Reihe vonToolanbietern eingenistet und bieten nützliche und effiziente Tools zu den verschiedensten Aufgabenan. Die wichtigsten Anbieter seien hier genannt:

ð IBM Performance-Monitor

ð PLATINUM DBA-Tools, Tools zur Katalogverwaltung, Tools zur physischen Daten-

verwaltung ( Komprimierung, Encryption usw. )

ð BMC DBA-Tools, Tools zur Katalogverwaltung, Tools zur physischen Daten-

verwaltung ( Komprimierung, Encryption usw. )

ð Candle Performance-Monitor

ð CLEVER.SYS Tools zur Datenverwaltung und Testdatenerstellung mit "Relational Tools"von Princeton Softech Inc.

Die bekanntesten und wohl auch wirkungsvollsten Produkte in einer DB2-Umgebung sind:

Accelerator for DB2 Performance-Werkzeug für DB2 von BMC

Accumac for DB2 Performance Monitor für DB2 von Legent (jetzt CA)

APS/DB2 DB2 Tool von Sage Software

Avoid-Bind DB2 Utility, das Programmänderungen analysiert, um herauszufinden, obRE-BIND’s nötig sind: HLS Technologies

Capacity Plus Tool zur Datenkomrimierung von Softworks Inc.

CA-ProAudit Audit- und Reporting-System für DB2 von CA

CA-ProEdit Entwicklungs- und Test-Werkzeug von CA

CA-ProOptimize SQL-Statement Optimierer und Werkzeug für das physische Design vonDB2-Datenbanken

CA-ProSecure Security-Administrationswerkzeug für DB2 von CA

CDF Communications and Data Facility. Ein Teil des IBM-Datenmanagementsfür CIM-Daten. Es besteht aus einem DB2-Repository und wird von IISRgenutzt. Wird ersetzt durch CDF/MVS

Compare Facility DB2 Utility, das es ermöglicht, DB2-Subsysteme und DDL-Dateien zu ver-gleichen und zu synchronisieren: Platinum Technology Inc.

Compress/DB2 DB2 Plattenkomprimierer der DBT Gruppe

Database Analyzer DB2-Monitor mit Analyse-, Prüf- und Tuning-Funktionalität von PlatinumTechnology Inc.

Data Compressor Datenkomprimierer für DB2 von Platinum Technology Inc.



Data Packer Datenkomprimierer für DB2 von BMC. Besitzt verschiedene Ausprägungenfür DB2, IMS, OS und VSAM.

DB2 Activity Monitor DB2 Performance Monitor der BMC Software Inc.

DB2 Admin/Solution DB2 Toolkit für Datenbank- und Security-Administration

DB2 Alter DB2 “change management” Werkzeug von BMC

DB2/Batch Packet für Batch-Betrieb unter DB2 von Relational Architects

DB2 Catalog Manager DB2 Werkzeug von BMC zur Katalogverwaltung von DB2

DB2 Copy Plus DB2 Copy-Dienstprogramm von BMC

DB2 DASD Manager DB2-Tool von BMC

DB2 Manager DB2 Performance Mangement Werkzeug von Bool&Babbage Inc.

DB2 Monitor DB2 Performance Monitor von Responsive Systems Inc.

DB2 On-Schedule DB2-Scheduling System von Tadiran Information Systems

DB2PM DB2-Performance-Monitor von IBM

DB2 Reorg Plus Tabellen Reorganisdationswerkzeug von BMC Inc.

DB/Auditor DB2 Audit-Reporting System von Systems Center Inc.

DB/DASD DB2 DASD-Plattenverwaltungswerkzeug von Candle Inc.

DB/Explain DB2 SQL-Analyse- und Entwicklungswerkzeug von Candle Inc.

DB/Spaceman DB2 “Space Manager” von Candle Inc.

DCC Database Control Center mit mehreren DB2 Utilities von Tone SoftwareCorp.

Diagram/DB2 DB2 “reverse engineering” Werkzeug von Advanced Data Management Inc.

Fast Index DB2 Utility, das Indizes auf große DB2-Tabellen legt: Platinum TechnologyInc.

Fast Load DB2 Utility, das den Ladevorgang von DB2-Tabellen beschleunigt,Statistiken erstellt und “image copies” zieht: Platinum Technology Inc.

Fast Recover DB2 Utility, das DB2-Tablespaces und Indexspaces wiederherstellt: Platin-um Technology Inc.

Fast Unload DB2 Utility, das den Entladevorgang von DB2-Tablespaces bewerk-stelligt: Platinum Technology Inc.

Governor Facility Utility, das QMF-Administratoren hilft, Ressourcen und Kommandoswährend einer QMF-Session zu beobachten: Platinum Technology Inc.

IN2ITIVE DB2 Performance Trend Analyse-werkzeug von Legent (jetzt CA)



InfoPak 6 Datenkomprimierungstools von InfoTel für DB2, VSAM, IMS, CA-IDMS,CA-Datacom/DB und MVS-Dateien

Insight/DB2 DB2 Performance Monitor von Legent (jetzt CA)

Loadplus for DB2 Utility zum Laden von DB2-Tabellen: BMC Inc.

MV Manager for DB2 System Monitor und Report-Werkzeug von Bool&Babbage

Omegamon Performance Monitor von Candle Inc.

Opertune Software zur dynamischen Änderung von DB2-Parametern von BMC Inc.

Performance Advisor Expertensystem zum Tuning von MVS, CICS, IMS und DB2 von DomanskiSciences

Plan Analyzer Utility zur Analyse, Kontrolle und Optimierung von “Application Plans”:Platinum Technology Inc.

Preview for DB2 Expertensystem zur Performancevorhersage in DB2 von Legent (jetzt CA)

Quick Copy Image Copy Utility von Platinum Technology Inc.

Rapid Reorg DB2-Utility zur Reorganisation von Tablespaces und Indexspaces bei DB2:Platinum Technology Inc.

Report Facility DB2- online- und batch-Reporting Werkzeug: Platinum Technology Inc.

Shrink Datenkompressionswerkzeug für DB2 von Sterling Software Inc.

SOP Standards & Operation Procedures für DB2 von Chicago Soft Ltd.

SQL-Ease Utility zur Generierung von SQL-Statements, EXPLAIN-Analyse, Perfor-mance-Vorhersage und SQL-Standardisierung von Platinum TechnologyInc.

Strobe Performance-Messwerkzeug von Programart für MVS, CICS, IMS undDB2-Subsysteme

The Monitor Performance Monitor von Landmark Systems Corp. für VTAM, CICS, DB2und MVS (auch bekannt als TMON).

Vista for DB2 PC-basiertes Werkzeug zur DB2-Performance-Analyse von RelationalData Services

XpEditer Interaktives Test- Debugging-Werkzeug für DB2- und TSO-Umgebungenvon Compuware Corp.



1.1 Möglichkeiten der formatierten Dateneingabe in DB2

Die Notwendigkeit von Werkzeugen um DB2 soll am Beispiel der "Relational Tools"Softech dargestelltwerden. “Relational Tools” von Princeton Softech beruhen auf dem Verständnis und damit der Grund-lage von “relational sets”. Dieser völlig neue Ansatz führt zu einer starken Vereinfachung beim Kopie-ren, Editieren und Inspizieren von DB2-Daten.

Relational Tools” ermöglichen:

ð Die Nutzung von Beziehungen zwischen den Tabellen, um Daten miteinander zu

verknüpfen

ð Die Erstellung relational intakter Testdatenbanken in wenigen Minuten

ð Die vereinfachte Bearbeitung von relationalen Daten

ð Das Erstellen kleiner, unabhängiger Testdatenbanken, die auf die Anforderungen

verschiedenster Entwickler abgestimmt sind

ð Ersparnis von Speicherplatz, indem das Klonen ganzer Produktionsdatenbanken

vermieden wird.

ð Die Überprüfung und das Editieren verknüpfter Daten vor und nach demProgrammtest

Move-for-DB2: DB2-Testdatenbanken erstellen und verwalten

Die Erstellung qualitativ hochwertiger Testdaten war schon immer ein Problem. Die Erstellung qualita-tiv hochwertiger relationaler Testdaten für DB2 ist sogar extrem schwierig, da relationale Daten in meh-reren Tabellen gespeichert werden.

Beispiel: Die Erstellung einer DB2-Testdatenbank durch Kopieren einer Teilmenge der Produktions-datenbank kann Stunden, ja sogar Tage dauern. Hierbei handelt es sich nämlich nicht nur um dasKopieren von 500 wahlfreien Zeilen aus 10 verschiedenen Tabellen. Denn die Zeilen der verschiede-nen Tabellen stehen miteinander in Beziehung. Bei Verwendung von Referentiellen-lntegritäts-Regeln(Rl) wird das Verfahren noch komplizierter.

Ohne Verwendung der “Relational Tools” kann man relationale Testdaten durch Klonen einer gesam-ten Produktionsdatenbank, schrittweises Kopieren einzelner Tabellen oder durch Schreiben einer An-wendung zur Navigation durch die DB2-Daten erstellen.

Access-for-DB2: Relationale Daten überprüfen und editieren

Zum sinnvollen Testen einer Anwendung muß eine Testdatenbank spezielle Testdaten enthalten. Eini-ge dieser Testdaten sollen Datenfehler oder Datenwertkombinationen enthalten, die in der Produktions-datenbank nicht vorkommen oder vorkommen sollen. Mit Access-for-DB2, dem “Relational Editor”, kannman die Testdatenbank überprüfen und im Bedarfsfall Daten modifizieren, einfügen oder löschen.Access-for-DB2 eliminiert das zeitaufwendige manuelle “Zusammensetzen” von Daten aus verschie-denen Tabellen. Entwickler können vor und nach der Ausführung ihrer DB2-Anwendungen die ver-knüpften Daten gleichzeitig auf demselben Bildschirm sehen, prüfen und editieren.



1.2 Katalogverwaltung und -nutzung

Eine Reihe der genannten Tools dienen vorwiegend der Verwaltung des DB2-Katalogs. Sie sind Edito-ren, die die Katalogtabellen und ihre Inhalte in ihrer Abhängigkeit darstellen. Um mit diesen Werkzeu-gen sinnvoll umgehen zu können ist die Kenntnis der Katalogstruktur von DB2 äußerst nützlich.

1.2.1 Die Katalogstruktur von DB2

Der DB2-Katalog besteht aus:

ð den DB2-Systemtabellen

ð dem "directory"-Teil

ð der Metastruktur der DB2-Datenbankumgebung

Bei DB2 dient der Katalog als zentrale Informationsbasis für• Zugriffsberechtigungen

• Optimierungsmaßnahmen

• Verwendungsnachweise

• alle "user"- Datenbank-Objekte

Der Katalog selbst ist hierfür als DB2- (System-) Datenbank (DSNDB04 / DSNDB01) organisiert undbesitzt folgende Eigenschaften:

• er enthält ca. 40 Tabellen( ohne CDB )

• er ist mit SQL abfragbar

• hat nicht für alle Tabellen Indizes !!!

Alle DB2-Objekte, ihre Namen, Eigenschaften und Datentypen werden im DB2-Katalog eingetragen.Die Tabellen des Katalogs heissen auch SYSTEM-Tabellen von DB2. Die DB2-Objekte können unterihren Namen mit SQL wieder aufgefunden werden, da der DB2-Katalog ebenfalls als DB2-Datenbankorganisiert ist.

Die DB2-(User-)Objekte stehen beispielsweise in folgenden Tabellen:

database ð SYSIBM.SYSDATABASE

tablespace ð SYSIBM.SYSTABLESPACE

tables ð SYSIBM.SYSTABLES

index ð SYSIBM.SYSINDEXES usw.



plan

dbrm

vtree

vltree

stmt

tabauth

colauth

packlst

package

packstmt

stogroup

volumes

tablespace

tablepart

tables

synonyms columnsindexes

database

keysindexpart

Das DB-Basismodell

checkdep

checks

Das erweiterte DB2-Katalogmodell

plandep

resauth

userauth

planauth packauth

packdep

Die Metastruktur des Katalogs weist im Groben folgende Abhängigkeiten auf:



1.2.2 Die Systemtabellen von DB2

Die einzelnen System-Tabellen haben folgende Bedeutung:

SYSAUXRELS enthält eine Zeile für jede "auxiliary table", die für eine LOB-Spale erstelltwurde. Jede Basistabelle, die partitioniert wurde, braucht eine "auxiliaryTable" für jede Partiton einer LOB-Spalte (ab V6)

SYSCHECKS enthält eine Zeile für jeden "constraint"

SYSCHECKDEP enthält eine Zeile für jede Referenz auf eine Spalte einer Tabelle ineinem Check- "constraint"

SYSCOLAUTH enthält die GRANT UPDATE Privilegien für Spalten eines Viewsoder einer Tabelle

SYSCOLDIST enthält eine oder mehrere Zeilen für die erste Schlüsselspalte einesIndex (Zeilen können manuell eingefügt und/oder gelöscht werden)

SYSCOLDISTSTATS enthält eine. keine oder mehrere Zeilen für die erste Schlüsselspalte eines"partitioned" Index. "non-partitioned" Indexes werden vom RUNSTATSnicht berücksichtigt.(Zeilen können manuell eingefügt und/oder gelöscht werden)

SYSCOLSTATS enthält eine. keine oder mehrere Zeilen für jede Spalte pro Partition einerTable. "non-partitioned" TS werden vom RUNSTATS nicht berücksichtigt.(Zeilen können manuell eingefügt und/oder gelöscht werden)

SYSCOLUMNS beschreibt die Spalten aller Tabellen

SYSCONSTDEP zeichnet alle Abhängigkeiten auf "check constraints" oder "user-defaults"auf eine Spalte auf (ab V6)

SYSCOPY enthält Recovery-Informationen für DB2-Utilities

SYSDATABASE enthält alle DB2-Datenbanken (nicht DSNDB01)

SYSDBAUTH enthält die Privilegien der User auf die Datenbank(en)

SYSDATATYPES enthält eine "row" für jeden "user-defined datatype" im System (ab V6)

SYSDBRM enthält eine Zeile für jedes DBRM eines Plans

SYSFIELDS enthält eine Zeile für jede Spalte einer Tabelle, auf die eine FIELDPROCgesetzt wurde

SYSFOREIGNKEYS enthält eine Zeile für jede Spalte eines FK

SYSINDEXES eine Zeile pro definierten Index

SYSINDEXPART für partitioned Index entsprechend der Anzahl Partitions, sonst 1Eintrag pro Index

SYSINDEXSTATS enthält eineZeilen für jede Partition eines "partitioned" Index. Die



Kataloigtabelle enthält die korrespondierenden Spalten vonSYSIBM.SYSINDEXES, bezogen auf eine einzelne Partition(Partition-Level-Statistiken)

SYSKEYS beschreibt die Spalten eines Indexkeys

SYSLOBSTATS enthält eine Zeile für jeden LOB-Tablespace (ab V6)

SYSPACKAGE enthält für jedes Package eine Zeile

SYSPACKAUTH enthält die Privilegien der User über die Packages

SYSPACKDEP beschreibt die Abhängigkeit zwischen Packages und DB2-Objekten

SYSPACKLIST beschreibt die Package Lists lokal gebundener Pläne

SYSPACKSTMT enthält das SQL-Skript aller in einen Plan eingebundenen DBRM's

SYSPARMS zenthält eine Zeile für jeden Parameter einer Routine oder mehereZeilen für Tabellenparameter (ab V6)

SYSPKSYSTEM enthält eine oder mehrere Zeilen für jedes Package. Jede Zeile definiertein oder mehrere Verbindungen zu einem bestimmten Trägersystem, indem die Package "enabled" oder "disabled" ist

SYSPLAN enthält für jeden Plan eine Zeile

SYSPLANAUTH enthält die Privilegien der User über die Pläne

SYSPLANDEP beschreibt die Abhängigkeit zwischen Plänen und DB2-Objekten,z.B. Tabellen, Views, Synonyms, Tablespaces, Indizes und Aliases

SYSPLSYSTEM enthält eine oder mehrere Zeilen für jeden Plan. Jede Zeile definiert einoder mehrere Verbindungen zu einem bestimmten Trägersystem, indem der Plan "enabled" oder "disabled" ist

SYSPROCEDURES enthält EINE Zeile für jede "stored procedure"

SYSRELS enthält eine Zeile für jede "referential constraint" zwischen den Tabellen

SYSRESAUTH enthält die USE Privilegien für Bufferpools, Storage Groups, und TS,sowie CREATE IN und PACKADM ON Privilegien für "collections"

SYSROUTINEAUTH zeichnet alle Privilegien eines Users für die vorhandenen Routinen auf(ab V6)

SYSROUTINES enthält eine "row" für jede Routine. Eine Routine kann sein: eine "user-defined function", eine "cast function" oder eine "stored procedure" (abV6)

SYSSCHEMAAUTH enthält eine oder mehrere Zeilen für jeden User, der Privilegien für einSchema in der Datenbank besitzt (ab V6)

SYSSTMT enthält das SQL-Skript aller in einem Package vorkommendenSQL-Befehle



SYSSTOGROUP beschreibt die Storage Groups(zeilenweise)

SYSSTRINGS enthält CHaracter-Konvertierungsinformationen für verteilte Daten. JedeZeile beschreibt Konvertierungsregeln zu einem bestimmten "character-set" auf einen anderen "character-set"

SYSSYNONYMS beschreibt die Synonyme auf Tabellen und Views

SYSTABAUTH enthält die GRANT TABLE Authorisierungen

SYSTABLEPART enthält 1 Zeile für jeden nicht-partitionierten TS und 1 Zeile fürjede Partition eines PTS

SYSTABLESPACE alle Tablespaces

SYSTABLES alle Tabellen zeilenweise

SYSTABSTATS enthält eine Zeile für jede Partition einer Tabelle, die einem PTS zuge-ordnet ist.

SYSTRIGGERS enthält eine "row" für jeden Trigger (ab V6)

SYSUSERAUTH enthält die Systemprivilegien pro User

SYSVIEWDEP enthält Informationen über Abhängigkeiten zwischen Views und Tablesbzw. anderen Views

SYSVIEWS enthält eine oder mehrere Zeilen für jeden View. In einer oder mehrerenZeilen wird der SQL-Statement-Tex des View abgelegt.

SYSVLTREE enthält den restlichen Teil des Analyse-Pfades eines Views fallserforderlich (>4000 Bytes)

SYSVTREE enthält den ersten Teil des Analysepfades eines Views (bis 4000 Bytes)

SYSVOLUMES beschreibt die Volumes pro Storage Group

SYSDUMMY1 enthält EINE Zeile. Die Tabelle wird für SQL-Statements genutzt, indenen eine Tabelle benötigt wird, die Inhalte aber irrelevant sind.

Die aufgeführte Liste von Katalogtabellen ist nicht vollständig....



Zusätzliche wesentliche Informationen aus dem Katalog betreffen natürlich Zugriffsberechtigungen, dieAuthorisierungen. Die folgende Grafik ergänzt die Informationen über den DB2-Katalog in diesemPunkt.

Sie zeigt die Abhängigkeiten in denen sich User bezüglich der Autorisierung befinden.

* Zugriffsberechtigungen

USER

Tabellen und "views" (TABAUTH)

Tabellenspalten (COLAUTH)

Datenbanken (DBAUTH)

Systemressourcen (RESAUTH)

Anwendungspläne (PLANAUTH)

Entsprechend der Autorisierung und den Kenntnissen kann man aus dem Katalog eine Reihe wichtigerTuning- und Administrationsinformationen gewinnen.

Hier eine kleine Auswahl:

SYSINDEXESParameter: CLUSTERED % der Zeilen, die noch in CLUSTER-Reihenfolge sind

FIRSTKEYCARD Anz. unterschiedlicher IX-Wert-Ausprägungen bezogen aufdas erste Indexfeld eines zusammengesetzten Index

FULLKEYCARD Anzahl unterschiedlicher Werte im gesamten IndexNLEVELS Anzahl der Index-Ebenen

SYSTABLESParameter: CARD % der pages des TS die Zeilen der entsprechenden Tabellen

enthalten

SYSINDEXPARTParameter: NEAROFFPOS Anzahl der Zeilen einer Tabelle, die weniger als 16/32 pages

von der "home-page" entfernt sindFAROFFPOS Anzahl der Zeilen einer Tabelle, die mehr als 16/32 pages von

der "home-page" entfernt sindLEAFDIST % Anzahl der IX-Blöcke der "leaf-pages", die nicht in der

geforderten Sequenz (ASC oder DESC liegen)

SYSPLANParameter: PLSIZE Größe des Basissegments eines Plans

AVGSIZE durchschnittliche Größe eines Plan-Segments

1.2.3 Die wichtigsten Systemtabelleninformationen



SYSTABLESPACEParameter: NACTIVE Anzahl aktiver pages im TS

SYSTABLEPARTParameter: FARINDREF Anz. Zeilen, die mehr als 16/32 pages von der "home-page"

entfernt sindNEARINDREF Anz. Zeilen, die weniger als 16/32 pages von der "home-page"

entfernt sindPERCDROP % des Speicherplatzes, der von Zeilen aktiver / gelöschter

Tabellen belegt ist.

Die Interpretation der Aussagen in den Katalogfeldern und deren Zusammenhänge werden jedochdem Benutzer überlassen ... Er ist verantwortlich für die konsequente Einstellung des DB2!

Um bestimmte Zustände im DB2-Umfeld erkennen zu können, ist es möglich, entsprechende Querieszu formulieren, die jedoch je nach Inhalt nicht trivial sind. Als Beispiel folgt eine Query, die nachFremdschlüsseln ohne Indexdefinition fahndet:

SELECT REL.CREATOR , REL.TBNAME , REL.RELNAME

FROM SYSIBM.SYSRELS REL WHERE REL.CREATOR = &creator AND REL.CREATOR !! REL.TBNAME

!! REL.RELNAME NOT IN ( SELECT REL.CREATOR !!

REL.TBNAME !!REL.RELNAME

FROM SYSIBM.SYSFOREIGNKEYS F , SYSIBM.SYSRELS R , SYSIBM.SYSINDEXES I , SYSIBM.SYSKEYS K

WHERE F.CREATOR = R.CREATOR AND F.TBNAME = R.TBNAME AND F.RELNAME = R.RELNAME AND R.CREATOR = I.TBCREATOR AND R.TBNAME = I.TBNAME AND R.COLCOUNT = I.COLCOUNT AND I.CREATOR = K.IXCREATOR AND I.NAME = K.IXNAME AND K.COLNAME= F.COLNAME AND K.COLSEQ = F.COLSEQ GROUP BY

I.NAME, R.CREATOR, R.TBNAME,R.RELNAME, R.COLCOUNT

HAVING COUNT ( * ) = R.COLCOUNT)

ORDER BY REL.CREATOR, REL.TBNAME, REL.RELNAME



Die DB2-Dienstprogramme (utilities) dienen zur Administration der Datentabellen und zur Versorgungder Katalogtabellen mit Optimierungsinformationen und Statistiken. Sie dienen sowohl dem initialenLaden von Daten, als der Sicherung derselben und den Backup-Aufgaben der DBA. Im einzelnen gibtes bei DB2 folgende Utilities:

LOAD Laden von Tabellen aus sequentiellen Dateien

COPY Sichern von Tabellenspeichern (TS) = Image Copy(IC)ð Full IC = Sichern des gesamten TS

ð Incremental IC = Sichern geänderter Teile (Seiten) =Teilsicherung

MERGECOPY Zusammenmischen von Teilsicherungen oder von Teil- und Gesamt-sicherung

REORG Reorganisieren von Tabellenspeichern und/oder Indizes

RUNSTATS Statistische Informationen über Tabellen und Indizes im DB2-Katalogabspeichern. Diese Informationen werden beim automatischen Festlegen der

DB2-Suchstrategie (DB2-Optimizer) verwendet

RECOVER Wiederherstellen von aktuellen Daten auf den Ebenenð Tabellenspeicher (TS),abh. TS

ð “Partition” eines TS (PTS)

ð Teile eines TS (RID's)anhand des DB2-Protokolls (LOG) oder einer Datensicherung (IC oder IIC)

CHECK Indizes auf Konsistenz prüfen und Überprüfen der RI-Bedingungen aufGültigkeit

QUIESCE Definieren eines gemeinsamen „Recovery“-Punkts

STOSPACE Statistik über Platzbelegung von TS und STOGROUPS im DB2-Katalog eintragen

MODIFY Entfernen von alten Informationen über Datensicherungenund DB2-Protokoll (LOG) aus dem DB2-Katalog

REPAIR Reparieren von physischen DB2-Teilen (z.B. pages usw.) in besonderenProblemsituationen (nur für die Systemprogrammierung)

Alle DB2-Utilities sind wiederanlauffähig, d. h. nach Abbruch steht das Dienstprogramm in einer DB2-Utility-Queue (mit einer bestimmten ID=UTILID) und kann über DB2-Kommandos wieder gestartetwerden. Die Verarbeitung wird vom letzten Synchronisationspunkt aus fortgesetzt. Der Nachteil hierbeiist, daß ein abgebrochenes Utility durchaus benötigte Ressourcen im DB2 belegt lassen kann. Indiesem Fall muß das Utility erst aus der Queue entfernt werden - mit dem TERM UTILITY Kommando.Mit DISPLAY UTILITY kann der Status einer Utility-Verarbeitung abgefragt werden. Die Verarbeitung istin mehrere Phasen eingeteilt:

ð Initialisierung (UTILINIT)

ð Bearbeitung (unterschiedlich)

ð Terminierung (UTILTERM)

2. Utilities



Die Bearbeitung besteht aus einer Phase bei COPY, MERGECOPY, MODIFY, RUNSTATS, REPAIR undSTOSPACE. Die Bearbeitung besteht aus mehreren Phasen bei CHECK, LOAD, RECOVER, undREORG.Besonders beachtenswert scheinen folgende gravierenden Änderungen der Utilities seit Version 2.3.

2.1 Das CHECK - Utility

wurde für DB2 V2 R1 erweitert um die Überprüfung von RI - Bedingungenð es identifiziert Inkonsistenzen von RI-Abhängigkeiten

ð es verifiziert die Integrität von Beziehungen zwischen mehreren Tabellen(verbunden mit RI - “constraints”)

ð optional korrigiert die Anweisung CHECK DATA Verletzungen von RI-Bedingungen, indem sie ungültige “rows” aus einer “abhängigen” Tabelle löscht

2.2 Das LOAD - “utility”

ist ebenfalls ein multifunktionales Werkzeug. Es besitzt die folgenden Fähigkeiten:ð Datenzeilen aus einem Ladebestand, die doppelte Werte in einer Spalte mit

UNIQUE INDEX - Definition verursachen würden, werden nicht geladen ...ð ENFORCE CONSTRAINTS (optional) ist “default” für alle LOAD-Vorgänge

ð DISCARD - Verarbeitung: neue DISCARD - Bedingungen wurden implementierta) Eingabe-Daten, die RI-Bedingungen verletzen würden, werden nicht geladenb) Eingabe-Daten mit “duplicate key values” werden nicht geladen

ð LOAD ENFORCE CONSTRAINTS / NO- CHECK PENDING bei Verletzung von RI- ungültige “rows” werden “discarded”

2.3 Das QUIESCE - “utility”

nützt dem RECOVER abhängiger TS unter anderem mitð der Definition eines “point of consistency” (QUIESCE Point) für bestimmte TS

ð dies ermöglicht ein RECOVER dieser TS-Gruppe auf einen bestimmten undkonsistenten Zeitpunkt

ð einem vom System kontrollierten Recovery eines TS - Set für RI; wann immer nichtalle abhängigen TS eines “sets” bis zum selben QUIESCE - Point wiederherstellbar

sind, setzt DB2 alle betroffenen TS in den PENDING-Status, um zu verhindern,daß ein Benutzer inkonsistente Daten zugreift

ð benutzerspezifischem RECOVERY für applikationsbezogene TS

Nutzt man die QUIESCE-Information aus der SYSIBM.SYSCOPY, so kann man benutzergesteuertsicherstellen, daß zusammenhängende Tabellen auf einen bestimmten konsistenten Punkt zurückge-setzt werden können.

Das QUIESCE-UTILITY dient dem Vorbereiten eines log. konsistenten RBA - Zustandes für einzukünftiges RECOVERY und der Definition eines POC über abhängige Tabellen hinweg (!)



Der Ablauf geschieht folgendermaßen:

a) Aufbau des QUIESCE-Punkts- S-Lock auf alle in der Liste angegebenen TS- Prüfung auf COPY/CHECK/RECOVER-PENDING Status

b) Schreiben der WRITE Buffers auf DASD’s - Fehler bei I/O-Error - Schreibfehler auf die Tabelle - TS - RESTART-Pending Status

c) Aufzeichnen des log. RBA auf SYSIBM.SYSCOPY- mit ICTYPE “Q” auf SYSIBM.SYSCOPY- mit “timestamp” und RBA- diese SYSCOPY Information wird auf das LOG geschrieben, wenn

DBD01, SYSCOPY oder SYSUTIL TS in den “QUIESCE”-Zustandgesetzt werden



2.4 Empfehlungen zu den Utilities

1. Überlegungen zu partiellen RECOVERY-Vorgängen:QUIESCE immer periodisch nach COPY-Läufen

2. QUIESCE sollte nicht die regulären COPY-Vorgänge beeinflussen,sondern zu gesonderten Zeitpunkten durchgeführt werden

3. Sicherstellen der Vollständigkeit der TS-Liste (—> Report )

4. QUIESCE auf wenig belastetem System

5. QUIESCE-Punkt auf DSNDB01 und DSNDB06 gemeinsam



2.5 PENDING Status

Es gibt 3 PENDING STATUS für DB2

a) wann immmer DB2 Verletzungen der Datenintegrität entdeckt, so setzt es diebetroffenen DB2 - Objekte in einen Status “PENDING”: CHECK PENDING

b) “data recover” von “user”-Daten ist nicht mehr möglich und DB2 zeigt beliebige ungültigeDaten- und/oder Indexzustände an, die aufgrund von “abnormal termination”von bestimmten “utilities” entstanden sind: RECOVERY PENDING

c) zeigt an, daß Daten nicht mehr wiederherstellbar sind, falls entsprechende Fehlerzu-stände auftreten würden, z.B. "secondary storage failures": COPY PENDING

Entstehung und Auswirkungen von PENDING STATUS:

COPY PENDING CHECK PENDING RECOVERY PENDING

DML „read-only“ none none

utilities alle CHECK RECOVERaußer QUIESCE LOAD REPLACE LOAD REPLACE

REPAIR REPAIRRECOVER

gesetzt LOAD ( LOG NO ) ALTER TABLE RECOVER TOCOPYRECOVER TORBA (add FK) RECOVER TORBARECOVER TOCOPY LOAD (ENFORCE NO) „abnormal

termination“ von:REORG LOG NO LOAD REPLACE * LOADMODIFY DELETE RECOVER TORBA * RECOVER

DATE (*) RECOVER TOCOPY * REORGCHECK DELETE NO

zurück- COPY FULL YES CHECK DELETE YES RECOVERgesetzt SHRLEVEL

REFERENCE

andere LOAD REPLACE CHECK DELETE NO LOAD REPLACERESET- LOG YES LOAD REPLACEMöglichk. REORG LOG YES ENFORCE

CONSTRAINTSDROP TABLE

Ausnah- REPAIR SET REPAIR SET REPAIR SETme NOCOPYPEND NOCHECKPEND NORCVRPENDRESET

-START DATABASE ( ) SPACENAM ( ) ACCESS ( FORCE )befreit den TS aus allen 3 Status und anderen Restriktionen



3. Performanceverbesserungen an Utilities

Die Utility-Performance spielt insbesondere bei folgenden Dienstprogrammen eine Rolle:

LOAD und REORG: Hier gibt es die neuen Optionen SORTKEYS, PREFORMAT, NOSYSREC

RECOVER INDEX: Reduktion der Pfadlänge in der UNLOAD-Phase reduziert die CPU-Zeit

RUNSTATS: Die neue Funktion "sampling" reduziert die Verarbeitungsanforderungen bei derSammlung von Statistiken üner "non-indexed" Spalten.

COPY: CHANGELIMIT Option zur Bestimmung ob FULL oder INCREMENTAL Copyerfolgen soll

Online REORG: SHRLEVEL Option zur Bestimmung welche Art von Zughriffen während desREORG zugelassen werden sollen.

3.1 PREFORMAT

Um unbenutzte Pages in einem neuen TS vorzuformatieren sollte die Option PREFORMAT benutztwerden.Die Option PREFORMAT kann im LOAD und/oder REORG Utility spezifiziert werden:

ð LOAD

− LOAD DATA PREFORMAT INTO TABLE <tname>

− LOAD DATA INTO TABLE <tname> PART 1 PREFORMAT

ð REORG

− REORG TABLESPACE <tsname> PREFORMAT

− REORG INDEX <ixname> PREFORMAT

− REORG TABLESPACE <tsname> PART 1 PREFORMAT

− REORG INDEX <ixname> PART 1 PREFORMAT

Nach dem LOAD bzw. derm REORG Utility werden so alle "unused pages" vorformatiert. DB2 beginntdabei mit der höchsten RBA + 1 bis zur höchstmöglichen RBA für diesen Datenbereich.

Beim INSERT werden neue Datenpages vor ihrer Nutzung vorformatiert. Diese Formatierung erfolgt inBlöcken, je nachdem wieviele "poages" benötigt werden.

Insbesonders bei INSERT-intensiven Applikationen, kann man über den PREFORMAT-Parameter Zeitsparen, da die "pages" vor dem INSERT nicht mehr formatiert werden müssen.

3.2 SORTKEYS

Die Verwendung von SORTKEYS vermeidet das Schreiben der extrahierten Schlüssel auf SYSUT1 oderSYSOUT "data sets". Stattdessen werden sie im Speicher an den SORT-Prozess übergeben.



Dies geschieht wie folgt:

ð LOAD

− LOAD DATA SORTKEYS <estimate> INDO TABLE <tname>

ð REORG

− REORG TABLESPACE <tsname> SORTKEYS

<estimate> beschreibt die Anzahl Schlüssel, die in diesem Job sortiert werden sollen. Die Angabe wirdan doe SORT-Funktion weitergeleitet, um so eine effiziente Zuweisung von Speicher und Arbeitsberei-chen zu ermöglichen. Fehlt die Angabe oder ist sie 0, dann schreibt das Utility die extrahierten Schlüsselwährend der "reload"-Phase auf SYSUT1, so als ob SORTKEYS nicht angegeben wäre. Dann ruft esvdie SORT-Pahse auf und danach werrden sie an die "build phase" im Speicher gegeben. In diesem Fallist der Performancegewinn halb so groß, wie bei der Angabe eines <estimate> - Wertes, da die I/O's aufSYSUT1 nicht vermieden werden können.

Obwohl aber SORTKEYS bedeutet, daß die Datasets SYSUT1 / SYSOUT nicht benutzt werden sollen,müssen sie trotzdem zugewiesen werden, da sie für Verarbeitungsfehler benötigt werden.

Der <estimate>-Parameter ist für REORG nicht erlaubt, da der REORG die richtige Größe der Bereichewährend der "unload"-Phase ermittelt; d.h. wenn SORTKEYS beim REORG angegeben wurde, dannwird weder SYSUT! noch SYSOUT benutzt.

Die Unterschiede der Verarbeitung mit und ohne SORTKEYS sind in den folgenden Bildern veranschau-licht:

LOAD DATA INDDN PERSONALINTO TABLE SKRAUS.PERSONAL

1. Während der "reload"-Phase werden die Daten in den TS geladen. Die Schlüssel werdenextrahiert und in SYSUT1 geschrieben.

2. Die SORT-Phase beginnt3. Die SORT-Phase besteht aus 5 Schritten ( (a) bis (e) )4. Die "build"-Phase liest die sortierten Schlüssel von SYSOUT und baut den Index auf.

Phase Verarbeitung

1. „reload“ reload

23. SORT ( a ) SORT Init

( b ) Records In( c ) SORT( d ) Records Out( e ) SORT Term

4. Build build

SYSUT1

SORTOUT

Für LOAD FKin der ENFORCE Phase gelesen



LOAD DATA REPLACE INDDN INPUTSORTKEYS 66000INTO TABLE SKRAUS.ABTEILUNG

1. Zu Beginn der "reload"-Phase wwird eine "subtask" gestartet, die die Verarbeitung derSchlüsselsortierung kontrollieren soll. Sie initialisiert und wartet auf die "Haupt-Task", umdie Schlüssel an den SORT übergeben zu können.

2. Die "Reload"-Phase lädt die Daten in den TS, extrahiert die Schlüssel und übergibt sie inden Speicher zum Sortieren.

3. Am Ende der "Reload"-Phase, wird der letzte Schlüsselwert übergeben und der Sortvorgangwird komplettiert.

4. Der SORT übergibt die sortierten Schlüssel zur "build"-Phase, wo die Indizes aufgebaut werden.

3.2.1 Vorteile

1. "keys" werden im Speicher sortiert, anstatt auf einen Zwischenspeicher geschrieben zu werden.

2. Die "elapsed time" vom Start der "reload"-Phase bis zum Ende der "build"-Phase wird reduziert.

3.2.2 Überlegungen

Ist SORTKEYS angegeben, so kann er im Falle eines ABEND entweder in der "reload"-, "sort"- oder der"build"-Phase ohne zusätzlichen "dataset" vom Anfang der "reload"-Phase wieder gestartet werden.

Ohne Angabe von SORTKEYS, überprüft der LOAD jeden extrahierten Schlüssel auf SYSUT1, ob er nochin der Sortierreihenfolge liegt. Sind die Schlüssel in sortierter Reihenfolge, wird die SORT-Phaseübergangen. Nicht so bei der Angabe von SORTKEYS; d.h. ein LOAD, der keine SORT-Phase benötigtist für den Einsatz des Parameters SORTKEYS nicht geeignet.

Ähnlich verhält es sich mit REORG's auf Tabellen mit "clustering index", da auch der REORG dieSortierung übergeht, falls sie unnötig erscheint.

SORTKEYS ist nicht erlaubt für SYSDBASE, SYSDBAUTH, SYSPLAN und SYSVIEWS in DSNDB06.

Phase Verarbeitung

1. Haupt-task Sub-TaskSORT Init

2. „reload“ reloadRecords In

3. SORT Sort

Records Out

4. Build buildSORT Term

FK in der ENFORCE Phase gelesen



3.3 COPYDDN und RECOVERDDN

Die Angabe von COPYDDN zeigt an, daß ein "full image copy" gezogen werden soll, während ein LOADREPLACE oder ein REORG Utility laufen. Man nennt diesen Vorgang "inline copy".

Die Syntax lautet:

ð LOAD

− LOAD DATA REPLACE COPYDDN <ddname> INTO TABLE <tname>

− LOAD DATA INTO TABLE <tname> PART <n> REPLACE COPYDDN <ddname>

ð REORG

− REORG TABLESPACE <tsname> COPYDDN <ddname>

Zur Bearbeitung der Ausgabedaten aus einem "inline copy" haben die Utilities DSN1COPY undDSN1PRNT eine neue Option: INLCOPY.

Wird eine LOAD / REORG Operation ausgeführt, so kann man entscheiden, ob man die Änderungenaufzeichnen will oder nicht: LOG YES oder LOG NO. LOG NO spart Ausführungszeit, führt aber dasObjekt in den Status "copy pending".

Anmerkung:Auch wenn LOG NO angegeben wurde, so passiert "logging" während der"build" Phase, falls ein Typ 2 "non-partitioning index" existiert und einparalleler Zugriff auf eine ander Partition desselben TS erfolgt.

Um die Zeit, für die ein DB2-Objekt als nicht verfügbar gekennzeichnet wird, möglichst kurz zu halten,verwendet man dei neue Funkition COPYDDN. Damit wird ein "full image copy" während der LOAD /REORG Laufzeit erzeugt und das DB2-Objekt erhält nicht den Status "copy-pending", egal ob LOG YESgesetzt wurde oder nicht.

Anmerkung:... ein "inline copy" ist ungültig, wird die betroffene TS oder Partition nicht mitREPLACE bearbeitet.



• wird das Komprimierungsdictionary über LOAD neu erzeugt, erscheinen die Dictionary -Pages zweimal im "dataset", wobei das zweite Set die korrekte Version darstellt.

Der SYSCOPY-Satz für einen "inline copy" enthält ICTYPE=F und SHRLEVEL=R

DSN1COPY und DSN1PRNT verarbeiten "inline copies" wie "full image copies" mit folgenden Unter-schieden:

• Schlüsselwort INLKEY muß spezifiziert sein

• DSN1COPY kann mit oder ohne OBIDXLAT und RESET einen TS aus einem "inline copydataset" laden

• beim Druck aus einem "inline copy dataset" werden alle Instanzen gedruckt. Die letzte ist diekorrekte Instanz.

Anmerkung:... "Image copies", die während eines LOAD REPLACE erstelltwurden sind nicht empfehlenswert für RECOVER TOCOPY. Nichtkorrigierte Verletzungen von "unique indexes" und RI-Bedingungenkönnen im "image copy" vorkommen.

3.3.2 Bemerkungen zum "inline copy"

Messungen zeigen, daß die "inline copy"-Funktion die Zeit der Nichtverfügbarkeit eines DB2-Objektesbei REORG oder LOAD um 16,6% reduzieren kann.

3.3.1 Überlegungen zum "inline copy"

Der Dataset aus dem "inline copy" ist nicht exakt derselbe wie der Dataset aus dem "image copy", derbeim normalen COPY-Utility erzeugt wird:

Logisch ist dieser DS equivalent zu einem "full image copy" mit SHRLEVEL REF. Dennoch unterschei-den sich die Daten in bestimmten Bereichen:

• Datenpages können in falscher Reihenfolge oder auch mehrfach vorkommen. Kommen"pages" mehrfach vor, gibt es immer eine korrekte Kopie.

• "space map pages" können in falscher Reihenfolge oder auch mehrfach vorkommen.



3.4. RECOVER INDEX

DB2 V4 führte eine Verbesserung ein, die es zuließ, über die Angabe REORG SORTDATA UNLOADCONTINUE, mit verringertem CPU-Aufwand, zum Zeitpunkt der "unload" Phase, "rows" aus einer "page"und Schlüssel aus Indizes zu extrahieren.

Die Funktion RECOVER INDEX in DB2 V5 nutzt dieselbe Technik, um in der "unload"-Phase CPU-Zeitzu sparen.

Der RECOVER INDEX ALL ohne Zuweisung von SYSUT1 im Vergleich zu einem Vorgang mit SYSUT1spart ca. 11% CPU-Zeit und ca. 27% "elapsed time"



3.5. COPY

Die Änderung zum Utility COPY stellt sich dar in der Verwendung der Option CHANGELIMIT. Damit kannman Informationen über TS, Partition, ein "data set" oder eine Liste von derartigen Objekten erhalten.Dabei wird die Information zum Image Copy gesammelt und in einer eigenen Phase des COPY-Utilityaufgezeichnet.

Die Informationen des Reports bestehen aus:

• Gesamtzahl der verarbeiteten Pages, inklusive der vorformatierten Pages, die leer seinkönnen. Diese Pages wurden kopiert, wenn ein "full image copy" durchgeführt wurde.

• Die Anzahl von leeren Pages, falls der TS segmentiert ist.

• Die Anzahl geänderter Pages. Diese Zahl zeigt die kopierten Pages für einen "incrementalimage copy".

• Die Prozentzahlen zu den geänderten Pages

• Die Art des empfohlenen "image copy"-Verfahrens.

Ist TABLESPACE angegeben, wird die IC-Information für jede Partition ausgegeben (1), sowie für jedes"dataset", wenn die Tabelle nicht partitioniert ist (2) und für den betroffenen TS (3).

Man kann allerdings auch REPORTONLY zusammen mit CHANGELIMIT spezifizieren, wobei DB2 kein"image copy" erstellt, sondern nur den Report produziert. Ebenso reagiert DB2, wenn die für den "imagecopy" erforderliche DD-Zuweisung in der JCL nicht erfolgt oder DD DUMMY für das "image copy" Datasetangegeben wurde.

3.5.1 Die COPY CHANGELIMIT Option und Report

Angenommen es gibt einen PCCSKR1 in der DBSKR_001. Will man den TS prüfen, um festzustellenob "space map pages" defekt sind, oder ob irgendwelche andere Probleme existieren, die einenerfolgreichen "image copy" verhindern, z.B. ein "recovery pending"-Status. Zudem kann man die AnzahlÄnderungen auf dem TS seit dem letzten "image copy" feststellen.

Auf diesen TS kann man einen "incremental IC" fordern, wenn die Anzahl geänderter Pages zwischen10 und 40% liegt. Bei mehr als 40% geänderter Pages seit dem letzten IC soll ein "full IC" erfolgen.

Ein Beispiel für eon COPY-Statement, mit dem dies erreicht werden kann, kann wie folgt aussehen:



COPY TABLESPACE DBSKR_001.PCCSKR1 CHANGELIMIT( 10, 40 ) REPORTONLY

Report:

DSNU000I DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = RPTODSNU050I DSNUGUTC - COPY TABLESPACE DBSKR_001.PCCSKR1

CHANGELIMIT( 10, 40 ) REPORTONLYDSNU440I DSNUBCHG - IMAGE COPY INFORMATION

4KB EMTY CHANGED PERCENT OFDBNAME TSNAME DSNUM PAGES PAGES PAGES CHANGED PAGES ICTYPE----------------------------------------------------------------------------------------------------------------------------DBSKR_001 PCCSKR1 ALL 64 5 25 39.0 I

DSNU443I DSNUBCHG - INCREMENTAL CHANGE LIMIT METDSNU010I DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=2

Der Report zeigt, daß es keine defekten Pages in diesem TS gibt und daß die Anzahl geänderter Pagesseit dem letzten IC-Lauf größer ist als der minimale und der maximale Wert in CHANGELIMIT (10, 40)ist, sodaß ein "incremental IC" empfohlen wird.

Die Return-Codes für CHANGELIMIT können sein:

1 erfolgreicher Lauf, und keiner der CHANGELIMIT-Werte wurde erreicht. IC wirdunterdrückt.

2 erfolgreicher Lauf, und der CHANGELIMIT-Wert für IIC wurde erreicht. IIC wirdempfohlen.

3 erfolgreicher Lauf, und der CHANGELIMIT-Wert für "full IC" wurde erreicht.Vollständiger IC wird empfohlen.

8 während der Report-Phase prüft der IC jede einzelne "space map page" aufInkonsistenzen. Existieren defekte Pages, so wird RC = 8 gesetzt.

Report:

4KB EMTY CHANGED PERCENT OFDBNAME TSNAME DSNUM PAGES PAGES PAGES CHANGED PAGES ICTYPE----------------------------------------------------------------------------------------------------------------------------DBSKR_001 PCCSKR1 1 INFORMATION CANNOT BE DETERMINEDDBSKR_001 PCCSKR1 2 32 5 23 71.88DBSKR_001 PCCSKR1 ALL INFORMATION CANNOT BE DETERMINED

DSNU441I DSNUBASP - BROKEN PAGE FOUNDDBNAME = DBSKR_001TSNAME = PCCSKR1DSNUM = 1PAGE = 00000001

DSNU010I DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=8



3.5.2 Automatisieren des Image Copy Prozesses

Heute wird man nicht mehr ohne weiteres IC's initiieren und damit Kosten verursachen. Die CHANGE-LIMIT Option eröffnet eine einfache, kosteneffiziente Möglichkeit, festzustellen, ob ein IC erforderlich istund welcher Art er sein muß - IC oder IIC. Über die Abfrage des Statuscode kann dann netschiedenwerden, ob ein "full image copy" oder ein "incremental image copy" gezogen werden soll.

Das folgende Beispiel zeigt die Automatisierung ab >= 20% geänderter Pages. Ansonsten erfolgt keinIC.

//COPYREPY EXEC PGM=DSNUTILB,PARM=$DB2K,COPYR$//SYSCOPY DD DUMMY//SYSIN DD * COPY TABLESPACE DBSKR_001.PCCSKR1 CHANGELIMIT( 20 ) REPORTONLY/*// IF (COPYREPT.RC=3) THEN MAKE A FULL IMAGE COPY/*//COPYFULL EXEC PGM=DSNUTILB,PARM=$DB2K,COPYR$//SYSCOPY DD HLQ.SICH280799,SPACE(CYL,(15,1)),DISP=(,CATLG)//SYSIN DD * COPY TABLESPACE DBSKR_001.PCCSKR1 FULL YES/*// ENDIF/*

Report:

DSNU000I DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = COPYRDSNU050I DSNUGUTC - COPY TABLESPACE DBSKR_001.PCCSKR1

CHANGELIMIT( 20 ) REPORTONLYDSNU440I DSNUBCHG - IMAGE COPY INFORMATION

4KB CHANGED PERCENT OFDBNAME TSNAME DSNUM PAGES PAGES CHANGED PAGES ICTYPE----------------------------------------------------------------------------------------------------------------------------DBSKR_001 PCCSKR1 1 192 57 29.69DBSKR_001 PCCSKR1 2 192 30 15.63DBSKR_001 PCCSKR1 ALL 384 87 22.73

DSNU443I DSNUBCHG - FULL CHANGE LIMIT METDSNU010I DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=3

DSNU010I DSNUGUTC - OUTPUT START FOR UTILITY, UTILID=COPYFDSNU050I DSNUGUTC - COPY TABLESPACE DBSKR_001.PCCSKR1 FULL YESDSNU441I DSNUBBID - IMAGE COPY COMPLETE -

NUMBER OF PAGES = 384AVERAGE PERCENT FREE SPACE PER PAGE = 23.99PERCENT OF CHANGED PAGES = 22.73ELAPSED TIME = 00:00:09

DSNU010I DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0



3.6. RUNSTATS

DB2 Version 5 bietet eine Schätzfunktion zur Performanceverbesserung für die Verwendung von "non-indexed"-Spalten. Hierfür kann man eine %-Zahl definieren, die die Anz6ahl "rows" einer Tabellebeschreibt, die zur Kalkulation herangezogen werden soll. Zusätzlich dazu kann man mit DB2 V5Statistiken über die Zusammensetzung der Schlüsselspalten sammeln. Dies alles, um die Perfor-mance von Queries, die "correlated columns" im Prädikat verwenden, zu verbessern.

Folgende 3 Schlüsselworte steuern die neuen RUNSTATS-Optionen:

• SAMPLE bestimmt den Prozentsatz von "rows", die berücksichtigt werden sollen, um"non-indexed columns"-Statistiken zu erstellen.

• KEYCARD sammelt die Kardinalitäten der Konkatenation von Indexspalten, beginnendmit der ersten Indexspalte.

• FREQVAL steuert die Ermittlung von Statistiken über Häufigkeiten mittels:

à NUMCOLS als Angabe der Anzahl von Schlüsselspalten, die bei der Ermittlungvon Nutzungshäufigkeiten eines Index, zusammengefaßt werden sollen

à COUNT als Anzahl von zu sammelnden Nutzungshäufigkeitswerten

3.6.1. Gründe für die Nutzung des RUNSTATS-Utility

Das Utility RUNSTATS sammelt statistische Informationen über die Eigenheiten der Daten in TS undIndex und schreibt diese Werte in den Katalog. Es gibt zwei Arten von RUNSTATS: RUNSTATSTABLESPACE - er sammelt Informationen über TS und Indizes - und RUNSTATS INDEX: Hier werdenausschließlich Statistiken über Indizes gesammelt.

Der DB2 Optimizer nutzt diese Information, um den Zugriffsweg und die Zugriffsart zu den Daten zubestimmen - ACCESSPATH-Option.

Der Optimizer nutzt Filter, um aufgrund von Prädikat, Operator und den Statistiken, den besten Zugriffs-weg zu den DB2-Daten zu eruieren. Sollte noch nie ein RUNSTATS gelaufen sein, nutzt der Optimizer"default"-Einstellungen zur Optimierung. Diese führen zwangsläufig zu schlechter Performance.

Entsprechend sind die Empfehlungen für den Einsatz von RUNSTATS:• nach dem Laden einer Tabelle

• nach dem REORG einer Tabelle oder eines Index

• nachdem ein Index physisch neu erstellt wurde

• nach extensiven INSERT, UPDATE und DELETE Aktivitäten

• nach RECOVER TABLESPACE oder RECOVER INDEX Aktivitäten

Je mehr Statistiken verfügbar sind, umso größer ist die Chance, daß derOptimizer denbestmöglichen Zugriffspfad auswählt. Dennoch: Die CPU-Zeit zur Erstellung der Statistiken muß in einem vernünftigen Verhältniszum Nutzen der neuen Statistiken stehen!



3.6.2. Änderungen auf die Katalog-Tabellen

Die "integer"-Datentypen in den Katalogtabellen, die die Kardinalitäten darstellen, wurden in FLOAT-Datentypen migriert. Der Migrationsprozess kopiert die "alten" auf die "neuen" Spalten.Bei "large tables" werden nur die "neuen" Spalten gefüllt. Bei allen anderen Tabellen werden beideSpalten versorgt.

Der RUNSTATS nutzt ab DB2 V5 nur noch die "neuen" Statistikspalten.

Die neuen Spalten haben folgende Entsprechungen:

Tabellenname Originalname d. Spalte Name der migrierten Spalte

SYSCOLDIST FREQUENCY FREQUENCYFSYSCOLDISTSTATS FREQUENCY FREQUENCYFSYSCOLUMNS COLCARD COLCARDFSYSINDEXES FIRSTKEYCARD FIRSTKEYCARDF

FULLKEYCARD FULLKEYCARDF

3.6.3. Schnellerer RUNSTATS mit "sampling"

"sampling" wird benutzt, um Statistiken über "non-indexed"-Spalten ohne zu hohen CPU-Verbrauch zuerhalten. RUNSTATS "sampling" betrifft die Ermittlung von Spaltenstatistiken, die nicht die erste Spalteeines Index und weder in den Spalten HIGH2KEY, LOW2KEY und COLCARD in SYSIBM.SYSCOLUMNSnoch in den Spalten HIGH2KEY, LOW2KEY in SYSIBM.SYSCOLSTATS zu finden sind. Der Optimizernutzt diese "sampling"-Statistiken, wenn zu zusätzlichen Statistiken über Nutzungshäufigkeiten keiner-lei Werte gefunden werden. In diesem Fall hat der Optimizer bereits entschieden, daß es keinennutzbaren Eintrag in der SYSIBM.SYSCOLDIST gibt, weil

• Die Spalte nicht die erste im Index ist

• Die Spalte zwar die erste Spalte im Index ist, aber die Daten sind gleichmäßig durch dieseSpalte verteilt

• Die Spalte zwar die erste Spalte im Index ist, aber RUNSTATS ist noch nicht gegen den Indexgelaufen

Statistiken in der SYSCOLDIST können auch aus anderen Gründen als nicht relevant eingeschätzt sein,z.B. bei einem fehlerhaften manuellen Update der Statistiken.

DB2 V5 ermöglicht es, mittel des optionalen Schlüsselworts SAMPLE den %-Satz von "rows" proTabelle zu bestimmen, der die Kalkulationen der "non-indexed columns" begrenzen soll. Der Wert kannzwischen 1 und 100 liegen: Default ist 25 (%).

Die folgenden Beispiele zeigen sie Verwendung von SAMPLE:

25% "sampling":RUNSTATS TABLESPACE(DBSKR_001.PCCSKR1) TABLE (PERSONAL) SAMPLE

10% "sampling":RUNSTATS TABLESPACE(DBSKR_001.PCCSKR1) TABLE (PERSONAL) SAMPLE 10



Faktoren, die den CPU-Verbrauch von RUNSTATS beeinflussen:

• Anzahl "rows" in der Tabelle

• der %-Satz für "sampling"

• Anzahl der Spalten für das "sampling"

• Spaltenlänge

• Eindeutigkeit der Spalten

Faktoren, die die Genauigkeit eines Zugriffspfads beeinflussen:

• Anzahl "rows" in einer Tabelle

• der %-Satz für "sampling"

• Eindeutigkeit der Spalten

Die Genauigkeit der gesammelten Statistiken wird umso grösser sein, je höher die Anzahl der Sätze ist,die zum "sampling" herangezogen werden.

3.6.4. Messungen zum RUNSTATS mit "sampling"

Hier sollen folgende Szenarien untersucht werden:

• ein "large partitioned TS"

• die "Database A": mit Tabellen mit Millionen von langen Sätzen und VARCHAR-Daten

• die "Database B": mit Tabellen, die kleiner sind als die der "Database A", weniger Zeilenhaben und keine VARCHAR-Felder besitzen. Die Spaltendaten sind außerdem mehr"eindeutig".

Als weitere Randbedingung gilt: Die Queries der "Database A" sind komplex mit "joins" undSortiervorgängen, die der "Database B" sind einfacher mit weniger "joins".

Die Statistiken, beim "sampling" für einen "large PTS":

SAMPLE X% RUNSTATS CPU RUNSTATS CPU RUNSTATS CPU-DeltaSAMPLE X% SAMPLE 100% (%) <-> 100% (in sec)

100 315 - - 80 279 -36 -11 60 245 -70 -22 50 229 -86 -27 40 212 -103 -33 20 179 -136 -43 10 161 -154 -49 5 154 -161 -51

Formel für die Einsparung: % CPU Erparnis = (100 - x) * 0,55



Die Statistiken, beim "sampling" für die "Database A":


100 1445 - - 75 1229 -216 -15 50 1013 -432 -30 40 925 -520 -36 20 750 -695 -48 10 661 -784 -54 5 615 -830 -57


Ergebnisse bei der Ausführung der Query, beim "sampling" für die "Database A":für einen "nested-loop join" über sieben Tabellen

SAMPLE X% QUERY ELAPSED QUERY ELAPSED QUERY ELAPSEDSAMPLE X% Delta auf Delta (%) mit

SAMPLE 100% SAMPLE 100% (in sec)

100 73 - - 20 73 0 0 10 75 +2 +3 5 102 +29 +40 1 818 +745 +1020 * A 834 +761 +1042

*A heißt, daß kein RUNSTATS auf die Tabelle erfolgte.

Das Beispiel zeigt, daß bei einer "sampling" Rate von 10% ansprechend gute Query-Laufzeiten zuerzielen sind. Ab einer 5%igen "sampling"-Rate wird die Query-Zeit schlecht.

Ergebnisse bei der Ausführung der Query, beim "sampling" für die "Database A":für einen "merge-scan join" über zwei Tabellen mit Sort für DISTINCT

SAMPLE X% QUERY ELAPSED QUERY ELAPSED QUERY ELAPSEDSAMPLE X% Delta auf Delta (%) mit

SAMPLE 100% SAMPLE 100% (in sec)

100 228 - - 20 229 +64 +27 10 314 +86 +38 5 310 +82 +36 1 314 +86 +38 * A 388 +160 +70

*A heißt, daß kein RUNSTATS auf die Tabelle erfolgte.



Das Beispiel zeigt, daß bei einer "sampling" Rate von 20% akzeptable Query-Laufzeiten zu erzielen sind.Der "worst case" ist bei fehlendem RUNSTATS zu erkennen. Der Unterschied zum 1%-"sampling" istallerdings nicht sehr groß.

Die Statistiken, beim "sampling" für die "Database B":


100 36.3 - - 80 33.5 -2.8 -8 50 28.3 -8.0 -22 20 24.1 -12.2 -34 10 22.6 -13.7 -38 5 20.9 -15.4 -42 1 20.0 -16.3 -45


Beim Test von ca. 60 Queries zeigt sich in dieser DB-Type, daß der Zugriffspfad und seine Effizienzbezüglich der "sampling" - Rate nur wenig variieren. Nur bei einer "sampling" Rate von 1% werdenschlechte Query-Laufzeiten erzielt. Erklärbar ist dies über die geringere "join"-Aktivität der eingesetztenQueries und die Absenz von zusätzlichen Prädikaten.

Resümmeè:

1. Am meisten CPU-Aufwand wird beim "sampling" dann gespart, wenn dieDatenbank groß ist und VARCHAR-Spalten vorkommen bzw. die Spaltenwenig eindeutig sind. In diesem fall kann bis zu 45% CPU bei einer "sampling"-Rate von 25% eingespart werden.

2. RUNSTATS "sampling" mit 1% ist immer dann nützlich, wenn es darum geht,die "default"-Statistiken zu umgehen und keinerlei Statistiken für "non-indexed"-Spalten existieren.

3. "sampling" ersetzt keinesfalls erfolgreiche "matching index scans" mit guteinschränkenden Prädikaten oder einem gezielten "TS scan".

4. Eine Empfehlung ist die Nutzung von RUNSTATS "sampling" für Datenbanken,für die niemals Statistiken über "non-indexed" Spalten gesammelt wurden. Esscheint sinnvoll mindestens 1%-"sampling" zu versuchen, besser ist eine"sampling"-Rate mit 10% oder dem Optimum von 20%.



3.6.5. Korrelationsstatistiken

Das Utility RUNSTATS sammelt auch statistische Informationen über sogenannte "correlated keycolumns". Es gibt hierzu zwei Parameter für den RUNSTATS: KEYCARD und FREQVAL:

KEYCARD

veranlaßt das System die Kardinalitäten jeder Spalte und aller anhängigen Spalten zu sammeln.

Beispiel: Das folgende Control-Statement läuft auf einen Index (XSKR_01) aus 4 Spalten underzeugt folgende Kardinalitäten:

RUNSTATS INDEX (DB2CC01.XSKR_01) KEYCARD

• Erster Schlüssel (FIRSTKEYCARDF), gespeichert in SYSIBM.SYSINDEXES undSYSIBM.SYSINDEXSTATS

• Zusammenfassung der ersten und zweiten Schlüsselspalte, gespeichert inSYSIBM.SYSCOLDIST und SYSIBM.SYSCOLDISTSTATS

• Zusammenfassung der ersten, zweiten und dritten Schlüsselspalte, gespeichert inSYSIBM.SYSCOLDIST und SYSIBM.SYSCOLDISTSTATS

• Zusammenfassung der ersten, zweiten,dritten und vierten Schlüsselspalte(FULLKEYCARDF), gespeichert in SYSIBM.SYSINDEXES und SYSIBM.SYSINDEXSTATS

MERKE:Es gibt keinen Wert, der KEYCARD für einen Index aus zwei Spaltenbeschreibt. RUNSTATS INDEX sammelt diese Information inFIRSTKEYCARDF und FULLKEYCARDF als "default".

FREQVAL

kontrolliert die Sammlung von Statistiken über Nutzungshäufigkeiten. Wird dieses Schlüssel-wort angegeben, so werden zwei weitere Schlüsselworte obligatorisch: NUMCOLS und COUNT.

Beispiel: Um Statistiken für 15 Werte über die Nutzungshäufigkeit auf den ersten drei Spalten aisdem aus 5 Spalten zusammengesetzten Index (XSKR_05) zu erhaltenist folgendes Kontroll-Statement zu formulieren:

RUNSTATS INDEX (DB2CC01.XSKR_05)FREQVAL NUMCOLS 3 COUNT 15

• NUMCOLS zeigt an, wieviele Spalten des zusammengesetzten Schlüssels untersuchtwerden sollen, wenn Statistiken gesammelt werden. 3 bedeutet, daß Nutzungsstatistikenüber die ersten drei Indexsspalten gesammelt werden. Der "default" ist 1.

• COUNT beschreibt dei Anzahl von häufig genutzten werten, über die Statistiken angelegtwerden sollen. 15 heißt, daß die Statistiken für die 15 am meisten genutzten Wertegesammelt werden sollen. Der "default" liegt bei 10.

Spezifiziert man den Parameter KEYCARD, dann sammelt RUNSTATS auch Statistiken über Nutzungs-häufigkeiten für die 10 am häufigsten genutzten Schlüsselwerte auf die erste Index-Spalte.



Wird zusätzlich FREQVAL angegeben, dann sammelt das Utility die Statistiken alleine betreffend derZusammenstezung der Schlüsselwerte gemäß NUMCOLS. Die Werte bleiben nach dem Eintrag imKatalog und können mit der Zeit inaktuell werden.

Um dies zu verhindern, muß man FREQVAL-Werte für jede NUMCOLS - Angabe mitgeben. Beispiel: UmStatistiken für 10 häufig genutzte Werte auf der ersten Schlüsselspalte zu erhalten, sollte man 20 häufiggenutzte Werte auf die ersten zwei Schlüsselspalten und 50 häufig genutzte Werte auf die ersten dreiSchlüsselspalten anfordern:

RUNSTATS INDEX (DB2CC01.XSKR_05)FREQVAL NUMCOLS 1 COUNT 10FREQVAL NUMCOLS 2 COUNT 20FREQVAL NUMCOLS 3 COUNT 50

Die Nutzung von RUNSTATS mit NUMCOLS überschreibt alle vorangegangenen Statistiken im Katalogfür die betroffenen zusammengesetzten Index-Werte.

3.6.5.1 Korrelationsstatistiken - Empfehlung

KEYCARD und FREQVAL sollten genutzt werden,

• bei Korrelationen in den Schlüsseln, die aus mehr als einer Spalte bestehen und Queriesmit weniger als allen Spalten im "=" - Prädikat

• bei Indizes mit drei oder mehr Schlüsselspalten

• bei Korrelationen in den Schlüsseln, deren Werte in der oder den ersten Spalte(n) gleichsind bzw. eine niedrige Kardinalität besitzen solle mit Korrelationsstatistiken gearbeitetwerden.

Beispiel:

LANDKZ MANDAN´TEN_NR GUELTIG_DAT_VON ID .....

D 001 01.01.1999 12345D 001 01.01.1999 23456D 001 01.01.2000 23456D 002 01.01.1999 12345D 002 01.10.2000 23456......... .........

Man sollte auch von Zeit zu Zeit die Größe der SYSSTATS Katalogtabelleüberprüfen, damit diese aufgrund der gezogenen Statistiken nicht volläuft.



3.6.5.2 Spalten für die Korrelationsstatistiken

Seit DB2 V5 sind einige Katalogtabellen und -spalten neu strukturiert worden, um auch Korrelations-statistiken aufnehmen zu können.

Die Statistiken stehen in den Katalogtabellen SYSIBM.SYSCOLDIST und SYSIBM.SYSCOLDISTSTATS.

Spaltenname Datentyp Bedeutung

NAME VARCHAR(18) Name der Spalte. Ist NUMCOLUMNS> 1, dann identifiziert diese Spal-te die erste Spalte eines zusammen-gesetzten Schlüssels

TYPE CHAR(1) NOT NULL Typ der Statistiken:DEFAULT 'F' C = Kardinalität (KEYCARD)

F = Nutzungshäufigkeit (FREQVAL) oder "default"

CARDF FLOAT NOT NULL Anzahl unterschiedlicher WerteWITH DEFAULT -1 für eine Spaltengruppe (KEYCARD)

COLGROUPCOLNO VARCHAR(254) NOT NULL Identifiziert die Spaltengruppe,WITH DEFAULT für die diese Statistik gilt.

Bei einzelnen Spalten ist 0eingetragen.Ansonsten ist das Feld ein"array" von SMALLINT Spalten.

NUMCOLUMNS SMALLINT NOT NULL Anzahl Spalten in der Spalten-WITH DEFAULT -1 gruppe für die die Statistik

gilt.

FREQUENCYF SMALLINT NOT NULL Eine Zahl, die multipliziertWITH DEFAULT -1 mit 100 die %-Zahl der "rows"

ergibt, die den Wert in derSpalte COLVALUE enthalten;(0,153 bedeutet 15,3%)

COLVALUE VARCHAR(254) NOT NULL enthält den Wert der Spalte, fürWITH DEFAULT die die Nutzungshäufigkeiten-

statistik gilt.Dies ist ein "string" von Spal-tenwerten für eine "row" vomTyp "F" mit NUMCOLUMNS > 1Die Daten sind nicht druckbarwegen der enthaltenen "non-CHAR" Datentypen(!).



3.7. Online REORG

Die Änderung zum Utility REORG in der DB2 Version 5 enthalten gravierende Verbesserungen zurvorangegeangenen Version.

Über diese Option wird die Art des REORG eingestellt:

• Standard

• "read only online"

• "read-write online"

Diese drei Optionen existieren für die Reorganisation eines TS (automatisch mit allen Indizes), für dieReorganisation eines bestimmten Index und für die Reorganisation eine TS-Partition und des zugehö-rigen partitionierten Index:

• SHRLEVEL NONE(Standard REORG)

• SHRLEVEL REFERENCE ("read-only" Online-REORG)Diese Alternative erlaubt Applikationen Lesezugriffsberechtigung auf das Objekt, dasgerade reorganisiert wird - während der REORG läuft.

Der Prozess beinhaltet folgende Aktivitäten:

1. DB2 entlädt die Daten vom "alten" (Original) Datenbestand, sortiert die daten nach"cluster key" und lädt die Daten in den "neuen" (Shadow)-Datenbestand. DieAnwendung hat derweil Lesezugriffsmöglichkeiten auf das Original.

2. DB2 schaltet dann den Zugriff der Applikationen auf die "shadow"-Kopie, indem esdie betroffenen "datasets" - Tablespace und Indizes - umbenennt. Während desaktuellen Vorgangs des "switch" haben die Applikationen keinen Zugriff auf dieDaten.Wird dagegen nur eine Partition reorganisiert, so benennt DB2 lediglich die"datasets" für die Partition um und korrigiert für diese "datasets" die RID's für diezugehörige logische Partition.

3. DB2 gibt den Applikationen "read-write"-Zugriffsmöglichkeit.

• SHRLEVEL CHANGE ("read-write" Online-REORG)Diese Alternative erlaubt Applikationen Lese- und Schreibzugriffsberechtigung auf dasObjekt, das gerade reorganisiert wird.

Der Prozess beinhaltet folgende Aktivitäten:

1. DB2 zeichnet die laufende "Log Record Sequence Number" (LRSN) auf undentlädt die Daten vom "alten" (Original) Datenbestand, sortiert die daten nach"cluster key" und lädt die Daten in den "neuen" (Shadow)-Datenbestand. DieAnwendungen haben derweil Lese- und Schreibzugriffsmöglichkeiten auf dasOriginal und DB2 zeichnet die Aktivitäten im Log-File auf.

2. DB2 verarbeitet das Log-File, um das "shadow copy" zu aktualisieren. DieserVorgang erfolgt iterativ, indem mit jedem Iterationsschritt eine bestimmte Sequenz

3.7.1 Die Option SHRLEVEL



von Log-Sätzen verarbeitet wird. Die Anwendungen haben derweil Lese- undSchreibzugriffsmöglichkeiten auf das Original während jedes Iterationsschritts -den letzten ausgenommen. Während des letzten Iterationsschrittes haben dieApplikationen nur Leseberechtigung auf das Original.

3. DB2 schaltet dann den Zugriff der Applikationen auf die "shadow"-Kopie, indem esdie betroffenen "datasets" - Tablespace und Indizes - umbenennt. Während desaktuellen Vorgangs des "switch" haben die Applikationen keinen Zugriff auf dieDaten.Wird nur eine Partition reorganisiert, so benennht DB2 lediglich die "datasets" fürdie Partition um und korrigiert für diese "datasets" die RID's für die zugehörigelogische Partition.

4. DB2 gibt den Applikationen "read-write"-Zugriffsmöglichkeit auf das "shadowcopy".

3.7.2 Die "shadow datasets"

Der REORG mit SHRLEVEL REFERENCE und SHRLEVEL CHANGE benutzen "shadow"-Kopien derDaten die reorganisiert werden. Die verarbeitung dieser "shadow datasets" ist unterschiedlich, abhän-gig davon, ob DB23 die Objekte, die reorganisiert werden verwaltet oder nicht.

• "DB2 manged Objects"Im Falle, daß die zu reorganisierenden Objekte von DB2 verwaltet werden, erzeugt dasREORG Utility die "shadow datasets" für die Reorganisation automatisch. Die "shadowdatasets" werden in derselben Storage Group (STOGROUP) wie die zu reorganisieren-den Objekte angelegt. Auf den Platten für diese STOGROUP muß genug Platz verfügbarsein, um diese Objekte nochmal anlegen zu können. Während der "switch"-Phasebenennt der REORG den "shadow dataset" um auf die Originalnamen. Die Original-Datasets werden während der UTILTERM-Phase gelöscht.

• "User manged Objects"Die Nutzung von benutzerverwalteten Objekten beim REORG erfordert mehr manuelleUnterstützung. Die "shadow datasets" müssen vor Beginn der Reorganisation angelegtsein. Sie sollten als LINEAR VSAM-Datasets mit SHAREOPTIONS(3,3) definiert sein. Fürjedes REORG-Objekt muß es ein "shadow dataset" geben:

ð einen entsprechenden TS

– ein "shadow copy" für den TS

– ein "shadow copy" für jeden Index

ð eine oder mehr partitions des TS, der zu reorganisieren ist

– ein "shadow copy" für jede Partition im jeweiligen TS

– ein "shadow copy" für jede Partition eines jeden "partitioning Index"

– ein "shadow copy" für jede Partition eines jeden "non-partitioning Index"

Es gibt keine automatische Löschung von "user-managed " REORG-Datasets. Die zuweisung desPlatzes erfolgt über IDCAMS(PRIQTY und SECQTY), PCTFREE und FREEPAGE werden über denALTER-Befehl in DB2 eingestellt.



3.7.3 Die Phasen des Online REORG Utility

• Die "shadow dataset"-NamenskonventionenDer REORG erwartet bestimmte Dataset-Namen für die DB2-Datasets:

ð DB2 Standard Namen

<cat>.DSNDBx.<database>.<page>.<set>.I0001.A<nnn>

ð DB2 Namen für "shadow datasets" bei TS IX und Partitions

<cat>.DSNDBx.<database>.<page>.<set>.S0001.A<nnn>

ð DB2 Namen für "temporary datasets" bei TS IX und Partitions

<cat>.DSNDBx.<database>.<page>.<set>.T0001.A<nnn>

ð DB2 Namen für "shadow datasets" bei logischen Partitions eines "non-partitioned Index"<cat>.DSNDBx.<database>.<page>.<set>.S0<mmm>.A<nnn>

ð DB2 Namen für "temporary datasets" bei logischen Partitions eines "non-partitioned Index"<cat>.DSNDBx.<database>.<page>.<set>.T0<mmm>.A<nnn>

<mmm> ist die Partitionnummer der zu reorganisierenden Partition.

Der REORG durchläuft drei neue Phasen und erhielt einige Änderungen in der neuen Version, um die"online"-Aktivitäten unterstützen zu können.

• UTILINIT Initialisierung (unverändert).

• UNLOAD Entladen der Daten in ein "sequential dataset" (SYSREC). Die Datenwerden in der "clustering"-Reihenfolge sortiert, wenn ein "cluster"-Indexdefiniert ist und entweder SORTDATA oder SHRLEVEL CHANGE angege-ben wurde. Man kann NOSYSREC benutzen, um das Erstellen des Entla-de-"datasets" zu übergehen. Dies erhöht die Performance durch Verringe-rung von I/O's auf den Datasets. Für SHRLEVEL CHANGE ist NOSYSREC"default".

• RELOAD erneutes Laden der Daten aus der UNLOAD-Phase und extrahieren derIndexwerte zum Aufbau der Indizes. Wird der Prameter SORTKEYS ange-geben, so können die extrahierten Schlüsselwerte direkt im Speicherübergeben und parallel zur RELOAD-Phase sortiert werden. Dies reduziertdie "elapsed time" durch die Vermeidung von I/O's zusätzlich zum paralle-len "incore"-Sort. Für SHRLEVEL CHANGE ist SORTKEYS "default".Man kann den Parameter COPYDDN nutzen, um einen sogenannten"inline copy" während der RELOAD-Phase zu veranlassen. Dies ist optio-nal mit SHRLEVEL NONE und Voraussetzung in SHRLEVEL REFERENCEund SHRLEVEL CHANGE.

• SORT Sortieren der extrahierten Indexwerte. Ist die Option SORTKEYS angege-ben, so übergibt der SORT die Schlüsselwete im Speicheran die "BUILD"-Phase, ohne sie auf SORTOUT auszugeben. Dies vermindert die "elapsedtime".



• BUILD Baut die Indizes auf. Ist REORG TABLESPACE PART SHRLEVEL NONEspezifiziert, so korrigiert diese Phase auch die "logische Partition" eines"non-partitioning Index".

• LOG eine neue Phase in DB2 V5. Sie wird nur bei SHRLEVEL CHANGE ausge-führt und schreibt Log-Sätze für die "shadow copy". Dieser Schrit wirditerativ gestartet. Jede Iteration verarbeitet eine Log-Satz-Sequenz. Wäh-rend der letzten Iteration können Applikationen nur noch "read-only" auf dieDaten zugreifen.Sich ändernde "pages" werden dem "inline copy" angefügt. Während derRELOAD-Phase werden während der letzten Iteration zwei IIC gezogen -einer VOR dem "drain" der "Writer"-Prozesse und einer danach.

• SWITCH eine neue Phase in DB2 V5. Sie wird nur bei SHRLEVEL REFERENCE oderSHRLEVEL CHANGE ausgeführt und veranlaßt DB2 den Zugriff auf die"shadow copy" und die zugehörigen Indizes umzuschalten. Dieses"switching" wird durchgeführt über IDCAMS Rename und während dieserPhase können Daten nicht zugegriffen werden. Je mehr physische Datasetsalso IDCAMS zu verarbeiten hat, umso länger bleiben die Daten für dieApplikationen "nicht verfügbar".

• BUILD2 eine neue Phase in DB2 V5. Sie wird nur bei SHRLEVEL REFERENCE oderSHRLEVEL CHANGE ausgeführt und wenn das Objekt eine Partition einesPTS mit einem oder mehr "non-partitioned" Indizes ist. Während dieserPhase veranlaßt DB2 die Korrektur logischer Partitions in "non-partitioned"Indizes ohne sie insgesamt zu ersetzen. Dies, um "concurrent" REORG'sauf mehreren Partitions zu ermöglichen. Dazu erzeugt DB2 ein "shadowcopy" der logischen Partition.Während dieser Verarbeitung ist nur "read only" auf der logischen Partition,die korrigiert wird möglich. UPDATE ist nur auf anderen LP's möglich.INSERT und DELETE können nur auf Type 2 Indizes erfolgen.Dies ist die zeitraubendste Operation mit eingeschränktem Zugriff auf dieDaten. Man sollte also als Resultat aus dieser Erkenntnis versuchendiesen Prozess zu optimieren. Eine neue Option - PIECESIZE - im CREATEINDEX-Statement erlaubt die Aufteilung von "non-partitioned" Indizes inkleinere Teile und deren gleichmäßige Verteilung auf dem DASD-Gerät.Dies verhindert I/O-Blockaden und vermindert die "elapsed time" für dieRID-Korrekturen, und dies ist die Zeit, in der die Daten nicht verfügbar sind!

• UTILTERM ist auch bekannt ale "cleanup"- Phase in DB2. Hier werden die "DB2-managed"-Datasets wieder gelöscht.

3.7.4 Die Phasen des Online REORG und das Sperrverhalten

Die folgenden Bilder sollen das Verhalten des REORG in den unterschiedlichen Phasen und mit denverschiedenen Optionen verdeutlichen.

• SHRLEVEL NONE"default und identisch mit dem REORG in der DB2 Version 4.

Die UNLOAD-Phase ermöglicht "read"-Zugriffe auf die Daten (angezeigtüber DW = "Drain Writers"), während andere Phasen keinen Zugriff erlauben(kenntlich durch DA = "Drain All")



SYSREC, SYSUT1 und SORTOUT sind hier alle aufgeführt. Sie können über die ParameterNOSYSREC und/oder SORTKEYS vermieden werden.

• SHRLEVEL REFERENCEermöglicht "read-only" während des Online REORG

Die Lesemöglichkeit während der REORG-Phase ist ausgedehnt auf fast die gesamteLaufzeit des REORG (angezeigt über DW = "Drain Writers"). Lediglich während der"switch"-Phase ist jeglicher Zugriff auf die reorganisierten Objekte verboten (kenntlichüber DA = "Drain All").

Die Indizes werden beim REORG enders bearbeitet wie bei SHRLEVEL NONE. Da sie keinedirekte Rolle bei der Online Reorganisation spielen, können sie in einem Status "recoverypending" bleiben ohne die Reorganisation zu beeinflussen. Während der "switch"-Phasewerden neue Kopien erstellt.

UNLOAD RELOAD SORT BUILD

UTRO / DW UTUT / DA UTUT / DA UTUT / DA

DFSORTSYSREC SYSUT1 SORT- SORT-

WORK OUT

TS IX1 IX2

TS

UNLOADUTRO (DW)

RELOADUTRO (DW)

SORTUTRO (DW)

BUILDUTRO (DW)

SWITCHUTUT (DA)

TS TS

IX IX

IXTS

IX



Während der Ausführung des REORG Utilities verhindert Locks auf den Daten eine Durchfüh-rung eines "mass delete". Ist ein "mass delete" erforderlich, so werden nur die "space mappages" verändert.

Der REORG mit SHRLEVEL CHANGE hat drei neue Phasen. Die letzte neue Phase BUILD2korrigiert die Teile der "non-partitioned" Indizes beim REORG von partitionierten Tabellen. BeimREORG eines PTS bearbeitet die "switch"-Phase (über "rename", "dedrain" und "delete") die TSPartition - gekennzeichnet über TS Part N - und den betroffenen Teil des "partitioning" Index -erkennbar über IX Part N. Die BUILD2 Phase bearbeitet dann die logische Partition des "non-partitioned" Index durch den UPDATE der RID's. Während dieser Phase werden alle Objekte aufdieser logischen Partition (NPI LPART N) intern gesperrt ("drained") - DA = "Drain All".Lesen und UPDATE ist in anderen Partitions, die nicht reorganisiert werden erlaubt, nicht aberINSERT und DELETE.

• SHRLEVEL CHANGEermöglicht "read-only" während des gesamten Online REORG

Die Schreib- und Lesemöglichkeit während der REORG-Phase ist ausgedehnt auf diegesamte Laufzeit des REORG. Die "readr2 werden angenommen und somit "concurrentread/write" möglich (CR = "Claim Readers"). In der letzten Iterationsphase werden die"writer" gesperrt und admit sit nur noch "read-only" möglich (angezeigt über DW = "DrainWriters").Lediglich während der "switch"-Phase ist jeglicher Zugriff auf die reorganisierten Objekteverboten (kenntlich über DA = "Drain All").

TS

UNLOADUTRW (CR)

RELOADUTRW (CR)

SORTUTRW (CR)

BUILDUTRW (CR)

SWITCHUTUT (DA)

TS TS

IX IX

TS

IX

IXTS

IX

LOG

UTRW (CR) UTRO(DW)

MassenDelete

UNLOADUTRW (CR)

RELOADUTRW (CR)

SORTUTRW (CR)

BUILDUTRW (CR)

SWITCHUTUT (DA)

TSPart N

TSPart N

TSPart N

IXPart N IXPart N

IXPart N

LOG

UTRW (CR) UTRO(DW)

Switch Phase

1) Rename2) Dedrain3) Set UTRW

NPI1LPart N

Build2 Phase

1) RID Update2) Dedrain / UTRW

NPI1LPart 1bis n-1

NPI1LPart N

BUILD2



3.7.5 Die "mapping table"

Während der UNLOAD- und RELOAD-Phase nutzt das REORG Utility "mapping tables", um die RID's,die im Original genutzt werden auf die RID's im "shadow copy" abzubilden. UPDATE's auf dies Tabellewerden nicht im Log-File vermerkt; d.h. während dieser Phase ist ein Restart nicht möglich.

Die Korrektur der RID's beinhaltet 5 vVerarbeitungsschritte für jede Iteration:

1. Lesen der Log-Sätze2. Sortieren der Log_Sätze nach der alten RID3. Übertragen der alten auf die neue RID4. Sortieren der Log_Sätze nach der neuen RID5. Einfügen der Log-Sätze auf das "shadow copy"

Die "mapping table" ist eine DB2-Tabelle, die explizit in einem "segmented tablespace" angelegtwerden muß:

CREATE TABLESPACE maptable_TS SEGSIZE 4;

CREATE TABLE maptable(

TYPE CHAR (1) NOT NULL, SOURCE_RID CHAR (5) NOT NULL, TARGET_XRID CHAR (9) NOT NULL, LRSN CHAR (6) NOT NULL)IN maptable_TS;

CREATE TYPE 2 UNIQUE INDEX maptable_IX ON maptable( SOURCE_RID ASC, TYPE, TARGET_XRID, LRSN );

Der Zugriff zur "mapping table" erfolgt immer IX-Only. Die Anzahl "rows" in dieser Tabelle überschreitetselten die 110% der "rows" in der Tabelle / Partition, die reorganisiert werden soll.

Jede parallele Ausführung von REORG SHRLEVEL CHANGE sollte eine eigene "mapping table"zugewiesen bekommen. Ansonsten wird die Ausführung des Utility seriell erfolgen.

3.7.6 Die Ausführung eines Online REORG

Das folgende Beispiel zeigt einen typischen Online "read-write"-REORG:

REORG TABLESPACE QSE1312.maptable_TS COPYDDN(Local_Copy)RECOVERYDDN(Recover_Copy) SHRLEVEL CHANGEDEADLINE 1999-8-18-08.00MAPPINGTABLE maptableMAXRO 200LONGLOG DRAINDELAY 900



Das Beispiel enthält einige neue Kontroll-Statements:

• COPYDDN und RECOVERDDN ziehen "inline copies", einen für das lokale DBMS und einen fürdas "remote" DBMS.

• SHRLEVEL CHANGE erlaubt während der Online REORG-Phasen "read-write"-Zugriff.

• DEADLINE 1999-8-18-08.00 definiert die "deadline" für den Start der "switch"-Phase.

• MAPPINGTABLE enthält den Namen der "mapping table" für diese Reorganisation.

• MAXRO 200 bedeutet, dass das Zeit-Maximum für die letzte Iteration der Log-Sätze bei 200Sekunden liegt.

• LONGLOG DRAIN veranlasst das REORG Utility die "writer class" nach einer LONGLOGMeldung intern zu sperren. Dies geschieht, wenn der Log-Iterationsprozess dieApplikation(en), die auf die Log-File schreiben, nicht auffangen kann.

• DELAY 900 stellt die Zeitspanne dar, die das REORG Utility nach einer LONGLOG Meldungwartet, bis die internen Locks eingeschaltet werden.

3.7.7 Die Messungen beim Online REORG

Das folgenden Messungen basieren auf einem Online REORG auf einer 10-way 9672 mit 3390 DASD's:

Die Tabelle hat zwei Type 2 Indizes. Keine parallelen Updates. Die "cluster ratio" ist 100%. (AlleMessungen mit NOSYSREC und SORTKEYS und "inline copy")

SHRLEVEL NONE SHRLEVEL REFERENCE SHRLEVEL CHANGEZeit Sekunden Sekunden Delta % Sekunden Delta %

CPU 880 873 -0,8 970 +10

elapsed 856 961 +12.3 1242 +31

Das folgende Beispiel zeigt, dass sowohl die CPU-Zeit, als auch die "elapsed time"ansteigen, wenn die "cluster ratio" geringer ist: In diesem Beispiel 83%.

Die Tabelle hat zwei Type 2 Indizes. Keine parallelen Updates. Die "cluster ratio" ist 83%. (AlleMessungen mit NOSYSREC und SORTKEYS und "inline copy")

SHRLEVEL NONE SHRLEVEL REFERENCE SHRLEVEL CHANGEZeit Sekunden Sekunden Delta % Sekunden Delta %

CPU 838 825 -1,5 2869 +242

elapsed 820 921 +12.3 3049 +272



3.7.8 Die Empfehlungen zum Online REORG

Das Einfügen von "rows" in eine Tabelle am Ende eines TS verschlechtert die "cluster ratio" eines TS.Es erhöht die I/O Aktivitäten für das Wiederfinden und Lesen von Daten und kann zusätzliche "extents"im Dataset verursachen. Alle diese Faktoren beeinflussen die Effektivität - und nebenbei auch dieAntwortzeit - der Online Transaktionen.

In jedem Fall erhöhen parallel laufende Online Transaktionen die benötigte REORG-Zeit.

Für Applikationen, deren Antwortzeit kritisch ist, speziell in 24 x 7 Verfügbarkeitsanforderungssituationen,ist es problematisch, dass Faktoren, die der Performance schaden, schnellsmöglich beseitigt werden.In DB2 Version 5 kann das mit dem REORG SHRLEVEL CHANGE geschehen.



IndexA

ABEND 23Access-for-DB2 8ACCESSPATH 30

B

BUILD 40BUILD2 43

CCDB 9CHANGELIMIT 27CHECK PENDING 20Claim Readers 42, 43cleanup 41cluster key 38clustering index 23COLCARD 31COPY 27COPY PENDING 20copy pending 24COPYDDN 40, 45correlated key columns 35COUNT 35CPU-Zeit 26CR 42, 43

D

DA 41, 42, 43DASD 41DB2 manged Objects 39DB2-Katalog 9DB2-Systemtabellen 9DBD01 18DEADLINE 45DELAY 45directory 9Drain All 41, 42, 43Drain Writers 41, 42, 43DSN1COPY 24DSN1PRNT 24DSNDB01 19DSNDB06 19DUMMY 27DW 41, 42, 43



Eelapsed time 23, 26, 41

F

FIRSTKEYCARDF 35FREQVAL 36full IC 28full image copy 24, 25, 27FULLKEYCARDF 35

H

HIGH2KEY 31

IIBM 5ICTYPE 25IDCAMS 41IIC 28Image copies 25image copy 25, 27Incremental IC 21incremental IC 28incremental image copy 27INLCOPY 24inline copy 24, 25, 40, 41, 45INLKEY 25INSERT 21

J

join 32, 34

K

Katalog 9keys 23

L

large tables 31large TS 32LINEAR VSAM 39LOAD 21LOAD REPLACE 25LOG 24, 41LONGLOG DRAIN 45LOW2KEY 31LRSN 38lustering 40



Mmapping table 44, 45mass delete 43matching index scans 34MAXRO 45Metastruktur 9Move-for-DB2 8

N

non-indexed 30non-indexed columns 30, 31non-partitioning Index 39, 40, 41, 43NOSYSREC 40, 42NUMCOLS 35, 36

O

Online REORG 21, 44, 45, 46

PPage 21, 27partitioning Index 38, 39PIECESIZE 41PREFORMAT 21PTS 41

Q

QUIESCE 18, 19

R

RBA 21read-only 41"read-write"-REORG 44RECOVER 21, 25RECOVER INDEX 30RECOVER TABLESPACE 30RECOVERDDN 45RECOVERY PENDING 20recovery pending 27, 42Relational Tools 8RELOAD 40REORG 21, 30REORG TABLESPACE 44, 45Reorganisation 38Report 27REPORTONLY 27RID 38, 39, 43, 44rows 30RUNSTATS 21, 35, 36



SSAMPLE 31sampling 31, 32, 34segmented tablespace 44shadow copy 38, 41, 44shadow dataset 39SHRLEVEL 25, 38, 40SHRLEVEL CHANGE 40, 45SHRLEVEL NONE 40SHRLEVEL REFERENCE 40SORTDATA 40SORTKEYS 22, 23, 40, 42SORTOUT 40, 42space map page 27, 28, 43STOGROUP 39switch 41, 42, 45SYSCOPY 18SYSIBM.SYSCOLDIST 35, 37SYSIBM.SYSCOLDISTSTATS 35, 37SYSIBM.SYSCOLSTATS 31SYSIBM.SYSCOLUMNS 31SYSIBM.SYSINDEXES 35SYSIBM.SYSINDEXSTATS 35SYSREC 42SYSSTATS 36SYSUT1 22, 42

T

TS 21TS scan 34Type 2 Indizes 41

U

UNLOAD 40unused pages 21UTILINIT 40UTILTERM 39

VVARCHAR 32

W

writer class 45





Documents

Kapitel VIII: DB2 - Utilities, der Katalog und ToolsDB2 Reorg Plus Tabellen Reorganisdationswerkzeug von BMC Inc. DB/Auditor DB2 Audit-Reporting System von Systems Center Inc. DB/DASD