278-982-1-PB

Prévia do material em texto

v1.5 – 30OUT16 
 
 
Comparativo de Desempenho em Banco de Dados Oracle 
Utilizando Diferentes Sistemas de Arquivos 
 
Anderson A. Blasque, Fernando R. V. M. Lobo, Marcelo M. Moreira, Gustavo Bruschi 
 
Curso de Tecnologia em Banco de Dados – Faculdade de Tecnologia de Bauru 
(FATEC) 
Rua Manoel Bento da Cruz, Quadra 3, nº 30 - Centro - 17.015-171 - Bauru, SP - Brasil 
 
{Anderson.blasque, fernando.lobo, gustavo.bruschi}@fatec.sp.gov.br, 
moreira3ma@gmail.com 
 
Abstract. There is a growing concern for the best use of resources of 
Information Technology, and for that much investment has been made to 
develop software that can extract the most of available computational 
resources. This article demonstrates that it is possible to obtain significant 
performance differences in a Oracle Database Management System, by simply 
changing the file system and the block size. The analyzed results from 
benchmark tests exposes how these variations impacted positively and 
negatively in one of the most critical points in the hardware performance on 
the server, its hard drive. 
 
Resumo. É crescente a preocupação com o melhor aproveitamento dos 
recursos de Tecnologia da Informação, e para isso muito investimento tem 
sido feito para desenvolvimento de softwares que consigam extrair ao máximo 
os recursos computacionais disponíveis. Este artigo demonstra que é possível 
obter diferenças significantes de desempenho em um Sistema Gerenciador de 
Banco de Dados Oracle, com a simples troca do sistema de arquivos e a 
variação no tamanho dos blocos. Os resultados analisados a partir de testes 
de benchmark, mostram como essas variações impactaram positiva e 
negativamente em um dos pontos mais críticos no desempenho do hardware 
de um servidor, seu disco rígido. 
 
 
1. Introdução 
Segundo Chiavenato (2011) os avanços tecnológicos influenciaram consideravelmente 
o funcionamento das organizações a partir da Revolução Industrial, desde o resultado da 
aplicação da força motriz do vapor, que logo substituiu o esforço humano nas fábricas e 
indústrias. No final do século XVIII, a invenção da máquina de escrever acelerou o 
processo produtivo literário e consequentemente a quantidade de informação gerada. A 
 
v1.5 – 30OUT16 
 
 
invenção do telefone, no final do século XIX, aprimorou a comunicação e permitiu às 
organizações se descentralizarem e buscarem por novos rumos e mercados. O 
desenvolvimento tecnológico da segunda metade do século XX nos fez chegar ao 
computador, com ele as possibilidades de administrar grandes números e diferentes 
negócios simultaneamente a um custo mais baixo e com maior rapidez e absoluta 
confiabilidade. 
Em pleno século XXI, diante de um mercado agitado por novas soluções 
tecnológicas, investir em Tecnologia da Informação (TI) tem sido um desafio aos 
administradores, pois inovação não custa pouco, os ativos comprometidos na aquisição, 
treinamento e implantação são potencialmente altos, a explicação para isso é que os 
primeiros a aderirem à novidade tecnológica serão os que pagarão os altos custos em 
pesquisa e desenvolvimento (P&D) do produto, e quanto mais inovador ele se mostrar, 
maior o risco dele ser efêmero, caso o mercado não absorva essa nova tecnologia ou 
enquanto ela está sendo propagada, ocorra outra que a torne obsoleta. Tendo 
consciência dos riscos de fazer uma escolha equivocada e das poucas janelas de 
oportunidades para novos investimentos em TI, a capacidade técnica e do profissional 
em TI é colocada à prova dentro da organização e é neste momento que ela pode fazer a 
diferença, tanto para a empresa como para a carreira desse profissional. 
O objetivo deste trabalho é demonstrar de maneira sistemática, que é 
possível obter diferenças de desempenho no uso de um mesmo banco de dados apenas 
com a mudança do sistema de arquivos e do tamanho dos blocos em um disco, de modo 
que as informações deste sirvam como apêndice ao administrador de banco de dados 
(DBA - abreviação do termo em inglês: DataBase Administrator) no momento que este 
tiver a oportunidade de optar pelo sistema de arquivos utilizado no Banco de Dados 
Oracle que administra, seja durante a implantação de um novo Sistema Gerenciador de 
Banco de Dados (SGBD), seja quando faz uma ampliação de um sistema já existente, 
ou até mesmo buscando extrair maior desempenho do hardware que tem em mãos, 
recurso que vai além do tradicional ‘tunning’ do Banco de Dados, desta maneira 
postergando maiores investimentos por parte da organização na aquisição novos de 
materiais de hardware, agregando maior valor na gama de serviços e atribuições do 
profissional em TI em sua atividade fim. 
 
 
2. Fundamentação Teórica 
2.1. Banco de Dados 
A abstração de um Banco de Dados pode ser definida como uma coleção de conjuntos 
correlacionados de dados. De tal forma que são monitorados, examinados e manuseados 
conforme uma análise técnica detalhada. Para Silberschatz, Korth e Sudarshan (2006) é 
 
v1.5 – 30OUT16 
 
 
considerado como modelo de Banco de Dados Relacional, um conjunto de dados que 
contém uma estrutura denominada informalmente de tabela por linhas e colunas e as 
relações entre essas tabelas. Deitel H., Deitel P. e Choffnes (2005) afirmam que Banco 
de Dados é uma coleção de dados integrada com controle centralizado, com um sistema 
combinado entre hardware aonde ficam armazenados os dados e software que faz o 
controle de acesso, denominado Sistema Gerenciador de Banco de Dados (SGBD). 
Como diferencial um Banco de Dados privilegia a eliminação de redundâncias, o SGBD 
organiza os dados de acordo com seus conteúdos em vez de nomes de caminhos, utiliza 
técnicas padronizadas de organização de dados sendo elas geralmente relacionais ou 
orientadas à objetos, conforme o caso. 
 Independente da técnica padronizada na organização dos dados, atualmente 
