top of page
Suche

Autoupgrade - Scenario 2

  • Autorenbild: Christian Floreck
    Christian Floreck
  • 2. Jan. 2023
  • 2 Min. Lesezeit

Aktualisiert: 24. Dez. 2023


Autoupgrade - Das Schweizer Taschenmesser Scenario 2, Std 18 PDB in Std 19 PDB




 


Die Installation:


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


Grundlegende Informationen über den Aufbau der Konfiguration Datei findet ihr im zweiten Teil des Blogs.


 

Das Scenario:


Wir bewegen uns in einem Standard Edition Umfeld.

Eine PDB Release 18c soll in eine 19c PDB umgewandelt werden. Die üblichen Vorabüberlegungen:

  1. Wie teste ich den Upgrade ? Während des gesamten Testablaufs muss 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 ? Den "Guaranteed Restore Point" haben wir, da Std. Edition, nicht zur Verfügung.


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



Wir greifen auf die gleiche Technik zurück, die wir auch bei der Migration im 12er Umfeld genutzt haben (Siehe Scenario 1)

Es erfolgt also erst ein Kopieren der Quelldatenbank (hier einer PDB) in die Zieldatenbank mittels DB Link. Dann erfolgt eine Migration auf 19c. Ein Start von noncdb_to_pdb,sql ist nicht nötig, da wir uns schon im Quellsystem in einem PDB Umfeld bewegen,




Benötigt für dieses Herangehen werden also: Ein User auf der Quell Datenbank für den Database Link

Da wir uns im PDB Umfeld bewegen, müssen die User mit der Kennung C## gekenn-zeichnet werden. Das Anlegen von Usern in der PDB ist zwar möglich, aber das Erstellen eines "globalen" Users aus der CDB heraus scheint mir schlüssiger.

​CREATE USER C##clone IDENTIFIED BY clone container=all;

GRANT CREATE SESSION, CREATE PLUGGABLE DATABASE, SELECT_CATALOG_ROLE TO c##clone container=all;

GRANT READ ON sys.enc$ TO c##clone container=all;


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

DBR18pdb=

(DESCRIPTION =

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

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = DBR18pdb.darkwing.net)

)

)

Und einen Datenbank Link im Zielsystem.

CREATE DATABASE LINK CLONE18PDB CONNECT TO c##clone IDENTIFIED BY clone USING 'DBR18db';

Die Konfugrationsdatei ähnelt der im Scenario 1 genutzten. Allerdings muss hier der Name der Quell PDB definiert werden: upg1.pdbs=DBR18PDB

Es ist möglich mehrere PDBS, getrennt von einem Komma anzugeben. Dann müssen für jeden dieser Datenbank die Parameter upg1.source_dblink und upg1.target_pdb_name separat definiert werden (jeder von ihnen verweist auf eine PDB).

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.

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

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

upg1.sid=DBR18CDB

upg1.pdbs=DBR18PDB

upg1.restoration=no

upg1.source_home=/u01/app/oracle/product/18c/home2

upg1.target_home=/u01/app/oracle/product/19c/home3

upg1.source_dblink.DBR18PDB=CLONE18PDB 300

upg1.target_cdb=DB19CDB2

upg1.target_pdb_name.DBR18PDB=Former18pdb

upg1.target_pdb_copy_option.DBR18PDB=file_name_convert=NONE

upg1.start_time=+60m

upg1.close_source=NO

Wie gehabt analyze und fixup



Der Deploy, die PDB wird per DB Link kopiert.

Die Meldung das die Migration in einer Stunde startet ,,


Die Refreshs werden in der alter log gemeldet

Dann beginnt der Upgrade Prozess

Es folgen die Postfxups


Beide Instanzen laufen weiterhin




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

Statt DBR18PDB lautet der PDB Name Former18pdb, der Service Name hat sich folglich auch geändert: former18pdb.darkwing.net statt dbr18pdb.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('dbr18pdb.darkwing.net',\

'dbr18pdb.darkwing.net');

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

alter pluggable database former18pdb save state;

Man sieht, der alter Service ist wieder verfügbar.




Diese Vorgehensweise deckt also alle Anforderungen ab;

  • Die 18er Datenbank bleibt erhalten

  • Es liegt eine produktionsidentische Testdatenbank vor

  • Das Downtime Fenster wird nicht durch das Kopieren der Datenbank verlängert



Weiter geht's im nächsten Blog:

Migration einer 19er non PDB in eine 19er PDB.

 
















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

 





Comments

bottom of page