MAX_STRING_SIZE und Remote Cloning einer Non-CDB
Die maximale Länge einer VARCHAR2-Spalte ist standardmäßig auf 4000 Byte begrenzt. Mit der Einstellung „MAX_STRING_SIZE=EXTENDED“ kann man dieses Limit auf 32767 Bytes erhöhen. Aber kann man eine Non-CDB mit derart „verlängerten“ VARCHAR2-Spalten in eine CDB mit Standard-Einstellung kopieren? Kommt es dabei zu Problemen? Was ist dabei zu beachten?
Über die Einstellung MAX_STRING_SIZE habe ich schon an anderer Stelle in diesem Blog geschrieben:
- Multitenant: Wechsel zu den Extended Datatypes
- Oracle 12c: MAX_STRING_SIZE=EXTENDED – wo und wie werden die Daten abgespeichert?
Für meinen aktuellen Test habe ich zwei Datenbanken angelegt:
- NCDBEXT – eine Non-CDB mit MAX_STRING_SIZE=EXTENDED
- CDB1923 – eine CDB mit MAX_STRING_SIZE=STANDARD
Beide haben den Versionsstand Oracle Database 19c – 19.23 (RU April 2024):
oracle@kiwi:~/ $ORACLE_HOME/OPatch/opatch lspatches
36420641;DATAPUMP BUNDLE PATCH 19.23.0.0.0
36195566;JDK BUNDLE PATCH 19.0.0.0.240416
36199232;OJVM RELEASE UPDATE: 19.23.0.0.240416 (36199232)
36233263;Database Release Update : 19.23.0.0.240416 (36233263)
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)
OPatch succeeded.Vorbereitungen:
Einstellungen der Non-CDB:
oracle@kiwi:~/ [NCDBEXT] sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Sat Jul 6 12:32:20 2024
Version 19.23.0.0.0
Copyright (c) 1982, 2023, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.23.0.0.0
SQL> select cdb from v$database;
CDB
---
NO
SQL> show parameter max_string_size
NAME TYPE VALUE
------------------------------- ----------- ------------------------------
max_string_size string EXTENDEDDamit wir gleich ein „remote-cloning“ machen können, müssen wir das „CREATE PLUGGABLE DATABASE“-Recht in der Non-CDB vergeben:
SQL> grant create pluggable database to system;
Grant succeeded.
SQL> exit
Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.23.0.0.0Und jetzt noch ein Blick auf die CDB:
oracle@kiwi:~/ [CDB1923] sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Sat Jul 6 12:32:55 2024
Version 19.23.0.0.0
Copyright (c) 1982, 2023, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.23.0.0.0
SQL> select cdb from v$database;
CDB
---
YES
SQL> show parameter max_string_size
NAME TYPE VALUE
------------------------------ ----------- ------------------------------
max_string_size string STANDARD
SQL> exit
Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.23.0.0.0Clonen der Non-CDB
Schritt 1: Datenbank-Link anlegen und testen
SQL> create database link NCDBEXT
2 connect to system identified by manager
3 using 'localhost:1521/NCDBEXT';
Database link created.
SQL> select * from dual@ncdbext;
D
-
XSchritt 2: Non-CDB mittels Remote-Cloning zur PDB machen
SQL> create pluggable database PDBEXT from NON$CDB@ncdbext
2 file_name_convert=
3 ('/u01/oradata/NCDBEXT','/u01/oradata/CDB1923/PDBEXT');
Pluggable database created.Bis jetzt ist noch nicht viel passiert, denn das Remote-Cloning kopiert nur die Datenbank-Dateien der Non-CDB.
Schritt 3: Ergebnis kontrollieren
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDBEXT MOUNTED
SQL> alter session set container=PDBEXT;
Session altered.
SQL> show con_name
CON_NAME
------------------------------
PDBEXT
SQL> show parameter max_string_size;
NAME TYPE VALUE
------------------------------- ----------- ------------------------------
max_string_size string STANDARDDer Parameter ist also aktuell auf „STANDARD“ gesetzt. Dabei gilt, dass die Einstellungen auf PDB-Ebene in der Tabelle PDB_SPFILE$-Tabelle gespeichert sind und nicht im SPFILE. Es ist auch nicht verwunderlich, dass die Einstellung noch auf „STANDARD“ steht, denn außer dem Kopieren der Datenbank-Dateien ist ja noch nichts passiert
Konvertierung des Data Dictionaries
Der entscheidende Schritt ist jetzt die Konvertierung des Data Dictionaries. Aus dem „vollwertigen“ Data Dictionary der Non-CDB muss jetzt ein Dictionary gemacht werden, dass auf die Objekt-Definitionen etc. im Root-Container CDB$ROOT verweist:
SQL> spool /home/oracle/pdbext_noncdb_to_pdb.log
SQL> @?/rdbms/admin/noncdb_to_pdb.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 offDie Dictionary-Konvertierung läuft also ohne Probleme durch. Wie ist das Ergebnis?
QL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
3 PDBEXT MOUNTED
SQL> alter pluggable database PDBEXT open;
Pluggable database altered.
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
3 PDBEXT READ WRITE NO
SQL> show parameter max_string_size
NAME TYPE VALUE
------------------------------- ----------- ------------------------------
max_string_size string EXTENDED
SQL> exit
Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.23.0.0.0Anscheinend hat also das Skript „noncdb_to_pdb.sql“ die Einstellung erkannt und die Einstellung auf PDB-Ebene geändert. Allerdings findet sich weder in der alert.log-Datei der CDB-Instanz noch im Log des Konvertierungsskriptes ein Hinweis dazu.
Fazit
In diesem Test war ein Einhängen einer „Extended-Non-CDB“ in eine „Standard-CDB“ ohne Probleme möglich. Das Konvertierungsskript erkennt den Unterschied und passt die Einstellung der neuen PDB automatisch an.