Autoupgrade - Scenario 1

Autoupgrade - Das Schweizer Taschenmesser Scenario 1, Std 12 nonPDB in Std 19 PDB

---

Die Installation:

Die Installation wird des Autoupgrade Tool wird im ersten Teil beschrieben.

---

Das Scenario:

Wir bewegen uns zwar in einem Enterprise Edition Umfeld, verzichten aber auf Restore Points. Damit ist diese Vorgehensweise auch bei der Standard Edition verfügbar.

Eine Non PDB Release 12c soll in eine 19c PDB umgewandelt werden. Es sind einige Vorabüberlegungen angebracht.

1. Wie teste ich den Upgrade ? Während des gesamten Testablaufs muss die Datenbank, die upzugraden ist, natürlich weiterhin zur Verfügung stehen, Es muss ein produktionsidentisches System zur Verfügung gestellt. werden,
   

2. Wie führe ich einen schnellen und sicheren Rollback durch ? Achtung: Den "Guaranteed Restore Point" haben wir in einer Std. Edition, nicht zur Verfügung.

Wichtig: Die Ziel Datenbank (19er CDB) muss angelegt worden und sollte unbedingt auf compatible 12.2.0 Mode laufen. Siehe hier: https://mikedietrichde.com/2019/04/17/when-and-how-should-you-change-compatible/

Virtual Classroom Series

Nun müssen dem Autoupgrade Tool einige Informationen übergeben werden. Es ist möglich in einem Upgrade Prozess mehrere Datenbanken hintereinander zu verarbeiten. Diese werden durch eine wahlfreie Kennung (hier upg1.) gekennzeichnet.

global.autoupg_log_dir definiert das Verzeichnis, in dem das Upgrade Tool seine globalen Logdateien ablegen soll (unabhängig von den einzelnen Datenbanken). upg1.log_dir in diesem Verzeichnis werden die für das Upgrade der jeweiligen Datenbank abgelegt. Es ist empfehlenswert, beide Verzeichnisse gleich zu setzten. So entsteht eine Struktur, die alle Logfiles enthält - dies macht die Bereitstellung von Daten für einen Service Request einfach.

upg1.sid=DBR12

Die SID der Datenbank, für die der Upgrade erfolgen soll (Hier DBR12npdb).

upg1.restoration=no

Per default setzt das Autoupgrade Tool einen Guaranteed Restore Point vor Beginn des Upgrade. Dieser steht in einer Standard Edition nicht zur Verfügung. Ich setze diesen Wort grundsätzlich, um eine höhere Transparenz zu erreichen. Da wir eine PDB erstellen bleibt die ursprüngliche DB erhalten und kann für einen Rollback verwendet werden.

upg1.source_home=/u01/app/oracle/product/12c/home1

Das Home Verzeichnis der Quell Datenbank

upg1.target_home=/u01/app/oracle/product/19.19c/home2

Das Home Verzeichnisses der Ziel Datenbank

upg1.target_cdb=cDBR19

Der Name der Ziel CDB in die die Quell Datenbank als PDB integriert werden soll.

upg1.target_pdb_name=FormerDB12

Der Name für die entstehende PDB

Der Name kann identisch mit dem Namen der Quell Datenbank sein. Dann entstehen jedoch massive Probleme mit den Listern - es würden 2 Services mit dem gleichen Namen entstehen.

upg1.pdb_copy_option=file_name_convert=NONE

In der 19er Datenbank CDB ist OMF aktiv, d.h. der Pfad ist DB_CREATE_FILE_DEST definiert - in diesem Pfad werden die neuen Datenbank Dateien abgelegt. Die Bezeichnung NONE ist -aus meiner Sicht - etwas irreführend, sie könnte den Eindruck erwecken es würde nicht kopiert.

