finderr

-271 Could not insert new row into the table.

This problem has many possible causes, including a locked table or a

full disk. Check the accompanying ISAM error code for more

information.

-271 Não foi possível inserir uma linha na tabela. 

Este problema tem muitas causas possíveis, incluindo uma tabela bloqueada ou uma disco cheio. Verifique o código de erro ISAM que acompanha para mais informação.

-346 Could not update a row in the table.

While the database server was processing an UPDATE, it received an

unexpected error. Check the accompanying ISAM error code for more

detailed information on the cause. Possible causes include hardware

errors and locking conflicts.

-346     Não foi possível atualizar uma linha na tabela.

Enquanto o servidor do banco de dados estava processando um UPDATE, recebeu um erro inesperado. Verifique o código de erro ISAM que acompanha para informações detalhadas sobre a causa. Possíveis causas incluem erros de hardware e conflitos de locks.

Informix Dynamic Server 11.50 Fundamentals Exam 555 certification preparation, Part 1 - 2/2:

Instalação

Após o planejamento do IDS, o próximo passo é instalar o produto. O IDS está disponível no Unix/Linux, Windows e Mac OS X. As opções de instalação disponíveis para você dependem do sistema operacional que você possui.

Unix/Linux

A instalação do IDS geralmente é executado em duas partes:

• Extraia o produto da mídia (CD, fita ou download)
• Rodar o script de instalação

Copiar o produto da mídia normalmente é realizado com o comando tar -xf. O produto deve ser descompactado no local do diretório onde o produto será instalado.

Uma vez que o conjunto de produtos IDS abrange mais do que apenas um produto, o processo de instalação pode ser feito de uma só vez ou em etapas ao nível do produto. Ao executar o comando ids_install, o script de instalação instalará o servidor IDS, bem como quaisquer outros produtos relacionados que estejam no mesmo diretório. O comando installserver apenas instala o servidor IDS e ignora outros produtos.

As permissões de root são necessárias para executar o script de instalação.

Uma vez conectado como root, a instalação pode ser realizada de várias formas:

• Modo console (padrão): Este modo utiliza o terminal texto padrão  e solicita as respostas do instalador sobre aceitação de licença, localização de instalação, modo de instalação, separação de função e inicialização do servidor de demonstração. Uma vez que essas perguntas foram respondidas e o resumo foi aprovado, a instalação ocorrerá. A opção de modo de instalação consiste em uma instalação típica ou personalizada. Alguns dos recursos instaláveis personalizados incluem:
• Recursos de extensibilidade
• GLS
• Utilitários de Backup e Restore
• Enterprise replication
• Utilitarios de Data-loading

A inicialização do servidor de demonstração cria, configura e inicializa uma instância de IDS com base em um arquivo de configuração fornecido ou no arquivo de configuração padrão.

Exemplo do comando de instalação:

install_ids

• Modo GUI: Este modo é usado quando a opção -gui é especificada com o comando de instalação. A instalação GUI é exatamente como a instalação do modo console, mas usa uma interface gráfica Java para interação com o instalador. Exemplo do comando de instalação: installserver -gui   
• Modo Silent: Este modo permite a instalação não interativa. O modo silencioso utiliza um arquivo .ini para as informações de resposta que normalmente viriam do teclado ou mouse nos modos console e GUI. IDS vem com dois arquivos .ini padrão que podem ser usados, ou você, o instalador, pode criar o seu próprio .ini. Um arquivo .ini pode ser criado automaticamente durante uma instalação interativa, especificando a opção -record no comando de instalação. Exemplo: installserver -record minharesposta.ini

Para usar o arquivo .ini personalizado, você deve especificar a opção -options no comando de instalação.
Exemplo:
install_ids -silent -options minharesposta.ini

Se qualquer um dos arquivos .ini padrão for usado (bundle.ini ou server.ini), a opção -acceptlicense = yes deve ser especificada no comando de instalação; Caso contrário, a instalação não terá sucesso.
Exemplo:
install_ids -silent -acceptlicense=yes

Algumas das outras opções que também podem ser especificadas durante a instalação incluem:

• -javahome para utilizar um JRE já instalado
• -P installLocation= para determinar um diretório diferente
• -log para especificar um arquivo de log fora do padrão

É possível ter várias versões do IDS instaladas no mesmo sistema ao mesmo tempo. O único requisito é que eles estejam instalados em diretórios diferentes. A variável de ambiente INFORMIXDIR aponta para o diretório do produto que deve ser usado ao iniciar uma instância IDS.

Windows

A instalação do IDS no Windows é feita no modo gráfico ou no modo silencioso. 

Se a mídia de instalação vier de um arquivo de download, você deve extrair os arquivos em uma estrutura de pastas usando a ferramenta apropriada com base no tipo de arquivo. Se a mídia de instalação for um CD, você pode iniciar a instalação diretamente do CD.

Para iniciar a instalação, execute o Launch.exe ou setup.exe.

Launch.exe iniciará o processo de instalação GUI que irá levá-lo através das seguintes etapas:

• Selecionar os produtos para a instalação
• Aceitar as condições de licença 
• Selecionar o modo de instalação (típica ou customizada)
• Configurar a conta do usuario informix e a senha, se não existir
• Selecionar o diretório de instalação
• Concordar com os resumos da instalação

O modo de instalação típico ou personalizado é semelhante ao descrito na seção Unix/Linux acima, exceto que também permite o seguinte:

• Especificar uma conta de usuário diferente de um usuário local 'informix' 
• Habilitar a role separation
• Criar um server demo com ou sem inicialização do instalador
• Início do Assistente de Configuração de Instância
• Iniciando o utilitário ClusterIT

Para instalar no Windows no modo silencioso, o comando setup.exe é usado em um ambiente de linha de comando. Assim como descrito no ambiente Unix/Linux, o modo silencioso usa um arquivo .ini para as informações de resposta durante a instalação. O arquivo server.ini padrão pode ser usado, ou um arquivo personalizado pode ser criado.

Abaixo segue um exemplo do comando de instalação ao usar o arquivo server.ini padrão:

setup.exe -s -f1"C:\IIF\server.ini"

A maneira de usar um arquivo .ini personalizado durante a instalação é mudar o nome do arquivo na opção -f1 como mostrado no exemplo de comando acima.

Para criar um arquivo .ini personalizado a partir das respostas dadas durante uma instalação GUI, primeiro você deve executar o comando setup.exe -r -fl "C:\temp\mysilent.ini" a partir de um prompt de comando antes de iniciar a instalação GUI.

