Configuración 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

Parámetros del archivo de configuración

allow_unlimited_memory

Si desea permitir Optim High Performance Unload ignorar los valores ulimit que limitan el consumo de memoria para el shell asociado, establezca este parámetro en yes. Puede utilizar este parámetro si falla una descarga debido a las restricciones de límites de memoria. El valor predeterminado es no. allow_unlimited_memory es un requisito previo para ignorar de forma eficaz el límite de memoria, estableciendo memory_limit en no.

Restricción: Este parámetro sólo se aplica a plataformas Linux y UNIX y sólo se puede especificar en el archivo db2hpu.cfg maestro y no en ningún archivo de configuración especificado por el usuario.

blu_parallelism

Utilice este parámetro para determinar el número de columnas de una tabla organizada por columnas que se deben procesar en paralelo. De forma predeterminada, al descargar varias columnas de una tabla organizada en columnas, se produce un paralelismo en el procesamiento con un número de columnas procesadas en paralelo que se determina automáticamente. Este parámetro permite establecer un valor de su elección en este número. El valor asignado debe ser numérico. A continuación se muestra un ejemplo de su valor:

...
blu_parallelism=10
...

Consulte Consideraciones sobre el rendimiento al descargar una tabla organizada por columnas para obtener más información.

bufsize

Utilice este parámetro para definir el tamaño de búfer predeterminado que se utiliza cuando Optim High Performance Unload genera el archivo de salida. El valor es el número real de bytes que se utilizan para este almacenamiento intermedio. El valor mínimo aceptado es 262144 (256 kilobytes) y el valor máximo aceptado es 2097152 (2 MB). El valor más bajo utilizará menos memoria durante el proceso, pero disminuirá la eficacia de E/S. La razón por la que el valor máximo está limitado a 2 MB es que un valor de más de 2 MB utilizará más memoria, pero probablemente no producirá un aumento notable de eficiencia de E/S. Si el archivo de salida está en el mismo disco físico que el archivo Optim High Performance Unload (contenedor o copia de seguridad), entonces un valor mayor podría mejorar el rendimiento de Optim High Performance Unload.

Por ejemplo, si tiene 4 procesadores disponibles y quiere descargar TABLE1, TABLE2 y TABLE3, con la opción bufsize=262144, Optim High Performance Unload procesa cada tabla consecutivamente con 4 hilos de procesamiento y búferes de escritura de 256 KB cada uno.

compression_minsize

La compresión de datos puede ser mucho menos eficiente si la cantidad de datos a comprimir es pequeña. Y en tal caso, es mejor no comprimirlo. Si se habilita la capacidad de comprimir los datos enviados a través de la red, es posible elegir el tamaño mínimo que se debe considerar para comprimir estos datos, configurando este parámetro en el archivo de configuración db2hpu.cfg . El valor que se le asigne debe ser numérico, entre 0 y 10, cuya unidad es el Kb. Su valor predeterminado es 4Kb. Cuando este parámetro se establece en un valor determinado, si la cantidad de datos que se van a transferir es inferior a este límite, no se comprime antes de ser enviada.

A continuación se muestra un ejemplo de esta configuración de parámetros, con un valor correspondiente a un tamaño mínimo e 8Kb :

...
compression_minsize=8
...

db2api_monitoring

Solo para plataformas Linux y UNIX. El uso de las opciones Optim High Performance Unload FLUSH BUFFERPOOLS y LOCK implica llamar a las API de Db2®, que adquirirán bloqueos de Db2. La db2api_monitoring variable de configuración puede utilizarse para establecer un límite de tiempo tras el cual Optim High Performance Unload generará mensajes informativos para indicar que su procesamiento está a la espera de bloqueos de Db2 antes de poder continuar. Los bloqueos adquiridos al utilizar estas Optim High Performance Unload opciones no respetan ninguna condición de supervisión de bloqueo. Esta configuración de supervisión se realiza estableciendo el valor del parámetro db2api_monitoring del archivo db2hpu.cfg en un número de segundos. El valor predeterminado de este parámetro es 0. Si no se ha configurado ninguna supervisión, o el valor del parámetro se ha establecido en 0, el mecanismo de supervisión en las API de Db2 para el bloqueo y vaciado de las operaciones de agrupaciones de almacenamientos intermedios está inhabilitado. A continuación se muestra un ejemplo de uso del parámetro:

...
db2api_monitoring=120
...

Cuando el mecanismo está habilitado cada vez que se alcanza el valor, se envía un mensaje informativo, que especifica la operación para la que se ha producido la supervisión. Las operaciones se identifican por una de las siguientes cadenas:

• BLOQUEAR: Esta operación se realiza antes de la descarga de datos, para bloquear las actualizaciones de la tabla en cuestión durante el Optim High Performance Unload proceso (cuando se establece la opción LOCK YES).

• LOCK RESET: Esta operación se realiza después de la descarga de datos, para liberar el bloqueo de la tabla (cuando la opción LOCK YES está establecida).

• FLUSH BUFFERPOOLS: Esta operación se realiza antes de la descarga de datos para registrar y vaciar en disco los datos en agrupaciones de almacenamiento intermedio (cuando la opción FLUSH BUFFERPOOLS YES está establecida).

• FLUSH BUFFERPOOLS RESET: Esta operación se realiza después de la descarga de datos para confirmar el registro de datos en agrupaciones de almacenamiento intermedio (cuando la opción FLUSH BUFFERPOOLS YES está establecida).

Por ejemplo : Este Optim High Performance Unload informe de ejecución ilustra una situación en la que se alcanza el tiempo de supervisión al realizar una operación LOCK:

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

En este informe, el valor de supervisión se ha alcanzado tres veces al realizar la operación de bloqueo. En función del valor de supervisión que se haya definido, puede concluir que este valor se ha elegido incorrectamente (se ha establecido en un valor demasiado pequeño para el tiempo de duración de esta operación) o que está sucediendo algo inesperado con la duración de esta operación. La ejecución se ha completado correctamente con la descarga de los datos. Si la Optim High Performance Unload operación de bloqueo no se hubiera completado en absoluto, el mensaje de información habría seguido generándose hasta que Optim High Performance Unload se terminara manualmente o hasta que Db2 liberara los bloqueos que impedían Optim High Performance Unload progresar.

