Tutorial Parte 3 - Montando uma base de teste

Versão para impressãoEnviar para amigoVersão PDF

Agora que já temos uma instancia em funcionamento, aqui vou colocar uma pequena demonstração de como criar uma pequena base de teste e já até demonstrar alguns recursos e modo de trabalho com o Informix.

  1. Base de demonstração do Informix
  2. O que você precisa saber antes de começar
    1. Como acessar o Informix para executar SQLs?
    2. Quem pode criar um banco de dados?
    3. Qual será a lingua para codificação dos caracteres utilizada no banco de dados?
    4. Informações necessárias para criar um banco de dados
    5. Quais dados serão carregados?
  3. Definindo as variáveis de ambiente
  4. Criando a base de teste
    1. Base de dados
    2. Gerando os dados
    3. Prevendo o espaço utilizado pela tabela
    4. Criando a tabela
    5. Carregando a tabela
    6. Atualizando as estatísticas
  5. Alterando a estrutura da tabela
  6. Gerar o DDL de uma tabela/banco de dados
  7. Pegar informações de uma tabela

Base de demonstração do Informix


Com a instalação do Informix, já vem um banco de dados de demonstração , porém não vou mostrar como instalar porque no Information Center (Manual "Db-access User Guide") já possui bem detalhado como faze-lo, além de praticamente todo o processo ser automatizado.
Também não pretendo utilizar este banco devido ser muito pequeno e em alguns testes é interessante ter uma quantidade razoável de dados para identificar mais facil problemas com configurações, performance , enfim o comportamento do banco.
Mas nada impede que você o utilize , ele possui uma boa gama de variedade de recursos para testar.

O que você precisa saber antes de começar


Como acessar o Informix para executar SQLs?


O acesso ao Informix para execução dos SQLs (DDL, DML) pode ser feito através de uma aplicação cliente com conexão ODBC em uma maquina windows, através do utilitário dbaccess que já vem com o Informix (seu fucionamento é no modo caractere) ou através de utilitários de terceiros como o SQLCMD que é como uma versão avançada do dbaccess.
Irei utilizar o dbaccess pois é a ferramenta nativa do banco e é facil a sua utilização. Mas irei utiliza-la no modo não-interativo, porém nada impede que você o utilize no modo interativo até porque sua interface é bem intuitiva.
Para mais detalhes sobre o dbaccess veja este artigo .

Quem pode criar um banco de dados?


Na configuração padrão qualquer usuário pode criar um banco de dados na instancia, isso pode ser limitado através do arquivo de configuração ONCONFIG parametro DBCREATE_PERMISSION. Aqui não irei me preocupar com isso e irei utilizar o usuário informix mesmo.

Qual será a lingua para codificação dos caracteres utilizada no banco de dados?


Esta informação é de extrema importancia porque uma vez criado o banco de dados não é possível mais alterar seu code set. Para informações mais detalhadas sobre locale/GLS leia estes artigos.
Aqui já irei utilizar o code page no nosso português brasileiro (pt_BR.819).

Informações necessárias para criar um banco de dados


Para criar um banco de dados é preciso saber antecipadamente duas coisas: em qual dbspace este banco será criado e qual o modo de log será utilizado.
  • Qual dbspace utilizar? Esta informação é muito importante para ambientes em que você não pretende realizar muitas manutenções posteriormente. Uma vez que um banco é criado no dbspace X não há como trocar, para isso é necessário excluir o banco e recria-lo no outro dbspace (e consequentemente todos os seus dados).
  • Qual modo de log utilizar? Existe quatro opções: ANSI, No-Log, Un-Buffered e Buffered log.
    Buffered
    Define que o banco irá permitir transações (begin/commit/rollback) e que os log de transação serão "buferizados" antes de ser enviados para o disco. Para ambientes com alto volume OLTP pode ajudar na performance mas comprometer na integridade em caso de "crash".
    Un-bufered
    É similar ao Buffered, com uma unica diferença onde os dados do log não são "buferizados" eles são enviados para o disco (flush) assim que o dado é confirmado (commit) , diminuindo na performance porém ganhando na segurança e integridade dos dados.
    No-log
    Não deixa que o banco permita transações (begin/commit/rollback), onde cada interação com o banco é unica , assim também não é gerado log, aumentando na performance porém perdendo recursos transacionais para a aplicação e possibilidade de recovery dos logs em caso de "crash".
    ANSI
    Irá definir o banco de dados com padrão ANSI e possuirá todas as limitações que este padrão trabalha. Na parte de log ele irá trabalhar similar ao modo Un-Buffered.

