Bug com Unified Auditing no Oracle 12c

 
     Além da arquitetura Multitenant, outra feature que me chamou muita atenção no Oracle 12c,  foi a Unified Auditing, por 2 motivos principais:

Auditoria X Performance no Oracle Database

Olá pessoal,

     No artigo de hoje vou apresentar um assunto que faz parte do treinamento Database Performance Tuning (voltado principalmente para DBAs que precisam diagnosticar e resolver problemas de performance), onde vou falar sobre Auditoria e 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. O Grupo Pão de Açúcar, uma empresa em que eu trabalhei, tem que cumprir as exigências da SOX e por isso precisava auditar a maior parte dos sistemas, principalmente aqueles que envolvem operações financeiras.

     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, quando ele é instalado a partir do DBCA (Database Creator Assistant). 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 para aqueles que quiserem obter mais detalhes sobre o assunto;

          - FGA (Fine Grained Auditing):

             Esse tipo de auditoria  possibilita refinar a auditoria do BD, permitindo 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, 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 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, demonstraram os seguintes resultados (ver tabela abaixo): 

Fonte: Oracle Corporation

Obs.: A Oracle recomenda que você mova as tabelas de auditoria para tablespaces exclusivos, ao invés de mantê-los na localização padrão, que está dentro do tablespace SYSTEM. Mostro em detalhes como fazer isso no treinamento Database Performance Tuning.

  

CONCLUSÃO

    De acordo com os testes realizados pela Oracle, ao habilitar a 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 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 (Audit Trail 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.

Bom pessoal, por hoje é só! Espero que tenham gostado e que o artigo seja útil.

[]s