Einhängen einer EE-PDB in eine SE2-CDB – kann das funktionieren?
Datenaustausch zwischen Datenbanken – ein Klassiker, eine oft einfache Aufgabe. Wenn man beide Editionen der Oracle-Datenbank, die Enterprise Edition (EE) und die Standard Edition 2 (SE2) im Einsatz hat, z.B. wenn man aus Kostengründen in den verschiedenen Stages unterschiedliche Datenbank-Editionen einsetzt oder wenn man generell von der EE weg zur günstigeren SE2 migrieren möchte, dann könnte es doch eine Möglichkeit sein, in der Containerdatenbank-Architektur, einfach die PDB durch „Umhängen“ zu migrieren. Aber kann das funktionieren?
Es geht also darum, ob man eine Pluggable Datenbank (PDB) von einer Enterprise Edition-CDB mittels Unplug/Plug in eine SE2-Datenbank einhängen kann und was passiert, wenn in der Quelldatenbank Datenbank-Funktionen genutzt werden, die in der SE2 nicht verfügbar sind.
TL;DR:
Der einzige offiziell unterstützte Weg, von einer Enterprise Editon (EE)-Datenbank zur Standard-Edition2 (SE2) zu kommen, ist Export/Import (siehe MOS-Note 139642.1). Der hier vorgestellte Weg mittels Unplug/Plug oder Remote Cloning KANN unter gewissen Voraussetzungen funktionieren, ist aber nicht unterstützt.
Die Testumgebung
Auf meinem Test-System ist Oracle 19c je einmal die SE2- und einmal die EE-Software installiert. Dabei sind aus der EE-Software keinerlei Optionen rauskonfiguriert (siehe z.B. „Oracle Database 19c – Database Installation Guide“, Kapitel 12)
Beide Installationen haben den aktuellen Patch-Stand (RU 19.11 / April 2021):
oracle@kiwi:~/ [SECDB1] rdbms19se oracle@kiwi:~/ [rdbms19se] $ORACLE_HOME/OPatch/opatch lspatches 32545013;Database Release Update : 19.11.0.0.210420 (32545013) 32399816;OJVM RELEASE UPDATE: 19.11.0.0.210420 (32399816) 31732095;UPDATE PERL IN 19C DATABASE ORACLE HOME TO V5.32 29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399) OPatch succeeded. oracle@kiwi:~/ [rdbms19se] rdbms19ee oracle@kiwi:~/ [rdbms19ee] $ORACLE_HOME/OPatch/opatch lspatches 32545013;Database Release Update : 19.11.0.0.210420 (32545013) 32399816;OJVM RELEASE UPDATE: 19.11.0.0.210420 (32399816) 31732095;UPDATE PERL IN 19C DATABASE ORACLE HOME TO V5.32 29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399) OPatch succeeded.
Test 1:
In einer EE-CDB wird eine PDB angelegt, ausgehängt (UNPLUG) und dann in eine SE2-CDB eingehängt:
oracle@kiwi:~/ [CDB19C] sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Thu Jul 8 20:21:28 2021
Version 19.11.0.0.0
Copyright (c) 1982, 2020, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.11.0.0.0
SQL> create pluggable database EE2SE from TESTPDB file_name_convert=('TESTPDB','EE2SE');
Pluggable database created.
SQL> alter pluggable database all open;
Pluggable database altered.
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 SAMPLEPDB READ WRITE NO
4 TESTPDB READ WRITE NO
5 EE2SE READ WRITE NO
SQL> alter pluggable database EE2SE close immediate;
Pluggable database altered.
SQL> alter pluggable database EE2SE unplug into '/home/oracle/ee2se.xml';
Pluggable database altered.
SQL> drop pluggable database EE2SE keep datafiles;
Pluggable database dropped.
SQL> exit
Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.11.0.0.0
oracle@kiwi:~/ [SECDB1] sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Thu Jul 8 20:25:15 2021
Version 19.11.0.0.0
Copyright (c) 1982, 2020, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.11.0.0.0
SQL> create pluggable database EE2SE using '/home/oracle/ee2se.xml' file_name_convert=('/u01/oradata/CDB19/EE2SE/','/u01/oradata/SECDB1/EE2SE/');
Pluggable database created.
SQL> alter pluggable database EE2SE open;
Warning: PDB altered with errors.
Was sind die Fehler, die ein erfolgreiches Öffnen der PDB verhindern?
SQL> select type,message from pdb_plug_in_violations where status <>'RESOLVED'; TYPE MESSAGE --------- ---------------------------------------------------------------------------------------------------- WARNING CDB parameter pga_aggregate_target mismatch: Previous 3000M Current 6424M WARNING PDB is Enterprise Edition (8), but CDB is not Enterprise Edition (4) ERROR Database option APS mismatch: PDB installed version 19.0.0.0.0. CDB installed version NULL. ERROR Database option SDO mismatch: PDB installed version 19.0.0.0.0. CDB installed version NULL. ERROR Database option XOQ mismatch: PDB installed version 19.0.0.0.0. CDB installed version NULL.
Anscheinend ist es nicht die falsche Edition, denn das ist nur eine „Warnung“, sondern es sind die in der Quell-CDB installierten Optionen, die in der SE2 nicht zur Verfügung stehen und somit das erfolgreiche Öffnen der PDB verhindern.
Dabei könnte die Option „SDO“ unkritisch sein, denn die Spatial Option steht seit Ende 20219 auch kostenfrei in der SE2 zur Verfügung.
Test 2:
Starten wir also einen zweiten Versuch, bei der in der Ausgangsdatenbank keine Option außer Java installiert ist.
Beim Anlegen der CDB habe ich direkt die PDB „EE2SE“ mit anlegen lassen:
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 EE2SE READ WRITE NO
Wir können also die PDB direkt aushängen:
SQL> alter pluggable database EE2SE close immediate; Pluggable database altered. SQL> alter pluggable database EE2SE unplug into '/home/oracle/ee2se.xml'; Pluggable database altered. SQL> drop pluggable database EE2SE keep datafiles; Pluggable database dropped.
Und in diesem Fall gibt es keine Fehler beim Einhängen in die SE2-CDB:
SQL> create pluggable database EE2SE using '/home/oracle/ee2se.xml' nocopy; Pluggable database created. SQL> alter pluggable database EE2SE open; Pluggable database altered.
Es gibt nur einige Warnungen, die aber das Öffnen der PDB nicht verhindern:
SQL> select type,message from pdb_plug_in_violations where status <>'RESOLVED'; TYPE MESSAGE --------- ---------------------------------------------------------------------------------------------------- WARNING CDB parameter pga_aggregate_target mismatch: Previous 3000M Current 6424M WARNING PDB is Enterprise Edition (8), but CDB is not Enterprise Edition (4) WARNING Database option CATJAVA mismatch: PDB installed version NULL. CDB installed version 19.0.0.0.0. WARNING Database option CONTEXT mismatch: PDB installed version NULL. CDB installed version 19.0.0.0.0. WARNING Database option JAVAVM mismatch: PDB installed version NULL. CDB installed version 19.0.0.0.0. WARNING Database option ORDIM mismatch: PDB installed version NULL. CDB installed version 19.0.0.0.0. WARNING Database option XML mismatch: PDB installed version NULL. CDB installed version 19.0.0.0.0. 7 rows selected.
Es sind auch alle Datenbank-Komponenten gültig:
SQL> select comp_name,status from dba_registry COMP_NAME STATUS ---------------------------------------- -------------------------------------------- Oracle Database Catalog Views VALID Oracle Database Packages and Types VALID Oracle Real Application Clusters OPTION OFF JServer JAVA Virtual Machine VALID Oracle XDK VALID Oracle Database Java Packages VALID Oracle XML Database VALID Oracle Workspace Manager VALID Oracle Text VALID Oracle Multimedia VALID
OK, das war jetzt ein erfolgreicher Labor-Test mit einer leeren PDB. Aber wie ist es mit Daten?
Test 3:
Installieren wir also mal die Oracle-Beispieldaten von github (https://github.com/oracle/db-sample-schemas) in der PDB und probieren dann, die PDB in die SE2 einzuhängen.
Auch in diesem Fall – die Einzelheiten spare ich mir – gelingt das Einhängen in die SE2-CDB ohne Fehler.
Dies ist verwunderlich, denn das SH-Schema enthält zwei partitionierte Tabellen:
SQL> select distinct table_name from dba_tab_partitions where table_owner='SH'; TABLE_NAME ------------------------------ COSTS SALES
Und wie der folgende Ausführungsplan zeigt, wird Partitioning auch bei den Abfragen ausgenutzt (Partition Pruning):
SQL> select count(*) from sh.sales where time_id > to_date('01-JAN-2002','DD-MON-YYYY');
Execution Plan
----------------------------------------------------------
Plan hash value: 1500327972
---------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
---------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 8 | 4 (0)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | 8 | | | | |
| 2 | PARTITION RANGE ITERATOR| | 629 | 5032 | 4 (0)| 00:00:01 | 21 | 28 |
|* 3 | TABLE ACCESS FULL | SALES | 629 | 5032 | 4 (0)| 00:00:01 | 21 | 28 |
---------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter("TIME_ID">TO_DATE(' 2002-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
Der Grund dafür, dass der Transfer von EE nach SE2 mit partitionierten Tabellen funktioniert, ist wahrscheinlich die Tatsache, dass das Automatic Workload Repository (AWR) auch in der SE2 vorhanden ist (obwohl es nicht genutzt werden darf) und dass das AWR partitionierte Tabellen nutzt. Daher muss die Funktionalität „Partitioning“ auch in der SE2 vorhanden sein. Für eigene Tabellen darf (und kann) man es trotzdem nicht nutzen.
Darüber, wie der obige erfolgreiche Transfer aus Lizenzsicht zu bewerten ist, möchte ich allerdings lieber nicht nachdenken …
Ergänzung: auch wenn man nicht mit Unplug/Plug arbeitet, sondern die EE-PDB mit „Remote Cloning“ kopiert, kann man sie anschließend in der SE2-CDB problemlos öffnen.
Fazit:
In einfachen Fällen funktioniert der Wechsel von der Enterprise Edition zur Standard Edition 2 mittels Aushängen und Einhängen einer PDB bzw. mit Remote-Cloning. Allerdings besteht das Risiko, dass man sich unerkannt Features der Enterprise Edition in die SE2-Datenbank einhandelt.
Quellen / Referenzen / Links
- MOS-Note „Converting An Enterprise Edition Database To Standard Edition (Doc ID 139642.1)“
- Oracle Database 19c – Linux Database Installation Guide“, Kapitel 12 „Enabling and Disabling Oracle Database Options After Installation“
- Spatial now included with all editions of Oracle Database
Amazon Partner Link:
