Optim High Performance Unload konfigurieren

# HPU default configuration
bufsize=4194304
db2dbdft=SAMPLE
db2instance=db2inst2
netservice=db2hpudm42
doubledelim=binary

Schlüsselwort=Wert

Schlüsselwort=Wert:Unterwert, Wert:Unterwert

Schlüsselwort=Wert;Unterwert, Wert;Unterwert

Konfigurationsdateiparameter

allow_unlimited_memory

Wenn Sie zulassen wollen, dass Optim High Performance Unload ulimit-Werte ignoriert, die die Speicherbelegung für die zugehörige Shell begrenzen, setzen Sie diesen Parameter auf yes. Sie können diesen Parameter verwenden, wenn das Laden aus einer Tabelle aufgrund von Speicherbegrenzungen fehlschlägt. Der Standardwert ist no. allow_unlimited_memory ist eine Voraussetzung, um die Speicherbegrenzung effizient zu ignorieren, indem memory_limit auf no gesetzt wird.

Einschränkung: Dieser Parameter gilt nur für Linux- und UNIX-Plattformen und kann nur in der Masterdatei db2hpu.cfg und nicht in beliebigen benutzerdefinierten Konfigurationsdateien angegeben werden.

blu_parallelism

Mit diesem Parameter können Sie die Anzahl der parallel zu verarbeitenden Spalten in einer nach Spalten organisierten Tabelle festlegen. Werden mehrere Spalten einer nach Spalten organisierten Tabelle daraus geladen, werden sie standardmäßig parallel verarbeitet. Hierbei wird die Anzahl parallel verarbeiteter Spalten automatisch festgelegt. Dieser Parameter ermöglicht das Setzen dieser Anzahl auf den gewünschten Wert. Der zugewiesene Wert muss numerisch sein. Beispiel:

...
blu_parallelism=10
...

Weitere Informationen finden Sie in Leistung beim Entladen einer nach Spalten organisierten Tabelle verbessern.

bufsize

Mit diesem Parameter definieren Sie die Standardpuffergröße, die verwendet wird, wenn Optim High Performance Unload die Ausgabedatei generiert. Der Wert entspricht der tatsächlichen Anzahl Byte, die für diesen Puffer verwendet wird. Der kleinste akzeptierte Wert ist 262144 (256 Kilobyte) und der größte akzeptierte Wert ist 2097152 (2 MB). Der niedrigere Wert verbraucht weniger Speicher bei der Verarbeitung, aber die Ein-/Ausgabeeffizienz nimmt ab. Der Grund dafür, dass der Maximalwert auf 2 MB begrenzt ist, liegt darin, dass ein Wert größer 2 MB mehr Speicher verbraucht, aber zu keiner nennenswerten Steigerung der Ein-/Ausgabeeffizienz führt. Wenn sich die Ausgabedatei auf derselben physischen Platte befindet wie die Datei, die von Optim High Performance Unload gelesen wird (Container oder Backup), verbessert ein höherer Wert möglicherweise die Leistung von Optim High Performance Unload.

Wenn Sie beispielsweise über vier Prozessoren verfügen und Sie die Tabellen TABLE1, TABLE2 und TABLE3 mit der Option bufsize=262144 entladen wollen, verarbeitet Optim High Performance Unload eine Tabelle nach der anderen mit vier Verarbeitungsthreads und schreibt jeweils einen Puffer von 256 KB.

db2api_monitoring

Nur für Linux- und UNIX-Plattformen. Die Verwendung der Optim High Performance Unload-Optionen FLUSH BUFFERPOOLS und LOCK beinhaltet den Aufruf von Db2-APIs, die Db2-Sperren anfordern. Mit der Konfigurationsvariablen db2api_monitoring kann ein Zeitlimit festgelegt werden, auf Basis dessen Optim High Performance Unload Informationsnachrichten generiert, um anzugeben, dass die Verarbeitung durch Db2-Sperren aufgehalten wird und erst nach deren Aufhebung fortgesetzt werden kann. Die durch Verwendung dieser Optim High Performance Unload-Optionen angeforderten Sperren beachten keine Sperrenmonitorbedingungen. Diese Überwachungskonfiguration wird definiert, indem über den Wert des Parameters db2api_monitoring in der Datei db2hpu.cfg eine Anzahl Sekunden festgelegt wird. Der Standardwert für diesen Parameter ist 0. Wenn die Überwachung nicht konfiguriert ist oder der Parameterwert auf 0 gesetzt ist, wird der Überwachungsmechanismus für die Db2-APIs bezüglich Sperroperationen und Flushoperationen für Pufferpools inaktiviert. Nachfolgend steht ein Beispiel für die Verwendung des Parameters:

...
db2api_monitoring=120
...

Wenn der Mechanismus aktiviert ist, wird jedes Mal, wenn der Überwachungswert erreicht wird, eine Informationsnachricht gesendet, die die Operation angibt, für die die Überwachung erfolgte. Die Operationen werden durch eine der folgenden Zeichenfolgen angegeben:

• LOCK: Diese Operation wird vor der Datenentladung ausgeführt, um während des Optim High Performance Unload-Prozesses Aktualisierungen an der betroffenen Tabelle zu blockieren (wenn die Option LOCK YES gesetzt ist).

• LOCK RESET: Diese Operation wird nach der Datenentladung ausgeführt, um die Sperre für die Tabelle aufzuheben (wenn die Option LOCK YES gesetzt ist).

• FLUSH BUFFERPOOLS: Diese Operation wird vor der Datenentladung ausgeführt, um die Daten in den Pufferpools zu registrieren und per Flushoperation auf Platte zu schreiben (wenn die Option FLUSH BUFFERPOOLS YES gesetzt ist).

• FLUSH BUFFERPOOLS RESET: Diese Operation wird nach der Datenentladung ausgeführt, um für die Registrierung von Daten in Pufferpools ein Commit durchzuführen(wenn die Option FLUSH BUFFERPOOLS YES gesetzt ist).