db2api_timeout

Solo para plataformas Linux y UNIX. Utilice este parámetro y el db2api_monitoring para finalizar la ejecución de una Optim High Performance Unload operación que aún se está ejecutando cuando se alcanza el valor de tiempo del db2api_monitoring alcanzado. Los valores posibles del parámetro db2api_timeout son yes o no. El valor predeterminado es no. Si no hay ningún valor establecido para el parámetro db2api_monitoring , el valor del parámetro db2api_timeout en yes se ignorará. A continuación se muestra un ejemplo de uso del parámetro:

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

Cuando termina la ejecución, se envía un mensaje de error. El mensaje especifica la operación para la que se ha producido el tiempo de espera excedido. La lista de las operaciones supervisadas está en la descripción del parámetro db2api_monitoring.

Por ejemplo : Este Optim High Performance Unload informe de ejecución ilustra una situación en la que se alcanza el tiempo de supervisión al realizar una operación LOCK, lo que da lugar a un tiempo de espera de ejecución:

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)
 

En este informe, se ha alcanzado el valor de supervisión al realizar la operación de bloqueo. La Optim High Performance Unload ejecución se interrumpió y finalizó por error.

db2compr_api

Utilice este parámetro para especificar el nombre de la biblioteca de compresión predeterminada que se cargará cuando se realice la descarga de una imagen de copia de seguridad comprimida.

db2dbdft

Este parámetro corresponde al nombre de la base de datos que utiliza Optim High Performance Unload cuando no se proporciona un nombre de base de datos (opción de línea de comandos –d).

db2instance

Utilice este parámetro para especificar el nombre de instancia que utiliza Optim High Performance Unload cuando no se da un nombre de instancia (opción de línea de comandos –i).

db2promote

Utilice este parámetro para especificar si los usuarios que tienen la autorización Db2 para seleccionar de una tabla pero no tienen la autorización para realizar un QUIESCE SHARE en dicha tabla deben tener la autorización para ejecutar una descarga.

QUIESCE es necesario para descargar los datos en un estado coherente. Si db2promote está establecido en No, el valor predeterminado del parámetro LOCK se establece en NO. Este valor predeterminado se establece en YES. Los usuarios que no tienen autorización para utilizar SELECT y QUIESCE no resultarán afectados por la opción db2promote.

db2variables

Utilice este parámetro para especificar el uso de un archivo para establecer los valores de las variables de Db2 . Debe especificarse con una vía de acceso absoluta de un archivo que contenga una lista de nombres de variables de Db2 con sus valores.

A continuación se muestra un ejemplo de su valor:

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

dir_cfg

Cuando hay varias máquinas involucradas en una instancia de Db2, y la Optim High Performance Unload configuración es la misma en todas estas máquinas, utilice este parámetro para compartir los mismos Optim High Performance Unload archivos de configuración. Los Optim High Performance Unload archivos de configuración que se pueden compartir son:

• db2hpu.cfg

• db2hpu.locale

• db2hpu.map

• db2hpu.debug

• db2hpu.trace

• remote.locale

Para compartir dichos archivos:

- Copie todos los archivos de configuración de una máquina en una ubicación compartida.

- Actualice el archivo de configuración db2hpu.cfg en el directorio cfg de cada máquina; para ello, suprima todo el contenido y añada solo el parámetro dir_cfg en él.

- Defina el parámetro en la vía de acceso absoluta del directorio en el que están ubicados todos los archivos de configuración compartidos.

Nota: Para cada máquina, se utilizará la configuración compartida si el archivo de configuración db2hpu.cfg contiene sólo el parámetro dir_cfg con la ubicación compartida. Si el parámetro dir_cfg no es el único parámetro o no existe el parámetro dir_cfg, se ignorará la configuración compartida y se utilizarán los Optim High Performance Unload se utilizarán los archivos de configuración de este equipo.

Importante: El valor del parámetro debe especificarse como una vía de acceso absoluta del directorio donde se encuentran los archivos de configuración compartidos. Por ejemplo, si /sharedfs es la ubicación compartida de los archivos de configuración, debe especificar dir_cfg=/sharedfs en cada uno de los archivos de configuración locales.

doubledelim

Utilice este parámetro para especificar el valor predeterminado para la opción DOUBLE DELIM en el archivo de control. Este parámetro se aplica so lo a los formatos de salida DEL o DELIMITED. Si se establece en ON, se exploran las columnas de tipo binario para ver si aparece el delimitador y se duplica cada aparición descubierta. Si se establece en BINARY, solo se exploran las columnas de caracteres que tienen FOR BIT DATA y las columnas binarias. Si se establece en OFF, no se realiza ninguna exploración. El formato predeterminado es BINARY.

Puede obtener el mejor rendimiento realizando la menor exploración posible. Es posible que pueda evitar explorar columnas de caracteres si selecciona un carácter para utilizarlo como delimitador que sepa que no se utiliza en los datos descargos. Si no puede utilizar un carácter que no se utilice en los datos descargados, establezca la opción DOUBLE DELIM en ON en los archivos de control, cuando sea necesario. Si prevé que los usuarios no establecerán la opción DOUBLE DELIM en ON cuando sea necesario, puede establecerla en el archivo de configuración. El usuario puede alterar temporalmente el valor que se crea aquí en sus archivos de control individuales.

graphic_even_padding

Este parámetro permite interferir en cómo se gestionan en un archivo de salida ASC los valores de las columnas GRAPHIC, VARGRAPHIC, LONG VARGRAPHIC y DBCLOB que incluyen un tamaño impar. De forma predeterminada, estos valores se rellenan con un byte de valor nulo, de modo que el área asociada en el archivo de salida tenga un tamaño par. Si no se desea aplicar un comportamiento de este tipo, es posible inhabilitar el relleno a un tamaño par de estos valores, estableciendo este parámetro en no. El valor predeterminado es YES.

A continuación se muestra un ejemplo de su valor:

...
graphic_even_padding=no
...

hidden

Para especificar que desea incluir las columnas ocultas en la descarga, establezca esta opción en yes. El valor predeterminado es no.

ignore_load_error

Este parámetro permite ignorar los errores que se producirían durante la ejecución del programa de utilidad Db2 Load, cuando se migra automáticamente una tabla.

Para alterar temporalmente este valor para una tarea específica, se puede especificar un valor diferente con la cláusula IGNORE_LOAD_ERROR en el archivo de control. Para más información, véase IGNORE_LOAD_ERROR.

Al ejecutar Optim High Performance Unload para una migración automática de una tabla a un entorno de Db2, se llama a la utilidad de carga ( Db2 ) para cargar los datos en la tabla de destino. De forma predeterminada, si se produce un error durante la ejecución de Db2 Load, la migración automática se detiene y termina con un error. Si hay varias tablas a migrar dentro de la misma ejecución, el proceso se detiene después de que se encuentre un paso de carga de datos anómalo. Como resultado, las tablas restantes cuya migración todavía no se ha iniciado no se procesan en absoluto.

Para el caso en que haya un conjunto de tablas que procesar, con el fin de procesar las tablas restantes incluso si la migración de al menos una tabla hubiera fallado por cualquier motivo en el nivel de carga de Db2, se puede configurar Optim High Performance Unload para que ignore cualquier error encontrado por la utilidad Db2 Load. La migración de todas las tablas que se deben tener en cuenta se procesaría, incluso si al menos una no se puede migrar debido a un error en el nivel de carga de Db2 . Al final del proceso, uno tendría que averiguar si habría tablas cuya migración habría fallado debido a un error encontrado por el programa de utilidad Db2 Load, para poder ocuparse de su caso particular. Si realmente se encuentra un error, hay mensajes que lo muestran en el informe de ejecución y, también, un mensaje que menciona que se ignora este error. Sin embargo, el resto de las tablas se procesa como estaba previsto.

Si se establece este parámetro en 'yes' permite ignorar los errores que se producen durante la ejecución del programa de utilidad Db2 Load. Los valores posibles son 'yes' o 'no'. Su valor predeterminado es 'no'.

A continuación se muestra un ejemplo de su valor:

...
ignore_load_error=yes
...

ignore_nonexistent_table

Este parámetro permite ignorar los errores causados por nombres de tabla no existentes estableciéndolos en 'yes' en el archivo de configuración db2hpu.cfg .

Los valores posibles son 'yes' o 'no'. Su valor predeterminado es 'no'.

Al realizar una descarga de varias tablas durante la misma ejecución, con una cláusula ONLY TABLES o una cláusula EXCEPT TABLES o una cláusula INTO TABLES o una cláusula TABLES MODIFIERS especificadas también, por omisión se envía un error si un nombre especificado en esta cláusula no corresponde a una tabla existente y el proceso se detiene. Como resultado, el resto de las tablas que aún no se han procesado no se descargan.

Tal situación puede ser dolorosa para determinar fácilmente las tablas que no se han podido procesar. Para facilitar las cosas en tal situación, se puede lanzar Optim High Performance Unload para que ignore cualquier error causado por una tabla inexistente. La descarga de todas las tablas a considerar se procesaría incluso si al menos un nombre no se corresponde con ninguna tabla. Al final del proceso, uno tendría que averiguar si habría nombres ignorados, con el fin de cuidar de su caso particular. Si realmente se encuentra una situación de este tipo, hay un mensaje que muestra que un nombre es desconocido dentro del informe de ejecución, y también un mensaje que menciona que este error se ignora. Sin embargo, el resto de las tablas se procesa como estaba previsto.

Para alterar temporalmente este valor para una tarea específica, se puede especificar un valor diferente con la cláusula IGNORE_NONEXISTENT_TABLE en el archivo de control. Para más información, consulte IGNORE_NONEXISTENT_TABLE.

A continuación se muestra un ejemplo de su valor:

...
ignore_nonexistent_table=yes
...

instances_krb_keytab

Utilice este parámetro para habilitar el uso de un mecanismo de autenticación de Kerberos en Optim High Performance Unload si la opción LOCK o FLUSH BUFFERPOOLS está establecida en YES. Este mecanismo consiste en adquirir un ticket válido de Kerberos, antes de establecer una conexión con la base de datos de Db2. Este parámetro permite especificar un archivo keytab de Kerberos que se utilizará para adquirir un ticket de Kerberos válido. Debe especificarse con una lista de valores, basada en la siguiente plantilla:

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

Con una lista de este tipo, se pueden especificar varios archivos keytab de usuarios de instancias de Db2, si es necesario.

Se utilizará un archivo keytab de Kerberos configurado con este parámetro cuando Optim High Performance Unload ejecutará un comando «kinit» en segundo plano. Este parámetro es obligatorio cuando se especifica el parámetro instances_krb_principal . Un archivo keytab configurado con este parámetro debe tener permisos limitados al usuario de la instancia de Db2 al que está asociado.

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

Restricción : Este parámetro solo se puede especificar en el Optim High Performance Unload archivo de configuración global.

instances_krb_principal

Utilice este parámetro para habilitar el uso de un mecanismo de autenticación de Kerberos en Optim High Performance Unload si la opción LOCK o FLUSH BUFFERPOOLS está establecida en YES. Este mecanismo consiste en adquirir un ticket válido de Kerberos, antes de establecer una conexión con la base de datos de Db2. Este parámetro permite especificar un principal de autenticación de red ( Kerberos ) que se utilizará para adquirir un ticket de autenticación de red ( Kerberos ) válido. Debe especificarse con una lista de valores, basada en la siguiente plantilla:

instance1:PRINCIPAL1,instance2:PRINCIPAL2,...

Con una lista de este tipo, se pueden especificar múltiples usuarios principales de instancias de Db2, si es necesario.

Un principal de Kerberos configurado con este parámetro se utilizará cuando Optim High Performance Unload ejecutará un comando «kinit» en segundo plano. Este parámetro es obligatorio cuando se especifica el parámetro instances_krb_keytab .

...
instances_krb_principal=db2inst:INSTANCE_PRINCIPAL
...

Restricción : Este parámetro solo se puede especificar en el Optim High Performance Unload archivo de configuración global.

ixftrunc

Utilice este parámetro para ahorrar espacio cuando descargue datos VARCHAR o VARGRAPHIC en formato IXF. Sólo se considerarán las columnas de estos dos tipos con un tamaño mayor que el valor proporcionado a este parámetro. Con este parámetro, cada valor descargado para estos tipos de columnas tendrá el tamaño según el número de caracteres reales en los datos en lugar de tener el tamaño máximo establecido para la columna. El valor predeterminado es 20.