Quais dados serão carregados?


Para gerar os dados minha solução foi o file system da minha maquina. Assim consegui gerar uma massa de dados consideravel (260 mil registros, 350 MB).
Para criar a massa de dados utilizei o comando find do linux, nele utilizei vários parametros , gerando várias propriedades de cada arquivo. Caso você esteja utilizando windows e possuir o CygWin instalado, acredito que este comando também deva funcionar (mas não testei).
O comando para gerar os dados está na sequencia abaixo.

Definindo as variáveis de ambiente


Nas partes anteriores do tutorial definimos manualmente as variáveis de ambiente para poder ter acesso a instancia do Informix. Este processo é bem chato se for ficar repetindo cada vez que se abre uma shell. Decidi compartilhar com vocês a shell que escrevi para facilitar esse procedimento. Mas para não misturar com este tutorial gerei outro artigo que trata apenas dela, leia sobre ele aqui
# Quando criado a shell com as variaveis de ambiente , basta executa-la:
$ . env.idstitan
      INFORMIXSERVER idstitan
         INFORMIXDIR /dados/IBM/ids1150uc4de
    INFORMIXSQLHOSTS /dados/IBM/ids1150uc4de/etc/sqlhosts.idstitan
            ONCONFIG onconfig.idstitan
           DB_LOCALE pt_BR.8859-1
       CLIENT_LOCALE pt_BR.8859-1
       SERVER_LOCALE pt_BR.8859-1
      IFX_DIRTY_WAIT 300
    INFORMIXCONRETRY 3
     INFORMIXCONTIME 10
     LD_LIBRARY_PATH /dados/IBM/csdk350uc4/lib:/dados/IBM/csdk350uc4/lib/esql:/dados/IBM/ids1150uc4de/lib:/dados/IBM/ids1150uc4de/lib/esql:::
                PATH /dados/IBM/ids1150uc4de/bin:/home/informix/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/home/informix/bin:/home/informix/util
                TERM xterm
            TERMINFO /usr/share/terminfo
             TERMCAP /dados/IBM/ids1150uc4de/etc/termcap
        INFORMIXTERM terminfo
         PSORT_NPROC
        PSORT_DBTEMP
         DBSPACETEMP
           DBUPSPACE
        FET_BUF_SIZE
              OPTMSG
              OPTOFC
           SQLCMDLOG /home/informix/.sqlcmdlog
           TRACECKPT

Criando a base de teste

Base de dados


O banco de dados que iremos criar tera o nome myfs_db (abreviação de My FileSystem), mas pode utilizar outro nome se desejar. Iremos criar este banco de dados no dbspace dados1 e seu log será buffered.
# Defino as variaveis de ambiente para acesso ao banco
$ . env.idstitan

# Crio efetivamente o banco de dados com o comando CREATE DATABASE
$ echo "CREATE DATABASE myfs_db IN dados1 WITH BUFFERED LOG;" | dbaccess
Database created.
Database closed.

# Aqui já podemos verificar na tabela de sistema sysdatabases algumas propriedades
# do banco: que possui log, é buffered, data de criação , seu partnum , quem é o dono, etc.
$ echo "select * from sysdatabases where name ='myfs_db'" | dbaccess sysmaster
Database selected.

name         myfs_db
partnum      5242882
owner        informix
created      17/06/09
is_logging   1
is_buff_log  1
is_ansi      0
is_nls       1
flags        -12269

1 row(s) retrieved.
Database closed.

Gerando os dados


