Anunciado a aposentadoria dos exames de certificação OCP Oracle 8 e 8i

Olá,

Estava lendo o Oracle Certification blog de Paul Sorensen, e resolvi compartilhar a informação aqui. Segundo o post, à partir de 25 setembro de 2009, os exames (1Z0-010) Oracle8: New Features for Administrators e (1Z0-020) Oracle8i: New Features for Administrators serão descontinuados (aposentados), ou seja, não estarão mais disponíveis como opções de exames para a obtenção de certificação OCP.

O exame 1Z0-010 foi criado para aquele profissional que é OCP Oracle 7.3 e que deseja atualizar sua certificação para a versão do Oracle 8. Já o exame 1Z0-020, foi criado aquele profissional que é OCP Oracle 8 e que deseja fazer a atualização da sua certificação para a versão Oracle 8i. Portanto, para quem ainda tem interesse em realizar esses dois exames, os mesmos ainda poderão ser realizados até o dia 25 de setembro de 2009.

No mais, para os profissionais que detém a certificação OCP Oracle 7.3 e/ou OCP Oracle 8, os mesmos ainda terão a opção de atualização de suas certificações para a versão OCP Oracle 9i através do exame 1Z0-035 DBA Oracle 9i New Features for Oracle7.3 e OCPs Oracle8.

Introdução ao tipo de dado TIMESTAMP e suas variações ...

Olá,

Sabemos que o tipo de dado DATE do Oracle é um tipo especial capaz de armazenar datas que vão de 4712 a.C. a 9999 d.C, mas além de armazenar informações de século, ano, mês e dia, o mesmo também é capaz de armazenar informações de hora, minuto e segundo. Mas aí você poderia perguntar: Se o tipo de dado DATE é capaz de manter essas informações temporais, isso não poderia ser considerado um TIMESTAMP? Não necessariamente. O tipo de dados TIMESTAMP introduzido à partir do Oracle 9i, vai muito mais além do que simplesmente armazenar de forma "crua" informações de data e horários. Podemos dizer que o tipo de dado TIMESTAMP é uma extensão do tipo de dados DATE, capaz de manter informações de tempo com maior precisão. No mais, neste artigo farei uma breve introdução a este tipo de dado e suas variações (WITH TIME ZONE e WITH LOCAL TIME ZONE) que, muitas vezes, é fonte de dúvida entre desenvolvedores e administradores de banco de dados quanto à sua aplicação e uso.

Antes de começar a descrever sobre o tipo de dados TIMESTAMP, irei iniciar através do exemplo abaixo, como poderíamos verificar informações de século, data e horários atuais, selecionando-as direto do banco de dados através do uso da função SYSDATE:

SQL> select to_char(to_date(0,'J'), 'dd/mm/yyyy ad') from dual;
select to_char(to_date(0,'J'), 'dd/mm/yyyy ad') from dual
                       *
ERRO na linha 1:
ORA-01854: data juliana deve estar entre 1 e 5373484

SQL> select
  2  to_char(to_date(1,'J'), 'dd/mm/yyyy ad') de,
  3  to_char(to_date(5373484,'J'), 'dd/mm/yyyy ad') ate
  4  from dual;

DE              ATE
--------------- ---------------
01/01/4712 a.C. 31/12/9999 d.C.

SQL> select to_char(sysdate,'cc dd/mm/yyyy hh24:mi:ss') data from dual;

DATA
----------------------
21 17/08/2009 08:10:25

Talvez você também já tenha ouvido falar da função CURRENT_DATE. A diferença entre ela e o SYSDATE é que a função SYSDATE retorna a data e horário do servidor, enquanto que a função CURRENT_DATE retorna a data e horário de acordo com o fuso horário da sessão do usuário. Para comprovar tal explicação, no exemplo abaixo irei alterar o fuso horário da minha sessão para o fuso horário de Nova York nos EUA que é '-5:00'. No servidor Oracle, o fuso horário está definido em '-3:00', ou seja, três horas de atraso em relação à hora de Greenwich.

SQL> alter session set nls_date_format='dd/mm/yyyy hh24:mi:ss';

Sessão alterada.

SQL> select sessiontimezone from dual;

SESSIONTIMEZONE
----------------
-03:00

SQL> alter session set time_zone='-5:00';

Sessão alterada.

SQL> select sessiontimezone from dual;

SESSIONTIMEZONE
----------------
-05:00

SQL> select sysdate,current_date from dual;