Claro que você pode mudar o caminho e o nome do arquivo para se adequar ao seu ambiente.

Uma vez concluída a instalação, o novo arquivo .ini está pronto para usar para todas as futuras instalações silenciosas com a mesma configuração.

A instalação do Windows cria o arquivo de log em %INFORMIXDIR%\logs\, que mostra toda a atividade de instalação. A localização do arquivo de log pode ser modificado com a opção -f2"" quando utilizado com a instalação silenciosa.

O Windows permite que várias versões do IDS sejam instaladas em um computador com a opção -multiple.

Mac OS X

A instalação no Mac OS X é similar a instalação do Unix/Linux. Possui instalação GUI e os métodos de instalação silencioso (silent). Os privilégios de root são necessários para fazer uma instalação autônoma.

O método GUI é iniciado abrindo o pacote do informix e inserindo a senha do administrador do sistema quando solicitado. A instalação prossegue com instruções para:

• Informações da conta do usuário informix, se não existir
• Aceite da licença
• Diretório de instalação 
• Instalação do produto
• Modo de instalação (tipico e customizado)
• Role Separation
• Criação do servidor de banco de dados Demo
• Tuning automatico do Kernel
• Aprovação de sumario

O modo de instalação personalizado permite selecionar quais recursos estão instalados, conforme descrito na seção de instalação do Unix/Linux.

A instalação silenciosa é feita de forma semelhante à instalação silenciosa no Unix/Linux. No Mac OS X, o arquivo bundle.ini deve ser usado e personalizado para atender às suas necessidades de instalação.

Nota: Antes da instalação, certifique-se de alterar a opção -G licenseaccepted=false para true no arquivo .ini.

Caminho de instalação seguro

Durante a instalação do IDS 11.50, existe uma opção para proteger automaticamente o caminho de instalação. A proteção do caminho de instalação verifica se os diretórios no caminho de instalação possuem proprietários, grupos e permissões seguras configurados apropriadamente para o servidor de banco de dados.

Se você optar por não proteger o caminho na hora da instalação, você pode fazê-lo manualmente a qualquer momento.

Nota: IDS não será inicializado se o caminho de instalação não for seguro.

Para garantir o caminho em uma data posterior, faça o seguinte:

1. Execute $INFORMIXDIR/bin/onsecurity -r $INFORMIXDIR para criar um shell script.
2. Execute $INFORMIXDIR/tmp/secure.sh para alterar as permissões de segurança do path.

Proteger o path através deste processo manual permite que um administrador do sistema veja quais permissões serão atribuídas a qualquer diretório no caminho de instalação e tomarão as ações apropriadas para quaisquer diretórios extras que possam existir no caminho, mas que não faça parte da instalação IDS .

Configuração

Uma vez que o produto está instalado, é hora do próximo passo, que consiste em configurar o sistema operacional, o ambiente em que o IDS é executado e a instância do servidor IDS.

Aqui estão algumas definições que você deve saber antes de começar:

• Instancia IDS - Um conjunto definido de recursos do sistema operacional disponíveis para uso por um ou mais bancos de dados. Às vezes, uma instância também é conhecida como um servidor de banco de dados ou um mecanismo de banco de dados. Este conjunto de recursos consiste em espaço em disco, processos e memória.
• Banco de Dados Relacional - Uma coleção de dados organizados em tabelas para pesquisas rápidas, recuperação e armazenamento.

OS

Como a configuração do sistema operacional geralmente é uma função de administrador do sistema (SA), você pode precisar da ajuda do SA para completar esta tarefa.

O IDS é fornecido com um arquivo chamado "machine notes". Este arquivo existe no mesmo local que as "Release Notes" foram descritas na seção "Release Notes". O arquivo  "machine notes" consiste em recomendações para os parâmetros de configuração do kernel do sistema operacional apropriados para o tipo de máquina em que o IDS está instalado. Os parâmetros de configuração dependem diretamente do fabricante do sistema operacional.

No Unix/Linux, os parâmetros mais importantes do Kernel são a Shared Memory, semáforos, files, e usuários. I/O especial também podem ser configurados no Kernel.

A Listagem abaixo mostra um exemplo de "Machine Notes" para um sistema operacional HP-UX:

Machine Notes para Sistema Operacional HP-UX

Nota: Os valores indicados no "Machine Notes" são apenas valores recomendados com base no teste do produto. Se os valores diferirem muito dos valores já configurados no seu kernel, certifique-se com o administrador do sistema sobre como as mudanças desses valores podem afetar o sistema.

No Windows, o parâmetro de configuração mais importante é para memória. A capacidade de acessar mais do que a quantidade padrão de espaço de endereço de memória deve ser ativada no arquivo boot.ini. Ao alterar esse valor,  você pode aumentar isso de 2GB para aproximadamente 3GB. Embora não seja um parâmetro ajustável, é importante observar que todos os dados de uma instância IDS do Windows devem ser armazenados em partições NTFS, unidades físicas ou partições de disco lógico.

Ambiente

IDS depende muito do ambiente em que é iniciado. Por isso, as variáveis de ambiente que configuram esse ambiente são muito importantes para entender e definir corretamente. Existem cinco variáveis de ambiente principais para a instância IDS:

• INFORMIXDIR - O caminho completo para a localização do diretório do produto instalado.
• INFORMIXSERVER - O nome da instancia que será iniciada.
• PATH (opcional) - Deve incluir $INFORMIXDIR/bin por conveniência.
• ONCONFIG - (opcional) - Nome do arquivo de configuração "importante".
• INFORMIXSQLHOSTS - Aponta para o arquivo de informações de conectividade.

Como você pode notar, apenas duas das cinco variáveis de ambiente são necessárias; os outros três são opcionais. Este tutorial descreve por que isso é verdadeiro com mais detalhes.

A localização e o comando para definir a variável de ambiente dependem diretamente do SO que está sendo usado.

Um exemplo utilizando Unix e Korn Shell:

export INFORMIXDIR=/usr/informix

Como o Windows tem vários locais onde as variáveis de ambiente podem ser definidas, as seguintes regras de precedência se aplicam:

• Configurar a aplicação Setnet32
• Configurar em linha de comando antes de rodar á aplicação 
• Configurar no Windows como variáveis de usuarios
• Configurar no Windows como variáveis de ambiente
• Valor padrão 

A variável de ambiente INFORMIXDIR aponta para o local onde o produto está instalado. Isso é importante porque este caminho é precedido por alguns dos valores que são usados dentro do executável IDS. Sem este conjunto, o IDS não saberia onde procurar determinados arquivos que são necessários para serem executados com sucesso.

