quinta-feira, 12 de agosto de 2010

Manutenção de Tabelas

Tabelas do Catálogo do Sistema

  • systableDescreve cada tabela no banco de dados

    SELECT * FROM systables
    WHERE tabname = “customer”;

  • syscolumns – Descreve cada coluna nas tabelas

    SELECT * FROM syscolumns
    WHERE tabid = (SELECT tabid FROM systables WHERE tabname = “customer”);

Sempre que um banco de dados é criado, automaticamente são criadas tabelas de catálogo de sistema que armazenam informações sobre o banco de dados.  Sendo que o catálogo de sistema é armazenado dentro de tabelas normais do banco de dados, elas podem ser examinadas como qualquer outra tabela do banco de dados. Você pode usar estas tabelas para se familiarizar com a estrutura do banco de dados.

  • A tabela de catálogo de sistema systables descreve cada tabela do banco de dados. Ela contém uma linha para cada tabela, view, e sinônimos definidos no banco de dados, inclusive as tabelas de catálogo de sistema deles. A informação armazenada na tabela inclui o nome da tabela, dono, tamanho de linha, números de linhas, numero de colunas, modo de lock, tamanho de extents, e números de índices. A ligação entre a informação em systables com outras tabelas de catálogos é a coluna tabid, o identificador de catalogo de sistema tem tabids menores que 100.
  • A tabela de catálogo de sistemas syscolumns descreve cada coluna nas tabelas no banco de dados. Cada linha contem um nome de coluna, o tabid da tabela, o numero de seqüência da coluna dentro da tabela, o tipo de coluna, e o tamanho físico.

Tabelas Temporárias

CREATE TEMP TABLE temp_ordem (
ordem_num INTEGER) WITH NO LOG;

SELECT nome, sobrenome, cidade
FROM clientes
INTO TEMP temp_clientes WITH NO LOG;

Tabelas temporárias podem ser criadas em dbspaces especificamente criados para objetos temporários designados pela variável de ambiente ou parâmetro de configuração do Informix DBSPACETEMP.

Você pode criar tabelas temporárias que são semelhantes a uma tabela permanente a não ser que só é valida para a duração da sessão. Não há nenhuma entrada para uma tabela temporária nos catálogos de sistema systables ou syscolumns. Você não pode alterar tabelas temporárias. Você pode criar índices nelas.
Se você fechar a conexão com o banco de dados atual, a tabela temporária será apagada. Alternativamente, você pode derrubar uma tabela temporária usando o comando DROP TABLE.

Dbspaces temporários

As tabelas temporárias devem ser criadas em um dbspace que é especificamente designado para tabelas temporárias dentro do sistema Informix. Um dbspace temporário não gera registro nos logical logs. Então, tabelas temporárias criadas em um dbspace temporário devem ser de um banco de dados sem log ou tem de ser criadas usando a sintaxe WITH NO LOG. Um dbspace é designado como temporário no momento em que é criado.

DBSPACETEMP

A variável de ambiente DBSPACETEMP pode ser configurada para um ou mais dbspaces. Se uma variável de ambiente DBSPACETEMP não é configurada, o Informix usa o valor do parâmetro de configuração DBSPACETEMP.

Sinônimos

CREATE SYNONYM ord FOR logix:ordem;

CREATE SYNONYM cust FOR logix@prd:aviso_rec;

Você pode criar um sinônimo (synonym) para qualquer tabela ou view em qualquer banco de dados de seu servidor ou qualquer servidor de banco de dados na rede. O exemplo a seguir mostra um sinônimo para uma tabela fora do banco de dados atual:

CREATE SYNONYM ord FOR logix:ordem;

Se a tabela esta em um servidor de banco de dados diferente em sua rede, este servidor de banco de dados deve estar on-line quando você cria o sinônimo:

CREATE SYNONYM cust FOR logix@prd:aviso_rec;

Você pode criar um sinônimo para uma tabela que esta sendo excluída ou movida para um local diferente. Se o sinônimo tem o mesmo nome das tabelas excluídas ou movidas, a mudança será transparente para os usuários.
Os sinônimos são descritos na tabela de catalogo de sistema systables, com um tipo de tabela (tabtype) de “S”, e na syssyntable.

Privilégios

Os usuários tem os mesmos privilégios para um sinônimo como para a tabela para a qual o sinônimo aponta. Se o seu banco de dados é MODE ANSI, ou se você usa a palavra chave PRIVATE ao criar sinônimo, o usuário tem que saber o nome do dono do sinônimo.

CREATE PRIVATE SYNONYM meu_estoque FOR logix:estoque_trans;
SELECT * FROM amilcar.meu_estoque; – amilcar é o dono

Alterando uma Tabela

Usando o comando ALTER TABLE, você pode:

  • Adicionar uma coluna.
    Usando a clausula ADD, uma coluna pode ser acrescentada à tabela. Os conteúdos da coluna serão NULOS para linhas que já existam antes do comando ALTER TABLE ser executado. Você pode especificar onde por a coluna somando a clausula BEFORE. O exemplo seguinte põe a coluna ordem_op antes da coluna order_data:

    ALTER TABLE ordem
    ADD ordem_op INTEGER
    BEFORE ordem_data;
  • Modificar uma coluna.
    Você pode usar a clausula MODIFY para mudar o tipo de dado, o comprimento, ou permissão ou não de nulos em uma coluna. Você tem que especificar todos os atributos existentes para uma coluna ( por exemplo, as constraints UNIQUE e NOT NULL), ou eles serão excluídos. Você pode alterar uma tabela para mudar o tipo de dado se o novo tipo de dados for incompatível com os dados que já estão na coluna.
  • Excluir uma coluna.
    Você pode excluir uma coluna usando a cláusula de DROP. Excluir uma coluna significa que serão perdidos todos os dados desta.

In-Place ALTER TABLE

In-Place ALTER TABLE é usado para varias modificações que pode ser feitas a uma tabela. Como resultado, a tabela só é indisponível a usuários enquanto a definição da tabela é atualizada. Não é criada uma copia da tabela. Ao invés disso, são atualizadas as linhas de dados existentes à nova definição somente quando eles são atualizados. Novas linhas são inseridas com a nova definição. Esta característica é usada automaticamente.

Versões de Definição da Tabela (Table Definition Version)

O algoritmo In-Place ALTER TABLE cria uma nova versão da definição da tabela. Até 255 versões de definição da tabela são permitidas pelo servidor de banco de dados. Informações sobre as versões estão disponíveis usando a ferramenta oncheck:

# oncheck logix:ordem de –pT

Cada página de dados é associada com uma versão. Depois de uma In-Place ALTER TABLE, só são inseridas linhas novas em paginas de dados com a nova versão. Então, o mesmo extent pode ter versão 0, versão 1, versão 2 de paginas, por exemplo. Quando linhas em paginas antigas são atualizadas, todas as linhas na pagina de dados são atualizadas para a versão nova, se houver espaço suficiente. Se não houver espaço suficiente, a linha é apagada da pagina velha e inserida em uma pagina com a versão nova.

