Atualização/Migração de Banco de Dados Oracle 10G para 11G

Olá pessoal,

     No artigo de hoje irei comentar sobre algumas mudanças que ocorreram no Oracle Database 11G e darei algumas dicas sobre o processo de atualização/migração de versão de Banco de Dados (BD) Oracle 10G para 11G. O objetivo deste artigo não é servir como um roteiro de atualização/migração, mas sim orientar onde pesquisar roteiros completos e dar dicas sobre como resolver ou evitar problemas decorrentes deste processo, de acordo com a experiência que eu tive.

     Existem diversos métodos para fazer a atualização de um BD Oracle 10G p/ 11G. Entre eles, podemos destacar como principais os 3 abaixo:    

         1- Database Upgrade Assistant (DBUA): Método recomendado pela Oracle que contém uma interface gráfica amigável para realizar todo o processo de atualização;

         2- Manual Upgrade: Método de atualização que consiste em executar uma série de scripts e passos manualmente. Exige mais atenção e conhecimentos que o método anterior.

         3- Export and Import: Método de atualização mais seguro, em comparação com as opções anteriores, pois com ele você cria um novo BD e leva através de um dump os dados e estrutura do BD anterior. Se algo falhar no novo BD, é possível voltar facilmente a utilizar o BD anterior. Para grandes BDs, este pode ser um método de migração muito demorado, porém ele possui também outra vantagem. Ele reorganiza os objetos do BD em seus respectivos tablespaces, permitindo reduzir espaço de armazenamento e otimizar acesso aos objetos de dados (tabelas, visões materializadas etc.).

  

     Nas atualizações/migrações que eu fiz, utilizei apenas os métodos 2 e 3. Não consegui utilizar o método 1 porque sempre dava erro ao tentar atualizar um dos BDs que eu administro. Para não perder muito tempo tentando resolver este problema, optei por utilizar o método 2 quando tive que atualizar BDs que iriam permanecer na mesma máquina e utilizei o método 3 para atualizar/migrar BDs que além de sofrer alteração de versão, também passariam por troca de máquinas servidoras.

  
     Seguem abaixo algumas dicas, baseadas na experiência que eu tive, que poderão ser bastante úteis para quem precisará efetuar atualização/migração de Oracle 10G p/ 11G, em SO Linux:

1- Escolha um método de atualização:
     Cada método de atualização tem suas características e benefícios. Analise com calma cada um e escolha aquele que for mais indicado e apropriado para o seu ambiente e necessidade. Para conhecer melhor os métodos de atualização, leia o documento 11gr2_upgrade_methods.pdf (Meu Sky Drive, pasta Oracle -> Migração).

2- Utilize um bom guia ou roteiro de atualização:
     Após escolher o método de atualização, utilize um bom guia ou roteiro de atualização/migração. Recomendo o documento Oracle Database Upgrade Guide 11g Release 2 (código E17222-08 ou superior), que pode ser baixado no site da Oracle ou no Meu Sky Drive, pasta Oracle -> Migracao, arquivo ODB_Upgrade_Guide_11GR2_e17222_08.pdf. Este guia foi escrito pela própria Oracle e é o mais completo que eu encontrei. Como todo documento da Oracle, ele é não muito fácil de entender, portanto, leia com calma e atenção! Se você quer ler algo mais resumido, sugiro que leia o artigo "Upgrade para o Oracle Database para 11g " da Revista SQL Magazine 94.
  