Beispiel: Der folgende Optim High Performance Unload-Ausführungsbericht veranschaulicht eine Situation, in der bei der Ausführung einer LOCK-Operation die Überwachungszeit erreicht wird:

INZM031I Optim High Performance Unload for Db2 06.01.00.001(120531) 
         64 Bit 06/04/2012 (Linux lat194 x86_64)
INZI473I Speicherbegrenzungen: 'unlimited' für virtuellen Speicher und 'unlimited' für Datensegment.
       ----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+
000001 GLOBAL CONNECT TO SAMPLE; 
000002 UNLOAD TABLESPACE 
000003 PART(ALL) 
000004 SELECT * FROM "EMPLOYEE"; 
000005 OUTFILE("outfile") 
000006 ; 

INZU462I Start des HPU-Steuerungsschritts: 16:13:09.580.
INZU463I Ende des HPU-Steuerungsschritts: 16:13:09.591. 
INZU464I Start des HPU-Ausführungsschritts: 16:13:09.603.
INZU595I Der Db2-API-Aufruf 'LOCK' ist noch in Bearbeitung (Partition 0 von Tabelle 'I910.EMPLOYEE')
INZU595I Der Db2-API-Aufruf 'LOCK' ist noch in Bearbeitung (Partition 0 von 'I910.EMPLOYEE')
INZU595I Der Db2-API-Aufruf 'LOCK' ist noch in Bearbeitung (Partition 0 von Tabelle 'I910.EMPLOYEE') 
INZU410I Dienstprogramm HPU hat 42 Zeilen auf dem Host lat194 für I910.EMPLOYEE in outfile entladen. 
INZU465I Ende des HPU-Ausführungsschritts: 16:13:21.699. 
INZI441I HPU erfolgreich beendet: Echtzeit -> 0m12.118807s 
Benutzerzeit -> 0m3.214510s : Übergeordnet -> 0m0.032994s, Untergeordnet -> 0m3.181516s 
Systemzeit -> 0m3.529462s : Übergeordnet -> 0m0.013997s, Untergeordnet -> 0m3.515465s

In diesem Bericht wurde der Überwachungswert beim Ausführen der Sperroperation dreimal erreicht. Abhängig vom festgelegten Überwachungswert, können Sie zu dem Schluss kommen, dass dieser Wert ungünstig gewählt ist (für die Dauer dieser Operation wurde der Wert zu klein festgesetzt) oder dass mit der Dauer dieser Operation etwas nicht stimmt. Die Ausführung wurde erfolgreich abgeschlossen und die Daten wurden entladen. Wenn die Optim High Performance Unload-Sperroperation nicht abgeschlossen worden wäre, wäre die Informationsnachricht weiterhin generiert worden, bis entweder Optim High Performance Unload manuell beendet worden wäre oder bis Db2 die Sperren aufgehoben hätte, die Optim High Performance Unload am Fortschreiten der Verarbeitung gehindert haben.

db2api_timeout

Nur für Linux- und UNIX-Plattformen. Mit diesem Parameter und mit dem Parameter db2api_monitoring können Sie die Ausführung einer Optim High Performance Unload-Operation beenden, die immer noch aktiv ist, wenn der Zeitwert des Parameters db2api_monitoring erreicht wird. Für den Parameter db2api_timeout ist der Wert 'yes' oder 'no' möglich. Der Standardwert ist 'no'. Wird für den Parameter db2api_monitoring kein Wert festgelegt, wird die Einstellung 'yes' für den Parameter db2api_timeout ignoriert. Nachfolgend steht ein Beispiel für die Verwendung des Parameters:

...
db2api_monitoring=120
...
db2api_timeout=yes
...

Wenn die Ausführung beendet ist, wird eine Fehlernachricht gesendet. Die Nachricht gibt die Operation an, für die die Zeitlimitüberschreitung aufgetreten ist. Die überwachten Operationen sind in der Beschreibung zum Parameter db2api_monitoring aufgelistet.

Beispiel: Der folgende Optim High Performance Unload-Ausführungsbericht veranschaulicht eine Situation, in der bei der Ausführung einer LOCK-Operation die Überwachungszeit erreicht wird und deshalb eine Zeitlimitüberschreitung auftritt:

INZM031I Optim High Performance Unload for Db2 06.01.00.001(130412) 
         64 Bit 04/16/2013 (Linux lat186 3.1.0-1.2-desktop (187dde0) x86_64)
INZI473I Speicherbegrenzungen: 'unlimited' für virtuellen Speicher und 'unlimited' für Datensegment.
       ----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+
000001 GLOBAL CONNECT TO SAMPLE;
000002 UNLOAD TABLESPACE
000003 LOCK YES
000004 FLUSH BUFFERPOOLS NO
000005 SELECT * FROM EMPLOYEE;
000006 OUTFILE("outfile")
000007 ;

INZU462I Start des HPU-Steuerungsschritts: 15:29:59.597.
INZU463I Ende des HPU-Steuerungsschritts: 15:29:59.912.
INZU464I Start des HPU-Ausführungsschritts: 15:30:00.027.
INZU624E Zeitlimitüberschreitung für den Db2-API-Aufruf 'LOCK' (Partition 0 von Tabelle 'I958.EMPLOYEE').
INZU465I Ende des HPU-Ausführungsschritts: 15:30:02.364.
INZU366I HPU-Rückgabecode 8 (Ursachencode 0x123a016)

In diesem Bericht wurde der Überwachungswert beim Ausführen der Sperroperation erreicht. Die Ausführung von Optim High Performance Unload wurde mit Fehlern beendet.

db2compr_api

Mit diesem Parameter geben Sie den Namen der Standardkomprimierungsbibliothek an, die beim Entladen aus einem komprimierten Backup-Image geladen werden soll.

db2dbdft

Dieser Parameter entspricht dem Datenbanknamen, der von Optim High Performance Unload verwendet wird, wenn kein Datenbankname angegeben wird (Befehlszeilenoption –d).

db2instance

