Básico do DB2: Espaços de tabela e buffer pools

Este artigo ajuda o novo administrador de banco de dados DB2® a entender a importância de espaços de tabela e buffer pools. Este artigo também explica como a estruturação e o ajuste adequados de espaços de tabela e buffer pools podem aprimorar o desempenho do banco de dados. [Originalmente escrito em 2002, este artigo foi atualizado para o IBM DB2 V9.7 para Linux®, UNIX® e Windows®.]

Ani Patel, DB2 Advance Support Specialist, IBM

Photo of Ani PatelAni Patel trabalha atualmente no Laboratório da IBM em Toronto como Analista de Suporte Avançado a DB2 nível 2. Ele trabalha com suporte a DB2 há mais de 7 anos. Suas áreas de conhecimento incluem armazenamento, backup, recuperação e registro. Ele é bacharel em Engenharia da Computação pela Ryerson University, em Toronto, Canadá.



14/Mai/2010 (Primeira publicação 14/Mai/2010)

Introdução

Para o administrador de banco de dados (DBA) que acaba de entrar para o mundo do DB2 ou para o DBA prospectivo, as escolhas de estrutura e desempenho para um novo banco de dados podem ser muito confusas. Este artigo discute duas áreas nas quais o DBA tem importantes escolhas a fazer: espaços de tabela e buffer pools. A estruturação e o ajuste de espaços de tabela e buffer pools podem ter um impacto profundo no modo de desempenho do servidor DB2.

Neste artigo, os exemplos usam o DB2 Versão 9.7, Enterprise Server Edition. A maioria dos exemplos também se aplica a versões anteriores, a não ser que o contrário seja indicado.

Este artigo:

Aprendendo sobre espaços de tabela

Todos os dados de um banco de dados estão armazenados em um número de espaços de tabela. É possível pensar em um espaço de tabela como um filho e em um banco de dados como seu pai, onde o espaço de tabela (filho) não pode possuir mais de um banco de dados (pai). Devido ao fato de haver diferentes usos para espaços de tabela, eles são classificados de acordo com seu uso e como eles serão gerenciados. Há cinco espaços de tabela diferentes, nomeados de acordo com seu uso:

Espaço de tabela de catálogos
Há somente um espaço de tabela de catálogo por banco de dados e ele é criado quando o comando CREATE DATABASE é emitido. Chamado de SYSCATSPACE pelo DB2, o espaço de tabela de catálogo mantém as tabelas de catálogo do sistema. Esse espaço de tabela é sempre criado quando um banco de dados é criado.
Espaço de tabela regular
Um espaço de tabela regular armazena todos os dados permanentes, incluindo tabelas regulares e índices. Eles também podem manter dados grandes, como Objetos Grandes (LOBs), a não ser que eles estejam explicitamente armazenados em um espaço de tabela grande. Uma tabela e seus índices podem ser divididos em espaços de tabela regulares, se os espaços de tabela forem espaço gerenciado de banco de dados (DMS) para tabelas não particionadas ou espaço gerenciado de sistema (SMS) para tabelas particionadas. DMS e SMS são descritos na seção Gerenciamento de espaço de tabela. Espaço de tabela de catálogo é um exemplo de um espaço de tabela regular. Por padrão, o espaço de tabela de catálogo é o único espaço de tabela regular criado durante a criação do banco de dados.
Espaço de tabela grande
Um espaço de tabela grande armazena todos os dados permanentes assim como um espaço de tabela regular, incluindo LOBs. Esse tipo de espaço de tabela deve ser DMS, que é o tipo padrão. Uma tabela criada em um espaço de tabela grande pode ser maior do que uma tabela em um espaço de tabela regular. Uma tabela grande pode suportar mais de 255 linhas por página de dados, melhorando a utilização do espaço em páginas de dados. O DB2 cria um espaço de tabela grande chamado USERSPACE1 quando um banco de dados é criado.
Espaço de tabela temporário do sistema
Um espaço de tabela temporário do sistema armazena dados temporários necessários durante operações SQL, como classificação e reorganização de tabelas, criação de índices e junção de tabelas. Deve existir pelo menos um espaço de tabela temporário do sistema para cada banco de dados. O padrão criado com o banco de dados é nomeado TEMPSPACE1.
Espaço de tabela temporário do usuário
Espaços de tabela temporários do usuário armazenam tabelas temporárias globais declaradas. Não existe nenhum espaço de tabela temporário do usuário quando um banco de dados é criado. Pelo menos um espaço de tabela temporário do usuário deve ser criado para permitir a definição de tabelas temporárias declaradas. Espaços de tabela temporários do usuário são opcionais. Nenhum espaço de tabela temporário de usuário é criado por padrão.