3- Cuidados adicionais com atualização através de Export/Import:
     Se você irá utilizar o método de atualização "Export/Import", aconselho ter os seguintes cuidados:

          a) Utilize o DBCA para criar a nova instância de BD, utilizando o modelo que permite criar um novo BD a partir de um BD existente. Isso permite que você crie a nova instância com as mesmas configurações da instância antiga;

          b) Aproveite este momento da atualização para efetuar mudanças necessárias na nova instância. Eu por exemplo, aproveitei para alterar todos os tablespaces do BD para Bigfile Tablespaces (fiz isso através do DBCA). Essa alteração facilitará, futuramente, que eu mude o modo de armazenamento dos datafiles do BD, de FileSystem para ASM;

          c) Instale novamente os objetos do BD que não são instalados automaticamente com o DBCA. Ex.: Package UTL_MAIL.  Estes objetos são instalados normalmente a partir de scripts localizados na pasta ORACLE_HOME/rdbms/admin;

          d) Faça o import do dump (via Datapump), acrescentando o parâmetro VERSION com um valor indicando a versão do BD origem. Se você estiver fazendo migração de 10GR2 para 11GR2, o parâmetro VERSION deve conter o valor 10.2. Ex.: impdp / DUMPFILE=file.dmp LOGFILE=file.log FULL=Y VERSION=10.2

          e) Identifique todos os privilégios de usuários existentes para executar/acessar objetos de sistema (schemas SYS, SYSTEM, WKSYS) no BD antigo e reatribua estes privilégios no novo BD. Isso é necessário porque o Import no BD novo não contempla objetos dos schemas de sistema, portanto privilégios anteriormente concedidos a estes objetos, são perdidos e isso poderá resultar em muitos objetos inválidos no novo BD. Objetos criados no schema SYS ou SYSTEM também não migrados.

          
4- Cuidado com as senhas case sensitive:
     No 11G as senhas são case sensitive, no Oracle 10G não. Na empresa em que trabalho temos muitas aplicações em que cada usuário da aplicação se autentica utilizando uma conta de usuário Oracle (aproximadamente 3 mil usuários). Para evitar um possível bloqueio dessas contas (conforme política de segurança implementada) e uma demanda muito grande de suporte, optamos inicialmente por deixar as senhas de usuário Oracle como case insensitive. Para implementar esta alteração, tive que alterar o valor do parâmetro sec_case_sensitive_logon para FALSE, como no exemplo abaixo:
           ALTER SYSTEM SET sec_case_sensitive_logon=FALSE SCOPE=BOTH;

5- Conheça o novo Automatic Diagnostic Repository:
     No Oracle 11G há um novo recurso chamado Automatic Diagnostic Repository (ADR), que foi criado para facilitar o acesso às informações de alerta e de diagnóstico. Essas informações são armazenadas, por padrão, na pasta $ORACLE_BASE/diag, mas sua localização pode ser alterada configurando-se o parâmetro DIAGNOSTIC_DEST. Os parâmetros BACKGROUND_DUMP_DEST e USER_DUMP_DEST não são mais utilizados, portanto, os arquivos que ficavam armazenados nas pastas indicadas nos valores destes parâmetros, localizam-se agora em subdiretórios da estrutura de pastas do ADR ($ORACLE_BASE/diag).
     O arquivo alert.log (formato texto) do 10G foi substituído no 11G pelo arquivo log.xml (formato XML). Para ler o contéudo deste arquivo, faça uma consulta à visão X$DBGALERTEXT, como no exemplo abaixo:
          SELECT ORIGINATING_TIMESTAMP, message_text from X$DBGALERTEXT ORDER BY 1;

Obs.: Para mais informações sobre este item, leia o artigo:

           http://www.dba-oracle.com/oracle11g/oracle_11g_diagnostic_dest_tips.htm

   
6- Copie os arquivos Oracle Net:

     Para manter as configurações do listener e de conexões de rede com o BD novo, copie para o ORACLE_HOME da nova instância os arquivos Oracle Net: listener.ora, tnsnames.ora, sqlnet.ora e outros.

7- Recrie o arquivo de senhas (password file):
     Para manter a configuração de usuários que acessam o BD com privilégios SYSDBA, recrie o arquivo de senhas utilizando o utilitário orapwd, informando o mesmo número de entradas que existia no BD anterior. Siga o exemplo abaixo, substituindo "INSTANCE_NAME", "XXXX" e "N" por "nome da instância", "senha do arquivo" e "qtde total de usuários" que terão o privilégio SYSDBA:
             orapwd file=orapwINSTANCE_NAME password=XXXX entries=N