esse é o modelo o mais usual adotado pelo mercado, a qual representa a interpretação da 
modelagem dos dados, procurando simular/traduzir de fato o que acontece no mundo 
real de maneira simples. 
 
2.2. Sistema de Arquivos 
Segundo Jones (2007) um sistema de arquivos é uma organização de dados e metadados 
em um dispositivo de armazenamento. Morimoto (2005) diz que um sistema de 
arquivos é um conjunto de estruturas lógicas e de rotinas, que permitem ao Sistema 
Operacional (SO) controlar o acesso ao disco rígido. 
 Para Deitel H., Deitel P. e Choffnes (2005) um sistema de arquivos organiza 
arquivos e gerencia o acesso aos dados, eles são responsáveis por fornecer os 
mecanismos para que os arquivos sejam armazenados com segurança, garantindo a 
integridade das informações armazenadas, assim sendo os arquivos devem conter 
somente as informações neles depositadas. Os sistemas de arquivos são voltados 
principalmente para o gerenciamento do espaço do dispositivo de armazenamento, mas 
também podem acessar dados de arquivos armazenados em outros dispositivos (como a 
memória principal: memória RAM). Sistemas de arquivos devem exibir de forma 
independente os dispositivos de armazenamento, de forma que os usuários possam se 
referir aos arquivos por nomes simbólicos/lógicos (como 
“meudispositivo\minhapasta\meuarquivo.txt”), sem se preocuparem com os aspectos 
físicos de armazenamento nos dispositivos. Assim os usuários podem criar, modificar e 
eliminar arquivos, como também compartilhá-los, controlando permissões de leitura, 
gravação e execução de forma segura. 
 Em ambientes Windows os Sistemas de Arquivos conhecidos são o FAT16, 
FAT32 e NTFS, sendo que segundo a Microsoft (2001) a FAT16 (também conhecida 
por apenas FAT, originária do inglês ‘File Allocation Table’ – Tabela de Alocação de 
Arquivos) foi introduzida com a criação do MS-DOS em 1981, inicialmente para lidar 
com arquivos em disquetes, passou por pequenas alterações para trabalhar com discos 
 
v1.5 – 30OUT16 
 
 
rígidos, tem por característica ter seus arquivos nomeadosno formato 8.3, ou seja oito 
caracteres de nome do arquivo, seguido de um ponto, mais uma extensão de três 
caracteres que identifica o programa vinculado ao arquivo, sua limitação é de blocos de 
até 32KB e partições de até de 2GB. 
 A FAT32 foi introduzida junto com o Windows 95 Service Release 2 em 
1996, elaborada como uma extensão à FAT16, a qual passou a ser de 32 bits, e por isso 
esse nome, tem como característica a capacidade de administrar uma quantidade muito 
maior de blocos por partição, tendo 4GB como limite de tamanho de um único arquivo. 
O NTFS foi introduzido com a primeira versão do Windows NT, é completamente 
diferente do padrão FAT, oferecendo melhorias em segurança, compactação, cotas e 
criptografia de blocos, passou a ser padrão a partir do Windows XP e não sofre com as 
limitações descritas anteriormente, segundo Microsoft (2013) os nomes de diretório 
podem ter até 255 caracteres de comprimento, de arquivo podem ter até 253 caracteres, 
a partição de inicialização pode ter até 7,8GB e uma limitação de 2TB por partição. 
 Ambientes Linux os Sistemas de Arquivos mais populares são o XFS, 
EXT2, EXT3, EXT4, RaiserFS e BTRFS, por se tratar de um Sistema Operacional de 
código aberto, seus desenvolvedores estão espalhados pelo mundo e suas distribuições 
são desenvolvidas de acordo com as necessidades detectadas por cada um deles, 
fazendo com que a variedade de Sistemas de Arquivos seja ainda maior. Segundo Jones 
(2008) o XFS foi criado pela Silicon Graphics em 1995 para o Sistema Operacional 
IRIX, em 2001 o sistema de arquivos foi inserido ao Linux, pois já era desenvolvido e 
confiável, tanto que até hoje ainda é utilizado, segundo Silva (2016), é capaz atualmente 
de ter arquivos de 8 exabytes e partições de até 16 exabytes. De acordo com Jones 
(2009), o Linux quando criado tinha como Sistema de Arquivos o Minix, herdado de 
um Sistema Operacional de mesmo nome, que por sua vez se originou como uma 
vertente do Unix, porém o Minix apresentava problemas significativos de desempenho, 
por isso criou-se o Sistema de Arquivos Estendido o EXT, que foi introduzido em 1992 
ao Linux, este já era capaz de suportar arquivos de até 2GB, porém já em 1993 o EXT2 
foi integrado ao Sistema Operacional, como uma evolução à sua primeira versão, uma 
das mudanças foi a capacidade de ter arquivos de até 2TB, ainda se combinado com o 
kernel 2.6 extendido era capaz de ter arquivos de até 32TB, algo impensável para a 
época. 
 Em 2001 foi a vez do EXT3 ser parte do Linux, este por sua vez trouxe 
