segunda-feira, 29 de novembro de 2010

Como utilizar o zypper com o OpenSuSE

Instalando e removendo software

Para instalar um pacote registrado no repositorio use:

mozart:/etc/samba # zypper install samba-doc
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW package is going to be installed:
  samba-doc

1 new package to install.
Overall download size: 13.3 MiB. After the operation, additional 24.2 MiB will be used.
Continue? [y/n/?] (y): y
Retrieving package samba-doc-3.4.3-3.6.1.noarch (1/1), 13.3 MiB (24.2 MiB unpacked)
Retrieving: samba-doc-3.4.3-3.6.1.noarch.rpm [done (82.1 KiB/s)]
Installing: samba-doc-3.4.3-3.6.1 [done]
mozart:/etc/samba #

Para remover um pacote instalado use:

mozart:/etc/samba # zypper remove augeas-lenses
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following package is going to be REMOVED:
  augeas-lenses

1 package to remove.
After the operation, 151.0 KiB will be freed.
Continue? [y/n/?] (y): y
Removing augeas-lenses-0.5.0-2.2 [done]
There are some running programs that use files deleted by recent upgrade. You may wish to restart some of them. Run 'zypper ps' to list these programs.
mozart:/etc/samba #

Atualizando Pacotes:

Há duas maneiras de atualizar os pacotes com zypper. Para atualizar todas as correções oficiais, rode o comando abaixo:

mozart:/etc/samba # zypper update

nesse caso, todos os patches que estão disponiveis no repositorio serao verificados e instalados, se necessario.

Para à atualização de um único pacote, rode o comando abaixo:

mozart:/etc/samba # zypper update aaa_base
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following package is going to be upgraded:
  aaa_base

1 package to upgrade.
Overall download size: 148.0 KiB. No additional space will be used or freed after the operation.
Continue? [y/n/?] (y): y

Retrieving package aaa_base-11.2-43.46.1.x86_64 (1/1), 148.0 KiB (319.0 KiB unpacked)
Retrieving delta: ./rpm/x86_64/aaa_base-11.2-43.45.1_43.46.1.x86_64.delta.rpm, 93.0 KiB
Retrieving: aaa_base-11.2-43.45.1_43.46.1.x86_64.delta.rpm [done (8.9 KiB/s)]
Applying delta: ./aaa_base-11.2-43.45.1_43.46.1.x86_64.delta.rpm [done]
Installing: aaa_base-11.2-43.46.1 [done]
Additional rpm output:
insserv: warning: script 'K01bilogix' missing LSB tags and overrides
insserv: warning: script 'bilogix' missing LSB tags and overrides
Updating etc/sysconfig/language...
Updating etc/sysconfig/backup...
Updating etc/sysconfig/boot...
Updating etc/sysconfig/kernel...
Updating etc/sysconfig/suseconfig...
Updating etc/sysconfig/clock...
Updating etc/sysconfig/proxy...
Updating etc/sysconfig/windowmanager...
Updating etc/sysconfig/sysctl...
Updating etc/sysconfig/cron...
Updating etc/sysconfig/news...
Updating etc/sysconfig/shutdown...
Updating etc/passwd...unchanged
Updating etc/group...unchanged
Updating etc/shadow...unchanged
insserv: warning: script 'K01bilogix' missing LSB tags and overrides
insserv: warning: script 'bilogix' missing LSB tags and overrides


There are some running programs that use files deleted by recent upgrade. You may wish to restart some of them. Run 'zypper ps' to list these programs.

mozart:/etc/samba #

Para verificar os pacotes de atualizacao no repositorio registrado, verifique com o comando abaixo:

