DBA 101: administrando estruturas de dados do DB2

Entendendo os conceitos de Tablespace, Bufferpool, Extent e Container

Para um DBA, é de fundamental importância compreender a estrutura de armazenamento de dados do DB2 LUW. A configuração adequada dos recursos físicos e lógicos assegura uma boa operação do banco de dados e a otimização da performance. Este artigo examina os componentes básicos desta estrutura e apresenta exemplos práticos de configuração destes componentes.

Wagner Crivelini, DBA DB2 & SQL SERVER, IBM

Wagner CriveliniProfissional certificado IBM IT Specialist Level 2 – Expert, com mais de 15 anos de experiência com tecnologia de bancos de dados, é autor de mais de 50 artigos sobre este tópico, além de participar como colaborador de diversas comunidades, como DB2 on Campus, BigDataUniversity.com, Revista SQL MAGAZINE Brasil, SQLServerCentral.com, podcast DatabaseCast e o blog Banco de Dados & BI. Perfil My Developer Works.



02/Nov/2012

Introdução

Entender os conceitos da estrutura de armazenamento de dados é uma premissa básica para qualquer candidato a administrador de bancos de dados (DBA) do DB2 LUW. Esta estrutura inclui componentes físicos (como containers, extents, páginas de dados e bufferpools) e lógicos (tablespaces, esquemas e tabelas). E é de fundamental importância compreender os relacionamentos entre estes componentes.

Uma configuração adequada desta estrutura de dados garantirá um bom desempenho e performance do DB2 LUW.

Este artigo descreve os principais componentes físicos e lógicos da estrutura de armazenamento de dados do DB2 LUW, mostrando o relacionamento entre eles. Finalmente são apresentados casos comuns do dia-a-dia em que esta estrutura precisa ser atualizada.


Situando o Exemplo

Este artigo foi desenvolvido usando-se uma máquina virtual SUSE LINUX rodando o DB2 Express-C v10.1 32-bit.

Para instruções sobre download e instalação da máquina virtual com DB2 for Linux usando VMWARE, acesse http://www-01.ibm.com/software/data/db2/express/download.html#vmware .

A Figura 01 mostra informações básicas desta máquina virtual.

Figura 1. Apresentação da máquina virtual.
Apresentação da máquina virtual.

Clique aqui para vizualizar a Figura 01 em tamanho maior.


Componentes Lógicos

A seguir uma revisão dos principais componentes lógicos.

Tabela

É o componente lógico mais conhecido da estrutura de dados. Na Wikipédia, a tabela de um banco de dados relacional é descrita como um objeto estruturado definido por um número finito de colunas ou campos que pode receber um número indefinido de linhas ou registros, que representam os dados em si.

De uma forma abstrata, podemos entender a tabela como um molde que só aceita dados que se “encaixam” na estrutura de campos desta tabela. E esta estrutura formal de campos é um requisito do modelo relacional.

Observe que a tabela não diz onde os dados serão armazenados. Diz apenas qual a estrutura dos registros que serão aceitos.

Esquema

Esquema se destina a organizar os diferentes objetos do banco de dados (tabelas, visões, funções, procedimentos armazenados, etc) em “coleções” com base num assunto e/ou proprietário comum. Assim pode-se criar, por exemplo, um esquema RH para objetos de bancos de dados relacionados ao Departamento de Recursos Humanos. Os objetos de bancos de dados, como as tabelas, por exemplo, se associam a um e apenas um esquema.

Analogamente, cada esquema está associado a um único banco de dados.

Espaço de tabela (Tablespace)

É uma camada lógica intermediária que vincula componentes lógicos que armazenam dados (tabelas, visões e índices) com os componentes físicos. Quando definimos um tablespace, informamos ao DB2 em qual recurso físico serão armazenados os dados relativos a uma determinada tabela e qual a alocação de memória será feita para esta tabela.

O conceito de tablespace é muito importante, porque ele associa objetos lógicos aos componentes do hardware em que o DB2 está operando. Por esta razão, é fundamental conhecer as características das tabelas, visões e índices do banco de dados para se desenhar adequadamente os tablespaces que serão usados.


Componentes Físicos

Vejamos agora os componentes físicos.

Contêiner