A variável de ambiente INFORMIXSERVER corresponde ao nome da instância IDS em que o ambiente será apontado por padrão. Essa variável de ambiente é importante para cada conexão de cliente que tenta acessar a instância IDS, seja esse cliente interno ou externo. Um cliente interno seria um utilitário que acompanha o software IDS. Um cliente externo seria qualquer aplicativo que use o SQL para conversar com o banco de dados. "Como você nomeia a instância IDS?" você pergunta. Isso é discutido um pouco mais tarde na seção "Arquivo de configuração".

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."

Informix Dynamic Server 11.50 Fundamentals Exam 555 certification preparation, Part 1 - 1/2:

Planejamento e instalação do IDS

Este tutorial é o primeiro de uma série de tutoriais projetados para ajuda-lo a se familiarizar com todos os diferentes aspectos do IBM Informix Dynamic Server (IDS) e ajuda-lo a se preparar para o exame de certificação do IDS Fundamentals. Este primeiro tutorial cobre o planejamento e a instalação do IDS, sendo um ótimo lugar para começar a entender e usar o IDS com sucesso.

Antes que você comece

Este tutorial ensina sobre o planejamento de uma instalação IDS. Este planejamento consiste em questões chaves que precisam ser respondidas, bem como obter informações sobre o produto, suas capacidades em sua maquina, e qualquer configuração previa que possa ser necessária.

Depois de planejar a instalação vem a instalação real. Este tutorial fala sobre as diferentes opções  de instalações disponíveis em cada sistema operacional e continua após a instalação na configuração de sua primeira instancia IDS, bem como iniciar e parar essa instancia uma vez que ela esta configurada.

Com este conhecimento você deve ser capaz de planejar, instalar e iniciar uma instancia do Informix Dynamic Server que você pode utilizar com o resto desta serie de tutoriais. Você também deve estar preparado para responder aos tipos de perguntas feitas na seção 1 do exame de certificação.

Sobre esta série

Esta série complementar de nove tutoriais foi desenvolvido para ajuda-lo a se preparar para o exame de certificação IBM Informix Dynamic Server Fundamentals. Este exame de certificação irá testar seu conhecimento de administração de nível de entrada do IDS, incluindo o básico de SQL (Structured Quero Language - Linguagem de consulta estruturada), como instalar o IDS, como criar bancos de dados e objetos de banco de dados, segurança, transação, backup e procedimento de recuperação e tecnologias de replicação de dados e propósitos. Esses tutoriais fornecem uma base sólida para cada seção do exame. No entanto, você não deve confiar nesses tutoriais com sua única fonte de preparação para o exame.

Objetivos

Quando você terminar este tutorial, você deve poder:

• Explicar as diferenças entre as edições IDS;
• Descrever diferentes aplicações de Banco de Dados;
• Descrever a configurações e os controles de usuários, incluindo a separação de funções;
• Compreender os tipos de dados disponíveis no IDS, incluindo o tipo incorporado e extensível;
• Explicar e executar os diferentes métodos de instalação disponíveis na sua plataforma;
• Explicar e executar as etapas para configurar uma instância IDS;
• Explicar os diferentes estados de uma instancia IDS;
• Executar comandos para alterar os estados de uma instancia IDS;

Pré-requisitos

Estes tutoriais são escritos para futuros administradores de banco de dados (DBAs). Embora algum conhecimento básico do conceito de banco de dados possa ajudar, não é necessariamente necessário.

Requisitos de sistemas

Para completar este tutorial, você não precisara de uma copia do IDS. Entretanto, se você tiver uma disponível, você definitivamente obterá mais informações sobre os tutoriais. Se você não tem uma copia, você poderá obter a versão free no site da IBM.

Planejamento

Primeiro foram meus pais, depois meu conselheiro da escola secundaria, meus professores da faculdade, meu treinador de negócios e a lista continua; mas todos eles me disseram essencialmente o mesmo: para ser bem sucedido, você precisa ter um plano. Quando se trata de implantação de banco de dados bem sucedida, o mesmo é verdade - você precisa planejar. Embora você possa não ter tempo para criar um plano, lembre-se de que ele pode salvar você muito mais tarde.

Então, esta primeira parte deste tutorial abrange a idéia de planejamento. Durante o planejamento, algumas das perguntas que você precisa perguntar incluem:

• Quais recursos eu preciso do Banco de Dados? 
• Quais tipos de aplicativos estou esperando conectar ao Banco de Dados?
• Quantos usuários existem, e de onde esses usuários se conectam?
• Que tipo de dados e qual a volumetria desses dados vou armazenar?
• Qual é o tempo de resposta esperado da minha aplicação?
• Vou utilizar o hardware existe ou um novo?
• Uma unica pessoa vai manter esse banco de dados, ou vou dividir papéis com uma equipe?

As perguntas podem continuar, mas vamos parar por agora. A intenção desta seção não é aprofundar nessas questões, mas fazer você pensar sobre elas e discutir alguns pontos de alto nível sobre alguns deles.

Edições IDS

O Informix Dynamic Server vem em quatro edições diferentes:

• Developer
• Express
• Workgroup
• Enterprise

O Developer Edition do IDS é um produto gratuito destinado apenas para desenvolvimento e teste de aplicações. Ele contém a maior parte da funcionalidade do Workgroup Edition, mas não possui capacidades de suporte técnico da IBM. Ele também possui limites de escalabilidade para processadores, memória e armazenamento.

A edição do Express destina-se a pequenas e médias empresas e está limitada a funcionar em sistemas operacionais Linux e Windows. Ele também contém a maior parte da funcionalidade da versão do Workgroup Edition com limitações de escalabilidade.

A versão Workgroup Edition é destinada as empresas de medio porte ou servidores departamentais de uma empresa. Está disponível para varias versões do UNIX/Linux, bem como para Windows e MAC OS X. Workgroup Edition adiciona funcionalidades adicionais, como o Enterprise Replication (ER) com algumas limitações e High-Availability Data Replication (HDR). Workgroup Edition também tem limites na escalabilidade.

A versão Enterprise Edition contém todas as funcionalidades do Workgroup Edition com escalabilidade ilimitada. Enterprise inclui todas as funcionalidades do HDR e ER, bem como funcionalidades adicionais para os recursos de disponibilidade continuo, otimização de armazenamento, LBAC entre outros.

Um das primeiras partes de um planejamento de banco de dados é decidir qual edição do IDS é necessária para suportar os requisitos de seu negócio.