Gerenciamento de espaço de tabela

Espaços de tabela podem ser gerenciados de duas maneiras:

Espaço gerenciado de sistema (SMS)
O sistema operacional gerencia espaços de tabela SMS. Contêineres são definidos como arquivos do sistema operacional regulares e são acessados usando chamadas do sistema operacional. Isso significa que todas as funções do sistema operacional regulares tratam de:
  • A E/S é armazenada em buffer pelo sistema operacional
  • O espaço é alocado de acordo com as convenções do sistema operacional
  • O espaço de tabela é automaticamente estendido quando necessário

No entanto, contêineres não podem ser descartados de espaços de tabela SMS e a adição de novos contêineres está restrita a bancos de dados particionados. Os três espaços de tabela padrão explicados na seção anterior são SMS.

Espaço gerenciado do banco de dados (DMS)
O DB2 gerencia espaços de tabela DMS. Contêineres podem ser definidos tanto como arquivos, que serão totalmente alocados com o tamanho dado quando o espaço de tabela for criado, ou como dispositivos. O DB2 gerencia a maior quantidade da E/S que o método de alocação e o sistema operacional permitirem. É possível estender os contêineres usando o comando ALTER TABLESPACE. Partes dos contêineres DMS não usados podem também ser liberadas (a partir da versão 8).

A Listagem 1 mostra como aumentar o tamanho do contêiner:

Listagem 1. Aumente o tamanho do contêiner
 ALTER TABLESPACE TS1 RESIZE 
(FILE '/conts/cont0' 2000,    
DEVICE '/dev/rcont1' 2000, 
FILE 'cont2' 2000)

Também é possível usar opções como EXTEND ou REDUCE para aumentar ou diminuir o tamanho de um contêiner.

Como criar e visualizar seus espaços de tabela

Ao criar um banco de dados, três espaços de tabela são criados (SYSCATSPACE, TEMPSPACE1 e USERSPACE1). A Listagem 2 mostra como criar um banco de dados chamado testdb, conectar-se a ele e listar os espaços de tabela usando a janela de comandos do DB2 ou a linha de comandos do UNIX.

Listagem 2. Crie, conecte e liste
 CREATE DATABASE testdb  CONNECT TO testdb  LIST TABLESPACES

A Listagem 3 mostra a saída do comando LIST TABLESPACES.

Listagem 3. Saída do comando LIST TABLESPACES
            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   
     Tablespace ID                        = 1
     Name                                 = TEMPSPACE1
     Type                                 = System managed space
     Contents                             = System Temporary data
     State                                = 0x0000
     Detailed explanation:      Normal   
     Tablespace ID                        = 2
     Name                                 = USERSPACE1
     Type                                 = Database managed space
     Contents                             = All permanent data. Large table space.
     State                                = 0x0000
     Detailed explanation:      Normal

O comando CREATE DATABASE cria automaticamente os três espaços de tabela na Listagem 3. O usuário pode substituir a criação padrão do espaço de tabela incluindo especificações do espaço de tabela no comando, mas um espaço de tabela de catálogo e pelo menos um espaço de tabela regular ou espaço de tabela grande e um espaço de tabela temporário do sistema devem ser criados no momento da criação do banco de dados. Mais espaços de tabela de todos os tipos (exceto espaço de tabela de catálogo) podem ser criados tanto com o comando CREATE DATABASE ou posteriormente, usando o comando CREATE TABLESPACE.

