Otimizando operações de Entrada e Saída (I/O)

O ajuste das operações de I/O é um passo fundamental segundo a metodologia recomendada para ‘Tunning’. Vou iniciar explicando o que é uma operação lógica de I/O. Quando uma consulta é processada, o processo servidor consulta os blocos necessários no Cache de Buffer do Banco de Dados (buffer cache). Todo acesso a esses blocos são operações lógicas de I/O. Isto inclui a leitura de cada bloco de uma tabela durante um full table scans, a escrita de cada linha no bloco através do comando insert, a remoção de linhas de um bloco de índice, e assim por diante.

Se o bloco acessado estiver no buffer cache, a operação lógica de I/O só consome CPU para manipular o bloco. Se este não for o caso, uma operação física de I/O é requerida para buscar os dados e trazê-los ao buffer cache. É importante salientar que uma operação física requer tanto acesso de I/O quanto CPU. Em muitos Sistemas Operacionais, os arquivos do sistema e os volumes lógicos podem significar cerca de 40% do tempo total de I/O.

E qual a importância de se observar essas operações de I/O?

I/O lógico consome muito CPU. Quanto mais operações de I/O o Banco de Dados executa, mais CPU é necessário. Além disso, toda operação requer um bloqueio para evitar o acesso ao bloco entre as sessões concorrentes. Levando em consideração que o tipo e o número de I/O lógicos são definidos no plano de execução de acordo com o comando SQL executado, e esse mesmo SQL é responsável pelo acesso aos dados através das aplicações, logo, ele passa a ter um papel importantíssimo para evitar um excesso de I/O.

Segue abaixo algumas alternativas para tentar reduzir o I/O:

• Evitar operações de I/O simultâneas - Operações simultâneas de vários usuários podem ocasionar contenção de recursos. A contenção faz com que os processos esperem até que os recursos sejam disponibilizados.
• Executar somente os comandos SQL necessários - De acordo com Craig Mullins, quase 80% dos problemas de performance em banco de dados são causados por códigos SQL mal elaborados. O foco dos comandos SQL devem ser “o que” e não “como”. O programador deve ter em mente quais são os dados necessários para sua aplicação e deixar que os otimizadores dos SGBDs ou DBAs escolham como será feito. O SQL tem extrema importância para as aplicações desenvolvidas em mais de 2 camadas. Se estes forem mal elaborados afeta diretamente o desempenho da aplicação e o que acaba impactando no negócio.
• Tente reduzir o número de I/O lógico - Para selecionar o plano de execução correto, você precisa ter certeza que há índices apropriados e um local de armazenamento adequado. O SGBD levará isso em consideração na hora de optar por um plano de execução que lê o mínimo possível de blocos. Isto é muito complicado!! Um full table scan pode utilizar menos I/O lógico do que o acesso via um determinado índice e pode utilizar muito mais em outro. O que vai definir é a identificação correta das tabelas envolvidas na query e os dados gravados nela.
• Use outras operações de I/O - Muitas consultas usam I/O lógico para recuperar dados de tabelas que possuem join. Muitos joins poderiam ser evitados, por exemplo, usando hash join ao invés de nested loop.
• Acelerando operações lógicas de I/O - I/O lógico não é tão rápido quanto acessar a memória. Muitos DBAs tem a concepção que operações lógicas de I/O são dez mil vezes mais rápido do que as operações físicas, trazendo o custo o mais próximo de zero. Isto não é tão simples assim. É verdade que uma operação simples de I/O lógico tem um custo bem menor do que o físico, porém, quando centenas de operações são feitas, a diferença do custo fica menos significante. Para acelerar o I/O lógico é necessário ter certeza que as tabelas contêm poucas linhas com apontamento para outras linhas (chained rows) e poucas linhas migradas, porque cada pedaço requer um I/O lógico adicional. E mais uma coisa, coloque sempre as colunas mais acessadas no início da tabela.

De nada adianta essas dicas se não forem bem utilizadas. Para aumentar a performance das aplicações é necessário que modifiquemos nossa maneira de pensar e agir. Devemos colocar as mãos na massa! Além das coisas que eu citei, vocês podem recriar alguns índices, apagar os que não estão sendo usados e/ou os não seletivos, reescrever os comandos SQL ineficientes, desabilitar as triggers quando essas não forem necessárias, reestruturar os dados (migração, particionamento, replicação) e muitas outras coisas. Basta correr atrás e entender o quão importante é e a diferença que isso faz em um sistema crítico.