Home 
ORDIX News 1/2005
ORDIX News 1/2005
ORDIX News 1/2005
Das IT-Magazin der ORDIX AG mit Fachbeiträgen zu Datenbanken, Unix und Java/XML.
Die Frage „Warum?“ bzw. „Wann muss ich eigentlich reorganisieren?“ haben wir ebenfalls in der letzten Ausgabe geklärt. Abbildung 1 stellt nochmals eine Zusammenfassung dar.
|
Es gibt also viele Gründe für eine Reorganisation und fast ebenso viele Möglichkeiten, eine Reorganisation durchzuführen.
Im Folgenden stellen wir Ihnen die unterschiedlichen Möglichkeiten vor und weisen auch auf „deutliche“ Performanceverbesserungen der einzelnen Reorganisationsmaßnahmen hin.
Die folgenden Punkte müssen bei einer Reorganisation zuerst bedacht werden:
Ob Sie mittels SQL oder Werkzeugen reorganisieren, müssen Sie selbst entscheiden. Wir zeigen Ihnen Vor- und Nachteile und worauf Sie achten sollten.
UNLOAD, LOAD und DBexportEine der am häufigsten genutzten Methoden ist ohne Zweifel der UNLOAD/LOAD Befehl.
Dabei sollte die folgende Reihenfolge genutzt werden (Indizes immer am Schluss):
Jedoch ist der UNLOAD/LOAD nicht immer das beste Werkzeug für die Reorganisation, insbesondere was Dauer - und damit Wartungsfenster - und Performance betrifft. Des Weiteren ist die Reihenfolge des Anlegens der Datenbankobjekte wichtig, denken wir nur mal an „referentielle Integrität“.
Achten müssen Sie insbesondere auf Long Transactions und die Anzahl konfigurierter Sperren. Deshalb ist ein „Lock Table ... in exclusive mode“ empfehlenswert. Ebenso sollten Sie, wenn möglich, LOGGING ausschalten.
ALTER TABLE BefehlDer ALTER TABLE Befehl kann nachträglich die NEXT EXTENT Size verändern. Dieses ist jedoch keine echte Reorganisationsmaßnahme, sondern bezieht sich lediglich auf die Extents, die „neu“ angelegt werden (siehe Abbildung 2).
Des Weiteren besteht die Möglichkeit, das Logging von Tabellen aufzuheben bzw. wieder zu aktivieren (siehe Spalte FLAGS in SYSTABLES). Jedoch lassen sich nur Tabellen auf „TYPE (RAW)“ setzen, also NO LOGGING, die keine aktiven Indizes bzw. Referenzen besitzen (siehe ebenfalls Abbildung 2).
-- neues Setzen der NEXT SIZE alter table customer modify next size 20000; -- Tabelle NO LOGGING setzen (RAW Mode) alter table customer type (RAW); -- Tabelle LOGGING wieder aktivieren (STANDARD MODE) alter table customer type (STANDARD); |
Achtung: alter table ... type (RAW); ist nur mit großer Vorsicht anzuwenden, da für diese Tabelle anschließend keine Transaktionsprotokolle mehr geschrieben werden.
SET BefehlMit Hilfe des SET Befehls können Indizes, Constraints und Trigger disabled und wieder enabled werden (siehe Abbildung 3). Den Status, ob z. B. ein Index enabled bzw. disabled ist, kann man der Systemkatalog-Tabelle SYSOBJSTATE entnehmen.
set indexes,constraints for customer disabled; set indexes,constraints for customer enabled; commit; |
Beim „Enablen“ eines Indexes wird dieser neu aufgebaut. Der Vorteil des SET Befehls ist, dass „fast“ keine Einträge in das logische Log geschrieben werden, denn erst beim COMMIT wird das „alte“ TABLESPACE des reorganisierten Indexes wieder freigegeben.
Voraussetzung:
In den DBspaces, in denen sich die Indizes befinden, muss genügend Speicherplatz zur Verfügung stehen, um die Index Daten neu aufzubauen. Die alten Daten bleiben so lange bestehen.
Vorteil:
Es werden nur wenige Einträge ins logische Log geschrieben, dabei handelt es sich um administrative Vorgänge wie Extent Allokation etc. Die Aktion ist parallelisierbar (PSORT_NPROCS, PDQPRIORITY, DBSPACETEMP)
Nachteil:
Nur Indizes können reorganisiert werden.
Der ALTER FRAGMENT Befehl kann auf fragmentierte, aber auch auf nicht fragmentierte Tabellen angewendet werden (siehe Abbildung 4). Bei nicht fragmentierten Tabellen kann jedoch nur die Option „INIT“ des ALTER FRAGMENT Befehls verwendet werden. Mit dieser Option kann man:
Voraussetzungen:
1. Im (Ziel-)DBspace muss genügend Speicherplatz zur Verfügung stehen.
2. Es müssen genügend logische Logs vorhanden sein.
Vorteile:
1. Objekt kann „während“ der Reorganisation in ein anderes DBspace verschoben werden. Daten und Indizes werden reorganisiert.
2. Parallelisierbar (PSORT_NPROCS, PDQPRIORITY, DBSPACETEMP)
Nachteile:
1. Die Tabelle Index wird während der Reorganisation mit einem „Exclusive Lock“ gesperrt.
2. Es werden TA (Transaktion)-Informationen ins logische Log geschrieben.
alter table customer modify next size 20000; alter fragment on table customer init in DBspace-Name; |
Eine sehr gängige Methode, Tabellen und Indizes zu reorganisieren, ist der Alter Index to Cluster Befehl.
Dieser erzeugt einen „gruppierten“ Index. Das bedeutet, die Daten liegen in der gleichen Reihenfolge vor, wie der Index indiziert ist. Somit wird bei einem Alter Index to Cluster nicht nur der Index sondern auch die zugrundeliegende Tabelle reorganisiert.
Voraussetzungen:
1. Im DBspace muss genügend Speicherplatz zur Verfügung stehen (mindestens doppelt so viel).
2. Es müssen ausreichend logische Logs vorhanden sein (ca. das 1,5 bis 2-fache der Tabellengröße).
Vorteil:
Die Aktion ist parallelisierbar (PSORT_NPROCS, PDQPRIORITY, DBSPACETEMP)
Nachteile:
1. Die Tabelle bzw. der Index erhält für die Zeit der Reorganisation ein Exclusive Lock.
2. Es werden TA-Informationen ins logische Log geschrieben.
Wie die meisten von uns eventuell schon mehrfach aus eigener Erfahrung wissen, kann die Reorganisation eines größeren Datenbestandes sehr viel Zeit in Anspruch nehmen. Jedoch steht meistens nur ein sehr begrenztes Zeitfenster zur Verfügung.
Die folgenden Methoden und Tools können Ihre Reorganisation um ein Vielfaches beschleunigen. Das Optimierungspotenzial ist enorm. Eigentlich betrifft es ausschließlich das Laden von Daten und das Anlegen von Indizes. Hier erreicht man jedoch schnell eine Zeitverbesserung vom Faktor 5 - 10!
ONPLOADDer High Performance Loader ONPLOAD von IBM Informix bietet in sehr vielen Fällen eine sehr performante Alternative zum herkömmlichen UNLOAD/LOAD. Dabei kann ONPLOAD beim Ent- bzw. Laden von Daten mehrere Aufgaben übernehmen.
Das wären u. a.:
Der ONPLOAD steht über ein GUI Frontend (IPLOAD, siehe Abbildung 5) oder als Commandline Tool (ONPLADM, siehe Abbildung 6) zur Verfügung.
|
usage : onpladm <command>
create job <jobname> {options}
create map <mapname> {options}
create project <projectname> {options}
create object {options}
delete job <jobname> {options}
delete query <queryname> {options}
delete device <devicename> {options}
delete project <projectname> {options}
modify object {options}
describe job <jobname> {options}
describe map <mapname> {options}
describe query <queryname> {options}
describe device <devicename> {options}
describe project <projectname> {options}
list job {options}
list map {options}
list format {options}
list query {options}
list filter {options}
list project {options}
list defaults {options}
run job {options}
run project {options}
configure defaults {options} |
Alle Aktivitäten des ONPLOADS werden als Projekte und Jobs in der eigenen Datenbank (onpload bzw. Auswertung der Umgebungsvariable DBONPLOAD) gespeichert. Ausführen kann man immer ein gesamtes Projekt oder auch nur einzelne Jobs.
Die Programme ipload und onpladm sind Werkzeuge, um die Datenbasis zu „füttern“. Ipload ist zwar sehr einfach zu bedienen, ist aber ungeeignet, wenn viele Tabellen oder eine ganze Datenbank reorganisiert werden soll. Hierfür wurde später onpladm entwickelt. Onpladm ist wiederum derzeit nur eingeschränkt für ANSI Datenbanken nutzbar.
Deshalb wurde von ORDIX bereits 1997 ein Werkzeug entwickelt, das ähnlich wie onpladm arbeitet, aber noch eine Reihe von Zusatz-Features bietet. Mit dieser Toolbox können Sie einfach und schnell z. B. eine gesamte Datenbank mittels ONPLOAD entladen bzw. laden. Des Weiteren erkennt das Werkzeug automatisch, welche Tabellen mittels ONPLOAD und welche mittels herkömmlichem UNLOAD/LOAD bearbeitet werden können und erstellt entsprechend auch die UNLOAD und LOAD Skripte. Somit benötigen Sie nur noch einen einzigen Shell-Skript-Aufruf, um z. B. eine komplette Datenbank zu entladen bzw. zu laden.
In folgenden Fällen kann ONPLOAD nicht verwendet werden:
Einige dynamisch veränderbare Parameter können die Performance bei Reorganisationen massiv positiv beeinflussen.
Dazu zählt der Parameter DS_TOTAL_MEMORY. Mit dem Befehl onmode -M <KBytes> kann er dynamisch verändert werden. Dieser Speicherbereich wird u. a. für temporäre Sortierungen (PDQ → Parallel Database Query) genutzt.
Die maximale Größe des DS Memory ist durch die Größe des virtuellen Speichers begrenzt (SHMVIRTSIZE, SHMADD → onstat -g seg).Wir empfehlen, DS_TOTAL_MEMORY je nach SQL-Befehl (z. B. CREATE INDEX) auf 50 % bis max. 90 % des virtuellen Speicherbereichs der Datenbank (SHMVIRTSIZE) zu setzen.
Die aktuelle Konfiguration ermittelt der Befehl onstat -g mgm (siehe Abbildung 7).
IBM Informix Dynamic Server Version 9.40.UC2 -- On-Line --
Memory Grant Manager (MGM)
--------------------------
MAX_PDQPRIORITY: 100
DS_MAX_QUERIES: 2
DS_MAX_SCANS: 1048576
DS_TOTAL_MEMORY: 250000 KB
Queries: Active Ready Maximum
0 0 2
Memory: Total Free Quantum
(KB) 250000 250000 125000
Scans: Total Free Quantum
1048576 1048576 1
Load Control: (Memory) (Scans) (Priority) (Max Queries) (Reinit)
Gate 1 Gate 2 Gate 3 Gate 4 Gate 5
(Queue Length) 0 0 0 0 0
|
PSORT_NPROCS und PSORT_DBTEMP
PSORT_NPROCS und PSORT_DBTEMP sind Umgebungsvariablen, die wir noch aus früheren Zeiten kennen (Informix Online).
Mit der Umgebungsvariable PSORT_NPROCS kann die Anzahl der parallelen Sort-Threads gesteuert werden. Die Optimale Einstellung für diese Variable ist die Anzahl der physikalischen CPUs.
Die Umgebungsvariable PSORT_DBTEMP spezifiziert die Filesysteme, in denen temporäre Sortierdateien angelegt werden (z. B. export PSORT_DBTEMP=/home1:/home2:/home3:/home4).
Besser jedoch als die Nutzung von temporären Filesystemen ist die Verwendung von mehreren temporären DBspaces. Diese werden mit dem ONCONFIG Parameter DBSPACETEMP oder der gleichnamigen Umgebungsvariable angegeben (DBSPACETEMP=tempdbs1,tempdbs2). Somit kann eine temporäre Sortierung im Root-DBspace oder im Filesystem (/tmp) vermieden werden.
Voraussetzung für eine parallele Verarbeitung ist jedoch ein eingeschaltetes PDQ (Parallel Database Query). Das bedeutet, PDQPRIORITY muss > 1 gesetzt werden!
PDQPRIORITYMit PDQPRIORITY wird festgelegt, wie viele Datenbank-Ressourcen für einzelne Sessions verwendet werden können. Im günstigsten Fall können 100 % der Ressourcen verwendet werden. Es erfolgt somit auch automatisch eine parallele Verarbeitung. Das Aktivieren von PDQ erfolgt mittels einer Umgebungsvariablen bzw. mittels des SET Befehls (siehe Abbildung 8).
|
#Umgebungsvariablen |
Das Anlegen der Indizes lässt sich mittels PDQ (PDQPRIORITY=100) und mehreren TEMPDBSPACES deutlich beschleunigen. Dadurch wird ein gleichzeitiges temporäres Sortieren der einzelnen Sort-Threads ermöglicht. Stehen keine weiteren RAW Devices bzw. Festplattenpartitionen zur Verfügung, kann auch auf „Cooked Files“ im Filesystem zurückgegriffen werden. Diese können nach dem CREATE INDEX wieder gelöscht werden.
Folgendes ist beim Anlegen von temporären DBspaces jedoch zu beachten:
Ansonsten werden diese DBspaces nicht genutzt. Der Eintrag erfolgt einfach getrennt durch „,“.
Viele Möglichkeiten stehen uns zur Verfügung (siehe Abbildung 9). Es muss nicht immer der altbekannte UNLOAD/LOAD Befehl sein. Besonders mit PDQ, ONPLOAD und mehreren temporary DBspaces lässt sich sehr viel Zeit einsparen.
|
Mit dem neuesten IBM Informix Release (IDS 10.0) werden noch weitere, u. a. den Bereich Reorganisation betreffende Neuerungen hinzukommen.
Sie haben Fragen zum Thema Reorganisation und IBM Informix? Sprechen Sie uns an! - Wir zeigen Ihnen, wo Sie Zeit und Geld sparen können.
Guido Saxler (info@ordix.de).