Para gerar os dados , com o usuário root do linux utilizei os comandos abaixo:
# Quebro o find com vários -printf apenas para ficar mais facil a leitura
# Para entender o que é cada parâmetro , veja o "man find" ou a estrutura da tabela
# que iremos carregar estes dados.
# Utilizo o sed para corrigir a fração de segundos, caso contrario irá
# ocorrer erro na carga do Informix
# find / -printf "%h|%f|%p|%l|%m|%M|%F|%y|%Y|%u|%g|%U|" \
   -printf "%G|%s|%i|%AY-%Am-%Ad %AT|%CY-%Cm-%Cd %CT|" \
   -printf "%TY-%Tm-%Td %TT|%D|\n" 2>/dev/null | \
   sed -e "s,\.[0-9]\{10\},\.0,g"  > /tmp/dados.unl

# Verifica tamanho do arquivo gerado e quantas linhas 
# ls -oh /tmp/dados.unl
-rw-r----- 1 root 57M 2009-06-17 14:06 /tmp/dados.unl
# wc -l /tmp/dados.unl
261283 /tmp/dados.unl

# Por ter sido gerado com o usuário root é preciso acertar a
# permissão de leitura 
# chmod 666 /tmp/dados.unl

# Aqui verficamos as primeiras linhas geradas:
# head  /tmp/dados.unl
|/|/||755|drwxr-xr-x|ext2|d|d|root|root|0|0|4096|2|2009-04-04 21:12:51.0|2009-06-17 09:10:26.0|2009-06-17 09:10:26.0|2049|
|lost+found|/lost+found||700|drwx------|ext2|d|d|root|root|0|0|16384|11|2009-03-06 10:04:24.0|2009-03-06 10:04:24.0|2009-03-06 10:04:24.0|2049|
|etc|/etc||755|drwxr-xr-x|ext2|d|d|root|root|0|0|8192|229377|2009-04-04 18:10:44.0|2009-06-17 12:28:43.0|2009-06-17 12:28:43.0|2049|
/etc|fstab|/etc/fstab||644|-rw-r--r--|ext2|f|f|root|root|0|0|1343|231216|2009-06-17 09:27:55.0|2009-06-16 22:03:40.0|2009-06-16 22:03:40.0|2049|
/etc|mtab|/etc/mtab||644|-rw-r--r--|ext2|f|f|root|root|0|0|578|232433|2009-06-17 12:28:43.0|2009-06-17 12:28:43.0|2009-06-1712:28:43.0|2049|
/etc|zypp|/etc/zypp||755|drwxr-xr-x|ext2|d|d|root|root|0|0|4096|229380|2009-06-01 20:33:09.0|2009-06-11 14:15:41.0|2009-06-11 14:15:41.0|2049|
/etc/zypp|systemCheck|/etc/zypp/systemCheck||644|-rw-r--r--|ext2|f|f|root|root|0|0|360|230260|2009-05-28 20:26:55.0|2009-06-11 14:15:41.0|2009-05-28 20:26:55.0|2049|
/etc/zypp|zypp.conf|/etc/zypp/zypp.conf||644|-rw-r--r--|ext2|f|f|root|root|0|0|7255|230853|2009-05-28 20:26:55.0|2009-06-11 14:15:41.0|2009-05-28 20:26:55.0|2049|
/etc/zypp|repos.d|/etc/zypp/repos.d||755|drwxr-xr-x|ext2|d|d|root|root|0|0|4096|230867|2009-06-01 20:33:09.0|2009-06-11 14:15:41.0|2009-06-01 20:33:09.0|2049|
/etc/zypp/repos.d|video-cl.repo|/etc/zypp/repos.d/video-cl.repo||644|-rw-r--r--|ext2|f|f|root|root|0|0|131|229540|2009-03-1417:30:21.0|2009-05-07 16:38:37.0|2009-05-07 16:38:37.0|2049|

Prevendo o espaço utilizado pela tabela