Tipos de aplicação

As aplicações que se conectam a um Banco de Dados geralmente são dividas em duas categorias:

• Online Transaction Processing (Processamento de transações Online), melhor conhecida como OLTP
• Decision Support System (Sistema de Apoio à Decisão), melhor conhecido como DSS, mas as vezes chamado de Data Warehousing

"Então qual a diferença?" você se pergunta. vamos ver alguns exemplos.

OLTP

OLTP - O processamento é como um aplicativo de Call Center. Quando você liga para sua operadora de cartão de crédito ( ou um Help Desk de qualquer tipo), o atendente na linha geralmente pede-lhe algo que é exclusivo da sua conta, como o numero da conta. Esse número de conta é utilizado para pesquisar no banco de dados para obter alguns registros associados apenas a você. Poderia ser apenas um registro - talvez a informação da sua conta; ou pode ser uma dúzia, como as informações de sua conta mais as últimas 15 transações de sua conta. De qualquer forma, ele é projetado para ser uma busca rápida que traz de volta os dados em questão de alguns segundos ou menos. Embora possa trazer de volta uma dúzia de linhas com dados de várias tabelas, as linhas que retornam são apenas uma fração de uma fração do numero de linhas que são mantidas no banco de dados.  As 20 linhas que o aplicativo pode ter retornado não são, portando, nada comparadas aos 200 milhões de registros na tabela. Isso não é para fazer se sentir pequeno no grande esquema de coisas; estou apenas tentando apontar um par de elementos chaves para um sistema do tipo OLTP. Isto:

• Retorno de algumas linhas de uma consulta
• Ter um tempo de resposta muito rápido - geralmente alguns segundos ou menos
• Utilização de indices únicos para obter um conjunto de registros
• Um ambiente de tipo leitura e escrita
• permitir conexões de muitos usuários

Systema OLTP foi projetado para serem sistemas de leitura e gravação. Aplicativos de usuários, como  o help desk do cartão de credito, não selecionara somente dados do banco de dados, mas também frequentemente atualizara (update) e inserirá (insert) novos dados.

DSS ou data warehousing

Consultas tipo DSS, por falta de um melhor termo, são consultas de tipo de relatórios. São consultas mais pesadas, mais longas. Tomando o exemplo da empresa de cartão de crédito acima, o CEO da empresa quer:

• Descobrir a quantidade de  transações de cartão de crédito ocorreram no último mês
• Ter um relatório de todos os clientes que estão inadimplentes em suas contas

Observe que essas consultas não estão associadas a um determinado cliente. A primeira consulta pode usar apenas uma tabela para obter seus dados (ou pode usar varias), mas é necessário fazer uma pesquisa muito maior ao longo de um período de dados para obter seus resultados durante o mês, e depois agrega os dados para obter o resultado final. A segunda consulta é semelhante a primeira, porem traz muito mais dados.

Muitas pessoas pensam em consultas de tipo DSS como consultas que retornam um livro de dados. No entanto, isso não é verdade. Dos exemplos, a primeira consulta é uma consulta DSS, mas retorna somente uma linha, um valor, de fato da conta. A segunda consulta pode retornar muitos dados, dependendo da quantidade de pessoas inadimplentes daquela conta.

Os elementos chaves associados com uma consulta DSS são:

• Consultas longas; pode ser minutos ou horas
• Utilização de mais recursos
• Quantidade maiores de linhas retornadas que correspondem aos critérios da consulta
• Maior agregação dos dados (sum, min, max, count, e assim por diante)
• Utilização de seqüencial scan nas tabelas, uma vez que grandes conjuntos de dados estão envolvidos.

Os ambientes DSS são ambientes de somente leitura. Embora que os dados tenham que ser inseridos no sistema de alguma forma, geralmente são cargas com grandes quantidade de INSERT, uma vez, se o sistema não for atualizado ou atualizado com pouca frequência.

Portanto, não categorize uma consulta pela quantidade de dados retornado, mas sim pelos elementos chaves da própria consulta.

O modelo de dados que é utilizado durante o projeto do banco de dados também é muito importante. O IDS pode tirar proveito de três modelos de dados:

• Modelo de dados relacionais - Modelo típico OLTP
• Modelo de dados objeto relacional - Adiciona ao modelo de dados relacionais as opções de extensibilidade do IDS (tipo de dados estendido, rotinas definidas pelo usuário, tipos definidos pelo usuário, agregados definidos pelo usuário e assim por diante)
• Modelo de dados dimensional - Modelo típico DSS, suporte ao processamento analítico online (OLAP)

Embora nos ambientes de hoje, um único banco de dados não é necessariamente um ambiente OLTP ou DSS, é sempre uma boa ideia tentar descobrir qual será o tipo de aplicação principal para o seu banco de dados, e siga um caminho de design que corresponda a esse tipo.

Para acomodar o fato de que muitos bancos de dados tem ambos os tipos de aplicativos conectados a eles ao mesmo tempo, o IDS possui parâmetros configuráveis para ajudar o desempenho das consultas OLTP e DSS em execução no mesmo banco de dados.

Users

Outra parte do planejamento é cuidar dos requisitos do usuário.

As questões básicas a serem feitas são:

• Preciso de usuários ou grupos especiais para o software?
• De onde conectara os usuarios?
• Quantos usuários espero se conectar simultaneamente?

A importância de responder a estas três perguntas não é apenas boa para o planejamento do banco de dados, mas também para o planejamento dos requisitos de hardware.

O IDS no Unix/Linux requer uma conta de usuário "informix", bem como um grupo "informix" criado na máquina de instalação. O Windows reduz esse requisito e permite um usuário "informix"ou o usuário de um sistema local e um "Informix-Admin". Durante a instalação no Windows, você pode escolher qual conta de usuário você deseja usar.

Por padrão, o usuário "informix" é considerado o "superusuário" do IDS. Tem acesso a tudo e pode fazer tudo o que precisa ser feito no IDS.

O IDS utiliza autenticação externa de usuário, o que significa que ele não possui usuários configurados internamente no software, mas depende de outros recursos para ajuda-lo a autenticar um usuário. Estes recursos externos podem ser o mecanismo de autenticação do Sistema Operacional (SO) da maquina onde o IDS esta sendo executado, LDAP, MS Active Directory ou o Pluggable Authentication Module (PAM).