mozart:/etc/samba # zypper list-updates
Loading repository data...
Reading installed packages...
S | Repository           | Name                                | Current Version | Available Version | Arch
--+----------------------+-------------------------------------+-----------------+-------------------+-------
v | openSUSE-11.2-Update | aria2                               | 1.5.2-2.3.1     | 1.9.3-0.1.1       | x86_64
v | openSUSE-11.2-Update | autofs                             | 5.0.4-6.1       | 5.0.4-6.2.1       | x86_64
v | openSUSE-11.2-Update | bash                               | 4.0-18.3        | 4.0-18.4.1        | x86_64
v | openSUSE-11.2-Update | bash-doc                         | 4.0-18.3        | 4.0-18.4.1        | x86_64
v | openSUSE-11.2-Update | bzip2                               | 1.0.5-36.6      | 1.0.5-36.7.1      | x86_64
v | openSUSE-11.2-Update | cifs-mount                       | 3.4.2-1.1.3.1   | 3.4.3-3.6.1       | x86_64
v | openSUSE-11.2-Update | cpio                                | 2.10-4.2        | 2.10-4.3.1        | x86_64
v | openSUSE-11.2-Update | cron                                | 4.1-195.196.1   | 4.1-195.197.1     | x86_64
v | openSUSE-11.2-Update | cups                                | 1.3.11-4.1      | 1.3.11-4.5.1      | x86_64
v | openSUSE-11.2-Update | cups-client                       | 1.3.11-4.1      | 1.3.11-4.5.1      | x86_64
v | openSUSE-11.2-Update | cups-libs                          | 1.3.11-4.1      | 1.3.11-4.5.1      | x86_64
v | openSUSE-11.2-Update | desktop-translations           | 11.2-11.13.1    | 11.2-11.16.1      | noarch
v | openSUSE-11.2-Update | device-mapper                   | 1.02.31-11.2    | 1.02.31-11.3.1    | x86_64
v | openSUSE-11.2-Update | dhcpcd                             | 3.2.3-47.2      | 3.2.3-47.4.1      | x86_64
v | openSUSE-11.2-Update | ethtool                             | 6-79.2          | 6-79.3.1          | x86_64
v | openSUSE-11.2-Update | findutils                            | 4.4.0-46.2      | 4.4.0-46.3.1      | x86_64
v | openSUSE-11.2-Update | freetype2                          | 2.3.9-2.2       | 2.3.9-2.4.1       | x86_64

terça-feira, 23 de novembro de 2010

onstat–b (Mostra informações do buffer em uso)

Use a opção onstat -b para exibir informações do buffers que estão em uso, incluindo o número total de páginas residentes na área de buffer.

Sintaxe:

informix@isis:~> onstat –b

O número máximo de buffers disponíveis especificado no parâmetro de configuração BUFFERPOOL do ONCONFIG.

O comando onstat -b também fornece informações resumidas dos número de buffers modificados, o número total de páginas residentes na área de buffer, o numero total de buffer disponível, o numero total de hash buckets disponíveis e o tamanho do buffer em bytes (tamanho da pagina).

informix@isis:~> onstat -b

IBM Informix Dynamic Server Version 11.50.FC6WE -- On-Line -- Up 14 days 06:16:07 -- 303184 Kbytes

Buffers
address           userthread        flgs pagenum          memaddr           nslots pgflgs xflgs owner             waitlist

Buffer pool page size: 2048
1 modified, 50000 total, 65536 hash buckets, 2048 buffer size

informix@isis:~>

Nota: Informações geradas pelo onstat –b são paginas sendo modificadas por uma thread. Não confundir com paginas usadas.

O tamanho da pagina é a menor unidade de I/O no sistema e determinada no momento da transferência.

Atualmente, o campo userthread é sempre 0.

O numero de hash buckets é a menor potencia de dois no buffers.

Buffer hash buckets aponta para o buffer headers. Cada buffer header contem um ponteiro para um pagina no buffer que mantem informações sobre o status de paginas lidas e escritas para a pagina de buffer. Haverá um cabeçalho de buffer para cada reserva na área de buffer.

As chamadas são feitas para determinar a validade das informações contidas na página do buffer para cada I/O executado.

O número de páginas modificadas se torna zero quando o buffer pool é liberado com um checkpoint ou quando as paginas são limpadas.

