Konfigurieren Optim High Performance Unload

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

keyword=value

keyword=value:subvalue, value:subvalue

keyword=value;subvalue, value;subvalue

Konfigurationsdateiparameter

allow_unlimited_memory

Wenn Sie zulassen möchten, dass Optim High Performance Unload die ulimit-Werte zu ignorieren, die den Speicherverbrauch 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 nogesetzt wird.

Einschränkung: Dieser Parameter gilt nur für Linux -und UNIX-Plattformen und kann nur in der Masterdatei db2hpu.cfg und nicht in 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. Mit diesem Parameter kann ein Wert seiner Wahl auf diese Zahl gesetzt werden. Der zugewiesene Wert muss numerisch sein. Beispiel:

...
blu_parallelism=10
...

Weitere Informationen finden Sie unter Leistungsaspekte beim Entladen einer nach Spalten organisierten Tabelle .

bufsize

Verwenden Sie diesen Parameter, um die Standardpuffergröße zu definieren, die verwendet wird, wenn Optim High Performance Unload die Ausgabedatei generiert wird. 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 demselben physischen Datenträger befindet wie die Datei, Optim High Performance Unload (Container oder Sicherung) befindet, kann ein höherer Wert die Leistung verbessern Optim High Performance Unload.

Wenn Sie beispielsweise über 4 verfügbare Prozessoren verfügen und TABLE1, TABLE2 und TABLE3 mit der Option bufsize=262144 entladen möchten, Optim High Performance Unload jede Tabelle nacheinander mit 4 Verarbeitungsthreads und Schreibpuffern von jeweils 256 KB verarbeitet.

compression_minsize

Die Komprimierung von Daten kann viel weniger effizient sein, wenn die zu komprimierende Datenmenge klein ist. Und in einem solchen Fall ist es besser, es nicht zu komprimieren. Wenn die Möglichkeit der Komprimierung der über das Netzwerk gesendeten Daten aktiviert ist, kann die Mindestgröße für die Komprimierung dieser Daten ausgewählt werden, indem dieser Parameter in der Konfigurationsdatei db2hpu.cfg festgelegt wird. Der zugewiesene Wert muss numerisch sein und zwischen 0 und 10 liegen, wobei die Einheit Kb ist. Der Standardwert ist 4Kb. Wenn dieser Parameter auf einen bestimmten Wert eingestellt ist und die zu übertragende Datenmenge unter diesem Grenzwert liegt, wird sie vor dem Senden nicht komprimiert.

Hier ist ein Beispiel für diese Parametereinstellung mit einem Wert, der einer Mindestgröße von 8Kb entspricht:

...
compression_minsize=8
...

db2api_monitoring

Nur für Linux- und UNIX-Plattformen. Die Verwendung der Optim High Performance Unload FLUSH BUFFERPOOLS und LOCK-Optionen beinhaltet das Aufrufen von Db2® -APIs, die Db2 -Sperren erwerben. Die db2api_monitoring konfigurationsvariable kann verwendet werden, um ein Zeitlimit festzulegen, nach dessen Ablauf Optim High Performance Unload informationsmeldungen generiert werden, die darauf hinweisen, dass die Verarbeitung auf Db2 -Sperren wartet, bevor sie fortgesetzt werden kann. Die bei der Nutzung dieser Optionen erworbenen Sperren Optim High Performance Unload optionen erworbenen Sperren erfüllen keine der Bedingungen für die Sperrüberwachung. 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 keine Überwachung konfiguriert ist oder der Parameterwert auf 0 gesetzt ist, ist der Überwachungsmechanismus für die Db2 -APIs zum Sperren und Löschen von Pufferpooloperationen 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:

• SPERREN: Dieser Vorgang wird vor dem Entladen der Daten ausgeführt, um Aktualisierungen der betreffenden Tabelle während des Optim High Performance Unload (wenn die Option LOCK YES eingestellt 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).

Zum Beispiel : Dieser Optim High Performance Unload ausführungsbericht veranschaulicht eine Situation, in der die Überwachungszeit bei der Durchführung eines LOCK-Vorgangs erreicht wird:

INZM031I Optim High Performance Unload for Db2 06.01.00.001(120531) 
         64 bits 06/04/2012 (Linux lat194 x86_64)
INZI473I Memory limitations: 'unlimited' for virtual memory and 'unlimited' for data segment
       ----+----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 HPU control step start: 16:13:09.580.
INZU463I HPU control step end : 16:13:09.591. 
INZU464I HPU run step start : 16:13:09.603.
 INZU595I The 'LOCK' Db2 API call is still in progress (partition 0 of 'I910.EMPLOYEE' table)
INZU595I The 'LOCK' Db2 API call is still in progress (partition 0 of 'I910.EMPLOYEE' table)
INZU595I The 'LOCK' Db2 API call is still in progress (partition 0 of 'I910.EMPLOYEE' table) 
INZU410I HPU utility has unloaded 42 rows on lat194 host for I910.EMPLOYEE in outfile. 
INZU465I HPU run step end : 16:13:21.699. 
INZI441I HPU successfully ended: Real time -> 0m12.118807s 
User time -> 0m3.214510s : Parent -> 0m0.032994s, Children -> 0m3.181516s 
Syst time -> 0m3.529462s : Parent -> 0m0.013997s, Children -> 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 der Optim High Performance Unload sperrvorgang überhaupt nicht abgeschlossen worden wäre, wäre die Informationsmeldung so lange generiert worden, bis sie entweder Optim High Performance Unload manuell beendet wurde oder bis Db2 die Sperren aufhob, die Optim High Performance Unload am Fortfahren gehindert wurden.