keepalive_time

Los sockets creados por Optim High Performance Unload para sus comunicaciones de red pueden permanecer inactivas durante un largo periodo de tiempo. En concreto, esto puede ocurrir para un socket creado durante la migración automática de datos.

Durante la migración automática de datos, un socket se dejará inactivo durante los datos de la Carga de tabla de destino. Puede estar inactivo durante un largo periodo en función de cuánto tiempo tare la Carga del paso.

Algunos sistemas están configurados de forma que los sockets que permanecen inactivos demasiado tiempo se desconecten automáticamente por el propio sistema. Por ejemplo, se puede producir tal situación cuando un cortafuegos está implicado en la configuración de red. Como resultado de una desconexión inesperada de uno de sus enchufes, una Optim High Performance Unload tarea no puede completarse correctamente.

Para evitar esta situación, Optim High Performance Unload puede crear sus sockets con características específicas de keepalive. Cuando se crea un socket de esta forma, los paquetes vacíos se envían de forma regular a través de la propia capa de TPC/IP para asegurarse la pseudo-actividad. El Optim High Performance Unload intervalo de tiempo de conexión entre paquetes vacíos puede ajustarse independientemente de cualquier configuración de conexión del sistema operativo genérico.

Este parámetro activa el Optim High Performance Unload mecanismo de mantenimiento de conexión.

Hay tres maneras de establecer este parámetro:

• con el valor -1: desactiva la sintonización de keepalive, de modo que los Optim High Performance Unload se crean sockets sin la capacidad de mantener artificialmente una actividad en ellos.
• con el valor 0 (valor predeterminado): habilita la sintonización de mantenimiento para que los Optim High Performance Unload se crean sockets con la capacidad de mantener artificialmente una actividad en ellos. El intervalo de tiempo entre los paquetes de activación respetará el valor establecido en el nivel del sistema operativo.
• con un valor numérico positivo: habilita la sintonización de mantenimiento para Optim High Performance Unload sockets. El intervalo de tiempo entre los paquetes de activación se establece en el valor configurado en minutos.

Como ejemplo, el siguiente valor habilitará paquetes de activación de sockets cada 10 minutos:

...
keepalive_time=10
...

keystore_file

