Esse artigo faz parte da revista SQL Magazine edição 59. Clique aqui para ler todos os artigos desta edição

text" align=left>O que há de novo na versão mais recente do BD Oracle

 

De que se trata o artigo?

Com a liberação da versão 11g do banco de dados Oracle, novas características estão presentes e são justamente essas novas características que serão abordadas neste artigo, de maneira prática e intuitiva.

 

Para que serve?

Fornecer conceitos de utilização das novas características da versão bem como fornecer subsídios práticos para a perfeita implementação das funcionalidades em ambientes de desenvolvimento, teste, pré-produção e produção.

 

Em que situação o tema é útil?

Além de manter o suporte técnico da Oracle, a migração do banco de dados para a versão mais recente do produto é importante para que se possa utilizar novas funcionalidades que em muito agregam ao negócio. Neste artigo destacamos:

 

- ganho em segurança ao utilizar senha “Case Sensitive”;

- ganho em utilização de recursos de servidor com o gerenciamento de   memória (Memory Management);

- maior facilidade na manutenção do modelo de dados com a otimização de adição de nova coluna em tabela, o novo parâmetro de espera em DDL e novas colunas com valores padrão e não nulos;

- ganho em performance de consultas com a utilização de Colunas Virtuais, Índices Invisíveis e Tabelas Somente Leitura (Read Only Tables);

- ganho no desenvolvimento de aplicações através da utilização de seqüências (sequences) em expressões PL/SQL, melhorias em Expressões Regulares e novas funções.

 

A Oracle finalmente liberou a nova versão de seu banco de dados, o Oracle 11g na versão 1, mais especificamente a release 11.1.0.6.0 nas modalidades Standard Edition, Standard Edition One e Enterprise Edition para as plataformas Microsoft Windows 32-bit e x64, Linux x86 e x86-64, Solaris SPARD 64-bit, AIX, HP-UX Itanium e PA-RISK 64-bit.

Esta versão traz centenas de novas funcionalidades, mas ainda não temos a total certeza sobre quais destas funcionalidades realmente trarão benefícios significativos para os DBA e principalmente para os negócios da empresa e, definitivamente, a única maneira de descobrir é testando. E é justamente esta a intenção deste artigo (e dos próximos que virão a seguir), cobrir algumas destas novas funcionalidades da versão. Vamos ao que interessa!

 

Senha Case Sensitive

Uma das primeiras coisas que logo percebemos assim que iniciamos os testes no Oracle 11g é que finalmente a senha de conexão ao bd é case sensitive ou seja, diferencia letras maiúsculas e minúsculas, o que significa que ao conectar-se ao bd a senha deverá ser digitada exatamente da maneira que foi definida, considerando-se o que é maiúsculo e minúsculo.

Até então, esta era uma grande falha em termos de segurança nas versões anteriores e, após algumas décadas, a Oracle finalmente percebeu esta importância.

Veja alguns testes na Listagem 1.

 

Listagem 1. Testes da característica de senha case sensitive.

 

1.                 SQL> -- Teste 1

2.                 SQL> conn / as sysdba

3.                 Connected.

4.                 SQL> create user sqlmag1 identified by SqlMag1;

 

5.                 User created.

 

6.                 SQL> grant dba to sqlmag1;

 

7.                 Grant succeeded.

 

8.                 SQL> conn sqlmag1/sqlmag1

9.                 ERROR:

10.             ORA-01017: invalid username/password; logon denied

11.             Warning: You are no longer connected to ORACLE.

 

12.             SQL> conn sqlmag1/SQLMAG1

13.             ERROR:

14.             ORA-01017: invalid username/password; logon denied

 

15.             SQL> conn sqlmag1/SqlMag1

16.             Connected.

 

17.             SQL> conn SQLMAG1/SqlMag1

18.             Connected.

 

19.             SQL> -- Teste 2

20.             SQL> create user "SqlMag2" identified by sqlMAG1;

 

21.             User created.

 

22.             SQL> conn SQLMAG2/sqlMAG1

23.             ERROR:

24.             ORA-01017: invalid username/password; logon denied

25.             Warning: You are no longer connected to ORACLE.

 

26.             SQL> conn sqlmag2/sqlMAG1

27.             ERROR:

28.             ORA-01017: invalid username/password; logon denied

 

29.             SQL> conn "SqlMag2"/sqlMAG1

30.             ERROR:

31.             ORA-01045: user SqlMag2 lacks CREATE SESSION privilege; logon denied

 

32.             SQL> conn / as sysdba

33.             Connected.

34.             SQL> grant dba to SqlMag2;

35.             grant dba to sqlmag2

36.             *

37.             ERROR at line 1:

38.             ORA-01917: user or role 'SQLMAG2' does not exist

 

39.             SQL>  grant dba to "SqlMag2";

 

40.             Grant succeeded.

 

41.             SQL> conn "SqlMag2"/sqlMAG1

42.             Connected.

 

43.             SQL>  select username from dba_users where lower (username) like '%sql%';

 

44.             USERNAME

45.             ------------------------------

46.             SqlMag2

47.             SQLMAG1

 

O teste 1 (linhas 1 a 18) da Listagem 1 mostra a criação do usuário com a definição da senha com caracteres mesclados entre maiúsculos e minúsculos (linha 4) e foi concedido o privilégio de DBA para este usuário (linha 6). Perceba a mensagem de erro ao tentar conectar-se com a senha em caracteres diferentes dos definidos (linhas 8 e 12). Perceba também que a conexão foi bem sucedida independente da maneira com que o nome do usuário foi digitado (maiúsculo ou minúsculo) (linhas 15 e 17).

