Administração: Implementação

Configuração de Novo Roteamento de Cliente Automático (DB2_MAX_CLIENT_CONNRETRIES |e DB2_CONNRETRIES_INTERVAL)

Por padrão, o recurso de novo roteamento de cliente automático tenta novamente a conexão com um banco de dados repetidamente por até 10 minutos. No entanto, é possível configurar |o comportamento exato de nova tentativa utilizando uma ou as duas variáveis de registro a seguir:

|
• DB2_MAX_CLIENT_CONNRETRIES: O número máximo de novas tentativas de conexão feitas |pelo novo roteamento de cliente automático.
|
• DB2_CONNRETRIES_INTERVAL: O tempo de suspensão entre novas tentativas de conexão consecutivas, em número de segundos.

Se DB2_MAX_CLIENT_CONNRETRIES estiver configurado, mas DB2_CONNRETRIES_INTERVAL não, |DB2_CONNRETRIES_INTERVAL assumirá o padrão de 30.

Se DB2_MAX_CLIENT_CONNRETRIES não estiver configurado, mas DB2_CONNRETRIES_INTERVAL |estiver, DB2_MAX_CLIENT_CONNRETRIES assumirá o padrão de 10.

Se nem DB2_MAX_CLIENT_CONNRETRIES nem DB2_CONNRETRIES_INTERVAL estiver configurado, |o recurso de novo roteamento de cliente automático será revertido para seu comportamento padrão descrito anteriormente.

Nota:

Os usuários da conectividade Tipo 4 com o DB2^(R) Universal JDBC Driver devem utilizar |as duas seguintes propriedades de origem de dados para configurar o novo roteamento de cliente |automático:

|
• maxRetriesForClientReroute: Utilize esta propriedade para limitar o número de novas tentativas se a conexão primária com o servidor falhar. Esta propriedade será utilizada apenas se a propriedade retryIntervalClientReroute também estiver configurada.
|
• retryIntervalForClientReroute: Utilize esta propriedade para especificar o período |de tempo (em segundos) para suspensão antes de uma nova tentativa. Esta propriedade será utilizada apenas se a propriedade maxRetriesForClientReroute também estiver configurada.

Esclarecimento da Variável de Registro DB2TIMEOUT

A variável de registro DB2TIMEOUT não é mais suportada. Esta configuração foi utilizada |para controlar o período de tempo limite para clientes do Windows^(R) 3.x e Macintosh |durante longas consultas SQL. Este recurso foi desativado por padrão.

Diretórios Criados durante a Criação do Contêiner de Espaço de Tabelas

Ao criar contêineres de espaço de tabelas, o DB2 UDB cria todos os níveis de diretório |que não existem.

Por exemplo, se um contêiner for especificado como /project/user_data/container1 e o diretório /project não existir, o DB2 UDB |criará os diretórios /project e /project/user_data.

Começando com o DB2 UDB V8.2, FixPak 4, os diretórios criados pelo DB2 UDB |são criados com PERMISSION 700. Isto significa que apenas o proprietário possui acesso de |leitura, gravação e execução.

Ao criar várias instâncias, observe o seguinte cenário:

|
1. Utilizando a mesma estrutura de diretórios utilizada acima, suponha que os níveis de diretório /project/user_data não existam.
|
2. user1 cria uma instância, denominada user1 por padrão, em seguida, cria um banco de dados e, em seguida, cria um espaço de tabelas com /project/user_data/container1 como um de seus contêineres.
|
3. user2 cria uma instância, denominada user2 por padrão, em seguida, cria um banco de dados e, em seguida, tenta criar um espaço de tabelas com /project/user_data/container2 como um de seus contêineres.

Como o DB2 UDB criou os níveis de diretório /project/user_data com |PERMISSION 700 no primeiro pedido, user2 não possui acesso a estes níveis de diretório |e não pode criar container2 nestes diretórios. | Neste caso, a operação CREATE TABLESPACE falhará.

Existem dois métodos para resolver este conflito:

|
1. Crie o diretório /project/user_data antes de criar os espaços de tabelas |e de configurar a permissão para qualquer tipo de acesso requerido para |user1 e user2 para criar os espaços de tabelas. Se existirem todos os níveis de um diretório de espaço de tabelas, o DB2 UDB não modificará o acesso.
|
2. Quando user1 criar /project/user_data/container1, configure a |permissão de /project/user_data para qualquer tipo de acesso requerido |para user2 para criar o espaço de tabelas.

Armazenamento Automático

O formato de nomes para os contêineres foi alterado de maneira que o ID do espaço de tabelas e o ID do contêiner também foram alterados. O novo formato é:

