Neste artigo, vamos simular o upgrade da Application HR_APP que criamos nos \u00faltimos artigos, de modo que estas altera\u00e7\u00f5es sejam refletidas nos Application PDBs tamb\u00e9m. Para isso, vamos conectar diretamente no Application Root e validar a vers\u00e3o atual:<\/p>\n\n\n
\n[oracle@quiasma ~]$ sqlplus sys\/oracle@HR_AC as sysdba\n \nSQL*Plus: Release 18.0.0.0.0 - Production on Mon Jul 12 18:20:06 2021\nVersion 18.13.0.0.0\n \nCopyright (c) 1982, 2018, Oracle. All rights reserved.\n \n \nConnected to:\nOracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production\nVersion 18.13.0.0.0\n \nSQL> column app_name format a15\nSQL> column app_version format a10\nSQL> column app_status format a15\nSQL> SELECT APP_NAME, APP_VERSION, APP_STATUS FROM DBA_APPLICATIONS WHERE APP_IMPLICIT='N';\n \nAPP_NAME APP_VERSIO APP_STATUS\n--------------- ---------- ---------------\nHR_APP 1.0 NORMAL\n<\/pre><\/div>\n\n\nAntes de iniciar efetivamente as altera\u00e7\u00f5es na application, devemos executar o comando abaixo usando o nome da aplica\u00e7\u00e3o, sua vers\u00e3o atual e a vers\u00e3o futura:<\/p>\n\n\n
\nSQL> ALTER PLUGGABLE DATABASE APPLICATION HR_APP BEGIN UPGRADE '1.0' TO '2.0';\n \nPluggable database altered.\n<\/pre><\/div>\n\n\nPara nosso caso, vamos criar uma tabela nova na aplica\u00e7\u00e3o, conforme script abaixo:<\/p>\n\n\n
\nSQL> CREATE TABLE HR.JOB_HISTORY\n(\n EMPLOYEE_ID NUMBER(6) CONSTRAINT JHIST_EMPLOYEE_NN NOT NULL,\n START_DATE DATE CONSTRAINT JHIST_START_DATE_NN NOT NULL,\n END_DATE DATE CONSTRAINT JHIST_END_DATE_NN NOT NULL,\n JOB_ID VARCHAR2(10 BYTE) CONSTRAINT JHIST_JOB_NN NOT NULL,\n DEPARTMENT_ID NUMBER(4)\n); 2 3 4 5 6 7 8\n \nTable created.\n \nSQL> ALTER TABLE HR.JOB_HISTORY ADD (\n CONSTRAINT JHIST_EMP_ID_ST_DATE_PK\n PRIMARY KEY\n (EMPLOYEE_ID, START_DATE) ENABLE VALIDATE); 2 3 4\n \nTable altered.\n<\/pre><\/div>\n\n\nAp\u00f3s as altera\u00e7\u00f5es, podemos encerrar o processo de upgrade com o comando abaixo:<\/p>\n\n\n
\nSQL> ALTER PLUGGABLE DATABASE APPLICATION HR_APP END UPGRADE TO '2.0';\n \nPluggable database altered.\n<\/pre><\/div>\n\n\nVemos que o upgrade j\u00e1 \u00e9 refletido com sucesso no ambiente:<\/p>\n\n\n
\nSQL> column app_name format a15\nSQL> column app_version format a10\nSQL> column app_status format a15\nSQL> SELECT APP_NAME, APP_VERSION, APP_STATUS FROM DBA_APPLICATIONS WHERE APP_IMPLICIT='N';\n \nAPP_NAME APP_VERSIO APP_STATUS\n--------------- ---------- ---------------\nHR_APP 2.0 NORMAL\n<\/pre><\/div>\n\n\nO interessante a ser observado \u00e9 que o Oracle, de forma autom\u00e1tica, cria um novo application root “clone”, toda vez que um Upgrade \u00e9 realizado. Ou seja: \u00e9 bom validarmos sempre se h\u00e1 espa\u00e7o dispon\u00edvel para essa opera\u00e7\u00e3o. Em nosso caso, o nome do novo elemento \u00e9 “F3315411449_3_1”:<\/p>\n\n\n
\nSQL> conn \/ as sysdba\nConnected.\nSQL> col name format a20\nSQL> SELECT CON_ID, NAME, APPLICATION_ROOT, OPEN_MODE, APPLICATION_ROOT_CON_ID FROM V$PDBS ORDER BY 3,1;\n \n CON_ID NAME APP OPEN_MODE APPLICATION_ROOT_CON_ID\n---------- -------------------- --- ---------- -----------------------\n 2 PDB$SEED NO READ ONLY\n 3 HIPOFISE2 NO READ WRITE\n 4 HIPOFISE1 NO READ WRITE\n 6 HR_PDB1 NO READ WRITE 5\n 7 HR_PDB2 NO READ WRITE 5\n 5 HR_AC YES READ WRITE\n 9 F3315411449_3_1 YES READ WRITE 5\n \n7 rows selected.\n \nSQL> col name format a80\nSQL> SELECT NAME FROM V$DATAFILE WHERE CON_ID=9;\n \nNAME\n--------------------------------------------------------------------------------\n\/oracle\/dados\/ASWAN\/ASWAN\/C6F4B61917B40C4DE0536A00A8C013CD\/datafile\/o1_mf_system\n_jgsdmp5n_.dbf\n \n\/oracle\/dados\/ASWAN\/ASWAN\/C6F4B61917B40C4DE0536A00A8C013CD\/datafile\/o1_mf_sysaux\n_jgsdmp5n_.dbf\n \n\/oracle\/dados\/ASWAN\/ASWAN\/C6F4B61917B40C4DE0536A00A8C013CD\/datafile\/o1_mf_undotb\ns1_jgsdmp5o_.dbf\n \n\/oracle\/dados\/ASWAN\/ASWAN\/C6F4B61917B40C4DE0536A00A8C013CD\/datafile\/o1_mf_hr_tbs\n_jgsdmp5o_.dbf\n \nNAME\n--------------------------------------------------------------------------------\n<\/pre><\/div>\n\n\nPor\u00e9m, os Application PDBs ainda est\u00e3o com a vers\u00e3o antiga:<\/p>\n\n\n
\nSQL> col pdb_name format a10\nSQL> 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;\n \nPDB_NAME APP_NAME APP_VERSIO APP_STATUS\n---------- --------------- ---------- ---------------\nHR_PDB1 HR_APP 1.0 NORMAL\nHR_PDB2 HR_APP 1.0 NORMAL\n<\/pre><\/div>\n\n\nA tabela que criamos no processo de upgrade, n\u00e3o existe no Application PDB HR_PDB1:<\/p>\n\n\n
\nSQL> ALTER SESSION SET CONTAINER=HR_PDB1;\n \nSession altered.\n \nSQL> DESC HR.JOB_HISTORY;\nERROR:\nORA-04043: object HR.JOB_HISTORY does not exist\n<\/pre><\/div>\n\n\nPara que o Application PDB tenha as altera\u00e7\u00f5es refletidas em sua estrutura, \u00e9 necess\u00e1rio sincroniz\u00e1-lo com o Application Root, conforme o exemplo abaixo:<\/p>\n\n\n
\nSQL> ALTER PLUGGABLE DATABASE APPLICATION HR_APP SYNC;\n \nPluggable database altered.\n<\/pre><\/div>\n\n\nAgora temos um Application PDB em uma vers\u00e3o, e outro em outra vers\u00e3o:<\/p>\n\n\n
\nSQL> conn sys\/oracle@HR_AC as sysdba\nConnected.\nSQL> col pdb_name format a10\nSQL> 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;\n \nPDB_NAME APP_NAME APP_VERSIO APP_STATUS\n---------- --------------- ---------- ---------------\nHR_PDB1 HR_APP 2.0 NORMAL\nHR_PDB2 HR_APP 1.0 NORMAL\n<\/pre><\/div>\n\n\nNaquele onde o upgrade foi realizado, j\u00e1 \u00e9 poss\u00edvel ver a tabela criada com sucesso:<\/p>\n\n\n
\nSQL> ALTER SESSION SET CONTAINER=HR_PDB1;\n \nSession altered.\n \nSQL> DESC HR.JOB_HISTORY;\n Name Null? Type\n ----------------------------------------- -------- ----------------------------\n EMPLOYEE_ID NOT NULL NUMBER(6)\n START_DATE NOT NULL DATE\n END_DATE NOT NULL DATE\n JOB_ID NOT NULL VARCHAR2(10)\n DEPARTMENT_ID NUMBER(4)\n<\/pre><\/div>\n\n\nPara deixar o ambiente coeso, vamos aplicar o processo processo no Application PDB que est\u00e1 na vers\u00e3o 1.0:<\/p>\n\n\n
\nSQL> conn sys\/oracle@HR_AC as sysdba\nConnected.\nSQL> ALTER SESSION SET CONTAINER=HR_PDB2;\n \nSession altered.\n \nSQL> ALTER PLUGGABLE DATABASE APPLICATION HR_APP SYNC;\n \nPluggable database altered.\n \nSQL> conn sys\/oracle@HR_AC as sysdba\nConnected.\nSQL> col pdb_name format a10\nSQL> 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;\n \nPDB_NAME APP_NAME APP_VERSIO APP_STATUS\n---------- --------------- ---------- ---------------\nHR_PDB1 HR_APP 2.0 NORMAL\nHR_PDB2 HR_APP 2.0 NORMAL\n<\/pre><\/div>\n\n\nObs: Este procedimento foi criado pelo senhor Ahmed Baraka (www.ahmedbaraka.com) e foi apenas reproduzido por mim em um laborat\u00f3rio pessoal para fins de aprendizado.<\/p>\n","protected":false},"excerpt":{"rendered":"
Neste artigo, vamos simular o upgrade da Application HR_APP que criamos nos \u00faltimos artigos, de modo que estas altera\u00e7\u00f5es sejam refletidas nos Application PDBs tamb\u00e9m. Para isso, vamos conectar diretamente no Application Root e validar a vers\u00e3o atual: Antes de iniciar efetivamente as altera\u00e7\u00f5es na application, devemos executar o comando abaixo usando o nome da […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[],"class_list":["post-5737","post","type-post","status-publish","format-standard","hentry","category-multitenant"],"_links":{"self":[{"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/posts\/5737","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/comments?post=5737"}],"version-history":[{"count":1,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/posts\/5737\/revisions"}],"predecessor-version":[{"id":9083,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/posts\/5737\/revisions\/9083"}],"wp:attachment":[{"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/media?parent=5737"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/categories?post=5737"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/swiv.com.br\/index.php\/wp-json\/wp\/v2\/tags?post=5737"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}