Na postagem de hoje não vou publicar um artigo, farei algo diferente, vou compartilhar um vídeo em que eu demonstro a instalação do Oracle Database 11GR2 Express Edition + instalação do SQL Developer 3.0, em um Sistema Operacional Windows. Além da instalação, no vídeo faço vários comentários sobre as vantagens e desvantagens da versão Express do Oracle Database e sobre características do SQL Developer e mostro no final, como se conectar no Banco de Dados utilizando o SQL Developer.

Estou escrevendo este artigo para fazer um comparativo e comentar sobre algumas vantagens e recursos dos 2 bancos de dados (BDs) mais utilizados nas grandes empresas do Brasil: Oracle e SQL Server, conforme pesquisa realizada em 2005 pelo Grupo Impacta (ver Figura 1). Embora a pesquisa de 2005 não seja tão recente, ela foi a mais confiável e concisa que eu encontrei para demonstrar a nossa realidade (o que temos nas empresas brasileiras).

Figura 1 – BDs mais utilizados nas grandes empresas brasileiras (Grupo Impacta 2005)

Conheço os 2 BDs que vou comentar neste artigo, porém conheço muito melhor o BD Oracle, por isso gostaria que os profissionais que estiverem lendo este artigo, deixem comentários que possam acrescentar mais detalhes sobre o SQL Server e recursos que existem nele e que não tenham itens correspondentes no Oracle.

Seguem abaixo as principais características de cada BD:

SQL Server:

- SGBD comercializado atualmente pela Microsoft. Nasceu em 1988, a partir de uma parceria entre Microsoft, Sybase e Aston-Tate;

- Última versão: SQL Server 2008;

- Custo de uma licença da versão Enterprise por CPU: aprox. U$ 28.000 por CPU;

- Pode ser instalado somente em SO Windows;

- Possui ferramentas de administração com interface gráfica excelentes, que possibilitam um gerenciamento mais fácil e produtivo. Ex.: SQL Server Management Studio 2008;

- Como toda ferramenta Microsoft, o BD SQL Server em geral, é mais fácil de administrar e de programar do que em Oracle.

- 2 recursos que acho bastante interessantes em SQL Server e que não existem correspondência no Oracle, são:

a) Divisão lógica de uma instância contendo vários BDs. No Oracle temos apenas vários schemas. O SQL Server possui uma camada extra onde cada BD pode conter vários usuários ou schemas. Desse modo, podemos organizar e gerenciar melhor schemas correlacionados, pertencentes a uma mesma aplicação, em um BD isolado dos demais schemas do BD;

b)  Possui um schema do sistema chamado MODEL que serve como template para schemas de usuários. Se por exemplo, o schema MODEL tiver 2 tabelas e uma visão, ao criar um novo schema de usuário, ele será criado com estes mesmos objetos.

Oracle:

-  SGBD comercializado atualmente pela Oracle, que nasceu em 1979 e que foi o primeiro BD relacional comercializado no mundo;

- Última versão: Oracle Database 11G;

- Custo de uma licença da versão Enterprise por CPU: U$ 47.500 (até 2 core);

- Pode ser instalado em múltiplas plataformas desde 1985. Entre as principais, podemos citar: Unix, Linux, HP/UX, BIM AIX, IBM VMS e Windows;

- Possui ferramentas de administração com interface gráfica menos amigáveis que as do SQL Server. Isso vem mudando e melhorando a cada nova versão do Oracle. No 10G, o Enterprise Manager possui muitos recursos e sua interface gráfica evoluiu muito, mas ainda acho que as ferramentas da Microsoft são mais intuitivas e mais produtivas. No Oracle o DBA costuma gerenciar muitas atividades do BD através de conjuntos de scripts;

- Possui uma documentação muito bem detalhada, o que de início até assusta, mas permite que você conheça muito bem o BD e todos os seus recursos;

- Possui mais recursos de segurança e performance que o SQL Server. Exemplos:

a) Por padrão, o Oracle não commita transações. Isso permite que você desfaça as alterações de uma instrução SQL, caso ela tenha sido submetido erroneamente. No SQL, por padrão as intruções SQL são auto-commitadas, o que facilita o trabalho geral dos desenvolvedores, mas que dificulta o trabalho de recuperação por danos acidentais e o controle transacional;