<caminho_de_armazenamento>/<instância>/NODE####
/T#######
/C#######.<EXT>

em que:

• /T####### é o ID do espaço de tabelas. Por exemplo, T0000003.
• /C####### é o ID do contêiner. Por exemplo, C0000012.

Definindo uma Coluna Gerada em uma Tabela Existente

Iniciando com o DB2^(R) Universal Database Versão 8.2.2 (equivalente à Versão 8.1 FixPak 9), as colunas geradas podem ser utilizadas em índices exclusivos.

As colunas geradas não podem ser utilizadas em restrições, restrições referenciais, chaves primárias e tabelas temporárias globais. Uma tabela criada com LIKE e exibições materializadas não herda as propriedades da coluna gerada.

Variáveis de Registro Agregadas

Ao definir DB2WORKLOAD=SAP, o espaço de tabelas do usuário SYSTOOLSPACE e o espaço de tabelas temporário do usuário SYSTOOLSTEMPSPACE não são criados automaticamente. Esses espaços de tabelas são utilizados para tabelas criadas pelos seguintes assistentes, utilitários ou funções:

• Manutenção automática
• Orientador de design
• Painel de informações do banco de dados Centro de Controle
• Procedimento armazenado SYSINSTALLOBJECTS, se o parâmetro de entrada do espaço de tabelas não for especificado
• Procedimento armazenado GET_DBSIZE_INFO

Sem os espaços de tabelas SYSTOOLSPACE e SYSTOOLSTEMPSPACE, não é possível utilizar esses assistentes, utilitários ou funções.

Para estar apto a utilizar os assistentes, utilitários ou funções, faça um dos seguintes:

• Crie manualmente SYSTOOLSPACE (apenas no nó de catálogo, se utilizar DPF). Por exemplo:

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

• Chame SYSINSTALLOBJECTS para criar objetos, especificando um espaço de tabelas válido para cada um dos seguintes nomes de ferramentas: "DB2AC", "POLICY" e "STMG_DBSIZE_INFO"

Após concluir pelo menos uma dessas opções, crie um espaço de tabelas temporário do usuário (também apenas no nó de catálogo, se utilizar DPF). Por exemplo:

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

Após criar o espaço de tabelas SYSTOOLSPACE e o espaço de tabelas temporário SYSTOOLSTEMPSPACE, é possível utilizar os assistentes, utilitários ou funções mencionados anteriormente.

Considerações de Autenticação para Clientes Remotos

O tipo de autenticação DATA_ENCRYPT_CMP é projetado para permitir que os clientes de um release anterior que não suportam criptografia de dados conectem-se a um servidor utilizando a autenticação SERVER_ENCRYPT em vez da DATA_ENCRYPT. Esta autenticação não funciona quando as três instruções a seguir são verdadeiras:

• O nível do cliente é Versão 7.2.
• O nível do gateway é Versão 8 FixPak 7 ou posterior.
• O servidor é Versão 8 FixPak 7 ou posterior.

Neste caso, o cliente não pode se conectar ao servidor. Para permitir a conexão, você deve fazer upgrade do cliente para a Versão 8 ou ter seu nível de gateway na Versão 8 FixPak 6 ou posterior.

Suporte a DIO (Direct I/O) e CIO (Concurrent I/O)

A DIO (Direct I/O) aprimora o desempenho da memória porque evita o armazenamento em cache no nível do sistema de arquivos. Este processo reduz o código extra da CPU e disponibiliza mais memória para a instância do banco de dados.

A CIO (Concurrent I/O) inclui as vantagens da DIO e também livra a serialização dos acessos de gravação.

DB2 UDB (Universal Database) suporta DIO e CIO no AIX; e DIO no HP-UX, Solaris Operating Environment, Linux e Windows.

As palavras-chave NO FILE SYSTEM CACHING e FILE SYSTEM CACHING são parte das instruções CREATE e ALTER TABLESPACE SQL para permitir especificar se DIO ou CIO deve ser utilizada com cada espaço de tabela. Quando NO FILE SYSTEM CACHING está efetivo, DB2 UDB tenta utilizar E/S concorrente sempre que possível. Nos casos em que a CIO não é suportada (por exemplo, se JFS for utilizado), a DIO será utilizada no lugar.

Para obter informações adicionais, consulte o artigo "Aprimorar o desempenho do banco de dados nos contêineres do sistema de arquivos no IBM DB2 UDB Stinger utilizando a Concurrent I/O no AIX" localizado na seguinte URL:

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

Tecnologia de Distribuidor e Novo Roteamento de Cliente Automático

As informações a seguir fazem parte do Apêndice B do Administration Guide: Implementation "Using automatic client rerouting":

