Introdução e índice com os outros posts desta série.
Vimos no post sobre Extents que as extensões do banco de dados podem ter até 1TB cada, desde que o sistema operacional suporte este tamanho de arquivo. Para uma Storage Area de 50GB, por exemplo, é possível ter uma única extensão de 50GB ou 50 extensões de 1GB cada uma. Podemos analisar esta escolha sob dois aspectos principais: do gerenciamento e do desempenho.
O aspecto do gerenciamento muitas vezes é esquecido, apesar de ser o mais importante. A idéia é simples: é mais fácil gerenciar menos arquivos do que gerenciar mais arquivos. Considere o trabalho de mover para outro local ou realizar um backup manual de um banco de dados de 1500 arquivos. Se um dos arquivos for esquecido a cópia está inconsistente (leia-se corrompida). Também é importante considerar restrições operacionais. Alguns discos SCSI de alto desempenho possuem capacidade de 36GB. Se estas unidades são utilizadas ou há intenção de utilizá-las, arquivos de 50GB não são adequados. No outro extremo, criar 200 arquivos de 250MB cada sem nenhum benefício administrativo é inútil.
O aspecto do desempenho não é tão simples. A melhor opção depende de muitos fatores, alguns dos quais não são simples de analisar. Se há disponibilidade de vários discos físicos, por exemplo, devem ser criados vários arquivos para distribuir a carga de IO entre os discos. A maior parte das instalações, no entanto, possui muito mais bancos de dados e extensões do que discos físicos.
Neste cenário de recursos restritos, é melhor criar poucos arquivos grandes para a Storage Area ou criar vários arquivos pequenos, estando todos no mesmo disco? É comum encontrarmos recomendações dizendo que para um melhor desempenho devemos utilizar extensões de no máximo 500MB ou no máximo 1GB. Estas recomendações parecem ser baseada em suposições ou características de sistemas operacionais muito antigos.
Uma crença muito popular é que abrir um arquivo pequeno é mais rápido do que abrir um arquivo grande. Para o sistema operacional, no entanto, a abertura de um arquivo consiste basicamente em:
- verificar se o arquivo existe;
- verificar as permissões do arquivo;
- verificar se o arquivo não está aberto em um modo incompatível;
- alocar um descritor(handle) e disponibilizá-lo para a aplicação (OpenEdge, no nosso caso).
Independente do tamanho do arquivo, as operações acima (e outras mais) são realizadas. O tempo para a abertura de qualquer arquivo é similar, independente do seu tamanho. Como as operações acima são realizadas para cada arquivo, podemos concluir que quanto mais arquivos para serem abertos mais tempo é gasto na operação.
Além do tempo de abertura, o consumo de recursos é proporcional a quantidade de arquivos. Cada arquivo aberto precisa de um handle no sistema operacional e a aplicação deve manter uma lista e gerenciar estes handles.
Outro mito bastante comum é que ler dados de um arquivo pequeno é mais rápido do que ler dados de um arquivo grande. Isto podia ser verdade nos sistemas antigos, mas os sistemas de arquivos dos sistemas operacionais modernos são bastante eficientes para lidar com arquivos grandes. Se houver alguma recomendação explícita do fornecedor do sistema operacional é interessante seguí-la, mas em linhas gerais o tempo é proporcional a quantidade de dados lidos, não ao tamanho do arquivo. Isso quer dizer que ler 1MB de um arquivo de 100MB ou de um arquivo de 10GB demora virtualmente o mesmo tempo. Evidentemente, ler 100MB demora mais do que ler 1MB, independente do tamanho do arquivo.
Para realizar alguns testes, criei 2 bancos de dados com 15 áreas cada um. No banco blog cada uma das 15 áreas possui 1023 extensões de 1MB, para um total de aproximadamente 15GB e 15345 extensões. O banco blog2 possui apenas 1 extensão de 1023MB por área, para um total de aproximadamente 15GB e 15 extensões. A quantidade de áreas e o tamanho total dos dois bancos são iguais, a diferença está no tamanho e quantidade de extensões. Os arquivos de estrutura (.st) utilizados para criar os bancos estão disponíveis para download no fim deste post.
Várias operações realizadas demoraram mais no banco de dados com vários arquivos pequenos. O tempo para carregar o banco de dados foi de mais de 1 minuto para o banco blog, comparado com menos de 0,5 segundos para o banco blog2. Os tempos para parar os bancos de dados foram de quase 3 minutos e aproximadamente 3 segundos. Os tempos para executar o comando TRUNCATE BI foram de mais de 4 minutos e menos de 1 segundo. Até mesmo executar o utilitário promon ou abrir um client com conexão de shared-memory ao banco de dados demora muito mais tempo quando há vários extensões para o banco de dados.
Algumas operações que ocorrem normalmente quando o banco de dados está ativo, notoriamente o checkpoint, também demoram mais quando há várias extensões.
O banco de dados criado para teste tinha muitas extensões, justamente para enfatizar a diferença de tempos. Na prática, os bancos de dados possuem menos do que 15 mil extensões e a diferença de tempo para as operações no banco de dados não será perceptível. A mensagem principal é que você deve levar em conta as características administrativas e operacionais do ambiente, antes de se preocupar se arquivos grandes realmente gerarão problemas de desempenho.
arquivos ST.zip (1,51 kb)
Assinar feeds (RSS)