A tabela que iremos criar ficou com uma estrutura grande, o que deixei propositalmente. São 18 campos e o tamanho do registro no banco de dados ficou com aproximadamente 1312 bytes.
Todo registro possui um ROWID e este ocupa um espaço de 4 bytes para cada registro, sendo assim ao calcular o espaço alocado por um registro, é necessário considerar estes 4 bytes. Então nosso espaço alocado por registro será 1316 bytes (1312+4).
É muito importante saber o tamanho do registro de uma tabela e se há tipos de dados que podem variar de tamanho (varchar, nvarchar, lvarchar). Este cuidado se deve a perda de espaço que pode ocorrer em disco e requisições de I/O desenecessárias diminuindo drasticamente a performance do banco de dados, além do uso desenecessário de memória.
Com este tamanho de registro , teremos um disperdicio muito grande de espaço em disco se utilizar paginas de 2 Kbyte do dbspace dados1.
Para entender melhor, isso se deve ao fato de que um registro não é quebrado em duas pagina , ele precisa caber por inteiro em uma unica pagina. Assim se o registro tiver 1316 bytes, dois deles irão ocupar 2632 bytes que é bem maior que 2048 de uma pagina. No fim ao seguir a regra, teremos um registro por pagina.
Como já sabemos que cada registro irá ocupar uma pagina inteira e temos a quantidade total de registros, então já podemos calcular quanto espaço esta tabela irá necessitar: 261.283 paginas * 2 KB = 520 MB !
Então vamos recalcular em outro tamanho de pagina para ver em qual deles conseguimos melhor aproveitamento:
  • Pagina 4 Kbytes = 4096 bytes - 28 bytes de overhead = 4068 bytes disponiveis
    4068 / 1316 = 3.1 = 3 registros com um disperdicio de 120 bytes por pagina
  • Pagina 6 Kbytes = 6144 bytes - 28 bytes de overhead = 6116 bytes disponiveis
    6116 / 1316 = 4.6 = 4 registros com um disperdicio de 852 bytes por pagina
  • Pagina 8 Kbytes = 8192 bytes - 28 bytes de overhead = 8164 bytes disponiveis
    8164 / 1316 = 6.2 = 6 registros com um disperdicio de 268 bytes por pagina
  • Pagina 10 Kbytes = 10240 bytes - 28 bytes de overhead = 10212 bytes disponiveis
    10212 / 1316 = 7.7 = 7 registros com um disperdicio de 1000 bytes por pagina
Bom, ainda poderiamos calcular para paginas com tamanho de 12, 14, 16 Kbytes, mas para este exemplo não considero necessário até porque a pagina de 4 Kb demonstrou um bom aproveitamento e também porque é preciso tomar cuidado quando trabalhar com paginas muito grandes, o que pode gerar um uso desencessário de memória e I/O de disco, mesmo se o espaço dentro dela for bem aproveitado.
Agora podemos calcular o tamanho da tabela já que cada pagina terá 3 registros assim: 261.283 / 3 = 87.095 paginas de 4 Kb = 350 MB! Que diferença!!!
Imagine se esta tabela estivesse com 10 milhões de registros e utilizando paginas de 2 KBytes, o estrago que causaria no sistema!

Como criamos apenas dbspaces com paginas de 2 KB irei adicionar um novo dbspace com pagina de 4 KB para a nossa tabela e para isso iremos precisar de pelo menos mais 400 MB de disco já que prevemos que ela irá ocupar 350 MB.
No meu micro eu já consegui mais espaço em disco e irei criar um novo dbspace chamado dados2 com o tamanho de 400 MB.

# A unica diferença deste comando dos que executamos nos outros tutoriais é o
# parametro -k 4 que indica o tamanho da pagina 
$ onspaces -c -d dados2 -k 4 -p /ifmxdados/dados2.ch1 -o 0 -s 400000
Verifying physical disk space, please wait ...
Space successfully added.

** WARNING **  A level 0 archive of Root DBSpace will need to be done.

# Podemos ver o dbspace criado com paginação de 4 KBytes
$ ls -oh /ifmxdados/dados2.ch1
-rw-rw---- 1 informix 391M 2009-06-17 16:41 /ifmxdados/dados2.ch1
$ onstat -d

