PDB clone scheitert mit ORA-00600 oder ORA-65345

"Clone doch mal schnell die ProduktionsPDB auf die Testumgebung" - ein leichtfertiger Satz des Applikationsverantwortlichen, der mal kurz zu grauen Haaren beim zuständigen Kunden-Datenbankadministrator führte. Wer konnte auch ahnen, dass er gleich zweimal in Probleme lief, bei denen wir dann zu Hilfe eilten. Aber was war da eigentlich passiert?

Nach der Umstellung einiger Applikationen auf Single-Tenant bzw. Multitenant stand ein Refresh der Daten auf der Testdatenbank an. Wie es sich für größere Datenbanken gehört, hat der Kunden-Datenbankadministrator auf einen (Datapump-) Export der Daten verzichtet. Stattdessen wurde der (aus der Non-CDB Zeit bekannte) Weg mittels Recovery Manager (RMAN) genutzt, die Datenbank zu clonen. Da es sich um eine einzelne PDB handelte, war klar - hier muss auch nur die Pluggable Database gecloned werden. 

Der Kunde ist im Oracle Datenbank-Bereich ganz fit, so war es für ihn auch ein einfaches, mit dem Recovery Manager den Clone der PDB anzustoßen. Er nutzte dabei die 19.6 Produktion als Target-Datenbank und die 19.6 Testumgebung als Auxiliary. Nach dem Löschen der alten PDB aus der Testumgebung wurde das RMAN duplicate gestartet: Im nachfolgenden Statement ist die Datenbank edmp die Produktion, edmt die Test und cdbt der root-Container der Testdatenbank (MS Windows spielt hier keine Rolle, der Fehler tritt auch auf Linux-Systemen nachweisbar auf):

duplicate pluggable database edmp as edmt to cdbt from active database
db_file_name_convert('D:\oradata\cdbp\edmp','D:\oradata\cdbt\edmt');

Nach dem Restore der Datenbankdateien und der Archive Logs warf der RMAN Prozess bzw. die Datenbank einen ORA-00600 Fehler und brach das Clonen ab:

ORA-00600: internal error code, arguments: [ktbair2: illegal inheritance], [], [], [], [], [], [], [], [], [], [], []

Wir haben die Testdatenbank testweise auf 19.8 (letzter freigegebener Stand für die Applikation) gepatched - der Fehler trat aber weiterhin auf.

Da es keine Support Note zu diesem Fehler gab, haben wir die Traces analysiert und einen Support Request bei Oracle eröffnet.
In den Traces sieht man beim Auftreten dieses Fehlers folgendes:

Error Stack: ORA-600[ktbair2: illegal inheritance]
Main Stack:
ktbair2 <- kdolkr <- kco_issue_callback <- kcoapl <- kcbrapl_reread
<- kcbr_apply_change <- kcbr_mapply_change <- kcbrapply_int <- 1 <- kcbr_apply_pending
<- kcbr_media_apply <- krp_serial_apply <- krr_do_media_recovery <- krddmr
<- dbs_do_recovery <- dbs_rcv_start_main <- dbs_rcv_start <- kpdbcRecoverPdb
<- kpdbSwitch <- kpdbcApplyRecovery <- kpdbcRefreshPDB <- kpdbSwitch
<- kpdbcRefreshDrv <- kpdbadrv <- opiexe <- opiosq0 <- kpooprx <- kpoal8 <- opiodr <- ttcpip
<- opitsk <- opiino <- opiodr <- opidrv <- sou2o <- opimai_real <- opimai <- OracleThreadStart

Current SQL: alter pluggable database refresh

Die Datenbank befindet sich also schon im Media Recovery und führt einen Apply der Archivelogs durch (über den Befehl alter pluggable database refresh) und scheitert dabei. 

Beim Service Request wurden wir von Orracle auf folgende Note verwiesen:
Hot clone PDB across dblink between Linux and Windows encountered ORA-00600 [ktbair2: illegal inheritance] ( Doc ID 2546640.1 )

Der Hot Clone über den Datenbank-Link funktioniert, denn diesen haben wir als Workaround implementiert. Was nicht wirklich ein Wunder ist, denn der in der Note erwähnte Bug wurde bereits mit Datenbank-Version 18.1 gefixed.

Offensichtlich scheint diese Problematik auf einen anderen Fehler zurückzuführen sein, denn der Oracle Support verwies uns später als Lösung auf:

RMAN: PDB DUPLICATION Fails With Error: ORA-00756: RECOVERY DETECTED A LOST WRITE OF A DATA BLOCK ( Doc ID 2687900.1 )
Bug 31310624 RMAN# ORA-756 (Lost Write) during existing PDB Duplication