Quando uma tabela com varias versões é consultada, o Informix retorna os valores apropriados para qualquer coluna que não exista fisicamente. São retornados valores default para colunas criadas com um valor default, caso contrario são retornados como valores nulos.

Cada comando in-Place ALTER TABLE subseqüente na mesma tabela,  leva mais tempo para ser executado. Informix recomenda não mais que 50 a 60 execuções de Alters em uma tabela. Se você deseja eliminar as varias versões de uma tabela, force uma mudança imediata a todas as linhas. Por exemplo, use um simples comando UPDATE que fixa o valor de uma coluna a ela mesma.

Logging e ALTER TABLE

O comando ALTER TABLE cria registros nos logical logs mesmo quando o banco de dados não permite log. Com grandes tabelas e uma quantidade inadequada de espaço de logical log, pode ser difícil de evitar uma long trasaction. Usando um comando in-place ALTER TABLE, cada pagina de dados tem um registro no log no momento que a mudança acontece fisicamente (isto é, quando uma linha é inserida ou é atualizada). Os registros iniciais nos logical logs para o comando In-Place ALTER TABLE são muitos breves.

In-Place ALTER TABLE não sera usado se:

  • Adicionando ou Excluindo uma Coluna
    Se a coluna que é adicionada ou excluída é parte de uma expressão de fragmentação usada para fragmentar uma tabela, o In-Place ALTER TABLE não será usado. Se a coluna excluída for a referenciada por uma expressão de fragmentação de indice, um erro sera retornado.
  • Modificando uma coluna
    A operação de modificação esta sujeita a mais restrições. Em geral, a operação não será executada In-Place, se não puderem ser feitas todas as conversões entre os tipos de dados anteriores e os novos sem erros, ou se a distribuição de linhas por fragmentos mudar como resultado desta conversão. A coluna modificada não pode ser um VARCHAR.

Tamanho do Next Extent e Modo de Lock

ALTER TABLE ordem MODIFY NEXT SIZE 300;

ALTER TABLE ordem LOCK MODE (ROW);

O ALTER TABLE pode ser usado para mudar o tamanho da Next Extent ou modo de lock para uma tabela:

  • Voce pode mudar o tamanho da Next Extent. Isto não alterará qualquer Extent atual que foi alocado, só os futuros. O exemplo acima mostra a mudança do tamanho da Next Extent para 300 Kb.
  • Voce pode mudar o modo de Lock das linhas para PAGE ou ROW.

Tabelas sem Log

O Informix tem um tipo adicional de tabela, a Raw Permanent Table. Esta tabela não gera registro nos logical logs mesmo que o banco de dados tenha log. Antigamente somente tabelas temporarias poderiam estar sem log. Tabelas com o comportamento normal em um banco de dados com log são chamadas de Standart Permanent Tables.
Esta caracteristica permite o carregamento rápido de tabela muito grandes. Você pode usar qualquer ferramenta de carregamento, o High Performance Loader por exemplo, para carregar tabelas raw. Depois que o dado está carregando, um backup nível-0 deve ser executado. Isto prove um ponto de partida para restarbelecer dados se for necessario. Para evitar problemas de concorrencia e dados incompativeis, voce tem que mudar uma tabela raw em uma tabela standard antes de usar a tabela em uma transação.
Tabelas standart existentes podem ser convertidas temporariamente para tabelas raw para carregar rapidamente dados novos. Será solicitado a você excluir qualquer indice ou constraint, pois esses não são permitidos em uma tabela raw.

Renomeando Colunas, Tabelas e Bancos de Dados

RENAME COLUMN financeiro.paid_date TO data_pagamento;

RENAME TABLE stock TO estoque;

RENAME DATABASE logix TO totvs;

Se voce renomeia uma coluna que é referenciada por uma view no banco de dados, o texto da view na tabela de catalogo de sistema sysviews é atualizado com o novo nome. Se a coluna é referenciada em um check constraint, o texto do check constraint é atualizado na tabela de catalogo de sistema syschecks.
Quando uma tabela é renomeada, as referencias para a tabela dentro de qualquer view são alteradas.
O comando RENAME TABLE opera tanto em sinonimos como tambem tabelas. O nome da tabela é substituido se aparecer em uma definição de Triggers. Não é substituido se estiver dentro das ações da Trigger.

Em Stored Procedures

Os nomes de colunas e tabelas dentro do texto de uma stored procedure não são alterados pelo RENAME COLUMN ou RENAME TABLE. A stored procedure devolvera um erro quando esta se referir uma coluna ou tabela não existente.

Excluindo Tabelas e Banco de Dados

DROP TABLE ordem;

DROP DATABASE logix;

Quando você exclui uma tabela ou banco de dados, o espaço ocupado pelas tabelas é liberado e os dados não são mais acessiveis.

Residencia em Memoria

SET TABLE estado MEMORY_RESIDENT;

SET TABLE estado NON_RESIDENT;

O desempenho de uma query pode ser melhorada se o objeto da query não tiver que ser recuperado em disco. Esta caracteristica permite que um ou mais fragmentos de uma tabela, a tabela inteira ou um indice especifico tenha tratamento preferencial no Buffer Pool da memoria compartilhada. Suas paginas serão as ultimas a serem consideradas pela substituição de pagina quando um free buffer é solicitado pelo servidor de banco de dados.
Um usuario tem que ter permissão DBA na tabela para fixa-la em memoria. Para desativar esta caracteristica, use a sintaxe:

SET TABLE nome_tabela NON-RESIDENT;

O desligamento do servidor também desativara esta caracteristca.

O Utilitario DBSCHEMA

dbschema –d logix

dbschema –d logix –ss

dbschema –d logix –t ordens > schema.out

O utilitario DBSCHEMA é usado para produzir um arquivo de comandos SQL que contém os comandos CREATE TABLE, CREATE INDEX, GRANT, CREATE SYNONUM, E CREATE VIEW solicitados para reproduzir um banco de dados inteiro ou uma tabela selecionada. Você tem que especificar o banco de dados com opção –d.

Opções Adicionais:

-t tabname Só a tabela ou view serão incluidas. Especifique all em lugar de tabname para todas as tabelas.
-s synname Comandos CREATE SYNONYM do usuário (synname) especificado. Especifique all no lugar do synname para todos os sinonimos.
-p pname Imprime só os comandos GRANT para o usuario listado. Especifique all no lugar do pname para todos os usuarios.
-f stproc Exibe informações de distribuição. Especifique all no lugar do stproc para todas as store procedures.
-hd tabname Exibe informações de distribuição. Especifique all no lugar do tabname para todas as tabelas.
-ss Gera informação server-specific para a tabela informada, incluindo o modo de lock, tamanho de extent e nome de dbspace.
-r Gera CREATE e GRANT do role especificado ou entre com all para todos os roles.
outputfilename Envia a saida ao arquivo nomeado.