SYSDATE             CURRENT_DATE
------------------- -------------------
17/08/2009 08:15:45 17/08/2009 06:15:45

Podemos perceber acima que SYSDATE retornou o horário do servidor, e CURRENT_DATE o horário de acordo com o fuso horário definido na minha sessão.

Bom, voltando ao assunto que originou este artigo e, como já dito anteriormente, o tipo de dados TIMESTAMP introduzido à partir do Oracle 9i é uma extensão do tipo de dados DATE. Além de armazenar o ano, mês, dia, horas, minutos e segundos do tipo de dados DATE, o mesmo é capaz também de armazenar o valor das frações de segundo. A precisão dessas frações, como o próprio nome já diz, nada mais é do que o número de dígitos da parte fracionária dos "segundos". Esta precisão pode ser um número de 0 a 9, mas quando não especificado, o seu valor padrão é 6.

SQL> create table t1 (ts_data timestamp);

Tabela criada.

SQL> desc t1
 Nome                         Nulo?    Tipo
 ---------------------------- -------- ------------------------
 TS_DATA                               TIMESTAMP(6)


SQL> insert into t1 values (localtimestamp);

1 linha criada.

SQL> alter session set nls_timestamp_format = 'dd/mm/yyyy hh24:mi:ss.ff';

Sessão alterada.

SQL> select * from t1;

TS_DATA
--------------------------
05/08/2009 08:20:32.627869

Além do exemplo demonstrado acima, existem ainda duas variações do tipo de dados TIMESTAMP:

O tipo TIMESTAMP WITH TIME ZONE é uma variante de TIMESTAMP que inclui um deslocamento de fuso horário (TIME ZONE) em seu valor. Podemos dizer que o deslocamento de fuso horário em questão é a diferença em horas e minutos entre o horário local e o UTC. UTC é um acrônimo do Inglês para "Coordinated Universal Time" ou "Tempo Universal Coordenado" que corresponde ao fuso horário de referência a partir do qual se calculam todas as outras zonas horárias do mundo. Segundo algumas bibliografias, o UTC é o sucessor do Tempo Médio de Greenwich (Greenwich Mean Time), abreviadamente mais conhecido como GMT. Esta nova denominação foi cunhada para basear a medida do tempo nos padrões atômicos, mais do que nos celestes. Em resumo, dois valores TIMESTAMP WITH TIME ZONE serão considerados idênticos se representarem o mesmo instante em UTC, independente dos deslocamentos de fusos horários (TIME ZONE) armazenados nos dados. Confuso? Bom, para que não haja dúvidas, poderemos ver abaixo um exemplo que demonstra uma informação de data e horário que deverá ser reunida ou coordenada entre diferentes regiões geográficas com fusos horários distintos:

Por exemplo:

TIMESTAMP '17/08/2009 08:00:00 -3:00'

é o mesmo que

TIMESTAMP '17/08/2009 06:00:00 -5:00'

Isto é, 08:00 horas da manhã no horário de Brasília é o mesmo que 06:00 horas da manhã no horário de Nova York nos EUA.

O outro tipo, TIMESTAMP WITH LOCAL TIME ZONE é outra variante de TIMESTAMP que inclui um deslocamento de fuso horário em seu valor. A diferença é que este deslocamento não é armazenado como parte dos dados da coluna, mas sim, normalizado para o fuso horário do banco de dados (DBTIMEZONE). O verbo "normalizar", neste caso, eu entendo como um cálculo que é realizado tendo como base o fuso horário definido no banco de dados afim de se mostrar o horário local do usuário. Portanto, o Oracle retornará a informação de data, hora, minuto e segundo no fuso horário local da sessão que está acessando o dado. Vale a pena salientar que o uso desta variante é apropriado para aplicações onde se deseja exibir as datas e os horários usando o fuso horário do sistema cliente. Para quem já acessou algum tipo fórum ou lista de discussão de nível global, notará que ao postar algum tópico no fórum, a data e horário mostrada será convertida para o fuso horário local. Caso um leitor que esteja no Japão acessar o tópico, verá a data e horário de acordo com o fuso horário do Japão. Então, utilizando como base o exemplo anterior:

Supondo que eu esteja no Brasil (fuso horário -3:00) e insira a data e horário abaixo:

TIMESTAMP '17/08/2009 08:00:00'

e um usuário que esteja em Nova York (fuso horário -5:00) acessar o mesmo dado, a data apresentada para este usuário será

