Básico do DB2: Espaços de tabela e buffer pools
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:
- Define os tipos de espaços de tabela e explica como o DB2 armazena dados em espaços de tabela
- Cobre as opções de configuração e mostra o processo de criação e gerenciamento de um espaço de tabela
- Discute buffer pools, cobrindo a definição de buffer pool e como criá-lo e usá-lo
- Sugere o que deve ser considerado ao transferir bancos de dados
- Descreve como buffer pools e espaços de tabela devem ser organizados para maximizar o desempenho
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. 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 KB | 4 005 | 500 | 64 GB |
| 8 KB | 8 101 | 1 012 | 128 GB |
| 16 KB | 16 293 | 1 012 | 256 GB |
| 32 KB | 32 677 | 1 012 | 512 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
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.
- Determine as restrições dadas pelas estruturas de tabela. Isso pode resultar em ter que usar mais de um espaço de tabela regular.
- Considere se possuir as tabelas em espaços de tabela com configurações diferentes pode aumentar significativamente o desempenho.
- Estruture um espaço de tabela experimental.
- Considere o uso do buffer pool, que pode levá-lo a fazer algumas alterações na estrutura anterior do espaço de tabela.
- 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
- Consulte o Centro de Informações do DB2 para Linux, UNIX e Windows para obter mais detalhes sobre sintaxe SQL para os comandos usados neste artigo, assim como detalhes sobre espaços de tabela e buffer pools.
- Consulte a área do DB2 para Linux, UNIX e Windows no developerWorks para obter recursos necessários para melhorar suas habilidades do DB2.
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.
Sobre o autor
Ani 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á.