Will man, das die Datenbank Dateien nicht kopiert werden den, so muss die default Option NOCOPY genutzt werden, Hierzu muss nur der Parameter pdb_copy_option aus dem Config File entfernt werden. Nutzt man kein OMF so kann über den Parameter file_name_convert=('/DB12/,/DB19/') erreicht werden, dass die Datenbank Dateien in eine neue Verzeichnis Struktur kopiert werden. Hier wird in allen Pfaden "/DB12/" durch "/DB19/" ersetzt. Im ASM Umfeld lautet die Konfiguration dann, bedingt durch Handling von Dateinamen im ASM Umfeld beispielsweise file_name_convert=(‘+DATA',’+DATA’).

Denkansatz 1

upg1.log_dir=/home/oracle/autoupgrade/up12npdto19pdb

upg1.sid=DBR12

upg1.restoration=no

upg1.source_home=/u01/app/oracle/product/12c/home1

upg1.target_home=/u01/app/oracle/product/19.19c/home2

upg1.target_cdb=cDBR19

upg1.target_pdb_name=FormerDB12

upg1.target_pdb_copy_option=file_name_convert=NONE

Bei jedem Start des Autoupgrade Tools entsteht ein Unterververzeichnis im Format <SID>/<laufende Nummer>, wobei ab 100 gezählt wird. Der erste Schritt ist der analyze:  java -jar autoupgrade.jar -config up12npdto19pdb.cfg -mode analyze

Es ist eine HTML Datei entstanden die Informationen über die notwendigen Änderungen in der Quell Datenbank enthält:

./DBR12/100/prechecks/dbr12_preupgrade.html

Es werden zwei "Typen" von Fehlern gemeldet. Zum einen ein Verweis auf Data Dump Advanced Queues. Hier liefert das autoupgrade Tool einen Hinweis auf eine MOS Node und der Administrator muss manuell eingreifen.

Das Löschen hat keinen Einfluss auf das Quellsystem, bei Start eines Datapumps Jobs wird eine neue Queue angelegt,

Dieser Punkt zeigt die Grenzen des Autoupgrade Tools auf.

Insbesondere das Entfernen von Datenbank Komponenten, die in dem Zielsystem nicht mehr unterstützt werden (ein Punkt der bei der Migration von 11 nach 19 relevant ist) kann ein Automatismus nicht handeln.

Hier muss der Datenbank Administrator in Zusammenarbeit mit der Applikationsentwicklung klären, ob Komponenten entfernt werden können.

Zum anderen ein Hinweise auf die Statistiken. Hier ist kein Eingreifen nötig, der "Fixup" Schritt aktualisiert die Statistiken.

java -jar autoupgrade.jar -config up12npdto19pdb.cfg -mode fixups

Die Queues wurden manuell entfernt, die Statistiken vom "Fixups" gefahren.

Die Probleme sind beseitigt - also los mit den Upgrade!

java -jar autoupgrade.jar -config up12npdto19pdb.cfg -mode deploy

Betrachten wir den laufenden Job

Den Status...

Noch einmal den Status es geht voran ...

Wer sich die Logdateien ansehen will:

Der Upgrade läuft.Jedoch, ein genauer Blick ins Logfile macht hellhörig - sollte er zumindest. Es erfolgt ein Upgrade der dbr12. Wollten wir nicht eine PDB in der 19er CDB haben?

Gut, verfolgen wir den Prozess weiter ...

Die Umwandlung in eine PDB läuft....

Nochmal den Status, auch hier sieht man: Die Umwandlung in eine PDB läuft.

Der Upgrade ist erfolgreich abgeschlossen.

In der 19er DB ist die gewünschte PDB entstanden, mit "save state" den read write Modus für den nächstem Systemstart sichern.

Man sieht auch: Die PDB hat die Datenbank Dateien aus der 12er DB kopiert.

Die Dateien der Quell Database DBR12 gibt es auch noch.

Zufriedenheit macht sich breit.

Aber:

Ein erstes Erstaunen: Denn die 12 Datenbank läuft nicht mehr !

Das spfile und das Passwort File sind doch noch da...

Das Erstaunen wächst - die 12 DB steht auch nicht mehr in der /etc/oratab !

Gut, wir machen den Eintrage in die /etc/oratab - kein Problem! DBR12:/u01/app/oracle/product/12c/home1:N i

Wir setzen die Umgebungsvariablen erneut, diesmal erfolgreich. Also erfolgt ein munteres Startup.

Das Erstaunen weicht Entsetzen...

Unsere Datenbank!

Ist dies etwa gar ein Produktionssystem?

Und was war mit den Tests ?

Und besonders - wie war das mit dem Fallback, der natürlich getestet wurde?

Was ist eigentlich schief gelaufen? Erinnern wir uns an den Blick in das Log des Upgrades.

Richtig, dort wurde der Upgrade der DBR12 gemeldet.

Der Ablauf der der Migration ist also der folgende.

1. Migration der 12er Datenbank in eine 19er Datenbank Daher ist ist ein Öffnen als 12er Datenbank nicht mehr möglich.

2. Umwandlung in eine PDB
   

Der Parameter upg1.target_pdb_copy_option=file_name_convert betrifft die Umwandlung in eine PDB - hier werden die Datenbankdateien von der nonPDB kopiert, bevor sie in eine PDB umgewandelt werden. Aber eben erst nach der Migration in den 19er Release.

Was nun? Wenn wir keine Snapshot Technologie zur Verfügung haben (Std. Edition) bleibt nur ein Rollback des Upgrades als Option oder ein Restore. Zudem - wenn wir einen Test durchführen wollen (Also einen Test des Upgrades und einen Test der Funktion aller Applikationen mit dem neuen Datenbank Release) wäre diese Methode kein gangbarer Weg. Immerhin reden wir hier ggf. über ein Produktionssystem. Es stellen sich also die Frage: Kann ich eine Test Datenbank erstellen, ohne die Quelldatenbank zu "verlieren" ? Dazu müsste die Quelldatenbank vor dem Upgrade kopiert werden. Für die Bereitstellung der Testdatenbank spielt die Laufzeit dieses Kopiervorgangs keine signifikante Rolle. Natürlich sollte der Prozess des Kopierens zu einer lastarmen Zeit erfolgen. Will man auch bei der Produktionsmigration die Quell Datenbank auf diese Weise erhalten, ist die für das Kopieren der Datenbank notwendige Zeit Fenster jedoch kritisch.

Kann man hier 0ptimierend eingreifen ?

Und ja - man kann !

Das Kopieren der Datenbank in eine CDB kann über einen Datenbank Link erfolgen, die Quell Datenbank bleibt erhalten, ich erhalte eine produktions-identische Testdatenbank, sogar von einem Server auf den anderen.

Nun bleibt die Problematik bei der Produktionsmigration. Das Kopieren der Datenbank soll ja keine Downtime bedeuten. Die Downtime soll auf das Minimum (de facto den Upgrade und die Umwandlung in eine PDB) reduziert werden. Also müssen alle Änderungen in der Quelldaten permanent in die Zieldaten-bank repliziert werden bis das Kopieren abgeschlossen wurde. Noch besser wäre es, wenn ich den Start der Migration festlegen könnte: Beispiel: Ich starte starte den Autoupgrade am Freitag Abend um 20:00. Auf den Systemen kann noch weiter gearbeitet werden. Aus Tests ist mir bekannt, der Kopiervorgang dauert 6 Stunden.

Er ist also um 02:00 nachts abgeschlossen. Um 04.00 werden die Quell System "stillgelegt" (Beginn der Downtime) um 05:00 beginnt die eigentliche Migration. Dem Autoupgrade muss nur mitgeteilt werden, dass es 9 Stunden (von 20:00 bis 05:00) warten soll, bis es den Upgrade starten soll und z.B. alle 5 Minuten die Änderungen des Quellsystems in das Zielsystem replizieren soll.

Benötigt für dieses Herangehen werden: Ein User auf der Quell Datenbank für den Database Link Die Quell Datenbank muss im Archivelog Modus laufen,

​CREATE USER clone IDENTIFIED BY clone;

GRANT CREATE SESSION, CREATE PLUGGABLE DATABASE, SELECT_CATALOG_ROLE TO clone;

GRANT READ ON sys.enc$ TO clone;

Einen TNS Names Eintrag im Zielsystem, der in das Zielsystem verweist:

DBR12 =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = tstupgrade.darkwing.net)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = DBR12.darkwing.net)

)

)