db2api_timeout

Nur für Linux- und UNIX-Plattformen. Verwenden Sie diesen Parameter und den db2api_monitoring parameter, um die Ausführung eines Optim High Performance Unload operation, die noch ausgeführt wird, wenn der Zeitwert des db2api_monitoring parameters erreicht ist. Die gültigen Werte für den Parameter db2api_timeout sind 'yes' und 'no '. Der Standardwert ist 'no' (Nein). Wenn kein Wert für den Parameter db2api_monitoring festgelegt ist, wird die Einstellung des Parameters db2api_timeout auf 'yes' 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.

Zum Beispiel : Dieser Optim High Performance Unload ausführungsbericht veranschaulicht eine Situation, in der die Überwachungszeit bei der Durchführung eines LOCK-Vorgangs erreicht wird, was zu einer Zeitüberschreitung bei der Ausführung führt:

INZM031I Optim High Performance Unload for Db2 06.01.00.001(130412) 
         64 bits 04/16/2013 (Linux lat186 3.1.0-1.2-desktop (187dde0) x86_64)
INZI473I Memory limitations: 'unlimited' for virtual memory and 'unlimited' for data segment
       ----+----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 HPU control step start: 15:29:59.597.
INZU463I HPU control step end  : 15:29:59.912.
INZU464I HPU run step start    : 15:30:00.027.
 INZU624E A time out occurred for 'LOCK' Db2 API call (partition 0 of 'I958.EMPLOYEE' table).
INZU465I HPU run step end      : 15:30:02.364.
INZU366I HPU return code 8 (reason code 0x123a016)
 

In diesem Bericht wurde der Überwachungswert beim Ausführen der Sperroperation erreicht. Die Optim High Performance Unload ausführung wurde irrtümlicherweise abgebrochen und 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

Verwenden Sie diesen Parameter, um den Instanznamen anzugeben, der von Optim High Performance Unload verwendet wird, wenn kein Instanzname angegeben wird (Befehlszeilenoption –i).

db2promote

Verwenden Sie diesen Parameter, um anzugeben, ob Benutzern, die über die Db2 -Berechtigung zum Auswählen aus einer Tabelle verfügen, aber nicht über die Berechtigung zum Ausführen von QUIESCE SHARE für diese Tabelle verfügen, die Berechtigung zum Ausführen eines Entladeprozesses erteilt werden soll.

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 zum Festlegen der Werte von Db2 -Variablen angeben. Sie muss mit einem absoluten Pfad einer Datei angegeben werden, die eine Liste von Db2 -Variablennamen mit ihren Werten enthält.

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 all diesen Computern gleich ist, verwenden Sie diesen Parameter, um dieselben Optim High Performance Unload konfigurationsdateien Die Optim High Performance Unload konfigurationsdateien, die gemeinsam genutzt werden können, sind:

• db2hpu.cfg

• db2hpu.locale

• db2hpu.map

• db2hpu.debug

• db2hpu.trace

• remote.locale

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

- Kopieren Sie alle Konfigurationsdateien eines Systems 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.

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

Hinweis: Für jede Maschine wird die gemeinsam genutzte Konfiguration verwendet, wenn die Konfigurationsdatei db2hpu.cfg nur den Parameter dir_cfg mit der gemeinsam genutzten Position enthält. Wenn der Parameter "dir_cfg" nicht der einzige Parameter ist oder es keinen Parameter "dir_cfg" gibt, wird die gemeinsam genutzte Konfiguration ignoriert und die Optim High Performance Unload konfigurationsdateien auf diesem Computer verwendet.

Wichtig: Der Parameterwert muss als absoluter Pfad des Verzeichnisses angegeben werden, in dem sich die gemeinsam genutzten Konfigurationsdateien befinden. Lautet die Position der gemeinsam genutzten Konfigurationsdateien beispielsweise /sharedfs, 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 sie auf ON gesetzt ist, werden die Zeichentypspalten und die binären Typspalten nach Vorkommen des Begrenzers durchsucht und jedes erkannte Vorkommen wird verdoppelt. Bei Angabe von BINARY werden nur Zeichenspalten mit FOR BIT DATA und binären Spalten durchsucht. Wenn diese Option auf OFF gesetzt ist, findet kein Scannen statt. 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 ein solches Verhalten nicht angewendet werden soll, ist es möglich, die Auffüllung auf eine gerade Größe dieser Werte zu inaktivieren, indem Sie diesen Parameter auf no setzen. Der Standardwert ist 'JA'.

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.

ignore_load_error

Dieser Parameter ermöglicht es, die Fehler zu ignorieren, die während der Ausführung des Db2 -Dienstprogramms LOAD bei der automatischen Migration einer Tabelle auftreten würden.