Mit diesem Parameter geben Sie den Instanznamen an, der von Optim High Performance Unload verwendet wird, wenn kein Instanzname angegeben wird (Befehlszeilenoption –i).

db2promote

Mit diesem Parameter geben Sie an, ob Benutzer, die über die Db2-Berechtigung zum Auswählen (SELECT) aus einer Tabelle verfügen, aber nicht die Berechtigung QUIESCE SHARE für die betreffende Tabelle haben, diese Berechtigung zwecks Ausführung eines Entladevorgangs erhalten sollten oder nicht.

Die Berechtigung QUIESCE ist erforderlich, um Daten in einem konsistenten Zustand zu entladen. Wenn db2promote auf 'no' gesetzt ist, ist der Standardwert des Parameters LOCK auf NO gesetzt. Dieser Standardwert wird stattdessen auf YES gesetzt. Auf Benutzer, die sowohl die Berechtigung für SELECT als auch für QUIESCE haben, hat die Option db2promote keine Auswirkungen.

db2variables

Mit diesem Parameter können Sie die Verwendung einer Datei für das Festlegen der Werte von Db2-Variablen angeben. Er muss über den absoluten Pfad einer Datei mit einer Liste von Db2-Variablennamen mit ihren Werten angegeben werden.

Beispiel:

...
db2variables=/home/i1111/mydb2vars.txt
...

dir_cfg

Wenn mehrere Maschinen an einer Db2-Instanz beteiligt sind und die Optim High Performance Unload-Konfiguration auf allen diesen Maschinen identisch ist, bietet Ihnen dieser Parameter die Möglichkeit, dieselben Optim High Performance Unload-Konfigurationsdateien gemeinsam zu nutzen. Die folgenden Optim High Performance Unload-Konfigurationsdateien können gemeinsam genutzt werden:

• db2hpu.cfg

• db2hpu.locale

• db2hpu.map

• db2hpu.debug

• db2hpu.trace

• remote.locale

Gehen Sie wie folgt vor, um diese Dateien gemeinsam zu nutzen:

- kopieren Sie alle Konfigurationsdateien einer einzelnen Maschine an eine gemeinsam genutzte Speicherposition.

- aktualisieren Sie die Konfigurationsdatei db2hpu.cfg im Verzeichnis cfg jeder Maschine, indem Sie den gesamten Inhalt löschen und der Datei lediglich den Parameter dir_cfg hinzufügen.

- setzen Sie den Parameter auf den absoluten Pfad des Verzeichnisses, in dem sich alle gemeinsam genutzten Konfigurationsdateien befinden.

Anmerkung: Für jede Maschine wird die gemeinsam genutzte Konfiguration verwendet, wenn die Konfigurationsdatei db2hpu.cfg lediglich den Parameter dir_cfg mit der gemeinsam genutzten Speicherposition enthält. Wenn der Parameter dir_cfg nicht der einzige Parameter ist oder kein Parameter dir_cfg vorhanden ist, wird die gemeinsam genutzte Konfiguration ignoriert und es werden die Optim High Performance Unload-Konfigurationsdateien auf dieser Maschine verwendet.

Wichtig: Der Parameterwert muss als absoluter Pfad des Verzeichnisses angegeben werden, in dem sich die gemeinsam genutzten Konfigurationsdateien befinden. Wenn z. B. /sharedfs die gemeinsam genutzte Speicherposition der Konfigurationsdateien ist, müssen Sie dir_cfg=/sharedfs in jeder der lokalen Konfigurationsdateien angeben.

doubledelim

Mit diesem Parameter geben Sie den Standardwert für die Option DOUBLE DELIM in der Steuerdatei an. Dieser Parameter gilt nur für DEL- oder DELIMITED-Ausgabeformate. Wenn er ON lautet, werden die Zeichentypspalten auf Vorkommen des Begrenzers geprüft und jedes erkannte Vorkommen wird verdoppelt. Bei BINARY werden nur die Zeichenspalten durchsucht, die FOR BIT DATA aufweisen. Bei OFF werden keine Spalten durchsucht. Der Standardwert ist BINARY.

Die beste Leistung erhalten Sie, wenn so wenig wie möglich durchsucht wird. Sie können das Durchsuchen von Zeichenspalten vermeiden, indem Sie ein als Begrenzer zu verwendendes Zeichen auswählen, von dem Sie wissen, dass es nicht in den entladenen Daten verwendet wird. Wenn Sie ein in den entladenen Daten nicht verwendetes Zeichen nicht verwenden können, sollten Sie die Option DOUBLE DELIM in den Steuerdateien falls erforderlich auf ON setzen. Wenn Sie erwarten, dass Ihre Benutzer die Option DOUBLE DELIM nicht auf ON setzen, obwohl dies erforderlich ist, können Sie die Option in der Konfigurationsdatei festlegen. Der Benutzer kann jede hier vorgenommene Einstellung in den eigenen Steuerdateien überschreiben.

graphic_even_padding

Mit diesem Parameter können Sie beeinflussen, wie die Werte der GRAPHIC-, VARGRAPHIC-, LONG VARGRAPHIC- und DBCLOB-Spalten mit einer ungewöhnlichen Größe in einer ASC-Ausgabedatei verarbeitet werden. Diese Werte werden standardmäßig mit einem Nullbyte aufgefüllt, damit der zugehörige Bereich in der Ausgabedatei eine gewöhnliche Größe hat. Wenn dieses Verhalten nicht angewendet werden soll, kann das Auffüllen für eine gewöhnliche Wertegröße durch das Setzen dieses Parameters auf "no" inaktiviert werden. Der Standardwert ist "yes".

Beispiel:

...
graphic_even_padding=no
...

hidden

Setzen Sie diese Option auf yes, um anzugeben, dass verdeckte Spalten in den Entladevorgang eingeschlossen werden sollen. Der Standardwert ist no.

ixftrunc