b) Por padrão, o Oracle permite efetuar leitura consistente de dados. Esse recurso permite que um usuário “B” leia os dados de uma linha de uma tabela, no mesmo momento em que ela está sendo alterada por um usuário “A”, sem que o usuário “B” visualize os dados que estão sendo alterados pelo “A”. Não há bloqueio de leitura nem risco do usuário “B” visualizar os dados que ainda não foram commitados pelo usuário “A”. No SQL Server esse não é o comportamento padrão do BD, portanto, desenvolvedores inexperientes poderão desenvolver aplicações com sérios problemas de performance no acesso concorrente, se não tiverem os conhecimentos necessários para contornar bloqueios de leitura aos dados;

c) Arquitetura mais flexível e com mais recursos para otimização de performance. No Oracle é possível criar e gerenciar diversas estruturas de memória no BD. É possível, por exemplo, definir estruturas de armazenamento com tamanhos de blocos que podem variar de 2k à 32k. No SQL Server só é possível criar estruturas de armazenamento de 8k. Em Oracle, sistemas OLAP e índices em geral, são otimizados com tamanhos de blocos maiores (32k);

d) Possui Packages, que são objetos que permitem (entre diversos outros benefícios) agrupar e encapsular código de stored procedures e funções;

e) Possui Sequences (que já li em alguns blogs que será implementado no SQL Server 2012). Sequences possuem muito mais recursos do que colunas de auto-incremento, existentes em SQL Server, para definir valores de chaves-primárias. Um exemplo que posso citar é o cache de Sequences, que permite otimizar a performance de inserções que necessitam de um valor único para compor a chave-primária (ver artigo http://www.fabioprado.net/2010/09/cache-em-oracle-sequences.html;

f) O Oracle possui mais tipos de índices que o SQL Server. Índices permitem otimizar consultas em BD. 2 exemplos que vou citar no Oracle que não existem itens correspondentes no SQL Server são: índices BITMAP (que permitem otimizar consultas em colunas com baixa cardinalidade) e índices Baseados em função (que permitem indexar funções em colunas);

g) Permite criar um ou mais processos chamados listeners, que são utilizados para conectar clientes remotos ao BD. Uma das vantagens de ter este tipo de processo é que a conexão ao BD pode ser distribuída entre diversos listeners, ou seja, podemos configurar múltiplos listeners para grupos menores de usuários, para ouvir em portas diferentes, com o objetivo de evitar gargalos de conexão ao BD quando temos muitos usuários (normalmente mais de 200 conexões por segundo) se conectando ao mesmo tempo;

h) O Oracle possui um modelo de controle de acesso concorrente chamado multiversion read consistency (MVRC) que é um dos melhores modelos do mercado para permitir um controle de acesso concorrente com menor contenção de linhas e consequentemente, melhor performance quando há acesso concorrente aos dados. No Oracle o controle de bloqueios é realizado através da gravação de indicadores de bloqueio no nível das linhas, já no SQL Server existe um componente chamado Lock Manager para fazer o mesmo trabalho. No Lock Manager há uma sobrecarga maior para gerenciar uma grande qtde. de bloqueios, que consequentemente pode degradar a performance de atualizações e acessos concorrentes.

CONCLUSÃO:

A percepção que eu tenho é que a Microsoft tem um histórico de manter o foco na entrega de produtos mais fáceis de se utilizar e de gerenciar. A Oracle, por sua vez, tem foco na entrega de produtos com mais segurança e com vasta gama de recursos.

Ambos são ótimos BDs e cada um tem suas vantagens e desvantagens. O SQL Server tem a principal vantagem de ter um custo menor, aproximadamente metade do preço de um Oracle. no SQL Server existem algumas funcionalidades (Ex.: Particionamento de tabelas) que também existem no Oracle, mas que no SQL Server não precisa de licença adicional, enquanto que, no Oracle, é necessário adquirir licenças adicionais (Options), o que torna o produto Oracle mais caro ainda. Outra vantagem do SQL Server é a facilidade de uso e gerenciamento. Eu, particularmente, quando comecei a trabalhar com Oracle, achava tudo muito difícil. As ferramentas do SQL Server eram mais produtivas e mais intuitivas.

O Oracle tem um custo mais alto que o SQL Server e é mais difícil de administrar, porém é um produto que possui mais recursos de segurança e performance, que podem ser muito importantes e cruciais para empresas que possuem aplicações críticas e que possuem muitos dados e muitos usuários concorrentes, em geral.

Para finalizar, vou responder agora a questão que é o título deste artigo: Qual é o melhor BD: Oracle ou SQL Server?