Cuando se ejecute Optim High Performance Unload en modo independiente contra una copia de seguridad cifrada, utilice este parámetro para especificar la ruta absoluta del archivo de almacén de claves de Db2 que se debe considerar. En función del tipo de almacén de claves (PKCS12, KMIP o PKCS#11), el archivo en cuestión es un archivo PKCS12 que contiene la clave maestra de cifrado que se debe utilizar o un archivo de texto que contiene la configuración del servidor KMIP asociado, o un archivo de texto que contiene la configuración de PKCS#11 asociado. Este parámetro es obligatorio cuando se ejecuta Optim High Performance Unload en modo independiente porque, en tal caso, la información relativa al almacén de claves contenida en la copia de seguridad podría no ser válida para el equipo en el que se ejecuta Optim High Performance Unload se ejecuta.

keystore_lock

Cuando se ejecuta Optim High Performance Unload en un entorno cifrado basado en el uso de un almacén de claves local de PKCS#12, ejecuta la herramienta GSKit de IBM en segundo plano para obtener información de este almacén de claves. Según la versión de IBM GSKit, esta herramienta no puede ejecutarse varias veces en paralelo para acceder al mismo almacén de claves PKCS#12. Como resultado, ejecutar Optim High Performance Unload varias veces en paralelo para tareas que necesitan obtener información del mismo almacén de claves de PKCS#12 podría provocar fallos intermitentes causados por la ejecución de la herramienta GSKit de IBM. Establezca este parámetro para evitar una situación de este tipo y habilite el acceso protegido a un almacén de claves PKCS#12. El valor que tenga asignado debe ser un nombre de archivo absoluto, y el archivo correspondiente debe existir. Cuando se establece este parámetro, Optim High Performance Unload bloquea exclusivamente el archivo configurado antes de llamar a la herramienta GSKit IBM. Este bloqueo se libera cuando se devuelve la herramienta IBM GSKit.

Nota: Consulte la documentación de IBM GSKit para determinar si la versión de IBM GSKit se ve afectada.

A continuación se muestra un ejemplo de su valor:

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

keystore_type

Cuando se ejecute Optim High Performance Unload en modo independiente contra una copia de seguridad cifrada, utilice este parámetro para especificar el tipo de archivo de almacén de claves de Db2 que se debe considerar. En función del tipo de almacén de claves (PKCS12, KMIP o PKCS#11), se puede establecer con los valores 'pkcs12' o 'kmip' o 'pkcs11'. Este parámetro es obligatorio cuando se ejecuta Optim High Performance Unload en modo independiente porque, en tal caso, la información relativa al almacén de claves contenida en la copia de seguridad podría no ser válida para el equipo en el que se ejecuta Optim High Performance Unload se ejecuta.

krb_keytab

Utilice este parámetro para habilitar el uso de un mecanismo de autenticación de Kerberos en Optim High Performance Unload para el usuario que lo haya iniciado. Este mecanismo consiste en adquirir un ticket válido de Kerberos, antes de establecer una conexión con la base de datos de Db2. Este parámetro permite especificar un archivo keytab de Kerberos que se utilizará para adquirir un ticket de Kerberos válido. Se utilizará un archivo keytab de Kerberos configurado con este parámetro cuando Optim High Performance Unload ejecutará un comando «kinit» en segundo plano. Este parámetro es obligatorio cuando se especifica el parámetro krb_principal . Un archivo keytab configurado con este parámetro debe tener permisos limitados al usuario que ha iniciado Optim High Performance Unload.

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

Restricción : Este parámetro solo se puede especificar en el Optim High Performance Unload archivo de configuración específico del usuario.

krb_principal

Utilice este parámetro para habilitar el uso de un mecanismo de autenticación de Kerberos en Optim High Performance Unload para el usuario que lo haya iniciado. Este mecanismo consiste en adquirir un ticket válido de Kerberos, antes de establecer una conexión con la base de datos de Db2. Este parámetro permite especificar un principal de autenticación de red ( Kerberos ) que se utilizará para adquirir un ticket de autenticación de red ( Kerberos ) válido. Un principal de Kerberos configurado con este parámetro se utilizará cuando Optim High Performance Unload ejecutará un comando «kinit» en segundo plano. Este parámetro es obligatorio cuando se especifica el parámetro krb_keytab .

...
krb_principal=USER_PRINCIPAL
...

Restricción : Este parámetro solo se puede especificar en el Optim High Performance Unload archivo de configuración específico del usuario.

lobinlinesize

Este parámetro permite establecer el tamaño de truncamiento aplicado a los datos de LOB alineados. El parámetro debe establecerse en valor numérico y la unidad es el kilobyte.

Importante : Cualquier configuración de este tamaño de truncamiento se ignora cuando la Optim High Performance Unload tarea se inicia con el formato de salida IXF en cuestión. En tal caso, el valor predeterminado de 32700 bytes se conservará para el truncamiento de los datos de LOB.

Restricción: El valor especificado para el tamaño de truncamiento de datos LOB cuando está en línea no se puede establecer en un valor menor que 32Kbo mayor que 1024Kb.

A continuación se muestra un ejemplo de este valor de parámetro, con un valor correspondiente a un tamaño de truncamiento de 64 Kb:

...
lobinlinesize=64
...

maxmemory

Utilice este parámetro para especificar el límite superior de memoria del sistema en bytes que Optim High Performance Unload puede utilizar. Si el valor especificado es demasiado bajo para proceder con la descarga, Optim High Performance Unload se utilizarán los requisitos mínimos.

maxselects

Cuando realiza la descarga desde una imagen de copia de seguridad, este parámetro permite limitar el número de tablas descargadas en paralelo. De forma predeterminada, todas las tablas especificadas en el mismo bloque UNLOAD se procesan en paralelo. Cuando hay muchas tablas implicadas, esto puede dar como resultado que se agote la memoria. Si se limita el número de tablas procesadas en paralelo se reducirá el consumo de memoria, pero se aumentará el tiempo que dura la descarga ya que la imagen de copia de seguridad implicada se lee como mínimo una vez por cada conjunto de tablas descargado. Por lo tanto, el mejor valor para este parámetro es el número máximo de tablas que se pueden procesar en paralelo sin agotar la cantidad de memoria disponible.

maxthreads

Utilice este parámetro para especificar el número máximo de subprocesos de procesamiento que Optim High Performance Unload puede utilizar. Puede especificar este parámetro para limitar el uso de proceso para descargas que implican tablas pequeñas. Establecer un valor más bajo para este parámetro permitirá Optim High Performance Unload descargar varias tablas al mismo tiempo utilizando menos subprocesos de procesamiento. El valor mínimo de este parámetro es 1 y el valor máximo es igual al número de procesadores.

Por ejemplo, si tiene 4 procesadores disponibles y desea descargar TABLE1, TABLE2 y TABLE3, con la opción maxthreads=1, Optim High Performance Unload procesa las tres tablas al mismo tiempo con un hilo de procesamiento para cada una.

maxunstaging

Este parámetro de configuración permite limitar el número de tablas procesadas en paralelo para el paso de desorganización. Al ejecutar Optim High Performance Unload para descargar datos de una copia de seguridad, se realiza un paso de preparación durante la lectura de estos datos de la copia de seguridad. Cuando se termina este paso de transferencia, de forma predeterminada, se inician tantas hebras como tablas a descargar para desorganizar los datos asociados a estas tablas. Si el número de tablas que se deben procesar es significativo, esto puede dar lugar a un incremento importante de los recursos asignados para el proceso global.

Para limitar este incremento, se puede especificar el número máximo de tablas que se pueden deshacer en paralelo. Como resultado, el número de hebras iniciadas en paralelo para el paso de deshacer puede controlarse. Cuando se alcanza este número máximo, el paso de desorganización de una nueva tabla se inicia automáticamente cuando se termina este paso para otro.

A continuación se muestra un ejemplo de su valor:

...
maxunstaging=100
...

memory_limit

Para especificar que Optim High Performance Unload pueda utilizar tanta memoria como sea necesaria para completar una tarea determinada, establezca memory_limit en no. Sólo puede establecer memory_limit si ya ha establecido el parámetro de archivo de configuración allow_unlimited_memory en yes.

Puede especificar el parámetro memory_limit en el nivel del archivo de configuración maestro, en los archivos de configuración especificados por el usuario o en el nivel de línea de mandatos.

mig_pipe_timeout

Utilice este parámetro para especificar el valor de tiempo de espera que se debe tener en cuenta para la apertura de conductos mediante el componente de lectura de una migración automática. El valor asignado debe ser numérico, que corresponda a un número de segundos. Debe establecerse en el archivo de configuración ubicado en la máquina donde Optim High Performance Unload se invoque para que se realice la migración de datos.

Una migración automática tiene dos componentes internos que colaboran juntos: uno para leer los datos que se van a migrar y el otro para cargar estos datos en el destino en cuestión. Los datos migrados se comunican entre los dos componentes mediante secuencias, que pueden ser archivos o conductos: el componente de lectura escribe los datos en estas secuencias, que luego lee el componente de carga. Si se utilizan los conductos, no se pueden abrir con el componente de lectura mientras el componente de carga no haya abierto los conductos en cuestión. Se puede producir una latencia al principio del componente de carga antes de abrir las corrientes que se van a consumir, especialmente cuando la migración se realiza hacia un destino Db2 , para el que el componente de carga invoca el programa de utilidad Db2 Load bajo las cubiertas. Hay un tiempo de espera para la apertura de los canales por parte del componente de lectura, que por defecto es de 30 segundos. Si se produce una latencia mayor que este valor al inicio del componente de carga, el componente de lectura deja de abrir los conductos y detiene su procesamiento, con lo que la migración automática no finaliza. En este caso, es posible que sea necesario configurar un valor idóneo para este tiempo de espera.

Como ejemplo, el siguiente valor permitiría configurar en 180 segundos el valor de tiempo de espera para la apertura de los conductos en una migración automática:

...
mig_pipe_timeout=180
...

min_extent_per_thread

Utilice este parámetro para especificar el número mínimo de extensiones de página de datos (que se enlaza con el número de páginas utilizadas para una tabla) para iniciar otra hebra de proceso. Este parámetro sólo se utiliza si el parámetro use_stats se establece en yes. El valor predeterminado es 6.

monitor

Establezca este parámetro en yes para habilitar la supervisión de tareas para cualquier Optim High Performance Unload ejecución. El valor predeterminado es no.

nbcpu

Utilice este parámetro para limitar el número de unidades de trabajo que se inician. Este valor tiene un efecto tanto en el uso de la memoria como en el grado de paralelismo para Optim High Performance Unload. Optim High Performance Unload utiliza este valor como límite superior para la paralelización del procesamiento. El valor máximo de este parámetro es el número de procesadores del sistema, que es valor predeterminado. El valor mínimo es 1.

Por ejemplo, si tiene 4 procesadores disponibles y desea descargar TABLE1, TABLE2 y TABLE3, con la opción nbcpu=2, Optim High Performance Unload procesa cada tabla consecutivamente con 2 hilos de procesamiento.

netservice

Utilice este parámetro para especificar el nombre del servicio asociado con la Optim High Performance Unload función de red en el archivo de sistema de servicios. La Optim High Performance Unload instalación establece este parámetro automáticamente.

nettohosts

Atención: Este parámetro está ahora en desuso. Cree un archivo de configuración de db2hpu.map en el subdirectorio cfg de su directorio de instalación principal Optim High Performance Unload directorio de instalación principal para especificar las asociaciones de nombres de red y nombres de host.

Utilice este parámetro cuando los nombres de red, a diferencia de los nombres de host, se especifiquen en la segunda columna del archivo db2nodes.cfg. Optim High Performance Unload solo puede identificar máquinas con nombres de host. La segunda columna del archivo db2nodes.cfg se utiliza para determinar si una partición de base de datos es local o remota. Optim High Performance Unload utiliza este parámetro para determinar qué nombre de host está relacionado con un nombre de red determinado. Las reglas de formateo para este parámetro siguen las reglas de formateo para las listas. Si define este parámetro, el formato es: nettohosts=host1sw:host1, host2sw:host2...

network_compression

Dependiendo de la distancia entre las máquinas implicadas en una tarea determinada, o del rendimiento de la red, puede haber consideraciones de rendimiento relacionadas con la cantidad de datos transferidos a través de la red. En tal caso, podría ser interesante reducir la cantidad de datos transferidos comprimiéndolos antes de enviarlos por un lado, y descomprimiéndolos al recibirlos de la red por el otro lado. Esto podría permitir reducir el tiempo total dedicado al procesamiento de la tarea realizada.

La habilitación de la capacidad de comprimir los datos enviados a través de la red se puede realizar configurando este parámetro en el archivo de configuración de db2hpu.cfg . Su valor puede ser un zlib e para utilizar la compresión ZLib, siempre que la biblioteca ZLib esté disponible en los equipos que intercambian los datos que se van a comprimir. También podría ser necesario configurar el parámetro de configuración zlib_api , si el nombre de la biblioteca ZLib no se reconoce automáticamente.

A continuación se muestra un ejemplo de este valor de parámetro:

...
network_compression=zlib
...

odpp_path

odpp_version

Cuando se utiliza Optim High Performance Unload para un procesamiento de enmascaramiento ODPP, si las opciones PATH y VERSION de la cláusula DATAMASKING se omiten en el archivo de control asociado, Optim High Performance Unload intenta obtener la ruta y la versión ODPP esperadas del archivo de configuración db2hpu.cfg . Su configuración puede realizarse en esta ubicación a través de la utilización de dos parámetros dedicados:

• odpp_path (en lugar de la opción PATH en la cláusula del archivo de control DATAMASKING).
• odpp_version (en lugar de la opción VERSION en la cláusula del archivo de control DATAMASKING).

Ejemplo de su especificación:

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

El establecimiento de estos dos parámetros es la manera preferida de especificar el método de enmascaramiento de datos en el nivel de archivos de configuración, en comparación con su establecimiento con los cuatro siguientes parámetros.

Para más información: DATAMASKING

odpp_api_loader

odpp_api_parser

odpp_api_adapter

odpp_api_provider

Cuando se utiliza Optim High Performance Unload para un procesamiento de enmascaramiento ODPP, si la opción LOAD de la cláusula DATAMASKING se omite en el archivo de control asociado, Optim High Performance Unload intenta obtener los nombres de bibliotecas esperados del archivo de configuración db2hpu.cfg . Su configuración se puede realizar en esta ubicación a través de la utilización de cuatro parámetros dedicados:

• odpp_api_loader (en lugar de la biblioteca LOADER de la opción LOAD en la cláusula de archivo de control DATAMASKING).
• odpp_api_parser (en lugar de la biblioteca PARSER de la opción LOAD en la cláusula de archivo de control DATAMASKING).
• odpp_api_adapter (en lugar de la biblioteca ADAPTER de la opción LOAD en la cláusula del archivo de control DATAMASKING).
• odpp_api_provider (en lugar de la biblioteca PROVIDER de la opción LOAD en la cláusula de archivo de control DATAMASKING).

Ejemplo de su especificación:

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

Los valores de estos parámetros deben ser nombres de archivos absolutos relativos a las bibliotecas ODPP en cuestión. Se debe establecer cada biblioteca ODPP necesaria, ya sea a nivel de archivo de configuración o a nivel de archivo de control. Al establecer las bibliotecas de ODPP, se deben especificar los nombres de las bibliotecas ODPP existentes para que se carguen según lo previsto. El nombre de biblioteca de ODPP establecido para cada parámetro presentado debe ser el adecuado, para encontrar las API de ODPP respectivas que se buscan.

Para más información

openssl_api_crypto

Utilice este parámetro para especificar el nombre de la biblioteca criptográfica OpenSSL, cuando no se reconozca automáticamente.

openssl_api_ssl

Utilice este parámetro para especificar el nombre de la biblioteca ssl OpenSSL, cuando no se reconozca automáticamente.

openssl_uso_criptográfico

Utilice este parámetro para habilitar o inhabilitar el uso de OpenSSL para el descifrado de datos y el hash de datos. Los valores posibles son sí o no. El valor predeterminado es YES. Puede que sea necesario inhabilitar este uso si la versión de OpenSSL instalada no es compatible con la aceleración de hardware de CPU incorporado.

progress_monitoring

Utilice este parámetro si desea habilitar la capacidad de supervisar el Optim High Performance Unload progreso de la ejecución de una tarea. Para ello, este parámetro debe establecerse en un valor numérico mayor que 0. Su valor es un número de segundos que corresponde a un tiempo de espera de supervisión. Su valor predeterminado es 0. Cuando el valor establecido en él es mayor que 0, cada vez que se alcanza el tiempo de espera de supervisión establecido, se envía un mensaje informativo INZM092I que contiene una referencia a la hora actual en el informe de ejecución.

A continuación se muestra un ejemplo de este valor de parámetro:

...
progress_monitoring=600
...

Establecer este parámetro puede ser útil cuando se ejecuta una Optim High Performance Unload tarea que dura mucho tiempo, porque puede ser imposible medir el progreso de su ejecución a partir de su informe final. De hecho, aparte de los mensajes habituales que marcan el inicio y el final de los pasos de control y procesamiento, el informe no incluye un mensaje que contenga una noción de tiempo. El uso de este parámetro permite a uno superar tal situación, y generar mensajes informativos regulares para marcar el progreso de tal ejecución.

shared_datapart_processing

Los valores posibles son sí y no. El valor predeterminado es no. La configuración de este parámetro se aplicará a cualquier Optim High Performance Unload tarea. Para sustituir este valor para una tarea específica, se puede especificar un valor distinto con la cláusula SHARED_DATAPART_PROCESSING en el archivo de control. Para más información, véase PROCESAMIENTO_DATAPART_COMPARTIDO.

Utilice este parámetro, en el caso de una tabla con datos particionados en una instancia de DPF, para habilitar un procesamiento paralelo de copias de seguridad de particiones de base de datos diferenciadas y mejorar el rendimiento. Es práctico sobre todo en el caso de las tareas que se ejecutan en copias de seguridad gestionadas por un gestor de almacenamiento, a fin de obtener una lectura paralela de las distintas copias de seguridad de las particiones de bases de datos. El comportamiento predeterminado es un procesamiento serializado que puede producir un rendimiento malo cuando las copias de seguridad implicadas las toma un gestor de almacenamiento. Para especificar este parámetro, el formato es:

...
shared_datapart_processing=yes
...

Para más información Configuración relacionada con el tratamiento de datos-particiones

stacksize

Utilice este parámetro para ajustar el tamaño máximo de la pila relacionada con un Optim High Performance Unload proceso. El valor asignado debe ser numérico, cuya unidad sea el Kb. Puede que sea necesario aumentar el tamaño de la pila para una Optim High Performance Unload ejecución, en particular cuando el tamaño predeterminado de esta pila no es lo suficientemente grande como para realizar con éxito una tarea basada en una instrucción SQL recursiva profunda. Por ejemplo, una sentencia SQL que tiene un grupo de predicados ORed en su cláusula WHERE. Si no se establece este parámetro, el tamaño de pila se hereda del entorno a través del valor 'ulimit' asociado al tamaño de la pila. Cambiar este valor de entorno permitiría tener un valor diferente que se aplicaría al tamaño de pila de Optim High Performance Unload ejecuciones, pero se comportaría en cualquier comando lanzado desde este entorno actualizado. El uso de este parámetro permite aumentar el tamaño de la pila aplicándolo únicamente a las Optim High Performance Unload tareas únicamente, sin interferir en ninguna aplicación por separado.

Por ejemplo, la siguiente configuración permitiría establecer el tamaño de la pila para Optim High Performance Unload tareas a 256Mb:

...
stacksize=262144
...

Atención: El stacksize parámetro solo está disponible en las plataformas Linux y Unix.

stagedir

Utilice este parámetro para especificar el directorio en el que desea Optim High Performance Unload generar archivos temporales al descargar datos de imágenes de copia de seguridad. De forma predeterminada, se utiliza el directorio temporal del sistema.

stage_per_part

Utilice este parámetro para definir diversas ubicaciones para la transferencia de copia de seguridad, una ubicación por cada partición de base de datos. Sin esta opción, todos los archivos de transferencia se crearán en un directorio exclusivo, por tanto en un sistema de archivos exclusivo. Puede utilizar esta opción para asegurar que hay suficiente espacio disponible y que el espacio no está limitado a un directorio y un sistema de archivos para el área de transferencia. Este valor de parámetro puede ser yes o no; el valor predeterminado es no.

Cuando este parámetro se establece en yes en el archivo db2hpu.cfg, los archivos por etapas se distribuirán por partición de base de datos en la ubicación con nombre siguiente: DBPARTnnn donde nnn es un número de 3 dígitos que coincide con el número de partición de base de datos asociado. La ubicación raíz para estos directorios es el directorio definido como área de transferencia: el directorio definido mediante el parámetro de configuración stagedir o el directorio /tmp de forma predeterminada. Estas ubicaciones deben existir: de lo contrario, se mostrará un mensaje de error.

Cuando se habilita la función de transferencia de partición por base de datos, se aplica de forma sistemática al espacio de transferencia que está relacionado con el proceso de las copias de seguridad de las particiones de base de datos que contienen datos durante la fase de ejecución. Si el catálogo procesado durante la fase de control se recupera de una copia de seguridad de partición de base de datos de catálogo, esta característica sólo se aplicará si se especifica la opción CATN de la cláusula USING BACKUP CATALOG. En este caso, los archivos por etapas potenciales para el catálogo se crearán en una sububicación que se corresponde al número de partición de base de datos especificado en la opción CATN. Si esta opción no se especifica, los archivos de transferencia potenciales para el catálogo se crearán en el directorio raíz de transferencia directamente.

Atención: Para ampliar el espacio de transferencia, las ubicaciones de partición por base de datos se deben crear como enlaces simbólicos hacia las vías de acceso físicas que aterrizan en sistemas de archivos distintos. Si estas ubicaciones se crean como directorios físicos en la misma ubicación raíz, el espacio de transferencia no se incrementará.

Por ejemplo : suponga que tiene la siguiente configuración para una operación de descarga de copias de seguridad de una instancia de Db2 que tiene tres particiones de base de datos, #1, #2, #3:

...

stagedir=/staging

stage_per_part=yes

...

En este caso, se deben crear las vías de acceso siguientes antes de iniciar cualquier operación de descarga:

/staging/DBPART001

/staging/DBPART002

/staging/DBPART003

Si una de estas vías de acceso no existe, fallará una operación de descarga que necesite crear un archivo de transferencia y se visualizará un mensaje de error.

storeprocedure_report

Utilice este parámetro para especificar el archivo donde se encuentra el informe de ejecución de una Optim High Performance Unload tarea realizada a través de la invocación del Optim High Performance Unload procedimiento almacenado. Cuando se ejecuta el Optim High Performance Unload se ejecuta el procedimiento almacenado, el informe asociado a la Optim High Performance Unload ejecución subyacente se gestiona a través del parámetro de salida del procedimiento almacenado denominado STDERR. Siendo este parámetro de tipo de datos CLOB, su visualización está limitada a 8192 bytes por el CLP de Db2 . En consecuencia, si el informe de ejecución es superior a este límite, se mostrará truncado y no se pueden obtener pruebas del resultado de la ejecución.

Este parámetro es el medio para configurar Optim High Performance Unload para que la ejecución del procedimiento almacenado escriba el informe completo en un archivo, en lugar de mostrarlo a través de un parámetro de salida. Debe estar establecido con una especificación de nombre de archivo absoluta.

syncsize

Utilice este parámetro para habilitar la sincronización de los archivos de salida con el disco. Cuando el sistema operativo está configurado de forma que puede que la memoria caché de disco utilice una gran cantidad de memoria, generar grandes archivos de salida puede provocar un importante consumo de memoria y afectar a la usabilidad de la máquina por parte de aplicaciones independientes. Para limitar la cantidad de memoria consumida por la memoria caché de disco al ejecutar una tarea de descarga, este parámetro permite habilitar la capacidad de sincronizar regularmente los archivos de salida con el disco.

El valor asignado a este parámetro debe ser numérico, cuya unidad sea el Kb. Al definir este parámetro, cada vez que el tamaño de un archivo de salida haya alcanzado la cantidad de datos configurada, el archivo se sincroniza con el disco.

A continuación se muestra un ejemplo de su valor:

...
syncsize=10000
...

tsm_api

Utilice este parámetro para especificar el nombre de biblioteca de API que se debe cargar dinámicamente al descargar datos de imágenes de copia de seguridad almacenadas en Tivoli® Storage Manager.

umask

Utilice este parámetro para alterar temporalmente umask en un sistema remoto y generar archivos con los permisos adecuados. De forma predeterminada, el valor de umask para descargas remotas es el valor de umask del iniciador del daemon xinetd (o inetd). A continuación, los permisos de archivos generados se restringen mediante la umask de root. Cuando realiza una migración automática del sistema, esta restricción puede ser problemática porque Db2 Load necesita que los archivos de datos sean legibles por el usuario de instancia de la base de datos de destino. En algunos casos (en función de la configuración del sistema), el umask aplicado es demasiado restrictivo y los archivos generados no son visibles para el usuario de la instancia de la base de datos de destino. Puede configurar la Optim High Performance Unload opción umask para permitir que el programa anule esta umask restrictiva.

La definición de la característica umask se basa en la definición umask de UNIX: se utilizan tres dígitos octales para definir permisos para las máscaras de usuario/grupo/otras. El valor de umask puede aceptar valores octales entre 000 y 777. El valor umask recomendado para Optim High Performance Unload es 022. Se generarán archivos de salida con los permisos adecuados para realizar la migración manual o automática.

Restricción:

• El parámetro umask se aplica sólo a archivos generados remotamente.
• La definición de umask en Optim High Performance Unload no le permite generar archivos de datos con todo tipo de derechos de acceso. Optim High Performance Unload siempre consultará la generación de archivos de datos con derechos de acceso 644 (rw-r--r--). Si la máscara de usuario es más restrictiva, se reducirán los derechos de acceso. Si umask es menos restrictivo, los derechos de acceso seguirán siendo rw-r--r--.

use_netname

Utilice este parámetro para habilitar o inhabilitar el uso de nombres de red cuando se utilizan en el archivo db2nodes.cfg de la instancia de Db2 en cuestión. Estos nombres de red normalmente corresponden a interfaces de red especializadas o de alta velocidad. Puede elegir si desea gestionar las Optim High Performance Unload comunicaciones de red a través de estas interfaces o no. De forma predeterminada, el valor de este parámetro se establece internamente en yes y el uso de nombres de red se habilita de forma predeterminada.

use_stats

Utilice este parámetro para especificar si desea Optim High Performance Unload considerar las estadísticas de la tabla del catálogo. Esta información permite Optim High Performance Unload determinar el número óptimo de subprocesos de procesamiento que se utilizarán al descargar las tablas.

Los valores posibles para este parámetro son yes o no. Si especifica yes, Optim High Performance Unload puede optimizar el procesamiento descargando tablas más grandes en paralelo. Esta opción sólo puede ser efectiva si las estadísticas de las tablas son actuales.

Atención : El uso de la opción yes puede reducir significativamente Optim High Performance Unload el rendimiento en algunas circunstancias. Por ejemplo, si una tabla en particular tiene información estadística obsoleta que muestra que la tabla tiene pocos datos o ninguno, aunque la tabla se haya actualizado desde entonces para incluir varios millones de filas, Optim High Performance Unload seguirá considerando que la tabla es pequeña y utilizará un solo hilo de procesamiento para descargarla.

El valor predeterminado es no.

xbsa_api

Utilice este parámetro para especificar el nombre de biblioteca de API que se cargará dinámicamente cuando descargue datos desde una copia de seguridad. Este parámetro sólo se considera cuando se especifica la opción USE XBSA al descargar desde las imágenes de copia de seguridad. La opción USE XBSA significa que las imágenes de copia de seguridad las gestiona una herramienta de almacenamiento similar a XBSA.

zlib_api

Utilice este parámetro para especificar el nombre de la biblioteca ZLib, cuando no se reconozca automáticamente.