segunda-feira, 9 de agosto de 2010

Criando Banco de Dados e Tabelas

Criando um Banco de Dados

Como administrador do banco você precisa saber certas decisões antes de criar um banco de dados.

  • Onde no sistema Informix, o banco de dados será armazenado? Normalmente esta decisão é tomada junto com o administrador do sistema Informix, quem cria e administra os dbspaces dentro de um sistema Informix.
  • Você usará um log de transação para registrar todas as mudanças nos dados do banco de dados? Quando este log será enviado ao disco?
  • Este será um banco de dados padrão ANSI? Bancos de dados ANSI devem estar de acordo com certas regras colocadas pelo comitê de padrões ANSI.

Quando você cria um banco de dados, são geradas automaticamente tabelas e catálogo de sistema (system catalog) que descrevem a estrutura do banco de dados. Estas tabelas são acessadas cada vez que um comando SQL é executado. O catálogo de sistema é usado para determinar privilégios no sistema ou verificar nome de tabelas, por exemplo.

Localização: Dbspaces

A localização de banco de dados, tabelas e índices no Informix são um conjunto particular de espaço em disco, chamado de dbspace. A instância do IDS possui espaço de disco associados a ela denominados chunks. Cada chunk é uma unidade contínua de espaço. Um conjunto lógico de chunks é chamado de dbspace. Cada instância do Informix tem pelo menos um dbspace, o root dbspace.

Localização de um banco de dados

Você pode especificar qual dbspace usar ao criar um banco de dados. isto significa que as tabelas de catálogo de sistema serão localizadas no chunk ou chunks associados a este dbspace. A menos que você especifique o contrário, todas as tabelas associadas com aquele banco de dados, e os índices correspondentes, serão armazenados neste dbspace.
Se você não especificar o dbspace no qual criará o banco de dados, o banco de dados, por default, será criado no root dbspace. Isto não é recomendado. Outros dbspaces devem ser criados para conter os bancos de dados.

Separando os bancos de dados em dbspaces diferentes pode ter várias vantagens:

  • Um banco de dados não pode crescer além do espaço disponível no dbspace. Limitando o tamanho e número de chunks associados a um dbspace, você limita também o tamanho do banco de dados.
  • Você pode associar os bancos de dados a diferentes devices associando-os a dbspaces separados que tem chunks em dispositivos diferentes. Isto reduzirá a concentração de I/O.
  • Se um de seus dispositivos sofrer falha, você perderá o acesso ao banco de dados armazenado no dbspace daquele dispositivo. outros bancos de dados não serão afetados.

DBspaces e crescimento

Dbspaces podem ter tantos chunks associados a ele quanto necessário. Se você esgotar o espaço em um dbspace em particular (porque todos os chunks associados a ele estão cheios), você pode adicionar chunk a ele.

Modos de Log: No Logging

Você pode criar um banco de dados no sistema Informix que não registre (log) transações. Se um banco de dados não tiver log, então não é registrada qualquer mudança feita aquele banco de dados no logical log. Da perspectiva da aplicação, isto significa que transações não são suportadas.

Sem recuperação Total

Mais importante, um banco de dados sem log não pode ser recuperado completamente se você precisar restabelecer o sistema de um archive (backup). Considerando que um archive registra o estado do sistema no momento do archive, quaisquer alterações feitas desde o momento do archive devem ser recuperadas dos registros nos logical logs. Considerando que um banco de dados sem log não cria registro de log, não haverá como recuperar essas alterações.

Modos de Log: Buffered Logging

Se você escolher registrar as transações do banco de dados, os registros dos logs não são gravados diretamente em disco. Eles são posto primeiro em um buffer em memória, chamado logical log buffer. Eventualmente o buffer será transferido para disco e as entradas serão gravadas no logical log em disco.
Se um banco de dados é criado com Buffered Log, então os registros do logical log buffer não serão gravados em disco até que o buffer seja preenchido totalmente.

Vantagem

O volume de I/O físico é reduzido consideravelmente. Considerando que o I/O físico é uma operação que demanda um grande custo, isto pode melhorar o desempenho de seu sistema.

Desvantagem

Se um crash (queda) de sistema acontecer, tudo que está contido no buffer e não estiver ainda em disco será perdido. Sem os dados que estão contidos no logical log em disco, o IDS não pode recuperar essas transações quando o sistema é novamente colocado em operação. Assim enquanto Buffered Log pode melhorar o desempenho, ele pode resultar na perda de algumas transações no caso de uma queda do sistema.

Modos de Log: Unbuffered Logging

Se um banco de dados é criado com unbuffered Log, o conteúdo do logical log buffer é gravado no logical log em disco assim que uma transação esteja completa. Isto significa que uma vez que você completou uma transação no banco de dados, os logs desta transação serão gravados em disco.

Vantagem

Se houver uma falha de sistema, as alterações serão recuperadas quando o sistema voltar a operar.

Desvantagem

Um volume maior de I/O físico será executado em disco, o que pode degradar um pouco o desempenho.

Banco de Dados Mode ANSI

Quando você cria um banco de dados padrão ANSI (Log Mode ANSI) as seguintes características principais o diferenciam de um banco de dados fora de MOde ANSI:

  • Todos os bancos de dados usam log unbuffered.
  • Todos os comandos são contidos em transações. Programas que acessam banco de dados ANSI não podem usar o comando BEGIN WORK; o programa sempre está em uma transação e o comando COMMIT WORK implicitamente iniciará uma nova transação assim que a transação corrente seja concluída.
  • A propriedade é exigida. Você tem que usar o nome do dono quando você recorrer a cada tabela, view, sinônimo, índice, ou constraint a menos que você seja o dono deste objeto.
  • O nível de isolamento default é Repeatable Read. Os níveis de isolamento serão discutidos em um capítulo posterior.
  • Os privilégios default em bancos de dados ANSI é diferente de bancos de dados não ANSI. Usuários não recebem privilégios PUBLIC para tabelas e sinônimos por default.

O comando CREATE DATABASE

Você cria um banco de dados com o comando CREATE DATABASE. Este comando também criará automaticamente o catálogo de sistema. Os exemplos mostram diferentes modos para criar um banco de dados no IDS.

CREATE DATABASE tecnologia

Este comando criará um banco de dados no local default que é o root dbspace. O banco de dados é criado sem log. Como mencionando anteriormente, a criação de banco de dados root dbspace não é recomendada.

CREATE DATABASE tecnologia IN dbspace1 WITH LOG

Este exemplo cria um banco de dados no dbspace chamado dbspace1, com Unbuffered Logging.

CREATE DATABASE tecnologia WITH BUFFERED LOG

Este exemplo criará um banco de dados no local default com Buffered Logging.

CREATE DATABASE tecnologia IN dbspace1 WITH LOG MODE ANSI