Nota: Independentemente a forma que você escolheu para a autenticação, a coisa importante é lembrar que TODOS os usuários que precisam acessar o banco de dados precisam ter uma conta e senha com um mecanismo de autenticação externo para que o banco de dados possa autenticação-los e permitir-lhes acessar os dados. Isso pode levar há um planejamento importante, independente se você tiver duas contas de usuários conectando ou 2000 contas de usuários conectados.

Como mencionado anteriormente, por padrão, o usuário "informix" é o "superusuário" da instalação do IDS. No entanto, certas especificações exigem que o poder administrativo seja dividido em vários usuários, com cada usuário tendo um subconjunto da administração total. Isso é conhecido como role separation (separação de função) e esta dividido em duas categorias:

• Tarefas administrativas para pessoas que executam a instancia
• Tarefas de auditoria para pessoas que auditam o que está acontecendo na instancia

Role separation deve ser ativada durante a instalação do software, definindo a variável de ambiente INF_ROLE_SEP antes de iniciar o processo de instalação, ou ativar durante o processo de instalação interativa. Role separation só pode ser desativado desinstalando ou reinstalando o IDS. Role separation utiliza contas de usuários do Windows e contas de grupos no Unix/Linux. Se o Role separation foi ativada, o processo de instalação pedirá as informações necessárias para essas contas de usuários e grupos.

Os três usuários que participam da Role separation são:

• Database System Administrator (DBSA) - Controla as operações gerais da instancia
• Database System Security Office (DBSSO) - determina o que será auditado
• Audit Analysis Officer (AAO) - monitora a auditoria

Outros usuários que não fazem parte da separação de funções, mas podem precisar de algum planejamento:

• Database Administrator (DBA) - gerencia os banco de dados da instancia
• Operating-System Administrator (OSA) - satisfaz os requisitos do Sistema Operacional
• System Users - qualquer usuário que precise acessar os dados

Tipos de dados

Parte do planejamento do banco de dados esta relacionado com os tipos de dados disponíveis. A maneira mais fácil de descrever como os dados são armazenados em um banco de dados é usando uma analogia de planilha eletrônica. Até agora, você esperava ter usado ou visto algum tipo de planilha ( como por exemplo, Microsoft Excel ). Quando você olha a planilha, ela é organizada em linhas e colunas de células. Quando você olha para uma coluna da célula (dados verticais), geralmente todos os dados da mesma coluna são semelhantes - uma coluna de datas ou uma coluna de valores de dinheiro - com um cabeçalho de coluna que descreve o que os dados significam.

Quando você olha para uma linha da célula (dados horizontais), todos os dados nas células em conjunto descrevem uma instancia especifica do que a planilha esta representando. No exemplo abaixo, esta planilha descreve os clientes da XYZ Shoe Store. Cada linha descreve informações sobre um cliente especifico, onde cada coluna descreve um conceito que esta sendo mantido sobre todos os clientes. Então, para cada cliente, você esta armazenando seu nome, idade, tamanho do sapato, a última compra de sapatos e quando ele comprou.

Exemplos de dados

Os bancos de dados não mantem dados em planilha, mas em tabelas. Tabelas, como planilhas, são construídas por linhas e colunas. Durante a definição da tabela, você especifica quais colunas de dados estão sendo mantidas e que tipo de dados cada coluna usa. Um tipo de dados definido restringe o tipo de dados que a coluna pode armazenar. Se você define uma coluna como INTEGER, então essa coluna não poderá conter letras; é obrigado a apenas conter números inteiros. As linhas da tabela são adicionadas à medida que os aplicativos começam a armazenar dados nas colunas da tabela. Os dados são armazenados uma linha por vez. No exemplo acima tem cinco colunas - a primeira coluna, Name,   definido como caracter/string; a coluna Age definido como integre; a coluna Shoesize definido como decimal; a coluna LastTransDate definido como date; e a coluna LastTransAmt definido como money.

Agora que você ja possui uma ideia de como os tipos de dados são utilizados, vamos dar uma olhada nos tipos de dados que estão disponíveis no IDS.

Tipo de dados disponíveis 

• Tipos de dados incorporados
• BIGINT - Números inteiros de -(2⁶³ -1) até 2⁶³ -1
• BIGSERIAL - Números inteiros de -(2⁶³ -1) até 2⁶³ -1, automaticamente incrementado pelo server; as vezes utilizado como uma chave primaria de substituição 
• BLOB - Binary Large Object de até 4 TB de tamanho, armazenando objetos em seu formato nativo
• BOOLEAN - valores 'T' ou 'F'; pode ser testado em expressões
• BYTE - versão antiga do BLOB com 2³¹ byte, teoricamente limitado porem na pratica o limit é determinado pela capacidade de seu disco
• CHAR(n) - armazena 'n' caracteres de dados; se o valor é maior que n, preenche em branco até o tamanho 'n'
• CHARACTERVARYING(m,r) - compatível com ANSI VARCHAR
• CLOB - Character Large Object de até 4TB de tamanho; armazena dados de caracter
• DATE - data do calendario; o formato padrão é MM/DD/YYYY; pode ser modificado com a variável de ambiente DBDATE; especifica um ponto no tempo.
• DATETIME - data do calendario e tempo; formato padrão YYYY-MM-DD HH:MM:SS.FFF; pode ser modificado com a variável de ambiente DBTIME; especifica um ponto no tempo.
• DECIMAL(p,s) - valores decimais, onde 'p' é um numero total de dígitos e 's' é o numero de dígitos à direita do ponto decimal
• NUMERIC(p,s) - como o DECIMAL
• DOUBLE PRECISION - como o FLOAT
• FLOAT - números de ponto flutuante de dupla precisão com até 17 dígitos significativos
• IDSSECURITYLABEL - um VARCHAR(128) utilizado somente com Label Based Access Control (LBAC)
• INTEGER - números inteiros de -(2³¹ -1) até 2³¹ -1
• INT8 - números inteiros de -(2⁶³ -1) até 2⁶³ -1
• INTERVAL - mesmo formato do DATETIME, porem especifica um período de tempo
• LVARCHAR(m) - comprimento de caracter longo com 'm' sendo o tamanho máximo; use apenas o espaço necessário para armazenar dados até o tamanho 'm', tamanho máximo de 2GB quando usado com UDT, senão o máximo de 32K
• MONEY(p,s) - assim como o valor DECIMAL, exceto formatado com caracteres de dinheiro, o padrão é $ e . , mas pode ser alterado com a variável de ambiente DBMONEY
• NCHAR(n) - armazena dados de caracteres de comprimento fixo, mas inclui o uso do Global Language Support (GLS) para armazenar conjuntos de caracteres de um único byte e de vários bytes suportados pelo LOCALE do banco de dados; também permite o uso de sequencias de agrupamento local.
• NVARCHAR(m,r) - como o VARCHAR, porem com características especiais como o NCHAR
• REAL - como o SMALLFLOAT
• SMALLFLOAT - números de ponto flutuante de precisão única com aproximadamente nove dígitos significativos
• SERIAL - números inteiros -(2³¹ -1) até 2³¹ -1, incrementado automaticamente pelo server
• SERIAL8 - como o SERIAL com um range de -(2⁶³ -1) até 2⁶³ -1
• SMALLINT - números inteiros de -32767 até 32767
• TEXT - versão antiga do CLOB com um numero máximo de 2GB
• VARCHAR(m,r) - campo de comprimento de caracter variável com 'm' como o tamanho máximo (até 255) e 'r' como o menor espaço reservado; se o valor que esta sendo armazenado for menor que 'r', o valor será preenchido com espaço até o tamanho 'r'; se o valor for maior que 'r' e menor que 'm, então ele usara apenas o espaço necessário para armazenar o valor
• Tipo de dados estendido
• Tipo de dados complexo
• Linhas
• Coleção
• Tipos de dados definido pelo usuário
• Tipos distintos 
• Tipos opacos

