Der Parameter COMPATIBLE in einer Oracle Datenbank steuert wie sich bestimmte Features der Datenbank “abwärts” kompatibel verhalten. Das heißt, wie und mit welcher Datenstruktur Features Daten abspeichern. So kann z.B. eine alte Feature Version (niedrigere COMPATIBLE Version) nicht mit den Daten umgehen, die durch eine neue Feature Version erstellt wurden. Weiterhin kann sich das Verhalten der Datenbank zwischen den einzelnen Feature Versionen ändern.
Der COMPATIBLE Parameter wird im Rahmen eines Datenbank Upgrades (bspw. 12.2 auf 19) relevant. Oracle selbst empfiehlt, den Parameter erst nach erfolgtem Upgrade und erfolgreicher Testphase zu erhöhen. Konkret empfehle ich hier mindestens zwei Wochen an zeitlichem Abstand. Hintergrund dieser Empfehlung ist, dass ein Downgrade der Datenbank Version nach einer erhöhung der COMPATIBLE Version NICHT mehr möglich ist. Ein “zurücksetzen” der Compatible Version ist ebenfalls NICHT möglich. Einmal erhöht, bleibt nur ein Restore der kompletten Datenbank um die COMPATIBLE Version wieder herunterzusetzen. (Auf den Zeitpunkt bevor der COMPATIBLE Wert angepasst wurde)
Nun stellt sich die Frage, wie kann die eigentliche Parameteränderung denn gefahrlos getestet werden? Die Antwort darauf heißt nach meinem Wissen “Garnicht“!
Nun zum eigentlichen Thema, nämlich “Guaranteed Restore Points” in Kombination mit der Erhöhung des COMPATIBLE Parameters. Wie Mike Dietrich in seinem Blog Beitrag “Guaranteed Restore Points and COMPATIBLE Parameter” ebenfalls bemerkt, war diese Kombination in älteren Oracle Versionen eine ziemlich gefährliche. Der Restore Point war schlicht nicht mehr nutzbar, die Datenbank ist aber dennoch gestartet nach der Parameteränderung von COMPATIBLE! Seit der Oracle Version 12.2.0.1 verhindert Oracle aber das versehentliche Starten der Datenbank mit der folgenden Meldung:
SQLPLUS> alter system set COMPATIBLE='19.0.0' scope=spfile; System altered. SQLPLUS> shutdown immediate ... ORACLE instance shut down. SQLPLUS> startup ORACLE instance started. ... ORA-38880: Cannot advance compatibility from 11.2.0.4.0 to 19.0.0 due to guaranteed restore points
Mike Dietrich gibt ebenfalls in seinem Blog Beitrag eine Anleitung, wie diese “Sperrsituation” nun aufzulösen ist. Hier meine (leicht andere) Version.
Die Datenbank befindet sich im NOMOUNT Status. In diesem Status kann man einen Restore Point nicht löschen. Hierzu müssten wir uns im MOUNT Status befinden. Also muss zunächst wieder der COMPATIBLE Wert auf den ursprünglichen Wert zurückgesetzt werden. Hier können wir jetzt den Umweg über das PFILE machen (wie Mike) oder wir setzen den Wert direkt wieder im SPFILE in dem Status in dem wir die Datenbank im Moment haben (NOMOUNT). Anschließend starten wir die Datenbank neu (dieses mal im MOUNT) und entfernen den Restore Point.
SQLPLUS> alter system set COMPATIBLE='11.2.0.4.0' scope=spfile; System altered. SQLPLUS> shutdown immediate ORA-01507: database not mounted ORACLE instance shut down. SQLPLUS>startup mount ORACLE instance started. ... Database mounted. SQLPLUS> select guarantee, name from v$restore_point; GUARANTEE NAME --------- -------------------------------------------- YES BEFORE_UPGRADE SQLPLUS> drop restore point BEFORE_UPGRADE; Restore point dropped.
Nun steht es uns frei wie wir weiter verfahren. Entweder öffnen wir die Datenbank (dann mit der alten COMPATIBLE Einstellung) oder wir setzen den COMPATIBLE Wert erneut auf die höhere Version im SPFILE und starten die Datenbank nochmals durch.
Philip
Fehlercodes: ORA-38880