TIMESTAMP '17/08/2009 06:00:00'

No mais, para demonstrar o uso do tipo TIMESTAMP e suas duas variações, irei realizar algumas operações abaixo. Vale a pena salientar que o Oracle possui além das funções SYSDATE e CURENT_DATE, outras funções embutidas para capturar informações de data e horários atuais como, LOCALTIMESTAMP, CURRENT_TIMESTAMP e SYSTIMESTAMP onde:

• LOCALTIMESTAMP: retorna um valor do tipo TIMESTAMP como data e horário corrente (incluindo frações de segundos), de acordo com o fuso horário definido na sessão do usuário.

• CURRENT_TIMESTAMP: retorna um valor do tipo TIMESTAMP WITH TIME ZONE como data e horário corrente (incluindo frações de segundos), de acordo com o fuso horário definido na sessão do usuário.

• SYSTIMESTAMP: retorna um valor do tipo TIMESTAMP WITH TIME ZONE como data e horário corrente (incluindo frações de segundos), de acordo com o fuso horário definido no sistema onde o servidor de banco de dados reside.

Para demonstrar o resultado das funções acima, executarei os comandos SQL abaixo:

SQL> alter session set time_zone='-5:00';

Sessão alterada.

SQL> select localtimestamp,current_timestamp,systimestamp from dual;

LOCALTIMESTAMP           CURRENT_TIMESTAMP               SYSTIMESTAMP
------------------------ ------------------------------- -------------------------------
17/08/09 06:20:54,656000 17/08/09 06:20:54,656000 -05:00 17/08/09 08:20:54,656000 -03:00

Podemos perceber pelo resultado acima que LOCALTIMESTAMP e CURRENT_TIMESTAMP apresentaram o mesmo horário, a diferença é que CURRENT_TIMESTAMP trouxe a informação do fuso horário (-5:00). Já a função SYSTIMESTAMP, diferente de CURRENT_TIMESTAMP, trouxe o horário de acordo com o fuso horário definido no sistema do servidor de banco de dados.

Irei agora criar uma tabela de teste conforme abaixo:

SQL> create table t2 (
  2   a timestamp,
  3   b timestamp with time zone,
  4   c timestamp with local time zone
  5  );

Tabela criada.

SQL> desc t2
 Nome                      Nulo?    Tipo
 ------------------------- -------- ---------------------------------
 A                                  TIMESTAMP(6)
 B                                  TIMESTAMP(6) WITH TIME ZONE
 C                                  TIMESTAMP(6) WITH LOCAL TIME ZONE

SQL> insert into t2 values (localtimestamp,localtimestamp,localtimestamp);

1 linha criada.

SQL> select * from t2;

A                        B                               C
------------------------ ------------------------------- ------------------------
17/08/09 08:30:10,250000 17/08/09 08:30:10,250000 -03:00 17/08/09 08:30:10,250000

Independente da função utilizada, as informações de data e horários foram inseridas nas devidas colunas e mostram o mesmo horário. Agora irei realizar através de uma aplicação (no meu caso o SQL*Plus), a simulação do acesso remoto ao banco de dados na qual o usuário está localizado em uma região geográfica onde fuso horário desta região seja diferente como, por exemplo, Nova York nos EUA:

SQL> alter session set time_zone='-5:00';

Sessão alterada.

SQL> select dbtimezone,sessiontimezone from dual;

DBTIMEZONE SESSIONTIMEZONE
---------- ---------------
-03:00     -05:00

SQL> select * from t2;

A                         B                              C
------------------------ ------------------------------- ------------------------
17/08/09 08:30:10,250000 17/08/09 08:30:10,250000 -03:00 17/08/09 06:30:10,250000

De acordo com o resultado acima, podemos notar que os resultados das colunas A e B não se alteraram, ou seja, como o usuário Nova Yorkino não tem conhecimento do fuso horário da região de onde está localizado o banco de dados, o valor da coluna A seria um tanto impreciso. Já o valor da coluna B faria mais sentido pelo fato de apresentar a informação do fuso horário, ou seja, o usuário saberia de forma precisa, o horário em que o dado foi gravado. Por último, podemos perceber que o valor da coluna C foi automaticamente "convertido" para o fuso horário da sessão do usuário que, neste caso é '-5:00'.

Concluindo, o tipo de dado TIMESTAMP WITH LOCAL TIME ZONE é ideal e apropriado para aplicações onde se deseja exibir informações de data e horários usando o fuso horário do sistema cliente.