Contêineres

Cada espaço de tabela possui um ou mais contêineres. Novamente, você pode pensar em um contêiner como sendo um filho e um espaço de tabela como seu pai. Cada contêiner pode pertencer somente a um espaço de tabela único, mas um espaço de tabela pode ter muitos contêineres. É possível adicionar ou descartar contêineres de um espaço de tabela DMS e seus tamanhos podem ser modificados. Contêineres só podem ser adicionados a espaços de tabela SMS em bancos de dados particionados em uma partição que ainda não possui um contêiner alocado para o espaço de tabela. Quando novos contêineres são adicionados, um novo balanceamento automático distribui os dados em todos os contêineres. O novo balanceamento não evita o acesso simultâneo ao banco de dados.

Configurações do espaço de tabela

Há várias configurações que podem ser especificadas para espaços de tabela, tanto quando são criados ou, posteriormente, com uma instrução ALTER TABLESPACE. A lista a seguir descreve as configurações.

Tamanho da página
Define o tamanho das páginas usadas para o espaço de tabela. Os tamanhos suportados incluem de 4 KB, 8 KB, 16 KB e 32 KB. O tamanho de página limita o comprimento da linha e a contagem de colunas de tabelas que podem ser colocados em um espaço de tabela de acordo com os limites mostrados na Tabela 1:
Tabela 1. Implicações do tamanho de página
Tamanho da página Limite do tamanho da linha Limite da contagem de colunas Capacidade máxima (espaço de tabela DMS)
4 KB4 00550064 GB
8 KB8 1011 012128 GB
16 KB16 2931 012256 GB
32 KB32 6771 012512 GB

Espaços de tabela são limitados a 16384 páginas, então, escolher um tamanho de página maior aumentará a capacidade do espaço de tabela.

Tamanho da extensão
Especifica o número de páginas que serão escritas em um contêiner antes de passar para o próximo contêiner. O gerenciador de banco de dados circula repetidamente pelos contêineres enquanto os dados são armazenados. Este parâmetro tem efeito somente quando há contêineres múltiplos para o espaço de tabela.
Tamanho de pré-busca
Especifica o número de páginas que é lido a partir de um espaço de tabela quando a pré-busca de dados estiver sendo executada. A pré-busca procura por dados necessários para uma consulta antes que seja feita a referência deles pela consulta para que a consulta não precise esperar para que a E/S seja executada. A pré-busca é selecionada pelo gerenciador de banco de dados quando ele determina que a E/S sequencial é adequada e que a pré-busca pode ajudar a melhorar o desempenho.
Gasto adicional e taxa de transferência
Determina o custo de E/S durante a otimização da consulta. Ambos os valores são medidos em milissegundos e eles devem ser a média para todos os contêineres. O gasto adicional é o tempo associado à atividade do controlador de E/S, tempo de busca do disco e latência rotacional. A taxa de transferência é a quantidade de tempo necessária para ler uma página na memória. Os valores padrões para um banco de dados criado no DB2 Versão 9 são 7,5 milissegundos e 0,06 milissegundos, respectivamente. Os valores padrões para um banco de dados que é migrado de uma versão anterior do DB2 para a Versão 9 ou superior são 12,67 milissegundos e 0,18 milissegundos, respectivamente. Esses valores podem ser calculados com base em especificações de hardware.

Exemplo de uma instrução CREATE TABLESPACE

A Listagem 4 cria um espaço de tabela regular, incluindo todas as configurações deste artigo.

Listagem 4. Criando um espaço de tabela
 CREATE TABLESPACE USERSPACE3  PAGESIZE 8K  MANAGED BY SYSTEM  USING 