alguns avanços importantes, como journaling, que tornou o sistema operacional mais 
robusto e confiável em caso de paradas bruscas, recuperando o arquivo que estava 
aberto e/ou evitando a perda do arquivo, como ocorria nas versões anteriores deste. Em 
sua última atualização o Sistema de Arquivos Estendido está na versão 4, o EXT4, que 
se encontra no pacote de instalação do Linux desde 2008, vieram novos avanços 
voltados à maior confiabilidade, desempenho e confiabilidade, o tamanho máximo de 
um arquivo no EXT4 é de 1 exabyte. 
 
v1.5 – 30OUT16 
 
 
 O RaserFS foi introduzido ao código Linux em 2001, uma de suas 
curiosidades é que quando um arquivo é menor que o tamanho do bloco, esse sistema de 
arquivos tem como recurso nativo a capacidade de juntar mais de um arquivo em um 
mesmo bloco, com isso há um desperdício menor de espaço em disco, na ordem de 5%, 
esse sistema de arquivos também teve atualizações, sendo a versão 4 a mais atual, 
porém o RaserFS tem caído em desuso por várias distribuições Linux, devido um 
problema do seu criador/desenvolvedor teve com a justiça, por isso seu 
desenvolvimento foi interrompido e também pela comunidade Linux ter encontrado em 
outros Sistemas de Arquivos as funcionalidades por ele oferecida. 
 Segundo Abreu (2012), o BRTFS foi criado a partir 2007 pela Oracle 
Corporation, tendo à frente como um de seus principais desenvolvedores Chris Mason, 
que foi engenheiro desenvolvedor que trabalhou no RaserFS para SUSE (uma das 
grandes distribuidoras Linux), introduzido no Sistema Operacional em 2009, seu 
objetivo é torna-lo 100% eficaz em tolerância de falhas e erros, tem um recurso 
interessante que merece ser destacado o snapshot, que é a capacidade de congelar um 
sistema criando uma duplicata, para ser recuperada posteriormente, o tamanho máximo 
de arquivo no BTRFS é de 16 exabytes. 
 
2.3. Sistemas de Benchmark 
Conforme Iata (2008) no final dos anos 70 os executivos da Xerox necessitavam 
entender como um concorrente japonês era capaz de oferecer impressoras de alta 
qualidade por preços inferiores aos seus custos de produção, para tal criaram um 
processo de análise da concorrência e comparação dos resultados, que se deu o nome de 
benchmarking. Morimoto (2005) conceitua benchmark já aplicado na computação, 
porém de forma ampla, como “programas usados para medir o desempenho de um 
computador”. Ferreira e Barros (2007) menciona benchmark como um ou mais 
programas que executados chegam à resultados que tornam possível realizar 
comparações de desempenho de programas que executam uma tarefa em uma mesma 
configuração de hardware. 
 Voltado à banco de dados, segundo DeWitt (tradução nossa) em 1981 
buscava-se criar um referencial para comparação de banco de dados relacionais, de 
modo que pudessem analisar seu desempenho, porém não podiam imaginar como isso 
se tornaria tão popular. Creditou-se que o principal fator de seu sucesso era que ali 
estava a primeira forma de avaliar com medidas imparciais de produtos reais. O 
benchmark desencadeou uma série de “guerras de referências” entre banco de dados 
comerciais. 
Percebe-se que softwares de benchmark buscam resultados através de 
comparações de padrões pré-estabelecidos em um referencial. Segundo o Transaction 
Processing Performance Council (2016), o TPC é uma corporação sem fins lucrativos, 
 
v1.5 – 30OUT16 
 
 
fundado para definir processamento de banco de dados e parâmetros de referência da 
transação e fornecer resultados confiáveis para a indústria, através de seus programas 
benchmark utilizados amplamente por seus membros e filiados. A Dell está entre os 
membros efetivos do TPC, ela fornece o software de benchmark Benchmark Factory 
7.3.0 x64, de fácil assimilação e ambiente bastante intuitivo, utilizado neste trabalho. 
 
2.4. Disco Rígido Magnético (Hard Disk - HD) 
Deitel H., Deitel P. e Choffnes (2005) afirmam que em 1957 a IBM trouxe ao mercado 
o primeiro disco rígido magnético, chamado de RAMAC (Randon Access Method os 
Accounting and Control - método de contabilidade e controle de acesso aleatório), 
tinham a grande vantagem de não ter dados gravados sequencialmente, como nas fitas 
magnéticas, podendo ter suas cabeças movimentadas em frações de segundo entre o 
começo e o fim da mídia rotativa, algo impensável de ser realizado com um rolo de fita, 
as primeiras unidades do RAMAC tinham a capacidade total de cinco megabytes e 
custavam US$ 50 mil. 
 Segundo Tanenbaum (2007) um disco rígido magnético gira em velocidade 
fixa e constante, há disponíveis no mercado discos de velocidades rotacionais entre 
5400 e 10.800 RPM de acordo com a marca, modelo e interface de comunicação, estes 
discos tem sua superfície coberta por óxido de ferro, a qual é dividida em trilhas, que se 
assemelham à anéis (círculos concêntricos, iniciam e terminam em si mesmos, não 
formam espirais), a contagem delas começa da borda do disco (trilha 0) e são sucedidas 
por outras em direção ao centro do disco, que são cada vez menores (mais curtas). 
 De acordo com Hennessy e Patterson (2003) em geral um disco tem de 
5.000 à 30.000 trilhas por superfície, essas trilhas estão subdivididas em setores, em 
razão de uma estratégia adotada pelos fabricantes para melhor aproveitamento da 
superfície do disco, utilizada atualmente, chamada de densidade de bits constante, que 
consiste na variaçãoda quantidade de setores de acordo com o tamanho da trilha, dessa 
maneira a trilha mais externa contém mais setores do que as mais internas, então mais 
dados, afinal os setores tem tamanhos praticamente iguais do centro à borda, a diferença 
na quantidade de setores entre as extremidades interna e externa do disco chega à razão 
de 1,7 vez mais bits na porção mais externa. 
 Lembrando que a velocidade rotacional do disco é fixa, os dados nas bordas 