Oracle mostra sua liderança mais uma vez ...

Olá,

Bom, não sou eu quem está dizendo isso. Essa notícia chegou a mim através de e-mail, pelo fato da empresa em que trabalho ter uma parceria com a Oracle. Acredito que todos os parceiros também tenham recebido esta notícia da Vice-presidente de Alianças e Canais para Oracle América Latina. Para quem não sabe, a Sra. Sandra Vaz é vice-presidente de Alianças e Canais da Oracle para a América Latina e está na Oracle desde 1997, quando assumiu a gerência de Alianças Globais no Brasil. Desde então, galgou diversas posições, entre as quais a de diretora de Alianças na Oracle do Brasil e de diretora de Alianças e Canais para a América Latina. Na atual posição, que ocupa desde maio de 2005, a executiva é responsável por definir a estratégia da Oracle em toda a região no que tange às iniciativas e cobertura de mercado por meio de parcerias com distribuidores, revendas, integradores, fornecedores de hardware, consultorias internacionais e desenvolvedores independentes de software.

No mais, deixo aqui o conteúdo da "newsletter" que recebi intitulada de "From the desk of Sandra Vaz - Oracle mostra sua liderança mais uma vez":

Caros parceiros,

Gostaria de compartilhar duas novidades importantes: em primeiro lugar, tenho o prazer de anunciar que, pela primeira vez na história, neste segundo trimestre, a Oracle superou amplamente a SAP em ganhos por licença. Após sofrer perdas de 11% de seus ganhos totais, a SAP perdeu 40% dos ganhos por venda de licença.

Enquanto a SAP orgulha-se de ter obtido 4% de ganhos líquidos neste trimestre, sua margem operacional continua decrescendo: nos últimos quatro trimestres a margem operacional da SAP chegou a 26%, uma baixa de dois pontos. No entanto, a margem operacional global da Oracle, apesar da conjuntura econômica internacional desfavorável, segue crescendo. Desta forma, teremos mais argumentos para convencer nossos clientes de que devem escolher a Oracle como principal provedor de tecnologia.

A segunda novidade é outra grande notícia: a Oracle adquiriu a GoldenGate Software, dando um passo estratégico para fortalecer produtos complementares e de padrão compatível. As soluções da GoldenGate capturam e oferecem atualizações de informações críticas em tempo real, além de prover informações contínuas e sincronizadas em ambientes heterogêneos. Também melhoram a replicação de dados e a sincronização entre sistemas heterogêneos, garantindo a disponibilidade de dados contínuos para aplicações de negócios por meio de sistemas múltiplos em tempo real. Ela traz às empresas uma excelente inteligência corporativa, com análises mais precisas e oportunas de rendimento. Com essa aquisição, a Oracle e seus parceiros de negócios contam com a mais veloz e escalável solução de integração de dados em tempo real do mercado, o que complementa o valor e as estratégias de negócios futuros de produtos Oracle.

Como todos sabem, também adquirimos a Sun Microsystems oficialmente, outra empresa pioneira no setor, com quem a Oracle mantinha parcerias há vinte anos. O valor da operação foi de cerca de US$ 7,4 bilhões de dólares. De acordo com Larry Ellison, diretor executivo (CEO) da Oracle, "a aquisição da Sun transforma o setor de TI, combinando um excelente software empresarial com os principais sistemas de informática para a missão dos negócios".

Aproveito a oportunidade para agradecer a todos mais uma vez pela dedicação e inteligência que dedicam para que nossas metas em comum sejam cumpridas no dia-a-dia.

Segurança e compressão de dados com o Data Pump Export do Oracle 11g

Olá,

Neste artigo irei comentar um pouco das novas funcionalidades introduzidas no utilitário de exportação Export Data Pump (expdp) do Oracle 11g no que se refere à segurança e compressão dos dados exportados. É fato que os utilitários Data Pump (expdp/impdp) introduzidos à partir do Oracle 10g trouxeram vários recursos e vantagens sobre os utilitários tradicionais (exp/imp) como mais rapidez e flexibilidade nas operações de exportação/importação dos dados, entre outros. Portanto, destaquei alguns dos novos parâmetros adicionados ao utilitário Export Data Pump da versão 11g:

C:\> expdp help=y

Export: Release 11.1.0.6.0 - Production on Segunda-Feira, 03 Agosto, 2009 09:08:45

