Auditoria X Performance no Oracle Database

Por Fabio Prado
Publicado en Outubro 2013

Este artigo comenta sobre auditoria no Oracle Database, seus benefícios e desvantagens com relação à performance do BD. Para aqueles que são leigos no assunto, os recursos de auditoria em BD permitem registrar o que um ou mais usuários estão fazendo dentro do BD. É possível auditar qualquer operação ou instrução SQL de um ou mais usuários. É possível registrar, por exemplo, se um usuário fez LOGON ou LOGOFF, se ele apagou uma tabela ou se ele executou um SELECT em determinada tabela. Auditoria é um recurso poderoso que permite verificarmos o que está acontecendo dentro do BD. Se um registro importante some de uma tabela e ninguém sabe quem apagou ou ninguém quer se responsabilizar por essa perda, podemos saber exatamente quem apagou o registro, que instrução SQL foi executada e quando ele foi apagado. Em muitas empresas e sistemas, manter estes registros de auditoria é essencial para o negócio. Empresas que possuem ações na Bolsa de Nova York, por exemplo, precisam se adequar à lei Sarbanes Oxley (SOX), e um dos requisitos necessários para isso, é auditar grande parte dos sistemas.

No Oracle Database, atualmente existem 3 formas de auditar o BD:

- Auditoria Padrão:

Esse tipo de auditoria é a mais simples de usar e já vem habilitada por padrão no Oracle 11G (quando ele é instalado via DBCA). Os registros de auditoria podem ser gravados em uma tabela do BD (AUD$), em um arquivo do SO ou em arquivo XML.

- FGA (Fine GrainedAuditing):

Esse tipo de auditoria possibilita refinar a auditoria do BD, permitindo filtrar o que as empresas precisam auditar, baseando-se por exemplo, em colunas ou filtros de uma instrução SQL;

Esse tipo de auditoria possibilita refinar a auditoria do BD, permitindo filtrar o que as empresas precisam auditar, baseando-se por exemplo, em colunas ou filtros de uma instrução SQL;

Esse tipo de auditoria é totalmente criado e gerenciado por um desenvolvedor ou DBA. É o tipo de auditoria mais flexível e que também precisa de maior esforço para criar e gerenciar. A sua criação é feita através de triggers que são disparadas em eventos diversos, tais como, depois da execução de uma instrução INSERT em uma determinada tabela, e que inserem registros em tabelas de auditoria, também criadas pelo próprio desenvolvedor ou DBA.

Agora vamos à parte principal deste artigo: Evite auditar objetos do BD ou operações desnecessárias. Audite somente o que for necessário pelo tempo necessário, pois ela gera consumo adicional de CPU e I/O, e consequentemente degrada a performance do BD. Testes de auditoria padrão publicados no White Paper "Oracle DatabaseAuditing: Performance Guidelines" em 08/2010, realizados em um BD Oracle 11GR2, gerando aproximadamente 250 registros de auditoria por segundo, usando 50% da CPU antes de habilitar a auditoria, demonstraram os seguintes resultados (ver tabela abaixo):

CONCLUSÃO

De acordo com os testes realizados pela Oracle, ao habilitar auditoria padrão com gravação em uma tabela do BD (AuditTrail Setting = DB), tivemos uma degradação de 4,57% de I/O e 8,77% no consumo de CPU. Se for habilitado o modo de gravação extendido (AuditTrail Setting = DB_EXTENDED no 11G), o desempenho fica ainda pior. O consumo de I/O aumentou quase 3X e o consumo de CPU quase dobrou. Se você prioriza performance e precisa realmente habilitar auditoria, considere o uso da auditoria padrão com gravação em arquivos do SO (AuditTrail Setting = OS), pois esta configuração é a mais leve, adicionando um sobrecarga média de apenas 1,39% de I/O e 1,75% de CPU.


Postado por Fabio Prado.