Cada uma das páginas dentro do buffer pool pode ser exibida ao executar o comando onstat –g dmp com o valor memaddr e o pagesize ( exemplo onstat-g dmp 0xa088000 2048).

Não confundir o bloqueio de uma página da área de buffer com o bloqueio de uma página de banco de dados.

Páginas dentro da área de buffer será fechada e liberada como páginas (de qualquer tipo) que são lidas do disco e colocada no buffer.

quarta-feira, 22 de setembro de 2010

Profissionais Windows x Linha de Comando

Interessante esse tema, para ser sincero nem acho que nem tenho condições de estar escrevendo algum artigo para Windows, pois não conheço quase nada, porem tenho vários colegas de profissão que são profissionais em Windows e trabalham com o Mesmo, só que dar uma ênfase aqui, estou falando de profissionais que trabalham com Servidores Windows.

Pois bem… não é difícil deduzir que sou um profissional especializado no Mundo Unix, HP-UX, Linux, AIX, etc, trabalho com consultoria, a maioria sendo cliente Totvs principalmente aplicado ao sistema Logix, e 99% das consultoria que faço é baseado em sistemas Unix, aconteceu que esses dias um cliente que tem a base em Windows Server me contatou para fazer um serviço em Banco de Dados Informix.

Bom aceitei o desafio a principio somente auxiliando o responsável pelo sistema, e o auxilio foi no sentido de ajudar a criar uma instancia, dbspaces, chunks, etc,… até ai tudo bem, mas ai me deparei com um problema interessante, para entendermos melhor o problema vou explicar como faço no Unix para resolver isso.

Quando se cria a instancia no informix o IDS já cria os logical logs dentro do rootdbs, então geralmente, não sendo uma regra, por questão de organização até e performance a gente cria um dbspace e um chunk somente para o logical log:

# onspaces –a –d llog –p /dblog/llog.000 –o 0 –s 1000106

e no windows não é diferente:

# onspaces –a –d llog –p C:\IFMXDATA\tst\llog.000 –o 0 –s 1000212

muito bem, depois a gente da uma organizada em tudo isso, primeiro criando mais 3 arquivos de logs para o dbspace llog:

# onparams –a –d llog

e para o Windows o mesmo procedimento

depois de criado os 3 logs, então movemos o ponto do logical log e do check point ate os logs que foram criados.

# onmode –l

# onmode –c

muito bem, movidos os ponteiros, entra aqui uma brincadeira em shell script que utilizo muito para simplificar as tarefas, nesse caso para remover os logs do rootdbs

# for i in `seq 6`
do
onparams –d –l $i –y
done

esse comando simplesmente remove os 6 primeiros logical logs que estão no rootdbs, simplifica não…

pois bem…

depois comento isso para o windows,

feito isso no linux, o normal é a gente encher agora o chunk criado para os logs de logs, o comando ja passei acima , porem já pensou um chunk de 500.000 paginas, sendo que cada logical log tem o tamanho de 5000 paginas, a gente teria que executar o comando 100 vezes. é ai que entra a linha de comando novamente:

um exemplo bem simples e rápido

while true
do
onparams –a –d llog
done;

na era que começar a dar a mensagem na console de que o chunk esta cheio, simplesmente aperte o ctrl-c para cancelar a execução do script…

um exemplo mais elaborado

x=1
while [ $x != 0 ]
do
onparams –a –d llog
x=`onstat –d |grep tstlog | awk ‘{print $6}’`
done

esse script já é mais elaborado, na hora que a coluna do onstat free chegar a 0 quer dizer que ja encheu os logs, então o valor do x vai retornar 0 ao while fazendo que o mesmo aborte o código.

magico não , isso é o mundo linux.

Porem retornando ao tema Windows, no atendimento a esse cliente, fiquei pensando e agora como vamos encher o log…