Um diese Einstellung für eine bestimmte Task zu überschreiben, kann eine andere Einstellung mit der Klausel IGNORE_LOAD_ERROR in der Steuerdatei angegeben werden. Für weitere Informationen siehe IGNORE_LOAD_ERROR.

Bei der Ausführung Optim High Performance Unload eine automatische Migration einer Tabelle in eine Db2 -Umgebung ausgeführt wird, wird das Db2 -Lade-Dienstprogramm aufgerufen, um die Daten in die Zieltabelle zu laden. Wenn während der Db2 Load-Ausführung ein Fehler auftritt, wird die automatische Migration standardmäßig gestoppt und mit einem Fehler beendet. Wenn mehrere Tabellen innerhalb derselben Ausführung migriert werden müssen, wird die Verarbeitung nach einem fehlgeschlagenen Datenladeschritt gestoppt. Daher werden die übrigen Tabellen, für die die Migration noch nicht gestartet wurde, überhaupt nicht verarbeitet.

Für einen solchen Fall, in dem eine Reihe von Tabellen verarbeitet werden muss, kann man, um die verbleibenden Tabellen zu verarbeiten, selbst wenn die Migration von mindestens einer Tabelle aus irgendeinem Grund auf der Db2 -Ladeebene fehlgeschlagen wäre, Optim High Performance Unload so konfigurieren, dass es jeden Fehler ignoriert, der vom Db2 Load-Dienstprogramm festgestellt wird. Die Migration aller Tabellen, die berücksichtigt werden sollen, wird verarbeitet, auch wenn mindestens eine Tabelle aufgrund eines Fehlers auf der Db2 -Ladeebene nicht migriert werden kann. Am Ende der Verarbeitung müsste man herausfinden, ob es Tabellen gibt, bei denen die Migration aufgrund eines Fehlers, der vom Db2 -Dienstprogramm LOAD festgestellt wurde, fehlgeschlagen wäre, um den jeweiligen Fall zu beheben. Wenn tatsächlich ein solcher Fehler auftritt, wird er im Ausführungsbericht angezeigt und in einer Nachricht wird angegeben, dass dieser Fehler ignoriert wird. Die restlichen Tabellen werden jedoch wie erwartet verarbeitet.

Wenn Sie diesen Parameter auf 'yes' setzen, können Fehler, die während der Ausführung des Db2 -Ladedienstprogramms auftreten, ignoriert werden. Gültige Werte sind 'yes' und 'no '. Der Standardwert ist 'no'.

Beispiel:

...
ignore_load_error=yes
...

ignore_nonexistent_table

Mit diesem Parameter können Sie die Fehler ignorieren, die durch nicht vorhandene Tabellennamen verursacht werden, indem Sie sie in der Konfigurationsdatei db2hpu.cfg auf 'yes' setzen.

Gültige Werte sind 'yes' und 'no '. Der Standardwert ist 'no'.

Wenn während derselben Ausführung ein Entladen mehrerer Tabellen mit einer Klausel ONLY TABLES oder einer Klausel EXCEPT TABLES oder einer Klausel INTO TABLES oder einer Klausel TABLES MODIFIERS ausgeführt wird, wird standardmäßig ein Fehler gesendet, wenn ein in dieser Klausel angegebener Name keiner vorhandenen Tabelle entspricht und die Verarbeitung gestoppt wird. Daher werden die restlichen Tabellen, die noch nicht verarbeitet wurden, nicht entladen.

Eine solche Situation kann für die Bestimmung der Tabellen, die nicht verarbeitet werden konnte, schmerzhaft sein. Um in einer solchen Situation Abhilfe zu schaffen, kann man Optim High Performance Unload, damit es jeden Fehler ignoriert, der durch eine nicht vorhandene Tabelle verursacht wird. Das Entladen aller zu berücksichtigenden Tabellen würde verarbeitet werden, auch wenn mindestens ein Name keiner Tabelle entspricht. Am Ende der Verarbeitung müsste man herausfinden, ob es Namen gibt, die ignoriert werden, um sich um ihren besonderen Fall zu kümmern. Wenn eine solche Situation auftritt, wird in einer Nachricht angezeigt, dass ein Name im Ausführungsbericht unbekannt ist. Außerdem wird in einer Nachricht darauf hingewiesen, dass dieser Fehler ignoriert wird. Die restlichen Tabellen werden jedoch wie erwartet verarbeitet.

Zum Überschreiben dieser Einstellung für eine bestimmte Task kann eine andere Einstellung mit der Klausel IGNORE_NONEXISTENT_TABLE in der Steuerdatei angegeben werden. Weitere Informationen finden Sie unter IGNORE_NONEXISTENT_TABLE.

Beispiel:

...
ignore_nonexistent_table=yes
...

instances_krb_keytab

Verwenden Sie diesen Parameter, um die Verwendung eines Kerberos -Authentifizierungsmechanismus zu aktivieren, Optim High Performance Unload, wenn die Option LOCK oder FLUSH BUFFERPOOLS auf YES gesetzt ist. Dieser Mechanismus besteht darin, ein gültiges Kerberos -Ticket zu erwerben, bevor eine Verbindung zur Db2 -Datenbank hergestellt wird. Dieser Parameter ermöglicht die Angabe einer Kerberos -Keytab-Datei, die zum Erwerb eines gültigen Kerberos -Tickets verwendet wird. Es muss mit einer Werteliste spezifiziert werden, die auf der folgenden Vorlage basiert:

instance1:/path/keytab1,instance2:/path/keytab2,...

Mit einer solchen Liste kann man bei Bedarf mehrere Db2 -Instanzbenutzer-Schlüsseltabellen angeben.

Eine Kerberos -Keytab-Datei, die auf diesen Parameter eingestellt ist, wird verwendet, wenn Optim High Performance Unload im Hintergrund den Befehl "kinit" ausführt. Dieser Parameter ist obligatorisch, wenn der Parameter instances_krb_principal angegeben wird. Bei einer Keytab-Datei, die auf diesen Parameter eingestellt ist, müssen die Berechtigungen auf den Db2 -Instanzbenutzer beschränkt sein, dem sie zugeordnet ist.

...
instances_krb_keytab=db2inst:/home/db2inst/INSTANCE_KEYTAB.keytab
...

Einschränkung : Dieser Parameter kann nur in der Optim High Performance Unload globalen Konfigurationsdatei

instances_krb_principal

Verwenden Sie diesen Parameter, um die Verwendung eines Kerberos -Authentifizierungsmechanismus zu aktivieren, Optim High Performance Unload, wenn die Option LOCK oder FLUSH BUFFERPOOLS auf YES gesetzt ist. Dieser Mechanismus besteht darin, ein gültiges Kerberos -Ticket zu erwerben, bevor eine Verbindung zur Db2 -Datenbank hergestellt wird. Dieser Parameter ermöglicht die Angabe eines Kerberos -Prinzipalen, der zum Erwerb eines gültigen Kerberos -Tickets verwendet wird. Es muss mit einer Werteliste spezifiziert werden, die auf der folgenden Vorlage basiert:

instance1:PRINCIPAL1,instance2:PRINCIPAL2,...

Mit einer solchen Liste kann man bei Bedarf mehrere Db2 -Instanzbenutzer angeben.

Ein auf diesen Parameter eingestellter Kerberos -Hauptparameter wird verwendet, wenn Optim High Performance Unload im Hintergrund den Befehl "kinit" ausführt. Dieser Parameter ist obligatorisch, wenn der Parameter instances_krb_keytab angegeben wird.

...
instances_krb_principal=db2inst:INSTANCE_PRINCIPAL
...

Einschränkung : Dieser Parameter kann nur in der Optim High Performance Unload globalen Konfigurationsdatei

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 seine Netzwerkkommunikation erstellten Sockets können über einen längeren Zeitraum inaktiv bleiben. 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. Aufgrund einer unerwarteten Unterbrechung einer der Steckdosen kann eine Optim High Performance Unload aufgabe nicht erfolgreich abgeschlossen werden.

Um eine solche Situation zu vermeiden, Optim High Performance Unload kann seine Sockets mit spezifischen Keepalive-Eigenschaften 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 socket-Zeitintervall zwischen leeren Paketen kann unabhängig von den Socket-Einstellungen eines beliebigen generischen Betriebssystems angepasst werden.

Dieser Parameter aktiviert den Optim High Performance Unload keepalive-Mechanismus.

Dieser Parameter kann auf drei Arten festgelegt werden:

• mit dem Wert -1: Deaktiviert die Keepalive-Abstimmung, sodass die Optim High Performance Unload sockets erstellt werden, ohne dass die Aktivität auf ihnen künstlich aufrechterhalten werden kann.
• mit dem Wert 0 (Standardwert): Aktiviert die Keepalive-Einstellung, sodass die Optim High Performance Unload sockets mit der Fähigkeit erstellt werden, eine Aktivität auf ihnen künstlich aufrechtzuerhalten. Das Zeitintervall zwischen den Aktivierungspaketen beachtet den auf der Betriebssystemebene festgelegten Wert.
• mit einem positiven numerischen Wert: ermöglicht die Keepalive-Abstimmung für Optim High Performance Unload steckdosen. 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 Sie Optim High Performance Unload im Standalone-Modus gegen ein verschlüsseltes Backup ausgeführt wird, verwenden Sie diesen Parameter, um den absoluten Pfad der zu berücksichtigenden Db2 -Keystore-Datei anzugeben. 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 einem solchen Fall die Informationen zum im Backup enthaltenen Schlüsselspeicher möglicherweise nicht für den Computer gültig sind, auf dem Optim High Performance Unload ausgeführt wird.

keystore_lock

Bei der Ausführung Optim High Performance Unload in einer verschlüsselten Umgebung, die auf der Verwendung eines lokalen PKCS#12 -Schlüsselspeichers basiert, wird das IBM GSKit-Tool im Hintergrund ausgeführt, um Informationen aus diesem Schlüsselspeicher zu erhalten. Abhängig von der IBM GSKit-Version kann dieses Tool nicht mehrfach parallel ausgeführt werden, um auf denselben PKCS#12 -Keystore zuzugreifen. Daher kann es bei Optim High Performance Unload mehrere Prozesse parallel für Aufgaben ausgeführt werden, die Informationen aus demselben PKCS#12 -Schlüsselspeicher abrufen müssen, kann es zu zeitweiligen Fehlern kommen, die durch die Ausführung des IBM GSKit-Tools verursacht werden. Setzen Sie diesen Parameter, um eine solche Situation zu vermeiden und den geschützten Zugriff auf einen PKCS#12 -Keystore zu aktivieren. Der zugeordnete Wert muss ein absoluter Dateiname sein und die entsprechende Datei muss vorhanden sein. Wenn dieser Parameter gesetzt ist, Optim High Performance Unload wird ausschließlich die Datei gesperrt, die vor dem Aufruf des IBM GSKit-Tools konfiguriert wurde. Diese Sperre wird freigegeben, wenn das IBM GSKit-Tool zurückgegeben wird.