Copyright (c) 2003, 2007, Oracle.  All rights reserved.

Palavra-Chave         Descrição (Default)
--------------------- ------------------------------------------------------------------
COMPRESSION           Reduzir o tamanho do conteúdo do arquivo de dump onde houver 
                      palavra-chave válida. Os valores são: ALL, (METADATA_ONLY), 
                      DATA_ONLY e NONE.
ENCRYPTION            Criptografa parte ou todo o arquivo de dump onde houver a palavra-
                      chave válida. Os valores são: ALL, DATA_ONLY, METADATA_ONLY,
                      ENCRYPTED_COLUMNS_ONLY ou NONE.
ENCRYPTION_ALGORITHM  Especifica como a criptografia deve ser feita onde for válido. Os
                      valores de palavra-chave são: (AES128), AES192 e AES256.
ENCRYPTION_MODE       Método de gerar chave de criptografia onde houver palavra-chave 
                      válida. Os valores são: DUAL, PASSWORD e (TRANSPARENT).
ENCRYPTION_PASSWORD   Chave de senha para criar dados de coluna criptografados. 
REUSE_DUMPFILES       Sobregrava o arquivo de dump de destino, se existir (N).

Em versões anteriores, se quiséssemos proteger um arquivo dump de exportação de forma que somente pessoas autorizadas pudessem ter acesso ao seu conteúdo afim de realizar uma importação, teríamos que "compactar" o arquivo dump utilizando compactadores de terceiros e, através de senha, proteger o mesmo. No entanto, além de não ser uma tarefa muito interessante, mesmo assim isso não impediria que o arquivo compactado fosse "crackeado" através de softwares específicos para estes tipos de compactação. Uma outra forma seria a de exportar os dados utilizando um usuário de banco de dados com privilégios DBA na qual, para importar o arquivo, apenas outro usuário com privilégios DBA ou com privilégios IMP_FULL_DATABASE conseguiria importar o arquivo. Entretanto, nada impediria alguém de simplesmente carregar o arquivo dump para outro banco de dados e, com os privilégios apropriados, importar os dados.

A boa notícia é que à partir do Oracle 11g o utilitário de exportação Export Data Pump (expdp) veio com algumas inovações como o parâmetro ENCRYPTION_PASSWORD e ENCRYPTION_ALGORITHM na qual poderemos simplesmente definir uma senha criptografada que será armazenada no arquivo dump de exportação. Neste caso, a importação do arquivo através do utilitário Import Data Pump (impdp) somente poderá ser realizada diante da digitação da senha que foi definida na criação do arquivo dump de exportação. Vale a pena salientar que na versão do utilitário expdp 10g R2, o parâmetro ENCRYPTION_PASSWORD era aplicado apenas em colunas encriptadas.

Bom, antes de realizar um exemplo prático sobre este recurso, iniciarei o artigo com um outro recurso que foi adicionado ao utilitário de exportação (expdp) chamado COMPRESSION. Com esta opção poderemos definir um nível de compressão não só dos metadados, mas também dos dados. Na versão 10g, por padrão, a compressão é realizada somente no nível de metadados e, na versão 11g, esta compressão foi estendida também para o nível de dados.

Abaixo realizarei alguns testes comparando a taxa de compressão entre as opções disponíveis:

   compression={all | data_only | metadata_only | none}

onde,
 
* ALL: Ambos os metadados e dados são compactados;
* DATA_ONLY: Somente os dados são compactados.
* METADATA_ONLY: Somente os metadados são compactados. Esta é a opção padrão.
* NONE: Nada é compactado.

Apenas como ilustração, irei exportar um schema de banco de dados na qual atualmente possui aproximadamente 460 MB de dados (entre dados tabelas e índices).

SQL> select sum(bytes)/1024/1024 "TOTAL (MB)" from dba_segments where owner='SCOTT';

TOTAL (MB)
----------
   460,875


-- Utilizando o expdp da versão 11g (sem nenhuma compactação)
C:\> expdp scott/tiger DIRECTORY=datapump_dir DUMPFILE=expdp11_compress_none.dmp
     compression=none

-- Utilizando o expdp da versão 10g (compactação padrão)
C:\> expdp scott/tiger DIRECTORY=datapump_dir DUMPFILE=expdp10.dmp

-- Utilizando o expdp da versão 11g (compactando apenas metadados)
C:\> expdp scott/tiger DIRECTORY=datapump_dir DUMPFILE=expdp11_compress_metadata_only.dmp
     compression=metadata_only