Ein Database Link auf dem Ziel System

CREATE DATABASE LINK CLONENONPDB12 CONNECT TO clone IDENTIFIED BY clone USING 'DBR12';

desc user_tables@CLONENONPDB12;

Das desc Kommmando dient der Prüfung des DB Links.

Die Konfugrationsdatei ähnelt der Vorherigen: upg1.source_dblink.DBR12=CLONENONPDB12 300

Neu ist der Eintrag CLONENONPDB12, dieser definiert den Namen des angelegten Datenbank Links vom Quell in das Zielsystem. 300

Dieser Wert gibt das Intervall in Sekunden an, in dem die Zieldatenbank über den Datenbank Link aktualisiert werden soll.

upg1.start_time=+60m

Hier wird festgelegt, wann der eigentliche Upgrade Prozess starten soll. Dieser Wert muss natürlich größer sein, als das für den Kopiervorgang notwendige Zeit Fenster - dieses muss durch aussagefähige Tests ermittelt werden. upg1.target_pdb_copy_option.DBR12=file_name_convert=NONE upg1.target_pdb_name.DBR12=FormerDB12clone

Hier muss die SID der Quell Datenbank DBR12 eingefügt werden.

upg1.close_source=NO Dieser Parameter ist wichtig. Per default ist er auf YES, dadurch wird die Quell DB vor dem Upgrade des Zielsystems heruntergefahren. Dies ist evtl. nicht erwünscht, z.B. wenn ein Migrationstest eines Produktionssystem erfolgt. Erfolgt eine Produktionsmigration kann hierdurch sicher gestellt werden, das nicht versehentlich ein Zugriff auf das "alte" System erfolgt.