Este exemplo criará um banco de dados ANSI no dbspace chamado dbspace1. Um banco de dados ANSI usa Unbuffered logging.

Criando uma tabela

Quando você cria uma tabela em um banco de dados, você deve decidir:

  • Os nomes e os tipos de dados das colunas na tabela
  • O dbspace onde a tabela será armazenada. As tabelas podem ser criadas no mesmo dbspace onde esta o banco de dados ou em um dbspace diferente.
  • A quantidade de espaço continuo a ser alocado inicialmente no dbspace para esta tabela. isto é determinado pelo tamanho de extent configurado na tabela.
  • O nível de lock da tabela. Locks são usados para prevenir um usuário de acessar os dados que estão sendo utilizados por outro usuário.

Quando uma tabela é criada, as informações das colunas e das tabelas são inseridas automaticamente nas tabelas de catálogo systables e syscolumns.

Tabelas e Dbspaces

Com o Informix, você pode criar tabelas em dbspaces diferentes daqueles onde se localiza o banco de dados. As informações do catálogo do sistema para a tabela são armazenadas com o resto do banco, mas os dados da tabela serão armazenados no dbspace especificado.
A vantagem da localização de algumas tabelas em dbspaces diferentes é que estas tabelas podem ser colocadas em dispositivos físicos diferentes do restante do banco de dados.

  • Tabelas Grandes – não haverá competição para espaço de outras tabelas.
  • Tabelas Acessadas Frequentemente – Terão uma redução de concentração de leitura do disco quando outros processos agirem em tabelas diferentes.

Agrupando tabelas para Backup (Archive)

Os utilitários de archive (backup) do IDS suportam archive e restore com paralelismo e com granularidade de dbspace. Para utilizar ao máximo estas vantagens, agrupe tabelas em dbspces baseado em quais tabelas precisam ser arquivadas mais frequentemente.

Extents

O espaço em disco para uma tabela é alocado em unidades denominadas extents. Um extent é um volume de espaço fisicamente contínuo em disco; a quantidade é especificada para cada tabela quando esta é criada.
O tamanho de um extent é especificado em kilobytes. Este numero deve ser múltiplo do tamanho da pagina do sistema (page size). A pagina é a unidade básica de I/O em um sistema Informix. O tamanho da pagina é determinada pela arquitetura do servidor ou sistema operacional, e não pode ser mudado. O tamanho de pagina mais usado é 2 kbytes, embora alguns sistemas usam 4 kbytes no tamanho da pagina.
Quando um extent é acrescentado, no principio esta vazio. Quando este extent não tem mais espaço, outro extent será alocado para a tabela, quando aquele extent estiver cheio, outro extent será alocado, e assim por diante.
Cada tabela tem dois tamanhos de extent associados a ela.

Extent Size (Tamanho de Extent) – É o tamanho do primeiro extent alocado para a tabela. Este primeiro extent é alocado quando a tabela é criada. O padrão é 8 paginas.

Next Size (Próximos Extents) – É o tamanho de cada extent subseqüente a ser acrescentado à tabela. O default é 8 paginas.

O tamanho mínimo de um extent é de 4 paginas. Não há nenhum tamanho máximo na pratica (estaria numa faixa de 2 Gigabytes). Informix recomenda calcular o tamanho de extent para cada uma de suas tabelas ao invés de usar o tamanho de extent default.

Tblspace

Todos os extent alocados para uma determinada tabela são logicamente agrupados e são referenciados como um tblspace. O espaço representado pelo tblspace pode não ser contínuo, pois os extent podem estar espalhados por um dispositivo até onde se tenha espaço. Uma vez que um extent foi alocado para uma tabela, este extent nunca será liberado para reutilização por outras tabelas. Se um extent deveria ficar vazio (devido a um volumoso DELETE na tabela), o extent ainda fara parte do tblspace. Porém, o espaço será utilizado novamente quando são inseridas linhas adicionais nesta tabela no futuro.

Numero total de extents

O número total de extents permitidos em uma tabela varia de acordo com o tamanho de página, numero de índices, o numero de coluna por índice, e o tipo de colunas na tabela (VARCHAR, TEXT, ou BYTE). Para sistemas com uma pagina de 2 kbytes, o numero máximo de extents é aproximadamente 200. Sistemas com 4 kbytes podem ter aproximadamente 450 extents. Se uma tabela alcançar o numero de máximo de extents, você precisara descarrega-lá (unload), achar um espaço contínuo para recriar a tabela com menos extents, e então recarregar os dados.
Ter muitos extents pode afetar o desempenho, particularmente em um ambiente com processos volumosos (DSS) onde são selecionados grandes grupos de linhas. Haverá I/O adicional ao trazer as páginas de dados para a memoria compartilhada em virtude de todos os extents que precisaram ser acessados.

Reclamando espaço em extents vazios

Se você quiser reclamar o espaço em extents vazios e torna-lo disponível para o dbspace utilizar em outras tabelas, você pode mudar um dos índices da tabela par um índice CLUSTER, forçando uma regravação da tabela. Isto é discutido em mais detalhes no capítulo Índices e Estratégia de Indexação.

Crescimento dos Extents

Há situações especiais que podem alterar o tamanho dos extents subseqüentes com relação ao tamanho especificado no momento em que a tabela foi criada.

Concatenação (Concatenation).

Concatenação de extents acontece quando um extent de uma tabela é alocado e este extent é fisicamente adjacente a um extent já existente para a mesma tabela. O extent existente é simplesmente aumentado. Este efeito é visto frequentemente ao executar uma grande de carga em uma tabela. Geralmente, cada extent novo alocado será contínuo com a extent já existente. Uma grande tabela pode ser carregada e ao final estar ocupando um único grande extent.

Duplicando (Doubling)

Duplicação do espaço de Extent ocorre quando o número de extent alocados para uma tabela em particular cresce para um múltiplo de 16. O tamanho atual de um novo extent será dobrado.

 

Modificação Manual

O tamanho do primeiro extent subseqüentes é especificado quando a tabela é criada. É possível alterar o tamanho de extent usando o comando ALTER TABLE. Você pode  aumentar ou pode diminuir o tamanho de extent para qualquer extent subseqüente. Isso não alterará o tamanho de extents já alocados.

Limitação de Espaço

Se a quantidade livre de espaço contínuo em um dbspace é menor que o tamanho do extent atual, a quantidade de espaço disponível será alocada ao extent embora seja menor que a quantidade desejada. Será usado o espaço mínimo disponível para o extent.

Modo de Lock da Tabela

Para prevenir erros quando mais de um usuário esta lendo ou modificando dados, o Informix usa um sistema de locks para controlar o acesso. Quando você cria uma tabela que você pode escolher o nível de lock que o Informix usará para a tabela.

Nível de Lock por Pagina ( Page Level)

