Pular para o conteúdo principal

Remover ou atualizar o APEX para atualização do banco de dados Oracle de 12.1 para versão 12.2?

          Hoje fui realizar testes de migração de algumas bases de homologação que usam CDB da versão 12.1 para 12.2. E me deparei com um situação que gostaria de compartilhar.
         Se você não tiver personalizado sua instalação através de scripts, que foi meu caso, seu CDB$ROOT terá o APEX instalado por padrão.
           Bom, o primeiro passo pra migração é executar o utilitário disponibilizado pela própria Oracle preupgrade.jar. Você pode baixa-lo no MOS Note:884522.1.

            A execução é simples:

java -jar /u01/app/oracle/product/12.2.0.1/rdbms/admin/preupgrade.jar TEXT

          Depois que o logs forem gerados, serão criados alguns arquivos com recomendações para o upgrade e se você tiver o APEX instalado, uma delas será:

  ======================
  INFORMATION ONLY
  ======================
   + Consider upgrading APEX manually, before the database upgrade.

     The database contains APEX version 4.2.5.00.08 and will need to be
     upgraded to at least version 5.0.4.00.12.

     To reduce database upgrade time, you can upgrade APEX manually before
     the database upgrade.  Refer to My Oracle Support Note 1088970.1 for
     information on APEX installation upgrades.



             É justamento sobre essa recomendação que quero falar. Ela é somente uma informação não é um erro e nem vai te impedir de atualizar. Mas se você remover ou atualizar o APEX antes de migrar seu banco de dados Oracle, terá o seu tempo de upgrade reduzido. Eu optei por excluir o APEX do CDB$ROOT, pois fazendo isso você pode instalar o APEX somente nos PDBs que realmente precisa e também pode ter várias versões diferentes do APEX.

            Pode usar a consulta pra verificar a versão instalada.

select reg.COMP_NAME, reg.VERSION, con.NAME, con.CON_ID
from CDB_REGISTRY reg, V$CONTAINERS con
where reg.CON_ID=con.CON_ID and reg.COMP_ID='APEX' order by CON_ID;



Removendo o APEX DO CDB$ROOT
            Lembrando que fazendo isso estamos removendo também de todos os PDBS. Se quiser aprofundar mais pode conferir a documentação

Acesse o diretório:
 cd $ORACLE_HOME/apex


Conecte no CDB$ROOT e execute o script para remover o APEX

 sqlplus / as sysdba
 SQL> @apxremov_con.sql

           Verifique se o APEX foi realmente removido e se existe algum objeto inválido.

select comp_id, STATUS from dba_registry where comp_id='APEX';
select object_name, status from dba_objects where status='INVALID';

          Caso necessário execute o script abaixo para recompilar os objetos inválidos.
SQL> @?/rdbms/admin/utlrp.sql


Depois de desinstalado... agora é seguir com o upgrade. Caso queira realizar a instalação do APEX nos PDBs faça:

cd $ORACLE_HOME/apex
sqlplus / as sysdba
SQL> alter session set container=SEUPDB;
SQL> @apexins.sql SYSAUX SYSAUX TEMP /i/


Verifique a instalação executando
select comp_id, status , con_id from cdb_registry where comp_id='APEX';

Comentários

Postagens mais visitadas deste blog

Configurando a política de retenção de backups no RMAN

                       Configurando a politica de reten çã o de backups no RMAN        O objetivo deste post é explicar como podemos configurar a reten çã o de backups na poderosa ferramenta de backup do bando de dados Oracle RMAN. Podemos configurar nossa pol í tica tendo por base dois tipos: janela de recupera çã o (recovery window) ou redundãncia (redundancy). Abaixo iremos abordar os dois tipos.       Para identificar qual dos dois tipos o RMAN está usando, use: RMAN> show retention policy; Política baseada em redundância CONFIGURE RETENTION POLICY TO REDUNDANCY 1; Política baseada em janela de recuperação CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS; ·        Política baseada em redund â ncia ( REDUNDANCY )       De uma maneira bem simples e objetiva, o par â metro REDUNDANCY especifica quantos backups full ou incremental level 0 de cada datafile o RMAN vai manter, os demais são considerados obsoletos. Veja o exemplo abaixo

Permissões necessárias para criar triggers no Oracle

Há pouco tempo passei por um problema durante a criação de uma trigger de LOGON na versão 12c do banco de dados Oracle. Estava com alguns problemas em uma aplicação que tinha uma trigger de Logon. A trigger em si era bem simples, vou por o código mais abaixo, o problema é que ela estava criada dentro do usuário SYSTEM. Provavelmente foi a maneira mais fácil e preguiçosa de criar o objeto, uma vez que o SYSTEM já possui todas as permissões necessárias para criação. Porém isso não uma boa prática. Então resolvi tirar do SYSTEM e jogar para o usuário dono dos objetos da aplicação. Quando fui tentar criar o objeto no SCHEMA dono dos objetos da aplicação, recebi um erro com falta de permissões: ORA-01031: insufficient privileges . O erro ocorreu porque estava esquecendo de conceder a role ADMINISTER DATABASE TRIGGER para o usuário. Em resumo, as permissões necessárias para criação de uma trigger: CREATE TRIGGER - para criar uma trigger no seu próprio esquema (SCHEMA) CREATE AN

ORA-01623 ORA-00312 - Removendo redo logs

Após realizar um restore de um ambiente de Oracle RAC para um single instance usando snapshot de storage, tentei recriar os redo logs recebi o seguinte erro durante a exclusão de um grupo de discos. SQL> alter database drop logfile group 2; ORA-01623: o log 2 é o log atual para a instância UOW (thread 1) - não é possível eliminar ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.1638.1051804433' ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.981.1051804433' O erro quer dizer que o grupo de redo pertence a outra thread. Quer dizer que ele pertence a outra instância do ambiente RAC. Como no meu caso não precisarei mais dela, basta usar o comando: SAL> alter database disable thread 2; Database altered.   Usei o SQL abaixo para gerar os comandos para excluir os redo logs SQL> select distinct 'alter database drop logfile group '||(group#)||';' from v$log where thread#=2; 'ALTERDATABASEDROPLOGFILEGROUP'||(G