quinta-feira, 20 de dezembro de 2012

Movendo os objetos de auditoria para outra tablespace


A auditoria do banco de dados Oracle, quando ativada os objetos deste dispositivo, são criados nas tablespaces SYS ou SYSMAN, dependendo da versão do Oracle.

Neste artigo vamos dar uma repassada nas opções e comandos básicos de auditoria e também apresentaremos uma solução de contorno para alterar a tablespace onde os objetos de auditoria são criados.

Inicialmente é necessário ativar a auditoria, para tanto deve-se configurar o parâmetro AUDIT_TRAIL. Para essa alteração é necessário reiniciar a base de dados, porque esse parâmetro é estático.  O parâmetro AUDIT_TRAIL permite os valores indicados abaixo.

·        none – Desabilita a auditoria (valor pré configurado);
·        os – Habilita a auditoria, coletando informações pertinentes ao Sistema Operacional;
·        db – Habilita a auditoria, coletando informações pertinentes ao banco de dados (visão SYS.AUD$);
·    db,extended – db - Habilita a auditoria, coletando informações pertinentes ao  banco de dados (visão SYS.AUD$) e adiciona os valores pertinentes as colunas SQLBIND e SQLTEXT (da visão SYS.AUD$);
·       xml – Habilita a auditoria, coletando informações pertinentes ao  Sistema Operacional em formato XML;
·    xml,extended – Habilita a auditoria, coletando informações pertinentes ao Sistema Operacional incluindo as SQLBIND e SQLTEXT  (da visão SYS.AUD$);

Na maioria dos casos a opção de auditoria (db ou db,extend) é a mais utilizada, permitindo verificar detalhes dos acessos no banco de dados. Porém essa opção gera um grande volume de informação na visão “SYS.AUD$”. Este objeto fica armazenado na tablespace SYSTEM, o que muitas vezes ocasiona estouro, parando o banco de dados.

Uma opção para corrigir esse problema é realizar a movimentação dos objetos de auditoria para outra tablespace, de modo a melhorar a administração de capacidades da auditoria Oracle.

A seguir os passos necessários para a mudança:

1. Desativar a auditoria se ela estiver habilitada:

SQL> alter system set audit_trail=none scope=spfile;

2. Reiniciar o banco de dados:

SQL> startup;

3. Criar uma nova tablespace para armazenar os objetos da auditoria:

SQL> create tablespace tbs_auditoria
   2 datafile ’/home/oracle/oradata/dbf/tbs_audit_01.dbf’
   3 size 2g autoextend on next 1g maxsize 4g;

4. Conectar como SYS, executar os passos abaixo:

SQL> conn sys/**** as sysdba

SQL> create table system.aud$ tablespace tbs_auditoria
   2 as select * from aud$;

SQL> create index system.i_aud1
   2 on system.aud$(sessionid, ses$tid) tablespace tbs_auditoria;

SQL> rename aud$ to aud$_temp;

SQL> create view aud$ as select * from system.aud$;

5. Conectar com o usuário SYSTEM e conceder os privilégios abaixo:

SQL> conn system/****

SQL> grant all on aud$ to sys with grant option;

SQL> grant delete on aud$ to delete_catalog_role;

6. Reativar a auditoria, utilizar os passos abaixo:

SQL> alter system set audit_trail=DB scope=spfile;

SQL> startup;

7. Recriar as visões da auditoria do dicionário de dados:

SQL> @?/rdbms/admin/cataudit.sql

Apartir desses passos executados os objetos de auditoria serão criados na tablespace TB_AUDITORIA.

Abaixo alguns exemplos do comando AUDIT.

AUDIT ALL BY BY ACCESS;
AUDIT EXECUTE PROCEDURE BY BY ACCESS;
AUDIT UPDATE TABLE,
      SELECT TABLE,
      INSERT TABLE,
      DELETE TABLE BY BY ACCESS;

Os comandos acima realizam auditoria de todos os comandos que o executar no banco de dados (DDL, DML, Logon e Logoff).

Também é possível realizar auditoria de um objeto específico, independente do usuário que o acessa e também por uma sessão inteira. O comando ficaria assim:

AUDIT ALL ON [OWNER].[TABELA] BY SESSION;

Para desabilitar a auditoria de determinado objeto deve-se utilizar o comando “NOAUDIT”, conforme o exemplo abaixo:

NOAUDIT ALL ON [OWNER].[TABELA] BY SESSION;

Dica importante:  O comando “AUDIT ALL” habilita a auditoria para todo o banco e para todas as atividades. Recomenda-se analisar a real necessidade para utilização deste comando num ambiente de produção. Pois esse comando gera lentidão no banco de dados e também um volume muito grande de informação armazenada da auditoria no banco de dados.

Nota Final: Embora exista um Note da Oracle (72460.1) para a execução desta atividade, a Oracle indica que esse procedimento não é suportado pelo suporte, portanto em ambientes críticos deve-se consultar o Suporte da Oracle para detalhes.

Referências:  Oracle Database, Security Guide 11g Release 2 (11.2);
                           Oracle Label Security, Administrator’s Guide 11g Release 2 (11.2).



MSc. Rubens Oliveira
DBA Oracle Consultor
olivert.dba@consultant.com

domingo, 2 de dezembro de 2012

Usando o “Datapump” para exportar/importar em bancos remotos


Para a exportação e importação de dados no banco de dados Oracle em bancos remotos, historicamente  poderia ser utilizado uma conexção via SQL*NET. Para isso, utilizando o utilitário (exp/imp) era necessário colocar a string de conexão na frente do usuário e senha. 

Conforme apresentado abaixo:

$exp userid=usuario/senha@banco_remoto ... e demais opções
$imp userid=usuarui/senha@banco_remoto ... e demais opções

Sabemos que para bancos de dados grandes, este procedimento era um problema porque os limites do sistema operacional sobre o tamanho do arquivo e a latência da rede entre os servidores tornava quase impossível a execução deste procedimento.

Alguns DBAs criativos usavam utilitários de compactação de arquivos, via Unix/Linux  (compress, gzip, entre outros), para obter o máximo de capacidade do arquivo durante a gravação e também diminuir a latência da rede entre os servidores.

Nas versões posteriores a importação e exportação permite o uso de múltiplos arquivos de “dump” permitindo contornar os limites.

Apartir do Oracle 10g, o utilitário “Datapump” permite eliminar o arquivo de “dump”,  realizando a operação diretamente de um banco de dados Oracle remoto.

Neste artigo irei demonstrar como é possível fazer a importação de uma tabela acessando o banco de dados remotamente.

Para estes testes, foram criados o usuário SCOTT com sua senha original TIGER, e na base de dados de origem (LAB1) e destino (LAB2). E no banco de dados destino (LAB2), foram criadas algumas tabelas com conteúdos.

Abaixo seguem as informações sobre os testes.

Base de origem: LAB1
Usuário       : SCOTT
Senha         : TIGER

Não existem tabelas criadas.


Base de destino: LAB2
Usuário        : SCOTT
Senha          : TIGER

Tabelas e quantidades de linhas:

BONUS    -> 0  LINHAS
EMP      -> 14 LINHAS
DEPT     -> 4  LINHAS
DUMMY    -> 1  LINHAS
EMP      -> 14 LINHAS
SALGRADE -> 5  LINHAS

O primeiro passo será criar um “database link”, no banco de dados (LAB1) para acessar o banco de dados destino (LAB2) remotamente.

Para a criação do “database link”, deve-se usar o comando CREATE DATABASE LINK e fornecer credenciais de login, o nome do “database link”, o usuário de conexão, a senha e a string para conexão. 

Abaixo segue o exemplo utilizado.

CREATE DATABASE LINK TEST
   CONNECT TO scott IDENTIFIED BY tiger USING 'LAB2';

O comando de importação do “Datapump”, (impdp), utilizará este “database link” para acessar diretamente dados remotos. A linha de comando apresentada abaixo aponta para um NETWORK_LINK no banco de destino (LAB2), abaixo a linha de comando utilizada.

$impdp scott/tiger TABLES=emp,dept DIRECTORY=DATA_PUMP_DIR NETWORK_LINK=test

Import: Release 11.2.0.1.0 - Production on Mon Nov 26 15:58:36 2012
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,Data Mining and Real Application Testing options
Starting "SCOTT"."SYS_IMPORT_TABLE_01":  scott/******** TABLES=emp,dept DIRECTORY=DATA_PUMP_DIR NETWORK_LINK=test
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 128 KB
Processing object type TABLE_EXPORT/TABLE/TABLE

. . imported "SCOTT"."DEPT"                                   4 rows

. . imported "SCOTT"."EMP"                                   14 rows

Job "SCOTT"."SYS_IMPORT_TABLE_01" successfully completed at 15:58:50

Esse comando irá ler as informações das tabelas (DDL e DML) DEPT e EMP da base de dados remota (LAB2) e criar as tabelas e importar os dados na base local (LAB1).

Após a importação das tabelas, temos:

SQL> select name from v$database;

NAME
---------------------------
LAB1

SQL> select * from cat;

TABLE_NAME           TABLE_TYPE
-------------------- ---------------------------------
DEPT                 TABLE
EMP                  TABLE

Note que nenhuma operação de exportação foi realizada na base de dados destino (LAB2) e nenhum arquivo de “dump” foi criado para este processo.

Mais informações sobre as importações utilizando um link de rede, consultar o manual Oracle Database Utilities, 11g Release 2 (11.2)”.



MSc. Rubens Oliveira
DBA Oracle Consultor
olivert.dba@consultant.com