O contêiner é um dispositivo físico de armazenamento, como um arquivo de dados do sistema operacional, um disco ou um dispositivo (raw device). O tipo de dispositivo será definido pela forma de gerenciamento do espaço, seja ele gerenciado pelo sistema (SMS) ou pelo banco de dados (DMS).

Os contêiners são associados diretamente aos tablespaces.

Página de Dados

É a unidade de espaço em disco onde o DB2 armazena os registros. A quantidade de registros por página depende do tamanho da página de dados (4K, 8K, 16K, 32K) e do tamanho de cada registro. Um registro é gravado obrigatoriamente dentro de uma única página.

Extensão (Extent)

A extensão aloca um espaço contínuo dentro de um contêiner para uso exclusivo por um objeto do banco de dados. A extensão define o número de páginas de dados que são escritas dentro deste espaço alocado.

Buffer (Bufferpool)

É uma área de memória usada para armazenar dados em cache e reduzir a leitura de discos. Sendo assim, bufferpools ajudam muito na performance do banco de dados. São criados definindo-se o número de páginas de dados armazenadas em cache (exemplo: 1000 páginas) e o tamanho aceito para cada página (exemplo: 4K, 8K, 16K ou 32K). É obrigatório que exista ao menos um bufferpool por banco de dados, o qual poderá ser compartilhado entre os objetos deste banco. Importante observar que o tamanho dos tablespaces criados no banco de dados deve ser compatível com o tamanho dos bufferpools que ele possui.


Encaixando as Peças

Esta estrutura de dados pode parecer confusa, mas na realidade a associação entre os componentes físicos e lógicos segue um processo simples. Tabelas são componentes lógicos que recebem dados compatíveis com o modelo desta tabela. Porém, para que o DB2 armazene estes dados, é necessário definir um vínculo entre a tabela e os recursos físicos da máquina.

Quem realiza este vínculo é o tablespace, que se associa a recursos de memória (bufferpools) e recursos de disco (contêiners).

Um bufferpool reserva espaço na memória do servidor para que os dados sejam trabalhados durante a execução das várias operações executadas pelo DB2. Por exemplo, para manipulação dos registros durante a gravação do log de transações, para execução de uma consulta, etc.

Um contêiner aloca espaço em um disco da máquina, seja na forma de arquivos ou dispositivos, dependendo do modo como é gerenciado o tablespace que o utiliza. O contêiner armazena as páginas de dados e são elas que efetivamente guardam os dados da tabela.

As páginas de dados, por sua vez, são alocações dentro dos contêiners onde são armazenados os dados. O tamanho das páginas de uma tabela é definido na criação do tablespace desta tabela. Este tamanho deve obrigatoriamente ser compatível com o tamanho do bufferpool usado, visto que o DB2 precisará ler as páginas do disco para guardá-las em cache de memória.

Extensões são espaços contínuos dentro dos contêiners nos quais são agrupadas as páginas de dados. O tamanho da extensão é definido pelo número máximo de páginas registradas na extensão e o tamanho da própria página. Extensões que gravam 8 páginas de 16K terão 128K (8x16).

A Figura 2 representa a estrutura de dados associada a uma tabela chamada Tabela2.

Figura 2. Representação esquemática da estrutura de dados do DB2.
Representação esquemática da estrutura de dados do DB2.

Tipos de Tablespaces

O DB2 utiliza diferentes tipos de tablespaces. São eles:

  • Regulares
  • Grandes
  • Temporários

Tablespaces Regulares

Lidam com todo tipo de informação permanente, sejam de tabelas ou índices. Todo banco de dados tem ao menos um tablespace regular, visto que na criação de todo banco de dados do DB2 é criado um tablespace especial associado às tabelas de sistema. Este é o SYSCATSPACE. Este tablespace é reservado exclusivamente para as tabelas de sistema e não deve ser usado para nenhuma outra finalidade.

Tablespaces Grandes

Este tipo de tablespace armazena todo tipo de informação permanente, incluindo objetos grandes (LOBs) ou campos XML. Os tablespaces grandes permitem a criação de tabelas maiores do que tabelas equivalentes criadas em tablespaces regulares. Todo banco de dados tem ao menos um tablespace grande, que é criado junto com cada um novo banco de dados. Seu nome é USERSPACE1 e este é o tablespace default de todo banco de dados.

Tablespaces Temporários