IBM Informix Dynamic Server Version 11.50.UC4DE -- On-Line -- Up 01:34:48 -- 650228 Kbytes

Dbspaces
address  number   flags      fchunk   nchunks  pgsize   flags    owner    name
5c3b1808 1        0x60001    1        1        2048     N  B     informix rootdbs
5c485230 2        0x60001    2        1        2048     N  B     informix llog
5c485390 3        0x60001    3        1        2048     N  B     informix plog
5c4854f0 4        0x42001    4        1        2048     N TB     informix temp1
5c485650 5        0x60001    5        1        2048     N  B     informix dados1
5d375750 6        0x60001    6        1        4096     N  B     informix dados2
 6 active, 2047 maximum

Chunks
address  chunk/dbs     offset     size       free       bpages     flags pathname
5c3b1968 1      1      0          100000     88795                 PO-B- /ifmxdados/rootdbs.ch1
5c4857b0 2      2      0          40000      4947                  PO-B- /ifmxdados/llog.ch1
5c485988 3      3      0          75000      4947                  PO-B- /ifmxdados/plog.ch1
5c485b60 4      4      0          35000      34947                 PO-B- /ifmxdados/temp1.ch1
5c485d38 5      5      0          75000      0                     PO-B- /ifmxdados/dados1.ch1
5d3758b0 6      6      0          100000     99947                 PO-B- /ifmxdados/dados2.ch1
 6 active, 32766 maximum

Criando a tabela


Salvei o script com a estrutura da tabela no arquivo fs_full.sql e irei executa-lo com o dbaccess.
# Os parametros que utilizei no dbaccess são:
# -a          Define que o dbaccess deverá abortar a execução caso algum erro ocorra
# -e          Para o dbaccess ecoar o script executado no output padrão 
# myfs_db     O banco de dados a conectar
# fs_full.sql Script com os comandos SQL.
$ dbaccess -a -e myfs_db fs_full.sql 
Database selected.

CREATE TABLE fs_full
  (
    diretorio         NCHAR(300),
    nome_arquivo      NCHAR(100) not null ,
    path_nome_arquivo NCHAR(400),
    link_destino      NCHAR(400),
    permissao_octal   SMALLINT,
    permissao_str     NCHAR(10),
    filesystem_armazenado NCHAR(10),
    tipo1             NCHAR(1),
    tipo2             NCHAR(1),
    owner_user        NCHAR(15) not null ,
    owner_group       NCHAR(15) not null ,
    owner_uid         INTEGER not null ,
    owner_gid         INTEGER not null ,
    tamanho_bytes     BIGINT,
    inode             BIGINT,
    ultimo_acesso     DATETIME YEAR TO FRACTION(3),
    ultima_mod_status DATETIME YEAR TO FRACTION(3),
    ultima_mod_dados  DATETIME YEAR TO FRACTION(3),
    device_number     INTEGER
  ) IN dados2 LOCK MODE ROW
;
Table created.

ALTER TABLE fs_full ADD CONSTRAINT (
  CHECK (tipo1 IN ('b' ,'s' ,'f' ,'d' ,'l' ,'c' ,'p' )) CONSTRAINT cns_fsfull_tp1_check,
  CHECK (tipo2 IN ('b' ,'s' ,'f' ,'d' ,'l' ,'c' ,'p' ,'L' ,'N' ,'U' )) CONSTRAINT cns_fsfull_tp2_check )
;
Table altered.
Database closed.