O lock por pagina estabelece um lock em uma página inteira. Este é o nível de lock default. O lock por pagina provê o método mais eficiente para estabelecer lock em varias linhas. Mas, pelo fato de estar colocando lock em todas as linhas da página, outros usuários não podem acessar estes dados. O lock por pagina diminui a concorrência, ou a disponibilidade dos dados para outros usuários.
Considerando que um lock por pagina, na verdade estará estabelecendo um lock em mais de uma linha com um só recurso, torna-se quando você está processando as linhas na mesma ordem como elas estão colocadas fisicamente em disco. Por exemplo, se você estiver processando uma tabela em sua ordem física, o lock por pagina lhe permite atualizar muitas linhas com menos locks.

Nível de Lock por Linha (Row Level)

O lock por linha estabelecerá locks em uma única linha de cada vez. O lock por linha aumenta a concorrencia porque só uma linha esta com lock. O IBM Informix Dynamic Server usa lock por linha nas tabelas de catálogo de sistema para prover o nível mais alto de concorrência. Quando o numero de linhas com lock é alto, você não só corre o risco por diminuir o numero de locks disponíveis, como torna o overhead do gerenciamento de locks significativo.

O comando CREATE TABLE

CREATE TABLE ordens (
                     order_num           SERIAL NOT NULL,
                     customer_num      INTEGER, 
                     order_date           DATE )
IN dbspace1
EXTENT SIZE 64
NEXT SIZE 32
LOCK MODE row;

O exemplo do comando CREATE TABLE acima, cria uma tabela chamada ordens  com três colunas, a tabela será gravada no dbspace1. 64 kbytes serão necessários, para alocar o primeiro extent. Todo extent subseqüente será alocado com 32 kbytes. Quando o lock for aplicado em algum registro da tabela, será com lock por linha. As tabelas também podem ser fragmentadas em diversos dbspaces para melhorar performance.

Estrutura de uma Pagina

Ao armazenar informações em uma tabela, o tipo de dado armazenado em uma pagina particular é homogêneo; quer dizer, se as linhas de dados são armazenadas na pagina, então a pagina conterá apenas linhas de dados. Se dados de índice são armazenados em uma pagina, então aquela pagina conterá somente dados de índice. Algumas paginas são reservadas para propósitos administrativos.

Todas as paginas usadas no servidor tem a seguinte estrutura de dados:

  • Page header – 24 bytes de informação usados para manter o mapa dos dados na pagina.
  • Timestamp – os últimos 4 bytes na pagina, usado para assegurar a validade das gravações.
  • Slot Table – contem uma entrada de 4 byte para cada linha inserida na pagina. Os 4 bytes armazenam o offset da linha na pagina e do tamanho da linha. A Slot Table é usada para localizar linhas na página.

O resto de espaço na pagina esta disponível para armazenar dados ou informações de índice.

Estimando Tamanho de Linhas e Extents para as Tabelas

Algumas diretrizes para calcular o espaço requerido para o armazenamento de uma tabela são:

  1. Determinar o número de linhas que você  deseja armazenar inicialmente na tabela.
  2. Determinar o comprimento da linha somando o tamanho de todas as colunas na tabela. Colunas BLOB que não são armazenados na tabela usarão 56 bytes para o ponteiro. Tabelas que contem VARCHAR ou colunas BLOB localizadas na tabela são impossíveis de terem seu tamanho calculado com precisão. Você pode usar o tamanho máximo possível ou um tamanho médio, mas o tamanho de linhas resultante será uma estimativa.
  3. Some 4 bytes para a entrada de Slot Table. O resultado é o rowsize (tamanho da linha).
  4. Determinar o tamanho da pagina em bytes subtraindo 28 (para o header) para obter o espaço de página utilizável (pageuse).
  5. Determinar quantas linhas inteiras podem ser gravadas em uma pagina (arredondado para baixo):
    # de linhas em uma pagina = pageuse / rowsize
  6. Determinar quantas paginas são necessárias (arredondando para cima)
    # de paginas = linhas totais / # de linhas em uma pagina
  7. Determinar o espaço total necessário em kbytes, utilizando uma pagina de 2 kbytes ou 4 kbytes, dependendo de seu sistema:
    espaço de disco = #de paginas * tamanho de pagina
  8. O resultado em #7 é o tamanho do FIRST EXTENT. Repita os passos, baseado no crescimento antecipado, para determinar o tamanho do NEXT EXTENT.

Alternativa: método “rough estimate” (Estimativa áspera):

