Oracle com JSON

Olá tudo bom? (espero que sim!)

Neste artigo quero falar um pouco de uma novidade do Oracle 12c que é a integração com JSON. Uma novidade bastante interessante já que de uns tempos pra cá JSON tem ganhado cada vez mais força dentro das aplicações (principalmente porque causa dos dos bancos de dados NoSql).

Neste artigo vamos falar de uma maneira bem superficial, mais para entendermos como funciona, e nos próximos artigos iremos explorar este tema mais afundo.

Para começar, vamos criar uma tabela que contenha uma coluna para receber os seus valores no formato JSON. Neste caso você pode criar uma coluna VARCHAR2 comum e na sequencia colocar uma constraint nesta tabela informando que na referida coluna só podem ser inseridos registros no formato JSON.

Usaremos uma tabela que armazene informações de cursos por exemplo:

CREATE TABLE cursos_json (
cod_curso NUMBER NOT NULL,
informacoes VARCHAR2(4000)
CONSTRAINT ensure_json CHECK ( informacoes IS JSON )
);


Repare que a coluna “informações” é VARCHAR2(4000) e na sequencia criamos uma constraint do tipo CHECK que usa uma nova função “IS JSON” que basicamente verifica se determinado conteúdo está no formato JSON ou não.

Feito isso, agora você pode consultar uma nova view que contém os metadados das tabelas que usarem JSON veja:

SELECT * FROM USER_JSON_COLUMNS;

Agora como parte de nosso exercício vamos inserir alguns registros, repare que é muito simples, basta você colocar no seu insert uma informação no formato JSON.

INSERT INTO cursos_json (cod_curso, informacoes)
values
(1,
'{"Curso": "DBA-Essential",
"Nível": "Iniciante",
"Topicos": ["Instalacao","Configuracao","Manutencao", "Backup / Recover"]
}');

INSERT INTO cursos_json (cod_curso, informacoes)
values
(2,
‘{“Curso”: “Tuning DB / App”,
“Nível”: “Intermediario”,
“Topicos”: [“Tuning de SQL”,”Tuning de Instancia”, “Tuning de SO”]
}’);

Depois das linhas inseridas podemos agora consulta-las, execute um select comum na sua tabela e veja aí todos os registros inseridos com sucesso.

Gostaria de deixar um desafio aqui, se você reproduziu este conteúdo no seu ambiente de estudos tente inserir um registro que NÃO seja JSON na coluna INFORMACOES e veja o que acontece.

Por agora paramos no select e insert, prometo nos próximos artigos abordar outras atividades como update, delete entre outros, este é um novo recurso da versão 12c que eu particularmente gostei bastante e prometo divulgar aqui mais novidades, aguardem!

Forte abraço e até a próxima!

Douglas Paiva de Sousa

Oracle Result Cache

 

O result cache é uma área de memória da instância que retém o resultado das instruções SQL para reutilização por outras sessões, a memória utilizada neste caso é a memória da shared pool, nela ficará contido o resultado de comandos “SELECT” e funções PL/SQL que estarão tirando proveito desta funcionalidade.

Quando determinado comando SQL (select ou uma PL/SQL function) é utilizado por repetidas vezes, o banco de dados pode armazenar o resultado destes comandos no result cache para ser reutilizado por outras sessões que executarem o mesmo comando, evitando então a execução repetida e desnecessária destes comandos, porém quando o dado (que está no result cache) é modificado o resultado é descartado do cache. O uso do result cache é recomendado para tabelas que tem altos índices de leituras e retornam baixa quantidade de registros e/ou tabelas read-only.

Benefícios do result cache.

Redução do tempo de resposta: com os dados retidos no cache, evita-se a repetida execução da query.

Maior eficiência no uso dos recursos: a redução de round trips pode resultar em um ganho substancial de performance e consequente economia de recursos como CPU e I/O. Uma vez que os dados estão em cache estes outros recursos podem ser liberados para outras tarefas dentro da instância.