Existem dois subtipos de tablespaces temporários.

  • de sistema, usados pelo DB2 para realização de operações internas, como ordenação de dados, junção de tabelas, etc O DB2 cria um tablespace deste tipo assim que cria cada banco de dados. Seu nome é TEMPSPACE1.
  • De usuário, que precisam ser criados pelos usuários para que o DB2 possa lidar com tabelas temporárias e/ou variáveis de tabela. Nos dois casos, os dados são mantidos em memória.

Gerenciando Tablespaces

O DB2 utiliza três tipos de gerenciamento de tablespaces e cada um deles permite ações específicas.

O primeiro deles são os tablespaces gerenciados pelo sistema operacional, chamados SMS. Neste tipo de tablespaces, a maior parte das ações de gerenciamento é executada pelo sistema operacional. Os contêiners usados são definidos como arquivos e acessados através do sistema operacional.

O segundo tipo de gerenciamento é o chamado tablespace gerenciado pelo banco de dados (DMS). Aqui as ações são controladas pelo DB2. Os tablespaces do tipo DMS são mais flexíveis e versáteis, mas exigem mais atenção por parte do DBA.

O terceiro é o armazenamento automático que pretende combinar as vantagens dos dois tipos anteriores. Neste caso o próprio gerenciador do DB2 controla a alocação de containers e gerenciamento de espaço. Este é o default do DB2 LUW v10.1.

Vejamos agora algumas situações comuns do dia-a-dia que afetam a estrutura de dados do DB2 e quais as ações que solucionam cada caso.

1. Identificando parâmetros de um banco de dados

Vamos criar um banco de dados chamado MEUBD e identificar tablespaces, contêiners, bufferpools e tipo de gerenciamento dos tablespaces.

O banco de dados foi criado executando-se um comando simples:

db2 create database MEUBD

Naturalmente, para se executar qualquer ação relacionada ao banco de dados MEUBD, seja criação de novos objetos, consulta a tabelas ou identificam de parâmetros, é preciso antes de tudo se conectar ao banco.

db2 connect to MEUBD

Para reconhecer os tablespaces existentes neste banco e também os detalhes de cada um deles, usaremos o comando.

db2 list tablespaces show detail

A Listagem 1 mostra o resultado deste comando. São listados os três tablespaces default que são criados junto com qualquer banco de dados novo e mais o tablespace SYSTOOLSPACE. Este objeto foi criado porque ele é usado pelo coletor automático de estatísticas e, nas versões mais novas do DB2, esta funcionalidade está habilitada por default.

Listagem 1. Descrição dos Tablespaces de MEUBD

db2inst1@db2v10:~> db2 list tablespaces show detail
           
	Tablespaces for Current Database

Tablespace ID                        = 0
Name                                 = SYSCATSPACE
Type                                 = Database managed space
Contents                             = All permanent data. Regular table space.
State                                = 0x0000  Detailed explanation:    Normal
Total pages                          = 24576
Useable pages                        = 24572
Used pages                           = 22176
Free pages                           = 2396
High water mark (pages)              = 22176
Page size (bytes)                    = 4096
Extent size (pages)                  = 4
Prefetch size (pages)                = 4
Number of containers                 = 1


Tablespace ID                        = 1
Name                                 = TEMPSPACE1
Type                                 = System managed space
Contents                             = System Temporary data
State                                = 0x0000  Detailed explanation:    Normal
Total pages                          = 1
Useable pages                        = 1
Used pages                           = 1
Free pages                           = Not applicable
High water mark (pages)              = Not applicable
Page size (bytes)                    = 4096
Extent size (pages)                  = 32
Prefetch size (pages)                = 32
Number of containers                 = 1


Tablespace ID                        = 2
Name                                 = USERSPACE1
Type                                 = Database managed space
Contents                             = All permanent data. Large table space.
State                                = 0x0000  Detailed explanation:    Normal
Total pages                          = 8192
Useable pages                        = 8160
Used pages                           = 96
Free pages                           = 8064
High water mark (pages)              = 96
Page size (bytes)                    = 4096
Extent size (pages)                  = 32
Prefetch size (pages)                = 32
Number of containers                 = 1


Tablespace ID                        = 3
Name                                 = SYSTOOLSPACE
Type                                 = Database managed space
Contents                             = All permanent data. Large table space.
State                                = 0x0000  Detailed explanation:    Normal
Total pages                          = 8192
Useable pages                        = 8188
Used pages                           = 152
Free pages                           = 8036
High water mark (pages)              = 152
Page size (bytes)                    = 4096
Extent size (pages)                  = 4
Prefetch size (pages)                = 4
Number of containers                 = 1