Hinweis: Informationen dazu, ob Ihre IBM GSKit-Version betroffen ist, finden Sie in der IBM GSKit-Dokumentation.

Beispiel:

...
keystore_lock=/home/i1111/kst.lck
...

keystore_type

Wenn Sie Optim High Performance Unload im Standalone-Modus gegen ein verschlüsseltes Backup ausgeführt wird, verwenden Sie diesen Parameter, um den Typ der zu berücksichtigenden Db2 -Keystore-Datei anzugeben. 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 einem solchen Fall die Informationen zum im Backup enthaltenen Schlüsselspeicher möglicherweise nicht für den Computer gültig sind, auf dem Optim High Performance Unload ausgeführt wird.

krb_keytab

Verwenden Sie diesen Parameter, um die Verwendung eines Kerberos -Authentifizierungsmechanismus in Optim High Performance Unload für den Benutzer, der sie gestartet hat, Dieser Mechanismus besteht darin, ein gültiges Kerberos -Ticket zu erwerben, bevor eine Verbindung zur Db2 -Datenbank hergestellt wird. Dieser Parameter ermöglicht die Angabe einer Kerberos -Keytab-Datei, die zum Erwerb eines gültigen Kerberos -Tickets verwendet wird. Eine Kerberos -Keytab-Datei, die auf diesen Parameter eingestellt ist, wird verwendet, wenn Optim High Performance Unload im Hintergrund den Befehl "kinit" ausführt. Dieser Parameter ist obligatorisch, wenn der Parameter krb_principal angegeben wird. Eine Keytab-Datei, die auf diesen Parameter eingestellt ist, muss über Berechtigungen verfügen, die auf den Benutzer beschränkt sind, der sie gestartet hat Optim High Performance Unload.

...
krb_keytab=/home/user/USER_KEYTAB.keytab
...

Einschränkung : Dieser Parameter kann nur in der Optim High Performance Unload benutzerspezifischen Konfigurationsdatei

krb_principal

Verwenden Sie diesen Parameter, um die Verwendung eines Kerberos -Authentifizierungsmechanismus in Optim High Performance Unload für den Benutzer, der sie gestartet hat, Dieser Mechanismus besteht darin, ein gültiges Kerberos -Ticket zu erwerben, bevor eine Verbindung zur Db2 -Datenbank hergestellt wird. Dieser Parameter ermöglicht die Angabe eines Kerberos -Prinzipalen, der zum Erwerb eines gültigen Kerberos -Tickets verwendet wird. Ein auf diesen Parameter eingestellter Kerberos -Hauptparameter wird verwendet, wenn Optim High Performance Unload im Hintergrund den Befehl "kinit" ausführt. Dieser Parameter ist obligatorisch, wenn der Parameter krb_keytab angegeben wird.

...
krb_principal=USER_PRINCIPAL
...

Einschränkung : Dieser Parameter kann nur in der Optim High Performance Unload benutzerspezifischen Konfigurationsdatei

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 Kürzungsgröße wird ignoriert, wenn die Optim High Performance Unload aufgabe 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 Wert, der für die Größe der abgeschnittenen LOB-Daten angegeben wird, wenn sie integriert ist, kann nicht auf einen Wert kleiner als 32Kboder größer als 1024Kbgesetzt werden.

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

...
lobinlinesize=64
...

maxmemory

Verwenden Sie diesen Parameter, um die Obergrenze des Systemspeichers in Bytes festzulegen, die Optim High Performance Unload verwendet werden kann. Wenn der angegebene Wert zu niedrig ist, um mit dem Entladen fortzufahren, Optim High Performance Unload werden die Mindestanforderungen verwendet.

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.

maxthreads

Verwenden Sie diesen Parameter, um die maximale Anzahl der Verarbeitungsthreads anzugeben, die Optim High Performance Unload verwendet werden können. Sie können diesen Parameter angeben, um den Verarbeitungsaufwand für Entladungen bei kleinen Tabellen zu beschränken. Wenn Sie für diesen Parameter einen niedrigeren Wert festlegen, können Optim High Performance Unload mehrere Tabellen gleichzeitig mit weniger Verarbeitungsthreads zu entladen. Der Mindestwert für diesen Parameter ist 1 und der Maximalwert entspricht der Prozessorzahl.

Wenn Sie beispielsweise über 4 verfügbare Prozessoren verfügen und TABLE1, TABLE2 und TABLE3 entladen möchten, verarbeitet die Option maxthreads=1Optim High Performance Unload verarbeitet alle drei Tabellen gleichzeitig mit jeweils einem Verarbeitungsthread.