Redução do uso de memória: Quando utilizado no lado do client há mais memória disponível para o servidor executar outras atividades (também há essa possibilidade).

Configuração do result cache:

Por default quando você inicializa a instância de banco de dados a memória destinada ao result cache é parte da shared pool, já com relação à quantidade de memória, isso vai depender do valor alocado para instância e como ele vai ser gerenciado, veja:

• Com ASMM (automatic shared memory management):

Neste caso, a quantidade de memória para a shared pool é subtraída do valor atribuído ao parâmetro SGA_TARGET, sendo assim para o result cache é alocado 0,50% do valor da SGA_TARGET.

• Com gerenciamento de memória manual:

Neste caso, o valor que será atribuído ao result cache é o correspondente a 1% da quantidade de memória da shared pool.

Exemplos de uso:

No exemplo acima, você pode ver no plano de execução que o resultado da query vem do result cache, pois na coluna “Name” do ID 1 informa que você obtém o resultado desta query de dentro do cache.

Metadados:

Com o select abaixo (na view V$RESULT_CACHE_OBJECTS), você consegue consultar os metadados de seu result cache (exemplo: data de criação, quantidade de blocos e linhas) para gerenciamento do mesmo.

Uma outra maneira de monitorar o comportamento de seu result cache é usar a package DBMS_RESULT_CACHE.MEMORY_REPORT. Além desta função, caso você queira limpar todo o seu result cache é possível usar a mesma package porém com a procedure FLUSH vide exemplo: exemplo DBMS_RESULT_CACHE.FLUSH;

Parâmetros:

Existem alguns parâmetros no SPFILE que você também pode usar para gerenciar o result cache.

• RESULT_CACHE_MAX_SIZE: Quantidade de memória alocada para o result cache. (se quiser usar os valores padrão, defina-o para 0).
• RESULT_CACHE_MAX_RESULT: Quantidade máxima de memória (em percentual) para o result cache, valor padrão 5%.
• RESULT_CACHE_REMOTE_EXPIRATION: Tempo em minutos que os resultados das queries devem ser mantidos no result cache.

Exemplos de uso:

O result cache pode ser invocado pelas aplicações de duas maneiras, pelos hints /*+ RESULT_CACHE */ e também /*+ NO_RESULT_CACHE */ e nas definições das tabelas através das definições do parâmetro:

RESULT_CACHE (MODE DEFAULT | FORCE)

Vejamos alguns exemplos:

Com HINT NO_RESULT_CACHE:

Com o HINT RESULT_CACHE:

Exemplo com o parâmetro RESULT_CACHE na definição das tabelas:

Neste caso, ao criarmos as tabelas já podemos informar no parâmetro RESULT_CACHE qual será o comportamento conforme abaixo:

DEFAULT: Se especificado, em pelo menos uma das tabelas envolvida em um SELECT ou function PL/SQL o resultado não vai para o result_cache, a menos que o parâmetro RESULT_CACHE_MODE do SPFILE (ou na sessão) esteja especificado como FORCE ou o hint /*+ RESULT_CACHE +/ seja explicitamente escrito na query.

FORCE: Se todas as tabelas envolvidas em uma query ou function PL/SQL tiveram marcadas com o result cache neste modo, seu resultado sempre irá para o result cache.

Observação: Vale lembrar que o parâmetro RESULT_CACHE nas tabelas pode ser modificado com um ALTER TABLE… vide exemplo:

ALTER TABLE sales RESULT_CACHE (MODE FORCE);

Monitoramento:

Você pode monitorar o uso do result cache através de diversas views que o banco de dados oferece, com essas views fica mais fácil entender como está o uso deste recurso e se o mesmo está surtindo os efeitos esperados no que tange a performance de sua aplicação.

V$RESULT_CACHE_STATISTICS: Com essa view você coleta informações à respeito das configurações e uso de memória do result cache.

V$RESULT_CACHE_MEMORY: Lista todos os blocos de seu servidor que estão no result cache bem com suas estatísticas.

V$RESULT_CACHE_OBJECTS: Lista todos os objetos de seu banco de dados que possuem blocos alocados no result cache.

V$RESULT_CACHE_DEPENDENCY: Lista as dependências de objetos que estão no result cache vs objetos que não se encontram no mesmo.

DBA | ALL | USER _TABLES: Essas views possuem uma coluna chamada RESULT_CACHE que informa quais objetos estão definidos para usar o result cache ou não.

Abaixo alguns exemplos:

Monitoramento das estatísticas do result cache:

É isso aí, concluindo result cache é algo relativamente simples, porém se bem empregado pode lhe ajudar a ter significativos ganhos de performance, para maiores informações, você pode consultar a documentação oficial da Oracle.

Espero ter ajudado, forte abraço e até a próxima.

Douglas Paiva de Sousa

 

Sql*Plus SET HIST

Olá tudo bem?

Neste breve artigo quero compartilhar com vocês uma novidade que a versão 12cR2 do Oracle trouxe, é algo que parece simples, mas para quem trabalha a maior parte do tempo no Sql*Plus (entenda-se DBAs) é um grande avanço, trata-se da função SET HIST do Sql*Plus.

Essa funcionalidade não vem habilitada por default, ou seja você tem que explicitamente fazê-lo, mas é algo bem simples, basta digitar SET HIST ON vejamos abaixo:

Assim que você  habilitar esta opção, por default já é estabelecido um limite para que os seus últimos 100 comandos fiquem registrados no histórico, sendo assim a partir de agora você pode sair executando seus comandos que os mesmos ficarão registrados no histórico.

Para exibir todos os comandos registrados no histórico, basta digitar HIST. Caso você queira listar e executar os comandos pelo número que lhes foram atribuídos basta digitar HIST mais o número do comando e a palavra RUN,  é possível também alterar a quantidade de comandos armazenados no histórico, para isso use o comando SET HIST mais a quantidade de comandos que você quer que permaneça no histórico.

Alterando a quantidade de registros retidos no histórico:

Exibindo o histórico:

Reexecutando um comando:

Muito bem! E para finalizar se você quiser limpar o conteúdo retido no seu histórico, basta digitar HIST CLEAR e tudo será removido do histórico.

Por enquanto vamos ficando por aqui, mas em breve teremos mais artigos com dicas e novidades sobre o mundo Oracle, nos acompanhe também no Facebook, LinkedIn e Youtube para ficar sempre informado sobre nossas novidades! Um forte abraço e até a próxima.

Douglas Paiva de Sousa

Treinamento Oracle Data Guard

Save the date!

Um pouco de Oracle RAC

Um pouco de Oracle RAC. Processo de instalação do Grid Infrastructure.

Treinamento Tuning & Performance

PL/SQL Transações Autônomas

Olá, normalmente nos posts que escrevo, sempre acabo falando de assuntos voltados para DBAs (até mesmo porque eu sou um rsrsrs), mas por muitas vezes nos meus treinamentos de SQL e PL/SQL os alunos acabam por me cobrar posts voltados para o processo de desenvolvimento, confesso que escrevo pouco ou quase nada a esse respeito, mas prometo pagar essa divida com vocês a partir de agora, escrevendo artigos úteis para desenvolvedores, até mesmo porque eu já fui um e gostava muito de programar, sendo assim vamos lá.

Hoje vamos falar de transações autônomas, que são aquelas famosas transações que acontecem de maneira independente, ou seja, uma transação principal se inicia e implicitamente dispara um outra transação. Para dar um exemplo mais claro, imagine uma situação onde devemos guardar registros de auditoria dentro de uma aplicação. Neste caso uma transação principal do usuário será iniciada, alterar um registro na tabela de funcionários por exemplo. Ao executar essa alteração na tabela de funcionários, uma trigger dispara e insere em uma tabela de auditoria que “fulano” alterou informações do funcionário “X” tal dia tal hora.

Neste caso, uma transação não pode atrapalhar a outra, se a transação principal sofrer um rollback, a transação autônoma não pode fazer parte deste rollback, caso contrário o processo de auditoria estaria comprometido, e o inverso também é verdadeiro, se houver algum erro no processo de registro na tabela de auditoria, você pode não querer atrapalhar a transação principal do usuário.

Pois bem, como fazemos isso dentro do banco de dados? Como informo para o banco de dados que existe esse “isolamento” entre as transações? Para isso usamos um comando chamado “PRAGMA AUTONOMOUS_TRANSACTION” esse comando informa ao compilador em tempo de “compilação” (e não de “execução”) que essas transações estão relacionadas, porém de maneira autônoma, ou seja uma não pode influenciar o comportamento da outra.

O comando “PRAGMA AUTONOMOUS_TRANSACTION” pode ser informado em qualquer parte da sessão declarativa de seu código, mas para ter um código mais limpo e legível procure colocar sempre no início. Abaixo alguns exemplos:

Em um bloco anonimo:

DECLARE
PRAGMA AUTONOMOUS_TRANSACTION -- <<< Olha ele aí!;
emp_id NUMBER(6);
amount NUMBER(6,2);
BEGIN
emp_id := 200;
amount := 200;
UPDATE employees SET salary = salary - amount WHERE employee_id = emp_id;
COMMIT;
END;
/
Em uma trigger:
CREATE OR REPLACE TRIGGER audit_sal
AFTER UPDATE OF salary ON employees FOR EACH ROW
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION; -- <<< Olha aí, outro exemplo!
BEGIN
INSERT INTO emp_audit VALUES( :old.employee_id, SYSDATE,
:new.salary, :old.salary );
COMMIT;
END;
/

Conclusão: Trabalhar com transações autônomas traz muitas vantagens no processo de desenvolvimento, você consegue de certa forma fazer com que dois objetos trabalhem em sincronismo, mas sem que um afete as funcionalidades do outro, conseguindo então encapsular e modularizar as funcionalidades no seu código para automatizar tarefas, transações autônomas não geram disputas por recursos como lock e dead lock por exemplo.

Então é isso aí, foi um artigo curto, mas acredito que pode ser útil, em breve mais artigos para desenvolvedores e DBAs é claro!

Forte abraço e até a próxima!

Douglas Paiva de Sousa

Métodos de compilação PLSQL

Muitas vezes no seu dia a dia você tem objetos PLSQL que precisam ser executados com uma certa frequência e necessitam de uma velocidade bem agressiva. Nestes casos o primeiro passo é fazer um trabalho de otimização no código e também na instancia (caso seja preciso), mas se mesmo assim você ainda não conseguir chegar a um tempo de resposta adequado, ainda há uma solução. O método de compilação de seu código, interpretado ou nativo, vejamos na sequencia esse assunto com maiores detalhes.

Na versão 9i do Oracle, foi introduzida capacidade de compilar seus códigos PLSQL de maneira “nativa” (diretamente na linguagem C) o que o torna bem mais rápido do que no modo interpretado. Nessa época, e desenvolvedor tinha uma certa dependência do DBA, pois era preciso que fosse definido no SPFILE da instancia de banco de dados um parâmetro chamado “PLSQL_NATIVE_LIBRARY_DIR”, onde se apontava um diretório para instalar um compilador da linguagem C. Pois bem, isso já faz parte do passado e nas versões mais atuais (11g / 12c) não há mais essa necessidade, tudo o que se precisa fazer é alterar um outro parâmetro de nome PLSQL_CODE_TYPE, que pode ser alterado diretamente no escopo de sessão e então tirar todo proveito dessa alternativa para acelerar o tempo de execução de seus objetos PLSQL, vejamos o exemplo abaixo:

PLSQL_CODE_TYPE = ‘INTERPRETED’: Neste modo, o código é compilado em uma área intermediaria da memória e persistido no dicionário de dados da instancia, para ser interpretado em tempo de execução (o que é mais demorado).

PLSQL_CODE_TYPE = ‘NATIVE’: Neste caso o código não será interpretado em tempo de execução, pois o mesmo já será persistido em sua forma nativa, consequentemente a execução será mais rápida.

Você pode alterar o valor do parâmetro PLSQL_CODE_TYPE no escopo de sessão:

ALTER SESSION SET PLSQL_CODE_TYPE = NATIVE;

Ou no momento da compilação do seu objeto PLSQL:

ALTER PROCEDURE my_proc COMPILE PLSQL_CODE_TYPE = NATIVE;

Você pode consultar o método de compilação de seus objetos PLSQL através das views de performance USER | ALL | DBA_PLSQL_OBJECT_SETTINGS. Agora vamos à parte prática deste assunto.

SQL> connect hr/hr
Connected.
SQL> create or replace function fib (n POSITIVE) return integer is
2 begin
3 if (n = 1) or (n = 2) then
4 return 1;
5 else
6 return fib(n - 1) + fib(n - 2);
7 end if;
8 end fib;
9 /
Function created.
SQL> ALTER SESSION SET plsql_code_type = 'INTERPRETED';
Session altered.
SQL> ALTER FUNCTION fib COMPILE;
Function altered.
SQL> DECLARE
2 X number;
3 begin
4 X := fib(40);
5 dbms_output.put_line(X);
6 end;
7 /
102334155
PL/SQL procedure successfully completed.
Elapsed: 00:01:05.34
SQL> CONNECT / AS SYSDBA
Connected.
SQL> ALTER SYSTEM flush shared_pool;
System altered.
SQL> CONNECT hr/hr
Connected.
SQL> ALTER SESSION SET plsql_code_type = 'NATIVE';
Session altered.
SQL> ALTER FUNCTION fib COMPILE;
Function altered.
SQL> set serveroutput on
SQL> set timing on
SQL> DECLARE
2 X number;
3 BEGIN
4 X := fib(40);
5 dbms_output.put_line(X);
6 END;
7 /
102334155
PL/SQL procedure successfully completed.
Elapsed: 00:00:32.63
SQL>

Está aí o exemplo, agora pegue aquele seu processo que leva cerca de duas horas para executar e corte esse tempo pela metade! rsrsrs. Espero ter ajudado.

Forte abraço e até a próxima!

Douglas Paiva de Sousa

Oracle 12c Instalação (Linux)

A versão 12c do Oracle já está aí há um bom tempo, e eu até já escrevi alguns artigos a respeito, porém acredito que um dos principais eu não tenham produzido até então, mas chegou a hora de fazê-lo, enfim vamos lá falar da instalação do Oracle 12c, em ambiente Linux é claro!

Preparando o sistema operacional:

A primeira etapa deste processo consistem em preparar o sistema operacional para que se possa instalar o Oracle, sendo assim, precisamos fazer alguns ajustes dentro do Linux. Há duas formas de fazê-lo, uma é de maneira automática, onde você simplesmente baixa uma lib do “public-yum” da Oracle e essa lib faz tudo pra você e outra onde se faz tudo manualmente (aliás eu recomendo essa maneira para os iniciantes, é mais difícil, porém você vai praticar mais e aprender mais). Aqui veremos as duas maneiras.

Porém antes dessa etapa precisamos acertar um pequeno detalhe no servidor, que é a resolução do hostname, vamos lá.

Com algum editor de texto, abra o arquivo “/etc/hosts” e faça com que ele resolva o hostname de seu servidor, conforme abaixo.

<IP-address>  <fully-qualified-machine-name>  <machine-name>

Exemplo:

127.0.0.1       localhost.localdomain  localhost

192.168.0.210   oradata-lab1.localdomain    oradata-lab1

Instalando os pré-requisitos de SO (automático).

Para acertar as configurações do seu SO de maneira automática, basta configurar o “plublic-yum” (se não souber acesse http://public-yum.oracle.com) em seu servidor e baixar a lib “oracle-rdbms-server-12cR1-preinstall”.

# yum install oracle-rdbms-server-12cR1-preinstall -y

Após terminar essa etapa, você pode seguir para as configurações adicionais e na sequencia o “setup” propriamente do software do Oracle.

Instalando os pré-requisitos de SO (automático).

Caso opte pela configuração manual do SO, você deve seguir os seguintes passos:

Adicione as seguintes entradas no “/etc/sysctl.conf”

fs.file-max = 6815744
kernel.sem = 250 32000 100 128
kernel.shmmni = 4096
kernel.shmall = 1073741824
kernel.shmmax = 4398046511104
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
fs.aio-max-nr = 1048576
net.ipv4.ip_local_port_range = 9000 65500

Na sequência, execute o commando “/sbin/sysctl –p”

/sbin/sysctl -p

Adicione as seguintes linhas no arquivo “/etc/security/limits.conf.

oracle soft nofile 1024
oracle hard nofile 65536
oracle soft nproc 16384
oracle hard nproc 16384
oracle soft stack 10240
oracle hard stack 32768

Para que a instalação do Oracle funcione corretamente, as seguintes “libs” precisam ser instaladas:

yum install binutils -y
yum install compat-libcap1 -y
yum install compat-libstdc++-33 -y
yum install compat-libstdc++-33.i686 -y
yum install gcc -y
yum install gcc-c++ -y
yum install glibc -y
yum install glibc.i686 -y
yum install glibc-devel -y
yum install glibc-devel.i686 -y
yum install ksh -y
yum install libgcc -y
yum install libgcc.i686 -y
yum install libstdc++ -y
yum install libstdc++.i686 -y
yum install libstdc++-devel -y
yum install libstdc++-devel.i686 -y
yum install libaio -y
yum install libaio.i686 -y
yum install libaio-devel -y
yum install libaio-devel.i686 -y
yum install libXext -y
yum install libXext.i686 -y
yum install libXtst -y
yum install libXtst.i686 -y
yum install libX11 -y
yum install libX11.i686 -y
yum install libXau -y
yum install libXau.i686 -y
yum install libxcb -y
yum install libxcb.i686 -y
yum install libXi -y
yum install libXi.i686 -y
yum install make -y
yum install sysstat -y
yum install unixODBC -y
yum install unixODBC-devel -y

Crie os grupos “oinstall” e “db” e na sequencia crie o usuário “oracle”.

groupadd -g 54321 oinstall
groupadd -g 54322 dba

useradd -g oinstall -G dba oracle

Para efeitos de testes, defina o nivel de segurança do “SELINUX” como permissive, lembrando, apenas para laboratórios, não use isso em produção. No arquivo “/etc/selinux/config”

SELINUX=permissive

Após a alteração, execute o comando como “root”

setenforce Permissive

Desabilite o firewall do Linux.

service iptables stop
chkconfig iptables off

Crie os diretórios para a instalação do software.

mkdir -p /u01/app/oracle/product/12.1.0.2/dbhome_1
chown -R oracle:oinstall /u01
chmod -R 775 /u01

Acerte as variáveis de ambiente no “/home/oracle/.bash_profile”.

# Oracle Settings
export TMP=/tmp
export TMPDIR=$TMP

export ORACLE_HOSTNAME=ol6-121.localdomain
export ORACLE_UNQNAME=cdb1
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/12.1.0.2/db_1
export ORACLE_SID=cdb1

export PATH=/usr/sbin:$PATH
export PATH=$ORACLE_HOME/bin:$PATH

export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib
export CLASSPATH=$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib

Descompacte os arquivos de instalação.

unzip linuxamd64_12102_database_1of2.zip
unzip linuxamd64_12102_database_2of2.zip

Acesse a pasta “database” e execute o arquivo de instalação do software “./runInstaller”.

./runInstaller

 

Na primeira tela, desmarque as opções para baixar atualizações automáticas do “My Oracle Support”.

Confirme as opção novamente, clicando em “Sim”.

Selecione a opção “Instalar somente o software do banco de dados”.

Marque a opção “Instalação do banco de dados de instancia única”.

Nas opção de idiomas, selecione o que melhor lhe atender (preferencialmente “Português do Brasil” ou “Inglês”).

Selecione a edição do banco de dados que deseja usar (Enterprise, Standard ou Standard Edition).

Verifique se os caminhos apresentados para $ORACLE_BASE e $ORACLE_HOME estão compatíveis com o que você definiu no “.bash_profile”.

Verifique as definições de nomes de usuário e grupos dentro do sistema operacional.

Aguarde a verificação dos pré-requisitos. Caso haja alguma coisa pendente o instalador irá reportar a falha, mas estando tudo certo, a próxima tela será apenas para rever as opções da instalação.

Reveja as informações da instalação que você vai fazer e clique em “Instalar”.

Acompanhe o processo de instalação. Até que lhe seja solicitado a execução dos scripts como “root”.

Execute o script a seguir logado com o usuário “root”.

Pronto! Seu software está instalado, o próximo passo agora é criar a base de dados, em breve escreverei um artigo relacionado.

Forte abraço!

Douglas Paiva de Sousa

12c enable_ddl_logging.

No Oracle 12c uma das novas funcionalidades implementadas é a habilidade do banco de dados em monitorar e registrar em um arquivo de log (log.xml) todo e qualquer comando do tipo DDL (Data Definition Language), essa funcionalidade, por padrão vem desabilitada, porém você pode habilitá-la, através do parâmetro ENABLE_DDL_LOGGIN do spfile, para isso basta executar um simples ALTER SYSTEM trocando o valor para TRUE ou FALSE. Abaixo um exemplo:

Primeiramente vejamos se essa característica já se encontra habilitada no seu banco de dados. Para isso execute o comando “SHO PARAMETER” conforme a imagem.

No nosso caso está com a opção default, ou seja desabilitado, para progredir vamos habilitar a funcionalidade com o comando “ALTER SYSTEM” vide imagem.

Agora está pronto! De agora em diante todos os seus comandos DDL serão registrados em um arquivo de log chamado log.xml. Para testar tal funcionalidade, vamos fazer alguns comandos, usaremos um CREATE, um ALTER, um INSERT e um DROP. Depois veremos os resultados produzidos no arquivo de log.

Após executar alguns comandos, podemos consultar o arquivo de log, porém onde ele fica? Sua localização padrão é $ADR_HOME/ddl/log. Mas onde fica meu $ADR_HOME? Para responder essa pergunta, basta executar um select em uma view chamada V$DIAG_INFO, nela você encontra todas as informações inerentes a arquivos de log e trace de seu banco de dados.

De acordo com o SELECT acima, podemos identificar que nossa $ADR_HOME se encontra em “/u01/app/oracle/diag/rdbms/orcl/orcl”, neste caso então dentro deste caminho ainda teremos as pastas “ddl/log” e então o arquivo log.xml. Para visualizarmos o arquivo, podemos usar qualquer editor de texto (no meu caso usei o “vim”) para ver o resultado.

Na sequencia, o conteúdo do arquivo é exibido.

Repare, o comando INSERT não apareceu, isso porque a funcionalidade é monitorar apenas DDLs e não DMLs. Na minha opinião essa funcionalidade ficou muito boa, talvez não para ficar o tempo todo habilitada, pois pode gerar muito log e te dar problemas de 100% de utilização em disco, mas para processos pontuais, como por exemplo uma migração de determinada aplicação, isso seria viável, pois você teria o registro de todos os DDLs que foram executados.

É isso aí, espero ter ajudado, forte abraço e até a próxima!

Douglas Paiva de Sousa