Observe na Listagem 1 que são listados os tablespace, seu tipo, o tipo de gerenciamento e os tamanhos de páginas, tamanhos de extensões, número de contêiners etc. Mas não são informados os nomes de contêiners ou dos bufferpools utilizados.

Podemos obter estas informações de outras maneiras. Para identificar os containers usados por um tablespace, podemos usar o comando LIST TABLESPACE CONTAINERS e informar o ID do tablespace desejado. No exemplo a seguir, o tablespace é USERSPACE1, cujo ID é 2. A Listagem 2 mostra o resultado deste comando.

Listagem 2. Contêiner usado pelo tablespace USERSPACE1

db2inst1@db2v10:~> db2 list tablespace containers for 2 show detail


           Tablespace Containers for Tablespace 2

Container ID  = 0
Name          = /db2fs/db2inst1/NODE0000/MEUBD/T0000002/C0000000.LRG
Type          = File
Total pages   = 8192
Useable pages = 8160
Accessible    = Yes

No caso dos bufferpools, podemos fazer uma consulta direta nas tabelas de catálogo do DB2. Por exemplo, a tabela SYSCAT.BUFFERPOOLS informa detalhes de cada bufferpool enquanto que SYSCAT.TABLESPACES faz o mesmo em relação a tablespaces.

A Listagem 3 mostra a consulta usada e seu resultado. Como se vê, todos os quatro tablespaces criados usam o bufferpool default IBMDEFAULTBP, que trabalha com páginas de 4K.

Listagem 3. Características de bufferpools e tablespaces

db2inst1@db2v10:~> db2 select T.TBSPACE, B.BPNAME,  
B.BUFFERPOOLID,  B.NPAGES, B.PAGESIZE from 
SYSCAT.BUFFERPOOLS B left join SYSCAT.TABLESPACES T 
on T. BUFFERPOOLID = B. BUFFERPOOLID ORDER BY 1

TBSPACE           BPNAME        BUFFERPOOLID NPAGES      PAGESIZE   
------------------------------------------------------------------------------------------
SYSCATSPACE       IBMDEFAULTBP       1          -2        4096
SYSTOOLSPACE      IBMDEFAULTBP       1          -2        4096
TEMPSPACE1        IBMDEFAULTBP       1          -2        4096
USERSPACE1        IBMDEFAULTBP       1          -2        4096

  4 record(s) selected.

2. Adicionando campos que excedem o tamanho do tablespace

Aproveitando o mesmo banco de dados MEUBD, vamos criar a tabela TAB1, que possui dois campos: ID (com tipo de dados inteiro) e DESCRICAO (alfanumérico com 1000 posições). A declaração SQL para criar esta tabela é mostrada a seguir.

db2 “create table TAB1 (ID int, DESCRICAO varchar(1000))”

Como nada foi especificado, a tabela TAB1 será associada ao tablespace USERSPACE1. Agora inserimos um registro na tabela e conferimos o conteúdo da mesma.

db2 “insert into TAB1 values (1, ‘xxxxxxxxxxxxxxxxxxxxxxxxxx’)”
db2 “select * from TAB1”

Continuando o exercício, vamos imaginar que em um determinado momento da história da tabela TAB1 será necessário incluir uma nova coluna chamada COMENTARIO, que aceita até 5000 caracteres.

Instintivamente, o DBA responsável tentará executar a sentença abaixo.

db2 “alter table TAB1 add COMENTARIO varchar(5000)”

Porém esta ação vai gerar um erro SQL0670E:

“The row length of the table exceeded a limit of ‘4005’ bytes
(tablespace ‘USERSPACE1’)”.

É fácil entender a razão do problema. Na criação da tabela TAB1, ela foi automaticamente associada ao tablespace USERSPACE1 e este tablespace usa com o bufferpool IBMDEFAULTBP, que trabalha com páginas de 4k.

Quando tentamos acrescentar este novo campo de 5000 bytes à tabela já existente, os registros de TAB1 passarão a ocupar 6008 bytes, ou seja, 8 bytes do campo ID mais 1000 do campo DESCRICAO mais 5000 do campo COMENTARIO.