8- Atualize as estatísticas de objetos do BD:    
     Para proporcionar melhor desempenho após a atualização/migração, é recomendado atualizar as estatísticas de objetos do BD, executando o bloco PL/SQL abaixo:
BEGIN
     DBMS_STATS.GATHER_DATABASE_STATS();
END;

9- Atualize scripts e rotinas de manutenção:
     Como no 11GR2 é recomendado e quase obrigatório fazer uma atualização ou migração de versão OUT-OF-PLACE (em um novo ORACLE_HOME), temos que ter o cuidado de atualizar todos os scripts que são executados através de processos externos, crontab, external scheduler jobs etc, para que eles referenciem o novo caminho do ORACLE_HOME no 11G. Isso é inevitável e mais trabalhoso ainda quando o BD for migrado para uma máquina diferente. Para exemplificar, tive que alterar o local de vários scripts de geração de relatórios para a nova pasta ORACLE_HOME. Também tive que alterar um serviço do SO, que criei de acordo com o roteiro do link: http://www.oracle-base.com/articles/linux/AutomatingDatabaseStartupAndShutdownOnLinux.php, para iniciar e parar os BDs após um shutdown, start ou restart da máquina servidora. O serviço executava scripts na pasta ORACLE_HOME (Ex.: /u01/app/oracle/10.2.0) antiga e tive que alterá-lo para apontar para o novo ORACLE HOME (Ex.: /u01/app/oracle/11.2.0).

10- Atualize o catálogo do RMAN:
     Se os seus backups são gerenciados por um repositório do RMAN, é necessário atualizar o catálogo do RMAN para contemplar a nova instância de BD.

11- Configure o arquivo /etc/oratab:
     Se você migrou o BD para uma nova máquina, configure o arquivo /etc/oratab para especificar os BDs que devem ser reiniciados após um shutdown da máquina servidora. Por padrão, ao instalar um BD Oracle, este arquivo é configurado para não startar automaticamente o BD.

12- Crie ACLs para packages que utilizam serviços de rede:

     No 11G, por questões de segurança, usuários que utilizam packages de serviços de rede, tais como UTL_STMP e UTL_MAIL, precisam de privilégios adicionais, chamados ACLs. O guia do item 2 aborda este assunto em mais detalhes.

13- Atualize o agente do Enterprise Manager Grid Control:
     Se o BD é gerenciado pelo Enterprise Manager Grid Control e você utilizou o método com DBUA ou Manual Upgrade, atualize o registro do agente (cliente do Enterprise Manager) para contemplar o novo Oracle Home. Se você utilizou o método com Export/Import, migrando o BD para uma nova máquina, você terá que instalar o agent na nova máquina e registrar o BD.

14- Verifique os objetos DIRECTORY:
   Recrie objetos DIRECTORY  que apontavam para diretórios da instância antiga. Antes de recriá-los, é necessário recuperar privilégios de usuários sobre eles para aplicar novamente estes privilégios, após a recriação.
Observações: Este artigo não contempla passos ou cuidados requeridos quando o BD utiliza Oracle RAC ou Dataguard.

15- Cuidado com objetos que foram criados por usuários com privilégios de DBA:
    Tive problemas com objetos Scheduler Jobs criados nos schemas de alguns usuários, que não foram migrados via export/import. Descobri que estes objetos não foram migrados porque o usuário dono deles não tinha privilégios de criar aqueles tipos de objetos. Os objetos tinham sido criados por um usuário DBA.

   
     Para aqueles que buscam mais informações, sugiro também a leitura dos seguintes notes, no site Oracle Support:

        - Things to Consider Before Upgrade to 11.2.0.2 in Relation to Database Performance [Document 1320966.1]

         - Query Performance Degradation - Upgrade Related - Recommended Actions [Document 745216.1]

         - TROUBLESHOOTING: Server Upgrade Results in Slow Query Performance [Document 160089.1]

Por hoje é só! Qualquer dúvida, é só deixar um comentário!

[]s