Mit diesem Parameter können Sie Speicherplatz sparen, wenn VARCHAR- oder VARGRAPHIC-Daten im IXF-Format entladen werden. Nur die Spalten dieser zwei Typen, die größer als der für diesen Parameter angegebene Wert sind, werden berücksichtigt. Bei diesem Parameter hat jeder für diesen Spaltentyp entladene Wert die Größe, die der Anzahl der realen Zeichen in den Daten entspricht, anstatt die für die Spalte festgelegte Maximalgröße. Der Standardwert ist 20.

keepalive_time

Die von Optim High Performance Unload für die Netzkommunikation erstellten Sockets bleiben möglicherweise für einen langen Zeitraum inaktiv. Dies kann besonders für ein Socket der Fall sein, das während der automatischen Datenmigration erstellt wurde.

Während der automatischen Datenmigration bleibt ein Socket während des Zielladevorgangs für die Tabellendaten inaktiv. Abhängig davon, wie lange der Ladeschritt dauert, bleibt es unter Umständen über einen langen Zeitraum inaktiv.

Manche Systeme sind so konfiguriert, dass die Verbindung zu Sockets, die zu lange inaktiv bleiben, automatisch vom System getrennt wird. Solch eine Situation kann zum Beispiel eintreten, wenn eine Firewall an der Netzkonfiguration beteiligt ist. Als Folge eines nicht erwarteten Verbindungsabbaus bei einem der zugehörigen Sockets kann eine Optim High Performance Unload-Task nicht erfolgreich abgeschlossen werden.

Um eine solche Situation zu vermeiden, kann Optim High Performance Unload die zugehörigen Sockets mit bestimmten Keepalive-Merkmalen erstellen. Wenn ein Socket auf diese Weise erstellt wird, werden regelmäßig leere Pakete über die TPC/IP-Schicht selbst gesendet, um Pseudoaktivität für das Socket sicherzustellen. Das Optim High Performance Unload-Socketzeitintervall zwischen leeren Paketen kann unabhängig von jeder generischen Socketeinstellung des Betriebssystems optimiert werden.

Dieser Parameter aktiviert den Keepalive-Mechanismus von Optim High Performance Unload.

Dieser Parameter kann auf drei Arten festgelegt werden:

• mit dem Wert -1: inaktiviert die Keepalive-Optimierung, damit die Optim High Performance Unload-Sockets so erstellt werden, dass keine künstlich erzeugte Aktivität für sie stattfinden kann.
• mit dem Wert 0 (Standardwert): aktiviert die Keepalive-Optimierung, damit die Optim High Performance Unload-Sockets so erstellt werden, dass künstlich erzeugte Aktivität für sie stattfinden kann. Das Zeitintervall zwischen den Aktivierungspaketen beachtet den auf der Betriebssystemebene festgelegten Wert.
• mit einem positiven numerischen Wert: aktiviert die Keepalive-Optimierung für Optim High Performance Unload-Sockets. Das Zeitintervall zwischen den Aktivierungspaketen ist auf den konfigurierten Wert (in Minuten) gesetzt.

Durch die Einstellung im folgenden Beispiel werden alle 10 Minuten Socketaktivierungspakete aktiviert:

...
keepalive_time=10
...

keystore_file