-- Utilizando o expdp da versão 11g (compactando apenas dados)
C:\> expdp scott/tiger DIRECTORY=datapump_dir DUMPFILE=expdp11_compress_data_only.dmp
     compression=data_only

-- Utilizando o expdp da versão 11g (compactando dados e metadados)
C:\> expdp scott/tiger DIRECTORY=datapump_dir DUMPFILE=expdp11_compress_all.dmp
     compression=all

-- Utilizando o exp 11g tradicional
C:\> exp scott/tiger file=exp_traditional.dmp

Abrindo um parênteses aqui, podemos ver abaixo que a estimativa de tamanho para o dump gerado será de aproximadamente 413 MB, bem próximo ao tamanho real dos arquivos de exportação gerados, que não passaram de 395 MB.

Export: Release 11.1.0.6.0 - Production on Segunda-Feira, 03 Agosto, 2009 09:10:35

Copyright (c) 2003, 2007, Oracle.  All rights reserved.

Conectado a: Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Estimativa em andamento com o método BLOCKS...
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TABLE_DATA
Estimativa total usando o método de BLOCKS: 413.8 MB

Vamos então aos resultados dos tamanhos dos arquivos dump gerados (em MB) pelas exportações:

[Linux tmp]$ ls -hlatr *.dmp
(1) -rw-r----- 1 oracle oinstall 395M Ago  3 09:12 expdp11_compress_none.dmp
(2) -rw-r----- 1 oracle oinstall 384M Ago  3 09:19 expdp10.dmp
(3) -rw-r----- 1 oracle oinstall 384M Ago  3 09:25 expdp11_compress_metadata_only.dmp
(4) -rw-r----- 1 oracle oinstall 137M Ago  3 09:32 expdp11_compress_data_only.dmp
(5) -rw-r----- 1 oracle oinstall 125M Ago  3 09:39 expdp11_compress_all.dmp
(6) -rw-r----- 1 oracle oinstall 382M Ago  3 09:42 exp_traditional.dmp

De acordo com a listagem acima, a primeira exportação (1) realizada utilizando o expdp da versão 11g com a opção (compression=none) gerou um arquivo dump de 395 MB de tamanho.

A segunda exportação (2) realizada utilizando o expdp da versão 10g gerou um arquivo dump de 384 MB de tamanho, ou seja, o arquivo foi compactado a uma proporção de cerca de 97% em relação ao arquivo dump gerado pela exportação (1) na qual não foi utilizada nenhuma opção de compressão. Como dito anteriormente, apenas os metadados são compactados na versão 10g:

A terceira exportação (3) realizada utilizando o expdp da versão 11g com a opção (compression=metadata_only) gerou um arquivo dump de 384 MB, ou seja, a mesma taxa de compressão que foi utilizada com o utilitário expdp da versão 10g.

A quarta exportação (4) realizada utilizando o expdp da versão 11g com a opção (compression=data_only) gerou um arquivo dump de 137 MB, ou seja, o arquivo foi compactado a uma proporção de cerca de 35% em relação ao arquivo dump gerado pela exportação (3), onde foi utilizada a opção (compression=metadata_only).

A quinta exportação (5) realizada utilizando o expdp da versão 11g com a opção (compression=all) gerou um arquivo dump de 125 MB, ou seja, o arquivo foi compactado a uma proporção de cerca de 32% em relação ao arquivo dump gerado pela exportação (4), onde foi utilizada a opção (compression=data_only).

Para não deixar o export tradicional (exp) de lado, a sexta exportação (6) foi realizada utilizando o exp da versão 11g que gerou um arquivo dump de 382 MB, ou seja, o arquivo criado teve uma proporção de cerca de 99% em relação ao arquivo dump gerado pela exportação (3), onde foi utilizado o utilitário expdp com a opção (compression=data_only).

Apenas para fins de comparação, irei utilizar um dos compactadores mais conhecidos do mercado para de compactar o arquivo de 384 MB (expdp11_compress_metadata_only.dmp).

[Linux tmp]$ zip expdp11_compress_metadata_only.zip expdp11_compress_metadata_only.dmp
  adding: expdp11_compress_metadata_only.dmp (deflated 69%)

[Linux tmp]$ ls -lh *.zip
-rw-r--r-- 1 oracle oinstall 119M Ago 03 09:45 expdp11_compress_metadata_only.zip

