A partir do ponto de separação de dados lógicos, existem tablespaces que consistem em segmentos que consistem em extends que consistem em blocos oracle que consistem em blocos OS. Qual estrutura lógica realmente contém dados de registro concreto (onde os dados de todos os campos do mesmo registro residem lado a lado no sistema de arquivos). No mundo do MySQL, existe uma página de dados (8, 16 KB) que contém um ou mais registros no mesmo endereço físico.
Além disso, como determinar qual tamanho é o melhor? Quanto mais páginas existirem, mais fragmentação de dados aparecerá e isso pode afetar o desempenho.
O bloco é a estrutura que contém os dados da linha. A documentação da Estrutura de Armazenamento Lógico tem uma visão geral detalhada de tudo isso.
Observe que os dados de uma única linha podem residir em mais de um bloco (isso é chamado de encadeamento de linhas), portanto, não precisam ser contíguos no disco. A migração de linha também pode deixar apenas um "endereço de encaminhamento" no bloco original da linha que aponta para o novo bloco de residência da linha.
Todas as E/S de e para o SGA são feitas em pedaços do tamanho de um bloco (possivelmente mais de um bloco por vez, mas, para o SGA, nunca menor que um bloco).
O tamanho do bloco do tablespace SYSTEM determina o tamanho do bloco "natural" do banco de dados. Você pode ter outros tablespaces com tamanhos de blocos diferentes, mas:
Portanto, em geral, é mais simples usar apenas um tamanho de bloco, apenas para evitar a sobrecarga administrativa e de ajuste do gerenciamento do tamanho de vários buffers de bloco.
Como você determina o tamanho de bloco ideal para um banco de dados é um compromisso, assim como quase todo o resto.
Blocos menores significam que seu SGA é mais granular, mas cada bloco tem relativamente mais sobrecarga. E linhas largas em pequenos blocos terão maior probabilidade de encadear ou migrar, o que pode ser uma fonte de problemas de desempenho.
Blocos maiores significam menos chances de encadeamento (supondo que PCTFREE e PCTUSED estejam razoavelmente definidos). Mas também significa grandes I/Os de bloco único e menos granularidade em seu SGA. Como uma alteração em qualquer linha de um bloco exige que todo o bloco seja gravado no disco, tamanhos de bloco maiores podem levar a mais volume de E/S de gravação do que os menores.
Outro fator a ser levado em consideração é que os arquivos de dados tradicionais (não bigfile) são limitados a 4 milhões de blocos. Isso é cerca de 32G para 8k blocos, mas apenas 8G para 2k blocos. Como o número de arquivos por espaço de tabela (não-bigfile) é limitado (a 1022), isso pode ser importante. (Também há um máximo de 65.533 arquivos por banco de dados, possivelmente menos. Consulte os limites físicos do banco de dados .)
Os sistemas transacionais tendem a usar tamanhos de bloco relativamente menores do que os sistemas de armazenamento de dados, mas isso não é nada como uma regra rígida e rápida. (por exemplo, as diretrizes atuais de melhores práticas da Oracle no Exadata são 8k blocos, independentemente dos cenários).