A variável de ambiente PATH deve ser alterada para incluir $INFORMIXDIR/bin. Embora isso seja opcional, pode ser muito conveniente. É muito mais fácil digitar oninit do que ter que digitar /usr/informix/bin/oninit (assumindo /usr/informix é onde o produto IDS está instalado).
A variável de ambiente ONCONFIG é definida com o nome do arquivo de configuração a ser usado pela instância IDS. Cada instância tem apenas um arquivo de configuração que ele usa em qualquer momento. É possível usar um arquivo de configuração diferente, mas isso faz uma parada do software, alterando a variável de ambiente ONCONFIG para apontar para um arquivo diferente e reiniciando o software.
Note: A variável de ambiente ONCONFIG é definida apenas com o nome do arquivo. Não está definido para o caminho do arquivo. Exemplo:
export ONCONFIG=onconfig.prd
O arquivo onconfig esta localizado em $INFORMIXDIR/etc, então você não precisa saber onde o arquivo esta localizado, apenas o nome do arquivo a ser usado nesse diretório. O arquivo onconfig pode ser nomeado para qualquer outro nome que você deseja; no entanto, o padrão tornou-se onconfig.algo, substituindo o "algo" por um nome significativo, como no exemplo acima ("prd"). Também é possível usar um arquivo chamado onconfig, se essa for sua decisão. Em seguida, a variável de ambiente ONCONFIG torna-se opcional. A variável de ambiente ONCONFIG é importante para o trabalho do DBA (por exemplo, iniciar e parar a instância). A atividade normal do cliente SQL não precisa ter a variável de ambiente ONCONFIG definida.
A variável de ambiente INFORMIXSQLHOSTS é definida com o
caminho completo e o nome do arquivo que está sendo usado para informações de conectividade. Exemplo:
export INFORMIXSQLHOSTS=/work/ajm/mysqlhosts
Esse parametro é opcional pois se ele não estiver setado, o IDS procura pelo arquivo $INFORMIXDIR/etc/sqlhosts que possui as informações que ele necessita. "Que informações são essas?" você se pergunta. Esse tutorial descreve isso na seção "SQLHOSTS".
É importante notar que cada conexão de cliente, interna ou externa, requer informações de conectividade. Então, cada cliente quer obter suas informações do arquivo padrão ou do arquivo apontado pela variável de ambiente INFORMIXSQLHOSTS.
As cinco variáveis de ambiente listadas acima não são as únicas disponíveis para uso com IDS. Na verdade, o IDS possui facilmente mais de 100 variáveis de ambiente que podem ser usadas para controlar diferentes aspectos do software. Este tutorial já mostrou algumas variáveis a mais, como o - DB_LOCALE e CLIENT_LOCALE que controlam as configurações do GLS. Basta lembrar que os cinco listados acima são os mais importantes, e dois deles são necessários.
SQLHOSTS
O arquivo SQLHOSTS é necessário para as informações de conectividade. É uma configuração vital para um banco de dados porque é usado por cada cliente, interno ou externo, que se conecta à instância. Se não estiver configurado corretamente, ninguém poderá se conectar ao banco de dados e obter dados.
IDS é desenvolvido para executar localmente ou remotamente (ambiente distribuído) do cliente. Então, para que o cliente se conecte com sucesso ao IDS, ele precisa saber onde a instância do IDS reside e como chegar a ele. Pense no arquivo sqlhosts como a lista telefônica do IDS. É uma listagem de todas as instâncias de IDS disponíveis (por nome), onde residem (nome do host ou IP do computador) e qual a porta de serviço a ser usada ao enviar uma solicitação, assim como a lista telefônica normal lista as pessoas pelo nome, onde elas vivem (endereço), e como entrar em contato com eles (número de telefone). A porta de serviço do sqlhosts especificam quais portas o IDS respondera as declarações SQL recebidas de seus clientes. Isso é a mesma forma de como o telnet usa a porta 23 ou o http usa a porta 80, por padrão, para aceitar pedidos recebidos. As portas utilizadas pelo IDS não são portas padrão global, mas, em vez disso, é configurado pelo DBA no arquivo sqlhosts.
A forma geral do arquivo sqlhosts é de cinco colunas e se parece com a Tabela abaixo:
Descrição do arquivo SQLHOSTS
Na seção anterior mencionamos que cada instância IDS tem um nome. Esse nome está na primeira coluna do arquivo sqlhosts. A localização da instância está na terceira coluna, a coluna do nome do host. O número da porta onde o IDS está ouvindo os pedidos de SQL recebidos está na quarta coluna.
Na segunda coluna, a coluna NETTYPE, permite que você especifique se deseja usar um protocolo de rede ou um protocolo local para o cliente falar com a instância do IDS. Isso está diretamente relacionado ao local onde o cliente está sendo executado, em oposição a onde a instância IDS está sendo executada.
Se o cliente e o servidor estiverem sendo executados na mesma máquina física, a comunicação pode ocorrer de várias maneiras:
- Shared memory (conhecido como comunicação interprocesso ou ipc)
- Network interfaces (sockets ou TLI)
- Local pipes (nomeado ou não nomeado)
- DRDA (Distributed Relational Database Architecture)
No entanto, se o cliente e o servidor estão rodando em maquinas diferentes, então as rotas de comunicação são reduzidas porque você precisa confiar na rede. Então, neste caso, você só tem as opções de:
- Network interfaces (sockets ou TLI)
- DRDA
A coluna NETTYPE é como o administrador especifica qual rota de comunicação um cliente deve usar quando se conecta a uma instância pelo nome especificado na coluna um.
A quinta coluna, também conhecida como coluna opções, é uma coluna opcional que pode ser usada para configurar várias coisas. O exemplo acima tem o valor k=0. O "k" significa keep-alive e o "0" desliga este recurso quando se conecta ao servidor usando este DBSERVERNAME. O recurso keep-alive pede ao serviço de rede que verifique periodicamente o fim de da conexão para garantir que ainda existe. Se o destino de recepção não responder em tempo hábil, o serviço de rede assume que algo aconteceu, encerra a conexão e libera seus recursos. por padrão, o recurso keep-alive está ativado e geralmente deve ser deixado ligado.
Abaixo outra ilustração de exemplo:
Exemplo do arquivo SLQHOSTS
Com base na primeira linha no exemplo acima, se a variável de ambiente INFORMIXSERVER do cliente estiver definida como HR_prod, onsoctcp informa ao cliente para usar uma implementação sockets do protocolo TCP para se comunicar na rede. O cliente enviaria quaisquer solicitações SQL para a porta 1543 da máquina com o endereço IP 192.168.12.234. O campo hostname pode usar o endereço IP ou o nome do host da máquina, desde que o nome do host possa ser resolvido para um endereço IP com as chamadas do sistema apropriadas. A opção de b=8192 informa ao cliente para usar um buffersize de 8192 bytes ao se comunicar com o servidor. As conexões padrão usam um buffersize de 4096 bytes.
Se a variável de ambiente INFORMIXSERVER do cliente estiver definida como Acct_devel, onipcshm diz ao cliente que o servidor é local e que usa um mecanismo especial conhecido como Conexões de Memória Compartilhada. O mecanismo especial é definido e mantido pelo IDS para conexões locais para poder se conectar à instância usando um recurso global de Unix Shared Memory. O cliente irá então utilizar esta parte da memória compartilhada, escrever seus pedidos SQL e leer os resultados dela. Conforme descrito acima, isso só está disponível quando o aplicativo cliente e a instância IDS estão sendo executados na mesma máquina.
A coluna ServiceName pode usar um número de porta ou um nome de serviço. Se um nome de serviço for usado, esse valor deve ser resolvido para um número de porta válido, conforme especificado no arquivo /etc/services em Unix/Linux/Mac ou system32\ drivers\etc\services no Windows.
Arquivo de configuração
Durante a configuração, o arquivo ONCONFIG geralmente vem de mãos dadas com o arquivo sqlhosts por causa dos campos que precisam corresponder. Como mencionado anteriormente, cada instância tem um nome e esse nome é usado na primeira coluna do arquivo sqlhosts. Como uma instância sabe qual é o nome? Esse é apenas um dos muitos parâmetros que estão configurados no arquivo de configuração IDS.
A instalação IDS vem com um arquivo chamado onconfig.std no subdiretório etc do caminho de instalação. Este arquivo deve ser usado como um modelo para o arquivo de configuração real de uma instância. Copie o arquivo onconfig.std para um arquivo de outro nome, (por exemplo, onconfig.prd). Embora a parte onconfig do nome do arquivo não seja necessária, tornou-se padrão. Uma vez que o arquivo foi nomeado, a variável de ambiente ONCONFIG deve ser definida para apontar para esse nome de arquivo.
Nota: A variável de ambiente ONCONFIG é somente o nome do arquivo, não a localização, porque o arquivo de configuração tem que existir no $INFORMIXDIR/etc (%INFORMIXDIR%/etc no Windows).
Com mais de 180 parâmetros configuráveis e mais de 1100 linhas no total com comentários, o arquivo de configuração pode ser bastante assustador. Mas não se preocupe; as enormes quantidades de comentários, mais uma pequena experiência, trarão tudo em perspectiva. Na verdade, uma das coisas boas a saber é que apenas nove desses 180 parâmetros são necessários para colocar uma instância do IDS em funcionamento. O resto são para performance, extensibilidade, e recurso de suporte.
Então, vamos começar por dar uma olhada nessas nove e, em seguida, talvez um pouco mais, por diversão :-).
A configuração dos nones parâmetros necessários para subir uma instancia incluem:
- ROOTNAME
- ROOTPATH
- ROOTOFFSET
- ROOTSIZE
- MSGPATH
- CONSOLE
- DBSERVERNAME
- DBSERVERALIASES
- SERVERNUM
Do primeiro ao quarto estão ligados a espaço em disco. Não é necessário que todo o espaço em disco que a instância vai utilizar seja configurado no mesmo momento. Mais espaço em disco pode ser adicionado conforme a necessidade; no entanto, No entanto, uma certa quantidade de espaço em disco precisa existir desde o início. Este espaço em disco recebe um nome (ROOTNAME), uma localização (ROOTPATH), uma posição inicial (ROOTOFFSET) e um tamanho (ROOTSIZE). Quando a instância do IDS usando este arquivo de configuração for iniciada pela primeira vez, formatará esse espaço definido e inicializá-lo-á para um aspecto especificado. Por isso, você precisa ter certeza de que nada mais está usando esse mesmo espaço em disco. ROOTPATH pode apontar para um arquivo existente ou um dispositivo raw.
O quinto e sexto parâmetros têm a ver com as mensagens de log. Uma vez que a instância IDS deve ser executado em segundo plano, ele precisa de um local onde pode escrever mensagens de informações, de aviso e de erros. MSGPATH define um caminho e um nome de arquivo do arquivo ao qual você gostaria que as mensagens fossem escritas. CONSOLE pode ser usado para enviar mensagens especiais para uma tela de console se for usada. Por causa da duplicação de mensagens para esses dois lugares, o padrão tornou-se para enviar o CONSOLE para /dev/null.
Agora discutiremos o sétimo e o oitavo parâmetro. Cada instância do IDS tem um nome (DBSERVERNAME), e pode ter mais de um nome se necessário para diferentes tipos de conectividade (DBSERVERALIASES). Pense nisso desta maneira: Você pode ter o nome de nascimento Amilcar, mas você pode ter outros nomes para os quais você também responde (alias), como Ami. Você poderia dizer para as pessoas que não conhecem você, que se chama Amilcar, mas amigos próximos chamam você de Ami. Você responde por ambos os nomes, mas você pode responder de uma maneira diferente, dependendo de qual nome você esta sendo chamado. É semelhante ao IDS: pode ter apenas um nome, mas pode ter muitos alias. O nome e cada um dos alias devem estar listados no arquivo SQLHOSTS em uma linha diferente. Lembre-se que é o arquivo SQLHOSTS que informa ao cliente como se conectar à instância, dependendo do nome ou alias (primeira coluna no arquivo SQLHOSTS) que é usado.
O nono parâmetro é um número inteiro exclusivo entre zero e 255 para cada instância de IDS que está sendo executada na mesma máquina. Sem nos aprofundar muito, este número (SERVERNUM) é usado para ajudar a gerar um valor necessário para a memória compartilhada UNIX. Uma vez que é possível iniciar mais de uma instância de IDS na mesma máquina, o valor especificado pelo SERVERNUM deve ser diferente para cada instância para ajudar o IDS a certificar-se de que ele calcula um número exclusivo para dar ao UNIX.
Alguns outros parâmetros de interesse sem muito detalhe incluem:
- PHYSFILE, ajuda a dimensionar o log físico
- LOGFILES e LOGSIZE, ajuda a configurar o logical logs
- ADMIN_MODE_USERS, especifica os usuários que podem se conectar enquanto a instância estiver em modo administrativo; O usuário informix sempre pode se conectar
- DBCREATE_PERMISSION, especifica um usuário que pode executar instrução SQL CREATE DATABASE
- BUFFERPOOL, configura o tamanho e os parâmetros de ajuste de um bufferpool
Então, mesmo que o arquivo de configuração seja grande, entende-lo por blocos o ajudará a começar a entender. Lembre-se, você não precisa saber tudo para subir uma instância de IDS.
Nota: Com pequenas exceções, o arquivo onconfig é lido apenas no tempo de inicialização; quaisquer alterações feitas diretamente no arquivo onconfig não terão efeito até que a instância seja interrompida e reiniciada. Alguns dos parâmetros onconfig podem ser alterados dinamicamente com o comando onmode (discutido mais adiante neste tutorial).
Reflexos da configuração
Note: Agora que você aprendeu sobre as três partes das configurações das variáveis de ambiente, arquivo sqlhosts e o arquivo onconfig, revisemos a importância de como essas três partes se juntam para que a conectividade do cliente funcione com sucesso.
Vamos demonstrar um exemplo do trecho de cada parte:
Variáveis de ambiente:
INFORMIXSERVER=HR_Prod
Exemplo do arquivo SQLHOSTS:
arquivo onconfig
DBSERVERNAME HR_Prod
DBSERVERALIASES HR_Devel
Observe como todos eles têm o mesmo "Nome" (HR_Prod) neles. O arquivo onconfig informa à instância qual é o nome. O arquivo sqlhosts informa onde encontrar a instância por esse nome. O cliente diz em qual instância ele quer conversar, especificando-o na variável de ambiente.
Então, quando o cliente começa a ser executado, ele leva o valor da variável de ambiente INFORMIXSERVER, procura-se no arquivo sqlhosts, descobre para onde enviar seu pedido SQL e, em seguida, o envia.
Por outro lado, o DBA nomeou a instância no arquivo onconfig e, quando a instância foi iniciada, ele pesquisou no arquivo sqlhosts para descobrir qual servidor (número de porta) deve estar configurada para as solicitações recebidas.
Iniciando
Não podemos terminar este tutorial até entender como completar a configuração e acabar com instancia online.
O que fizemos até agora:
- Planejamento da instalação
- Instalação do produto que você decidiu de acordo com seu planejamento
- Configurou uma instância do produto, configurando o ambiente, o arquivo sqlhosts e o arquivo onconfig
- Certifique-se de que o espaço em disco para o qual ROOTPATH é apontado existe
Agora é hora da conclusão. Essa ultima sessão vai tratar de como inicializar e parar uma instancia IDS.
oninit
Uma vez que uma instância IDS é apenas um conjunto de recursos de SO utilizado por um banco de dados, você precisa de uma maneira para alocar e desalocar esses recursos quando necessário. As ferramentas que você tem para fazer isso são conhecidas como os comandos oninit e onmode. Embora seja válido no Windows também, uma vez que uma instância IDS funciona como um serviço, é melhor iniciar e parar o serviço, ou use o comando para iniciar uma ajuda ao serviço.
Antes de falar sobre como iniciar o software, considere mais uma coisa. Uma instância IDS tem vários estados em que pode estar. A tabela abaixo lista alguns dos diferentes estados e o que eles significam:
Estados IDS
O comando oninit só é válido para iniciar a instância. Pense na instância como um carro. Para ligar um carro, você gira a chave; se o carro estiver em qualquer estado, exceto desligado, girar a chave fará um ruído terrível. Uma instância IDS é a mesma coisa. O comando oninit somente trabalhara se a instancia estiver parada (offline). Se a instância estiver em qualquer outro estado, executar o comando oninit retornara um aviso. Não vai acontecer nada, mas também não funcionará.
O comando oninit vem com as opções listadas e descritas abaixo:
opções oninit
- -i --> inicializa um espaço em disco. Como formatar um disco rígido, ele só deve ser usado a primeira vez que a instância for iniciada.
- -y --> automaticamente responde "Yes"para todas as questões
- -j --> Inicia uma instancia em modo administrativo. Também conhecido como single-user.
- -v --> modo "Verbose". Mostra mensagens adicionais no monitor enquanto inicializa.
- -s --> Inicia uma instancia em modo quiescent mode.
Há mais opções para se utilizar, mas veremos somente essas opções neste tutorial.
onmode
O comando onmode é usado para parar a instância, bem como uma infinidade de outras coisas.
O comando onmode é usado para alterar o estado da instância, para alterar dinamicamente alguns dos parâmetros no arquivo onconfig, adicionar e liberar memória, configurar o scanner B-tree, configurar os recursos HDR e Mach11, forçar um checkpoint, e muito mais.
Este tutorial abrange apenas dois desses tópicos: alteração do estado da instância e alteração dinâmica dos parâmetros do arquivo onconfig.
Ao usar o comando onmode para alterar o estado da instância, ele usa as seguintes opções:
opções onmode
- -m --> Altera a instância do estado do single-user ou quiescent para estado on-line.
- -s ---> Executa um shutdown graceful e altera a instância para o estado quiescent de single-user ou on-line.
- -j ---> Executa um shutdown immediate para usuários non-admin somente, e traz a instância para estado single-user a partir do estado quiescent ou on-line.
- -u ---> Executa um shutdown immediate e altera a instancia para quiescent do estado single-user ou on-line.
- -k ---> Executa um shutdown immediate e altera a instancia para off-line para todos os usuarios.
- -y --> Responde automaticamente as perguntas como "yes"
Como mostrado em itálico acima, o IDS tem duas formas de shutdown: um shutdown graceful e um immediate.
O shutdown graceful não permite novas conexões, mas permite que os usuários conectados continuem até se desconectar. Quando o último usuário se desconectar, a instancia irá mudar para o estado especificado pela opção dada ao comando onmode.
O shutdown immediate para todas as atividades no banco de dados e coloca a instancia imediatamente para o estado especificado pela opção dada ao comando onmode.
A ilustração abaixo mostra os comandos oninit e onmode. Entre cada comando, um onstat - é executado para mostrar o estado da instância. A mensagem "Shared memory not initialized for INFORMIXSERVER 'xxx'" significa que não existe nenhuma instância rodando com esse nome.
onmode -wf / -wm
Como mencionado anteriormente, o comando onmode pode ser usado para outras coisas também, incluindo a alteração dinâmica dos valores de alguns dos parâmetros onconfig. Isto é realizado com os comandos onmode -wf e onmode -wm. A maneira mais fácil de lembrar a diferença é que "f" significa file e "m" significa memory. Portanto, o comando onmode -wf muda a configuração atual na memória e muda o valor no arquivo onconfig. O comando onmode -wm somente altera o valor corrente em memória.
Nota: A partir do IDS 11.50, apenas um subconjunto limitado dos parâmetros onconfig pode ser alterado dinamicamente dessa maneira.
A sintaxe do comando é: onmode -wf <onconfig parameter>=<value> ou onmode -wm <onconfig parameter>=<value>.
Exemplo:
onmode -wf AUTO_CKPTS=0
onmode -wm RESIDENT=1
Se você tentar alterar um valor que não seja compatível com o comando onmode -wf/wm, você verá uma mensagem como essa:
"Configuration Parameter to be changed is not valid or not supported with this option."