são lidos/gravados com velocidades superiores na ordem de até 70%, quando 
comparadas com às taxas obtidas nas trilhas mais internas. 
 
2.5. Disco de Estado Sólido (Solid State Disk - SSD) 
Morimoto (2011) afirma que os SSD representam a maior revolução em armazenamento 
desde o primeiro disco da IBM, afinal seu princípio de funcionamento é completamente 
 
v1.5 – 30OUT16 
 
 
diferente, com os discos magnéticos dando lugar aos chips de silício utilizados nas 
memórias flash. Uma das vantagens mais óbvias dos SSD são os tempos de acesso 
muito baixos, altas taxas de transferência nas leituras e gravações, mesmo em ordem 
aleatória. Outros pontos de destaque são o baixo consumo, o silencio no funcionamento, 
a resistência a choques físicos e por isso maior segurança aos dados, justamente por não 
conter partes móveis em seu interior. 
 Conforme Alecrim (2013) o mercado presenciou evoluções espantosas no 
desempenho das memórias RAM e dos processadores, enquanto que nos HDs isso 
ocorreu mais na capacidade de armazenamento do que no desempenho, as aplicações 
modernas precisavam de um armazenamento mais veloz, com menor consumo de 
energia e maior durabilidade, que fosse capaz de apresentar uma capacidade razoável de 
armazenamento, o SSD foi uma resposta à essas necessidades. Apesar de aceitar-se que 
o nome faz uma alusão à ausência de peças móveis em seu interior, o termo “Estado 
Sólido” diz respeito ao uso de material sólido para o transporte dos sinais elétricos entre 
transistores, ao invés de tubos de vácuo, como ocorriam nas válvulas. No SSD o 
armazenamento é feito em chips de memória, não há peças em movimento ou motores 
para garantirem seu funcionamento, isso acaba por fazer com que eles sejam mais 
econômicos no consumo de energia. A tecnologia SSD é baseada em chips criados para 
armazenar dados, mesmo que ocorra ausência de energia, portanto, pode-se dizer que 
são dispositivos não voláteis de armazenamento de dados. O SSD tem maior resistência 
térmica e à choques físicos, apesar de não ser indestrutível. Os custos de SSD, 
comparado à um HD ainda são muito elevados, porém acredita-se que os avanços 
proporcionados pela tecnologia SSD são irreversíveis. 
 
2.6. Impactos do Sistema de Arquivos e do Disco no Desempenho de um Banco de 
Dados 
Segundo Ramakrishnan e Gehrke (2011), o tempo de leitura e gravação varia 
dependendo do tempo de acesso (que resulta da equação: tempo de acesso = tempo de 
busca + latência rotacional + tempo de transferência), que sugere que o tempo gasto 
para operações de um banco de dados é afetado significativamente pela maneira como 
os dados estão armazenados no disco. Considerando que a memória de um sistema 
computacional é organizada através de uma hierarquia onde as mais velozes e caras 
estão no topo e as mais lentas e de menor custo estão na base, então obedecendo essa 
lógica no topo, temos as memórias cache do processador e a memória RAM, mais caras 
e voláteis. 
No meio dessa cadeia hierárquica estão as memórias dos discos rígidos e 
SSD, mais lentas se comparadas às primeiras, porém mais acessíveis e não voláteis, e 
por último temos o armazenamento em fita e discos óticos. Como os Bancos de Dados 
precisam ser armazenados em ambientes não voláteis, os melhores dispositivos de 
 
v1.5 – 30OUT16 
 
 
armazenamento são os SSD e os discos rígidos, nesta ordem, neles o SGBD opera lendo 
ou gravando nos blocos, esse procedimento é chamado de operação E/S (entrada/saída), 
a velocidade que isso ocorre está diretamente ligada à capacidade do tempo de acesso, 
quanto menor esse tempo, melhor o desempenho global do SGBD. 
 
 
3. Materiais e Métodos 
Para realização dos experimentos, foi adotado o método da análise descritiva qualitativa 
para comparação dos resultados dos testes de desempenho entre os sistemas de 
arquivos. 
Separaram-se os testes de desempenho em dois momentos distintos, o que 
chamaremos de testes prévios ou testes iniciais, os quais tiveram como foco demonstrar 
as diferenças de desempenho obtidas a partir das variações dos sistemas de arquivos e 
tamanho de blocos em um mesmo disco rígido, com resultados apresentados como parte 
do Método, os quais fomentaram a elaboração de um trabalho mais completo e voltado 
à verificar se as mesmas variações se aplicam ao Banco de Dados Oracle com o uso de 
um SSD, que será chamado de Testes Principais. 
Utilizou-se um computador doméstico, com a seguinte configuração: 
processador Intel Core 2 Quad Q8300, 8GB DDR3 de memória RAM. Como 
dispositivos de armazenamento foram adotados dois drives SSD (um deles com o SO e 
outro com o Sistema Gerenciador de Banco de Dados), em detrimento de um HD 
tradicional, conforme vantagens descritas no item 2.5. 
 Levando em consideração que cada file system tem sua própria estratégia 
no gerenciamento do posicionamento dos arquivos na mídia, baseados na 
fundamentação do item 2.4., que explica o porquê o posicionamento do arquivo na 
mídia em disco magnético interfere no desempenho durante a leitura/gravação de 
arquivos, se fosse utilizado um disco rígido magnético seria apresentada uma nova 
variável de difícil controle à qual não poderia ser desconsiderada, de tal modo que 
acabaria por obstruir uma comparação real e imparcial de desempenho. 
 Foram realizados testes prévios de desempenho de disco, com um disco 