('d:\usp3_cont1', 'e:\usp3_cont2', 'f:\usp3_cont3')  
EXTENTSIZE 64  PREFETCHSIZE 32  BUFFERPOOL BP3  OVERHEAD 7.5  TRANSFERRATE 0.06

Como visualizar os atributos e contêineres do seu espaço de tabela

Especificar a opção SHOW DETAIL do comando LIST TABLESPACES mostra informações adicionais: LIST TABLESPACES SHOW DETAIL.

A Listagem 5 mostra a saída para o espaço de tabela USERSPACE1. Por padrão, os três espaços de tabela criados no momento da criação do banco de dados serão listados.

Listagem 5. Saída do comando LlST TABLESPACES SHOW DETAIL
 		Tablespaces for Current Database   
    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

Para listar os contêineres necessários para usar o Tablespace ID da saída acima, insira LIST TABLESPACE CONTAINERS FOR 2.

Listagem 6. Saída do comando LlST TABLESPACES CONTAINERS
 		Tablespace Containers for Tablespace 2  
    Container ID = 0  Name = C:\DB2\NODE0000\SQL00004\SQLT0002.0  Type = Path

O comando lista todos os contêineres para o espaço de tabela especificado. O caminho na Listagem 6 aponta para o local onde o contêiner reside fisicamente.

Buffer Pools

Um buffer pool está associado a um único banco de dados e pode ser usado por mais de um espaço de tabela. Ao considerar um buffer pool para um ou mais espaços de tabela, é necessário assegurar-se de que o tamanho de página do espaço de tabela e o tamanho de página do buffer pool são os mesmos para todos os espaços de tabela atendidos pelo buffer pool. Um espaço de tabela pode usar somente um buffer pool.

Quando um banco de dados é criado, um buffer pool padrão chamado IBMDEFAULTBP é criado e é compartilhado por todos os espaços de tabela. Mais buffer pools podem ser adicionados usando a instrução CREATE BUFFERPOOL. O tamanho do buffer pool é padronizado pelo tamanho especificado pelo parâmetro de configuração de banco de dados BUFFPAGE, mas é possível substituí-lo especificando a palavra-chave SIZE no comando CREATE BUFFERPOOL. O tamanho adequado do buffer pool é essencial para um bom desempenho do banco de dados, pois ele reduzirá a E/S do disco, a operação que consome mais tempo. Buffer pools grandes também terão um efeito na otimização de consulta, pois uma maior parte do trabalho pode ser feita na memória.

Buffer pools baseados em blocos
A Versão 8 ou uma versão superior permite que você reserve uma parte do buffer pool (até 98%) para pré-busca baseada em blocos. A E/S baseada em blocos melhora a eficiência da pré-busca lendo um bloco em uma área contínua da memória ao invés de carregá-lo de maneira dispersa em páginas separadas. O tamanho dos blocos deve ser uniforme por buffer pool e é controlado pelo parâmetro BLOCKSIZE. O valor é o tamanho de bloco medido em páginas de 2 a 256, sendo 32 o padrão.

Exemplo de instrução CREATE BUFFERPOOL

Para um exemplo da instrução CREATE BUFFERPOOL, insira: CREATE BUFFERPOOL BP3 SIZE 2000 PAGESIZE 8K

O buffer pool é designado a USERSPACE3 no exemplo CREATE TABLESPACE deste artigo e é criado antes da criação do espaço de tabela. Observe que os tamanhos de página de 8 KB para o buffer pool e espaço de tabela são os mesmos. Caso crie o espaço de tabela após criar o buffer pool, é possível deixar sintaxe BUFFER POOL BP3 de fora na instrução CREATE TABLESPACE. Ao invés disso, é possível usar o comando ALTER TABLESPACE para adicionar o buffer pool ao espaço de tabela existente, inserindo ALTER TABLESPACE USERSPACE3 BUFFERPOOL BP3.

Como visualizar os atributos de seu buffer pool

É possível listar informações do buffer pool consultando a visualização do sistema SYSCAT.BUFFERPOOLS, como mostra a Listagem 7.