Sobre a estrutura desta tabela, tenho algumas observações e dicas:
  • Estou utilizando o tipo NCHAR ao invés do CHAR para ordenação correda dos dados em caso de realizado SORT no campo.
    Para mais informações sobre esta situações leia os artigos sobre locale/idiomai
  • Não estou estou utilizando campos VARCHAR, LVARCHAR ou NVARCHAR porque avaliei o conteúdo dos dados antes de carrega-lo e não vi necessidade para utilizar campos variaveis e também eles impedem que seja realizado "alter in-place" na tabela, este recurso irei demonstrar ao final do tutorial.
  • O parametro IN dados2 no final do CREATE TABLE define que esta tabela será armazenada no dbspace dados2, independente de qual dbspace o banco de dados myfs_db pertença.
  • O parametro LOCK MODE ROW define que o controle de lock da tabela será por linha/registro. A outra opção é por pagina (PAGE). Os principais motivos de definição deste parametro são concorrência dos dados e alocação de recurso da instancia na maquina.
  • Adicionei constraints apenas para ilustrar como nomea-las , é muito importante ter nomes claros nas constraints porque quando ocorrer algum erro na aplicação ao violar a regra dela , o nome será exibido. Se deixado o nome padrão gerado pelo Informix você terá um certo trabalho para identificar qual constraint gerou o erro.

Carregando a tabela


Para carregar a tabela iremos utilizar o comando mais básico e acessivel do Informix, o LOAD.
Porém é necessário ter alguns cuidados ao realizar grande carga de dados devido todo dado alterado ser logado. Se carregado uma tabela com o log ativo tudo que for inserido nela será copiado no log e tratado como uma transação unica. Se o seu log não for grande o suficiente você terá um erro de "Long Transaction", mas não pense que para resolver basta ter um log grande pois se tiver você pode gerar outros problemas (geração de logs desnecessáriamente).
No meu caso a tabela a ser carregada terá 350 MB, o meu log tem 70 MB então já sei que este problema irá ocorrer:
$ echo "load from /tmp/dados.unl insert into fs_full" | dbaccess -e myfs_db
Database selected.

load from /tmp/dados.unl insert into fs_full

  458: Long transaction aborted. 12204: RSAM error: Long transaction detected.
  847: Error in load file line 33823.
Error in line 3
Near character position 0

Database closed.

Para resolver isso existe três soluções:

  1. Remover o log do banco, transformando ele para um "no-log".
    Porém isto tem efeito sobre todo banco de dados e todos os seus usuários. Se um usuário tentar abrir uma transação com BEGIN WORK, irá retornar erro. Para realizar esta mudança pode-se utilizar os comandos ondblog, ontape ou task/admin (função ALTER LOGMODE).
  2. Remover o log da tabela, transformando a tabela em RAW
    Tabelas RAWs não são logadas, independente do banco de dados que pertençam. Porém existe alguns pré requisitos para que uma tabela seja convertida para RAW, se você não tiver algum deles o banco não irá converte-la.
  3. Aumentar o logical log. Pior de todas as opções e recomendo que nunca deve ser utilizado a não ser que você tenha certeza do que está fazendo e de suas consequencias (problemas de performance, restauração de backup, geração de backup, risco do processo não funcionar,etc).

Na nossa situação o mais facil e rápido será alterar o log da tabela:

$ dbaccess -a -e myfs_db carrega.sql
Database selected.

# Alteramos o tipo da tabela para RAW
ALTER TABLE fs_full TYPE(RAW)
;
Table altered.

# Executamos um truncate na tabela, para zerar qualquer dado já existente
TRUNCATE TABLE fs_full
;
Table truncated.

# Iniciamos a carga na tabela com o comando LOAD,utilizando o delimitador padrão , pipe "|"
LOAD FROM /tmp/dados.unl INSERT INTO fs_full
;
261283 row(s) loaded.

# Voltamos o tipo da tabela de RAW para STANDARD
ALTER TABLE fs_full TYPE(STANDARD)
;
Table altered.
Database closed.

Atualizando as estatísticas


Pronto a tabela está carregada, porém ainda não está pronta para ser utilizada devidamente, um passo muito importante é a atualização das estastisticas . Para mais informações leia este artigo

$ echo "UPDATE STATISTICS MEDIUM" | dbaccess myfs_db
Database selected.

Statistics updated.
Database closed.

Alterando a estrutura da tabela