rígido magnético de 1TB (um terabyte) e 7200RPM, os quais demonstraram que ao 
fazer uso de três file systems (NTFS, FAT16 e FAT32), apenas ao modificando o 
tamanho da unidade de alocação (bloco) com tamanhos entre 512B e 64KB, obtivemos 
diferenças significativas de desempenho acima dos 30%, do melhor em relação ao pior 
desempenho obtido. Na ocasião foi utilizado o mesmo computador doméstico descrito, 
no disco foram criadas pequenas partições de 10GB (dez gigabytes), exceto a FAT16 
que tem limite de tamanho em 2GB (dois gigabytes), para pormenorizar os efeitos do 
posicionamento dos dados na mídia, os softwares de benchmark foram o Roadkill’s 
 
v1.5 – 30OUT16 
 
 
Disk Speed v 1.0 e CrystalDiskMark v 3.0.3 x64 funcionando em ambiente Windows 7, 
conforme resultados tabulados nas figuras à seguir. 
 
Figura 1. Benchmark de um disco rígido (HD) com variações de sistemas arquivos e 
tamanho de blocos 
 Na Figura 1 é possível verificar um mesmo disco formatado com o Sistema 
de Arquivos NTFS com blocos de 512 bytes e com compactação ativada chega a ser 
31,73% mais rápido que o mesmo disco formatado com FAT16 e blocos de 32KB na 
Leitura Linear (segunda linha na penúltima coluna). Também é possível constatar que 
nos testes iniciais com a partição NTFS utilizando blocos de 512 bytes e com 
compactação ativada é capaz de ser 39,68% mais rápida se comparada a uma partição 
FAT32 nos testes de desempenho de Leitura Aleatória (segunda linha na última coluna). 
Figura 2. Benchmark de um disco rígido (HD) com variações de sistemas arquivos e 
tamanho de blocos 
 Na Figura 2, verifica-se que o menor desempenho está com o Sistema de 
Arquivos FAT16, tanto para leitura, como para gravação, por isso nas duas últimas 
colunas apresenta 0%, pois os índices obtidos em ambos os testes foram referência para 
os outros. Novamente o mesmo disco formatado com o Sistema de Arquivos NTFS, 
adotando blocos de 512 bytes e com compactação ativada obteve melhor desempenho, 
sendo 31,56% superior na leitura e 30,35% na gravação, quando comparado com o 
Sistema de Arquivos de menor desempenho. 
MBLidos¹ Velocidade¹ MB Lidos¹ Velocidade¹ Qt Acessos Tp Acesso²
NTFS 512 608,5625 121,6647 16,8125 3,3611 562 8,90 27,78 8,91
NTFS 512 Compact 627,3750 125,4701 21,5625 4,3099 745 6,71 31,73 39,68
NTFS 4K 595,3125 119,0567 19,7813 3,9501 638 7,84 25,00 28,14
NTFS 4K Compact 599,0625 119,8035 17,8438 3,5649 653 7,66 25,79 15,59
NTFS 16K 573,5625 114,7117 15,7188 3,1432 515 9,71 20,43 1,82
NTFS 64K 561,5625 112,3073 20,8125 4,1577 729 6,86 17,91 34,82
FAT16 476,2500 95,2443 16,4063 3,2733 491 10,20 0,00 6,28
FAT32 496,6875 99,3373 15,4375 3,0774 581 8,62 4,29 0,00
¹ Megabytes por segundo (MB/S)
² Tempo em segundos e centésimos de segundo
³ Valores Percentuais em relação ao menor valor
Variação 
Linear³
Variação 
Aleatória³
Roadkil's Disk Speed Version 1.0
Leitura Linear Leitura Aleatória Tempo de Acesso
Leitura Gravação Leitura Gravação Leitura Gravação Leitura Gravação
NTFS 512 128,4 128,0 50,42 72,29 0,643 1,290 0,745 1,310 28,55 28,64
NTFS 512 Compact 131,4 129,7 51,57 72,38 0,658 1,304 0,712 1,289 31,56 30,35
NTFS 4K 125,4 124,4 49,96 68,09 0,640 1,236 0,711 1,264 25,55 25,03
NTFS 4K Compact 125,5 124,9 49,98 68,89 0,635 1,295 0,730 1,241 25,65 25,53
NTFS 16K 121,3 120,0 49,30 66,05 0,618 1,279 0,715 1,278 21,45 20,60
NTFS 64K 117,7 117,0 48,97 68,08 0,647 1,295 0,728 1,258 17,84 17,59
FAT16 99,9 99,5 45,39 63,87 0,606 1,228 0,712 1,240 0,00 0,00
FAT32 104,6 103,9 47,07 63,83 0,631 1,233 0,721 1,185 4,73 4,42
Variação 
% Grav 
Variação 
% Leitura 
CrystalDiskMark 3.0.3 x64
Sequencial 512K 4K 4K QD32
 
v1.5 – 30OUT16 
 
 
 Para realização dos Testes Principais, adotou-se a variação no tamanho dos 
blocos, com duas medidas disponíveis em todos os file systems testados, apesar do 
NTFS fornecer grande flexibilidade no tamanho de seus blocos, a FAT32 é mais 
limitada, por isso, os blocos tiveram que ser de 4KB, 8KB e 64KB. Por acreditar-se que 
quanto menor o tamanho do bloco, menores serão as perdas de espaço em disco, em 
razão do comprometimento de todo o espaço alocado por bloco ser dedicado à apenas 
um arquivo, assim sendo, se este arquivo for muito pequeno, o espaço restante é 
inutilizado, portanto, quanto maior o bloco, maior a perda de espaço alocado nesse caso, 
para comprovar essa hipótese o bloco menor de 4KB. 
 Por outro lado, crê-se que quanto maior o bloco, menor a quantidade total de 
