Auditoria X Performance no Oracle Database
Introdução
No artigo de hoje vou apresentar um assunto que faz parte do meu treinamento de Performance Tuning em Oracle Database 10G/11G (http://www.fabioprado.net/p/performance-tuning-oracle-database.html), voltado principalmente para DBAs que precisam diagnosticar e resolver problemas de performance, onde vou falar sobre Auditoria no BD e seus benefícios e desvantagens, com relação à performance.
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 é essencial para o negócio. Em empresas, por exemplo, que possuem ações na Bolsa de Nova York, é necessário se adequar à lei Sarbanes Oxley (SOX), e um dos requisitos necessários para isso, é auditar grande parte dos sistemas. O Grupo Pão de Açúcar, uma empresa onde eu já trabalhei, tinha que cumprir as exigências da SOX e por isso precisava auditar a maior parte dos sistemas, principalmente aqueles que envolvem operações financeiras.
Tipos de auditoria
No Oracle Database, atualmente existem 3 formas de auditar o BD:
– Auditoria Padrão:
Esse tipo de auditoria é o mais simples de usar e vem já habilitado por padrão no Oracle 11G. Os registros de auditoria podem ser gravados em uma tabela do BD (AUD$), em um arquivo do SO ou em arquivo XML. Como não é o objetivo deste artigo explicar como usá-la, sugiro a leitura do artigo COMO AUDITAR E GERAR RELATÓRIOS DE AUDITORIA EM ORACLE DATABASES (http://www.tiespecialistas.com.br/2012/04/como-auditar-e-gerar-relatorios-de-auditoria-em-oracle-databases/#.UQEp4m881Fo) para aqueles que quiserem obter mais detalhes sobre o assunto;
– FGA (Fine Grained Auditing):
Esse tipo de auditoria permite refinar a auditoria do BD. Ele permite filtrar o que a gente precisa auditar, baseando-se por exemplo, em colunas ou filtros de uma instrução SQL;
– Auditoria baseada em valor:
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 criadas pelo próprio desenvolvedor ou DBA.
Performance da auditoria
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 Database Auditing: 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.
De acordo com os testes realizados pela Oracle, ao habilitar auditoria padrão do Oracle com gravação em uma tabela do BD (Audit Trail 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 (Audit Trail Setting = DB_Extended), 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 (Audit Trail Setting = OS), pois esta configuração é a mais light, adicionando um sobrecarga média de apenas 1,39% de I/O e 1,75% de CPU.
Bom pessoal, por hoje é só!
[]s
Referências