Pular para o conteúdo principal

Upgrade Oracle APEX 18.1

Nesse post vou fazer um breve resumo de como atualizar para nova versão do Oracle APEX 18.1 que saiu 24/05/18.

No meu ambiente atual estou usando Oracle 11.2.0.4 com Linux e o APEX na versão 5.1 com três aplicações. E vou migrar o APEX para 18.1 com PL/SQL Gateway.

Vamos lá para o processo...


Em resumo basta instalar o novo software na sua base de dados que o processo de instalação vai atualizar as aplicações existentes nas versões anteriores. Da versão 1 até a 5 do APEX são suportadas para esta atualização.

1 - Primeiro vamos baixar o software aqui

2 - Em seguida vamos descompactar o arquivo e logar na base de dados que vamos atualizar com um usuário SYSDBA.

3 - Para instalação do APEX vamos executar o script @apexins.sql
Mude seu diretório padrão para a pasta descompacta apex.

 cd /u01/apex/
sqlplus / as sysdba
@apexins.sql APEX_TS APEX_FILES TEMP /i/


APEX_TS - é o nome da tablespace que ficarão os usuário de aplicação APEX
APEX_FILES - é o nome da tablespace que ficarão os arquivos de usuário
TEMP - tablespace temporaria
/i/ - Diretório virtual para as imagens APEX. Para futuros upgrades é recomendado definir como /i/

4- Agora vamos criar ou configurar a conta de Instância de Administrador. Muda seu diretório para a pasta descompactada apex. E então execute:


cd /u01/apex/
sqlplus / as sysdba
@apxchpwd.sql


Siga as instruções do script e crie seu usuário e senha.

5- Chegou a parte da configuração do Embedded PL/SQL Gateway. Como estamos saindo de uma versão antiga para a 18.1, vamos atualizar o diretório de imagens.
 Mude seu diretório padrão para a pasta descompacta apex. Conecte no banco e execute o script passando o diretório base da instalação. No meu caso descompactei em /u01/apex, então irei passar /u01

cd /u01/apex
sqlplus / as sysdba
@apex_epg_config /u01


6 - Desbloqueie o usuário ANONYMOUS:
 ALTER USER ANONYMOUS ACCOUNT UNLOCK;

7- Verifique a porta HTTP no Oracle XML DB
SELECT DBMS_XDB.GETHTTPPORT FROM DUAL;

Habilite, se não estiver , o protocolo Oracle XML DB. Aqui você pode passar a porta que desejar.
EXEC DBMS_XDB.SETHTTPPORT(8080);


8 - E por fim, uma vez que a atualização tenha sido realizada com sucesso, podemos apagar o esquema APEX antigo. Mas como boa prática, é bom esperar um pouco até tudo tenha sido testado.

 DROP USER APEX_050100 CASCADE;



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