Podemos perceber acima que o arquivo foi compactado a uma proporção de cerca de 31% em relação ao arquivo original, ou seja, praticamente a mesma proporção utilizando a opção (compression=data_only) do utilitário expdp.

Já que utilizei o "zip" porque não usar o famoso "Winrar"? Fazendo um teste, o arquivo original de 384 MB foi compactado a uma proporção de cerca de 17%, ou seja, o tamanho do arquivo de 384 MB foi reduzido para 65,8 MB.

No geral, e deixando de lado os compactadores de terceiros, podemos perceber uma diferença "gritante" de compressão do arquivo dump de exportação quando utilizamos as opções (data_only) ou (all) do utilitário Export Data Pump 11g.

Protegendo o arquivo dump de exportação com senha

Agora irei comentar um pouco sobre outro recurso muito interessante que, como dito anteriormente, à partir do Oracle 11g, o utilitário de exportação Export Data Pump (expdp) disponibilizou os parâmetros ENCRYPTION_PASSWORD e ENCRYPTION_ALGORITHM na qual poderemos definir de forma "nativa", uma senha criptografada que será armazenada no arquivo dump de exportação. Neste caso, a importação do arquivo através do utilitário Import Data Pump (impdp) somente poderá ser realizada diante da digitação da senha que foi definida na criação do arquivo dump de exportação. Meu foco aqui será demonstrar a utilização do método (modo) PASSWORD.

De acordo com a documentação, o "Data pump encryption" é um recurso relevante apenas para instalações do Oracle 11g Enterprise Edition. Para maiores detalhes sobre os parâmetros abaixo, recomendo acessar a documentação oficial.

O parâmetro ENCRYPTION possui as seguintes opções:

ENCRYPTION = {all | data_only | encrypted_columns_only | metadata_only | none}

O parâmetro ENCRYPTION_PASSWORD possui as seguintes opções de algoritmos para criptografia:

ENCRYPTION_ALGORITHM = { AES128 | AES192 | AES256 }

O parâmetro ENCRYPTION_MODE especifica o método para geração da chave de criptografia:

ENCRYPTION_MODE = { DUAL | PASSWORD | TRANSPARENT }

O parâmetro ENCRYPTION_PASSWORD é utilizado para informarmos a senha que será criptografada.

Vale a pena salientar que o valores padrões desses parâmetros dependerão de uma combinação dos mesmos. Se somente o parâmetro ENCRYPTION_PASSWORD for especificado, então o parâmetro ENCRYPTION terá por padrão o valor ALL. Se nenhum dos parâmetros ENCRYPTION e ENCRYPTION_PASSWORD for especificado, então o parâmetro ENCRYPTION terá por padrão o valor NONE. No caso do parâmetro ENCRYPTION_ALGORITHM, seu valor padrão é AES128.

Vamos então a um exemplo prático:

C:\> expdp scott/tiger DIRECTORY=datapump_dir DUMPFILE=expdp11_senha.dmp 
     encryption=all 
     encryption_mode=password 
     encryption_password=minhasenha

Após a execução do comando acima o arquivo dump gerado foi criado como demonstrado abaixo:

[Linux tmp]$ ls -hlatr *.dmp
-rw-r----- 1 oracle oinstall 384M Ago  3 09:50 expdp11_senha.dmp

Irei simular agora a importação do arquivo dump para um outro schema de banco de dados. Para isso irei criar o usuário de banco de dados ADAM como demonstrado abaixo:

C:\> sqlplus system/manager

SQL*Plus: Release 11.1.0.6.0 - Production on Seg Ago 3 09:55:06 2009

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

Conectado a:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> create user adam identified by jones default tablespace users;

Usuário criado.

SQL> grant connect,resource to adam;

Concessão bem-sucedida.

Após a criação do usuário ADAM no banco de dados, irei realizar a importação do arquivo dump criptografado:

-- Realizando a importação sem informar a senha
C:\> impdp adam/jones DIRECTORY=datapump_dir DUMPFILE=expdp11_senha.dmp

Import: Release 11.1.0.6.0 - Production on Segunda-Feira, 03 Agosto, 2009 09:57:46

Copyright (c) 2003, 2007, Oracle.  All rights reserved.

Conectado a: Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORA-39002: operação inválida
ORA-39174: A senha de criptografia deve ser fornecida.


-- Realizando a importação especificando uma senha inválida
C:\> impdp adam/jones DIRECTORY=datapump_dir DUMPFILE=expdp11_senha.dmp 
     encryption_password=senhaerrada

