Oracle Database 11G: 5 mudanças que ocorreram em relação ao 10G

Olá pessoal,
 

     No artigo de hoje vou comentar sobre algumas mudanças que ocorreram no Oracle Database 11G, em relação a versão anterior deste Banco de Dados (BD), o Oracle Database 10G. Este artigo será bastante útil para quem deseja atualizar o BD para 11G ou para quem já atualizou e ainda não identificou todas as mudanças que ocorreram. Aconselho a aqueles que ainda irão fazer a atualização, que leiam antes o artigo Atualização/Migração de Banco de Dados Oracle 10G para 11G e que configurem o parâmetro COMPATIBLE do BD para manter o 11G com as características de um 10G temporariamente, com o objetivo de "dar um tempo" para que as aplicações sejam adaptadas às mudanças desta última versão e se você tiver problemas graves com a migração, possibilitar que você faça um downgrade de versão, ou seja, voltar para o 10G. O valor do COMPATIBLE para possibilitar o downgrade deve ser o valor correspondente à sua versão anterior. Ex.: COMPATIBLE = 10.2.0. 

     As principais mudanças que foram implementadas no 11G e que impactaram nos sistemas dos BDs que eu administro, são relacionadas à segurança do BD. O 11G está mais seguro, nele foram eliminadas várias brechas de segurança que existiam no 10G. Essas novas implementações de segurança, porém, podem gerar erros nas aplicações que já eram executadas no 10G sem problema algum. Neste artigo você verá alguns erros que podem acontecer e algumas formas de como evitá-los.

    

     Dentre as principais mudanças que ocorreram no 11G, irei destacar as seguintes:

        1- Senhas case sensitive: 

      No Oracle 10G as senhas de usuários não são sensíveis aos caracteres maiúsculos e minúsculos. No 11G, por padrão, as senhas são case sensitive. Para desabilitar esse novo comportamento, se for necessário, altere o parâmetro  sec_case_sensitive_logon do BD, como no exemplo abaixo:

            ALTER SYSTEM SET sec_case_sensitive_logon=FALSE SCOPE=BOTH;
        
          Na empresa em que trabalho precisei implementar esta alteração porque temos algumas aplicações que se autenticam com as contas de usuários Oracle. São aproximadamente 3 mil contas de usuários Oracle que são utilizadas diariamente pelos usuários para se autenticar em algumas aplicações. Para evitar suporte demasiado aos usuários com as senhas após a atualização dos BDs, achamos melhor manter as senhas case insensitive (mesmo comportamento da versão 10G).

        2- Roles default com senhas:

      No Oracle 10G se um usuário possui uma role default com senha, ele pode utilizar todos os privilégios daquela role sem fornecer a senha dela. Sempre que a role for default, o usuário nem precisa saber qual é a senha dela. No 11G isso mudou. Agora mesmo que a role seja default, o usuário terá que fornecer a senha para que ele possa utilizar os seus privilégios. Não adianta nem tentar criar uma trigger de logon para fornecer automaticamente a senha de uma role quando determinado usuário se logar, pois o BD não permite executar código para fornecer senhas de roles dentro de triggers de logon. Se você atualizou para 11G e seu BD não está configurado para o modo de compatibilidade com o 10G, você terá que resolver este problema através de 1 das soluções abaixo:

            a) A aplicação ou usuário que deseja utilizar os privilégios da role default com senha terá que executar o seguinte comando: SET ROLE  nome_role IDENTIFIED BY senha

            b) Você terá que alterar a role para não exigir senha (remover senha da role). Em ambientes de homologação eu não configurei o parâmetro COMPATIBLE, neste caso, tive que implementar esta solução nas roles com senha que existiam nestes BDs.

   

        3- Colunas ambíguas
      Ao atualizar para o Oracle 11G algumas funcionalidades das aplicações podem começar a disparar o erro "ORA-00918 column ambiguously defined". Por que isso não ocorria antes? No 11G o otimizador de queries está mais exigente. Se 2 ou mais tabelas possuem colunas com o mesmo nome, ao especificar estas colunas em uma instrução SQL você deverá obrigatóriamente prefixar o álias ou nome da tabela. Sem prefixá-las, acontecerá o erro ORA-00918. Em algumas versões/patchset do Oracle, ele aceitava nomes de colunas ambíguas sem prefixar álias ou nome da tabela. Para evitar este erro, sempre especifique álias ou nome da tabela como prefixo para nomes de colunas nas instruções SQL. Para mais informações, leia: http://dbaspot.com/oracle-faq/475942-ora-00918-column-ambiguously-defined.html.
     
        4- Coluna PASSWORD da visão DBA_USERS
      No Oracle 10G, ao consultar a visão DBA_USERS, a coluna PASSWORD exibia a senha criptografada dos usuários do BD. Com isso, usuários com privilégios de DBA, podiam hackear as senhas de usuários de BD (para mais informações leia o artigo http://www.rodrigoalmeida.net/blog/tecnica-de-hack-em-senhas-armazenadas-pelo-oracle). No Oracle 11G a coluna PASSWORD da visão DBA_USERS não exibe mais a senha criptografada dos usuários. Para fazer isso, agora é necessário consultar a visão USER$.
           Ex.:  SELECT NAME, PASSWORD FROM USER$;
     

        5- Compilação de objetos remotos

      No Oracle 11G, objetos remotos são verificados em tempo de compilação. Isso não ocorria no 10G. Antes, se você referenciava um objeto remoto inexistente em uma Stored Procedure (SP), a SP era compilada sem nenhum problema, pois o Oracle só iria validar a existência daquele objeto em tempo de execução. No 11G o Oracle já faz essa validação em tempo de compilação. Achei essa característica muito boa. Isso evita a compilação de objetos que possam retornar erros futuros. Quando atualizei alguns BDs para 11G, o número de objetos inválidos em alguns desses BDs aumentou consideravelmente, devido a objetos remotos que eram referenciados e que não existiam mais. Estes objetos eram lixo que estavam no BD e que só consegui identificá-los na versão 11G.
   
      

  

Bom pessoal, por hoje é só!
   

  

[]s