R.: Bom… isso depende da necessidade! De um modo geral, acredito que o SQL Server é mais indicado para pequenas e médias empresas ou pequenas e médias aplicações, devido ao custo menor desse BD e porque normalmente as aplicações que são executadas nestes ambientes possuem menor quantidade e complexidade de requisitos. O Oracle, por sua vez, é mais indicado para grandes empresas ou grandes aplicações, que possuem requisitos de negócios mais complexos e críticos, e que possuem grana para pagar pelos recursos de segurança e performance adicionais que este BD oferece.

Por hoje é só! Deixem seus comentários!

Referências:

• http://www.linhadecodigo.com.br/artigo/2412/Análise-de-desempenho-entre-os-bancos-de-dados-SQL-Sever-x-Oracle.aspx
• http://www.dba-oracle.com/t_sql_server_vs_oracle_terminology.htm
• http://stackoverflow.com/questions/2322260/basic-differences-between-oracle-and-sql-server
• http://pt.wikipedia.org/wiki/Oracle_(banco_de_dados)
• http://msdn.microsoft.com/pt-br/library/ms175049.aspx
• http://en.wikipedia.org/wiki/Microsoft_SQL_Server

[]s

Fonte: http://www.fabioprado.net/2012/01/qual-e-o-melhor-banco-de-dados-oracle.html

No artigo de hoje vou escrever sobre um assunto que eu comento e demonstro em mais detalhes nos meus treinamentos de Tuning de SQL em Oracle 10G/11G, que é a performance das stored procedures (SPs) nas aplicações. O uso de stored procedures, em substituição ao uso de instruções SQL, pode otimizar drásticamente a performance de aplicações que acessam/atualizam bancos de dados (BDs).

No exemplo deste artigo as regras de negócio estão dentro da SPs. Muita gente é contra esta prática, pois aprendemos em arquitetura de sistemas que as regras de negócio devem ficar na aplicação e não no BD. Concordo em partes, pois em aplicações críticas, que exigem alta performance, o que é mais importante: uma aplicação filosóficamente melhor (com regras de negócio na aplicação) ou uma aplicação mais rápida?

Vou demonstrar a seguir, um exemplo de uma aplicação bem simples que eu desenvolvi com o Dot Net Framework 3.5, para provar o conceito de que SPs podem otimizar a performance das aplicações. A aplicação, chamada Teste de performance de transações, poderá ser baixada para testes e é totalmente parametrizável (ver arquivo TesteTransacao.exe.config). Ela simula a realização de simples transferências entre contas bancárias, retirando o valor de uma conta corrente (conta origem) e depositando o respectivo valor em outra conta corrente (conta destino).

Figura 1 – Tela principal da aplicação “Testes de performance de Transações”

A operação de transferência ocorre em modo transacional (deve fazer tudo ou nada, se 1 passo falhar, desfaz os passos anteriores), composto por 3 passos:

a) Verificar se a conta origem possui saldo para efetuar a transferência;

b) Retirar (sacar) valor da conta origem;

c) Depositar valor na conta destino;

A aplicação está disponível para download no MEU SKY DRIVE (ver painel direito da página principal do meu blog), pasta Oracle -> Scripts, arquivo TesteTransacao.zip. Para efetuar a instalação e utilizá-la, siga os passos abaixo:

1- Descompactar o arquivo TesteTransacao.zip;

2- Conectar-se no BD desejado e instalar os objetos de BD (tabela CONTA e package PKG_CONTA) que estão no arquivo Script_BD_Teste_Transacao.sql. Instale os objetos no schema de um usuário que será utilizado pela aplicação para conectar-se no BD.

3- Configurar os valores (values) dos parâmetros (keys) do arquivo TesteTransacao.exe.config, conforme indicações abaixo:

1. instance_name = Nome da instância do BD onde os objetos foram criados. Especificar nome de uma instância cadastrada no arquivo tnsnames.ora da máquina em que a aplicação irá ser executada;
2. user_name = Nome do usuário que a aplicação utilizará para conectar-se no BD;
3. pwd_user = Senha do usuário que a aplicação utilizará para conectar-se no BD;
4. idContaOrigem = Número da conta origem;
5. idContaDestino = Número da conta destino;
6. vlInicialContaOrigem = Valor inicial da conta origem;
7. vlInicialContaDestino = Valor inicial da conta destino;
8. intTotalInteracoes = Valor indicando qtde. de operações de transferências que serão realizadas;
9. vlTransferencia = Valor da transferência.