Listagem 7. Consultando SYSCAT.BUFFERPOOLS
 SELECT * FROM SYSCAT.BUFFERPOOLS  BPNAME
BUFFERPOOLID  DBPGNAME  NPAGES  PAGESIZE  ESTORE  NUMBLOCKPAGES  BLOCKSIZE
------------  ------------  --------  ------  --------  ------  -------------  ---------
IBMDEFAULTBP       1              -     1000      4096       N              0
0  1 record(s) selected.

Para descobrir qual buffer pool está designado aos espaços de tabela, execute a consulta mostrada na Listagem 8.

Listagem 8. Consultando SYSCAT.TABLESPACES
 SELECT TBSPACE, BUFFERPOOLID FROM SYSCAT.TABLESPACES  
TBSPACE    
BUFFERPOOLID  
-----------  ------------ 
SYSCATSPACE       1  
TEMPSPACE1        1  
USERSPACE1        1  
3 record(s) selected.

O BUFFERPOOLID é mostrado na consulta na Listagem 8, possibilitando que você veja qual buffer pool está associado a cada espaço de tabela.

Diagrama visual da maneira como um banco de dados mantém espaços de tabela

Agora que você sabe o que é um espaço de tabela e um buffer pool e como criá-los, a Figura 1 mostra um exemplo de como eles são visualmente organizados dentro de um banco de dados.

Figura 1. Espaços de tabela e buffer pools
diagram shows a DB2 database with 5 table spaces and the disk containers that are assigned to each table space

O banco de dados de exemplo possui cinco espaços de tabela: um espaço de tabela de catálogo, dois regulares, um grande e um temporário do sistema. Nenhum espaço de tabela temporário de usuário foi criado. Há oito contêineres. Nesse exemplo, os buffer pools podem ser designados da seguinte maneira:

  • BP1 (4 KB) para SYSCATSPACE e USERSPACE2
  • BP2 (8 KB) para USERSPACE1
  • BP3 (32 KB) para LARGESPACE e SYSTEMP1

Examinando implicações de desempenho

Em geral, ao estruturar espaços de tabela e colocação de contêineres em dispositivos físicos, o objetivo é maximizar o paralelismo de E/S e a utilização de buffer. Para atingir esse objetivo, é necessário possuir um entendimento completo da estrutura do banco de dados e aplicativos. Somente assim é possível determinar tais problemas, como se a separação de duas tabelas em dispositivos diferentes levará à E/S paralela ou se uma tabela deve ser criada em um espaço de tabela separado para que ela possa ser totalmente armazenada em buffer.

Comece estruturando o layout físico de um novo banco de dados estruturando a organização do espaço de tabela, como mostram as etapas a seguir.

  1. Determine as restrições dadas pelas estruturas de tabela. Isso pode resultar em ter que usar mais de um espaço de tabela regular.
  2. Considere se possuir as tabelas em espaços de tabela com configurações diferentes pode aumentar significativamente o desempenho.
  3. Estruture um espaço de tabela experimental.
  4. Considere o uso do buffer pool, que pode levá-lo a fazer algumas alterações na estrutura anterior do espaço de tabela.
  5. Aloque contêineres para os espaços de tabela.

Esse processo é interativo e a estrutura deve ser verificada com teste de estresse e avaliações de desempenho. Claramente, chegar à melhor estrutura pode ser um esforço bem intenso, então, o tempo gasto só pode ser justificado se o desempenho do banco de dados tiver que ser o melhor possível. Como regra:

  • Inicie com a estrutura mais simples e factível.
  • Adicione complexidade somente quando houver uma justificativa de desempenho suficiente para ela, baseando-se em testes.

Frequentemente, vale a pena uma pequena diminuição no desempenho para diminuir a complexidade de administração e manutenção de uma estrutura de banco de dados mais simples. O DB2 possui uma lógica de gerenciamento de recursos sofisticada , o que, como padrão, produz um desempenho muito bom sem a necessidade de uma estrutura elaborada.

Organização do espaço de tabela

Cada tabela, dependendo da maneira como é acessada com mais frequência, possui um conjunto mais eficiente de configurações de espaço de tabela: PAGESIZE, EXTENTSIZE e PREFETCHSIZE.

O espaço de tabela de catálogo e os espaços de tabela temporários do sistema devem, geralmente, ser alocados como SMS. Não há razão para possuir mais de um espaço de tabela temporário do mesmo tamanho de página e, geralmente, o espaço com o maior tamanho de página é o suficiente.

A pergunta pertinente é se devemos ou não dividir os dados de usuários em múltiplos espaços de tabela. Uma consideração é a utilização de páginas. Linhas não podem ser divididas entre páginas, então, tabelas com linhas longas necessitam do tamanho de página adequado. No entanto, não pode haver mais de 255 linhas em uma página, então, tabelas com linhas curtas não usam a página toda.

Por exemplo, uma tabela com um comprimento de linha de 12 bytes colocada em um espaço de tabela com tamanho de página de 32 KB usa apenas cerca de 10% de cada página, que é calculada como (255 linhas * 12 bytes) + 91 bytes de gasto adicional) / tamanho de página de 32 KB = ~10%). Essa é apenas uma consideração no caso de a tabela ser grande, o que significa que o espaço desperdiçado for significativo. Isso também deixa a E/S e o armazenamento em buffer menos eficiente, pois o conteúdo realmente útil de cada página é pequeno.

Se uma tabela pode ser colocada em um espaço de tabela com tamanho de página menor ou também usar completamente um tamanho de página maior, então, o método de acesso mais frequente determina qual é o melhor. Se, geralmente, mais linhas são acessadas de maneira sequencial (talvez a tabela esteja em cluster), então, o tamanho de página maior é mais eficiente. Se as linhas forem acessadas de maneira aleatória, então, o tamanho de página menor permitirá que o DB2 faça melhor uso do buffer, pois mais páginas se ajustam a mesma área de armazenamento.

Após agrupar as tabelas por tamanho de página, a frequência e o tipo de acesso determinam se um novo agrupamento dos dados em espaços de tabela separados é justificado. EXTENTSIZE é o número de páginas de dados que será gravado em um contêiner antes da gravação no próximo contêiner (caso existam contêineres múltiplos no espaço de tabela).

PREFETCHSIZE especifica o número de páginas que é lido a partir de um espaço de tabela quando a pré-busca de dados estiver sendo executada. A pré-busca é usada quando o Gerenciador de Banco de Dados determina que a E/S sequencial é adequada e a pré-busca pode ajudar a melhorar o desempenho (geralmente, verificações de tabelas grandes). É uma boa prática definir explicitamente o valor do PREFETCHSIZE como um múltiplo do valor EXTENTSIZE para seu espaço de tabela e o número de contêineres de espaço de tabela. Por exemplo, se EXTENTSIZE for 32 e houver quatro contêineres, então PREFETCHSIZEs bons seriam 128, 256, etc. Se uma ou mais tabelas muito usadas necessitarem de um conjunto diferente desses parâmetros, além dos valores que são melhores para o restante do desempenho do espaço de tabela, coloque as tabelas muito usadas em um espaço de tabela separado para melhorar o desempenho geral.

Se a pré-busca for um fator importante em um espaço de tabela, considere separar parte do buffer para E/S baseada em blocos. O tamanho do bloco deve ser igual ao PREFETCHSIZE.

Utilização do buffer pool

A razão mais importante para usar mais de um espaço de tabela do usuário é para gerenciar o uso do buffer. Um espaço de tabela pode ser associado a somente um buffer pool, mas um buffer pool pode ser usado por mais de um espaço de tabela.