Um detalhe é que apenas a senha é case sensitive no Oracle 11g, no caso do nome de usuário, ainda temos que utilizar o velho artifício de criar o usuário definindo o seu nome entre aspas (“ “) como mostrado no teste 2 (linhas 19 a 42) da Listagem 1.

A linha 20 mostra a criação do usuário definindo seu nome (através da utilização das aspas) e senha com caracteres maiúsculos e minúsculos. Veja nas linhas 22 e 26 as tentativas sem sucesso de conexão utilizando-se caracteres diferentes do definido na criação do usuário (apenas no nome do usuário, a senha está correta).

Finalmente, na linha 29 a conexão bem sucedida utilizando-se o nome na mesma forma que a definida na criação (perceba o detalhe da utilização das aspas), porém o erro de falta de privilégio de criação de sessão (porém o problema de usuário e senha não existe mais).

Na linha 34 a tentativa de concessão de privilégio de DBA para o usuário, porém com a mensagem de erro alertando que o usuário não existe. Mas não o criamos anteriormente? Veja na linha 39 que a concessão agora foi bem sucedida, pois utilizamos as aspas no nome do usuário.

E, para terminar, a linha 41 apresenta a conexão bem sucedida com a sessão devidamente criada. Por último, as linhas 43 a 47 apresentam os usuários criados no bd.

Nos testes fica bem claro que apenas a senha é naturalmente case sensitive, para utilizar o mesmo conceito para o nome do usuário, teremos que criá-lo utilizando as aspas (“ ”), porém SEMPRE que fizermos referência a este usuário, as aspas deverão estar presentes. De qualquer maneira, acredito que esta mudança (a senha pelo menos) já é um bom começo.

 

Gerenciamento de Memória (Memory management)

No Oracle 10g, o parâmetro SGA_TARGET era responsável por alterar dinamicamente os componentes da SGA (ver Nota DevMan 1) baseado na utilização do bd.

Agora a Oracle traz o novo parâmetro MEMORY_TARGET e MEMORY_MAX_TARGET.

O parâmetro MEMORY_TARGET não irá apenas ajustar dinamicamente a SGA, mas também a PGA (ver Nota DevMan 1) substituindo a necessidade de determinar o parâmetro PGA_AGGREGATE_TARGET. O detalhe é que este ajuste dinâmico será feito até o limite definido no parâmetro MEMORY_MAX_TARGET.

 

SGA – System Global Area e PGA – Program Global Area

A SGA – System Global Area, ou Área Global do Sistema, é um grupo de estruturas de memória compartilhada que contem dados e informações de controle para uma instância de banco de dados Oracle. Caso vários usuários estejam conectados simultaneamente (que é uma situação comum) na mesma instância, então os dados e informações contidas na SGA são compartilhados entre os usuários, por esse motivo, a SGA é também conhecida como Shared Glogal Area, ou Área Global Compartilhada.

Uma instância é formada pela SGA e os processos Oracle e quando a instância é iniciada (startup), o Oracle automaticamente aloca memória para a SGA e no momento em que a instância é finalizada (shutdown), a memória alocada é liberada novamente para o Sistema Operacional. Outro detalhe é que cada instância possui a sua própria SGA.

A SGA é utilizada tanto para leitura quanto escrita de dados, o que significa dizer que todos os usuários conectados à instância poderão ler informações da SGA e vários processos irão escrever informações na SGA durante a execução do Oracle.

Já a PGA – Program Global Area, ou Área Global de Programa, é um buffer de memória que contém dados e informações de controle do processo servidor (server process). No caso de um banco de dados Oracle configurado para conexões em modo dedicado, cada nova sessão terá seu próprio processo servidor e as informações contidas na PGA serão acessadas apenas por esta sessão.

 

Não somos muito fanáticos por gerenciamento automático principalmente porque as aplicações, em geral, sempre trazem um série de problemas como falta de bind variable (ver Nota DevMan 2), consultas mal escritas, etc. e, sinceramente, não acreditamos que o gerenciamento automático seja capaz de lidar com isso. Por exemplo, se a aplicação não utiliza “bind variable” em alguma consulta amplamente utilizada, o gerenciamento automático irá aumentar a SHARED_POOL e diminuir outras áreas. Outro exemplo seria uma consulta fazendo algo errado e retornando um produto cartesiano que não deveria existir, como o gerenciamento automático irá lidar com isso?

 

Bind Variables

Uma bind variable nada mais é que uma variável de macro-substituição em consultas SQL onde a mesma será substituída por um valor real exatamente antes da execução da consulta.

A grande vantagem do uso de bind variables é que a consulta não sofrerá um novo processo de compilação em memória, a mesma já estará em memória caso já tenha sido utilizada anteriormente, mesmo que com outro valor. Esta técnica provê ganhos expressivos no tocante a performance.

Um exemplo de uso de bind variable é:

SQL> SELECT empno, name, last_name

  2    FROM employees

  3    WHERE empno = :EMPNO_BIND_VAR;

 

Muitas vezes, problemas da aplicação são relativamente simples de solucionar e você ainda pode utilizar o ...

Quer ler esse conteúdo completo? Tenha acesso completo