Administración: Implantación

Configuración del redireccionamiento automático de cliente (DB2_MAX_CLIENT_CONNRETRIES |y DB2_CONNRETRIES_INTERVAL)

Por omisión, la característica de redireccionamiento automático de cliente reintenta la conexión |a una base de datos repetidamente hasta 10 minutos. Es, sin embargo, posible configurar |la conducta exacta de reintentar utilizando una o ambas de las siguientes dos variables de |registro:

|
• DB2_MAX_CLIENT_CONNRETRIES: El número máximo de reintentos de conexión intentados |por el redireccionamiento automático de cliente.
|
• DB2_CONNRETRIES_INTERVAL: El tiempo de inactividad entre reintentos de conexión |consecutivos, en segundos.

Si se ha establecido DB2_MAX_CLIENT_CONNRETRIES, pero no DB2_CONNRETRIES_INTERVAL, |DB2_CONNRETRIES_INTERVAL por omisión se establece en 30.

Si se ha establecido DB2_MAX_CLIENT_CONNRETRIES, pero no DB2_CONNRETRIES_INTERVAL, |DB2_MAX_CLIENT_CONNRETRIES por omisión se establece en 10.

Si no se ha establecido DB2_MAX_CLIENT_CONNRETRIES ni DB2_CONNRETRIES_INTERVAL, |la característica de redireccionamiento automático de cliente revierte a su conducta |por omisión previamente descrita.

Nota:

Los usuarios de conectividad de Tipo 4 con el DB2^(R) Universal JDBC Driver |deben utilizar las siguientes dos propiedades de fuente de datos para configurar |el redireccionamiento automático de cliente:

|
• maxRetriesForClientReroute: Utilice esta propiedad para limitar el número |de reintentos si la conexión primaria al servidor falla. Esta propiedad sólo se |utiliza si se establece la propiedad retryIntervalClientReroute.
|
• retryIntervalForClientReroute: Utilice esta propiedad para especificar la cantidad |de tiempo (en segundos) de inactividad antes de reintentar otra vez. Esta propiedad sólo se |utiliza si se establece la propiedad maxRetriesForClientReroute.

Clarificación de la variable de registro DB2TIMEOUT

La variable de registro DB2TIMEOUT ya no está soportada. Este valor se utilizaba |para controlar el periodo de tiempo de espera para clientes Windows^(R) 3.x y Macintosh |durante consultas SQL largas. Esta característica se inhabilitó por omisión.

Directorios creados durante la creación del contenedor de espacio de tabla

Cuando se crean contenedores de espacio de tablas, DB2 UDB crea los niveles de |directorio que no existen.

Por ejemplo, si un contenedor se especifica como /project/user_data/container1, y |el directorio /project no existe, entonces DB2 UDB |crea los directorios /project y /project/user_data.

Al iniciar con DB2 UDB V8.2, FixPak 4, cualquier directorio creado por DB2 UDB |se crea con PERMISSION 700. Esto significa que sólo el propietario tiene acceso de lectura, |escritura y de ejecución.

Cuando se crean múltiples instancias, observe el escenario siguiente:

|
1. Utilizando la misma estructura de directorio anterior, se supone que los niveles de |directorio /project/user_data no existen.
|
2. user1 crea una instancia, llamada user1 por omisión, después crea |una base de datos y, después, crea un espacio de tabla |con /project/user_data/container1 como uno de sus contenedores.
|
3. user2 crea una instancia, llamada user2 por omisión, después crea |una base de datos y, después, crea un espacio de tabla |con /project/user_data/container2 como uno de sus contenedores.

Debido a que DB2 UDB creó niveles de directorio /project/user_data con |PERMISSION 700 desde la primera petición, user2 no tiene acceso a estos niveles |de usuario y no se puede crear container2 en dichos directorios. | En este caso, falla la operación CREATE TABLESPACE.

Hay dos métodos para resolver este conflicto:

|
1. Crear el directorio /project/user_data antes de crear los |espacios de tabla y establecer cualquier permiso de acceso que se necesite para |user1 y user2 para crear los espacios de tabla. Si existen todos los niveles de un directorio de |espacio de tabla, DB2 UDB no modifica el acceso.
|
2. Después que user1 crea /project/user_data/container1, establecer el permiso |de /project/user_data para cualquier acceso que se necesite para |user2 para crear el espacio de tabla.

Almacenamiento automático

El formato de los nombres de los contenedores ha cambiado de tal manera que el ID de espacio de tabla y el ID de contenedor también han cambiado. El nuevo formato es:

<vía de acceso de almacenamiento>/<instancia>/NODE####
/T#######
/C#######.<EXT>

donde:

• /T####### es el ID de espacio de tabla. Por ejemplo, T0000003.
• /C####### es el ID de contenedor. Por ejemplo, C0000012.

Definición de una columna generada en una tabla existente

A partir de DB2^(R) Universal Database Versión 8.2.2 (equivalente a la Versión 8.1 FixPak 9), se pueden utilizar columnas generadas en índices exclusivos.