Os tipos de dados de compilação são considerados atômicos, o que significa que eles não podem ser divididos em pedaços pequenos. Cada tipo de dados incorporado tem suas próprias características que o tornam único.

A listagem 1 fornece um exemplo de como utilizar a compilação de  tipo interno ao criar a tabela de cliente (dados da tabela 1):

Listagem 1. Utilizando o tipo de compilação

CREATE TABLE customer 

(

   Name CHAR(55),

   Age INTEGER,

   Shoesize DECIMAL(3,1)

   LastTransDate DATE,

   LastTransAmt MONEY(5,2)

);

Tipos de dados extendidos

Uma vez que os tipos de dados incorporados não podem abranger todos os tipos possíveis que os usuários desejam armazenar, IDS tem a capacidade de ampliá-los combinando os conjuntos integrados ou adicionando novos tipos de dados definidos pelo usuário. A categoria de tipo de dados complexo é composta por dois tipos de dados conhecidos como row e collection.

A melhor maneira de descrever um tipo de dados ROW é que ela imita uma linha em uma tabela, mas você coloca toda essa linha em uma única coluna. Portanto, é um tipo de dados de várias partes composto pelos tipos de dados incorporados. Não é mais atômico. Os tipos de dados ROW podem ser nomeados ou renomeados.

Exemplo:

Usando a XYZ Shoe Store do exemplo acima, talvez você queira armazenar o nome completo do cliente - primeiro, meio e último. Em vez de criar três colunas diferentes - uma para cada parte - você pode criar uma única coluna que tenha três partes.

O tipo de dados COLLECTION é, na verdade, uma categoria de três tipos de dados subjacentes chamados de set, multiset e list. O tipo de dados COLLECTION permite que grupos de dados, todos do mesmo tipo de dados, sejam armazenados juntos em uma única coluna.

Exemplo:

Usando a XYZ Shoe Store do exemplo acima, talvez você queira armazenar as marcas favoritas de sapatos dos clientes. Você não quer criar várias colunas porque você não sabe qual é a quantidade de colunas que você precisa. Algumas pessoas têm apenas uma marca favorita; outras pessoas tem cinco marcas favoritas quando se trata de sapatos. Um vez que todos as marcas são apenas cadeias de caracteres, eles são todos os mesmo tipo de dados. Então, você pode criar uma coluna chamada FavBrands de tipo SET que armazena dados de sequencia de caracteres. Agora uma única coluna pode armazenar tantas marcas favoritas dos clientes. Com SQL, você pode entrar e selecionar todos os clientes cujos FavBrands incluem a Nike, independentemente da quantidade de marcas favoritas listadas. Você selecionaria um tipo SET, já que o SET não permite COLLECTION duplicados. Não faz sentido ter um valor 'Nike', 'Keds', 'Nike'. Ambas as listas MULTI-SET permitem duplicadas. COLLECTIONS não permitem elementos nulos, então, ao definir uma COLLECTION, a restrição NOT NULL de deve ser especificada.

A listagem 2 fornece um exemplo para criar a tabela CUSTOMER usando as idéias de ROW e COLLECTION acima:

CREATE TABLE customer

(

   Name ROW( fname CHAR(15),  mi CHAR(1),  lname CHAR(35)),

   Age INTEGER,

   Shoesize DECIMAL(3,1),

   LastTransDate DATE,

   LastTransAmt MONEY(5,2)

   FavBrands SET(CHAR(10) NOT NULL)

);

Depois de fazer as mudanças, meus dados da tabela pareceriam algo como:

Tipo User-Defined

Embora os tipos incorporados e os tipos complexos possam cobrir muitos dos dados que um usuário deseja armazenar, é possível que novos tipos de dados sejam necessários. Novas aplicações e tecnologias trazem novas coisas que podem precisar de novos tipos de dados. Então, ao invés do IDS decidir quando é bom adicionar um novo tipo de dados, o IDS permite você adicionar novos tipos de dados sempre que necessário. Esses tipos de dados são conhecidos como tipos User-Defined ou UDTs. Você projeta isso, você diz ao IDS como interagir com ele, e você possui ótimas funcionalidades novas.

Se tudo na vida fosse tão fácil, incluindo isso, então todos poderiam estar fazendo isso. Na verdade, não é necessariamente difícil; Há várias coisas que você precisa fazer para que tudo funcione. Mais disso surgirá, pois este tutorial continuara a discutir UDTs e funções de suporte para UDTs. Então vamos voltar para UDTs....

Como visto na lista de tipos de dados disponíveis acima, o primeiro tipo de UDTs que você possui é chamado de um tipo DISTINCT. Simplificando, um tipo DISTINCT é apenas a renomeação do tipo de dados incorporado. Isso herda as características básicas do tipo incorporado, mas não as funções de suporte.

Exemplo: CREATE distinct type Shoesize AS DECIMAL(3,1):

