Aprenda a instalar o banco de dados IBM Informix Dynamic Server
O banco de dados IBM Informix Dynamic Server também conhecido por IBM IDS foi primeiramente desenvolvido e comercializado pela Informix Inc.,nos Estados Unidos nos anos 70. Em meados de 2001 a divisão de banco de dados Informix foi vendida para a IBM, que mantém o desenvolvimento do produto que se encontra atualmente na versão 10. Atualmente, este banco de dados relacional possui uma variedade de plataformas que se estendem desde a família Windows até distribuições Linux, passando por praticamente todas as plataformas Unix.
Existem diferentes formas de se instalar um servidor de banco de dados Informix, dada a quantidade de pontos a serem configurados. Contudo, daremos aqui uma explanação sobre vários aspectos envolvidos em um determinado processo de instalação em ambiente Unix. Espera-se que esta explanação possa ajudar de forma clara e abrangente todas as fases envolvidas na instalação do IBM IDS, além de ajudar na determinação da melhor forma para se utilizar adequadamente este produto, tirando-se o máximo benefício.
Analisando-se os arquivos de notas (release notes) disponíveis em HTML ou arquivos texto, você encontrará informações específicas sobre plataformas, parâmetros do núcleo do sistema operacional (kernel) recomendados, diretórios requeridos, interfaces suportadas e atualização de documentação. Estas informações podem ser encontradas no diretório ($INFORMIXDIR/ release/en_us/0333) do produto.
O primeiro ponto para tornar um servidor de banco de dados IBM IDS disponível é necessário que sejam observados alguns parâmetros de configuração do sistema operacional como semáforos (Ler Nota 1) e memória compartilhada (Ler Nota 2). A seguir daremos uma explanação de como se configurar estes parâmetros para sistemas Unix System V e BSD.
System V
- SMMNI: número máximo de semáforos disponível;
- SEMMSL: número máximo de semáforos por grupo (deve ser >= 100);
- SEMMNS: número total de semáforos disponível;
- SHMMAX: tamanho máximo de um segmento de memória compartilhada;
- SHMSEG: número máximo de segmentos que um processo pode acessar;
- SHMMNI: número máximo de segmentos para um sistema Unix;
BSD
- SEMMNI: número máximo do conjunto de semáforos disponível;
- SEMMNS: umero total de semáforos;
- SHMSIZE: tamanho máximo de um segmento de memória compartilhada;
- SHMMNI: número máximo de segmentos para um sistema Unix;
$ sysctl –p
- BUFFERS - numero máximo de buffers da memória compartilhada
- LOCKS - numero inicial de locks usado pelos objetos do banco de dados
- LOGBUFF - tamanho dos buffers de logical log
- PHYSBUFF - tamanho dos buffers de physical log
- RESIDENT - especifica residência para a porção residente da memória compartilhada do banco
- SERVERNUM - especifica um identificador único como sendo numero do banco de dados na rede
- SHMTOTAL - total de memória usada para um servidor de banco de dados
- SHMADD - tamanho de segmento de memória a ser adicionado dinamicamente
- SHMTOTAL - total de memória a ser utilizado pelo servidor de banco de dados
- SHMVIRTSIZE - total de memória a ser utilizado pelo servidor de banco de dados
Semáforos são como um tipo de bandeira que controlam mecanismos de lock. O servidor usa estes mecanismos para controlar processos e quando não há trabalho disponível, eles são colocados em estado de suspensão (sleep). Também são usadas para sincronizar comunicação entre o cliente e o servidor em conexões do tipo memórias compartilhadas (shared memory). Neste caso, são alocados para a instancia e um semáforo para cada conexão na memória compartilhada.
Para sistemas Linux que utilizam kernel 2.4.x, possuem um valor padrão de parâmetro msgmni (fila de mensagem) de 16, o que permite somente poucas conexões simultâneas ao IDS. Além disto, o parâmetro deve ser configurado para que o IDS seja usado adequadamente.
Os parâmetros de memória compartilhada são usados para criar um ambiente no servidor para que este acomode as necessidades do banco de dados à realidade do seu computador. Estes valores assim, como tantos outros existentes no arquivo de configuração do IBM IDS (ver Listagem 15) serão usados toda a vez em que o servidor de banco de dados for iniciado, criando um ambiente operacional para que o banco de dados possa fazer uso dos recursos existente no computador o qual foi criado.
Métodos de I/O
O Segundo ponto é entendermos os métodos de I/O no IBM IDS. Para tanto, necessitamos primeiramente identificar alguns processos que estão em constante operação no servidor. Virtual processor são agrupados em classes, uma classe de virtual processor são processos utilizados para a execução de tarefas como, por exemplo, gravar dados em disco ou o processo que aguarda conexões ao banco de dados. Cada grupo de virtual processor manipula o mesmo tipo de atividade. O IBM IDS é composto por várias classes de processos onde, cada uma delas será responsável por um conjunto de tarefas (Ler Nota 2). Outro ponto a ser questionado é, os chamados dispositivos de acesso cru, do inglês raw devices que na verdade são arquivos de dispositivo de disco orientados a caractere, por outro lado temos os arquivos de disco orientados a blocos (cooked files). Cooked Files são arquivos regulares gerenciados pelo sistema operacional, podendo ser espaços em disco não contínuos diferentemente dos arquivos raw que devem ser espaços contíguos de disco.
Veja a primeira posição da listagem 3 que demonstra como identificar estes tipos de dispositivos. Estes arquivos são encontrados no diretório de dispositivos do Unix (/dev). Os dispositivos do tipo raw não são partições montadas e gerenciadas pelo sistema de arquivos do Unix, ficando seu gerenciamento a critério da aplicação que efetua as operações de escrita e leitura de dados, provendo maior desempenho de I/O, pois, o dispositivo raw não usa o buffer cachê do Unix, pois ele transfere diretamente o buffer do SGBD para o disco além do fato de que se usando dispositivos raw não há custos para manutenção de i-nodes e de blocos livres ou utilizados no sistema de arquivos. Estes dispositivos raw pertencem à classe CPU de virtual processor. Finalmente temos o componente conhecido como thread onde, um pequeno número de virtual processor (VPs) será suficiente para realizar tarefas de muitas aplicações porque o servidor de banco de dados divide estas requisições da aplicação em partes, cada parte desta divisão é conhecida como thread. O virtual processor pode planejar o processamento destas threads individualmente e executá-las concorrentemente. Por esta razão virtual processor (VPs) são processos chamados multithreaded. Abaixo descreveremos os métodos de I/O do IBM IDS.
O IBM IDS executa o I/O de modo assíncrono, ou seja, são criadas filas de requisições de I/O, que independem do tipo de thread que a requisitou (AIO ou KAIO). O I/O assíncrono permite que as threads que requisitaram a tarefa de I/O continuem seu respectivo processo enquanto que o I/O é executado. O IBM IDS irá utilizar I/O assíncrono utilizando um dos dois métodos a seguir:
O método que utiliza KAIO (kernel asynchronous I/O), é um método que permite um ganho em desempenho das funções de I/O. Este método é coordenado pelo núcleo (kernel) do sistema operacional, e é manuseado pela thread kio. A thread kio é iniciada quando o primeiro dispositivo raw é acessado ou aberto, por exemplo, como quando se abre um arquivo para modo de edição. Quando uma requisição de escrita ou leitura é feita por uma sessão de um usuário, esta requisição é colocada em uma fila de I/O assíncrono, a partir deste momento, a thread kio lê a requisição e a submete ao sistema operacional para que este realize a operação solicitada, simultaneamente a thread kio finaliza a sua operação, pois, neste instante temos a ocorrência de agentes intrínsecos ao sistema operacional e aos dispositivos de hardware. O sistema operacional é responsável pela operação entre o buffer de memória e o disco, então, o virtual processor da classe CPU, monitorando o sistema operacional, descobre que a operação de I/O foi executada e que a requisição está agora na fila de solicitações atendidas. Este método de I/O somente será utilizado se forem criados os dispositivos do tipo raw.
O método que utiliza AIO (asynchronous I/O) são responsáveis por operações de escrita e leitura em disco, unicamente quando o método KAIO não está sendo utilizado, sendo que este método executará as tarefas de I/O em cooked files. O virtual processor da classe AIO pode ser adicionado ao IBM IDS dinamicamente quando em modo on-line. Na listagem 2 verificamos a adição de quatro threads AIO de classe CPU e a retirada de duas threads AIO da mesma classe, automaticamente e com o banco de dados em modo on-line. Algumas plataformas Unix não suportam KAIO (Ler Nota 4).
$ onstat -g glo
............................
Virtual processor summary:
class vps usercpu syscpu total
cpu 1 18233.50 11543.55 29777.05
aio 1 14.15 43.23 57.38
lio 1 11.47 36.91 48.38
pio 1 12.83 42.44 55.27
adm 1 68.89 118.39 187.28
soc 2 740.98 1667.37 2408.35
msc 1 39.35 20.01 59.36
total 8 19121.17 13471.90 32593.07
$ onmode -p +2 AIO
............................
Virtual processor summary:
class vps usercpu syscpu total
cpu 3 18233.50 11543.55 29777.05
............................
$ onmode –p -2 AIO
............................
Virtual processor summary:
class vps usercpu syscpu total
cpu 1 18233.50 11543.55 29777.05
............................
- AIO - classe que manuseia IBM IDS I/O assíncrono quando a opção de KAIO não está ativa.
- adm - classe que manuseia o temporizador que controla o tempo de espera de outros threads.
- adt - classe que manuseia auditoria.
- cpu - classe que executa todas as sessões que processam SQL vindas da aplicação, dentre outros processos internos.
- jvp - classe de execução de componentes Java.
- kio - classe que manuseia kernel AIO.
- encrypt - classe que manuseia funções de encriptação e decriptação de dados.
- lio - classe que manuseia logical log.
- pio - classe que manuseia physical log.
- msc - classe que manuseia aspectos genéricos de I/O.
- opt - classe usado para subsistemas ópticos.
- shm - classe usada para comunicação.
- soc - classe usada para comunicação.
- str - classe usada para comunicação.
- tli - classe usada para comunicação.
Criando um raw device
Para criar um dispositivo do tipo raw demonstrado na Listagem 3, é necessário que se possua uma partição de disco disponível para o dispositivo. Para criar um raw device é preciso desmontar um sistema de arquivos já existente ou criar uma porção nova de disco (Ler Nota 3) para algumas plataformas Unix, contudo é necessário consultar a documentação do sistema operacional para a criação correta do dispositivo, tirando o máximo desempenho de acordo com a plataforma. Criar uma área de disco que não pertence ao sistema de arquivo ou uma área de disco não montável. Definir permissão específica para o dispositivo e alterar o grupo e o dono do arquivo para o nome do produto, neste caso o usuário dono do produto é a conta informix, verificar na Listagem 4. Após a criação de um dispositivo do tipo raw, pode ser criado um link simbólico ou não para o dispositivo, pois, normalmente os dispositivos possuem em seus nomes combinações de letras e números o que pode tornar difícil a associação do nome do dispositivo com o nome da área em disco a ser utilizada, desta forma, o nome associado ficará mais fácil de ser administrado. Só não podemos esquecer de executar as mesmas alterações no novo link com relação ao dono, grupo e permissão do arquivo. O dispositivo raw não poderá ser montado (mount) no sistema de arquivos nem tão pouco ser objeto de execução do comando mkfs (make filesystem), com o risco de inviabilizar o uso ou mesmo a perda de dados caso este já tenha sido associado ao banco de dados.
Uma forma de saber se a associação do dispositivo do tipo raw com o banco de dados é verificar o primeiro caractere do dispositivo, onde a letra “c” determina um dispositivo do tipo caractere especial, conforme a Listagem 3. O comando de adição do chunk ao banco de dados esta especificado na Listagem.
$ ls –l /dev/rdisk*
crw-rw---- 1 informix informix 64 Dec 23 2004 rdisk_1_1
crw-rw---- 1 informix informix 64 Dec 23 2004 rdisk_1_2
crw-rw---- 1 informix informix 64 Dec 23 2004 rdisk_1_3
$ ls –l /dev/informix*
brw-r----- 1 informix informix 64 Mar 15 2004 informix
brw-r----- 1 informix informix 64 Mar 15 2004 informix_tools
brw-r----- 1 informix informix 64 May 5 2004 informix_msgs
Consulte a documentação do seu sistema operacionalAIX – use o comando mklvSun – use o comando vxassist makeHP-UX – use o comando lvcreateLinux – use o comando lvcreate.
$ ls –l /dev/ifmx* # listagem dos dispositivos existentes
cr-r----- 2 root staff 9, 5 Jan 1 12:00 /dev/ifmx-raw-001
cr-r----- 2 root staff 9, 5 Jan 1 12:10 /dev/ifmx-raw-002
$chown Informix.informix /dev/ifmx* # alteração do dono e do grupo dos arquivos raw
$ ls –l /dev/ifmx*
cr—r----- 2 informix informix 9, 5 Jan 1 12:00 /dev/ifmx-raw-001
cr—r----- 2 informix informix 9, 5 Jan 1 12:10 /dev/ifmx-raw-002
$chmod 660 /dev/ifmx* # alteração do modo dos arquivos raw
$ ls –l /dev/ifmx*
crw-rw---- 2 informix informix 9, 5 Jan 1 12:00 /dev/ifmx-raw-001
crw-rw---- 2 informix informix 9, 5 Jan 1 12:10 /dev/ifmx-raw-002
Para certificar se o seu sistema operacional e hardware suportam o método KAIO de I/O, consulte o diretório do IBM IDS.
$INFORMIXDIR/ release/en_us/0333/
Criando um cooked file
Não é recomendado que se utilize sistemas de arquivos do Unix, especialmente se seu sistema operacional pode obter vantagens do kernel AIO. Contudo, é muito fácil criar um cooked file listagem 5, sem a preocupação em investigar a quantidade de disco disponível para se alocar para uma área do banco de dados. Para adicionar mais espaço no banco de dados consulte a Listagem 18.
$ su informix
$ cd /usr/data
$ touch /usr/data/my_file
$ chmod 660 /usr/data/my_file
$ chgrp informix /usr/data/my_file
$ chown informix /usr/data/my_file
$ ls -l /usr/data/my_file
-rw-rw---- 1 informix informix 0 Jan 1 12:00 /usr/data/my_file
Note que o valor 0 (zero) indica que o arquivo foi apenas inicializado e não possui conteúdo.
Configurando Variáveis de ambiente
Para acessar iniciar ou parar o servidor de banco de dados, cada usuário precisa configurar um conjunto apropriado de variáveis de ambiente. As variáveis necessárias para um ambiente não complexo é mostrada abaixo (Ler Nota 5).- INFORMIXDIR deve ser alimentada com o valor referente ao diretório onde o produto será instalado.
- PATH deverá conter além dos valores referentes ao Unix os valores das variáveis $INFORMIXDIR/bin
- INFORMIXSERVER deverá conter o nome do servidor de banco de dados.
- ONCONFIG deverá conter o valor referente ao diretório onde se encontra o arquivo de configuração.
- TERM deverá conter o valor referente ao terminal usado pelo cliente.
- TERMINFO arquivo de configuração de padrão de terminais clientes.
- TERMCAP arquivo de configuração de padrão de terminais clientes.
- INFORMIXTERM especificam qual o padrão usado pelas ferramentas de edição de arquivos SQL.
Recomenda-se que sejam levantadas todas as variáveis de ambiente necessárias e que seja criado um arquivo de inicialização para que, toda a vez que a aplicação ou usuário efetivar uma conexão no servidor de banco de dados, este arquivo de configuração seja lido e as variáveis de ambiente sejam carregadas para configurar o ambiente adequadamente. Damos um exemplo de configuração de um arquivo de inicialização na listagem 6.
$ vi /etc/profile # abre o arquivo /etc/profile em modo de edição
……………………
# Configura Terminal
export TERM=vt100
stty erase ^H intr ^C
# Configura Variável de ambiente do IBM IDS
export INFORMIXDIR=/informix
export INFORMIXSERVER=my_server
export ONCONFIG=/informix/etc/onconfig.my_server
export PATH=$PATH:$INFORMIXDIR/bin:.
export TERMCAP=/informix/etc/termcap
export INFORMIXTERM=termcap
Configurando a conectividade
A conectividade permite que uma aplicação consiga conectar-se a qualquer servidor de banco de dados da rede. As informações de conectividade contemplam o nome do servidor de banco de dados, o tipo de conexão utilizada o nome do computador que hospeda o servidor de banco de dados e o nome do serviço pelo qual o servidor de banco de dados será conhecido. No IBM IDS temos o modelo cliente/servidor. Este modelo permite que a aplicação seja disponibilizada em um computador enquanto que o servidor de banco de dados seja outro componente ou, simplesmente ambos podem coexistir em um mesmo computador. No IBM IDS temos alguns métodos disponíveis para uma aplicação conectar-se ao servidor de banco de dados.
Temos o método chamado de conexão local onde a comunicação entre o servidor de banco de dados e a aplicação residem no mesmo computador. A conexão com a memória compartilhada (shared memory). Este método utiliza um canal de comunicação através do qual o cliente a o servidor de banco de dados comunicam-se entre si. A Figura 1 demonstra uma conexão shared memory.
Este método provê um desempenho muito grande para o servidor de banco de dados, porém, ele possui uma agravante em termos de segurança. Programas errôneos ou de cunho malicioso, poderão destruir os buffers de mensagem ou ainda programas poderão acessar os endereços de memória previamente solicitados pela aplicação destruindo seus conteúdos e causando danos irreparáveis. Tais programas não afetarão o servidor de banco de dados se for utilizada comunicação via stream-pipe ou via TCP/IP. Este tipo de conexão somente será utilizado se for configurado pelo administrador, o tamanho usado para a comunicação é de aproximadamente 12 KB multiplicado pelo numero de conexões esperadas. Veja a entrada my_server2 na Listagem 16 que define uma conexão via memória compartilhada (shared memory).
Um outro método de comunicação local é quando se utiliza conexão do tipo stream-pipe, conhecido como comunicação interprocesso (IPC) do Unix, que permite a comunicação entre processos em um mesmo servidor. As Vantagens deste método são que, diferentemente de conexões do tipo shared memory, este processo não coloca em risco a memória compartilhada do servidor e além disto, permite transações distribuídas entre bancos de dados disponibilizados em um mesmo servidor. Suas desvantagens são que, conexões stream-pipe são mais lentas que as conexões shared memory e que em algumas plataformas este tipo de conexão não está disponível.
O terceiro método, usando-se uma conexão local-loopback como se a aplicação e o servidor de banco de dados estivessem em computadores diferentes. Este tipo de conexão, igualmente IPC não permite que a memória compartilhada seja alvo de programas errôneos, porém em contrapartida, tem menor desempenho que conexões via shared memory. Esta conexão usa sockets ou interfaces de programa TLI (Transport Layer Interface).
Arquivos para Conectividade
Os arquivos de conectividade contém informações que permitem a comunicação entre o cliente e o servidor. Estes arquivos permitem também que o servidor de banco de dados comunique-se com outros servidores de banco de dados. Quando o servidor de banco de dados é configurado para usar protocolos de rede TCP/IP, as informações contidas em /etc/hosts e /etc/services são usadas para que seja preparado o arquivo $INFORMIXDIR/etc/sqlhosts. O arquivo /etc/hosts (Ler Nota 6), contém uma entrada para cada adaptador de rede do servidor de banco de dados contendo as informações. O arquivo $INFORMIXDIR/etc/sqlhosts Listagem 9, contém uma entrada para cada serviço disponível do protocolo TCP/IP e contém as seguintes informações. O nome do serviço e o numero do porte são arbitrários, contudo eles devem ser únicos no contexto do arquivo e devem ser iguais entre os servidores disponíveis no contexto servidores de banco de dados.
| IP address | host name | host alias(es) |
|---|---|---|
| 10.12.0.10 | my_host1 | my_alias1.company.com.br |
| 10.12.0.11 | my_host1 | my_alias2 |
| 10.12.0.12 | my_host1 | |
| 10.12.0.13 | my_host1 | |
| 10.12.0.14 | my_host2 |
| service name | port number and protocol aliases(optional) |
| my_instance1 | 10001/tcp |
O sistema operacional restringe o uso de portes de comunicação menores que o valo de 1024, portanto apenas use números de portes de comunicação superiores a 1024, para evitar conflitos.
TCP/IP poderão ser usados em ambos os casos onde, a aplicação e o servidor de banco de dados residirem ou não no mesmo servidor físico. Podemos definir o método de comunicação entre aplicação e o banco de dados, usando-se parâmetros de configuração e variáveis de ambiente. Quando este método é selecionado, existem outros arquivos que devem ser configurados tais como o arquivo de serviços /etc/services exemplificado na listagem 7 e o arquivo de hosts /etc/hosts exemplificado na listagem 8 sendo que, cada entrada neste arquivo, representa um computador de sua rede. O arquivo contém o endereço IP do próprio servidor de banco de dados, o nome deste servidor e como valor opcional um apelido, conhecido como alias, podendo este campo ser um domínio ou apenas um nome que define um servidor.
$ grep 1000 /etc/services
my_instance1 10001/tcp # Informix service1
my_instance2 10002/tcp # Informix service2
my_instance3 10003/tcp # Informix service3
my_instance4 10004/tcp # Informix service4
my_instance5 10005/tcp # Informix service5
$ vi /etc/hosts # Abre o arquivo /etc/hosts em modo de edição
………………………………………
10.12.0.10 my_host1 my_alias1.company.com.br
10.12.0.11 my_host2 my_alias2
10.12.0.12 my_host3
10.12.0.13 my_host4
Configuração de múltiplos portes
Em se possuindo vários adaptadores de rede no servidor, poderemos definir diferentes portes para um mesmo servidor de banco de dados onde, será necessária uma configuração múltipla no arquivo de serviços /etc/services e como conseqüência múltiplas entradas nos arquivos /etc/hosts e $INFORMIXDIR/etc/sqlhosts. No arquivo de configuração onconfig poderá ser utilizada uma das entradas para o parâmetro DBSERVERNAME e outra para o parâmetro DBSERVERALIASES. Aplicações poderão utilizar-se dos nomes definidos no arquivo de configuração comunicando-se por vias distintas providas pelos múltiplos adaptadores de rede.
Usando-se vários adaptadores de rede, poderemos criar um complexo método de comunicação entre a aplicação e o servidor de banco de dados, pois, imagine um servidor com dois adaptadores de rede com seus respectivos endereços IP (Ler Nota 8). Com dois adaptadores de rede ver listagens 9, 10 e 11, é necessário que precisemos descriminar todos os endereços IP no arquivo /etc/hosts. E no arquivo $INFORMIXDIR/etc/sqlhosts colocamos um metacaracter ‘*’ (asteristico) como código determinante de endereço IP na terceira posição, fazendo com que o servidor procure por todos os possíveis endereços IP que possam comunicar-se com o porte especificado, através de chamadas de sistema, quando o sistema operacional estiver em pleno funcionamento, o servidor de banco de dados deverá utilizar-se apenas dos protocolos TCP/IP para esta finalidade onde, uma das entradas será necessária para prover a conexão.
$ cat $INFORMIXDIR/etc/sqlhosts
DBSERVERNAME nettype hostname servicename options
my_server ontlitcp *my_server my_service
my_server ontlitcp *10.12.0.10 my_service
my_server_alias ontlitcp *my_server1 my_service
my_server_alias ontlitcp *10.12.0.11 my_service
my_instance1 10001/tcp # Informix service1
my_instance2 10002/tcp # Informix service2
DBSERVERNAME my_server # Name of default database server
DBSERVERALIASES my_server_alias # List of alternate DBSERVERNAME
Configurando arquivos de segurança de rede
IBM IDS segue padrões de segurança baseados na informação de segurança de rede. Para uma aplicação conectar-se ao servidor de banco de dados, o usuário precisa ter um ID válido no servidor remoto. O arquivo /etc/hosts.equiv contém os servidores remotos e usuários confiáveis pelo servidor de banco de dados, os quais podem se conectar sem o uso de senha Listagem 12. O sistema operacional usa este arquivo para determinar se o solicitante é ou não confiável. O arquivo $HOME/.rhosts pode ser usado para específicos usuários de computadores confiáveis ao invés de utilização genérica. Para se testar a confiabilidade entre os sistemas envolvidos, verifique a listagem 13.
$ grep my_server /etc/hosts.equiv
……
my_server1
my_server2
my_server3
……
my_server /home/my_account $ rlogin my_server1
my_server1 /home/my_account1 $
O usuário cliente deverá estar listado no arquivo /etc/passwd para que este tenha condições de efetuar a conexão no servidor de banco de dados. Alguns sistemas operacionais possuem um arquivo chamado de /etc/shadow que é usado como cópia de segurança do arquivo de senhas /etc/passwd. O arquivo .netrc é também utilizado para conexões remotas e é composto por nomes de maquinas, nomes de usuários e senhas de acesso, o qual necessita de administração no caso de alteração de configuração de algum de seus campos. Se o seu sistema utiliza NIS (Produto SUN Microsystems), que permite a propagação de arquivos de rede para outros computadores deve ser verificado seu funcionamento e como administrá-lo para evitar problemas de conexão causados pela manutenção dos arquivos /etc/hosts e /etc/services, garantindo-se que as alterações sejam efetuadas no servidor NIS (master) e, a partir dai seja propagada para os servidores secundários (slaves).
Se a aplicação de cliente e o servidor de banco de dados residirem em diferentes maquinas, o arquivo $INFORMIXDIR/etc/sqlhosts deverá estar definido nos dois ambientes com as mesmas informações. Pois, esta informação é requerida pelo servidor de banco de dados para processos iniciais.
Configurando o arquivo sqlhosts
Este arquivo é de suma importância para a utilização do servidor de banco de dados IBM IDS. Contém informações necessárias para que aplicações e ferramentas possam se conectar ao servidor de banco de dados. Sendo que para cada um servidor definido na rede, deveremos ter uma entrada nos moldes do arquivo conforme listagem 16. Este arquivo encontra-se no diretório $INFORMIXDIR/etc, porém podemos colocá-lo em um local diferente do padrão para tanto basta alterar sua localização e informar através da variável de ambiente INFORMIXSQLHOSTS Listagem 14. Algumas instalações necessitam que seja configurado o quinto campo do arquivo sqlhosts, (Ler Nota 10) para conhecer as opções e configurações para este campo.
$ export INFORMIXSQLHOSTS=/my_directory/my_sqlhosts.my_server
Configurando o servidor de banco de dados
Os parâmetros de configuração estão armazenados no arquivo $INFORMIXDIR/etc/ONCONFIG, conforme demonstrado na Listagem 15 que é uma réplica do arquivo de configuração, contudo ao ser instalado o produto, será gerado um arquivo padrão em $INFORMIXDIR/etc/ONCONFIG.std que contém valores iniciais de configuração recomenda-se que este arquivo seja duplicado para que o novo arquivo contenha as alterações a serem efetuadas referentes ao novo servidor. O nome do arquivo de configuração do IBM IDS será conhecido pelo ambiente pela variável ONCONFIG, (Ler Nota 5). O novo nome pode representar uma definição do sistema a ser criado, uma boa dica é que se use o nome do arquivo juntamente com o nome do servidor (onconfig.my_server). Ao editar-se este arquivo por meio de um editor comum do sistema operacional, mantendo-se as configurações padrões e alterando-se os valores a serem definidos para um novo servidor de banco de dados. O utilitário onmonitor pode também ser usado como uma ferramenta de edição deste arquivo (Ler Nota 9). Tenha em mente que, alterações pertinentes ao ambiente deste arquivo só terão validade após uma nova reinicialização do servidor. Portanto, quaisquer parâmetros de cunho estrutural, somente terão validade após o servidor de banco de dados ser parado e depois reinicializado, para outros parâmetros dinâmicos, a parada não será necessária, ver listagem 2.
Dynamic Server: Status Parameters Dbspaces Mode Force-Ckpt Archive ...
Status menu to view Dynamic Server.
-----------------------------On-Line------- Press CTRL-W for Help. --------
$ onstat -c
IBM Informix Dynamic Server Version 9.40.UC6 -- On-Line -- Up 84 days 02:10:25 -- 416768 Kbytes
Configuration File: /informix/INF940/etc/onconfig.myserver
# Root Dbspace Configuration
ROOTNAME rootdbs # Root dbspace name
ROOTPATH /dev/ifmx-raw-001
# Path for device containing root dbspace
ROOTOFFSET 0 # Offset of root dbspace into device (Kbytes)
ROOTSIZE 32768 # Size of root dbspace (Kbytes)
# Disk Mirroring Configuration Parameters
MIRROR 0 # Mirroring flag (Yes = 1, No = 0)
MIRRORPATH # Path for device containing mirrored root
MIRROROFFSET 0 # Offset into mirrored device (Kbytes)
# Physical Log Configuration
PHYSDBS phy_myserver # Location (dbspace) of physical log
PHYSFILE 32662 # Physical log file size (Kbytes)
# Logical Log Configuration
LOGFILES 10 # Number of logical log files
LOGSIZE 22926 # Logical log size (Kbytes)
# Diagnostics
MSGPATH /informix/online.log
# System message log file path
CONSOLE /dev/console # System console message path
ALARMPROGRAM /informix/alarm.ksh
# Alarm program path
SYSALARMPROGRAM /informix/etc/evidence.sh
# System Alarm program path
TBLSPACE_STATS 1
# System Archive Tape Device
TAPEDEV /informix/tapedev
TAPEBLK 16 # Tape block size (Kbytes)
TAPESIZE 2048000 # Max amount of data to put on log tape (Kbytes)
# Log Archive Tape Device
LTAPEDEV /informix/ltapedev
LTAPEBLK 16 # Log tape block size (Kbytes)
LTAPESIZE 2048000 # Max amount of data to put on log tape (Kbytes)
# Optical
STAGEBLOB # Informix Dynamic Server/Optical staging area
# System Configuration
SERVERNUM 1 # Unique id corresponding to a Dynamic Server instance
DBSERVERNAME my_server # Name of default database server
DBSERVERALIASES my_server_alias # List of alternate DBSERVERNAMEs
NETTYPE soctcp,1,50,NET # Configure poll thread(s) for nettype
NETTYPE ipcshm,1,50,CPU # Configure poll thread(s) for nettype
NETTYPE tlitcp,1,50,CPU # Configure poll thread(s) for nettype
DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env.
RESIDENT 0 # Forced residency flag (Yes = 1, No = 0)
VPCLASS cpu,num=2 # Number of user (cpu) vps
VPCLASS AIO,num=1 # Number of IO vps
MULTIPROCESSOR 1 # 0 for single-processor, 1 for multi-processor
SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to one
# Shared Memory Parameters
LOCKS 50000 # Maximum number of locks
BUFFERS 30000 # Maximum number of shared buffers
PHYSBUFF 32 # Physical log buffer size (Kbytes)
LOGBUFF 32 # Logical log buffer size (Kbytes)
LOGSMAX 20 # Maximum number of logical log files
CLEANERS 6 # Number of buffer cleaner processes
SHMBASE 0xa000000 # Shared memory base address
SHMVIRTSIZE 65536 # initial virtual shared memory segment size
SHMADD 65536 # Size of new shared memory segments (Kbytes)
SHMTOTAL 629144 # Total shared memory (Kbytes). 0=>unlimited
CKPTINTVL 300 # Check point interval (in sec)
LRUS 12 # Number of LRU queues
LRU_MAX_DIRTY 60 # LRU percent dirty begin cleaning limit
LRU_MIN_DIRTY 50 # LRU percent dirty end cleaning limit
LTXHWM 45 # Long transaction high water mark percentage
LTXEHWM 50 # Long transaction high water mark (exclusive)
TXTIMEOUT 0x12c # Transaction timeout (in sec)
STACKSIZE 32 # Stack size (Kbytes)
# Recovery Variables
# OFF_RECVRY_THREADS:
# Number of parallel worker threads during fast recovery or an offline restore.
# ON_RECVRY_THREADS:
# Number of parallel worker threads during an online restore.
OFF_RECVRY_THREADS 10 # Default number of offline worker threads
ON_RECVRY_THREADS 1 # Default number of online worker threads
# Data Replication Variables
# DRAUTO: 0 manual, 1 retain type, 2 reverse type
DRAUTO 0 # DR automatic switchover
DRINTERVAL 30 # DR max time between DR buffer flushes (in sec)
DRTIMEOUT 30 # DR network timeout (in sec)
DRLOSTFOUND /informix/INF940/etc/dr.lostfound # DR lost+found file path
# Read Ahead Variables
RA_PAGES 10 # Number of pages to attempt to read ahead
RA_THRESHOLD 5 # Number of pages left before next group
# DBSPACETEMP:
# Dynamic Server equivalent of DBTEMP for SE. This is the list of dbspaces
# that the Dynamic Server SQL Engine will use to create temp tables etc.
# If specified it must be a colon separated list of dbspaces that exist
# when the Dynamic Server system is brought online. If not specified, or if
# all dbspaces specified are invalid, various ad hoc queries will create
# temporary files in /tmp instead.
DBSPACETEMP my_temp_space, my_temp_space1 # Default temp dbspaces
# DUMP*:
# The following parameters control the type of diagnostics information which
# is preserved when an unanticipated error condition (assertion failure) occurs
# during Dynamic Server operations.
# For DUMPSHMEM, DUMPGCORE and DUMPCORE 1 means Yes, 0 means No.
DUMPDIR /informix/dump
# Preserve diagnostics in this directory
DUMPSHMEM 1 # Dump a copy of shared memory
DUMPGCORE 0 # Dump a core image using 'gcore'
DUMPCORE 0 # Dump a core image (Warning:this aborts Dynamic Server)
DUMPCNT 1 # Number of shared memory or gcore dumps for
# a single user's session
AFCRASH 0x21
AFFAIL 0x21
AFWARN 0x21
AFLINES 0
FILLFACTOR 90 # Fill factor for building indexes
# method for Dynamic Server to use when determining current time
USEOSTIME 0 # 0: use internal time(fast), 1: get time from OS(slow)
# Parallel Database Queries (pdq)
MAX_PDQPRIORITY 100 # Maximum allowed pdqpriority
DS_MAX_QUERIES # Maximum number of decision support queries
DS_TOTAL_MEMORY # Decision support memory (Kbytes)
DS_MAX_SCANS 1048576 # Maximum number of decision support scans
DATASKIP off # List of dbspaces to skip
# OPTCOMPIND
# 0 => Nested loop joins will be preferred (where
# possible) over sortmerge joins and hash joins.
# 1 => If the transaction isolation mode is not
# "repeatable read", optimizer behaves as in (2)
# below. Otherwise it behaves as in (0) above.
# 2 => Use costs regardless of the transaction isolation
# mode. Nested loop joins are not necessarily
# preferred. Optimizer bases its decision purely
# on costs.
OPTCOMPIND 0 # To hint the optimizer
ONDBSPACEDOWN 2 # Dbspace down option: 0 = CONTINUE, 1 = ABORT, 2 = WAIT
LBU_PRESERVE 1 # Preserve last log for log backup
OPCACHEMAX 0 # Maximum optical cache size (Kbytes)
# HETERO_COMMIT (Gateway participation in distributed transactions)
# 1 => Heterogeneous Commit is enabled
# 0 (or any other value) => Heterogeneous Commit is disabled
HETERO_COMMIT 0
# Optimization goal: -1 = ALL_ROWS(Default), 0 = FIRST_ROWS
OPT_GOAL -1
# Optimizer DIRECTIVES ON (1/Default) or OFF (0)
DIRECTIVES 1