global.autoupg_log_dir=/home/oracle/autoupgrade/up12npdto19pdb2

upg1.log_dir=/home/oracle/autoupgrade/up12npdto19pdb2

upg1.sid=DBR12

upg1.source_dblink.DBR12=CLONENONPDB12 300

upg1.restoration=no

upg1.source_home=/u01/app/oracle/product/12c/home1

upg1.target_home=/u01/app/oracle/product/19.19c/home2

upg1.target_cdb=cDBR19

upg1.target_pdb_name=FormerDB12

upg1.target_pdb_copy_option=file_name_convert=NONE

upg1.start_time=+30m

upg1.close_source=NO

Im Job Protokoll sieht man die Verzögerung des Starts.

Der Clone in der 19er CDB wird erstellt

In der 19er DB ist der Clone erstellt worden.

Die Datenbank ist im mount Status.

Notwendig sind noch Refreshs, Migration auf 19c und Umwandlung in CDB

Im Alert Log der Ziel Datenbank sind die Refreshs zu erkennen

Und ein Refresh

Dann beginnt der Upgrade Prozess

Gefolgt von vom Upgrade ..

Und der Umwandlung in eine PDB.

Und dem Kompilieren..

Der Upgrade ist abgeschlossen

Die 12er Datenbank läuft immer noch

Der Clone in der 19er DB ist verfügbar

Nun hat die entstandene PDB einen von der Quell DB abweichenden Namen.

Statt DBR12npdb lautet der PDB Name FORMERDB12CLONE, der Service Name hat sich folglich auch geändert: formerdb12clone.darkwing.net statt DBR12npdb.darkwing.net

Dies ist notwendig, da zwei Services gleichen Namens sich nicht korrekt an den Listener verbinden können. Um nach dem Produktionsupgrade einen passenden Service in einer PDB zu erzeugen dienen die Kommandos DBMS_SERVICE.CREATE_SERVICE und DBMS_SERVICE.START_SERVICE

Hier zu wird mittels alter session set container in die PDB gewechselt werden.

alter session set container=FORMER18PDB;

exec DBMS_SERVICE.CREATE_SERVICE('DBR12npdb.darkwing.net',\

'DBR12npdb.darkwing.net');

exec DBMS_SERVICE.START_SERVICE('DBR12npdb.darkwing.net');

alter pluggable database FORMER18PDB save state;

Man sieht - der "alte" Service ist wieder aktiv.

Diese Vorgehensweise deckt also alle Anforderungen ab;

• Die 12er Datenbank bleibt erhalten

• Es liegt eine produktionsidentische Testdatenbank vor

• Das Downtime Fenster wird nicht durch die Zeit für das Kopieren der DB verlängert.

Hiermit ist das Scenario 1, das aus meiner Erfahrung das häufigste ist, abgedeckt.

Weiter geht's im nächsten Blog:

Migration einer 18er PDB in eine 19er PDB.

---

Bei Fragen schreib mich einfach an: oracle.wasistwas@outlook.com

---