Como Shoesize está sendo definido como um decimal, assumirá as características de armazenamento do tipo decimal. No entanto, nem tudo que você pode fazer com um valor decimal faz sentido fazer com um valor de Shoesize. Um exemplo seria a adição. Não faz sentido adicionar dois tamanhos de sapatos para outro tamanho de sapato. A função de adição (+) é considerada uma função de suporte em IDS. Como o IDS não sabe se as funções de suporte terão sentido para o tipo DISTINCT recém-definido, ele simplesmente desabilita automaticamente todas as funções de suporte no tipo DISTINCT.  Por isso, você também não pode comparar um valor de tamanho de sapato com um valor decimal. Comparar o valor também é considerado parte da funcionalidade de suporte. Embora o tamanho do shoesize seja definido como um decimal, eles são considerados dois tipos diferentes (DISTINCT) que não podem ser comparados. Se você quiser comparar um valor decimal com um valor de shoesize, você deve primeiro fazer um Cast em um deles para se tornar o mesmo tipo do outro, e então a comparação pode ser feita.

Então, você se pergunta: "Se nenhuma função de suporte é suportada neste novo tipo de dados 'DISTINCT', qual a vantagem que isso me traz?". Bem, você pode ter algo especial que você pode fazer com Shoesizes, como dizer se um é maior do que outro. Este é um mal exemplo, uma vez que o tamanho do sapato segue um valor incremental normal, tal como valores decimais. No entanto, diga como você fez para incorporar os valores XS, S, M, L, XL e XXL também. Você teria que mudar SHOESIZE de um decimal para um tipo caracter. Mas agora, se você quisesse ver se o tamanho do sapato de um cliente aumentou ou diminuiu desde a sua ultima compra, você poderia confiar mais no pedido normal (alfabeticamente neste caso). Se você tentou confiar nos pedidos em ordem alfabética, então o gráfico de tamanho de sapatos seria L, M, S, XL, XS, XXL. Mas esse não é o caso porque você sabe que XS é o menor da lista de tamanho de sapatos. Uma vez que você não pode confiar nas funções incorporadas do IDS para ajudar com isso, você precisa de uma alternativa. A alternativa do IDS é permitir a escrita de rotinas externas que podem ser chamadas em SQL normal.
Assim, você poderia escrever uma rotina para fazer a comparação de tamanho de sapatos para você. Essas novas rotinas são conhecidas como User-Defined Routines (UDRs). Este tutorial abrange UDRs um pouco mais tarde.

O outro tipo de UDT é conhecimento como um tipo de dados OPAQUE. Assim como o nome descreve, um tipo OPAQUE é um novo tipo que o IDS não entende nada. Não só o tipo de dados deve ser descrito como IDS, algo como uma estrutura em C, mas você também precisa dizer ao IDS como estrutura deve ficar no disco, como converte-lo entre o formato do disco e o formato de exibição, como indexa-lo, e todas as funções de suporte que você deseja usar para isso. As pessoas sempre perguntam, "Se eu tiver que fazer tanto trabalho, porque eu deveria usar o IDS enquanto que eu posso escrever minha própria aplicação?" Embora os tipos de dados OPAQUE possam ter muito trabalho para configurar, eles tem uma recompensa, você automaticamente tem acesso a todas as demais funcionalidades do banco de dados. Depois de definir as funções de suporte, IDS pode utilizar  esse tipo em qualquer lugar em instruções SQL normal, Fazendo com que pareça como qualquer  tipo de função interna. Então agora você tem integridade de transação, backup e restore, armazenamento, funcionalidade de usuários, integração com outros tipos de dados, e tudo mais que já é incorporado no Sistema de Gerenciamento de Banco de Dados (SGBD).

Um excelente exemplo de usar os tipos OPAQUE é o GeoSpatial Datablade que define um tipo de dados Geopoint, que armazena coordenadas geográficas em quatro dimensões. A função de suporte em torno dessa solução é analisar a distância, proximidade, interseção, e outras funções baseadas em pontos geográficos. Essas funções podem ser incluídas dentro de instruções SQL normais para que os dados de caracteres, dados de pontos geográficos, e qualquer outro tipos de dados por sair no mesmo conjunto de resultados.

Rotinas definidas pelo usuário

As funções de suporte para qualquer UDT podem ser escritas em C, Java, ou Store Procedure Language (SPL). De fato, ele não para com UDTs. Um DBA pode criar uma UDR pra suportar tipos de dados internos.

Exemplo:

A função de agregação (rotina) média (AVG) para tipos de dados numéricos incorporados, ignora completamente os valores NULL quando ele faz cálculos.  Então, talvez você analise que precise de uma rotina AVG que possa ler valores NULL e converte-los em zeros e inclui-los no cálculo. Você pode escrever uma UDR que sobreponha a função AVG interna e utilizar sua nova rotina para tipos de dados internos, UDTs ou ambos.

Observer no exemplo, que os termos funções e rotinas são sinônimos. Isso ocorre porque o termo rotina é apenas uma categoria que engloba dois elementos reais: FUNCTIONS e PROCEDURES. Então, quando você cria uma rotina, você realmente usa as instruções CREATE FUNCTION ou CREATE PROCEDURE.

Por que os dois, você se pergunta. Por definições de padrões ANSI, uma função pode levar e retornar valores, onde uma PROCEDURE pode levar valores, mas não deve retornar nada. Um exemplo de uma FUNCTION seria a FUNCTION SUM - você passa 2 mais 2, e isso retorna 4. Um exemplo de uma PROCEDURE seria um UPDATE no salário de uma pessoa - você passa o novo salário, mas não precisa devolver nada ao usuário. A partir da versão 11.50, O IDS não é completamente compatível com ANSI, pois ainda exibe valores de retorno das PROCEDURES. Isso é feito para compatibilidade com versões anteriores. Certifique-se de manter os padrões ANSI em mente ao escrever quaisquer rotinas futuras.

Datablades

Antes de encerrar o tópico de extensibilidade de UDTs e UDRs, Vejamos um conceito mais conhecido como datablade. Como discutimos o que são UDTs e UDRs, O conceito Datablade deve ser fácil. Um Datablade é o empacotamento de UDTs e UDRs por uma razão específica. A razão é geralmente porque eles têm algo comum, como uma dada funcionalidade. Um exemplo seria o Geodetic Datablade. Dentro do Geodetic Datablade são todos os UDTs e UDRs necessários para fazer armazenamento geoespacial, recuperação, indexação e todos os tipos de análise. 

Notas

Vamos fingir por um segundo que você precisa de uma nova impressora para seu computador. Você se dirige para a loja de periféricos de computador, escolhe uma impressora que quiser e leva-o para casa com você. Quando chegar em casa, você sobre a caixa, e a primeira coisa que você faz é retirar o Manual do Usuário, lê a capa do manual e, em seguida, desembala o resto. Certo? Se você é como os outros 99% de nós, você pode retirar o manual, mas você o deixa de lado porque está muito animado com a sua impressora conectada. Bem, os fabricantes de periféricos descobriram isso e, para ajudar, eles colocaram algo mais no topo da caixa - uma coisa que eles chamam de "Leia-me primeiro" papel com 10 ou 20 passos fáceis para deixar a impressora funcionando.

