Neste artigo, vamos simular o upgrade da Application HR_APP que criamos nos últimos artigos, de modo que estas alterações sejam refletidas nos Application PDBs também. Para isso, vamos conectar diretamente no Application Root e validar a versão atual:
[oracle@quiasma ~]$ sqlplus sys/oracle@HR_AC as sysdba
SQL*Plus: Release 18.0.0.0.0 - Production on Mon Jul 12 18:20:06 2021
Version 18.13.0.0.0
Copyright (c) 1982, 2018, Oracle. All rights reserved.
Connected to:
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.13.0.0.0
SQL> column app_name format a15
SQL> column app_version format a10
SQL> column app_status format a15
SQL> SELECT APP_NAME, APP_VERSION, APP_STATUS FROM DBA_APPLICATIONS WHERE APP_IMPLICIT='N';
APP_NAME APP_VERSIO APP_STATUS
--------------- ---------- ---------------
HR_APP 1.0 NORMAL
Antes de iniciar efetivamente as alterações na application, devemos executar o comando abaixo usando o nome da aplicação, sua versão atual e a versão futura:
SQL> ALTER PLUGGABLE DATABASE APPLICATION HR_APP BEGIN UPGRADE '1.0' TO '2.0';
Pluggable database altered.
Para nosso caso, vamos criar uma tabela nova na aplicação, conforme script abaixo:
SQL> CREATE TABLE HR.JOB_HISTORY
(
EMPLOYEE_ID NUMBER(6) CONSTRAINT JHIST_EMPLOYEE_NN NOT NULL,
START_DATE DATE CONSTRAINT JHIST_START_DATE_NN NOT NULL,
END_DATE DATE CONSTRAINT JHIST_END_DATE_NN NOT NULL,
JOB_ID VARCHAR2(10 BYTE) CONSTRAINT JHIST_JOB_NN NOT NULL,
DEPARTMENT_ID NUMBER(4)
); 2 3 4 5 6 7 8
Table created.
SQL> ALTER TABLE HR.JOB_HISTORY ADD (
CONSTRAINT JHIST_EMP_ID_ST_DATE_PK
PRIMARY KEY
(EMPLOYEE_ID, START_DATE) ENABLE VALIDATE); 2 3 4
Table altered.
Após as alterações, podemos encerrar o processo de upgrade com o comando abaixo:
SQL> ALTER PLUGGABLE DATABASE APPLICATION HR_APP END UPGRADE TO '2.0';
Pluggable database altered.
Vemos que o upgrade já é refletido com sucesso no ambiente:
SQL> column app_name format a15
SQL> column app_version format a10
SQL> column app_status format a15
SQL> SELECT APP_NAME, APP_VERSION, APP_STATUS FROM DBA_APPLICATIONS WHERE APP_IMPLICIT='N';
APP_NAME APP_VERSIO APP_STATUS
--------------- ---------- ---------------
HR_APP 2.0 NORMAL
O interessante a ser observado é que o Oracle, de forma automática, cria um novo application root “clone”, toda vez que um Upgrade é realizado. Ou seja: é bom validarmos sempre se há espaço disponível para essa operação. Em nosso caso, o nome do novo elemento é “F3315411449_3_1”:
SQL> conn / as sysdba
Connected.
SQL> col name format a20
SQL> SELECT CON_ID, NAME, APPLICATION_ROOT, OPEN_MODE, APPLICATION_ROOT_CON_ID FROM V$PDBS ORDER BY 3,1;
CON_ID NAME APP OPEN_MODE APPLICATION_ROOT_CON_ID
---------- -------------------- --- ---------- -----------------------
2 PDB$SEED NO READ ONLY
3 HIPOFISE2 NO READ WRITE
4 HIPOFISE1 NO READ WRITE
6 HR_PDB1 NO READ WRITE 5
7 HR_PDB2 NO READ WRITE 5
5 HR_AC YES READ WRITE
9 F3315411449_3_1 YES READ WRITE 5
7 rows selected.
SQL> col name format a80
SQL> SELECT NAME FROM V$DATAFILE WHERE CON_ID=9;
NAME
--------------------------------------------------------------------------------
/oracle/dados/ASWAN/ASWAN/C6F4B61917B40C4DE0536A00A8C013CD/datafile/o1_mf_system
_jgsdmp5n_.dbf
/oracle/dados/ASWAN/ASWAN/C6F4B61917B40C4DE0536A00A8C013CD/datafile/o1_mf_sysaux
_jgsdmp5n_.dbf
/oracle/dados/ASWAN/ASWAN/C6F4B61917B40C4DE0536A00A8C013CD/datafile/o1_mf_undotb
s1_jgsdmp5o_.dbf
/oracle/dados/ASWAN/ASWAN/C6F4B61917B40C4DE0536A00A8C013CD/datafile/o1_mf_hr_tbs
_jgsdmp5o_.dbf
NAME
--------------------------------------------------------------------------------
Porém, os Application PDBs ainda estão com a versão antiga:
SQL> col pdb_name format a10
SQL> SELECT PDB.PDB_NAME, APP.APP_NAME, APP.APP_VERSION , APP.APP_STATUS FROM DBA_APP_PDB_STATUS APP, DBA_PDBS PDB WHERE APP.CON_UID=PDB.CON_UID;
PDB_NAME APP_NAME APP_VERSIO APP_STATUS
---------- --------------- ---------- ---------------
HR_PDB1 HR_APP 1.0 NORMAL
HR_PDB2 HR_APP 1.0 NORMAL
A tabela que criamos no processo de upgrade, não existe no Application PDB HR_PDB1:
SQL> ALTER SESSION SET CONTAINER=HR_PDB1;
Session altered.
SQL> DESC HR.JOB_HISTORY;
ERROR:
ORA-04043: object HR.JOB_HISTORY does not exist
Para que o Application PDB tenha as alterações refletidas em sua estrutura, é necessário sincronizá-lo com o Application Root, conforme o exemplo abaixo:
SQL> ALTER PLUGGABLE DATABASE APPLICATION HR_APP SYNC;
Pluggable database altered.
Agora temos um Application PDB em uma versão, e outro em outra versão:
SQL> conn sys/oracle@HR_AC as sysdba
Connected.
SQL> col pdb_name format a10
SQL> SELECT PDB.PDB_NAME, APP.APP_NAME, APP.APP_VERSION , APP.APP_STATUS FROM DBA_APP_PDB_STATUS APP, DBA_PDBS PDB WHERE APP.CON_UID=PDB.CON_UID;
PDB_NAME APP_NAME APP_VERSIO APP_STATUS
---------- --------------- ---------- ---------------
HR_PDB1 HR_APP 2.0 NORMAL
HR_PDB2 HR_APP 1.0 NORMAL
Naquele onde o upgrade foi realizado, já é possível ver a tabela criada com sucesso:
SQL> ALTER SESSION SET CONTAINER=HR_PDB1;
Session altered.
SQL> DESC HR.JOB_HISTORY;
Name Null? Type
----------------------------------------- -------- ----------------------------
EMPLOYEE_ID NOT NULL NUMBER(6)
START_DATE NOT NULL DATE
END_DATE NOT NULL DATE
JOB_ID NOT NULL VARCHAR2(10)
DEPARTMENT_ID NUMBER(4)
Para deixar o ambiente coeso, vamos aplicar o processo processo no Application PDB que está na versão 1.0:
SQL> conn sys/oracle@HR_AC as sysdba
Connected.
SQL> ALTER SESSION SET CONTAINER=HR_PDB2;
Session altered.
SQL> ALTER PLUGGABLE DATABASE APPLICATION HR_APP SYNC;
Pluggable database altered.
SQL> conn sys/oracle@HR_AC as sysdba
Connected.
SQL> col pdb_name format a10
SQL> SELECT PDB.PDB_NAME, APP.APP_NAME, APP.APP_VERSION , APP.APP_STATUS FROM DBA_APP_PDB_STATUS APP, DBA_PDBS PDB WHERE APP.CON_UID=PDB.CON_UID;
PDB_NAME APP_NAME APP_VERSIO APP_STATUS
---------- --------------- ---------- ---------------
HR_PDB1 HR_APP 2.0 NORMAL
HR_PDB2 HR_APP 2.0 NORMAL
Obs: Este procedimento foi criado pelo senhor Ahmed Baraka (www.ahmedbaraka.com) e foi apenas reproduzido por mim em um laboratório pessoal para fins de aprendizado.
Portuguese
English
Spanish