Para efetuar os testes, basta clicar nos 2 botões existentes na tela principal da aplicação: Transferência Ad hoc e Transferência com SP. O botão Transferência Ad hoc submete instruções SQL para o BD, enquanto que, o botão Transferência com SP, executa uma stored procedure no BD para executar as mesmas instruções SQL.

Vejam abaixo, a performance de testes que eu fiz:

TESTE 1: 1 transferência bancária

a) Tempo de Transferência do botão Transferência Ad hoc: 0,015s

Figura 2 – Teste de 1 transferência com SQL (ad hoc)

b) Tempo de Transferência do botão Transferência com SP:  0,00s

Figura 3 – Teste de 1 transferência com SP

TESTE 2: 1000 transferências bancárias

a) Tempo de Transferência do botão Transferência Ad hoc: 9,90s

Figura 4 – Teste de 1000 transferências com SQL (ad hoc)

b) Tempo de Transferência do botão Transferência com SP: 0,23s

Figura 5 – Teste de 1000 transferências com SP

CONCLUSÃO:

No Teste 1, de acordo com o tempo de execução da transferência SQL e transferência com SP, pudemos verificar que a 2ª (com SP) foi mais rápida, mas o teste com 1 só transferência não foi não tão eficiente para demonstrar o ganho em usar SP (a execução foi tão rápida que não foi possível computar o tempo (0,00s) através da aplicação).

No Teste 2, realizando 1000 transações, conseguimos verificar que o ganho de performance utilizando SP foi brutal. Com SP, pudemos verificar que o tempo das 1000 transferências foi 43 vezes mais rápido que as 1000 transferências submetendo SQL para a aplicação.

Mais detalhes, sobre a estrutura da aplicação, o porquê da stored procedure apresentar um desempenho superior neste exemplo e sobre a implementação de regras de negócio na aplicação ou na stored procedure, eu explico em meus treinamentos!

Por hoje é só!

[]s

Fonte: http://www.fabioprado.net/2011/09/otimizando-performance-de-aplicacoes.html

No artigo de hoje vou apresentar rapidamente uma ferramenta muito interessante que estou utilizando para executar benchmark de performance em Bancos de Dados Oracle, o Swingbench. Swingbench é um software livre que foi desenvolvido em Java por Dominic Giles (especialista em Banco de dados da Oracle UK), projetado para executar e monitorar cargas de dados em Bancos de Dados Oracle 10G e 11G, instâncias standalone ou RAC. Ele pode ser instalado em Windows, Linux e vários outros sistemas operacionais e possui funcionalidades para simulação de 4 tipos de aplicações, entre elas a de Entrada de Pedidos, que funciona bem no Oracle 11G e que será apresentada neste artigo.

Para baixar o Swingbench, entre em http://www.dominicgiles.com/downloads.html. Após baixá-lo, se o SO da máquina for Linux, faça a instalação conforme as instruções do link http://www.dominicgiles.com/installation.html. Se o SO for Windows, substitua no roteiro do link anterior, os processos necessários para efetuar a instalação do Java (se não houver instalação prévia)  e configure as variáveis de ambiente JAVAHOME e SWINGHOME apontando para os diretórios indicados no link.

Para usar a ferramenta é necessário criar antes da primeira utilização, os objetos de BD que serão utilizados para efetuar os testes. Para executar a instalação e iniciar os testes, leia e execute o que está descrito no link http://www.dominicgiles.com/simplebenchmark.html. O script oewizard deverá ser executado uma única vez para criar os objetos de BD. Após a criação destes objetos, execute o script swingbench  para inicializar a aplicação e permitir o início dos testes de performance. 

Eu estou utilizando este software para comparar performance de servidores de desenvolvimento, homogação e produção que eu administro e também utilizarei futuramente para medir performance quando houver upgrade de hardware de servidor de BD ou quando for efetuada uma migração de versão de BD.

Os principais indicadores de peformance que o Swingbench fornece e que eu acho que são os mais interessantes para efetuar as comparações de peformance, são: Average TPM (média de transações por minuto) e Average TPS (média de transações por segundo). Seguem abaixo o valor do indicador Average TPM dos BDs em que eu fiz os testes por um tempo de 2 minutos (configurável na ferramenta) simulando 15 sessões de usuários concorrentes, seguidos por imagens contendo todos os indicadores que a ferramenta disponibiliza em um gráfico de visão geral:

1. Produção (Oracle 10g): 657;
2. Homologação (Oracle 10g): 618;
3. Desenvolvimento (Oracle 11g): 684.

Imagem 1 – Teste de performance do servidor de produção

Imagem 2 – Teste de performance do servidor de homologação

Imagem 3 – Teste de performance do servidor de desenvolvimento

CONCLUSÃO

A ferramenta Swingbench  é uma ótima opção para fazer benchmark de performance entre BDs distintos e até mesmo para comparar a performance de um BD, contemplando o estado “antes” e “depois” de alguma alteração ou atualização.

Nos testes que eu fiz, o servidor de desenvolvimento foi o que apresentou melhor performance, porém, ressalto que ele é o único que eu já atualizei para a versão 11g do Oracle Database (ainda não sei se isso influenciou na performance) e que os BDs de desenvolvimento e homologação estavam ociosos no momento da realização dos testes. Os testes no BD de produção foram realizados em um período que concorreu com atividades de sessões de usuários de outras aplicações.

Por hoje é só!

[]s

Referências: http://www.dominicgiles.com/swingbench.html
Fonte: http://www.fabioprado.net/2011/11/benchmark-de-performance-em-banco-de.html

Primeiramente, gostaria de agradecer ao Fábio Prado pela oportunidade de escrever este artigo, que tem como objetivo principal apresentar um método fácil e eficiente para exportar dados de tabelas do Banco de Dados MS SQL Server para o Banco de Dados (BD) Oracle.

Utilizaremos para exportação dos dados o Oracle SQL Developer 3.0,  que além de ser free, já é uma ferramenta bem estável e consolidada. Para mais informações, consulte neste blog o post Conhecendo o novo Oracle SQL Developer 3.0. Este artigo não ensinará a utilizar o SQL Developer 3.0, portanto, é necessário que você já tenha familiaridade e conhecimentos prévios nesta ferramenta.

Para iniciar a exportação, abra o SQL Developer e configure-o para acessar o Banco de Dados SQL Server, seguindo os passos descritos no link: http://djiang.wordpress.com/2007/02/27/using-oracle-sqldeveloper-to-access-sqlserver/. Em seguida, crie uma conexão ao BD SQL Server, como no exemplo da Figura 1 (ver abaixo).

Figura 1 – Conexão com o SQL Server

No exemplo utilizado neste artigo, iremos exportar uma tabela chamada CLIENTES, do banco de dados MASTER do SQL Server. Para exportá-la devemos acessar MASTER >> dbo >> Tabelas >> CLIENTES (ver Figura 2).

• Possibilidade de reutilizar programas testados e estáveis, desenvolvidos em classes Java, ao invés de desenvolver algo novo em PL/SQL;
• Ganhar tempo utilizando um programa que já está pronto ao invés de desenvolver um novo;
• Possibilidade de expandir recursos de programação, pois Java possui muito mais recursos que PL/SQL para interagir, por exemplo, com o SO e programas externos.

• A performance é muito menor em relação a um programa PL/SQL puro;
• Aumenta-se a dificuldade de gerenciamento do BD, pois neste caso o DBA ou responsável pelo BD precisará gerenciar objetos externos, que normalmente ele não está acostumado a lidar, e isso poderá provocar problemas quando houver migração de BD para outras máquinas ou ambientes em que a classe Java não foi instalada;
• Será necessário gerenciar uma área de memória adicional do BD, chamada Java Pool.

• Aceita como entrada um valor alfanumérico correspondente à data de nascimento de uma pessoa;
• Retorna um valor numérico correspondente à idade atual da pessoa.

Passo 4- Executando a função:

No artigo de hoje compartilharei com vocês 2 apresentações que montei sobre as Certificações OCA e OCP nos Bancos de Dados Oracle 10G e 11G. Cada apresentação contempla uma versão (10G ou 11G) do Oracle Database e comenta sobre os principais pontos que devem ser considerados no processo de preparação para a certificação:

• Caminho para obter a certificação;
• Exames necessários;
• Como efetuar o agendamento e pagamento dos exames;
• Conhecimentos necessários;
• Treinamentos indicados;
• Dicas para estudos.

As apresentações estão disponíveis para download no blog www.fabioprado.net, Meu Sky Drive (ver painel direito superior do blog), pasta Oracle -> Apresentacoes, arquivos Certificacao_OCA_OCP_10G.pdf e Certificacao_OCA_OCP_11G.pdf.

