Páginas

24 de jan. de 2013

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
    

8 comentários:

  1. Fabio, percebi que no meu banco de dados (11g R2) por padrão a auditoria vem ativa como DB, se eu passa-lo para OS, vou ter algum ganho em consultas, atualizações e inserções ?

    Obrigado !

    ResponderExcluir
  2. Jairo, a auditoria padrão do 11G vem habilitada para somente alguns eventos, como por exemplo: CREATE SESSION, CREATE USER e eventos gerais para criar ou deletar objetos. Esses eventos não influenciam nas instruções SQL, em geral. Se vc tiver alguma tabela com auditoria habilitada nos eventos SELECT, INSERT, UPDATE e DELETE, aí sim, vale a pena desabilitar a auditoria neles para otimizar a performance das instruções SQL. Eu mostro isso no treinamento "Performance Tuning Oracle Database 10G/11G"
    (http://www.fabioprado.net/p/performance-tuning-oracle-database.html)

    []s

    ResponderExcluir
  3. Olá Fabio, voce mencionou o consumo de Memoria e CPU, voce sabe me dizer qual ao aumento de disco apos habilitar a auditoria??

    Obrigado.

    ResponderExcluir
    Respostas
    1. Vitor, acho q vc se confundiu. Eu mencionei I/O e CPU e não memória.
      I/O = disco, ok??????

      []s

      Excluir
  4. Olá Fabio, existe uma formula para calcular o consumo de disco necessário para armazenamento da auditoria de uma tabela, usando o parametro AUDIT_TRAIL=DB ?

    ResponderExcluir
    Respostas
    1. Elaine, nao existe uma formula, mas da pr vc fazer uma estimativa da seguinte forma: execute um select na tabela dba_tables filtrando pelo valor AUD$ na coluna que contem o nome das tabelas. Veja a qtde media media de bytes por linha e a qtde total de linhas e multiplique pelo tamanho do bloco do tablespace dessa tabela. Depois de um determinado periodo repita o procedimento e veja o qto os dados cresceram. A partir desse valor vc tera sua projecao de armazenamento para o periodo em que vc precisara reter os registros de auditoria, ok?

      Abs

      Excluir