O Informix possui um recurso muito legal chamado Alter in-place que permite a alteração da estrutura da tabela de modo instantaneo, independente da quantidade de dados existente nela.
Para a utilização deste recurso é necessário cumprir alguns pré-requisitos.
Bom, lembra que a tabela contém 260 mil registros e utiliza 350 MB de disco ,certo?
Que tal adicionamos uma nova coluna nela?
# Aqui executo um ALTER TABLE adicionando uma nova coluna de flag no meio da estrutura 
$ time { echo "ALTER TABLE fs_full add (flag_xyz CHAR(1) DEFAULT '1' BEFORE ultimo_acesso ) ; " | dbaccess myfs_db ; }
Database selected.
Table altered.

Database closed.

real    0m0.668s
user    0m0.024s
sys     0m0.004s

$ echo "SELECT FIRST 1 * FROM fs_full" | dbaccess myfs_db
Database selected.

diretorio
nome_arquivo        /
path_nome_arquivo   /
link_destino
permissao_octal     755
permissao_str       drwxr-xr-x
filesystem_armaze+  ext2
tipo1               d
tipo2               d
owner_user          root
owner_group         root
owner_uid           0
owner_gid           0
tamanho_bytes       4096
inode               2
flag_xyz            1
ultimo_acesso       2009-04-04 21:12:51.000
ultima_mod_status   2009-06-18 15:20:36.000
ultima_mod_dados    2009-06-18 15:20:36.000
device_number       2049

1 row(s) retrieved.
Database closed.

Veja quanto tempo levou para a execução, menos de 1 segundo!

Para outras informações leia este artigo do Vagner Pontes, a explicação dele é muito boa.

Gerar o DDL de uma tabela/banco de dados


Para gerar o esquema, comandos DDL, de uma tabela,procedures, grants, roles, banco de dados e etc deve-se utilzar o comando dbschema.
$ dbschema -d myfs_db -t fs_full

DBSCHEMA Schema Utility       INFORMIX-SQL Version 11.50.UC4DE

{ TABLE "informix".fs_full row size = 1313 number of columns = 20 index size = 0 
              }                                                                  
create table "informix".fs_full                                                  
  (                                                                              
    diretorio nchar(300),                                                        
    nome_arquivo nchar(100) not null ,
    path_nome_arquivo nchar(400),
    link_destino nchar(400),
    permissao_octal smallint,
    permissao_str nchar(10),
    filesystem_armazenado nchar(10),
    tipo1 nchar(1),
    tipo2 nchar(1),
    owner_user nchar(15) not null ,
    owner_group nchar(15) not null ,
    owner_uid integer not null ,
    owner_gid integer not null ,
    tamanho_bytes bigint,
    inode bigint,
    flag_xyz char(1)
        default '1',
    ultimo_acesso datetime year to fraction(3),
    ultima_mod_status datetime year to fraction(3),
    ultima_mod_dados datetime year to fraction(3),
    device_number integer,

    check (tipo1 IN ('b' ,'s' ,'f' ,'d' ,'l' ,'c' ,'p' )) constraint "informix".cns_fsfull_tp1_check,

    check (tipo2 IN ('b' ,'s' ,'f' ,'d' ,'l' ,'c' ,'p' ,'L' ,'N' ,'U' )) constraint
              "informix".cns_fsfull_tp2_check
  );

revoke all on "informix".fs_full from "public" as "informix";

Pegar informações de uma tabela


Utilize o SQL INFO
$ echo "INFO STATUS FOR fs_full" | dbaccess myfs_db
Database selected.

Table Name          fs_full
Owner               informix
Row Size            1313
Number of Rows      260474
Number of Columns   20
Date Created        18/06/09

Database closed.

5
Média: 5 (2 votos)
Sua avaliação: Nenhum

Comentar

O conteúdo deste campo é privado não será exibido ao público.
  • Endereços de páginas de internet e emails viram links automaticamente.
  • Você pode usar tags BBCode no texto.
  • Tags HTML permitidas: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>

Mais informações sobre as opções de formatação

CAPTCHA
Este teste é para bloquear programas automatizados e previnir spams
CAPTCHA de Imagem
Digite o texto exibido na imagem.