Symptoms:
       Corruption (Logical)
       Internal Error May Occur (ORA-600)
       ORA-756
       ORA-600 [3020]

Related To:
       Pluggable Database (PDB) / Container Recovery
       RMAN (Recovery Manager)

Description
       PROBLEM DESCRIPTION:
                 RMAN PDB duplicate fails with a lost write error
       REDISCOVERY INFORMATION:
                PDB duplicate to an existing PDB fails with a lost write error
Workaround
      None

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬ ACTION PLAN (Apply Patch)
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
1. The fix for 31310624 is first included in:
19.10.0.0.DBRU:210119 (JAN 2021) DB Release Update Revision(DB RU)

Für MS Windows muss also folgender Bundle Patch installiert werden: Patch 32062765 - Windows Database Bundle Patch 19.10.0.0.210119
Für Linux Umgebungen gibt es den Fix 31310624 auch einzeln. 

Ob der Fehler damit wirklich behoben ist, haben wir nicht mehr nachgetestet, da wir beim Kunden noch keine 19.10 Umgebung einspielen konnten. Sobald wir wissen, ob der Fehler so nicht mehr auftritt, werden wir den Artikel anpassen - wer schneller sein möchte, kann gerne Feedback in den Kommentaren hinterlassen.

Wie bereits im obigen Teil beschrieben, war unser funktionierender Workaround das Clone der Datenbank über einen Datenbank-Link. Wer wissen möchte, wie das funktioniert, wird hier fündig. 
Nachdem das Clonen bereits mehrfach erfolgreich durchgeführt wurde, kam der Kunde erneut auf uns zu. Er bekomme nun einen ORA-65345 "Integrierbare Datenbank kann nicht aktualisiert werden" (englisch: cannot refresh pluggable database) Fehler nach längerer Laufzeit - dabei mache er doch ein ganz normales Clonen und habe auch nichts geändert. Wie anhin auch ist das Skript unverändert und lief bereits.

create pluggable database edmt from emdp@CloneSource; 
alter pluggable database edmt open; 

Die Fehlerbeschreibung zum ORA-65345 sagt "The foreign archive log required for refreshing the pluggable database was not found. Re-create the refresh pluggable database and ensure that archive logging is enabled for the source multitenant container database (CDB)."

Mit dieser Fehlerbeschreibung war der Übeltäter relativ schnell auffindbar. Der Kunde hat zwar keine "refreshable pluggable database" angelegt (und natürlich lief der Archivelog Mode in der Produktion), aber das Clonen der PDB über den Datenbank-Link kopiert erst alle Datendateien in die neue Ziel-CDB und muss dann diese Datendateien noch alle auf den selben Stand bringen - dies macht die Datenbank im Hintergrund über ein Restore der Daten aus den Archivelogs der Quelldatenbank. Was war also passiert, dass das nun nicht mehr funktioniert hat? 
Das delete von Archivelogs im Recovery Manager ist schuld - denn in diesem Fall wurden die Archivelogs aus der Quell-DB in ein Backup aufgenommen und seit ein paar Tagen direkt mit delete input gelöscht. Somit standen sie am Ende des Clone-Vorgangs nicht mehr zum Recovern der gecloneten Datenbankdateien zur Verfügung. 

Der Fehler kann aber auch noch in weiteren Konstellationen auftreten, insbesondere dann, wenn die PDBs sehr groß sind und der Clone-Vorgang z.B. über Netzwerk durchgeführt wird (und durchaus Stunden dauern kann):

• delete archivelogs all (+XXX) löscht Archive Logs, bevor sie verwendet werden
• Die Fast Recovery Area gerät unter "Platzdruck" und löscht die Archive Logs, die schon in einem Backup vorhanden, sind automatisch. Dabei werden aktive Clone-Vorgänge nicht berücksichtigt.
• Eine Archivelog Deletion Policy ist gesetzt, z.B. auf shipped to standby, applied on standby oder backed up X times to device type disk und es wird ein delete obsolete ausgeführt.

Um diesen Fehler zu beseitigen muss also die jeweilige Grundeinstellung angepasst werden. D.h. ein backup archivelog mit delete input muss z.B. durch eines ohne delete input ersetzt werden. Dafür muss im Skript dann zusätzlich ein delete der Archivelogs eingebaut werden, bei dem die Archivelogs z.B. nach Aufnahme in ein Backup und Existenz seit 8h gelöscht werden. Hinweis: Wer auf der Suche nach dem Fehler über die NOTE:2613419.1 - ORA-65345 during PDB Hot Clone / PDB Refresh beim Oracle Support stolpert - diese ist, auch wenn aus verschiedenen anderen Notes auf diese verwiesen wird, nicht mehr öffentlich beim Support zu sehen.