uma maneira seria fazer na unha, seta para cima e enter… ate encher o log ,mas o Windows não? tem como automatizar a tarefa… ? postei em alguns blog essa duvida, e no máximo o que me responderam foi , cria um arquivo .bat e insira um monte de vez o comando e depois rode o arquivo de lote, sinceramente  acho que foi a pior resposta que ouvi até hoje, porem continuei minha pesquisa no google por dias, e não consegui achar a solução desse problema, e também consultei alguns especialistas em plataforma Microsoft.

ontem instalando um servidor windows para teste, fiquei ainda pensando … caramba será que não tem maneira de automatizar isso mesmo?

foi ai que para minha surpresa resolvi digitar um for la no prompt do windows, pode parecer engraçado, mas o windows tem um for, me desculpem os usuários de windows que conhecem, pois eu nao conhecia, e resolvi ler o help do FOR e para minha surpresa, resolvi o primeiro problema…..

sim removi os 6 primeiros logs no windows com o comando FOR olhem só….

FOR /L %i IN (1,1,6) DO onparams –d –l %i –y

magico também, risos.

ai tinha o segundo problema que na verdade já tinha resolvido o segundo o com o primeiro ficando assim:

FOR /L %i IN (1,1,97) DO onparams –a –l llog

problema resolvido, o windows server até que foi interessante nesse caso, resolver um problema via prompt, confesso que para mim foi novidade sim, porem conhecimento adquirido.

Mas gostaria de destacar a não resolução desse problema pelos profissionais do Windows, eles mesmos não conhecem isso, so sabem mexer em mouse? mau costume……

abraços a todos e qualquer duvida estou a disposição.

terça-feira, 21 de setembro de 2010

Códigos de retorno do utilitário onstat

O utilitário onstat exibe um conjunto de códigos de retorno quando você executa o utilitário.

Valor

Descrição

-1 Inicialização GLS local falhou ou IDS não anexou a memória compartilhada
0 Modo de Inicialização
1 Quiescent mode
2 Recovery mode
3

Backup mode

4 Shutdown mode
5 Online mode
6 Abort mode
7 User mode
255

Off-Line mode

segunda-feira, 6 de setembro de 2010

onstat – : Status do Servidor

Todas as saídas onstat inclui um cabeçalho. O comando onstat - exibe apenas o cabeçalho, devolvendo valores que indica o modo do servidor. A primeira parte da saída identifica a versão do Server, a segunda parte identifica o status do server. O status do servidor Informix pode assumir um dos seguintes valores:

  • Initialization

  • Shutting Down

  • Quiescent

  • OnLine

  • Fast Recovery

  • Abort

  • Archive Backup

  • Unknown

  • Read-Only

Adicionalmente, o status do servidor pode ser acompanhada de informações secundárias. O valor (PRIM) ou (SEC) será exibido para os sistemas em sistemas de replicação de dados. (CKPT REQ) aparecerá caso haja necessidade; (CKPT INP) aparecerá se um ponto de verificação está em andamento; e (LONGTX) aparecerá caso esteja tendo um ROLL BACK sendo executado.

E na parte final das informações são fornecidas o tempo que o servidor esta no ar, seguido pelo tamanho total dos segmentos da shared memory (resident + virtual) utilizado pelo servidor em Kbytes. Se o servidor é impedido de realizar qualquer trabalho, a razão é adicionado ao final da linha de status. As possíveis  razões para um sistema de bloqueio são:

  • CKPT Checkpoint
  • LONGTX Long Transaction
  • ARCHIVE Archive Requested Block
  • MEDIA_FAILURE DBSpace being marked down
  • HANG_SYSTEM Server Requested Block
  • DBS_DROP DBSpace is being dropped
  • DDR DDR Synchronization
  • LBU Prevent Log Backups

Sintaxe:

isis:~ # onstat -

(Version--Mode (Type)--(Checkpnt)--Up Uptime--Sh_mem Kbytes)

IBM Informix Dynamic Server Version 11.50.FC6WE -- On-Line -- Up 19 days 03:08:27 -- 1310184 Kbytes

Version:
Nome e a versão do produto