Las columnas generadas no se pueden utilizar en restricciones, restricciones de referencia, claves primarias y tablas temporales globales. Una tabla creada con LIKE y vistas materializadas no hereda propiedades de columnas generadas.

Agregar variables del registro

Cuando ha establecido DB2WORKLOAD=SAP, el espacio de tabla del usuario SYSTOOLSPACE y el espacio de tabla temporal del usuario SYSTOOLSTEMPSPACE no se crean automáticamente. Estos espacios de tabla se utilizan para las tablas creadas automáticamente mediante los asistentes, programas de utilidad o funciones siguientes:

• Mantenimiento automático
• Asesor de diseño
• Panel de información de base de datos del Centro de control
• El procedimiento almacenado SYSINSTALLOBJECTS, si el parámetro de entrada del espacio de tabla no se ha especificado
• Procedimiento almacenado GET_DBSIZE_INFO

Sin los espacios de tabla SYSTOOLSPACE y SYSTOOLSTEMPSPACE, no puede utilizar estos asistentes, programas de utilidad o funciones.

Para poder utilizar los asistentes, programas de utilidad o funciones, realice una de las acciones siguientes:

• Cree manualmente SYSTOOLSPACE (en el nodo del catálogo únicamente, si utiliza DPF). Por ejemplo:

     CREATE REGULAR TABLESPACE SYSTOOLSPACE 
        IN IBMCATGROUP 
        MANAGED BY SYSTEM 
        USING ('SYSTOOLSPACE')

• Invoque SYSINSTALLOBJECTS para crear objetos, especificando un espacio de tabla válido para cada uno de los nombres de herramientas siguientes: "DB2AC", "POLICY" y "STMG_DBSIZE_INFO"

Una vez que haya completado al menos una de estas opciones, cree un espacio de tabla temporal del usuario (también en el nodo del catálogo únicamente, si utiliza DPF). Por ejemplo:

   CREATE USER TEMPORARY TABLESPACE SYSTOOLSTMPSPACE 
      IN IBMCATGROUP 
      MANAGED BY SYSTEM 
      USING ('SYSTOOLSTMPSPACE')

Una vez que haya creado el espacio de tabla SYSTOOLSPACE y el espacio de tabla temporal SYSTOOLSTEMPSPACE, podrá utilizar los asistentes, programas de utilidad o funciones mencionados antes.

Consideraciones sobre la autentificación para clientes remotos

El tipo de autentificación DATA_ENCRYPT_CMP está diseñado para permitir que los clientes de un release anterior que no tienen soporte para el cifrado de datos puedan conectarse a un servidor utilizando la autentificación SERVER_ENCRYPT en lugar de DATA_ENCRYPT. Esta autentificación no funciona cuando se cumplen las tres afirmaciones siguientes:

• El nivel del cliente es la Versión 7.2.
• El nivel de la pasarela es la Versión 8 FixPak 7 o posterior.
• El servidor tiene la Versión 8 FixPak 7 o posterior.

En este caso, el cliente no puede conectarse al servidor. Para permitir la conexión, debe actualizar el cliente a la Versión 8 o hacer que el nivel de pasarela sea la Versión 8 FixPak 6 o anterior.

Soporte de E/S directa (DIO) y E/S simultánea (CIO)

La E/S directa (DIO) mejora el rendimiento de memoria dado que elude el almacenamiento en antememoria en el nivel de sistema de archivos. Este proceso reduce la actividad general de CPU y habilita más memoria para la instancia de base de datos.

La E/S simultánea (CIO) incluye las ventajas de DIO y también alivia la serialización de los accesos de grabación.

DB2 Universal Database (UDB) da soporte a DIO y CIO en AIX; y a DIO en HP-UX, Entorno operativo Solaris, Linux y Windows.

Las palabras clave NO FILE SYSTEM CACHING y FILE SYSTEM CACHING forman parte de las sentencias CREATE y ALTER TABLESPACE de SQL para permitirle especificar si debe utilizarse DIO o CIO con cada espacio de tabla. Cuando no hay en vigor ninguna palabra clave NO FILE SYSTEM CACHING, DB2 UDB intenta utilizar la E/S simultánea siempre que sea posible. En los casos en los que CIO no está soportado (por ejemplo, si se utiliza JFS), se utiliza en su lugar DIO.

Para obtener más información, consulte el artículo "Improve database performance on file system containers in IBM DB2 UDB Stinger using Concurrent I/O on AIX" que se encuentra en la siguiente dirección URL:

http://www.ibm.com/developerworks/db2/library/techarticle/dm-0408lee/

Tecnología de distribuidor y redireccionamiento automático de cliente

La información siguiente forma parte del manual Administration Guide:, Implementation Apéndice B "Using automatic client rerouting":

