Esse recurso é suportado somente no Ambiente Operacional Sun Solaris.
Devido à sobrecarga de E/S, a pré-busca de páginas no disco é uma operação cara. A pré-busca do DB2 melhora significativamente o rendimento quando o processamento pode ser sobreposto com E/S. A maioria das plataformas fornece primitivas de alto desempenho para ler páginas contíguas do disco em partes não-contíguas de memória. Essas primitivas são chamadas geralmente de "leitura dispersa" ou "E/S em vetor". Em algumas plataformas, o desempenho dessas primitivas não pode competir com a execução de E/S em blocos grandes. Por padrão, os conjuntos de buffers baseiam-se em páginas. Isto é, páginas contíguas no disco são pré-buscadas em páginas não-contíguas na memória. Posteriormente, o desempenho da pré-busca poderá ser aperfeiçoado nessas plataformas se as páginas puderem ser lidas do disco em páginas contíguas em um conjunto de buffers. Uma variável de registro, DB2_BLOCK_BASED_BP, permite a criação de uma seção no conjunto de buffers que contenha conjuntos de páginas contíguas. Esses conjuntos de páginas contíguas são chamados de "blocos". Definindo essa variável de registro, uma pré-busca seqüencial lerá as páginas do disco diretamente nesses blocos, em vez de ler cada uma individualmente. Isso melhorará o desempenho de E/S. Para obter mais informações sobre essa variável de registro, consulte a seção 'Variáveis de Registro e de Ambiente' do Administration Guide.
Várias áreas de tabela com tamanhos de extensão diferentes podem ser ligados a um conjunto de buffers com o mesmo tamanho de bloco. Há uma relação muito próxima entre tamanhos de extensão e tamanhos de bloco apesar de lidarem com conceitos distintos. Uma extensão é a granularidade na qual as áreas de tabela são demarcados em vários contêineres. Um bloco é a única granularidade em que servidores de E/S executando pedidos de pré-busca em seqüência considerarão a realização de E/S baseada em bloco.
Os pedidos de pré-busca em seqüência individuais utilizam páginas do tamanho da extensão. Quando esse pedido de pré-busca é recebido, o servidor de E/S determina o custo e benefício de se fazer cada pedido como uma E/S baseada em bloco (se houver uma área baseada em bloco no conjunto de buffers) em vez da E/S baseada em página utilizando o método de leitura dispersa. O benefício de se fazer qualquer E/S como E/S baseada em bloco é o benefício de desempenho da leitura do disco contíguo na memória contígua. O custo é a quantidade de memória desperdiçada no conjunto de buffers que pode resultar da utilização desse método.
A memória do conjunto de buffers pode ser desperdiçada por dois motivos ao executar E/S baseada em bloco:
O servidor de E/S permite algumas páginas desperdiçadas em cada bloco para obter o benefício de execução de E/S baseada em bloco. Entretanto, quando houver muito desperdício de um bloco, o servidor de E/S reverterá para a utilização de pré-busca baseada em página na área de páginas do conjunto de buffers. Como resultado, alguma E/S feita durante a pré-busca não será baseada em bloco. Essa condição não é a ideal.
Para obter um ótimo desempenho, é necessário ter várias áreas de tabela com o mesmo tamanho de extensão ligados a um conjunto de buffers com o mesmo tamanho de bloco. Ainda será possível obter um bom desempenho se o tamanho de extensão de algumas áreas de tabela for maior do que o tamanho do bloco do conjunto de buffers ao qual estiverem ligados. Não é aconselhável efetuar vinculação de áreas de tabela a um conjunto de buffers quando o tamanho da extensão é menor do que o tamanho do bloco.
Ambos os suportes, ao AWE e com base em bloco, não podem ser configurados para um conjunto de buffers ao mesmo tempo. Se as variáveis de registro DB2_AWE e DB2_BLOCK_BASED_BP referirem-se ao mesmo conjunto de buffers, o AWE obterá precedência. O suporte com base em bloco será desativado nesse caso e será reativado somente quando o AWE estiver desativado.
Um conjunto de buffers que estiver utilizando armazenamento estendido não suporta E/S baseada em bloco.
Antes de trabalhar com qualquer um dos exemplos, será necessário que você conheça os identificadores dos conjuntos de buffers em seu sistema. O ID do conjunto de buffers pode ser visto na coluna BUFFERPOOLID ou na exibição do catálogo de sistema SYSCAT.BUFFERPOOLS.
Cenário 1
Você tem um conjunto de buffers com um ID 4 que tem 1000 páginas. Você deseja criar uma área de blocos composta de 700 páginas nas quais cada bloco contém 32 páginas. É necessário executar o seguinte:
db2set DB2_BLOCK_BASED_BP=4,700,32
Quando o banco de dados for iniciado, o conjunto de buffers com ID 4 será criado com uma área de blocos de 672 páginas e uma área de páginas de 328 páginas. Neste exemplo, 32 não pode ser dividido igualmente em 700. Isso significa que o tamanho da área de blocos especificado teve que ser reduzido para o limite de tamanho de bloco mais próximo utilizando a seguinte fórmula:
((tamanho da área de blocos))
FLOOR(-----------------) X tamanho do bloco
( (tamanho do bloco) )
( 700 )
= FLOOR(-----------------) X 32
( 32 )
= 21 x 32
= 672
Cenário 2
Você tem um conjunto de buffers com um ID 11 que tem 3000 páginas. Você deseja criar uma área de blocos composta de 2700 páginas. É necessário executar o seguinte:
db2set DB2_BLOCK_BASED_BP=11,2700
Quando o banco de dados for iniciado, o conjunto de buffers com ID 11 será criado com uma área de blocos de 2688 páginas e uma área de páginas de 312 páginas. Sem um valor fornecido explicitamente para o tamanho do bloco, será utilizado o valor padrão de 32. Neste exemplo, 32 não pode ser dividido igualmente em 2700. Isso significa que o tamanho da área de blocos especificado teve que ser reduzido para o limite de tamanho de bloco mais próximo utilizando a seguinte fórmula:
((tamanho da área de blocos))
FLOOR(-----------------) X tamanho do bloco
( (tamanho do bloco) )
( 2700 )
= FLOOR(-----------------) X 32
( 32 )
= 84 x 32
= 2688