Antes de incluir as origens de dados do Sybase em um servidor federado, é preciso instalar e configurar o software Sybase Open Client no servidor federado do DB2. Consulte os procedimentos de instalação na documentação que é fornecida com o software do banco de dados Sybase para obter detalhes específicos sobre como instalar o software Open Client. Como parte da instalação, certifique-se de que os procedimentos armazenados do catálogo Sybase sejam instalados no servidor Sybase e as bibliotecas Sybase Open Client sejam instaladas no servidor federado DB2.
Depois de configurar a conexão do software cliente ao servidor Sybase, teste a conexão utilizando uma das ferramentas Sybase. Utilize a ferramenta isql para UNIX e a ferramenta SQL Advantage para Windows.
Para configurar o servidor federado para acessar os dados armazenados nas origens de dados do Sybase, você precisa:
Este capítulo discute as etapas 2 e 3.
As instruções neste capítulo aplicam-se ao Windows NT, AIX e Solaris Operating Environment As diferenças específicas da plataforma são observadas onde elas ocorrem.
Para incluir uma origem de dados do Sybase em um servidor federado, você precisa:
Estas etapas são explicadas com detalhes nesta seção.
Defina variáveis de ambiente da origem de dados modificando o arquivo db2dj.ini e emitindo o comando db2set. O arquivo db2dj.ini contém informações de configuração sobre o software do cliente Sybase instalado no servidor federado. O comando db2set atualiza o registro de perfil do DB2 com suas definições.
Em um sistema do banco de dados particionado, você pode utilizar um único arquivo db2dj.ini para todos os nós em uma instância específica ou você pode utilizar um único arquivo db2dj.ini para um ou mais nós em uma instância específica. Um sistema de banco de dados não-particionado pode ter apenas um arquivo db2dj.ini por instância.
Para definir as variáveis de ambiente:
SYBASE="<sybase home directory>"
onde <sybase home directory> é o diretório onde o cliente Sybase está instalado.
Se você estiver utilizando o arquivo db2dj.ini em um sistema de banco de dados não-particionado ou se você quiser que o arquivo db2dj.ini se aplique ao nó atual somente, emita:
db2set DB2_DJ_INI=$HOME/sqllib/cfg/db2dj.ini
Se você estiver utilizando o arquivo db2dj.ini em um sistema do banco de dados particionado e se quiser que os valores no arquivo db2dj.ini se apliquem a todos os nós dentro dessa instância, emita:
db2set -g DB2_DJ_INI=$HOME/sqllib/cfg/db2dj.ini
Se você estiver utilizando o arquivo db2dj.ini em um sistema do banco de dados particionado e se quiser que os valores no arquivo db2dj.ini se aplique a um nó específico, emita:
db2set -i INSTANCEX 3 DB2_DJ_INI=$HOME/sqllib/cfg/node3.ini
onde:
Para permitir acesso às origens de dados do Sybase, o servidor federado do DB2 deve ser link-edited às bibliotecas do cliente. O processo de link-edit cria um wrapper para cada origem de dados com a qual o servidor federado irá se comunicar. Quando você executar o script djxlink, crie a biblioteca de wrappers. Para emitir o script djxlink, digite:
djxlink
Para assegurar-se de que as variáveis de ambiente estejam definidas no programa, recicle a instância do DB2. Quando você reciclar a instância, atualize a instância do DB2 para aceitar as alterações feitas.
Emita os comandos a seguir, para reciclar a instância do DB2:
NET STOP instance_name NET START instance_name
db2stop db2start
Para criar e configurar um arquivo de interfaces, você deve criar o arquivo e torná-lo acessível.
Tipicamente, o Windows NT nomeia esse arquivo sql.ini. Renomeie o arquivo que acabou de criar de sql.ini para interfaces, para nomear o arquivo universalmente através de todas as plataformas. Se você optar por não renomear sql.ini para interfaces, será necessário utilizar o parâmetro IFILE ou a opção CONNECTSTRING que é explicada na etapa 8.
Em sistemas AIX e Solaris, esse arquivo é nomeado <instance home>/sqllib/interfaces.
ln -s -f /home/sybase/interfaces /home/db2djinst1/sqllib
Use a instrução CREATE WRAPPER para especificar o wrapper que será utilizado para acessar as origens de dados do Sybase. Wrappers são mecanismos que os servidores federados utilizam para comunicar-se com e recuperar dados das origens de dados. O DB2 inclui dois wrappers para Sybase, CTLIB e DBLIB. O exemplo a seguir mostra uma instrução CREATE WRAPPER:
CREATE WRAPPER CTLIB
onde CTLIB é o nome do wrapper padrão utilizado com o software Open Client do Sysbase. O wrapper CTLIB pode ser utilizado em servidores Windows NT, AIX e Solaris.
Você pode substituir o nome do wrapper padrão por um nome de sua escolha. Entretanto, se isso acontecer, será necessário também incluir o parâmetro LIBRARY e o nome da biblioteca wrapper para seu servidor federado na instrução CREATE WRAPPER. Consulte a instrução CREATE WRAPPER na publicação DB2 SQL Reference para obter mais informações sobre os nomes de bibliotecas do wrapper.
Para melhorar o desempenho quando a origem de dados do Sybase é acessada, defina a variável de ambiente DB2_DJ_COMM. Essa variável determina se um wrapper é carregado quando o servidor federado é inicializado. Defina a variável de ambiente DB2_DJ_COMM para incluir a biblioteca wrapper que corresponde ao wrapper especificado na etapa anterior; por exemplo:
db2set DB2_DJ_COMM='libctlib.a'
db2set DB2_DJ_COMM='libctlib.so'
Assegure-se de que não haja nenhum espaço em nenhum lado do sinal de igual (=).
Consulte a publicação DB2 SQL Reference para obter mais informações sobre os nomes de bibliotecas do wrapper. Consulte a publicação Manual do Administrador para obter informações sobre a variável de ambiente DB2_DJ_COMM.
Utilize a instrução CREATE SERVER para definir cada servidor Sybase cujas origens de dados você deseja acessar; por exemplo:
CREATE SERVER SYBSERVER TYPE SYBASE VERSION 12.0 WRAPPER CTLIB OPTIONS (NODE 'sybnode', DBNAME'sybdb')
onde:
Embora o nome do nó seja especificado como uma opção, ele é requerido para as origens de dados do Sybase. Consulte a publicação DB2 SQL Reference para obter informações sobre as opções adicionais.
Você pode utilizar a opção IGNORE_UDT do servidor com os protocolos CTLIB e DBLIB para especificar se o servidor federado deverá determinar o tipo interno sujeito a um UDT sem um tipo forte. Esta opção aplica-se apenas a origens de dados acessadas através dos protocolos CTLIB e DBLIB. Os valores válidos são:
Quando o DB2 cria pseudônimos, procura e cataloga informações sobre os objetos (tabelas, exibições, procedimentos armazenados) aos quais os pseudônimos apontam. Conforme ele procura pelas informações, pode achar que alguns objetos possuem tipos de dados que ele não reconhece (ou seja, tipos de dados que não mapeiam contrapartes no banco de dados federado). Tais tipos não reconhecidos podem incluir:
Quando o servidor federado encontra tipos de dados que ele não reconhece, retorna a mensagem de erro SQL3324N. Entretanto, ele pode fazer uma exceção a esta prática. Para origens de dados acessíveis através de protocolos CTLIB ou DBLIB, é possível definir a opção IGNORE_UDT do servidor de modo que o banco de dados federado encontre um UDT não reconhecido sem impressão intensa, o banco de dados federado determina qual é o tipo interno da UDT. Em seguida, se o banco de dados federado reconhece este tipo interno, o banco de dados federado retorna informações sobre o tipo interno para o catálogo. Para que o banco de dados determine os tipos de UDT que não possuem impressão intensa, defina IGNORE_UDT como 'Y'.
Especifique os limites de timeout, o caminho e o nome do arquivo de interfaces e o tamanho do pacote do arquivo de interfaces. O Sybase Open Client utiliza os limites de timeout para interromper as consultas e as respostas que são executadas por um longo período de tempo. Você pode definir esses limites no DB2, utilizando a opção CONNECTSTRING da instrução CREATE SERVER OPTION DDL . Utilize a opção CONNECTSTRING para especificar:
.-;-------------------------------.
V |
>>---+-----------------------------+-+-------------------------><
+-TIMEOUT-- = --seconds-------+
+-LOGIN_TIMEOUT-- = --seconds-+
+-IFILE-- = --"string"--------+
+-PACKET_SIZE-- = --bytes-----+
'-;---------------------------'
Exemplos:
Em servidores Windows NT, para definir o valor de timeout como 60 segundos e o arquivo de interfaces como C:\etc\interfaces, utilize:
CREATE SERVER OPTION connectstring FOR SERVER sybase1 SETTING 'TIMEOUT=60;LOGIN_TIMEOUT=5;IFILE="C:\etc\interfaces"'
Em servidores AIX e Solaris, defina o valor do timeout como 60 segundos e o arquivo de interfaces como/etc/interfaces, utilize:
CREATE SERVER OPTION connectstring FOR SERVER sybase1 SETTING 'TIMEOUT=60;PACKET_SIZE=4096;IFILE="/etc/interfaces"'
Se um ID do usuário ou uma senha no servidor federado for diferente de um ID do usuário ou senha da origem de dados do Sybase, utilize a instrução CREATE USER MAPPING para mapear o ID do usuário local para o ID do usuário e a senha definidos na origem de dados do Sybase; por exemplo:
CREATE USER MAPPING FOR DB2USER SERVER SYBSERVER OPTIONS ( REMOTE_AUTHID 'sybuser', REMOTE_PASSWORD 'day2night')
onde:
Consulte a publicação DB2 SQL Reference para obter mais informações sobre opções adicionais.
Atribua um pseudônimo para cada exibição ou tabela localizadas em sua origem de dados do Sybase. Você utilizará esses pseudônimos quando consultar a origem de dados do Sybase. Os pseudônimos do Sybase têm distinção entre maiúsculas e minúsculas. Coloque o esquema e os nomes de tabelas entre aspas duplas ("). O exemplo a seguir mostra uma instrução CREATE NICKNAME:
CREATE NICKNAME SYBSALES FOR SYBSERVER."salesdata"."europe"
onde:
data_source_name."remote_schema_name"."remote_table_name"
Repita essa etapa para cada tabela ou exibição, para a qual você deseja criar pseudônimos. Quando você cria o pseudônimo, o DB2 utilizará a conexão para consultar o catálogo de origens de dados. Essa consulta testa sua conexão à origem de dados. Se a conexão não funcionar, você receberá uma mensagem de erro.
Consulte a publicação DB2 SQL Reference para obter mais informações sobre a instrução CREATE NICKNAME. Para obter mais informações sobre os pseudônimos em geral e para verificar os mapeamentos de tipos de dados, consulte a publicação Manual de Administração do DB2.
Esta etapa é necessária apenas quando o servidor federado do DB2 e o
servidor Sybase estão executando diferentes páginas de códigos. As
origens de dados que estão utilizando o mesmo conjunto de códigos que o DB2,
não requerem conversão. A tabela a seguir fornece opções equivalentes
do Sybase para páginas de códigos do NLS (National Language Support).
As origens de dados do Sybase devem ser configuradas para corresponder a esses
equivalentes ou o código do cliente deve conseguir detectar a inconsistência e
sinalizá-la como um erro ou mapear os dados utilizando suas próprias
semânticas. Se nenhuma tabela de conversão puder ser encontrada da
página de códigos de origem para a página de códigos de destino, o DB2 emitirá
uma mensagem de erro. Consulte a documentação do Sybase, para obter
mais informações.
Tabela 2. Opções da Página de Códigos Sybase
| Página de código | Opção Sybase equivalente |
|---|---|
| 850 | cp850 |
| 897 | sjis |
| 819 | iso_1 |
| 912 | iso_2 |
| 1089 | iso_6 |
| 813 | iso_7 |
| 916 | iso_8 |
| 920 | iso_9 |