Import: Release 11.1.0.6.0 - Production on Segunda-Feira, 03 Agosto, 2009 10:03:55

Copyright (c) 2003, 2007, Oracle.  All rights reserved.

Conectado a: Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORA-39002: operação inválida
ORA-39176: A senha de criptografia está incorreta.


-- Realizando a importação especificando a senha correta
C:\> impdp adam/jones DIRECTORY=datapump_dir DUMPFILE=expdp11_senha.dmp 
     encryption_password=minhasenha 
     remap_schema=scott:adam

Import: Release 11.1.0.6.0 - Production on Segunda-Feira, 03 Agosto, 2009 10:05:48

Copyright (c) 2003, 2007, Oracle.  All rights reserved.

Conectado a: Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Tabela-mestre "ADAM"."SYS_IMPORT_FULL_01" carregada/descarregada com sucesso
Iniciando "ADAM"."SYS_IMPORT_FULL_01":  adam/******** DIRECTORY=datapump_dir
DUMPFILE=expdp11_senha.dmp encryption_password=******** remap_schema=scott:adam
Processando o tipo de objeto SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processando o tipo de objeto SCHEMA_EXPORT/SEQUENCE/SEQUENCE
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TABLE
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TABLE_DATA
. . importou "ADAM"."EMP"                        330.6 MB    1352 linhas
. . importou "ADAM"."DEPT"                       9.157 MB   55417 linhas
.
.
.

Para finalizar, o Export Data Pump da versão 11g, trouxe também um novo parâmetro chamado REUSE_DUMPFILES que poderá ser utilizado para que possamos sobrescrever um arquivo dump gerado anteriormente sem a necessidade de ter que exclui-lo manualmente como nas releases anteriores (10g R1/R2):

C:\> expdp scott/tiger DIRECTORY=datapump_dir DUMPFILE=expdp11_senha.dmp 
     encryption=all 
     encryption_mode=password 
     encryption_password=minhasenha

Export: Release 11.1.0.6.0 - Production on Segunda-Feira, 03 Agosto, 2009 10:09:38

Copyright (c) 2003, 2007, Oracle.  All rights reserved.

Conectado a: Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORA-39001: valor de argumento inválido
ORA-39000: especificação de arquivo de dump incorreto
ORA-31641: não é possível criar o arquivo de dump "/tmp/expdp11_senha.dmp"
ORA-27038: arquivo criado já existe
Additional information: 1


C:\> expdp scott/tiger DIRECTORY=datapump_dir DUMPFILE=expdp11_senha.dmp 
     encryption=all 
     encryption_mode=password 
     encryption_password=minhasenha 
     reuse_dumpfiles=y

Export: Release 11.1.0.6.0 - Production on Segunda-Feira, 01 Agosto, 2009 10:15:26

Copyright (c) 2003, 2007, Oracle.  All rights reserved.

Conectado a: Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Iniciando "SCOTT"."SYS_EXPORT_SCHEMA_01":  scott/******** DIRECTORY=datapump_dir 
DUMPFILE=expdp11_senha.dmp encryption=all encryption_mode=password 
encryption_password=******** reuse_dumpfiles=y
Estimativa em andamento com o método BLOCKS...
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TABLE_DATA
Estimativa total usando o método de BLOCKS: 413.8 MB
Processando o tipo de objeto SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processando o tipo de objeto SCHEMA_EXPORT/SEQUENCE/SEQUENCE
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TABLE
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/INDEX/INDEX
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/COMMENT
Processando o tipo de objeto SCHEMA_EXPORT/PACKAGE/PACKAGE_SPEC
Processando o tipo de objeto SCHEMA_EXPORT/FUNCTION/FUNCTION
Processando o tipo de objeto SCHEMA_EXPORT/PROCEDURE/PROCEDURE
Processando o tipo de objeto SCHEMA_EXPORT/PACKAGE/COMPILE_PACKAGE/PACKAGE_SPEC/ALTER...
Processando o tipo de objeto SCHEMA_EXPORT/FUNCTION/ALTER_FUNCTION
Processando o tipo de objeto SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE
Processando o tipo de objeto SCHEMA_EXPORT/VIEW/VIEW
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TRIGGER
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
. . exportou "SCOTT"."EMP"                  330.6 MB    1352 linhas
. . exportou "SCOTT"."DEPT"                 9.157 MB   55417 linhas
.
.
.