blocos no disco a serem administrados, partindo dessa concepção, menos blocos 
garantem uma manipulação mais rápida por parte do sistema de arquivos, por isso a 
opção por um bloco maior de 64KB. Para uma opção intermediária e balanceada entre 
ambas hipóteses, a escolha pelo bloco de 8KB. Abriu-se mão de testar o sistema de 
arquivos FAT16, em razão do SGBD Oracle criar um BD “Esquema” praticamente do 
tamanho do drive de 2GB, pouco restando para o teste do benchmark, impossibilitando 
seu uso. 
 Como ao invés do disco magnético (HD) de 1TB (um terabyte), dos testes 
iniciais, optou-se desenvolver esse trabalho com dois discos SSD de 120GB (cento e 
vinte gigabytes), chamaremos o primeiro por “SSD1”, o qual teve o SO, SGBD e 
Benchmark instalados, o segundo chamaremos de “SSD2”, neste foi instalado apenas o 
Banco de Dados, com as diferentes formatações de sistemas de arquivos e tamanhos de 
blocos, já descritas, para a realização de cada teste. 
 Com os SSD em atividade optou-se pelo uso da mesma metodologia de 
criação de seis partições de 10GB (dez gigabytes) no SSD2, cada uma com a variação 
do sistema de arquivos e blocos proposta, realizou-se a manipulação da pasta do banco 
de dados, copiando e colando-a de uma partição para a outra, permitindo que o SO 
somente ‘enxergasse’ uma partição, como se sempre fosse a mesma, inclusive com a 
mesma letra de drive no Windows, para tal foi necessário fazer uso de um Live CD, que 
é um disco óptico de boot (inicialização autônoma de um SO), com um pacote de 
ferramentas conhecido por Hiren’s Boot CD v15.2 o qual contém um módulo de 
manipulação de partições chamado de GParted, que funciona em ambiente Linux. 
 Porém seguindo essa metodologia, os testes apresentaram resultados com o 
desempenho cada vez melhor em relação ao teste da partição anteriormente testada. 
Para entender o fenômeno de aumento de desempenho, após ter realizado todos os seis 
testes propostos com cada uma das partições, somente o primeiro teste foi repetido e 
apresentaram-se diferenças do mesmo teste, que teoricamente deveria ser idêntico. Logo 
percebeu-se que os resultados estavam sendo otimizados à cada novo teste, pois à cada 
nova repetição, o SGBD Oracle DataBase 11g Release 2 tinha seu otimizador atuando 
na melhora do funcionamento do Banco de Dados utilizado pelo benchmark. Para evitar 
 
v1.5 – 30OUT16 
 
 
a atuação desse otimizador se fez necessária a modificação da metodologia inicial, à 
cada novo teste optou-se por formatar ambos os SSD, instalando novamente o SO do 
zero, com o SGBD e Benchmark no SSD1 e formatar o SSD2 com uma única partição 
para uso do Banco de Dados Oracle, utilizando o sistema de arquivos à ser testado, 
ainda assim o teste foi realizado apenas uma vez após cada nova instalação limpa. 
 Com isso foi possível isolar a possibilidade de que o otimizador do SGBD 
alterasse os resultados, pois não havia gravado registro algum de manipulação do Banco 
de Dados Oracle, desta forma acredita-se que esse trabalho teve total e absoluta exatidão 
nos resultados obtidos em cada um dos testes realizados. Cabe ressaltar que todo esse 
trabalho foi desenvolvido em um ambiente real, sem o uso de máquinas virtuais (VM), 
para que um SO (hóspede) não fosse subordinado a outro SO (hospedeiro) e que todos 
os recursos de hardware disponíveis fossem utilizados efetivamente para os testes de 
desempenho. 
 Portanto os sistemas de arquivos e blocos utilizados nesse trabalho durante 
os Testes Principais foram conforme o apresentado na Figura 3: 
 
Figura 3. Sistema de Arquivos e Tamanho de Blocos 
 
 
4. Resultados Obtidos 
Durante os experimentos com o Dell Benchmark Factory versão 7.3.0 x64 na versão 
Trial, verificou-se uma grande variedade de módulos de testes (TPC-B, TPC-C, TPC-D, 
TPC-E, TPC-H, Replication, Scalable Hardware, AS3AP). Para se chegar à escolha de 
qual módulo a ser utilizado, foi testado um a um dos módulos disponíveis, em busca de 
um que apresentasse resultados de carga expressivos de uso de disco e processador, 
porém nenhum deles registrou carga nos volumes de dados gravados e lidos do disco. 
 Ainda assim com o processador e SSD ‘ociosos’ (muito abaixo de seus 
limites físicos) durante os registros dos Testes Principais, foi possível mensurar as 
diferenças entre os sistemas de arquivos, bem como quando feita a variação do tamanho 
de blocos. O mais apropriado dentre os módulos de testes apresentados foi o TPC-C, 
que simula um ambiente completo de computação, onde um servidor recebe várias 
solicitações de usuários distintos (1, 4, 8 e 10 usuários), cada qual consultando (select), 
atualizando (update) e/ou inserindo (insert) dados em um Banco de Dados 
simultaneamente, criado para simular ambientes voltados à indústria de atacado e/ou 
varejo durante a entrada e saída de produtos comprados e vendidos. Nele foi possível 
extrair a taxa de transmissão de dados, durante a leitura e gravação do mesmo banco de 
Sistema de arquivos
Tamanho dos blocos 4KB 8KB 64KB 4KB 8KB 64KB
NTFS FAT32
 