Mode:
É o modo atual

Type:
Se o servidor de banco usa HDR, indica se o servidor é primario ou secundario.
Se o servidor não esta envolvido com HDR, então este campo não contem nada. Se o server é primario então será mostrado o valor P e se for um servidor secundario será exibido o valor S.

Checkpnt:
Se um flag Checkpnt é definido, poderá então ser mostrado mais 2 valores
(CKPT REQ) - Indica que um segmento de usuário solicitou um checkpoint
(CKPT INP) – Indica que um checkpoint esta em progresso. Durante o checkpoint, o acesso é limitado somente para leitura. O Servidor de Banco de Dados não pode escrever ou atualizar dados até que o checkpoint termine.

Uptime:
Indica o tempo que o Servidor de Banco de dados esta rodando.
Se a hora do sistema é alterado manualmente para uma data posterior da inicialização do banco de dados, o tempo de atividade não estará disponível. Nesta situação será exibido essa mensagem: Uptime Unavailable.

Sh_mem:
È o tamanho do banco de dados na Shared Memory, mostrado em kilobytes

sexta-feira, 3 de setembro de 2010

onstat -d: Comando que mostra informações sobre o chunk

 

Use o comando onstat-d para mostrar informações sobre os chunks de cada espaço de armazenamento.

O comando onstat –d fornece uma saída em duas partes. A primeira parte identifica todos os dbspaces numa instancia; a segunda parte identifica todos os chunks associados aos dbspaces da primeira parte.

Sintaxe:

onstat –d

O comando onstat –d fornece uma saída em duas partes. A primeira parte identifica todos os dbspaces numa instancia; a segunda parte identifica todos os chunks associados aos dbspaces da primeira parte.

Usando onstat-d com blobspaces

Se você usar o comando onstat-d em uma instância com chunks blobspace, o servidor de banco de dados exibira a seguinte mensagem:

NOTE: For BLOB chunks, the number of free pages shown is out of date. Run ‘onstat -d update' for current stats.

Para obter estatísticas dos chunks blobspaces atualizadas,  digite o comando onstat –d update. O utilitário onstat atualiza a shared memory com uma contagem exata de páginas livres para cada chunk blobspace.

Waiting for server to update BLOB chunk statistics ...

Exemplo do comando onstat –d:

IBM Informix Dynamic Server Version 11.50.FC6WE -- On-Line -- Up 14 days 04:47:06 -- 1310184 Kbytes
Dbspaces
address
number 
flags
fchunk
nchunks
pgsize
flags
owner
name
4c4cc028
1
0x70001
1
1
2048
N  B
informix
rootdbs
4d53e9d0
2
0x70001
2
1  
2048
N  B
informix
plog
4d53eb68   
3
0x42001
3
1
2048
N TB
informix
tmp1_tst
4d53ed00
4
0x42001
4
1
2048
N TB
informix
tmp2_tst
4d540028
5
0x42001
5
1
2048
N TB
informix
tmp3_tst
4d5401c0
6
0x60001
6
1
2048
N  B
informix
logicallog
4d540358
7
0x60001
7
1
2048
N  B
informix
crm_tst
4d5404f0
8
0x60001
8
4
2048
N  B
informix
logix_tst
8 active, 2047 maximum
Chunks
address
chunk/dbs
offset
size
free
bpages
flags
pathname
4c4cc1c0
1      1
0
150000 
110158
 
P0-B-
/dbtst/dbroots/rootdbs
4d540688
2      2
0
500053
0
 
P0-B-
/tstlog/pyslog/plog
4d540878
3      3
0
250053  
249950
 
P0-B-
/tsttmp/tmp1_tst
4d540a68        
4      4
0
250053  
249950
 
P0-B-
/tsttmp/tmp2_tst
4d540c58        
5      5
0
250053  
249950
 
P0-B-
/tsttmp/tmp3_tst
4d541028        
6      6
0
1500053
0
 