IDS incorporou a mesma idéia em duas partes. O primeiro é um arquivo README.html que está no diretório principal quando você extrai o software da mídia de instalação. O arquivo README possui instruções de instalações básicas, bem como links para vários outros arquivos de documentação conhecidos como "release notes". (Este tutorial discute mais sobre a instalação na seção "instalação".). O release notes descreve novos recursos, lançamentos suportados, valores de parâmetros do kernel, recursos obsoletos e informações sobre problemas de conhecimento e suas soluções alternativas. Se você está atualizando de uma versão de IDS para outra, os releases notes são um ótimo lugar para aprender sobre mudanças feitas entre lançamentos. Se você está instalando novo, eles ainda são um ótimo lugar para encontrar informações sobre esta versão e outros locais para obter informações. Se você está herdando um produto já instalado, as notas de versão ainda podem ser encontradas em um subdiretório do diretório onde o IDS está instalado. Vamos chamar o diretório onde IDS está instalado de INFORMIXDIR. Então, os release notes de versão seriam encontradas em /INFORMIXDIR/release no Unix / Linux ou C: \INFORMIXDIR\release no Windows. Na verdade, eles seriam encontrados em um conjunto de diretórios localizados sob isso. Esses diretórios localizados seguem uma convenção do Global Language Support  (GLS). Se você estiver instalando a versão em inglês dos EUA do produto no Unix/Linux, a estrutura de diretório será semelhante a: /INFORMIXDIR/release/en_us/0333.

Dependendo do seu país e idioma, os dois últimos subdiretórios podem ser nomeados de forma diferente, mas ainda terão uma estrutura similar. Dentro desse diretório final, você encontrará o releve notes de versão, tanto em formato html quanto em texto, para todos os produtos IBM Informix instalados nesta máquina.

Locales

A última parte da seção do release notes começou a trazer uma idéia de suporte de linguagem global - Global Language Support (GLS). Nem todos os países do mundo falam a mesma língua, tem o mesmo alfabeto, ou utiliza o mesmo dinheiro. Portanto, você não deve esperar que o software seja apenas em um idioma. É ai que entra o Locales. A "localização" é o processo de transformação de um produto para atender a um ambiente cultural específico. Como parte da localização, você cria arquivos de recursos específicos da cultura, arquivos de tradução para mensagens e erros, arquivos de tradução para a interface do usuário do produto e definir os formatos de data, hora e dinheiro.

Definir um local leva um passo adiante; mas também especifica um conjunto de códigos (mapeamento de caracteres) e seqüência de agrupamento (ordem de classificação do dicionário). Essa separação permite que várias localidades existam para a mesma localização, semelhante a um país que tenha várias regiões. Todas as regiões falam a mesma língua, mas cada região tem sua própria variação de dialetos. O tipo de produto e hardware determinará a localidade padrão que é usada ao criar um banco de dados. Isso é conhecido como DB_LOCALE. Para o produto IDS nos Estados Unidos e instalado no Unix/Linux, o DB_LOCALE padrão é en_us.8859-1 (também conhecido como en_us.819). Se instalado no Windows, o DB_LOCALE padrão é en_us.1252. Se você deseja alterar o DB_LOCALE padrão, ele deve ser especificado no tempo de criação do banco de dados definindo a variável de ambiente DB_LOCALE na sessão que executa a instrução SQL CREATE DATABASE.

A codificação de caracteres ISO8859-1 é para o alfabeto Latino, que muitos países compartilham.

Embora o DB_LOCALE especifique a localização padrão para o banco de dados, os clientes que se conectam ao banco de dados têm a capacidade de usar uma localização diferente. Os clientes têm a variável de ambiente CLIENT_LOCALE que especifica a localidade do cliente. Para que o banco de dados e o cliente troquem informações, suas localidades devem ser iguais ou compatíveis (conversíveis).

Ao armazenar dados de caracteres para GLS, é importante usar o tipo de dados NCHAR e NVARCHAR, em vez do tipo de dados CHAR e VARCHAR. Os tipos de dados "N" permitem o agrupamento (ordem de classificação) dos dados com base no CLIENT_LOCALE, em vez de apenas no DB_LOCALE. A instrução SQL SET COLLATION permite que um cliente mude isso dinamicamente dentro de sua sessão atual.

A listagem abaixo mostra os conceitos de formatação dos locais GLS. Como muitos países utilizam o alfabeto latino, muitos dos conjuntos de códigos para esses países são compatíveis. Depois de criar a tabela Shoe Store acima e popula-la com uma linha, executei a seguinte instrução SELECT SQL várias vezes, mas alterei a variável de ambiente CLIENT_LOCALE para algo diferente, mas ainda compatível com o DB_LOCALE para cada execução.

Observe como, ao mudar o CLIENT_LOCALE, o formato de dados é diferente. (o formato, não os dados). Você precisa ter cuidado ao usar isso porque uma data é uma data em qualquer país, mas $85 dólares americanos não são iguais a 85 reais brasileiros. Além disso, o motivo pelo qual todas as datas surgiram no formato Month Day Year é devido à chamada para a função TO_CHAR com a formatação definida como% B% d% Y.

Abaixo mostra a saída se você remover a chamada para a função TO_CHAR e redor novamente  a instrução SQL com o CLIENT_LOCALE determinado:

Para recapitular, as bibliotecas GLS permitem que um aplicativo atenda às expectativas culturais dos dados sem ter que mudar o aplicativo. GLS locais, através do uso de tipos especiais de dados, variáveis de ambiente e instruções SQL, permitem a formatação dinâmica e a triagem de dados para atender aos padrões dos clientes. Tudo isso pode ser feito sem ter que escrever o aplicativo cliente de forma diferente para cada país/região do mundo em que ele possa ser usado.

Sumario

Nessa primeira parte desse tutorial, você estudou sobre:

• Os dois tipos diferentes de aplicativos usados em comparação ao sistema RDBMS
• Como a autenticação do usuário é tratada no IDS
• Todos os diferentes tipos de dados que o IDS está disponível para usar
• Extensibilidade de IDS através de UDTs e UDRs
• Arquivos "Read-me first" e release notes no IDS
• Localização GLS