Estou negociando uma parceria com a empresa Capitani IT Solutions (www.capitani.com.br) para fazer palestras gratuitas (com duração aproximada de 3 horas) sobre Certificação no Oracle Database a partir do ano de 2012. Também escrevi um artigo bem mais detalhado sobre este assunto para a revista SQL Magazine, que deverá ser publicado na edição do mês 12/2011. Empresas que tiverem interesse em assistir uma apresentação IN-COMPANY, entrem em contato no e-mail fbifabio@gmail.com.

[]s

Referência: http://www.fabioprado.net/2011/11/certificacao-oca-e-ocp-no-oracle.html.

No artigo de hoje vou falar um pouco sobre PL/SQL, a linguagem procedural do Oracle Database.

Todos os SGBDs (Sistemas Gerenciadores de Banco de Dados) que eu conheço possuem uma linguagem de programação própria, que estende comandos e instruções não contempladas em SQL. Como exemplos, podemos citar o Oracle Database, que possui a linguagem PL/SQL, o SQL Server que possui a linguagem Transaction SQL e o DB2 que possui a linguagem SQL PL. Essas linguagens foram criadas para atender a necessidade de se criar programas dentro do próprio banco de dados e são extremamente úteis para executar tarefas de manutenção e para otimizar transações das aplicações que acessam o banco. No meu blog você encontrará vários artigos que usam código PL/SQL dentro destes cenários de manutenção e otimização, como por exemplo:

– Otimizando a performance de aplicações com stored procedures:
http://www.fabioprado.net/2011/09/otimizando-performance-de-aplicacoes.html

- PL/SQL mais rápido: Quando usar CURSORES ou collections (BULK COLLECT em NESTED TABLES)?
http://www.fabioprado.net/2011/05/plsql-mais-rapido-quando-usar-cursores.html

– Recompilando objetos inválidos no Oracle Database:
http://www.fabioprado.net/2011/05/recompilando-objetos-invalidos-no.html

Uma das principais vantagens da linguagem PL/SQL é permitir que você escreva programas que ficam armazenados no banco de dados e que podem ser reutilizados por qualquer aplicação/usuário que acesse o banco. Segundo Thomas Kyte, um dos maiores especialistas em Oracle do mundo, PL/SQL é a forma mais rápida de processar dados em Bancos de Dados Oracle. Entenda “processar dados” como não apenas submeter instruções SQL (UPDATE, SELECT, INSERT e DELETE) para o banco, mas sim, efetuar transações que consistem de várias estruturas de decisão, loops e outros tipos de processamento.

Como qualquer linguagem de programação, em PL/SQL é possível escrever código bom ou ruim. Para evitar enganos e não escrever código ruim, que também podem ser cometidos em qualquer outra linguagem, é necessário entender bem a estrutura do código PL/SQL, os detalhes de sua implementação e até mesmo como ele interage com código SQL.

Bom, hoje eu paro por aqui! Se quiserem conhecer melhor a linguagem PL/SQL e escrever código bem estruturado e com boa performance, eu ensino estes itens no meu treinamento de PL/SQL.

[]s

Antes de lerem este artigo, sugiro que leiam outro artigo que escrevi sobre como obter as certificações Oracle Database 10G (Entendendo o Programa de Certificação Oracle Database 10G). Atualmente ele é o artigo mais lido e mais comentado no meu blog, que orienta sobre o caminho completo para obter as certificações OCA, OCP e OCM, e que contém várias dicas de materiais de estudo.

Decidi escrever este artigo agora porque passei no exame 1Z0-043, por isso este é o melhor momento para eu escrever sobre como obter a certificação OCP Database 10G. Ressalto que ainda não sou OCP, pois tenho que aguardar uma resposta de aprovação da Oracle, sobre o último passo para tirar esta certificação que é a submissão de um formulário (através do site da VUE) informando que eu fiz um treinamento oficial Oracle.

1. Estou trabalhando há 4 anos com Administração de Bancos de Dados Oracle;
2. Há pouco mais de 1 ano tirei a Certificação OCA e comecei a dar aulas de Administração de Bancos de Dados Oracle;
3. Leio quase todos os dias a documentação online da Oracle em http://tahiti.oracle.com/ e muitos artigos sobre Oracle que pesquiso aleatóriamente no Google;
4. Estudei apostilas da Self Test Software (1Z0-042 e 1Z0-043) e o guia de estudos da Sybex OCP: Oracle 10g Administration II.

Neste artigo apresentarei o recurso de segurança do Oracle Database (existente a partir da versão 10G release 2) chamado Transparent Data Encryption (TDE). Este recurso permite proteger dados confidenciais de colunas e índices de tabelas, criptografando os dados e armazenando-os de modo seguro (criptografados) nos arquivos de dados do Sistema Operacional. Aos consultar estes dados (criptografados), eles são decriptografados antes de serem apresentados para o usuário final. A criptografia e decriptografia dos dados ocorre de forma transparente, sem necessidade de linhas de código adicionais na aplicação ou no banco de dados.

Com TDE, ao criptografar os dados de uma coluna de uma tabela, é gerada uma chave de criptografia para a tabela, que é armazenada no Dicionário de Dados (D.D.) para posterior decriptografia. Por sua vez, a chave de criptografia da tabela também é criptografada por outra chave, que é chamada chave mestra e que é armazenada fora do Banco de Dados, em um local seguro chamado Oracle Wallet.

Quando um usuário do Banco de Dados altera ou inclui dados (dados de entrada) em uma coluna criptografada, o Oracle Database recupera a chave mestra do Wallet, decriptografa a chave da tabela (recuperada no D.D.) e usa esta chave para criptografar os dados de entrada, antes de armazená-los no Banco de Dados. Nos dados, antes da criptografia, são adicionadas palavras extras chamadas SALT, que alteram os dados originais e que ajudam a dificultar “ataques hackers” de decriptografia. SALT é adicionado por padrão no TDE e pode ser utilizado somente ao criptografar tabelas. Índices não podem conter SALT.
Com TDE os dados podem ser criptografados utilizando um dos quatro seguintes algoritmos de criptografia:  3DES168, AES128, AES192 e AES256. AES192 é o algoritmo padrão.

É importante ressaltar que ao utilizar TDE nas tabelas, há um custo de performance para criptografar e decriptografar as colunas. Em testes do artigo Transparent Data Encryption (TDE) in Oracle 10g Database Release 2 (http://www.oracle-base.com/articles/10g/TransparentDataEncryption_10gR2.php), o tempo de execução das instruções SQL para atualizações e consultas em uma tabela (que possui o total de 2 colunas e somente 1 coluna criptografada) aumentou aproximadamente 40%.

Para utilizar TDE, no Oracle Database 10G Enterprise Edition (versão do Oracle mais utilizada), é necessário obter licensiamento da option Oracle Advanced Security (ver http://download.oracle.com/docs/cd/B19306_01/license.102/b14199/options.htm#CIHJHABF)

Para demonstrar a utilização de TDE, seguiremos os passos abaixo:
————————————————————————–
Para iniciar o passo-a-passo abaixo, é necessário conectar-se previamente no Banco de Dados desejado, através do SQL Plus, com um usuário com privilégios administrativos (usuário contendo a role DBA ou o privilégio de sistema SYSDBA), que não seja o SYS, pois se o passo 2 for executado pelo SYS ele irá falhar (o Oracle Database não permite utilizar TDE em objetos do schema SYS).
————————————————————————–

PASSO 1: Criando e referenciando o Wallet

a) Acrescente no arquivo sqlnet.ora da pasta network/admin do Oracle Home o seguinte bloco:

ENCRYPTION_WALLET_LOCATION =
(SOURCE=
(METHOD=file)
(METHOD_DATA=
(DIRECTORY=\ORACLE_BASE\admin\ORACLE_SID\wallet)))

O parâmetro DIRECTORY do bloco de código acima indica o caminho do arquivo Wallet que será criado no item ”b)” deste passo e está redigido de acordo com os padrões do sistema de arquivos do Windows.  Neste item, substitua os valores:
– ORACLE_BASE: pelo diretório correspondente ao Oracle Base em sua instalação de BD.
- ORACLE_SID: pelo nome da instância de BD.

Obs.: Se o diretório wallet não existir, crie-o dentro da pasta \ORACLE_BASE\admin\ORACLE_SID. A pasta “\ORACLE_BASE\admin\ORACLE_SID\wallet” é o caminho padrão de criação de Wallets.

b) Crie o Wallet e defina a chave mestra na instância de Banco de Dados (BD) em execução:
No prompt do SQL digite:
ALTER SYSTEM SET ENCRYPTION KEY AUTHENTICATED BY “Teste123“;

