Mais um blog inútil.

Bom dia,

Durante finais da decada de 80, todo e qualquer individuo que tivesse frequentado meia duzia de aulas de tuning de Oracle sabia que a forma mais simples de optimização de uma query era simplesmente eliminar os acessos físicos de  I/O (ou E/S se preferirem). Isso era o que se ensinava, mas basta pensar um pouco para perceber que "e então os memory accesses?". Alegava-se convictamente que os acessos à memoria eram tão rápidos que o seu impacto era desprezável. Isto parecia estranho no mínimo e curioso no máximo. Então toda a vida os programadores de C tentaram eliminar os acessos indevidos à memória e agora estes senhores dizem que isto é  desprezável.

É de fácil entendimento que agora tudo é mais complexo, maior e mais problemático por consequência. Mas basta pensar que os acessos à memoria consomem tempos de resposta, e muitos acessos à memoria consomem muitos tempos de resposta. Como exemplo simples, sabe-se que um CPU a 2.0GHz o code path associado a cada Oracle I/O operation (LIO) origina cerca de uma fracção de microsegundos de consumo de user-mode CPU. Logo vários milhões de LIOs consumirão fracções de segundo de tempos de resposta.
Fácilmente se percebe que excessivo LIO provoca uma quebra acentuada da escalabilidade do sistema.

Assim para tal, a medição dos tempos de resposta é vital num objectivo de performance e escalabilidade optima. Os consumidores de um serviço querem a resposta certa em menos tempo e de forma mais barata.

Ferramentas como o Resource Profiler que permitem uma decomposição dos tempos de resposta em 3 categorias principais:

* Categoria associada ao tempo de resposta
* Total consumido por acções nessa categoria
* Número de chamadas a uma determinada acção

Exemplo:

Response Time Component                Duration        # Calls     Dur/Call
----------------------------- ----------------- -------------- ------------
CPU service                    48,946.7s  98.0%        192,072    0.254835s
db file sequential read           940.1s   2.0%        507,385    0.001853s
SQL*Net message from client        60.9s   0.0%        191,609    0.000318s
latch free                          2.2s   0.0%            171    0.012690s
other                               1.4s   0.0%
----------------------------- ----------------- -------------- ------------
Total                          49,951.3s 100.0%

Com o uso de métricas como a CHR (Cache Hit Ratio) [CHR = (LIO - PIO) / LIO] e o uso dos Resource Profiles podemos perceber que muitas vezes as nossas intuições sobre o bottleneck estão efectivamente erradas.
Mais tarde se desejarem poderei descrever aqui um exemplo de como os ratios CHR sem um Resource Profile nos podem meter em grandes sarilhos :)

Obrigado,