maxunstaging

Dieser Konfigurationsparameter ermöglicht es, die Anzahl der parallel verarbeiteten Tabellen für den Unstaging-Schritt zu begrenzen. Bei der Ausführung Optim High Performance Unload beim Entladen von Daten aus einer Sicherung wird während des Lesens dieser Daten aus der Sicherung ein Staging-Schritt durchgeführt. Wenn dieser Zwischenspeicherschritt beendet wird, werden standardmäßig so viele Threads wie zu entladende Tabellen zum Aufheben der Zwischenspeicherung der Daten gestartet, die diesen Tabellen zugeordnet sind. Wenn die Anzahl der zu verarbeitenden Tabellen signifikant ist, kann dies zu einem wichtigen Anstieg der Ressourcen führen, die der Gesamtverarbeitung zugeordnet sind.

Um diese Erhöhung zu begrenzen, kann die maximale Anzahl Tabellen angegeben werden, die parallel nicht zwischengespeichert werden können. Dadurch kann die Anzahl der parallel gestarteten Threads für den Schritt zum Aufheben der Bereitstellung gesteuert werden. Wenn diese maximale Anzahl erreicht ist, wird der Schritt zum Aufheben der Zwischenspeicherung einer neuen Tabelle automatisch gestartet, wenn dieser Schritt für einen anderen beendet wird.

Beispiel:

...
maxunstaging=100
...

memory_limit

Um festzulegen, dass Optim High Performance Unload so viel Speicher wie nötig verwenden kann, um eine bestimmte Aufgabe abzuschließen, setzen Sie memory_limit auf no. Sie können memory_limit nur festlegen, wenn Sie den Parameter für die Konfigurationsdatei allow_unlimited_memory bereits auf yesgesetzt 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. Es muss in die Konfigurationsdatei auf dem Computer eingefügt werden, auf dem Optim High Performance Unload aufgerufen wird, damit die Datenmigration durchgeführt werden kann.

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. Eine Latenzzeit kann am Anfang der Ladekomponente auftreten, bevor sie die zu konsumierenden Datenströme öffnet, insbesondere wenn die Migration auf ein Db2 -Ziel durchgeführt wird, für das die Ladekomponente das Db2 -Ladedienstprogramm unter der Abdeckung aufruft. Für das Öffnen der Kanäle durch die Lesekomponente gilt eine Zeitüberschreitung, die standardmäßig 30 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.

monitor

Setzen Sie diesen Parameter auf yes , um die Aufgabenüberwachung für jede Optim High Performance Unload ausführung zu aktivieren. Der Standardwert ist no.

nbcpu

Mit diesem Parameter können Sie die Anzahl der gestarteten Arbeitseinheiten begrenzen. Dieser Wert wirkt sich sowohl auf die Speichernutzung als auch auf den Grad der Parallelität aus Optim High Performance Unload. Optim High Performance Unload verwendet diesen Wert als Obergrenze für die Parallelisierung der Verarbeitung. Der Maximalwert dieses Parameters ist die Anzahl der Prozessoren im System (Standardeinstellung). Der Mindestwert ist 1.

Wenn Sie beispielsweise über 4 verfügbare Prozessoren verfügen und TABLE1, TABLE2 und TABLE3 mit der Option nbcpu=2 entladen möchten, Optim High Performance Unload jede Tabelle nacheinander mit 2 Verarbeitungsthreads verarbeitet.

netservice

Verwenden Sie diesen Parameter, um den Servicenamen anzugeben, der mit der Optim High Performance Unload netzwerkfunktion in der Servicesystemdatei Die Optim High Performance Unload installation legt diesen Parameter automatisch fest.

nettohosts

Achtung: Dieser Parameter ist jetzt veraltet. Erstellen Sie eine db2hpu.map -Konfigurationsdatei im Unterverzeichnis cfg Ihres Hauptinstallationsverzeichnisses Optim High Performance Unload installationsverzeichnis an, um die Netzwerknamen und Hostnamen-Zuordnungen 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 identifizieren. 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 verwendet diesen Parameter, um zu bestimmen, welcher Hostname mit einem bestimmten Netzwerknamen verknüpft ist. 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...

network_compression

Je nach Entfernung zwischen den an einer bestimmten Aufgabe beteiligten Maschinen oder je nach Netzwerkdurchsatz können sich Leistungsaspekte im Zusammenhang mit der über das Netzwerk übertragenen Datenmenge ergeben. In einem solchen Fall könnte es interessant sein, die übertragene Datenmenge zu reduzieren, indem sie vor dem Senden auf der einen Seite komprimiert und beim Empfang aus dem Netzwerk auf der anderen Seite dekomprimiert wird. Dadurch könnte sich die Gesamtzeit für die Bearbeitung der ausgeführten Aufgabe verkürzen.

Die Komprimierung der über das Netzwerk gesendeten Daten kann durch das Festlegen dieses Parameters in der db2hpu.cfg -Konfigurationsdatei aktiviert werden. Sein Wert kann zlib sein, um die ZLib-Komprimierung zu verwenden, vorausgesetzt, die ZLib-Bibliothek ist auf den Rechnern verfügbar, die die zu komprimierenden Daten austauschen. Es kann erforderlich sein, auch den Konfigurationsparameter zlib_api festzulegen, wenn der Name der ZLib-Bibliothek nicht automatisch erkannt wird.