O recurso de novo roteamento de cliente automático do DB2 Universal Database para Linux, UNIX, e Windows permite que os aplicativos clientes se recuperem de uma perda de comunicação com o servidor restabelecendo automaticamente a conexão com o banco de dados do cliente para o servidor, para que o aplicativo possa continuar a funcionar com interrupção mínima.

Quando uma conexão do cliente para o servidor falha, os pedidos do cliente para reconexão são distribuídos para um conjunto definido de sistemas por um distribuidor ou dispatcher, como WebSphere EdgeServer

Você pode estar usando a Tecnologia de Distribuidor em um ambiente semelhante ao seguinte:

Cliente --> Tecnologia de Distribuidor --> (DB2 Connect Server 1 ou DB2 Connect Server 2) --> DB2 z/OS

em que:

• O componente de Tecnologia de Distribuidor tem um nome de host TCP/IP de DThostname
• O DB2 Connect Server 1 tem um nome de host TCP/IP de GWYhostname1
• O DB2 Connect Server 2 tem um nome de host TCP/IP de GWYhostname2
• O servidor DB2 z/OS tem um nome de host TCP/IP de zOShostname

O cliente é catalogado usando DThostname para utilizar a tecnologia de distribuidor para acessar qualquer um dos Servidores DB2 Connect. A tecnologia de distribuidor mediadora toma a decisão de utilizar GWYhostname1 ou GWYhostname2. Depois que a decisão é tomada, o cliente tem uma conexão de soquete direta com um desses dois gateways DB2 Connect. Depois que a conectividade do soquete é estabelecida com o servidor DB2 Connect escolhido, você tem um cliente típico para o servidor DB2 Connect para conectividade com o DB2 z/OS.

Por exemplo, suponha que o distribuidor escolha GWYhostname2. Isso produz o seguinte ambiente:

Cliente --> DB2 Connect Server 2 --> DB2 z/OS

O distribuidor não repete nenhuma das conexões se houver qualquer defeito de comunicação. Se você desejar ativar o recurso Novo Roteamento de Cliente Automático para um banco de dados nesse ambiente, o servidor alternativo para o banco de dados ou bancos de dados associados no DB2 Connect Server (DB2 Connect Server 1 ou DB2 Connect Server 2) deverá ser configurado para ser o distribuidor (DThostname). Em seguida, se o DB2 Connect Server 1 travar por algum motivo, o Novo Roteamento de Cliente Automático será acionado e a conexão do cliente será repetida como o distribuidor como servidor principal e alternativo. Esta opção permite combinar e manter os recursos do distribuidor com o recurso Novo Roteamento de Cliente Automático do DB2. Definir o servidor alternativo para um host diferente do nome do host do distribuidor ainda fornecerá aos clientes o recurso Novo Roteamento de Cliente Automático. Porém, os clientes estabelecerão conexões diretas com o servidor alternativo definido e evitarão a tecnologia de distribuidor, o que elimina o distribuidor e o valor que ele traz.

O Novo Roteamento de Cliente Automático interceptará os seguintes sqlcodes:

• sqlcode -20157
• sqlcode -1768 (código de razão = 7)

Considerações sobre o Novo Roteamento de Cliente Automático para Catalogar em um Servidor DB2 Connect

Considere os dois itens a seguir que envolvem a conectividade de servidor alternativo com o servidor DB2 Connect:

• A primeira consideração envolve a utilização do servidor DB2 Connect para fornecer acesso a um host ou banco de dados do iSeries em nome dos clientes remotos e locais. Nestas situações, pode haver confusão em relação às informações de conectividade de servidor alternativo em uma entrada do diretório do banco de dados do sistema. Para minimizar essa confusão, considere catalogar duas entradas no diretório de banco de dados do sistema para representar o mesmo host ou banco de dados do iSeries. Catalogue uma entrada para clientes remotos e catalogue outra para clientes locais.
• Segundo, as informações do servidor alternativo que são retornadas de um servidor de destino são mantidas apenas em cache. Se o processo do DB2 for encerrado, as informações do cache e, portanto, as informações do servidor alternativo, serão perdidas.

Suporte à Conta do Sistema Local (Windows)

Os aplicativos em execução no contexto de LSA (Local System Account) são suportados em todas as plataformas Windows, exceto a Windows ME.

Suporte ao ID do Usuário com Duas Partes

A instrução CONNECT e o comando ATTACH suportam IDs do usuário de duas partes. O qualificador do ID do usuário compatível com SAM é o nome de estilo do NetBIOS que possui um comprimento máximo de 15 caracteres. Este recurso não é suportado no Windows ME.

Detalhes de Autenticação de Kerberos

Informações Adicionais para Suporte Kerberos