v1.5 – 30OUT16 
 
 
dados Oracle na ordem de KB/S (Kilobytes por Segundo), conforme serão apresentados 
nos gráficos tabulados nos resultados à seguir. 
 
 
Gráfico 1. Comparativo dos testes de leitura 
 
 Percebe-se que diferentemente do apresentado nos benchmarks de disco, 
realizados com um disco rídigo de 1TB (Figura 1), em que a ordem de transferência de 
dados chega a ser de 600MB/S numa leitura linear, foi apresentada abaixo de 3KB/S e 
se repetiu a cada teste com resultados muito próximos entre um teste e outro, mostrandoque realmente o benchmark é teste de ‘caixa preta’, que analisa o disco, mas não 
prioriza sua medição, pois claramente os registros de desempenho mostraram apenas as 
transações (select, insert e update) de usuários não a criação e população das tabelas, 
quando claramente o disco e o processador foram efetivamente exigidos, sem permitir 
que o usuário opte por qual instante quer realizar a medição de desempenho. Assim 
sendo, temos a aparência que o sistema de arquivos NTFS não apresentou grandes 
melhorias de desempenho com a variação do tamanho dos blocos, ao contrário, a 
FAT32, teve em sua opção de blocos intermediária (8KB), maior desempenho para 
todas as variações de usuários. 
 Da mesma maneira como foi descrita no teste de leitura, a ordem de 
transferência de dados durante os testes chegou a valores próximos a 5KB/S, muito 
inferiores à capacidade de um SSD, que facilmente ultrapassaria os 300MB/S. 
Curiosamente na gravação o sistema de arquivos NTFS apresentou diferenças de 
desempenho conforme variaram-se o tamanho dos blocos, sendo que independente da 
2,1
2,2
2,3
2,4
2,5
2,6
2,7
2,8
2,9
3
1 usuário
4 Usuários
8 usuários
10 usuários
2,47
2,62
2,46
2,6
2,69
2,5 2,55
2,66
2,742,65
2,71
2,78
2,84
2,74
2,8
2,86
2,91
2,43
2,51
2,57
2,66
NTFS 4K
NTFS 8K
NTFS 64K
FAT32 4K
FAT32 8K
FAT32 64K
Benchmark Factory - TPC-C - Taxa de Leitura (em KB/S)
KB/S
 
v1.5 – 30OUT16 
 
 
quantidade de usuários o bloco de 8KB foi o de menor performance, enquanto que o 
bloco de mesma medida apresentou a melhor performance no sistema de arquivos 
FAT32. 
 
Gráfico 2. Comparativo dos testes de gravação 
 
 Para visualizar com maior clareza as diferenças nos resultados obtidos, 
estão apresentados os resultados em percentuais, tomando-se como referência o menor 
valor obtido na leitura e na gravação, fixando-o em 0% (sem ganho de performance), 
todos os outros resultados da mesma coluna apresentam valores percentuais positivos, 
para demonstrar com maior clareza as diferenças obtidas, conforme Figura 4: 
 
Figura 4. Comparativo dos testes de leitura (read) e gravação (write) em % 
3,8
4
4,2
4,4
4,6
4,8
5
5,2
1 usuário
4 Usuários
8 usuários
10 usuários
4,38 4,44
4,67
4,85
4,26 4,32
4,4
4,73
4,36 4,42
4,8
4,87
4,7 4,75
4,82
4,98
4,75 4,8
4,87
5,03
4,23 4,31
4,66 4,73
NTFS 4K
NTFS 8K
NTFS 64K
FAT32 4K
FAT32 8K
FAT32 64K
Benchmark Factory - TPC-C - Taxa de Gravação (KB/S)
KB/S
% Read % Write % Read % Write % Read % Write % Read % Write
NTFS 4K 1,646 3,546 1,594 3,016 1,946 6,136 1,128 2,537
NTFS 8K 1,235 0,709 1,594 0,232 1,167 0,000 1,128 0,000
NTFS 64K 2,881 3,073 1,594 2,552 3,502 9,091 3,008 2,960
FAT32 4K 9,053 11,111 7,968 10,209 8,171 9,545 6,767 5,285
FAT32 8K 12,757 12,293 11,554 11,369 11,284 10,682 9,398 6,342
FAT32 64K 0,000 0,000 0,000 0,000 0,000 5,909 0,000 0,000
8 usuários 10 usuários
Benchmark Factory - TPC-C
1 usuário 4 Usuários
Sist. Arquivos
 
v1.5 – 30OUT16 
 
 
5. Conclusão 
 Considerando os desafios encontrados pela constante evolução de sistemas e 
aliando-os às necessidades das organizações, a complexidade técnica de alguns sistemas 
de arquivos, quando o DBA estiver utilizando no servidor de Banco de Dados o SGBD 
Oracle combinado com o Sistema Operacional Windows terá a seu dispor os Sistemas 
de Arquivos utilizados neste trabalho. Caso constate que o uso de disco seja muito 
intenso, ou seja, que o gargalo de desempenho do SGBD está concentrado no disco, a 
recomendação é que se opte por criar um ambiente de testes com um disco formatado 
com o Sistema de Arquivos NTFS utilizando blocos de 512 bytes e compactação 
ativada, como o constatado nos testes iniciais de Benchmark de Disco (Figuras 1 e 2) e 
verificar se há diferença efetiva de desempenho que compense a substituição do sistema 
de arquivos e mudança no tamanho dos blocos. 
 Se o uso do processador não for intenso, entende-se que a melhor opção será 