Wenn Optim High Performance Unload im Standalone-Modus für ein verschlüsseltes Backup ausgeführt wird, geben Sie mit diesem Parameter den absoluten Pfad der zu berücksichtigenden Db2-Keystore-Datei an. Je nach Keystore-Typ (PKCS#12, KMIP oder PKCS#11) ist die fragliche Datei eine PKCS#12-Datei, die den zu verwendenden Verschlüsselungsmasterschlüssel enthält, eine Textdatei, die die zugehörige KMIP-Serverkonfiguration enthält, oder eine Textdatei, die die zugehörige PKCS#11-Konfiguration enthält. Dieser Parameter ist obligatorisch, wenn Optim High Performance Unload im Standalone-Modus ausgeführt wird, da in diesem Fall die Informationen, die sich auf den im Backup enthaltenen Keystore beziehen, unter Umständen nicht für die Maschine gültig sind, auf der Optim High Performance Unload ausgeführt wird.

keystore_type

Wenn Optim High Performance Unload im Standalone-Modus für ein verschlüsseltes Backup ausgeführt wird, geben Sie mit diesem Parameter den Typ der zu berücksichtigenden Db2-Keystore-Datei an. Je nach Keystore-Typ (PKCS#12, KMIP oder PKCS#11) kann der Wert 'pkcs12', 'kmip' oder 'pkcs11' festgelegt werden. Dieser Parameter ist obligatorisch, wenn Optim High Performance Unload im Standalone-Modus ausgeführt wird, da in diesem Fall die Informationen, die sich auf den im Backup enthaltenen Keystore beziehen, unter Umständen nicht für die Maschine gültig sind, auf der Optim High Performance Unload ausgeführt wird.

lobinlinesize

Dieser Parameter erlaubt das Festlegen der Abschneidegröße, die auf LOB-Inlinedaten angewendet wird. Der Parameter muss als numerischer Wert in der Einheit Kilobyte festgelegt werden.

Wichtig: Jede Einstellung dieser Größe für das Abschneidung wird ignoriert, wenn die Optim High Performance Unload-Task im Zusammenhang mit dem IXF-Ausgabeformat gestartet wird. In diesem Fall wird der Standardwert von 32700 Byte für das Abschneiden der LOB-Daten beibehalten.

Einschränkung: Der für die Größe für das Abschneiden von LOB-Daten angegebene Wert kann nicht auf einen Wert unter 32 KB oder über 1024 KB gesetzt werden, wenn es sich um Inlinedaten handelt.

Im nachfolgenden Beispiel für diese Parametereinstellung wird 64 KB als Abschneidegröße verwendet:

...
lobinlinesize=64
...

maxmemory

Mit diesem Parameter geben Sie die Obergrenze für den Systemspeicher (in Byte) an, den Optim High Performance Unload verwenden kann. Wenn der angegebene Wert zu niedrig ist, um mit dem Entladevorgang fortzufahren, verwendet Optim High Performance Unload die Mindestvoraussetzungen.

maxthreads

Mit diesem Parameter geben Sie die maximale Anzahl Verarbeitungsthreads an, die Optim High Performance Unload verwenden kann. Sie können diesen Parameter angeben, um den Verarbeitungsaufwand für Entladungen bei kleinen Tabellen zu beschränken. Wenn Sie diesen Parameter auf einen niedrigeren Wert setzen, kann Optim High Performance Unload mehrere Tabellen gleichzeitig bei Verwendung weniger Prozessthreads entladen. Der Mindestwert für diesen Parameter ist 1 und der Maximalwert ist gleich der Anzahl Prozessoren.

Wenn Sie beispielsweise über vier Prozessoren verfügen und Sie die Tabellen TABLE1, TABLE2 und TABLE3 mit der Option maxthreads=1 entladen wollen, verarbeitet Optim High Performance Unload alle drei Tabellen gleichzeitig und verwendet dabei für jede Tabelle einen Thread.

maxselects

Beim Entladen aus einem Backup-Image ermöglicht dieser Parameter, die Anzahl Tabellen zu begrenzen, die parallel entladen werden. Standardmäßig werden alle in demselben UNLOAD-Block angegebenen Tabellen parallel verarbeitet. Wenn viele Tabellen daran beteiligt sind, kann dies zur Nichtverfügbarkeit von Speicher führen. Wird die Anzahl der parallel verarbeiteten Tabellen begrenzt, reduziert dies zwar den Speicherbedarf, erhöht aber den Zeitaufwand für den Entladevorgang, da das betreffende Backup-Image pro Gruppe entladener Tabellen mindestens einmal gelesen wird. Der beste Wert für diesen Parameter ist deshalb die maximale Anzahl Tabellen, die parallel verarbeitet werden kann, ohne dass der verfügbare Speicher knapp wird.

memory_limit

Setzen Sie memory_limit auf no, um anzugeben, dass Optim High Performance Unload so viel Speicher wie nötig verwenden kann, um eine angegebene Task abzuschließen. Sie können memory_limit nur festlegen, wenn Sie den Konfigurationsdateiparameter allow_unlimited_memory auf yes gesetzt haben.

Sie können den Parameter memory_limit auf der Masterkonfigurationsdateiebene, in den benutzerdefinierten Konfigurationsdateien oder auf der Befehlszeilenebene angeben.

mig_pipe_timeout

Mit diesem Parameter geben Sie den Zeitlimitwert an, der von der Lesekomponente einer automatischen Konfiguration für das Öffnen von Pipes berücksichtigt werden soll. Der zugewiesene Wert muss numerisch sein und steht für eine Anzahl Sekunden. Er muss in der Konfigurationsdatei auf der Maschine festgelegt werden, auf der Optim High Performance Unload für die auszuführende Datenmigration aufgerufen wird.

Eine automatische Migration umfasst zwei interne Komponenten, die zusammen arbeiten: eine für das Lesen der zu migrierenden Daten und eine, um diese Daten in das gewünschte Ziel zu laden. Die migrierten Daten werden zwischen den beiden Komponenten mithilfe von Datenströmen übertragen, bei denen es sich um Dateien oder Pipes handeln kann: die Lesekomponente schreibt die Daten in diese Datenströme, die von der Ladekomponente gelesen werden. Wenn Pipes verwendet werden, können sie von der Lesekomponente erst geöffnet werden, wenn die Ladekomponente die fraglichen Pipes öffnet. Zu Beginn der Ladekomponente, bevor sie die zu verarbeitenden Datenströme öffnet, kann eine Latenz auftreten, besonders wenn die Migration in ein Db2-Ziel erfolgt, für das die Ladekomponente das Dienstprogramm Db2 Load verdeckt aufruft. Für das Öffnen der Pipes durch die Lesekomponente gilt ein Zeitlimit, das standardmäßig 10 Sekunden beträgt. Wenn es zu Beginn der Ladekomponente zu einer Latenz kommt, die diesen Wert überschreitet, beendet die Lesekomponente das Öffnen der Pipes und stoppt anschließend die Verarbeitung, sodass die automatische Migration fehlschlägt. In diesem Fall ist es unter Umständen erforderlich, einen geeigneten Wert für dieses Zeitlimit zu konfigurieren.

Durch die Einstellung im folgenden Beispiel werden 180 Sekunden als Zeitlimitwert für das Öffnen der Pipes in einer automatischen Migration konfiguriert:

...
mig_pipe_timeout=180
...

min_extent_per_thread

Mit diesem Parameter geben Sie die minimale Anzahl Speicherbereiche für Datenseiten an (in Verbindung mit der Anzahl verwendeter Seiten für eine Tabelle), um einen weiteren Verarbeitungsthread zu starten. Dieser Parameter wird nur verwendet, wenn der Parameter use_stats auf yes gesetzt ist. Der Standardwert ist 6.

nbcpu

Mit diesem Parameter können Sie die Anzahl der gestarteten Arbeitseinheiten begrenzen. Dieser Wert hat Auswirkungen sowohl auf die Speicherbelegung als auch auf den Grad der Parallelität für Optim High Performance Unload. Optim High Performance Unload verwendet diesen Wert als Obergrenze für die Parallelverarbeitung. Der Maximalwert dieses Parameters entspricht der Anzahl Prozessoren im System; dabei handelt es sich um die Standardeinstellung. Der Mindestwert ist 1.

Wenn Sie beispielsweise über vier Prozessoren verfügen und Sie die Tabellen TABLE1, TABLE2 und TABLE3 mit der Option nbcpu=2 entladen wollen, verarbeitet Optim High Performance Unload die Tabellen eine nach der anderen mit zwei Verarbeitungsthreads.

netservice

Mit diesem Parameter geben Sie den Servicenamen an, der dem Optim High Performance Unload-Netzfeature in der Servicesystemdatei zugeordnet ist. Dieser Parameter wird bei der Installation von Optim High Performance Unload automatisch festgelegt.

nettohosts

Achtung: Dieser Parameter wird nicht weiter unterstützt. Erstellen Sie eine Konfigurationsdatei db2hpu.map im Unterverzeichnis 'cfg' Ihres Optim High Performance Unload-Hauptinstallationsverzeichnisses, um die Beziehungen zwischen Netz- und Hostnamen anzugeben.

Verwenden Sie diesen Parameter, wenn in der zweiten Spalte der Datei db2nodes.cfg Netznamen anstelle von Hostnamen angegeben werden. Optim High Performance Unload kann nur Maschinen mit Hostnamen ermitteln. Anhand der zweiten Spalte der Datei db2nodes.cfg wird bestimmt, ob es sich um eine lokale oder eine ferne Datenbankpartition handelt. Optim High Performance Unload stellt anhand dieses Parameters fest, welcher Hostname sich auf einen bestimmten Netznamen bezieht. Die Formatierungsregeln für diesen Parameter folgen den Formatierungsregeln für Listen. Wenn Sie diesen Parameter definieren, sieht das Format wie folgt aus: nettohosts=host1sw:host1, host2sw:host2...

odpp_path

odpp_version

Wenn Optim High Performance Unload für eine ODPP-Maskierungsverarbeitung verwendet wird und wenn die Optionen PATH und VERSION der Klausel DATAMASKING in der zugehörigen Steuerdatei weggelassen werden, versucht Optim High Performance Unload, den erwarteten ODPP-Pfad aus der Konfigurationsdatei db2hpu.cfg abzurufen. Die beiden Einstellungen können in der genannten Datei mithilfe von zwei dedizierten Parametern festgelegt werden:

• odpp_path (anstelle der Option PATH in der Steuerdateiklausel DATAMASKING).
• odpp_version (anstelle der Option VERSION in der Steuerdateiklausel DATAMASKING).

Beispiel für ihre Spezifikation:

...
odpp_path=/opt/odpp
odpp_version=9.1
...

Die Datenmaskierungsmethode wird bevorzugt über diese beiden Parameter angegeben, anstatt sie über die folgenden vier Parameter festzulegen.

Weitere Informationen finden Sie in DATAMASKING.

odpp_api_loader

odpp_api_parser

odpp_api_adapter

odpp_api_provider

Wenn Optim High Performance Unload für eine ODPP-Maskierungsverarbeitung verwendet wird und wenn die Option LOAD der Klausel DATAMASKING in der zugehörigen Steuerdatei weggelassen wird, versucht Optim High Performance Unload, die erwarteten Bibliotheksnamen aus der Konfigurationsdatei db2hpu.cfg abzurufen. Sie können in der genannten Datei mithilfe von vier dedizierten Parametern festgelegt werden:

• odpp_api_loader (anstelle der Bibliothek LOADER der Option LOAD in der Steuerdateiklausel DATAMASKING).
• odpp_api_parser (anstelle der Bibliothek PARSER der Option LOAD in der Steuerdateiklausel DATAMASKING).
• odpp_api_adapter (anstelle der Bibliothek ADAPTER der Option LOAD in der Steuerdateiklausel DATAMASKING).
• odpp_api_provider (anstelle der Bibliothek PROVIDER der Option LOAD in der Steuerdateiklausel DATAMASKING).

Beispiel für ihre Spezifikation:

...
odpp_api_loader=/opt/odpp/bin/libODPPLoader.so.9.1
odpp_api_parser=/opt/odpp/bin/libODPPParser.so.9.1
odpp_api_adapter=/opt/odpp/bin/libODPPAdapter.so.9.1
odpp_api_provider=/opt/odpp/bin/libODPPProvider.so.9.1
...

Die Werte dieser Parameter müssen im Hinblick auf die beteiligten ODPP-Bibliotheken absolute Dateinamen sein. Jede erforderliche ODPP-Bibliothek muss entweder auf Konfigurationsdateiebene oder auf Steuerdateiebene festgelegt werden. Beim Festlegen der ODPP-Bibliotheken müssen die Namen von vorhandenen ODPP-Bibliotheken angegeben werden, damit sie wie erwartet geladen werden können. Für jeden aufgeführten Parameter muss der geeignete ODPP-Bibliotheksname festgelegt werden, damit die jeweiligen ODPP-APIs gefunden werden können.

Weitere Informationen finden Sie in DATAMASKING.

openssl_api_crypto

Mit diesem Parameter geben Sie den Namen der OpenSSL-Bibliothek crypto an, wenn der tatsächliche Name vom zugehörigen Standardnamen abweicht.

openssl_api_ssl

Mit diesem Parameter geben Sie den Namen der OpenSSL-Bibliothek ssl an, wenn der tatsächliche Name vom zugehörigen Standardnamen abweicht.

shared_datapart_processing

Mögliche Werte sind 'yes' und 'no'. Die Einstellung dieses Parameters wird auf jede Optim High Performance Unload-Task angewendet. Um diese Einstellung für eine bestimmte Task zu überschreiben, kann eine andere Einstellung über die Klausel SHARED_DATAPART_PROCESSING in der Steuerdatei angegeben werden.

Verwenden Sie diesen Parameter für eine datenpartitionierte Tabelle in einer DPF-Instanz, um die parallele Verarbeitung von eindeutigen Datenbankpartitionen zu aktivieren und die Leistung zu verbessern. Er ist besonders in solchen Fällen hilfreich, wenn Tasks für Backups ausgeführt werden, die von einem Speichermanager verwaltet werden, um paralleles Lesen der verschiedenen Datenbankpartitionsbackups zuzulassen. Das Standardverhalten ist die serialisierte Verarbeitung, die zu geringer Leistung führen kann, wenn die beteiligten Backups mithilfe eines Speichermanagers erstellt werden. Das Format für die Angabe dieses Parameters sieht wie folgt aus:

...
shared_datapart_processing=yes
...

Weitere Informationen finden Sie in Konfiguration für die Verarbeitung von Datenpartitionen.

stacksize

Mit diesem Parameter optimieren Sie die maximale Größe für den Stack in Bezug auf einen Optim High Performance Unload-Prozess. Der zugewiesene Wert muss numerisch sein und in KB angegeben werden. Möglicherweise muss die Stackgröße für eine Optim High Performance Unload-Ausführung erhöht werden, besonders wenn die Standardgröße für diesen Stack nicht groß genug ist, um eine Task auf der Basis einer SQL-Anweisung mit großer Rekursionstiefe auszuführen. Ein Beispiel hierfür wäre eine SQL-Anweisung, die in ihrer Klausel WHERE ein Bündel von Prädikaten enthält, die mit OR verknüpft sind. Wird dieser Parameter nicht festgelegt, wird die Stackgröße aus der Umgebung über den 'ulimit'-Wert übernommen, der der Stackgröße zugeordnet ist. Das Ändern dieses Umgebungswerts würde die Möglichkeit bieten, für die Stackgröße von Optim High Performance Unload-Ausführungen einen anderen Wert anzuwenden, aber er würde für jeden Befehl gelten, der über diese aktualisierte Umgebung gestartet wird. Die Verwendung dieses Parameters erlaubt es, nur die auf Optim High Performance Unload-Tasks anzuwendende Stackgröße zu erhöhen, ohne separate Anwendungen zu beeinträchtigen.

Im folgenden Beispiel setzt die Einstellung die Stackgröße für Optim High Performance Unload-Tasks auf 256 MB:

...
stacksize=262144
...

Achtung: Der Parameter stacksize ist nur auf Linux- und UNIX-Plattformen verfügbar.

stagedir

Mit diesem Parameter geben Sie das Verzeichnis an, in dem Optim High Performance Unload temporäre Dateien generieren soll, wenn Sie Daten aus Backup-Images entladen. Standardmäßig wird das temporäre Verzeichnis des Systems verwendet.

stage_per_part

Mit diesem Parameter definieren Sie mehrere Speicherpositionen für das Backup-Staging, und zwar eine Speicherposition pro Datenbankpartition. Ohne diese Option werden alle Staging-Dateien in einem einzigen Verzeichnis und somit in einem einzigen Dateisystem erstellt. Durch Verwendung dieser Option können Sie sicherstellen, dass genügend Speicher vorhanden ist und der betreffende Speicher nicht auf ein einzelnes Verzeichnis in einem einzelnen Dateisystem für den Staging-Bereich beschränkt ist. Dieser Parameterwert kann 'yes' oder 'no' sein. Der Standardwert ist 'no'.

Wenn dieser Parameter in der Datei db2hpu.cfg auf 'yes' gesetzt ist, werden die Staging-Dateien pro Datenbankpartition an eine Speicherposition verteilt, die wie folgt benannt wird: DBPARTnnn; dabei ist nnn eine dreistellige Nummer, die mit der zugehörigen Datenbankpartitionsnummer übereinstimmt. Die Stammposition für diese Verzeichnisse ist das Verzeichnis, das als Staging-Bereich definiert ist: entweder das Verzeichnis, das über den Konfigurationsparameter 'stagedir' definiert ist, oder standardmäßig das Verzeichnis '/tmp'. Diese Speicherpositionen müssen vorhanden sein, andernfalls wird eine Fehlernachricht angezeigt.

Wenn die Funktion für das Staging pro Datenbankpartition aktiviert ist, wird es systematisch auf den Staging-Bereich angewendet, der für die Verarbeitung der Backups von Datenbankpartitionen vorgesehen ist, die während der Ausführungsphase Daten enthalten. Wenn der Katalog, der während der Steuerungsphase verarbeitet wird, aus dem Backup mit der Katalogdatenbankpartition abgerufen wird, wird diese Funktion nur angewendet, wenn die Option CATN der Klausel USING BACKUP CATALOG angegeben ist. In diesem Fall werden die potenziellen Staging-Dateien für den Katalog an einer untergeordneten Speicherposition erstellt, die der für die Option CATN angegebenen Datenbankpartitionsnummer entspricht. Wird diese Option nicht angegeben, werden die potenziellen Staging-Dateien für den Katalog direkt im Staging-Stammverzeichnis erstellt.

Achtung: Zum Vergrößern des Staging-Bereichs müssen die Speicherpositionen für die pro Datenbank vorhandenen Partitionen als symbolische Links zu physischen Pfaden erstellt werden, die auf unterschiedlichen Dateisystemen enden. Wenn diese Speicherpositionen als physische Verzeichnisse an derselben Stammposition erstellt werden, wird der Staging-Bereich nicht vergrößert.

Beispiel: Angenommen, es liegt folgende Konfiguration für eine Entladeoperation aus Backups einer Db2-Instanz vor, die die drei Datenbankpartitionen #1, #2 und #3 enthält:

...

stagedir=/staging

stage_per_part=yes

...

In diesem Fall müssen die folgenden Pfade erstellt werden, bevor Sie eine Entladeoperation starten:

/staging/DBPART001

/staging/DBPART002

/staging/DBPART003

Wenn einer dieser Pfade nicht vorhanden ist, wird eine Entladeoperation, für die eine Staging-Datei erstellt werden muss, fehlschlagen und es wird eine Fehlernachricht angezeigt.

storeprocedure_report

Mit diesem Parameter geben Sie die Datei an, in die der Ausführungsbericht einer Optim High Performance Unload-Task geschrieben wird, die über den Aufruf der gespeicherten Optim High Performance Unload-Prozedur ausgeführt wird. Wird die gespeicherte Optim High Performance Unload-Prozedur ausgeführt, wird der Bericht, der sich auf die zugrunde liegende Optim High Performance Unload-Ausführung bezieht, über den Ausgabeparameter STDERR der gespeicherten Prozedur gehandhabt. Da dieser Parameter den CLOB-Datentyp aufweist, begrenzt der Db2-Befehlszeilenprozessor (CLP) die Anzeige des Parameters auf 8192 Byte. Wenn der Ausführungsbericht größer als dieser Grenzwert ist, wird er als Folge davon abgeschnitten angezeigt, sodass nicht geprüft werden kann, ob die Ausführung vollständig erfolgte.

Mit diesem Parameter wird Optim High Performance Unload so konfiguriert, dass bei der Ausführung der gespeicherten Prozedur der gesamte Bericht in eine Datei geschrieben wird, anstatt ihn über einen Ausgabeparameter anzuzeigen. Der Parameter muss mit einem absoluten Dateinamen angegeben werden.

syncsize

Mit diesem Parameter können Sie die Ausgabedateisynchronisation für die Platte aktivieren. Wenn das Betriebssystem so konfiguriert ist, dass das Plattencaching eine große Speicherkapazität belegen kann, kann das Generieren von großen Ausgabedateien zu einer umfangreichen Speicherbelegung führen und sich auf die Nutzbarkeit der Maschine durch separate Anwendungen auswirken. Soll die Speicherkapazität, die vom Plattencaching beim Ausführen einer Entladetask belegt wird, begrenzt werden, können Sie mit diesem Parameter das regelmäßige Synchronisieren der Ausgabedateien für die Platte aktivieren.

Der diesem Parameter zugewiesene Wert muss numerisch sein und in KB angegeben werden. Ist dieser Parameter festgelegt, wird die Datei jedes Mal, wenn die Größe einer Ausgabedatei um das konfigurierte Datenvolumen angestiegen ist, für die Platte synchronisiert.

Beispiel:

...
syncsize=10000
...

tsm_api

Mit diesem Parameter geben Sie den API-Bibliotheksnamen an, der dynamisch geladen werden soll, wenn Sie Daten aus Backup-Images entladen, die in Tivoli Storage Manager gespeichert sind.

umask

Mit diesem Parameter können Sie den umask-Wert auf einem fernen System überschreiben und Dateien mit entsprechenden Berechtigungen generieren. Standardmäßig ist der umask-Wert für Entladungen der umask-Wert des Starters für den Dämon xinetd (oder inetd). Die generierten Dateiberechtigungen werden dann durch den umask-Wert des Root eingeschränkt. Bei einer automatischen Systemmigration kann diese Einschränkung problematisch sein, da Datendateien für Db2 Load für den Instanzbenutzer der Zieldatenbank lesbar sein müssen. In einigen Fällen (abhängig von der Systemkonfiguration) ist der angewendete umask-Wert zu restriktiv und die generierten Dateien sind für den Instanzbenutzer der Zieldatenbank nicht sichtbar. Sie können die umask-Option von Optim High Performance Unload so festlegen, dass das Programm diesen restriktiven umask-Wert überschreiben darf.

Die Definition des umask-Features basiert auf der umask-Definition von UNIX: drei Oktalziffern werden verwendet, um die Berechtigungen für Masken für Benutzer/Gruppe/Sonstige zu definieren. Der umask-Wert kann Oktalwerte zwischen 000 und 777 annehmen. Der empfohlene umask-Wert für Optim High Performance Unload ist 022. Ausgabedateien werden mit den geeignete Berechtigungen zum Ausführen der manuellen oder automatischen Migration generiert.

Einschränkung:

• Der umask-Parameter gilt nur für fern generierte Dateien.
• Mit der umask-Definition in Optim High Performance Unload können Sie nicht Datendateien mit allen Arten von Zugriffsberechtigungen generieren. Optim High Performance Unload fragt die Generierung von Datendateien immer mit der Zugriffsberechtigung 644 (rw-r--r--) ab. Wenn der umask-Wert stärker eingeschränkt ist, wird die Zugriffsberechtigung reduziert. Wenn der umask-Wert weniger eingeschränkt ist, bleibt die Zugriffsberechtigung rw-r--r--.

use_netname

Mit diesem Parameter aktivieren oder inaktivieren Sie die Verwendung von Netznamen, wenn sie in der Datei db2nodes.cfg der beteiligten Db2-Instanz verwendet werden. Solche Netznamen entsprechen im Allgemeinen spezialisierten Hochgeschwindigkeitsnetzschnittstellen. Sie können auswählen, ob die Optim High Performance Unload-Netzkommunikation über diese Schnittstellen gehandhabt werden soll oder nicht. Standardmäßig ist dieser Parameterwert intern auf yes gesetzt und die Verwendung von Netznamen daher standardmäßig aktiviert.

use_stats

Mit diesem Parameter geben Sie an, ob Optim High Performance Unload die Tabellenstatistik aus dem Katalog berücksichtigen soll. Anhand dieser Informationen kann Optim High Performance Unload die optimale Anzahl Verarbeitungsthreads für das Entladen der Tabellen ermitteln.

Mögliche Werte für diesen Parameter sind yes und no. Bei Angabe von yes kann Optim High Performance Unload die Verarbeitung optimieren, indem umfangreichere Tabellen parallel entladen werden. Diese Option ist nur effektiv, wenn die Statistikdaten in den Tabellen aktuell sind.

Achtung: Die Verwendung der Option yes kann die Leistung von Optim High Performance Unload unter bestimmten Bedingungen signifikant reduzieren. Wenn beispielsweise eine bestimmte Tabelle veraltete Statistikdaten enthält, die angeben, dass die Tabelle nur wenige oder gar keine Daten enthält, obwohl die Tabelle in der Zwischenzeit aktualisiert wurde und mehrere Millionen Zeilen enthält, betrachtet Optim High Performance Unload die Tabelle weiterhin als klein und verwendet nur einen einzigen Verarbeitungsthread, um sie zu entladen.

Der Standardwert ist no.

xbsa_api

Mit diesem Parameter geben Sie den API-Bibliotheksnamen an, der dynamisch geladen werden soll, wenn Sie Daten aus einem Backup entladen. Dieser Parameter wird nur berücksichtigt, wenn Sie die Option USE XBSA beim Entladen aus Backup-Images angeben. Die Option USE XBSA gibt an, dass die Backup-Images durch ein XBSA-ähnliches Speichertool verwaltet werden.