O objetivo do ajuste do buffer pool é ajudar o DB2 a fazer o melhor uso possível da memória disponível para os buffers. O tamanho geral do buffer exerce um efeito significativo no desempenho do DB2, pois um grande número de páginas pode reduzir significativamente a E/S, que é a operação que consome mais tempo. No entanto, se o tamanho total do buffer for muito grande e não houver armazenamento o suficiente para alocá-lo, um buffer pool mínimo para cada tamanho de página é alocado e o desempenho é reduzido de maneira acentuada. Para calcular o tamanho máximo do buffer, o DB2 considera todas as outras utilizações de armazenamento, o sistema operacional e qualquer outro aplicativo. Quando o tamanho total disponível for determinado, essa área pode ser dividida em diferentes buffer pools para melhorar a utilização. Caso haja espaços de tabela com tamanhos de página diferentes, deve haver pelo menos um buffer pool por tamanho de página.

Possuir mais de um buffer pool pode preservar dados nos buffers. Por exemplo, é possível que você tenha um banco de dados que possua muitas pequenas tabelas frequentemente usadas, que normalmente estariam no buffer em sua totalidade para estarem acessíveis rapidamente. Também é possível que você possua uma consulta que é executada em uma tabela muito grande, que usa o mesmo buffer pool e envolve a leitura de mais páginas que o tamanho de buffer total. Quando essa consulta é executada, as páginas das tabelas pequenas e usadas muito frequentemente são perdidas, fazendo com que uma nova leitura seja necessária quando as páginas forem necessárias novamente. Caso as tabelas pequenas possuam seu próprio buffer pool, tornando, assim, necessário que elas possuam seu próprio espaço de tabela, suas páginas não podem ser substituídas pela consulta grande. Isso pode levar a um melhor desempenho geral do sistema, embora custe algum pequeno efeito negativo à consulta grande.

Frequentemente, o ajuste é uma troca entre diferentes funções de um sistema para chegar a um ganho geral de desempenho. É essencial dar prioridade a funções e ter o rendimento total e o uso em mente ao fazer ajustes no desempenho de um sistema.

Com o DB2 Versão 8 ou uma versão superior, é possível alterar os tamanhos dos buffer pools sem interromper o banco de dados. A instrução ALTER BUFFERPOOL com a opção IMMEDIATE tem efeito imediato, a não ser quando não há espaço suficiente reservado na memória compartilhada com o banco de dados para alocar um novo espaço. Esse recurso pode ser usado para ajustar o desempenho do banco de dados de acordo com mudanças periódicas em uso, como a mudança do uso interativo durante o dia para o trabalho em lote durante a noite. O DB2 Versão 9.1 ou superior permite o gerenciamento de tamanho totalmente automatizado de um buffer pool. O gerenciador de memória autoajustável (STMM) do DB2 controla esse processo de automação.

Organização do armazenamento físico

Quando as tabelas estiverem distribuídas nos espaços de tabela, é necessário determinar seu armazenamento físico. Um espaço de tabela pode ser armazenado em contêineres múltiplos e pode ser tanto SMS ou DMS. SMS é mais fácil de ser administrado e pode ser uma boa opção para espaços de tabela contendo muitas tabelas pequenas diversas (como o espaço de tabela de catálogo), especialmente se essas tabelas contiverem LOBs.

Para reduzir o gasto adicional de estender os contêineres SMS uma página por vez, execute o comando db2empfa. Isso define o valor do parâmetro de configuração do banco de dados MULTIPAGE_ALLOC para YES.

O DMS geralmente tem um melhor desempenho e fornece a flexibilidade de armazenamento de índices e dados LOB separadamente. Contêineres múltiplos para um espaço de tabela devem ser, tipicamente, colocados em volumes físicos separados. Isso pode melhorar o paralelismo de algumas E/Ss. Quando houver espaços de tabela de usuários múltiplos e dispositivos múltiplos, considere a lógica de aplicativo para distribuir a carga de trabalho entre esses dispositivos da maneira mais uniforme possível.