Acontece que registros deste tamanho não podem ser tratados num bufferpool de 4K (4096 bytes) e por isso vemos esta mensagem de erro.

E devemos lembrar que não é possível alterar o bufferpool associado a um tablespace.

Também não é possível alterar o tablespace associado a uma tabela.

A solução do problema exige uma sequência de ações, como se vê na Listagem 4. É necessário:

  • criar um novo bufferpool de 8k
  • criar um novo tablespace associado a este bufferpool
  • exportar os dados armazenados em TAB1
  • excluir a tabela TAB1
  • recriar TAB1 associando-a ao novo tablespace
  • importar os dados originais

Listagem 4. Adicionando campo que excede o tamanho do tablespace

db2inst1@db2v10:~> db2 create bufferpool BP8K size 2000 pagesize 8K
DB20000I  The SQL command completed successfully.

db2inst1@db2v10:~> db2 create tablespace 
TS8K pagesize 8K extentsize 64 prefetchsize 32 bufferpool BP8K
DB20000I  The SQL command completed successfully.

db2inst1@db2v10:~> db2 "export to '/home/db2inst1/tab1.txt'
of del messages '/home/db2inst1/tab1.emsg' select * from TAB1" 

Number of rows exported: 1

db2inst1@db2v10:~> db2 drop table TAB1
DB20000I  The SQL command completed successfully.

db2inst1@db2v10:~> db2 'create table TAB1 
(ID int, DESCRICAO varchar(1000), COMENTARIO varchar(5000)) in "TS8K"'
DB20000I  The SQL command completed successfully.

db2inst1@db2v10:~> db2 "load from '/home/db2inst1/tab1.txt'
of del insert into TAB1 (ID, DESCRICAO)"
SQL3501W  The table space(s) in which the table resides will not be placed in 
backup pending state since forward recovery is disabled for the database.

SQL3109N  The utility is beginning to load data from file 
"/home/db2inst1/tab1.txt".

SQL3500W  The utility is beginning the "LOAD" phase at time "09/12/2012 
10:51:23.549513".

SQL3519W  Begin Load Consistency Point. Input record count = "0".

SQL3520W  Load Consistency Point was successful.

SQL3110N  The utility has completed processing.  "1" rows were read from the 
input file.

SQL3519W  Begin Load Consistency Point. Input record count = "1".

SQL3520W  Load Consistency Point was successful.

SQL3515W  The utility has finished the "LOAD" phase at time "09/12/2012 
10:51:23.800356".


Number of rows read         = 1
Number of rows skipped      = 0
Number of rows loaded       = 1
Number of rows rejected     = 0
Number of rows deleted      = 0
Number of rows committed    = 1

3. Restaurando o backup de uma base numa nova instância

Consideremos agora um novo cenário. Estamos trabalhando num projeto onde existem dois ambientes: produção e desenvolvimento.

O DBA deve fazer uma atualização periódica dos dados na base de desenvolvimento. Por isso frequentemente ele deve fazer backup da base MEUBD na instância de produção DB2INST1, se logar na instância de desenvolvimento DEVINST e restaurar esta cópia.

Durante a configuração do ambiente de desenvolvimento, foram tomadas algumas providências:

  • abertura de uma nova sessão do LINUX usando usuário root para criação de um novo usuário do LINUX devinst e em seguida criação da instância do DB2 com o mesmo nome.
    echo ”root”
    useradd devinst -m -g db2grp1 -d /home/devinst
    /opt/ibm/db2/V10.1/instance/db2icrt -u db2fenc1 devinst

A segunda parte do processo exige que se abra outra sessão no LINUX, desta vez com o usuário db2inst1, para dar direito de leitura sobre a tabela TAB1 para o novo usuário devinst. Precisa também criar um diretório de backups e configurar permissões de acesso

echo “db2inst1”
db2 connect to MEUBD
db2 grant select on db2inst1.TAB1 to devinst
cd /tmp
mkdir db2backup
chmod 774 db2backup

Feito isso, vamos fazer uma cópia de segurança da base MEUBD e configurar permissão de acesso a este arquivo, processo que será repetido periodicamente.

db2 backup database MEUBD to /tmp/db2backup compress
chmod 740 NomeDoBackup

Concluída a preparação, vamos abrir outra sessão com o usuário devinst para restaurar a cópia na nova instância. Porém esta ação retorna erro na primeira tentativa, como se vê na Listagem 5.