La característica de redireccionamiento automático de cliente de DB2 Universal Database para Linux, UNIX, y Windows permite que las aplicaciones cliente se puedan recuperar de una pérdida de comunicación con el servidor volviendo a establecer automáticamente la conexión de base de datos desde el cliente con el servidor, de modo que la aplicación pueda seguir trabajando con la mínima interrupción.

Cuando una conexión entre el cliente y el servidor falla, un distribuidor o asignador, como por ejemplo WebSphere EdgeServer, distribuye las peticiones de reconexión del cliente a un conjunto definido de sistemas.

Es posible que esté utilizando Tecnología de distribuidor en un entorno similar al siguiente:

Cliente --> Tecnología de distribuidor --> (Servidor 1 de DB2 Connect o Servidor 2 de DB2 Connect) --> DB2 z/OS

donde:

• El componente Tecnología de distribuidor tiene el nombre de sistema principal TCP/IP nombresistpralDT
• El Servidor 1 de DB2 Connect tiene el nombre de sistema principal TCP/IP nombresistpral1GWY
• El Servidor 2 de DB2 Connect tiene el nombre de sistema principal TCP/IP nombresistpral2GWY
• El servidor de DB2 z/OS tiene el nombre de sistema principal TCP/IP nombresistpralzOS

El cliente se cataloga utilizando nombresistpralDT a fin de utilizar la tecnología de distribuidor para acceder a cualquiera de los dos servidores de DB2 Connect. La tecnología de distribuidor que interviene toma la decisión de utilizar nombresistpralGWY o nombresistpral2GWY. Una vez tomada la decisión, el cliente tiene una conexión de socket directa a una de estas dos pasarelas de DB2 Connect. Después de establecer la conectividad con el servidor de DB2 Connect que se ha elegido, se dispone de una conectividad típica entre cliente y servidor de DB2 Connect con DB2 Connect z/OS.

Por ejemplo, supongamos que el distribuidor elige nombresistpral2GWY. Esto generaría el siguiente entorno:

Cliente --> Servidor 2 de DB2 Connect --> DB2 z/OS

El distribuidor no reintenta ninguna de las conexiones si existe alguna anomalía en la comunicación. Si desea habilitar la característica de Redireccionamiento automático de cliente para una base de datos en este entorno, el servidor alternativo para la base de datos o las bases de datos asociadas en el Servidor de DB2 Connect (Servidor 1 de DB2 Connect o Servidor 2 de DB2 Connect) debería configurarse para ser el distribuidor (nombresistpralDT). A continuación, si el Servidor 1 de DB2 Connect se cierra por algún motivo, se activa el Redireccionamiento automático de cliente y se reintenta la conexión de cliente con el distribuidor tanto como servidor primario como secundario. Esta opción le permite combinar y mantener las posibilidades del distribuidor con la característica de Redireccionamiento automático de cliente de DB2. Al establecer el servidor alternativo como un sistema principal que no sea el nombre de sistema principal del distribuidor todavía se proporcionará a los clientes la característica de Redireccionamiento automático de cliente. Sin embargo, los clientes establecerán conexiones directas con el servidor alternativo definido y eludirán la tecnología de distribuidor, la cual elimina el distribuidor y el valor que éste aporta.

El Redireccionamiento automático de cliente interceptará los siguientes códigos de sql:

• código de sql -20157
• código de sql -1768 (código de razón = 7)

Consideraciones sobre el redireccionamiento automático de cliente para catalogar en un servidor de DB2 Connect

Tengamos en cuenta estos dos elementos que implican conectividad con un servidor de DB2 Connect:

• La primera consideración implica la utilización del servidor de DB2 Connect para proporcionar acceso a una base de datos de sistema principal o de iSeries en nombre de clientes tanto remotos como locales. En estas situaciones, puede producirse una cierta confusión relacionada con la información sobre conectividad del servidor en una entrada del directorio de bases de datos del sistema. Para minimizar esta confusión, tenga en cuenta la posibilidad de catalogar dos entradas en el directorio de bases de datos del sistema que representen la misma base de datos de sistema principal o de iSeries. Catalogue una entrada para clientes remotos y otra para clientes locales.
• En segundo lugar, la información sobre el servidor alternativo que se devuelve de un servidor de destino sólo se conserva en antememoria. Si el proceso de DB2 finaliza, la información en antememoria, y por lo tanto la información sobre el servidor alternativo, se pierde.

Soporte de cuentas del sistema local (Windows)

Las aplicaciones que se ejecutan bajo el contexto de la cuenta del sistema local (LSA) reciben soporte en todas las plataformas Windows, excepto en Windows ME.

Soporte de ID de usuario de dos partes

La sentencia CONNECT y el mandato ATTACH dan soporte a los ID de usuario de dos partes. El calificador del ID de usuario compatible con SAM es el nombre del estilo NetBIOS que tiene una longitud máxima de 15 caracteres. Esta característica no recibe soporte en Windows ME.

Detalles sobre la autentificación de Kerberos

Información adicional correspondiente al soporte de Kerberos