Obs.: Substitua Teste123 pela senha desejada. Este item define uma senha mestra e automaticamente cria o Wallet na pasta padrão referenciada no item “a)”.

PASSO 2: Criando e inserindo dados em uma tabela com uma coluna criptografada

Execute no SQL Plus os comandos abaixo:
CREATE TABLE   table_tde_test (
ID           NUMBER,
DATA1  VARCHAR2(40),
DATA2  VARCHAR2(40) ENCRYPT);

INSERT INTO table_tde_test (ID, DATA1, DATA2)
VALUES (1, ‘Dados NÃO criptogrados na coluna DATA1!’,'Dados criptogrados na coluna DATA2!’);

COMMIT;

ALTER SYSTEM FLUSH BUFFER_CACHE; –> força atualização dos dados no arquivo de dados da tabela

PASSO 3: Testando o TDE no nível da tabela

a) Execute um SELECT na tabela criada no passo anterior:
SELECT * FROM  table_tde_test;

Resultado:
Todos os dados da tabela serão retornados, inclusive os dados da coluna DATA2, que estão criptografados, pois o Wallet foi criado e está aberto desde o passo 1.

b) Feche o Wallet:
ALTER SYSTEM SET WALLET CLOSE;

Resultado:
Wallet fechado.

c) Execute novamente o SELECT do item “a)“:
SELECT * FROM  table_tde_test;

Resultado:
O SELECT irá disparar o erro ORA-28365, pois com o Wallet fechado não é possível recuperar a senha de criptografia da tabela e decriptografar os dados.

d) Execute um novo SELECT sem retornar os dados da coluna criptografada (DATA2):
SELECT ID, DATA1 FROM table_tde_test;

Resultado:
A instrução SELECT irá retornar com sucesso pois sem a incluir a coluna DATA2, não é necessário consultar o Wallet.

PASSO 4: Testando o TDE no nível do arquivo de dados

a) Localize o arquivo de dados em que a tabela foi criada. A query abaixo poderá ser executada para descobrir o caminho completo do arquivo de dados se o usuário conectado tiver privilégios administrativos ou tiver privilégios de SELECT nas visões DBA_TABLES e DBA_DATA_FILES:

SELECT            F.FILE_NAME
FROM              DBA_TABLES T
INNER JOIN   DBA_DATA_FILES F
ON         T.TABLESPACE_NAME = F.TABLESPACE_NAME
WHERE           T.TABLE_NAME = ‘TABLE_TDE_TEST’;

b) Entre na pasta localizada no item anterior:

– Se estiver usando SO Linux digite no prompt de comandos:
strings FILE.DBF | grep “criptogrados na coluna DATA”

Obs.: Substitua FILE.DBF pelo nome do arquivo de dados identificado no item anterior.

Resultado:

Você encontrará no arquivo DBF o valor “criptogrados na coluna DATA” apenas 1 vez, pois este é o valor da coluna DATA1. Se os dados da coluna DATA2 não estivessem criptografados, a pesquisa encontraria 2 vezes a frase pesquisada dentro do arquivo.

—————————————————————–

CONCLUSÃO

Apesar de degradar a performance da tabela, utilizar TDE para criptografar e decriptografar dados transparentemente é um ótimo recurso para proteger dados confidenciais, tais como salários ou números de cartões de crédito, pois eles só serão acessados por usuários ou aplicações que conheçam previamente a senha do Wallet.

Além de proteger os dados no nível lógico (conectado no banco de dados), TDE também protege os dados no nível físico, pois nos testes do Passo 4 podemos verificar que os dados aparecem em “texto limpo” no arquivo de dados do sistema operacional e podem ser lidos claramente por qualquer usuário que tenha acesso a ele.

—————————————————————–

Comandos e instruções SQL úteis:

• Para consultar tabelas que possuem colunas criptografadas com TDE:
  select * from DBA_ENCRYPTED_COLUMNS;
• Para somente abrir o Wallet:
  ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY “Password”; –> substituir Password pela senha master do Wallet.

Referências:

• http://www.oracleflash.com/26/Oracle-10g–Transparent-Data-Encryption-examples.html
• http://www.oracle-base.com/articles/10g/TransparentDataEncryption_10gR2.php
• http://download.oracle.com/docs/cd/E11882_01/license.112/e10594/options.htm#CIHFDJDG
• Material do curso oficial da Oracle: Oracle Database 10G Administration Workshop II.

Fonte: Blog Fabio Prado