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) 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 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 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 Na linha E, para terminar, a linha 41 apresenta a conexão bem sucedida com a sessão devidamente criada. Por último, as linhas 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 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