Estimativa áspera: (#de linhas * tamanho de linha * 125%)

Se o tamanho de linha é maior que o espaço utilizável em uma pagina, o Dynamic Server dividira a linha entre homepages e mainder pages. O numero de páginas de dados é calculado assim:
# de homepages + #de remainder pages.

Calculando Extent Size: exemplo usando a tabela clientes

Assuma que a base de clientes atual é 10.000 e é esperado que o crescimento anual seja de 5.000.

  1. Determine o numero de linhas que você deseja armazenar inicialmente na tabela (atual + crescimento = total).
    FIRST EXTENT baseado na base de clientes atuais + resto do ano = 10.000 + 5.000 = 15.000 linhas
    NEXT EXTENT baseado no crescimento anual = 5.000 linhas
  2. Determinar o comprimento da linha somando o tamanho de todas as colunas.
  3. Nome Coluna Tipo Dados Bytes
    num_cliente serial 4
    nome char(15) 15
    sobrenome char(15) 15
    endereco char(20) 20
    endereco_compl char(20) 20
    cidade char(15) 15
    estado char(2) 2
    cep char(5) 5
    telefone char(18) 18
    Total   114
  4. Some 4 bytes para a Slot Table.
    Rowsize = 114 + 4 = 118
  5. Determinar o tamanho da pagina subtraindo 28 para obter o espaço de pagina utilizável.
    Para pagina de 2 kbytes: 2048-28 = 2020
  6. Determinar quantas linhas inteiras podem se ajustar em uma pagina (arredondamento para baixo):
    2020/118 = 17.1 = 17 linhas
  7. Determinar quantas paginas são necessárias (arredondamento para cima):
    FIRST EXTENT = 15.000/17 = 823,5 = 824 paginas de dados
    NEXT EXTENT = 5.000/17 = 294,1 = 295 paginas de dados
  8. Determinar o espaço total necessário em kbytes:
    FIRST EXTENT = 824 * 2 kb = 1648 Kb
    NEXT EXTENT = 295 * 2 kb = 590 kb

O banco de dados Sysmaster

O System Monitoring Interface (SMI) oferece uma visão instantânea das informações de status do sistema para uma instancia Informix inteira. O banco de dados sysmaster engloba as tabelas usadas pelo SMI para recuperar estas informações. Há um banco de dados sysmaster para cada sistemas IDS. O banco de dados é criado automaticamente na primeira vez que o sistema IDS é iniciado.
A maioria das tabelas do sysmaster não armazenam qualquer dado. Ao invés disso, a estrutura do banco de dados aponta para as estruturas em memoria. Quando você examinar as tabelas do sysmaster usando SQL, o comando SELECT tem acesso aos dados em tempo real na memoria. Por isso, os dados recuperados de uma tabela, podem, não estar sincronizados com os dados recuperados de uma outra tabela.

Um banco de dados adicional, o banco de dados sysutils, também é criado automaticamente quando o sistema IDS é iniciado. Este banco de contém informações utilizadas pelas ferramentas de archive.

A seguir, são descritos alguns comandos SQL para obter informações sobre sua instancia Infomix no banco de dados sysmaster.:

  • sysdbspaces: todos os dbspaces na instancia, o numero de chunks, assim como se o dbspace é um blobspace ou dbspace temporários, status do dbspace:
    SELECT dbsnum, name, owner, nchunks, is_temp, isblobspace, flags
    FROM sysdbspaces;
  • syschunks: Numero de paginas livres, e o Numero de paginas usadas em chunks para um dbspace particular:
    SELECT syschunks.dbsnum, chknum, nxchknum, sysdbspace.name, chksize, nfree
    FROM syschunks, sysdbspaces
    WHERE syschunks.dbsnum = sysdbspaces.dbsnum
    AND sysdbspaces.name = “nome do dbspace”
  • sysdatabases: todos os bancos de dados da instancia e o status de seu modo log
    SELECT name, owner, created, is_logging, is_buff_log, is_ansi
    FROM sysdatabases;
  • systabnames: todas tabelas no banco de dados e seu dono
    SELECT partnum, dbsname, owner, tabname
    FROM systabnames
    WHERE dbsname = “nome do banco”
  • syssessions: usuario por sessão, nome do host, tempo conectado
    SELECT sid, username, uid, hostname, connected
    FROM syssession;
  • sysextents: cada extent no banco de dados, e a tabela associada a ela
    SELECT dbsname, tabname, start, size
    FROM sysextents;

quarta-feira, 4 de agosto de 2010

Tipos de Dados do Informix

CHAR vs. VARCHAR

  • CHAR(32)
    • Use se o conteúdo da coluna for imprevisível
    • Espaço necessário = comprimento
  • VARCHAR(150,20)
    • Use se a maioria das linhas usa uma quantidade pequena de espaço e o tamanho máximo da coluna é exceção.
    • Espaço necessário = comprimento + 1

Os tipos de dados character armazenam qualquer combinação de letras, números e símbolos. Tabulações e espaços podem ser incluídos. Nenhum outro character no-printable é permitido.

  • CHAR
    As colunas do tipo CHAR tem comprimento fixo. O comprimento máximo de uma coluna CHAR é de 32.767 bytes. Se uma coluna é definida com tamanho de 400 bytes, os dados nesta coluna ocuparão este espaço, mesmo que sejam inferiores a 400 bytes. Números também podem ser armazenados em uma coluna CHAR. Quando são armazenados assim, não poderão ser utilizados em algumas operações aritméticas. A ordenação de números seguirá a seqüencia do código ASCII, e quando armazenados em colunas numéricas são ordenados pela seqüencia binária. Números destinados a cálculos aritméticos devem ser armazenados em colunas numéricas.

 

  • VARCHAR
    Colunas VARCHAR armazena dados do tipo character com comprimento variável. Estas colunas podem armazenar dados de 0 a 255 bytes. Além do conteúdo da coluna, indicador de um byte é armazenado no inicio da coluna.
    O beneficio principal no uso de tipo de dados VARCHAR é que, quando usado corretamente, pode aumentar o número de linhas armazenadas por paginas em disco. VARCHAR é utilizado mais efetivamente quando a maioria das linhas precisa de pequena quantidade de espaço em disco, e algumas linhas requerem significativamente mais espaço. Por exemplo, uma coluna de comentário pode não ser usada em 80% das linhas de uma tabela. Porém, quando é preenchida, o tamanho máximo da coluna é frequentemente consumido.
    Como mais linhas podem ser armazenadas em uma página, campos VARCHAR podem aumentar a performance em leituras seqüenciais de tabelas e pode reduzir o desperdício de espaço em disco quando comparado com os mesmos dados armazenados em campos do tipo CHAR.
    Quando especificamos dados do tipo VARCHAR, um comprimento máximo de coluna é incluído na sintaxe da definição da coluna. O parâmetro de max-size fixa o limite máximo no comprimento dos caracteres permitido dentro do campo. O min-size fixa o comprimento mínimo de espaço em disco que sempre será reservado para dos dentro do campo. Quando uma linha é gravada, o Informix grava o numero de bytes necessários para armazenar o dado ou o número de bytes especificado em min-size para a coluna (o que for maior). Se depois a coluna crescer para um tamanho maior que o espaço disponível na linha, a linha deve ser movida para outro lugar na página, ou parte da linha deve ser movida para outra pagina. Você pode ver por que é importante especificar um min-size médio apurado quando a tabela é criada.

 

  • NCHAR
    NCHAR armazena qualquer string nativa de letras, números e símbolos. O tipo NCHAR é reconhecido somente quando o Native Language Support (NLS) estiver ativo através da variável de ambiente DBNLS. Quando o NLS estiver ativo, coluna CHAR serão tratadas como NCHAR. Consulte o IBM Informix Guide to SQL para informações adicionais.

 

  • NVARCHAR
    O tipo de dado NVARCHAR armazena qualquer seqüencia nativa de letras, números e símbolos variando o tamanho para um máximo de 255 bytes. O NVARCHAR é reconhecido somente quando o NLS está ativo ajustando a variável de ambiente DBNLS.

 

  • LVARCHAR
    A partir da versão 9.4 colunas de tabelas com o tipo de dado LVARCHAR podem chegar ao tamanho de 32,739 bytes, aumentando a capacidade de armazenamento do servidor.

 

Tipo de Dado Numérico

  • INTEGER
    Números entre –2.147.483.647 a +2.147.483.647, ocupa 4 bytes
  • SMALLINT
    Números entre –32.767 a +32.767, ocupa 2 bytes
  • FLOAT
    Números com ponto flutuante, precisão dupla, ocupa 8 bytes
  • SMALLFLOAT
    Número com ponto flutuante, precisão simples, ocupa 4 bytes
  • DECIMAL / MONEY
    Designação de precisão e escala até 32 dígitos significativos
    se a escala é impar, ocupa (precisão + 4) /2
    se a escala é par, ocupa (precisão + 3) /2

Os cinco tipos de dados numéricos são discutidos abaixo:

  • INTEGER – engloba números de –2.147.483.647 até +2.147.483.647. Um Integer ocupa 4  bytes de espaço em disco.
  • SMALLINT – engloba números de –32.767 até +32.767. Um Smallint ocupa 2 bytes de espaço em disco. Os 2 bytes economizados não é tão significante em tabelas pequenas, mas pode fazer uma diferença substancial em grandes tabelas. Você sempre pode converter um Smallint para um Integer sem perda de dados.
  • FLOAT – armazena números binários com ponto flutuante com até 16 dígitos (dupla precisão). O Float corresponde ao tipo double em C. Uma coluna do tipo de dado Float geralmente armazena números científicos que só pode ser calculado com valores aproximados. O Float ocupa 8 bytes de espaço em disco.
  • SMALLFLOAT – armazena números binários com ponto flutuante com até 8 dígitos (precisão simples). Um Smallfloat corresponde ao tipo float em C. Ele também armazena números que só podem ser calculados com valores aproximados. Um  Smallfloat utiliza 4 bytes de espaço em disco.
    Pelo fato dos números com ponto flutuante reterem somente seus dígitos mais significativos, o numero que você digita neste tipo de coluna e o numero que é armazenado no seu banco de dados podem diferir ligeiramente, dependendo de como seu computador armazena números de ponto flutuante internamente. Esta diferença ocorre quando um valor tiver mais dígitos que o número de ponto flutuante pode armazenar. O valor é armazenado em sua forma aproximada com os dígitos menos significativos tratados como zeros.
  • DECIMAL/MONEY – armazena números com o numero de dígitos especificado pelo usuário. Você pode especificar até 32 dígitos significativos. A faixa de números que você pode armazenar é de 10^-130 até 10^124. Note, contudo, que só 32 dígitos são significativos.

    O numero DECIMAL pode ser formatado com uma determinada precisão (precision) e escala (scale).
    • Precisão é o numero total de dígitos.
    • Escala é o numero de dígitos à direita do ponto decimal.
    Uma Coluna DECIMAL com uma definição (5,2) armazena um número de cinco dígitos com três dígitos antes do ponto decimal e dois dígitos apos o ponto decimal.
    O numero de bytes que são necessários para armazenar um valor DECIMAL pode ser calculado com as seguintes fórmulas:

    se a escala é impar -- N=(precisão+4)/2

    se a escala é par – N=(precisão+3)/2

    A precisão e escala default para DECIMAL é (16,0).

    O tipo de dado MONEY é sempre tratado como um numero decimal. A precisão e escala default para MONEY é (16,2).
    O formato de exibição para o tipo de dado MONEY pode ser alterado com a variável de ambiente DBMONEY.

FLOAT ou DECIMAL?

As vantagens do uso de dados DECIMAL ao invés de dados FLOAT são:

  • O DECIMAL permite maior precisão (32) sobre o FLOAT (8 ou 16).
  • Os Valores decimais são arredondados ao invés de serem truncados.
  • A precisão disponível do FLOAT pode diferir de uma máquina para  a outra, os quais podem ter algumas ramificações ao transferir dados por uma rede.

SERIAL

Colunas do tipo SERIAL contem números que são associados a cada linha da tabela em ordem seqüencial pelo sistema. Eles são armazenados como INTEGERS. Quando uma nova linha é inserida, a coluna serial é associada ao próximo numero na seqüencia. O numero inicial default é 1 (um), e o maior numero serial que pode ser associado é superior de 2.1 bilhões.

O tipo SERIAL associa valores em ordem seqüencial, mas não assegura a unicidade automaticamente. O próprio servidor de banco de dados não nomeará  um valor automaticamente. O próprio servidor de banco de dados não nomeará um valor duplicado para uma coluna serial, mas uma aplicação pode potencialmente inserir uma linha com um valor SERIAL duplicado. Para assegurar que valores únicos existem um uma coluna serial, crie a coluna com uma constraint do tipo UNIQUE, um índice único, ou uma constraint primary key.

Quando usar o SERIAL

Colunas do tipo SERIAL criam excelentes chaves primarias por causa de seu tamanho pequeno e potencial de unicidade. Só uma coluna SERIAL pode ser especificada em uma tabela.

Numero inicial.
Se o numero inicial for 100, a primeira linha a ser inserida será associada com o valor 100.

Quando uma ou mais linhas são excluídas, os dados são removidos, mas os valores seriais continuarão aumentando. Isto é, quando uma nova linha é acrescentada, ela será associada com o próximo numero da seqüencia. O numero SERIAL não pode ser reutilizado sem uma programação especial.

O tipo de dado SERIAL pode ser usado para armazenar números de identificação como numero de cliente e numero de pedido. Uma coluna SERIAL ocupa 4 bytes.

DATE, DATETIME e INTERVAL

  • DATE – O tipo de dado DATE é um INTEGER que representa o numero de dias desde 31 de dezembro de 1899. 1º de janeiro de 1990 é o dia 1. O tipo de dado DATE ocupa 4 bytes de espaço em disco.
    Uma coluna DATE é especificada em programas, formulários e SQL no seguinte formato padrão: mm/dd/yyyy
    • mm é o mês (1-12)
    • dd é o dia do mês (1-31)
    • yyyy é o ano (0001-9999)

      Você pode mudar o formato padrão através da variável de ambiente DBDATE.
  • DATETIME – DATETIME é uma evolução em cima do tipo DATE, onde um ponto no tempo é selecionável, isto é, podem ser definidos dados que armazenem pontos do tempo com granularidade de um ano até uma fração de segundo.

    A faixa de valores para cada campo DATATIME é:

    ANO  (D.C) 1 até 9999
    MES 1 a 12
    DIA 1 até 28,29,30 ou 31
    HORA 0 (meia-noite) até 23
    MINUTO 0 a 59
    SEGUNDO 0 a 59
    FRACTION(n) onde n são 1-5 dígitos significantes (default 3)
  • INTERVAL – é usado para armazenar valores que representam uma fatia de tempo. Um tipo de dados INTERVAL pode expressar fatias de tempo tão grandes quanto 9,999 anos e 11 meses, ou tão pequenos quanto uma fração de segundo.
    Tipo de dados INTERVAL não podem contar meses e dias. Isto é devido ao fato de o numero de dias por mês ser variável: Maio tem 31 dias, enquanto Setembro tem 30. O numero de dias em um mês também ode variar com o ano: ano bissexto.
    Por causa desta necessidades peculiares em calendários, ANSI divide o tipo INTERVAL em duas classes: intervalo de ano-mês e intervalo de dia-hora.

    Classes de intervalo de Ano-Mês são:
    - Anos (YEARS)
    - Meses (MONTHS)

    Classes de intervalo Dia-Hora são:
    - Dias (DAYS)
    - Horas (HOURS)
    - Minutos (MINUTES)
    - Segundos (SECONDS)
    - Frações de Segundos (FRACTIONS)

    Calcule o espaço ocupado por tipo de dados DATETIME e INTERVAL com o seguinte:

    Numero total de dígitos de todos os campos / 2 +1

DBCENTURY

A partir da versão 7.2 do Informix a variável de ambiente DBCENTURY permite a seleção do século apropriado para DATE e DATETIME com  dois dígitos no ano.

Valores aceitáveis para DBCENTURY são: P, F, C ou R.

P Passado. O ano é ampliado com ambos os séculos: atual e passado. A data mais próxima anterior da data de hoje é escolhida.
F Futuro. O ano é ampliado com ambos os séculos: atual e futuro. A data mais próxima após a data de hoje é escolhida.
C Closest. (o mais próximo) São usados o séculos: passado, presente e próximos séculos para ampliar o valor do ano. A data mais próxima à data de hoje é usada.
R Presente. O século atual é usado para ampliar o valor do ano.

O valor default da variável DBCENTURY é R.

Quando o valor de DBCENTURY é configurado como P ou F e a data de hoje é digitada, o século será o passado ou futuro respectivamente. O século atual será usado quando a palavra chave TODAY substituir a data de hoje, desde que TODAY use ano de 4 dígitos.

BINARY LARGE OBJECT – BLOB

Binary Large Objects, BLOBs, são streams de bytes de valor e tamanho arbitrários. Um BLOB pode ser uma imagem digitalizada ou som, ou um contrato legal. Um BLOB pode ser qualquer conjunto arbitrário de bytes para qualquer propósito.
Qualquer coisa que você pode armazenar no sistema de arquivo do computador você pode armazenar em um BLOB.
Informix permite que um BLOB seja armazenado com uma coluna dentro de um banco de dados. O limite teórico de seu tamanho é superior a 2.1 Bilhões de bytes. Este tamanho está baseado no maior valor que pode ser mantido em um inteiro de 4 bytes. 56 bytes de espaço são reservados na linha para informações gerais do BLOB. o BLOB em si armazenado em páginas separadas do resto da linha.

TEXT vs. BYTE

Existem dois tipos de BLOB:

  • TEXT – Um objeto de dados tipo TEXT é restrito para uma combinação de texto ASCII printable e caracteres de controle Ctrl-i, Ctrl-j e Ctrl-l. Exemplos de dados que podem ser armazenados em uma coluna TEXT:
    • Notas de texto
    • Especificações de engenharia
    • Arquivos de código fonte de programa
  • BYTE – O tipo BYTE pode armazenar qualquer tipo de dado binário como:
    • Planilhas eletrônicas
    • Módulos de programas
    • Imagens digitalizadas, por exemplo: fotografias e desenhos.
    • Arquivos de voz.

O tipo BYTE é um stream não identificado. O Informix só sabe o tamanho e a localização de um BLOB. Outros programas pode ser chamados para mostras a informação de um BLOB.

CLOB – Armazena texto de objetos grandes em um formato que suporte acesso randômico (mais inteligente do que o BLOB).

segunda-feira, 2 de agosto de 2010

Introdução à Administração de Banco de Dados

Um sistema IBM Informix:

Um sistema de gerenciamento do banco de dados IBM Informix é composto por processos do servidor de banco de dados, a memoria compartilhada (shared memory) que é utilizada pelo sistema, e o espaço em disco que é usado pelo sistema para armazenar os dados que estão sendo gerenciados.

Servidor de Banco de Dados:

O servidor de banco de dados (Database Server) é o programa que gerencia o conteúdo do banco de dados como esta armazenado em disco. O servidor de banco de dados sabe como as tabelas, linhas e colunas estão organizadas na unidade física de armazenamento de dados. O Servidor de banco de dados também interpreta e executa todos os comandos SQL.

Instância

Uma instância informix é um processo do servidor de banco de dados, junto com a memória compartilhada e o espaço em disco que são gerenciados pelos processos do servidor. Pode haver múltiplas instâncias em uma mesma maquina. Por exemplo, pode haver uma instância para desenvolvimento e uma instância para produção ou uma instância para testes.

Para acessar uma instância Informix, você precisa configurar as seguintes variáveis de ambiente:

  • INFORMIXDIR - precisa ser configurada com um path (caminho) completo onde residem os arquivos do Informix;
  • PATH - deve incluir o path completo do diretório que contêm os programas executáveis do Informix (normalmente $INFORMIXDIR/bin em um sistema UNIX);
  • INFORMIXSERVER - deve estar configurado para o nome do Servidor de Banco de Dados Informix (instância) que você deseja acessar.

Essas variáveis de ambiente podem ser configuradas automaticamente pela sua sessão quando você efetua um login ou configurada diretamente no prompt do sistema operacional.

Administração de Banco de Dados

O administrador de um banco de dados tem o papel de gerenciar com sucesso a implantação e o bom funcionamento dos Bancos de Dados IDS.

A administração de banco de dados envolve:

  • Criação do banco de dados e tabelas;
  • Segurança;
  • Assegurar a Integridade de dados;
  • Gerenciar concorrência;
  • Criação de índices;
  • Otimização do acesso aos dados.

Há muitas decisões que devem ser tomadas pelo Administrador do Banco de Dados antes de bancos e tabelas serem criados. Algumas dessas decisões são:

  • Definir a localização do banco de dados dentro do IDS;
  • Definir se o banco de dados registrará as atividades transacionais (log);
  • Seleção dos tipos de dados a serem usadas nas tabelas;
  • Criação de tabelas fragmentadas ou não-fragmentadas;
  • Definir a localização das tabelas dentro do IDS;
  • Alocação do espaço em disco na forma extents;
  • Seleção do modo de lock na tabela na gerencia de concorrência;

Há vários métodos de assegurar a integridade dos dados:

  • O Informix Dynamic Server permite que o administrador do banco de dados conceda ou restrinja os privilégios de acesso em nível de banco de dados, tabelas e colunas;
  • O DBA pode criar views ou uma janela para os dados na perspectiva do usuário;
  • Integridade referencial é utilizada para reforçar o relacionamento entre as tabelas;
  • Integridade da entidade (tabela) é reforçada pelo uso de chaves primarias (primary keys) que identificam a unicidade de cada linha em uma tabela;
  • Integridade semântica reforça os tipos de dados valores default.

Um DBA deve controlar a concorrência em um ambiente multiusuário. Isto envolve influenciar como os dados são lidos e acessados pelos usuários:

  • Concorrência de leitura (Read Concurrency) envolve como os dados são selecionados no banco de dados;
  • Concorrência de atualização (Update concurrency) envolve como os dados são inseridos, alterados e excluídos em um banco.

Controle de Concorrência é reforçado no IDS com o uso de níveis de isolamento e locks.

A administração de bancos de dados também inclui assegurar que os usuários possam acessar e atualizar informações da forma mais rápida possível. O otimizador de querys do IDS é responsável pela escolha do caminho mais rápido e eficiente no acesso aos dados. Ele examina índices e a distribuição dos dados nas tabelas, e seleciona o melhor caminho por um algoritmo baseado no custo deste acesso.

Estas são as tarefas do DBA:

  • Certificar-se de que os índices das tabelas sejam criados para ter a melhor performance;
  • Manter as estatísticas atualizadas para o otimizador de querys;
  • Criar a distribuição de dados (data distributions) necessária para auxiliar o otimizador a tomar decisões.