Multitenant: Einhängen einer Non-CDB mit einem höheren Patchstand
Neben dem Remote-Cloning einer Non-CDB in eine CDB mit einer anderen Einstellung bei MAX_STRING_SIZE ist das Einhängen oder Remote-Clonen einer Non-CDB in eine CDB mit höherem Patchstand eine Aufgabe, die man Alltag schon mal öfter hat, wenn seine Systeme nicht auf einem einheitlichen Patchstand halten konnte. Schauen wir uns doch mal an, wie dieser Sonderfall funktioniert.
Ausgangssituation
Quelle: Non-CDB NCDB1907:
Versionsstand:
oracle@kiwi:~/ [NCDB1907] $ORACLE_HOME/OPatch/opatch lspatches
30805684;OJVM RELEASE UPDATE: 19.7.0.0.200414 (30805684)
30869156;Database Release Update : 19.7.0.0.200414 (30869156)
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)
OPatch succeeded.
Parameter MAX_STRING_SIZE
SQL> show parameter max_string_size
NAME TYPE VALUE
------------------------------------ ----------- ------------------------
max_string_size string EXTENDED
(Der Parameter ist für den Test nicht relevant, aber dieser Post ist im Kontext von dem Blog-Post „MAX_STRING_SIZE und Remote Cloning einer Non-CDB“ entstanden.
Ziel: Container-Datenbank CDB1921:
Versionsstand:
oracle@kiwi:~/ [CDB1921] $ORACLE_HOME/OPatch/opatch lspatches
35787077;DATAPUMP BUNDLE PATCH 19.21.0.0.0
35648110;OJVM RELEASE UPDATE: 19.21.0.0.231017 (35648110)
35643107;Database Release Update : 19.21.0.0.231017 (35643107)
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)
OPatch succeeded.
SQL> show parameter max_string_size
NAME TYPE VALUE
------------------------------------ ----------- ------------------------
max_string_size string STANDARD
Schritt 1: „CREATE PLUGGABLE DATABASE“-Recht in der Non-CDB vergeben
Der Benutzer, mit dem sich der Datenbank-Link an der Non-CDB anmeldet, muss dort das „CREATE PLUGGABLE DATABASE“-Recht bekommen:
SQL> grant create pluggable database to system;
Grant succeeded.
Schritt 2: Datenbank-Link von der CDB in die Non-CDB anlegen (und testen)
SQL> create database link NCDB1907
2 connect to system identified by manager
3 using 'localhost:1521/NCD1907';
Database link created.
SQL> select * from dual@NCDB1907;
D
-
X
Schritt 3: Datenbank-Dateien kopieren
create pluggable database PDB1907 from NON$CDB@NCDB1907
2 file_name_convert=
3 ('/u01/oradata/NCDB1907','/u01/oradata/CDB1921/PDB1907')
4 ;
Pluggable database created.
Ergebnis:
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ WRITE NO
4 PDB1907 MOUNTED
Schritt 4: Dictionary-Konvertierung
SQL> alter session set container=PDB1907;
Session altered.
SQL> spool 1907to1921.log
SQL> @?/rdbms/admin/noncdb_to_pdb.sql
Session altered.
SQL>
SQL> -- leave the PDB in the same state it was when we started
SQL> BEGIN
2 execute immediate '&open_sql &restricted_state';
3 EXCEPTION
4 WHEN OTHERS THEN
5 BEGIN
6 IF (sqlcode <> -900) THEN
7 RAISE;
8 END IF;
9 END;
10 END;
11 /
PL/SQL procedure successfully completed.
SQL>
SQL> WHENEVER SQLERROR CONTINUE;
SQL> spool off
Schritt 5: PDB öffnen
Wenn man jetzt die PDB öffnen will, dann meldet die Datenbank einen Fehler:
SQL> alter pluggable database pdb1907 open;
Warning: PDB altered with errors.
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ WRITE NO
4 PDB1907 READ WRITE YES
Die PDB ist zwar geöffnet, aber nur im Restricted-Mode. Woran das liegt, zeigt der Blick auf die View PDB_PLUG_IN_VIOLATIONS:
SQL> select message,action from pdb_plug_in_violations where status <> 'RESOLVED';
MESSAGE
--------------------------------------------------------------------------
ACTION
--------------------------------------------------------------------------
Interim patch 35648110/25365038 (OJVM RELEASE UPDATE: 19.21.0.0.231017 (35648110
)): Installed in the CDB but not in the PDB
Call datapatch to install in the PDB or the CDB
Interim patch 35787077/25410019 (DATAPUMP BUNDLE PATCH 19.21.0.0.0): Installed i
n the CDB but not in the PDB
Call datapatch to install in the PDB or the CDB
Interim patch 30805684/23401476 (OJVM RELEASE UPDATE: 19.7.0.0.200414 (30805684)
): Not installed in the CDB but installed in the PDB
Call datapatch to install in the PDB or the CDB
'19.21.0.0.0 Release_Update 2309301519' is installed in the CDB but '19.7.0.0.0
Release_Update 2004040350' is installed in the PDB
Call datapatch to install in the PDB or the CDB
4 rows selected.
Wie erwartet, hat Oracle bemerkt, dass die neue PDB noch den Versionsstand 19.07 hat und dass die Patches des Release-Updates 19.21 noch in der PDB eingespielt werden müssen.
Schritt 6: datapatch ausführen
Mit dem Parameter „-pdbs“ kann datapatch für einzelne PDBs ausgeführt werden.
oracle@kiwi:~/ [CDB1921] /u00/app/oracle/product/19.21-ee/OPatch/datapatch -verbose -pdbs PDB1907
SQL Patching tool version 19.21.0.0.0 Production on Mon Jul 8 18:25:17 2024
Copyright (c) 2012, 2023, Oracle. All rights reserved.
Log file for this invocation: /u00/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_49934_2024_07_08_18_25_17/sqlpatch_invocation.log
Connecting to database...OK
[...]
Validating logfiles...done
Patch 30805684 rollback (pdb PDB1907): SUCCESS
logfile: /u00/app/oracle/cfgtoollogs/sqlpatch/30805684/23401476/30805684_rollback_CDB1921_PDB1907_2024Jul08_18_25_45.log (no errors)
Patch 35643107 apply (pdb PDB1907): SUCCESS
logfile: /u00/app/oracle/cfgtoollogs/sqlpatch/35643107/25405995/35643107_apply_CDB1921_PDB1907_2024Jul08_18_25_56.log (no errors)
Patch 35648110 apply (pdb PDB1907): SUCCESS
logfile: /u00/app/oracle/cfgtoollogs/sqlpatch/35648110/25365038/35648110_apply_CDB1921_PDB1907_2024Jul08_18_25_56.log (no errors)
Patch 35787077 apply (pdb PDB1907): SUCCESS
logfile: /u00/app/oracle/cfgtoollogs/sqlpatch/35787077/25410019/35787077_apply_CDB1921_PDB1907_2024Jul08_18_29_32.log (no errors)
Die Datenbank ist allerdings immer noch „nur“ im Restricted-Modus geöffnet, d.h. wir schließen und öffnen sie einmal:
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ WRITE NO
4 PDB1907 READ WRITE YES
SQL> alter pluggable database pdb1907 close;
Pluggable database altered.
SQL> alter pluggable database pdb1907 open;
Pluggable database altered.
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ WRITE NO
4 PDB1907 READ WRITE NO
Schritt 7: Kontrolle
SQL> set pagesize 100
SQL> column comp_name format a40
SQL> column version_full format a20
SQL> column con$name format a10
SQL> select comp_name,version_full,status from cdb_registry where con$name='PDB1907';
COMP_NAME VERSION_FULL STATUS
---------------------------------------- -------------------- -----------
Oracle Database Catalog Views 19.21.0.0.0 VALID
Oracle Database Packages and Types 19.21.0.0.0 INVALID
Oracle Real Application Clusters 19.21.0.0.0 OPTION OFF
JServer JAVA Virtual Machine 19.21.0.0.0 VALID
Oracle XDK 19.21.0.0.0 VALID
Oracle Database Java Packages 19.21.0.0.0 VALID
OLAP Analytic Workspace 19.21.0.0.0 VALID
Oracle XML Database 19.21.0.0.0 VALID
Oracle Workspace Manager 19.21.0.0.0 VALID
Oracle Text 19.21.0.0.0 VALID
Oracle Multimedia 19.21.0.0.0 VALID
Spatial 19.21.0.0.0 INVALID
Oracle OLAP API 19.21.0.0.0 VALID
Oracle Label Security 19.21.0.0.0 VALID
Oracle Database Vault 19.21.0.0.0 VALID
15 rows selected.
Zwei Komponenten sind „INVALID“. Dieses Problem können wir aber mittels „utlrp.sql“ lösen:
SQL> alter session set container=PDB1907;
Session altered.
SQL> @?/rdbms/admin/utlrp.sql
[...]
Function created.
PL/SQL procedure successfully completed.
Function dropped.
PL/SQL procedure successfully completed.
Ergebnis:
SQL> select comp_name,version_full,status from cdb_registry where con$name='PDB1907';
COMP_NAME VERSION_FULL STATUS
---------------------------------------- -------------------- ------------
Oracle Database Catalog Views 19.21.0.0.0 VALID
Oracle Database Packages and Types 19.21.0.0.0 VALID
Oracle Real Application Clusters 19.21.0.0.0 OPTION OFF
JServer JAVA Virtual Machine 19.21.0.0.0 VALID
Oracle XDK 19.21.0.0.0 VALID
Oracle Database Java Packages 19.21.0.0.0 VALID
OLAP Analytic Workspace 19.21.0.0.0 VALID
Oracle XML Database 19.21.0.0.0 VALID
Oracle Workspace Manager 19.21.0.0.0 VALID
Oracle Text 19.21.0.0.0 VALID
Oracle Multimedia 19.21.0.0.0 VALID
Spatial 19.21.0.0.0 VALID
Oracle OLAP API 19.21.0.0.0 VALID
Oracle Label Security 19.21.0.0.0 VALID
Oracle Database Vault 19.21.0.0.0 VALID
15 rows selected.
Und „MAX_STRING_SIZE“ wurde übrigens auch korrekt übernommen:
SQL> column value format a30
SQL> select con_id,value from v$system_parameter where name='max_string_size';
CON_ID VALUE
---------- ------------------------------
0 STANDARD
4 EXTENDED
Zusammengefasst:
Einhängen oder „Remote Cloning“ einer Non-CDB$ in eine CDB mit einem höheren Patch-Stand ist möglich. Ähnlich wie bei einer Patch-Einspielung muss auch hier der Patch in der neuen PDB mittels „datapatch“ installiert werden. Die nach der Patch-Einspielung ungültigen Komponenten können einfach mittels „utlrp.sql“ validiert werden; dieser Schritt ist ansonsten nicht erforderlich, aber ich gehöre zu den DBAs, die diesen Schritt ohnehin nach jeder Patch-Einspielung machen. Daher empfehle ich es meinen Kunden auch immer „utlrp.sql“ und die anschließende Kontrolle via CDB_REGISTRY in ihre Patch-Prozeduren mit aufzunehmen.