P0-B-
/tstlog/logicallog/llog
4d541218        
7      7
0
1000053
699914
 
P0-B-
/dbtst/crm/crm.01
4d541408        
8      8
0
2000053
116
 
P0-B-
/dbtst/logix/tst.01
4d5415f8        
9      8
0
2000003
90
 
P0-B-
/dbtst/logix/tst.02
4d5417e8        
10     8
0
2000003
542310
 
P0-B-
/dbtst/logix/tst.03
4d5419d8        
11     8
0
2000003
2000000
 
P0-B-
/dbtst/logix/tst.04
11 active, 32766 maximum
NOTE: The values in the “size” and “free” columns for DBspace chunks are
displayed interms of “pgsizes” of the DBspace to which they belong.
Expand chunk capacity mode: always

Descrição dos campos do DBspaces

address
É o endereço do dbspace na shared memory.

number
Número de identificação único do dbspace atribuído na criação.

flags
Valores hexadecimal usado para descrever cada dbspaces. Cada flag individual descreve o status do dbspace usando os seguintes valores hexadecimais:

Valor da Flag Descrição
0x00000000 Mirror não habilitado e dbspace não espelhado
0x00000001 Mirror habilitado e dbspace não espelhado
0x00000002 Mirror habilitado e dbspace espelhado
0x00000004 Mirror do chunk desabilitado
0x00000008 Mirror Recente
0x00000010 Blobspace
0x00000020 Blobspace em mídias removíveis
0x00000040 Blobspace em mídias óticas
0x00000080 Blobspace dropado
0x00000100 Blobspace é ótico STAGEBLOB
0x00000200 DBspace esta sendo recuperado
0x00000400 DBspace totalmente recuperado
0x00000800 Logical Log esta sendo recuperado
0x00001000 Uma tabela na dbspace esta sendo dropada
0x00002000 DBspace temporário
0x00004000 Blobspace esta sendo backupeado
0x00008000 Sbspace
0x00010000 Physical ou logical log alterado
0x00020000 Dbspace ou chunk tables alterado
0x00040000

Dbspace ou blobspace contem large chunk

0x00080000 Chunk nesse dbspace foi renomeado
0x00100000 DBspace temporários utilizados apenas em discos compartilhados em outros servidores.É um dos dbspaces listados no parâmetro ONCONFIG SDS_TEMPDBS.
0x00200000 DBspace temporários utilizados apenas em discos compartilhados em outros servidores. É um dos dbspaces listados no parâmetro ONCONFIG DBSPACETEMP.
0x00400000 O DBspace foi backapeado.

fchunk
É o numero de identificação do primeiro chunk da dbspace

nchunk
É o numero de chunk existente na dbspace

pgsize
É o tamanho da pagina do dbspace em bytes

flags
Usa letras em cada posição para descrever cada dbspace

Posição 1:

Flag Descrição
M Mirror
N Não Mirror

Posição 2:

Flag Descrição
X Mirror criado recente
P physical recuperado aguardando pela recuperação do Logical Log
L Logical esta sendo recuperado
R Sendo recuperado
D Down

Posição 3:

Flag Descrição
B Blobspace
S Sbspace
T DBspace temporária
U SBspace temporária
W DBspace temporário no server primário (Esta flag só é mostrada no server secundário)

Posição 4:

Flag Descrição
B O Dbspace tem chunks maiores que 2GB

Owner
Proprietário do DBspace

Name
Nome do DBspace

Na linha a seguir da lista dos dbspaces:
active: Numero de dbspaces sendo utilizando no momento pela instancia incluindo o rootdbs
Maximum: refere-se ao numero máximo de DBspaces que a instância suporta.

Descrição dos campos dos Chunks

address
É o endereço do chunk

chunk/dbs
É o numero do chunk associado ao numero do dbspace

offset
É o numero do offset do Chunk criado

size
Tamanho do total do chunk, esse numero é em paginas.

free
O número de páginas livres no chunk.
Para um blobspace, indica o números de paginas livres aproximado