Listagem 5. Tentativa de restauração de backup

devinst@db2v10:~> db2 restore database MEUBD from 
/tmp/db2backup taken at 20120914153650 replace existing 
SQL0970N  The system attempted to write to a 
read-only file.  SQLSTATE=55009

Isso acontece porque a cópia da base MEUBD precisa ser restaurada em DEVINST numa estrutura de contêiners similar, mas não idêntica, àquela usada na instância DB2INST1.

Como não foi especificada nenhuma instrução a este respeito no procedimento de restauração, o processo tenta escrever os dados exatamente nos mesmos contêiners que eram usados na instância de produção. Porém estes contêiners podem não existir no servidor em questão e/ou o usuário devinst pode não ter direito de escrita nestes contêiners. Por isso o processo falha.

A solução depende da configuração dos ambientes origem (DB2INST1) e destino (DEVINST).

No presente caso, a base MEUBD foi criada sem nenhuma informação sobre o modo de gerenciamento dos tablespaces. Portanto foi usado o gerenciamento padrão, que é armazenamento automático. Sendo assim, durante a restauração devemos apenas apontar para os diretórios de dados e de log da base e deixar o DB2 administrar os contêiners que serão usados.

É uma boa prática criar um banco de dados vazio antes de tentar fazer a primeira restauração. Isso porque ela pode falhar caso não exista o diretório onde será gravado o log do banco.

Uma vez finalizado o processo de restauração, deve-se lembrar que os objetos do banco MEUBD foram criados no esquema DB2INST1, simplesmente porque a tabela TAB1 foi criada por este usuário sem que tenha sido especificado nenhum esquema. Portanto o usuário devinst terá de especificar o nome completo da tabela para poder acessá-la (DB2INST1.TAB1).

A Listagem 6 mostra estas ações.

Listagem 6. Restaurando um backup em outra instância

devinst@db2v10:/tmp/db2backup> db2 restore database MEUBD from 
/tmp/db2backup taken at 20120914153650 on /home/devinst dbpath on 
/home/devinst/devinst/NODE0000/MEUBD into MEUBD newlogpath 
/home/devinst/devinst/NODE0000/MEUBD replace existing 

SQL2539W  Warning!  Restoring to an existing database that is the same as the 
backup image database.  The database files will be deleted.
DB20000I  The RESTORE DATABASE command completed successfully.


devinst@db2v10:/tmp/db2backup> db2 connect to meubd

   Database Connection Information

 Database server        = DB2/LINUX 10.1.0
 SQL authorization ID   = DEVINST
 Local database alias   = MEUBD

devinst@db2v10:/tmp/db2backup> db2 "select count(*) from db2inst1.TAB1" 

1          
-----------
          1

1 record(s) selected.

Conclusão

Conhecer a estrutura de dados do DB2 é ponto chave para o trabalho do DBA. Uma vez que o leitor domine os conceitos envolvidos, poderá projetar adequadamente as características dos componentes físicos e lógicos usados em cada objeto.

O artigo mostra recursos importantes no reconhecimento das características de um banco de dados, como tamanho de tablespaces e bufferpools, localização de contêiners, etc. Mostra também como o conhecimento da estrutura de dados ajuda na solução de problemas do dia-a-dia.


Referências

Patel, Ani. DB2 Basics: Table spaces and buffer pools. IBM DEVELOPERWORKS. 22/Abr/2010.
http://www.ibm.com/developerworks/data/library/techarticle/0212wieser/index.html

Chong, Raul. Video Course DB101PT - DB2 Essential Training I (versão em Português). Big Data University.
http://bigdatauniversity.com/courses/course/view.php?id=121

Chong, Raul. Video Course DB101PT - DB2 Essential Training II. Big Data University.
http://bigdatauniversity.com/courses/course/view.php?id=243

IBM. DB2 Versão 10.1 para Linux, UNIX e Windows: Glossário. IBM.
http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.glossary.doc/doc/glossary.html

Eaton, Chris. Storage Enhancements in DB2. Toolbox.com. 20/Jun/2005.
http://it.toolbox.com/blogs/db2luw/storage-enhancements-in-db2-4675

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Information Management
ArticleID=844125
ArticleTitle=DBA 101: administrando estruturas de dados do DB2
publish-date=11022012