pelo NTFS com blocos de 64KB, assim terá um uso menor de processamento durante as 
operações de E/S, por não utilizar algoritmos de compactação e descompactação durante 
essas operações. Se o SGBD não tiver um uso intenso do disco, como o constatado 
pelos testes de TPC-C de leitura e gravação nos Testes Principais, mas ainda assim o 
DBA necessitar de melhorar o desempenho de seu Banco de Dados, antes de se fazerem 
necessários maiores investimentos em equipamentos, sem levar em conta nenhuma 
outra variável, deverá verificar se seu disco está formatado com o sistema de arquivos 
FAT32 com blocos de 8KB, caso não o tenha feito, recomenda-se que se crie em um 
ambiente de testes um disco com essa formatação indicada e verifique os possíveis 
ganhos, no intuito de adiar um possível upgrade, pois se tratando de tecnologia, quanto 
mais se protela uma atualização, menos dispendiosa ela será. 
 Espera-se que com esse trabalho, outras mentes se sintam provocadas a 
realizar novos testes, com outros Sistemas de Arquivos, com novas variações de 
tamanho de blocos, assim como com o uso de outros Sistemas Operacionais, Sistemas 
Gerenciadores de Banco de Dados e Softwares de Benchmark, para que possam ter 
maior efetividade em verificar a velocidade de transmissão de dados entre o processador 
e o disco durante as transações reais de busca/leitura e inserção/gravação desses dados 
no Banco de Dados. 
 
 
6. Referências Bibliográficas 
Abreu, E. (2012) “Apresentando o BTRFS”, 
https://www.vivaolinux.com.br/artigo/Apresentando-o-Btrfs-Nova-geracao-de-
sistema-de-arquivos-para-GNU-Linux, Outubro. 
 
v1.5 – 30OUT16 
 
 
Alecrim, E. (2014) “O que é SSD (Solid State Drive)?”, 
http://www.infowester.com/ssd.php, Outubro. 
Chiavenato, I. (2011) “Introdução à Teoria Geral da Administração”, Rio de Janeiro, 
Elsevier, 8ª edição. 
Deitel, H. M.; Deitel, P. J.; Choffnes, D. R. (2005) “Sistemas Operacionais”. São Paulo, 
Pearson Prentice Hall, 3ª edição. 
Dewitt, D. J. (2014) “The Wisconsin Benchmark: Past, Present and Future”, 
http://research.microsoft.com/en-us/um/people/gray/benchmarkhandbook/chapter4. 
 Pdf, Outubro. 
Ferreira, J. L. e Barros, R. (2014) “Benchmark”, 
http://www.comp.pucpcaldas.br/users/joao.ferreira/benchmark/sobre.html, Outubro. 
Hennessy, J. L, e Patterson, D. A. (2003) “Arquitetura de Computadores: Uma 
Abordagem Quantitativa”, Rio de Janeiro, Campus, 3ª edição. 
Iata, C. (2014) “Benchmarking: Muito além de uma simples comparação”, 
http://pontogp.wordpress.com/2008/12/24/benchmarking-muito-alem-de-uma-
simples-comparacao/, Outubro. 
Jones, M. T. (2007) “Anatomia do Sistema de Arquivo do Linux”, 
http://www.ibm.com/developerworks/br/library/l-linux-filesystem/, Outubro. 
_____. (2008) “Anatomia dos Sistemas de Arquivos de journaling do Linux”, 
http://www.ibm.com/developerworks/br/library/l-journaling-filesystems/, Outubro. 
_____. (2009) “Anatomia do EXT4”, 
https://www.ibm.com/developerworks/br/library/l-anatomy-ext4/, Outubro. 
Microsoft (2001) “NTFS vs. FAT: Qual é o Certo Para Você?”, 
https://www.microsoft.com/brasil/windowsxp/using/setup/expert/russel_october01.m
spx, Outubro. 
_____. (2013) “Visão geral dos sistemas de arquivo FAT, HPFS e NTFS“, 
https://support.microsoft.com/pt-br/kb/100108, Outubro. 
Morimoto, C. E. (2005) “Sistema de Arquivos” 
http://www.hardware.com.br/termos/sistema-de-arquivos, Outubro. 
_____. (2005) “Benchmark”, http://www.hardware.com.br/termos/benchmark, Outubro. 
_____. (2011) “Entendendo os SSDs”, 
http://www.hardware.com.br/tutoriais/entendendo-ssd/, Outubro. 
 
v1.5 – 30OUT16 
 
 
Ramakrishnan, R.; Gehrke, J. (2011) “Sistemas de Gerenciamento de Banco de Dados”, 
São Paulo, McGraw-Hill, 3ª edição. 
Santana, B. (2016) “Por dentro do APFS, o novo sistema de arquivos da Apple”, 
https://macmagazine.com.br/2016/06/29/por-dentro-do-apfs-o-novo-sistema-de-
arquivos-da-apple/, Outubro. 
Silberschatz, A.; Korth, H. F.; Sudarshan, S. (2006) “Sistemas deBanco de Dados”, Rio 
de Janeiro, Elsevier, 5ª edição. 
Silva, E. (2016) “Aula #15 – Os Sistemas de Arquivos XFS e BTRFS”, http://www.esli-
nux.com/2016/04/aula-15-os-sistemas-de-arquivos-xfs-e.html, Outubro. 
Souza, A. et al (2012) “Sistemas de Arquivos” 
http://universemac.blogspot.com.br/2012/04/sistemas-de-arquivos.html, Outubro. 
Tanenbaum, A. S. (2007) “Organização Estruturada de Computadores”, São Paulo, 
Pearson Prentice Hall, 5ª edição.