bpages
Tamanho do total do chunk em blobpages.

flags
Prove informações de status dos chunks.

Posição 1:

Flag Descrição
P Primário
M Mirror

Posição 2:

Flag Descrição
N Renomeado e requer inicialização ou inconsistente
O Online
D Down
X Mirror criado recentemente
I Inconsistente

 

Posição 3:

Flag Descrição
- DBspace
B Blobspace
S Smart Blobspace

Posição 4:

Flag Descrição
B O chunk tem suporte acima de 2GB

Posição 5:

Flag Descrição
- Não utiliza direct I/O ou os I/O concorrentes estão em cooked
C No AIX ®, usando  I/O concorrendo em cooked
D Direto I/O

pathname
é o caminho dos chunks nos dispositivos físicos.

Na linha abaixo das visualizações dos chunks:
active: Numero de chunk sendo utilizando no momento pela instancia incluindo o rootdbs
Maximum: refere-se ao numero máximo de chunks a instância suporta.

quarta-feira, 1 de setembro de 2010

Comando onstat

O utilitário onstat lê estruturas de memória compartilhada e fornece estatísticas sobre o servidor de banco de dados no momento em que o comando é executado.

Você pode combinar várias opção em um único comando. O utilitário onstat não coloca lock na shared memory para executar o utilitário e não afeta o desempenho

onstat-D:

Imprima ler e gravar informações de página

Mostra informações de leituras e gravação das paginas.

Sintaxe:

onstat –D

Exemplo:

isis:~ # onstat -D

IBM Informix Dynamic Server Version 11.50.FC6WE -- On-Line -- Up 14 days 04:47:06 -- 1310184 Kbytes
Dbspaces
address
number 
flags
fchunk
nchunks
pgsize
flags
owner
name
4c4cc028
1
0x70001
1
1
2048
N  B
informix
rootdbs
4d53e9d0
2
0x70001
2
1  
2048
N  B
informix
plog
4d53eb68   
3
0x42001
3
1
2048
N TB
informix
tmp1_tst
4d53ed00
4
0x42001
4
1
2048
N TB
informix
tmp2_tst
4d540028
5
0x42001
5
1
2048
N TB
informix
tmp3_tst
4d5401c0
6
0x60001
6
1
2048
N  B
informix
logicallog
4d540358
7
0x60001
7
1
2048
N  B
informix
crm_tst
4d5404f0
8
0x60001
8
4
2048
N  B
informix
logix_tst
8 active, 2047 maximum
Chunks
address
chunk/dbs
offset
page Rd
page Wr
pathname
4c4cc1c0
1      1
0
304763  
234297  
/dbtst/dbroots/rootdbs
4d540688
2      2
0
4
794344  
/tstlog/pyslog/plog
4d540878
3      3
0
350420  
381160  
/tsttmp/tmp1_tst
4d540a68        
4      4
0
340538  
373925  
/tsttmp/tmp2_tst
4d540c58        
5      5
0
331212  
384088  
/tsttmp/tmp3_tst
4d541028        
6      6
0
6695    
2341270 
/tstlog/logicallog/llog
4d541218        
7      7
0
19987   
214     
/dbtst/crm/crm.01
4d541408        
8      8
0
1285405 
286704  
/dbtst/logix/tst.01
4d5415f8        
9      8
0
2809998
369856  
/dbtst/logix/tst.02
4d5417e8        
10     8
0
763712  
446188  
/dbtst/logix/tst.03
4d5419d8        
11     8
0
1
0
/dbtst/logix/tst.04
11 active, 32766 maximum
NOTE: The values in the "page Rd" and "page Wr" columns for DBspace chunks
are displayed in terms of system base  page size.
Expanded chunk capacity mode: always

A saída do onstat -D é quase idêntica à saída do onstat –d, com a ressalva de que as colunas size, free and bpages dos chunks são substituidos pelo page Rd e page Wr.

page Rd
É o numero de paginas lidas

page Wr
É o numero de paginas escritas

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;