Das folgende Beispiel zeigt diese Parametereinstellung:

...
network_compression=zlib
...

odpp_path

odpp_version

Wenn Optim High Performance Unload für eine ODPP-Maskierungsverarbeitung verwendet werden und die Optionen PATH und VERSION der DATAMASKING-Klausel in der zugehörigen Steuerungsdatei ausgelassen werden, Optim High Performance Unload versucht, den erwarteten ODPP-Pfad und die erwartete ODPP-Version aus der db2hpu.cfg -Konfigurationsdatei zu erhalten. 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.

Für weitere Informationen: 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 die Option LOAD der DATAMASKING-Klausel in der zugehörigen Steuerungsdatei ausgelassen wird, Optim High Performance Unload wird versucht, die erwarteten Bibliotheksnamen aus der db2hpu.cfg -Konfigurationsdatei 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 PARSER-Bibliothek der Option LOAD in der Klausel DATAMASK der Steuerdatei).
• odpp_api_adapter (anstelle der Bibliothek ADAPTER der Option LOAD in der Steuerdateiklausel DATAMDARIN).
• odpp_api_provider (anstelle der Bibliothek PROVIDER der Option LOAD in der Steuerdateiklausel DATAMDARIN).

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.

Für weitere Informationen DATAMASKING

openssl_api_crypto

Geben Sie mit diesem Parameter den Namen der OpenSSL -Verschlüsselungsbibliothek an, wenn diese nicht automatisch erkannt wird.

openssl_api_ssl

Verwenden Sie diesen Parameter, um den Namen der SSL-Bibliothek OpenSSL anzugeben, wenn sie nicht automatisch erkannt wird.

openssl_crypto_Verwendung

Verwenden Sie diesen Parameter, um die Verwendung von OpenSSL für die Datenentschlüsselung und das Datenhashing zu aktivieren bzw. zu inaktivieren. Mögliche Werte sind "Ja" und "Nein". Der Standardwert ist 'JA'. Möglicherweise muss diese Verwendung inaktiviert werden, wenn die installierte OpenSSL -Version die integrierte CPU-Hardwarebeschleunigung nicht unterstützt.

progress_monitoring

Verwenden Sie diesen Parameter, wenn Sie die Möglichkeit zur Überwachung des Optim High Performance Unload fortschritts der Aufgabenausführung Dazu muss dieser Parameter auf einen numerischen Wert größer als 0 gesetzt werden. Der Wert ist eine Anzahl von Sekunden, die einem Überwachungszeitlimit entspricht. Der Standardwert ist 0. Wenn der Wert größer als 0 ist, wird jedes Mal, wenn das Überwachungszeitlimit erreicht wird, eine Informationsnachricht INZM092I mit einem Verweis auf die aktuelle Zeit im Ausführungsbericht gesendet.

Das folgende Beispiel zeigt diese Parametereinstellung:

...
progress_monitoring=600
...

Die Einstellung dieses Parameters kann bei der Ausführung einer Optim High Performance Unload, die lange dauert, hilfreich sein, da es möglicherweise unmöglich ist, den Fortschritt ihrer Ausführung anhand ihres Abschlussberichts zu messen. Abgesehen von den üblichen Nachrichten, die den Anfang und das Ende der Steuerungs-und Verarbeitungsschritte markieren, enthält der Bericht keine Nachricht, die einen Zeitbegriff enthält. Durch die Verwendung dieses Parameters kann eine solche Situation überwunden und reguläre Informationsnachrichten generiert werden, um den Fortschritt einer solchen Ausführung zu markieren.

shared_datapart_processing

Die gültigen Werte sind yes und no. Der Standardwert ist 'no' (Nein). Die Einstellung dieses Parameters gilt für jede Optim High Performance Unload aufgabe. 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. Für weitere Informationen siehe SHARED_DATAPART_PROCESSING.

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
...

Für weitere Informationen Konfiguration im Zusammenhang mit der Verarbeitung von Daten-Partitionen

stacksize

Verwenden Sie diesen Parameter, um die maximale Größe für den Stapel im Zusammenhang mit einem Optim High Performance Unload prozess. Der zugewiesene Wert muss numerisch sein und in KB angegeben werden. Es kann notwendig sein, die Größe des Stapels für eine Optim High Performance Unload ausführung zu erhöhen, insbesondere wenn die Standardgröße für diesen Stapel nicht ausreicht, um eine Aufgabe basierend auf einer tiefen rekursiven SQL-Anweisung erfolgreich 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. Durch Ändern dieses Umgebungswerts könnte ein anderer Wert für die Stapelgröße von Optim High Performance Unload, aber es würde sich bei jedem Befehl verhalten, der von dieser aktualisierten Umgebung aus gestartet wird. Die Verwendung dieses Parameters ermöglicht es, die Stapelgröße nur für die Optim High Performance Unload aufgaben, ohne dass dies Auswirkungen auf separate Anwendungen hat.

Beispielsweise würde die folgende Einstellung es ermöglichen, die Stapelgröße für Optim High Performance Unload aufgaben auf 256Mb:

...
stacksize=262144
...

Hinweis: Der stacksize Parameter ist nur auf den Plattformen Linux und Unix verfügbar.

stagedir

Verwenden Sie diesen Parameter, um das Verzeichnis anzugeben, in dem Optim High Performance Unload temporäre Dateien generiert werden sollen, wenn Sie Daten aus Sicherungsabbildern 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: Um den Staging-Bereich zu vergrößern, müssen die Datenbankpartitionspositionen als symbolische Links zu physischen Pfaden erstellt werden, die auf unterschiedlichen Dateisystemen landen. Wenn diese Speicherpositionen als physische Verzeichnisse an derselben Stammposition erstellt werden, wird der Staging-Bereich nicht vergrößert.

Beispiel : Angenommen, Sie haben die folgende Konfiguration für eine Entladeoperation aus Backups einer Db2 -Instanz, die drei Datenbankpartitionen hat: #1, #2, #3:

...

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

Verwenden Sie diesen Parameter, um die Datei anzugeben, in der der Ausführungsbericht einer Optim High Performance Unload aufgabe, die durch den Aufruf der Optim High Performance Unload gespeicherten Prozedur ausgeführt wird, geschrieben wird. Wenn die Optim High Performance Unload gespeicherte Prozedur ausgeführt wird, wird der mit der zugrunde liegenden Ausführung verknüpfte Bericht Optim High Performance Unload ausführung wird über den Ausgabeparameter STDERR der gespeicherten Prozedur verarbeitet. Dieser Parameter hat den Datentyp CLOB und ist über den Befehlszeilenprozessor Db2 auf 8192 Byte begrenzt. 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.

Dieser Parameter ist der Mittelwert, der so konfiguriert werden muss Optim High Performance Unload, 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 Namen der API-Bibliothek an, die dynamisch geladen werden soll, wenn Sie Daten aus Backup-Images entladen, die in Tivoli® Storage Managergespeichert 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 Berechtigungen für die generierten Dateien werden dann durch den umask-Wert von Root eingeschränkt. Wenn Sie eine automatische Systemmigration durchführen, kann diese Einschränkung problematisch sein, da Db2 Load Datendateien benötigt, um für den Instanzbenutzer der Zieldatenbank lesbar zu sein. 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 Optim High Performance Unload option "umask" so einstellen, dass das Programm diese restriktive "umask" überschreiben kann.

Die Definition der umask-Funktion basiert auf der UNIX-umask-Definition: drei Oktalziffern werden verwendet, um Berechtigungen für Benutzer/Gruppe/andere Masken 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.
• Die umask-Definition in Optim High Performance Unload erlaubt es nicht, Datendateien mit jeder Art von Zugriffsrechten zu erstellen. Optim High Performance Unload die Generierung von Datendateien wird immer mit 644 Zugriffsrechten (rw-r--r--) abgefragt. Wenn die umask restriktiver ist, werden die Zugriffsrechte reduziert. Wenn der umask-Wert weniger restriktiv ist, bleibt die Zugriffsberechtigung rw-r--r--.

use_netname

Verwenden Sie diesen Parameter, um die Verwendung von Netznamen zu aktivieren oder zu inaktivieren, wenn sie in der Datei db2nodes.cfg der betroffenen Db2 -Instanz verwendet werden. Solche Netznamen entsprechen im Allgemeinen spezialisierten Hochgeschwindigkeitsnetzschnittstellen. Sie können wählen, ob Sie die Optim High Performance Unload netzwerkkommunikation über diese Schnittstellen abzuwickeln oder nicht. Standardmäßig ist dieser Parameterwert intern auf yes gesetzt und die Verwendung von Netznamen daher standardmäßig aktiviert.

use_stats

Verwenden Sie diesen Parameter, um anzugeben, ob Sie Optim High Performance Unload tabellenstatistiken aus dem Katalog berücksichtigen möchten. Diese Informationen ermöglichen es, Optim High Performance Unload die optimale Anzahl der Verarbeitungsthreads zu bestimmen, die beim Entladen der Tabellen verwendet werden sollen.

Gültige Werte für diesen Parameter sind yes oder no. Wenn Sie yes angeben, Optim High Performance Unload kann die Verarbeitung optimieren, indem größere Tabellen parallel entladen werden. Diese Option ist nur effektiv, wenn die Statistikdaten in den Tabellen aktuell sind.

Achtung : Die Nutzung der Option yes kann Optim High Performance Unload unter bestimmten Umständen die Leistung erheblich beeinträchtigen. Wenn beispielsweise eine bestimmte Tabelle veraltete Statistikinformationen enthält, die zeigen, dass die Tabelle nur wenige oder keine Daten enthält, obwohl die Tabelle inzwischen aktualisiert wurde und mehrere Millionen Zeilen enthält, Optim High Performance Unload wird die Tabelle immer noch als klein betrachtet und nur ein Verarbeitungs-Thread zum Entladen verwendet.

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' bedeutet, dass die Backup-Images von einem XBSA-ähnlichen Speichertool verwaltet werden.

zlib_api

Verwenden Sie diesen Parameter, um den Namen der ZLib-Bibliothek anzugeben, wenn sie nicht automatisch erkannt wird.