Algumas vezes me deparei com ambientes de produção onde o Informix não executava nenhuma comando administrativo no UNIX, ao rodar algum comando administrativo recebia a mensagem abaixo:
shared memory not initialized for INFORMIXSERVER 'demo_on'
A primeira coisa que alguem diria é que a variavel INFORMIXSERVER não está setada corretamente, isto também é verdade, porém após checar minha variável de ambiente constatei que o ambiente estava ok.
Nestes casos algumas vezes o DBA preferiu efetuar um bounce na instância e o ambiente voltou ao normal, porém foi necessário entender o porque isto ocorreu, nenhum gestor gosta de ter este tipo de resolução de problema.
Vamos a explicação do problema:
Após o Informix inicializar a shared memory o mesmo cria um arquivo de configuraçao em $INFORMIXDIR/etc chamado infos.dbservername , onde dbservername é o nome da sua instância.
Esse arquivo contém informações básicas para que alguns comandos administrativos (onstat, onmode, oncheck) possam fazr um attach na shared memory, sem esse arquivo não é possivel identificar a SHMKEY que foi gerada na inicialização.
Como vizualizar o arquivo de configuração?
ls -las $INFORMIXDIR/etc/.infos*
Para visualizar o conteudo:
onstat -g pos
Agora vem o conhecimento perdido, e para recriar o arquivo sem ter que reinicializar a instancia?
onmode -R
Quando este arquivo é removido?
Ahhhh , buena pregunta!! Quando tem alguém alterando configuração de servicos (/etc/services) ou fazer limpeza no file-system para recuperar espaço livre.
Caso você queira saber se realmente o problema é arquivo de configuração execute um trace no onstat:
strace onstat -
open("/opt/IBM/informix/etc/.infos.demo_on", O_RDONLYO_LARGEFILE) = -1 ENOENT (No such file or directory)access("/opt/IBM/informix/msg/en_us/0333/olutil.iem", R_OK) = 0close(3) = 0
No linux usamos o strace, em Aix costumo usar o truss, lembre-se de um post anterior que eu falei sobre alocação da shared memory, o IDS na inicialização faz o calculo da SHMKEY através dò cálculo (SERVERNUM * 65536) + shmkey , se o arquivo está lá é bom se a shared memory ainda está alocada , pode ser através do comando ipcs.
Este post me faz lembrar dos anos de Telesp Celular, velhos e bons tempos, mais pra frente irei postar algo sobre conexões IPC Stream Pipe (rodando em Tru64 dava pra fazer magia negra).
Hasta Luego!
sexta-feira, 27 de março de 2009
quinta-feira, 26 de março de 2009
InfoSphere Change Data Capture
Essa é a mais nova viagem para o DBA, essa feature veio após a aquisição da DataMirror , para integra-la ao Informix foi necessário aplicar uma nova feature chamada CDC (change data capture).
Através do CDC é possivel capturar os eventos registrados no log buffer e com isto definir alguma ações, do tipo replicar , transformar etc.
Lembram-se de SolidbDB?
Então com o CDC podemos replicar informações do Informix para uma base SolidDb, isto permite que o DBA distribua a informação em uma instância do tipo In-Memory e redirecione para este aplicações que requerem um response time muito rápido mesmo.
Para saber mais sobre InfoSphere Change Data Capture leia este artigo direto no developer works :
http://www.ibm.com/developerworks/data/library/techarticle/dm-0902govindarajan/
sexta-feira, 13 de março de 2009
IBM Data Server Common Client
Bom o que é o IBM Data Server Common Client?
Resumindo é um client para se conectar a qualquer banco de dados IBM, como assim a IBM só tem o DB2!!
Isto não é verdade, no decorrer dos anos a IBM desenvolveu e adquiriu diversas tecnologias de banco de dados, tais como: System R, IMS, DB2 Z/os, Db2 LUW, Informix Dynamic Server, Informix Extended Parallel Server, Universe , Unidata, Redbrick e outros mais.
Para quem trabalha com DB2 é bom dar uma olhada neste artigo do Paulz:
http://www.ibm.com/developerworks/data/library/techarticle/dm-0804zikopoulos/
Este client é mais conhecido como CCT ( Commom Client Technology), e realmente é muito produtivo para o desenvolvedor.
Explico o porque: muitos desenvolvedores de ferramentas open-source precisam fazer acessos em banco de dados da IBM, sejam eles informix ou db2.
Para trabalhar com as linguages PHP, Perl, Phyton era necessário configurar o cliente fazendo algumas compilações de biblioteca, era algo extremamente dificil, e não era suportado pela IBM.
Agora com o CCT após a instalação do client já temos instalado as bibliotecas para linguagens open-source, e a melhor parte é que caso você tenha qualquer problema com o client você pode abrir um chamado.
Estava de esquecendo do Informix, recentemente foi lancado o Informix Client SDK 3.50, com versão 64 bits, o produto está estável e o suporte para Windows 64 bits está Ok.
Trabalhando com Informix 11.X + CCT podemos usar o client do Db2 (db2clp) para acessar a base e até mesmo usar o .Net Provider do Db2 para acessar o Informix.
Quais o benefícios deste client?
- Portabilidade
- Suporte da IBM
- Recursos adicionais
Bata utilizar o CCT no Informix 11.X é necessário ativar um listener DRDA no Informix, desta forma o Informix estará ouvindo no formato DRDA.
O que é DRDA?
Significa Distibuted Relation Database Architecture, foi definido pelo Open Group como um padrão de interoperabilidade para banco de dados.
Mais sobre o open group:
http://en.wikipedia.org/wiki/The_Open_Group
Curiosidade:
Em 1992 o opengroup definiu o padrão CLI (Call Level Interface) para as linguagens C e Cobol, porteriormente o padrão CLI foi utilizado como base para a criação do padrão ODBC.
As informações que postei aqui são simples, porém são essencias para um desenvolvedor.
Creio que pouca gente imagina que antes do CCT era necessário compilar um driver para que seu programa conect-se a um banco de dados.
Essa dúvida sobre client surgiu numa conversa com meus amigos de Jundiai (terra da uva, do trabalho e da tecnologia), espero que tenha sido útil.
Dúvidas? Somos nozes!! E só perguntar.
Resumindo é um client para se conectar a qualquer banco de dados IBM, como assim a IBM só tem o DB2!!
Isto não é verdade, no decorrer dos anos a IBM desenvolveu e adquiriu diversas tecnologias de banco de dados, tais como: System R, IMS, DB2 Z/os, Db2 LUW, Informix Dynamic Server, Informix Extended Parallel Server, Universe , Unidata, Redbrick e outros mais.
Para quem trabalha com DB2 é bom dar uma olhada neste artigo do Paulz:
http://www.ibm.com/developerworks/data/library/techarticle/dm-0804zikopoulos/
Este client é mais conhecido como CCT ( Commom Client Technology), e realmente é muito produtivo para o desenvolvedor.
Explico o porque: muitos desenvolvedores de ferramentas open-source precisam fazer acessos em banco de dados da IBM, sejam eles informix ou db2.
Para trabalhar com as linguages PHP, Perl, Phyton era necessário configurar o cliente fazendo algumas compilações de biblioteca, era algo extremamente dificil, e não era suportado pela IBM.
Agora com o CCT após a instalação do client já temos instalado as bibliotecas para linguagens open-source, e a melhor parte é que caso você tenha qualquer problema com o client você pode abrir um chamado.
Estava de esquecendo do Informix, recentemente foi lancado o Informix Client SDK 3.50, com versão 64 bits, o produto está estável e o suporte para Windows 64 bits está Ok.
Trabalhando com Informix 11.X + CCT podemos usar o client do Db2 (db2clp) para acessar a base e até mesmo usar o .Net Provider do Db2 para acessar o Informix.
Quais o benefícios deste client?
- Portabilidade
- Suporte da IBM
- Recursos adicionais
Bata utilizar o CCT no Informix 11.X é necessário ativar um listener DRDA no Informix, desta forma o Informix estará ouvindo no formato DRDA.
O que é DRDA?
Significa Distibuted Relation Database Architecture, foi definido pelo Open Group como um padrão de interoperabilidade para banco de dados.
Mais sobre o open group:
http://en.wikipedia.org/wiki/The_Open_Group
Curiosidade:
Em 1992 o opengroup definiu o padrão CLI (Call Level Interface) para as linguagens C e Cobol, porteriormente o padrão CLI foi utilizado como base para a criação do padrão ODBC.
As informações que postei aqui são simples, porém são essencias para um desenvolvedor.
Creio que pouca gente imagina que antes do CCT era necessário compilar um driver para que seu programa conect-se a um banco de dados.
Essa dúvida sobre client surgiu numa conversa com meus amigos de Jundiai (terra da uva, do trabalho e da tecnologia), espero que tenha sido útil.
Dúvidas? Somos nozes!! E só perguntar.
quinta-feira, 5 de março de 2009
INFORMIX: Otimizando Queries com Diretivas
Para quem não está acostumado com o termo "diretiva do otimizador" irei dar um breve descrição:
- Um componente que faz a diferença em um RDBMS é otimizador de plano acesso de queries, este utiliza-se de cálculos baseados em custo ou regra.
No caso do Informix desde a versão 7.X (1994?) o otimizador é baseada em custo, no Informix Online (1990?) lembro-me que não tinha histograma mas creio que já era baseado em custo, porque estou contando esta histórinha?
Bom o Oracle passou a utilizar otimizador baseado em custo a partir da versão 10.X (2004?) , na versão 9.i o otimizador era hibrido o DBA escolhia: custo ou regra. (É mole!!?)
Voltando a nossas diretivas, temos os seguintes tipos:
Diretivas de Métodos de Acesso
Existe somente uma, indica que a ordem de acesso das tabelas na junção será de acordo com a ordem das tabelas na cláusula from do SQL.
ORDERED
Diretivas de Metas
Estas definem o comportamento do otimizador em relação ao retorno do resultado da query.
FIRST_ROWS - O retorno da query ocorre logo após a leitura das primeiras linhas, com isto é mais fácil interromper uma query quando vemos que a mesma não está rápida.
ALL_ROWS - O retorno das primeiras linhas da query ocorre após a leitura de todas as linhas envolvidas na consulta.
Uma diretiva externa é aquela que pode ser armazenada dentro do banco de dados, imagine um ERP onde você não tenha acesso ao código fonte, e foi detectada uma query onde o plano de acesso não esta legal.
Bom neste caso é possível armazenar esta query juntamente com as diretivas dentro de uma tabela de catálogo do Informix, sempre que este comando sql for parseado o engine irá aplicar as diretivas.
Veja exemplo abaixo:
save external directives {+ ORDERED USE_NL(u)} active for SELECT * FROM Tabela1 a, Tabela2 b WHERE b.cod_emp = a.cod_emp
Para consultar as diretivas externas em catálogo:
select * from sysmaster:sysdirectives
Para desativar uma diretiva externa:
UPDATE sysdirectives set active = 0 where id = ?
Para excluir uma diretiva externa:
DELETE from sysdirectives where id = 2
Normalmente quando falamos do otimizador temos que falar de várias tópicos, pois o cálculo do custo está relacionado ao custo de I/O, Network, CPU e seletividade.
Não quero entrar em update statistics mas vale lembrar que além de atualizar as estatisticas do catálogo e gerar os bins do histograma o mesmo tem mais funções, dentre elas varrer as páginas de índices que foram marcadas como excluídas e reenviar para a fila do B-Tree cleaner para que as mesmas sejam removidas.
Eu já tinha ouvido algumas discussões sobre o assunto: Update Statistics reorganiza os índices? Não é bem assim, ele apenas remove entradas marcadas como excluídas dos índices.
Por isto não esqueça de atualizar a estatisticas de suas tabelas e procedures, se você ainda não usa a versão 11.50 começa a pensar em usá-la, pois nesta versão a atualização de estatisticas é automática.
Dúvidas? Pregutas? Questions? Askpuentes!!
- Um componente que faz a diferença em um RDBMS é otimizador de plano acesso de queries, este utiliza-se de cálculos baseados em custo ou regra.
No caso do Informix desde a versão 7.X (1994?) o otimizador é baseada em custo, no Informix Online (1990?) lembro-me que não tinha histograma mas creio que já era baseado em custo, porque estou contando esta histórinha?
Bom o Oracle passou a utilizar otimizador baseado em custo a partir da versão 10.X (2004?) , na versão 9.i o otimizador era hibrido o DBA escolhia: custo ou regra. (É mole!!?)
Voltando a nossas diretivas, temos os seguintes tipos:
Diretivas de Métodos de Acesso
São diretivas que influenciam no caminho usado no plano de acesso, tais como acesso full, indexado etc.
Segue abaixo lista de diretivas:
FULL - Força um acesso sequencial na tabela
AVOID_FULL - Evita que seja executado um acesso sequencial na tabela
INDEX - Força a pesquisa no indice informado
AVOID_INDEX - Desconsidera o indice informado
INDEX_SJ - Força a auto-junção pelo indice informado
AVOID_INDEX_SJ - Evita a auto-junção através do índice informado.
São diretivas que influenciam a forma como a junção entre as tabelas será feita, por exemplo ler tabela a e buscar ocorrência na tabela B (Nested Loop)
Segue abaixo lista de diretivas:
USE_NL
AVOID_NL
USE_HASH
USE_HASH (tabname)
USE_HASH (tabname/BUILD)
USE_HASH (tabname/PROBE AVOID_HASH
Existe somente uma, indica que a ordem de acesso das tabelas na junção será de acordo com a ordem das tabelas na cláusula from do SQL.
ORDERED
Diretivas de Metas
Estas definem o comportamento do otimizador em relação ao retorno do resultado da query.
FIRST_ROWS - O retorno da query ocorre logo após a leitura das primeiras linhas, com isto é mais fácil interromper uma query quando vemos que a mesma não está rápida.
ALL_ROWS - O retorno das primeiras linhas da query ocorre após a leitura de todas as linhas envolvidas na consulta.
Diretivas de Explain
No exemplo abaixo usamo uma diretiva para que o otimizador exiba ao output do plano de acesso no arquivo de explain.
SELECT {+ EXPLAIN } *
FROM Tabela1 a, Tabela2 b
WHERE b.customer_num = a.customer_num
No exemplo abaixo usamo uma diretiva para que o otimizador exiba ao output do plano de acesso no arquivo de explain, porém a query não será executada, somente será criado o plano fe acesso.
SELECT {+ EXPLAIN AVOID_EXECUTE} ......
Definindo Diretivas ExternasUma diretiva externa é aquela que pode ser armazenada dentro do banco de dados, imagine um ERP onde você não tenha acesso ao código fonte, e foi detectada uma query onde o plano de acesso não esta legal.
Bom neste caso é possível armazenar esta query juntamente com as diretivas dentro de uma tabela de catálogo do Informix, sempre que este comando sql for parseado o engine irá aplicar as diretivas.
Veja exemplo abaixo:
save external directives {+ ORDERED USE_NL(u)} active for SELECT * FROM Tabela1 a, Tabela2 b WHERE b.cod_emp = a.cod_emp
Para consultar as diretivas externas em catálogo:
select * from sysmaster:sysdirectives
Para desativar uma diretiva externa:
UPDATE sysdirectives set active = 0 where id = ?
Para excluir uma diretiva externa:
DELETE from sysdirectives where id = 2
Normalmente quando falamos do otimizador temos que falar de várias tópicos, pois o cálculo do custo está relacionado ao custo de I/O, Network, CPU e seletividade.
Não quero entrar em update statistics mas vale lembrar que além de atualizar as estatisticas do catálogo e gerar os bins do histograma o mesmo tem mais funções, dentre elas varrer as páginas de índices que foram marcadas como excluídas e reenviar para a fila do B-Tree cleaner para que as mesmas sejam removidas.
Eu já tinha ouvido algumas discussões sobre o assunto: Update Statistics reorganiza os índices? Não é bem assim, ele apenas remove entradas marcadas como excluídas dos índices.
Por isto não esqueça de atualizar a estatisticas de suas tabelas e procedures, se você ainda não usa a versão 11.50 começa a pensar em usá-la, pois nesta versão a atualização de estatisticas é automática.
Dúvidas? Pregutas? Questions? Askpuentes!!
terça-feira, 3 de março de 2009
Suportando Informix/DB2
Muitos vezes atuando em suporte/consultoria podemos encontrar 2 tipos de problemas:
- Performance
- Down System
Vamos descrever mais sobre esses assuntos, mas lembrem-se vou dar o caminho das pedras, o how-to depende de cada um aplicar o conhecimento..
Performance
-------------
No caso de performance a coisa pode estar tão ruim que não conseguimos executar nem um comando no prompt , muito menos uma query para acessar o catálogo.
Nestes casos podemos utilizar o comando onstat (Informix) ou db2pd (db2), estes trabalham de uma forma diferente das outras ferramentas, através da funçao shmat se atacham a shared memory e executam leituras direta nas estruturas em memória.
Imaginem um ambiente com multiplas instâncias, a qual segmento de memoria o comando irá atachar-se?
Durante o startup da instancia o engine define uma chave (SHMKEY) para o segmento e atrav'es desta chave o onstat/db2pd podem fazer o attach na shared memory.
Alias para saber qual o SHMKEY de cada segmento 'e so executar o comando IPCS (no caso em ambiente UNIX), e possivel relacionar o SHMID com a saida do comando onstat -g seg.
Exemplos:
No informix temos um comando para identificar a quantidade de comandos DML que foram submetidos em uma tabela:
onstat -g ppf --> (e necessario setar o parametro TBLSTATS 1)
No db2 temos um comando com a mesma funcionalidade.
db2pd -db dbname -tcbstats
Down-System
----------------
Agora sabemos que e possivel acessar a shared memory diretamente atrav'es dos comandos onstat/db2pd, mas em caso de Down-System como faremos diagnostico se o engine nao passa pelo startup?
Neste caso 'e necessario utilizar ferramentas com acesso direto ao disco, tais como oncheck (Informix) ou db2dart (Db2).
Para executar o dump de uma pagina no Informix:
oncheck -pP
Para visualizar o conteudo de pagina reservada:
oncheck -pr
Para executar o dump de uma pagina no Db2:
db2dart dbname /ddel
Para DBAS Informix que queiram treinar db2dart este link vai dar uma ajuda:
http://www-01.ibm.com/support/docview.wss?rs=71&uid=swg21244563
Lembre-se que para usar db2dart com DB2_KEYDATACHECK em uma tabela com compressão é necessário aplicar o APAR IY87739
http://www-01.ibm.com/support/docview.wss?uid=swg1IY87739
Alias o que e DB2_KEYDATACHECK?? Lembram-se do CCFLAGS no Informix, bom isto e assunto pra outro post.
Maiores informações sobre o db2pd estão no Information Center:http://publib.boulder.ibm.com/infocenter/db2luw/v9//index.jsp
- Performance
- Down System
Vamos descrever mais sobre esses assuntos, mas lembrem-se vou dar o caminho das pedras, o how-to depende de cada um aplicar o conhecimento..
Performance
-------------
No caso de performance a coisa pode estar tão ruim que não conseguimos executar nem um comando no prompt , muito menos uma query para acessar o catálogo.
Nestes casos podemos utilizar o comando onstat (Informix) ou db2pd (db2), estes trabalham de uma forma diferente das outras ferramentas, através da funçao shmat se atacham a shared memory e executam leituras direta nas estruturas em memória.
Imaginem um ambiente com multiplas instâncias, a qual segmento de memoria o comando irá atachar-se?
Durante o startup da instancia o engine define uma chave (SHMKEY) para o segmento e atrav'es desta chave o onstat/db2pd podem fazer o attach na shared memory.
Alias para saber qual o SHMKEY de cada segmento 'e so executar o comando IPCS (no caso em ambiente UNIX), e possivel relacionar o SHMID com a saida do comando onstat -g seg.
Exemplos:
No informix temos um comando para identificar a quantidade de comandos DML que foram submetidos em uma tabela:
onstat -g ppf --> (e necessario setar o parametro TBLSTATS 1)
No db2 temos um comando com a mesma funcionalidade.
db2pd -db dbname -tcbstats
Down-System
----------------
Agora sabemos que e possivel acessar a shared memory diretamente atrav'es dos comandos onstat/db2pd, mas em caso de Down-System como faremos diagnostico se o engine nao passa pelo startup?
Neste caso 'e necessario utilizar ferramentas com acesso direto ao disco, tais como oncheck (Informix) ou db2dart (Db2).
Para executar o dump de uma pagina no Informix:
oncheck -pP
Para visualizar o conteudo de pagina reservada:
oncheck -pr
Para executar o dump de uma pagina no Db2:
db2dart dbname /ddel
Para DBAS Informix que queiram treinar db2dart este link vai dar uma ajuda:
http://www-01.ibm.com/support/docview.wss?rs=71&uid=swg21244563
Lembre-se que para usar db2dart com DB2_KEYDATACHECK em uma tabela com compressão é necessário aplicar o APAR IY87739
http://www-01.ibm.com/support/docview.wss?uid=swg1IY87739
Alias o que e DB2_KEYDATACHECK?? Lembram-se do CCFLAGS no Informix, bom isto e assunto pra outro post.
Maiores informações sobre o db2pd estão no Information Center:http://publib.boulder.ibm.com/infocenter/db2luw/v9//index.jsp
domingo, 1 de março de 2009
INFORMIX: Usando SQLIDEBUG/SQLIPRINT
Bom muitos ja sabem como fazer trace dos pacotes de rede do Informix, é só ativar a variável SQLIDEBUG conforme abaixo:
export SQLIDEBUG=2:/tmp/sqli_files
Caso voce defina este parâmetro antes de iniciar a instância todos os acessos ao banco irão gerar os arquivos de trace em /tmp com o nom dos arquivos iniciando com sqi_filesXXXX.
Mas e ai? Gerei o trace como faço para interpretá-lo?
Veja a nota oficial no site da IBM:
http://www-01.ibm.com/support/docview.wss?rs=630&context=SSGU8G&dc=DB520&uid=swg21104625&loc=en_US&cs=UTF-8&lang=en&rss=ct630db2
Para interpretar o trace é necessário utilizar um utilitário chamado SQLIPRINT, até há alguns anos este era somente de uso do suporte avançado , porém o mesmo está sendo distribuido com o Client SDK 2.90 a partir do release 2.90.XC4.
Após a instalação do Informix 11.50+Client SDK você pode verificar se o SQLIPRINT está instalado.
cd $INFORMIXDIR
find . -name SQLIPRINT
Afinal de contas, para que necessito de fazer trace do protocolo de comunicaçao do Informix?
Bom, por vários razões, auto-estudo, troubleshooting ou questões de performance, neste caso você quer ajustar os parâmetros FET_BUF_SIZE, OPTMSG, OPTOFC, ou até mesmo ajustar os parâmetros de TCP/IP do sistema operacional.
Onde conseguir mais informações sobre SQLIDEBUG?
Existem algumas apresentações da Informix Conference 2008 postadas no IIUG (http://www.iiug.org/), na área de usuários registrados é possivel baixá-las.
Lembre-se, o SQLIDEBUG é valido somente para conexoes Informix (SQLI), caso você esteja usando um listener DRDA com o IBM Data Server Client (DRDA) ai você deve usar as features do próprio client, mas isto vai ficar pendente para um post dedicado para DRDA.
export SQLIDEBUG=2:/tmp/sqli_files
Caso voce defina este parâmetro antes de iniciar a instância todos os acessos ao banco irão gerar os arquivos de trace em /tmp com o nom dos arquivos iniciando com sqi_filesXXXX.
Mas e ai? Gerei o trace como faço para interpretá-lo?
Veja a nota oficial no site da IBM:
http://www-01.ibm.com/support/docview.wss?rs=630&context=SSGU8G&dc=DB520&uid=swg21104625&loc=en_US&cs=UTF-8&lang=en&rss=ct630db2
Para interpretar o trace é necessário utilizar um utilitário chamado SQLIPRINT, até há alguns anos este era somente de uso do suporte avançado , porém o mesmo está sendo distribuido com o Client SDK 2.90 a partir do release 2.90.XC4.
Após a instalação do Informix 11.50+Client SDK você pode verificar se o SQLIPRINT está instalado.
cd $INFORMIXDIR
find . -name SQLIPRINT
Afinal de contas, para que necessito de fazer trace do protocolo de comunicaçao do Informix?
Bom, por vários razões, auto-estudo, troubleshooting ou questões de performance, neste caso você quer ajustar os parâmetros FET_BUF_SIZE, OPTMSG, OPTOFC, ou até mesmo ajustar os parâmetros de TCP/IP do sistema operacional.
Onde conseguir mais informações sobre SQLIDEBUG?
Existem algumas apresentações da Informix Conference 2008 postadas no IIUG (http://www.iiug.org/), na área de usuários registrados é possivel baixá-las.
Lembre-se, o SQLIDEBUG é valido somente para conexoes Informix (SQLI), caso você esteja usando um listener DRDA com o IBM Data Server Client (DRDA) ai você deve usar as features do próprio client, mas isto vai ficar pendente para um post dedicado para DRDA.
Assinar:
Postagens (Atom)