Dispositivos RAID possuem suas próprias considerações especiais. EXTENTSIZE deve ser igual ao tamanho da faixa RAID ou um múltiplo do tamanho da faixa RAID. PREFETCHSIZE deve ser do tamanho da faixa RAID multiplicado pelo número de dispositivos paralelos RAID (ou um múltiplo desse produto) e um múltiplo do EXTENTSIZE. O DB2 vem com suas próprias variáveis de registro, permitindo que você otimize seu ambiente específico. Insira o comando a seguir para ativar o paralelismo E/S dentro de um contêiner único: db2set DB2_PARALLEL_IO=*.

Como em outras áreas de avaliação de desempenho, a única maneira segura de saber se uma mudança teve um efeito benéfico é conduzir avaliações de desempenho. Avaliações de desempenho são relativamente mais complicadas de usar para mudanças de organizações físicas, pois é necessária uma quantidade comparavelmente grande de esforço para modificar espaços de tabela. O modo mais prático é minimizar o número de casos durante a fase de estruturação para que o desempenho de menos casos precise ser avaliado mais tarde. Talvez, a única situação que mereça tempo e energia para avaliar rigorosamente o desempenho de estruturas concorrentes seja quando o desempenho for extremamente importante e quando houver a probabilidade de uma diferença significativa de desempenho entre as estruturas. Devem-se enfatizar os buffer pools, assegurando-se de que eles não estejam alocados na memória virtual e que sejam usados da maneira mais eficiente.


Transferindo bancos de dados

Sempre reavalie parâmetros de ajuste e organização física do banco de dados antes de transferi-lo para um sistema diferente, mesmo quando os sistemas estiverem no mesmo tipo de plataforma. Os resultados podem ser inesperados e necessitarem de um trabalho substancial para solucioná-los.

Em uma situação real, um DBA copiou um banco de dados bem ajustado de um servidor Windows com 1 GB de armazenamento para um laptop executando o Windows com 256 MB de armazenamento. A conexão, que foi feita em menos de um segundo no servidor, levou 45 minutos no laptop. O DBA solucionou o problema reduzindo o tamanho do bufffer pool e outros parâmetros de memória.

A questão torna-se ainda mais difícil se as plataformas forem diferentes. Mesmo entre UNIX e Windows, o que é ideal em um sistema pode não ser em outro. A seguir, algumas dicas a serem consideradas:

  • Se a cópia do banco de dados tiver como objetivo a produção, repita o processo de ajuste.
  • Se o banco de dados tiver que ser transferido para a plataforma z/OS®, consulte os manuais e IBM Redbooks adequados®.
  • No DB2 para i, o setup físico e o ajuste são feitos fora do ambiente do banco de dados. Consulte os manuais de gerenciamento do sistema i da IBM.

Conclusão

Este artigo cobriu uma grande quantidade de material e não é, de maneira alguma, tudo o que você deve saber sobre estruturação e desempenho de banco de dados. A discussão focou-se em dois grandes problemas da estruturação do banco de dados sem entrar nos detalhes de otimização de consulta e considerações de aplicativos. Estruturar seu banco de dados é mais importante, pois todo o resto é colocado sobre ele. Então, seu planejamento inicial deve ser abrangente. Para sua conveniência, são fornecidas abaixo outras referências on-line para que seja possível continuar sua educação neste tópico.

Agradecimentos

Agradecemos a Gabor Wieser e David J. Kline, que escreveram a versão original deste artigo em 2002.

Recursos

Aprender

Obter produtos e tecnologias

  • Faça o download do DB2 Express-C, uma versão sem custos do DB2 Express Edition para a comunidade, que oferece os mesmos recursos de dados centrais que o DB2 Express Edition e fornece uma base sólida para construir e implementar aplicativos.
  • Elabore seu próximo projeto de desenvolvimento com o software de teste IBM, disponível para download diretamente no developerWorks.

Discutir

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=489499
ArticleTitle=Básico do DB2: Espaços de tabela e buffer pools
publish-date=05142010