Die Aufgabe:
Eine Oracle 11g R2 Datenbank, in unseren Falls mit der SID VDS, auf einem 2008 Server soll auf einen neuen Windows 2012 R2 Server und zusätzlich als Container in eine Oracle 12c PDB umziehen.
Im ersten Schritt muss eine 12c Datenbank Software Umgebung auf dem neuen Windows Server aufgesetzt werden.
Laut 12c Upgrade Dokumentation kann von folgenden Versionen direkt auf 12c ein Upgrade durchgeführt werden:
Bei allen anderen Versionen kommt nur ein Export/Import der Daten oder ein Upgrade auf eine unterstützte Version in Frage.
Bei uns liegt eine Oracle Database 11g Release 2 11.2.0.4 vor, daher kann der Upgrade direkt erfolgen.
Aber immer daran denken das ZUVOR das preUpgrade Script der Version 12c auf der 11g Datenbank gelaufen sein muss und das alle Ergebnisse aus dem Test auch umgesetzt worden sind!
In der neuen Umgebung wird die Produktion Datenbank geklont und auf 12c ein Upgrade durchgeführt.
Diese 12c Datenbank wird dann als eine Plugable Database Container in eine CDB Datenbank eingefügt.
Dazu muss allerdings zuvor eine neue CDB Datenbank erzeugt werden, in diese wird dann die VDS Datenbank als PDB Container eingefügt.
Auch sind folgende Schritte vor einem Upgrade sehr zu empfehlen:
Vor einem Server Umzug prüfen und aufräumen:
Nach dem Umzug
Voraussetzung: MS Windows 2012 installiert und in der Domain aufgenommen, Admin Passwort bekannt
D.h. in einem Tage kann ein erster Testumzug erfolgen.
Bei guter Planung und mit RMan Duplicate bzw. Verwendung eines Backups kann mit einer minimalen Downtime für die Applikation von ca. 1h für den Live Umzug (nach eine paar Übungsläufen und etwas Skripting!) gerechnet werden.
Natürlich ohne die Zeit, die die Applikation selber für einen Konsistenten Stop und dem erneuten Start benötigt!
In ganz kritischen Fällen können auch Umzugszeiten von unter 30 Minuten erreicht werden, dann muss aber entsprechende Performance für den DB Upgrade (CPU /I/O) zur Verfügung stehen und zuvor einiges an der Quell DB optimiert werden (OLAP und weitere nicht benötigte Optionen löschen, DB Console löschen, Statistiken optimieren etc.).
Auch sollte dann der komplette Umzug per Skript erfolgen, d.h. der Vorbereitungsaufwand steigt entsprechend an.
Für die Datenbank Software Installation werden min. 6 GB benötigt, würde aber wenigstens 12GB für das Oracle Home einplanen um später auch einfacher einen Patch einzuspielen!
Oracle Datenbank Software:
p21821214_121020_MSWIN-x86-64.zip 471.4 MB (494280638 bytes) SHA-1 8239C7C198353EEC4C5ED0EFD4AB2597CA9249BA MD5 0EE5EE8635985AD90EE0D9B622C204DD
Darauf achten das nach dem Download auch der Hash der Datei auch stimmt!
MS Windows:
Um unnötigen Bugs und ähnlichen Wirrungen der Softwareentwicklung aus den Weg zu gehen, eine Englische Version des Betriebssystems wählen und Usernamen mit „einfachen“ Buchstaben (ohne Umlaute etc.!) und Verzeichnisse immer ohne „ “ Leerzeichen angeben!
Die Virtuelle Platte (VHD) des Windows 2012 R2 Servers kann auch mit einer VMWare Workstation 11 genützt werden.
Dazu VHD herunterladen und in ein Verzeichnis kopieren.
Unter VMWare einen neue Virtuelle Maschine mit 4GB RAM anlegen und dabei als IDE Platte die VHD Datei angeben.
Zusätzlich eine D Platte für die Oracle Datenbank Software und die Test Datenbank anlegen. Für die Software 10GB einplanen + die eigentlichen Datenbank Daten, in meinen Fall nochmals 40GB.
Bei ersten Start die Sprache der Maschine auswählen (alles US) und DE für die Tastatur wählen.
Passwort für den Administrator Account setzen und an der Maschine anmelden.
Die D Platte wie gewohnt einrichten, um die D Platte aber auch als d: verwenden zu können muss das DVD Laufwerk auf einen anderen Buchstaben gemappt werden. Das geht am einfachsten wie gewohnt im alten Server Manager, diesen mit „compmgmt.msc“ aufrufen, im neuen Server Manager leider diese Funktion nicht wie gewohnt gefunden.
Danach die die VMWare Tools installieren und neu starten (an die neue Funktion mit der rechten untern Ecke und dem Zahnrad denken um die Power Button von Windows 2012 zu erreichen).
Neuen Maschinenname vergeben (wie 12CWIN2012ORA01) und in die Domain aufnehmen, nach der Installation sollte der Name und die Domain sich NIE mehr ändern! (Neuer Server Manager ⇒ Local Server ⇒ Computer Name anklicken, gewohnten Dialog ausfüllen)
Das Netzwerk konfigurieren und wenn nicht unbedingt benötigt IPV6 so weit wie möglich deaktivieren.
Administrative Powershell Session starten cd $ENV:systemroot\system32\drivers\etc notepad .\hosts
cmd reg add hklm\system\currentcontrolset\services\tcpip6\parameters /v DisabledComponents /t REG_DWORD /d 0xFFFFFFFF
Laut Microsoft ist das abschalten von IPV6 keine so gute Idee mehr! In einer Single DB Umgebung kann auch darauf verzichtet werden bzw. vorher gut in das Thema einlesen!
Oracle Software Owner zum Beispiel ORASYSTEM als User in der Domaine (oder eben dann lokal) anlegen und in die lokale Admin Gruppe auf dem Server explizit mitaufnehmen! (auch hier am einfachsten erst mal wieder mit „compmgmt.msc“ bzw. „lusrmgr.msc“ arbeiten! )
Vergeben der Local Security Policies für diesen User über Server Manager, Tools in der oberen Bar → Local Security Policy auswählen
Knoten Local Policies → User Rights Assignment
Dem Account ORASYSTEM die folgenden Policies (Richtlinien) zuweisen:
Single Instance
RAC
Prüfen das sich der Oracle Software Owner selber die Laufwerke der Maschine mit „net“ mounten kann:
net use \\localhost\c$ net use \\localhost\d$ The command completed successfully.
Auf C: und D: einen Ordner TEMP erstellen und systemweit diesen kurzen Pfad d:\temp für TMP und TEMP setzen (Umgebungseinstellungen für den User und das System anpassen!)
Aufruf „Advanced System Settings“ ( Control Panel\System and Security\System\Advanced System Settings ) oder einfach über die Suche eingeben und suchen lassen Reiter Advanced:
Internet Explorer Security ausschalten, falls lokal mit der DB Console gearbeitet werden soll Server Manager starten, Local Server anwählen, auf der rechten Seite unter Windows Error Reporting! siehe auch http://blog.blksthl.com/2012/11/28/how-to-disable-ie-enhanced-security-in-windows-server-2012/
Daher alternativ Firefox oder Chrome installieren und sich nicht mit dem Mist ärgern .-).
Bildschirmschoner auf „Blank“ stellen bzw. deaktivieren (Control Panel\Appearance\Display)
Region and Language (English US)
Control Panel → Clock, Language, and Region →Region
Welcome Screen and new user account settings Hacken setzen bei:
Listener Port 1521 mit hinzufügen
Während der Installation, besonders bei einem Real Application Cluster, sollte der Virenscanner am besten deinstalliert sein! Läuft das System kann der Virenscanner wieder installiert werden, sollte aber möglichst nicht permanent die Filesystem scannen und so einschränkt wie möglich konfiguriert werden!
Zeitzone einstellen (Control Panel/time/date and time)
siehe NTP Service MS Windows 2008 / 2012 auf einen eigenen NTP Server konfigurieren
Auf letzte Updates prüfen und diese einspielen. (Control Panel\Updates)
Abschließen die Maschine herunterfahren, Offline Snapshot ziehen (als Basis für weitere Maschinen) und neu starten.
Software herunterladen und zum Beispiel unter d:\tools installieren
Ist die Windows Maschine gut vorbereitet, ist die eigentliche Installation trivial.
Die Installationspakete auf der Maschine auspacken und installieren. Bei der Installation wird noch ein eigener OS User für den Datenbank Service angelegt.
Benötigter Plattenplatz: 6.07 GB (6,525,054,976 bytes)
Im ersten Schritt aber keine Datenbank bei der Installation anlegen!
Ablauf:
Verzeichnis d:\install anlegen
Dort die Datenbank Software kopieren, md5 Hash prüfen:
Get-FileHash .\p17694377_121020_MSWIN-x86-64_1of8.zip -Algorithm MD5 Algorithm Hash --------- ---- MD5 BFD76313558670D78773816BEEE62DD8 Get-FileHash .\p17694377_121020_MSWIN-x86-64_2of8.zip -Algorithm MD5 Algorithm Hash --------- ---- MD5 BD6C1C3B4452402A1339E428E9BBA353 Get-FileHash .\p21821214_121020_MSWIN-x86-64.zip -Algorithm MD5 Algorithm Hash --------- ---- MD5 0EE5EE8635985AD90EE0D9B622C204DD
Wenn der Hash jeweils stimmt (mit dem zuvor gemerkten Wert auf der jeweiligen Download Seite vergleichen!) auspacken der beiden 1 und 2 Archive nach d:\install\database.
Nach dem Auspacken die Zip Files löschen um Plattenplatz zu sparen.
Setup.exe als Administrator starten (rechte MausTaste, „run as Administrator“ wählen
Die Software ist nun installiert und ein neuer User unter dem später die DB Prozesse laufen wurde angelegt.
Nun im Anschluss gleich den aktuellen Patch einspielen.
Aktuell letzten Patch auf der Produktiven DB einspielen (Stand 03.01.2017 Patch 24922906: WINDOWS DB BUNDLE PATCH 12.1.0.2.161118 , p24922906_121020_MSWIN-x86-64.zip) und den letzen OPatch p6880880_121010_MSWIN-x86-64.zip
Stand 04.2019: :
Nach der Software Installation muss der Oracle Listener eingerichtet werden.
Apps Seite von Windows 2012 starten (Windows Symbol unten rechts, auf Start Seite Pfeil nach unten anwählen).
Von der App Seite den Net Configuration Wizard als Administrator starten
Nun in eine Command Shell prüfen ob der Listener bereits erfolgreich läuft.
lsnrctl status
Meine OraPowerShell Scripte dienen dazu die DB Umgebung über die PowerShell zu verwalten und zu sichern.
Auch ist eine Library von wichtigen SQL Skripten enthalten um die DB einfach per SQL*Plus zu steuern und zu verwalten.
Die wichtigste Funktion ist das jeweilige Setzen der Umgebung mit „setdb“ um immer die richtigen Umgebungsvariablen gesetzt zu haben.
PreUpgrade Script von der neuen Umgebung in die alten Umgebung kopieren und dort ausführen.
In meine Fall die Datei „preupgrd.sql“ und „utluppkg.sql“ aus den neuen Server Oracle Home D:\oracle\product\12.1.0.2\dbhome_1\RDBMS\ADMIN\ auf den alten Server kopieren, z.B. nach d:\temp\upgrade.
Das Script in der 11g Umgebung starten:
cd d:\temp\upgrade sqlplus / AS sysdba @preupgrd.sql ... ACTIONS REQUIRED: 1. Review results OF the pre-upgrade checks: D:\oracle\cfgtoollogs\VDS\preupgrade\preupgrade.log 2. EXECUTE IN the SOURCE environment BEFORE upgrade: D:\oracle\cfgtoollogs\VDS\preupgrade\preupgrade_fixups.sql 3. EXECUTE IN the NEW environment AFTER upgrade: D:\oracle\cfgtoollogs\VDS\preupgrade\postupgrade_fixups.sql ...
Das zeugte Logfile öffnen und die Einträge prüfen und befolgen
Zum Beispiel:
EXECUTE dbms_stats.gather_dictionary_stats; EXECUTE dbms_stats.gather_dictionary_stats;
@D:\oracle\cfgtoollogs\VDS\preupgrade\preupgrade_fixups.sql
Im ersten Schritte wird die Datenbank 1zu1 im die neuen Umgebung kopiert, entweder als Klone der Produktion um die Downtime minimal zu gestalten oder einfach als eine Kopie der Produktion, falls diese lang genug gestoppt werden kann.
Vorbereitung für einen RMAN Klon:
Nach dem Vorbereitungen:
Mit „RMAN Duplicate“ die bestehende 11g Datenbank aus der Live Umgebung klonen, siehe dazu die folgende Anleitung Eine Oracle Datenbank 11g R2 mit RMAN "DUPLICATE TARGET DATABASE TO xxxx FROM ACTIVE DATABASE " klonen
Letzte Archive vor der Downtime der produktiven Umgebung holen und alte Produktion stoppen.
Letzte Archive in die neue Datenbank einspielen und danach die Datenbank im Upgrade Modus öffnen.
Unsere Datenbank heißt in unseren Beispiel „VDS“
Da es Probleme mit dem Rman Duplicate gab, die Quell Datenbank herunterfahren und die Dateien per Hand kopieren.
Vom neuen Datenbank Server aus die Datendateien als Oracle Software Owner kopieren, sonst muss zweimal an den Rechten herum geschraubt werden!
Struktur der DB prüfen:
rman rman>CONNECT target / rman>report schema; .. # Gute übersicht über die Struktur der Datenbank! ..
Aus dem alten Oracle Home aus dem Verzeichnis „database“ spfilevds.ora und pwdvds.ora in die neue Umgebung in das neue Oracle Home in das Verzeichnis „database“ kopieren.
Die Verzeichnisstruktur der Datenbank inkl. Inhalt 1zu1 auf den neuen Server kopieren (inklusive der fast_recovery_area).
Meine Struktur sieht dann so aus:
Als neuen Eigentümer der Daten Verzeichnisse und der Dateninhalte den ORARUN User definieren, den spfile und die password Datei unter $ENV:ORACLE_HOME nicht vergessen!
Eine Administrative PowerShell öffnen und den DB Service anlegen:
$env:ORACLE_HOME="D:\oracle\product\12.1.0.2\dbhome_1" cd $env:ORACLE_HOME\bin oradim -new -sid VDS Enter password for Oracle service user: Instance created.
Tritt ein „O/S-Error: (OS 5) Access is denied.“ Fehler auf, prüfe ob wirklich eine administrative PowerShell Session gestartet wurde!
Auf der original Datendatenbank:
Kopieren das Full Backups + Archivelog Backup + Auto Backup + Controlfile Backup in die gleiche Verzeichnisstruktur auf den neuen Server wie in der alten Umgebung.
Nun die Datenbank in der alten Umgebung wieder herstellen.
rman>restore controlfile FROM autobackup; # alternativ rman>restore controlfile FROM ’f:\backup\name…..’ --hier das aktuellste controlfile nach dem backup nehmen
rman>ALTER DATABASE mount;
rman>crosscheck backup; rman>DELETE expired backup;
rman>catalog START WITH ’f:\backup’;
restore DATABASE
recover DATABASE
ALTER DATABASE OPEN resetlogs migrate;
$ENV:ORACLE_SID="VDS" sqlplus / as sysdba startup upgrade exit
Zur Überwachung des Alert Logs der DB diese mit einem Tail in zweiten Fenster anzeigen lassen:
adrci adrci> show homes ADR Homes: diag\rdbms\vds\vds diag\tnslsnr\12CWIN2012ORA01\listener adrci> set home diag\rdbms\vds\vds adrci> show alert -tail -f ... Completed: ALTER DATABASE OPEN MIGRATE ...
Nach dem Klone die Datenbank auf 12 mit dem neuen Perl Script „perl catctl.pl catupgrd.sql“ upgraden.
Für das Loging den Ordner d:\temp\upgtrade anlegen.
Gibt es die Hardware etwas her kann mit dem Schalter „-n“ die Parallelität beim Upgrade gesetzt werden. Auch sollte ein Log File Directory mit -l definiert werden, sonst landen die Logs alle im rdbms/Admin Verzeichnis!
Aufruf:
cd $ENV:ORACLE_HOME\rdbms\admin #am einfachsten dann mit dem kompletten Pfad aufrufen #Optionen anzeigen lassen und prüfen ob der Aufruf auch klappt D:\oracle\product\12.1.0.2\dbhome_1\perl\bin\perl catctl.pl -h #Upgrade starten D:\oracle\product\12.1.0.2\dbhome_1\perl\bin\perl catctl.pl -n 4 -l d:\temp\upgrade catupgrd.sql ... Number of Cpus = 2 SQL Process Count = 4 ------------------------------------------------------ Phases [0-73] Serial Phase #: 0 Files: 1 Time: 241s Serial Phase #: 1 Files: 5 Time: 66s Restart Phase #: 2 Files: 1 Time: 0s ... Time: 113s Serial Phase #:70 Files: 1 Time: 816s Serial Phase #:71 Files: 1 Time: 1s Serial Phase #:72 Files: 1 Time: 0s Serial Phase #:73 Files: 1 Time: 22s Grand Total Time: 6321s LOG FILES: (catupgrd*.log) Upgrade Summary Report Located in: D:\oracle\product\12.1.0.2\dbhome_1\cfgtoollogs\VDS\upgrade\upg_summary.log Grand Total Upgrade Time: [0d:1h:45m:21s]
Warum hat das bei mir so lange gedauert? Mit 45 bis 55 Minuten sollte man schon rechnen, hier war es aber sehr langsam. Das lag zum einem daran das es sich um eine VM Umgebung handelt, zum anderen kam es zu timeout, die kopierte DB ist normalerweise Teil eines Oracle Standby Verbandes, das hätte ich zuvor auflösen müssen. Auch habe ich zuvor die DB Console und OLAP eben nicht gelöscht, das kostet dann später eben unnötig Zeit.
Über das Tail im zweiten Fenster mit adrci kann nun gut der Fortschritt beobachtet werden.
Auch kann über ein PowerShell Tail das Logfile beobachtet werden:
Get-Content -Path "catupgrd0.log" -Wait .....
Allerdings werden soviel Log Daten erzeugt, das die Console mit dem Spool nicht mehr nachkommt und dann am Ende über 15 Minuten hinter dem Ende des Logfiles der Spool erzeugt wurde, ist also nicht in Echtzeit.
Nach dem Durchlaufen des catctl.pl die Datenbank starten und prüfen:
cd $ENV:ORACLE_HOME\rdbms\admin sqlplus / as sysdba startup @utlu121s.sql -- if use 19c!! @utlusts.sql TEXT -- Oracle Database 12.1 Post-Upgrade Status Tool 11-28-2015 15:50:34 Component Current Version Elapsed Time Name Status Number HH:MM:SS Oracle Server UPGRADED 12.1.0.2.0 00:18:56 JServer JAVA Virtual Machine VALID 12.1.0.2.0 00:06:27 Oracle Workspace Manager VALID 12.1.0.2.0 00:01:23 OLAP Analytic Workspace VALID 12.1.0.2.0 00:00:28 Oracle OLAP API VALID 12.1.0.2.0 00:00:32 Oracle XDK VALID 12.1.0.2.0 00:01:04 Oracle Text VALID 12.1.0.2.0 00:01:20 Oracle XML Database VALID 12.1.0.2.0 00:02:56 Oracle Database Java Packages VALID 12.1.0.2.0 00:00:21 Oracle Multimedia VALID 12.1.0.2.0 00:03:40 Spatial UPGRADED 12.1.0.2.0 00:08:36 Oracle Application Express VALID 4.2.5.00.08 00:38:31 Final Actions 00:02:58 Post Upgrade 00:12:54 Total Upgrade Time: 01:41:03
Sieht alles gut aus!
Das auf der alten Umgebung unter cfgtools das erzeugte Post Upgarde SQL auf den neuen Server nach d:\temp kopieren.
Post FixUp Script vom 11g Server aufrufen:
sqlplus / AS sysdba --Falls noch nicht gestartet startup @d:\temp\postupgrade_fixups.sql EXECUTE DBMS_STATS.gather_fixed_objects_stats; -- Recompile @?\rdbms\admin\utlrp.sql --check -- 12c @?\rdbms\admin\utluiobj.sql @?\rdbms\admin\utlu121s.sql -- if use 19c!! @?\rdbms\admin\utlusts.sql TEXT --
Die Empfehlungen beachten und dann auch befolgen.
Ist die Apex Option plötzlich ungültig, diese als SYS validieren und reparieren
SET serveroutput ON EXEC validate_apex;
In meine Fall haben Rechte gefehlt:
GRANT INHERIT ANY PRIVILEGES TO "APEX_050000"; EXEC validate_apex;
SET LINESIZE 400 SET PAGESIZE 100 COLUMN action_time FORMAT A20 COLUMN action FORMAT A10 COLUMN STATUS FORMAT A10 COLUMN description FORMAT A40 COLUMN version FORMAT A10 COLUMN bundle_series FORMAT A10 -- SELECT to_char(action_time, 'DD-MON-YYYY HH24:MI:SS') AS action_time , action , STATUS , description , traget_version , patch_id , traget_bundle_series FROM sys.dba_registry_sqlpatch ORDER BY action_time;
⇒ https://mikedietrichde.com/2016/11/30/dba_registry_history-vs-dba_registry_sqlpatch/
Läuft alles wie erwartet, kann nun zum Schluss der Compatible Parameter auf 12c gesetzt werden.
Achtung! Ist das esetzt gibt es kein Zurück mehr!
sqlplus / AS sysdba SHOW parameter compatible NAME TYPE VALUE ------------------------------------ ----------- ---------------- compatible string 11.2.0.4.0 --! so geht das nicht -- nach dem Start beschwert sich das System -- ORA-00723: Initialization parameter COMPATIBLE must be explicitly set -- alter system reset compatible -- ALTER system SET compatible="12.1.0.2.0" scope=spfile; startup force SHOW parameter compatible NAME TYPE VALUE ------------------------------------ ----------- --------------------- compatible string 12.1.0.2.0
siehe auch https://docs.oracle.com/database/121/NLSPG/ch4datetime.htm#NLSPG261
Status:
SELECT * FROM V$TIMEZONE_FILE; SELECT * FROM V$TIMEZONE_FILE; SELECT * FROM DATABASE_PROPERTIES WHERE property_name LIKE 'DST%’
EXECUTE DBMS_DST.BEGIN_UPGRADE(18) --# 19c 32
TRUNCATE TABLE sys.dst$error_table; TRUNCATE TABLE sys.dst$trigger_table;
SET serveroutput ON VAR numfail NUMBER BEGIN DBMS_DST.UPGRADE_DATABASE(:numfail, parallel => TRUE, log_errors => TRUE, log_errors_table => 'SYS.DST$ERROR_TABLE', log_triggers_table => 'SYS.DST$TRIGGER_TABLE', error_on_overlap_time => TRUE, error_on_nonexisting_time => TRUE); DBMS_OUTPUT.PUT_LINE('Failures:'|| :numfail); END; /
SELECT * FROM DBA_TSTZ_TABLES; SELECT * FROM SYS.DST$ERROR_TABLE; SELECT * FROM sys.dst$trigger_table;
VAR numfail NUMBER EXEC DBMS_DST.END_UPGRADE(:numfail); print
In unseren Fall wird die Datenbank ja auch auf einen anderen Server umgezogen, daher in der alten Datenbank die Datenbank Directories prüfen und auf den neuen Zielsystem die gleiche File Struktur anlegen und auf die Rechte für die Oracle „Run“ User achten (siehe Software Installation)!
Besonders für die Performance Überwachung sehr hilfreich (Nur wenn die Tuning/Diagnostic Pack Lizenz auch erworben wurde, nützen!)
Backup nach Bedarf einrichten und erstes Backup der neuen Umgebung erstellen. siehe auch Was muss alles gesichert werden
Den Datenbank Service auf „Automatic“ setzen und die Autostart Einstellungen kontrollieren, siehe auch Start der Oracle Instance unter Windows.
Den Patch hätten wir schon vor dem DB Upgrade mit der Software Installation einspielen können, jetzt benötigen wir wieder eine Downtime und müssen zusätzlich die Datenbank patchen.
Unter Windows ist es sehr wichtig das auch wirklich alles aus zu patchenden Oracle Home beendet ist.
Daher zuvor mit dem Process Explorer von SysInternals immer prüfen ob nicht doch noch etwas das Oracle Home verwendet nach dem der Listener und die Datenbank gestoppt wurden!
Ablauf:
cd D:\temp\p21821214_121020_MSWIN-x86-64-Patch10Nov2015\21821214 set ORACLE_HOME=d:\oracle\product\12.1.0.2\dbhome_1 %ORACLE_HOME%\opatch apply .. (Oracle Home = 'D:\oracle\product\12.1.0.2\dbhome_1') Is the local system ready for patching? [y|n] y ...
#SID und Umgebung setzen cd $ENV:ORACLE_HOME\OPatch .\datapatch -verbose ... Connecting to database...OK Bootstrapping registry and package to current versions...done Determining current state...done ... The following patches will be applied: 21821214 (WINDOWS DB BUNDLE PATCH 12.1.0.2.10(64bit):21821214) Installing patches... Patch installation complete. Total patches installed: 1 Validating logfiles... Patch 21821214 apply: SUCCESS ...
Damit ist die Datenbank auf dem neuesten Stand, Alert.log prüfen.
Prüfen ob noch Windows Updates ausstehen und dann das Sytem neu starten.
Läuft alles wie geplant nach dem Neustart und sind die Logs fehlerfrei kann die die Applikation hinter der Datenbank wieder gestartet werden.
Läuft alles wie geplant, kann das Feintuning der Applikation beginnen.
Zuerst neue Statistiken erzeugen dann alle SQL Profile löschen und dann heißt es die Applikation gut im Auge zu behalten und neu zu tunen!
Statistiken optimieren:
siehe dazu ⇒ Statistiken anlegen und überwachen
Da die 12c sich ganz anders verhält, empfiehlt es sich alle DB SQL Profile zu sichern und dann zu löschen.
Siehe dazu ⇒ Mit Oracle SQL Profilen arbeiten und SQL Profile zwischen Datenbanken austauschen
Jetzt die Applikation sorgfältig überwachen und schnell reagieren wenn Problem mit Ausführungsplänen auftauchen.
Belastet das die Produktion zu sehr, kann das natürlich zuvor alles in der TEST Umgebung zuvor erzeugt und dann per Export/Import in Prod eingespielt werden.
Nach dem Upgrade der Datenbank muss die Applikation auf Ihre Tauglichkeit bzgl. 12c im Detail geprüft und analysiert werden.
Sehr hilfreich ist hier ein Protokolls zur Überwachung von fehlerhaften SQL Statements in der Datenbank.
Eine Problem kann ein „set Role“ mit Password sein, in der verwendeten Software wird eine Rolle über Passwort aktiviert.
Damit das wieder funktioniert muss das Password auf der Rolle einfach erneut in der 12c Umgebung gesetzt werden und dann funktioniert es wieder!
Im nächsten Schritt kann dann aus der Singe Database Umgebung eine Plugable Database Umgebung entstehen.
Vorbereitung:
Ablauf:
siehe auch https://oracle-base.com/articles/12c/multitenant-migrate-non-cdb-to-pdb-12cr1
Soll das System wieder umgebaut/abgebaut werden ohne Neuinstallation von Windows sind die folgenden Schritte notwendig:
$ENV:ORACLE_HOME\deinstall\deinstall.bat
sc delete OracleRemExecServiceV2
Blogs:
Oracle Dokumentation
Ein paar Tipps für die Windows Konfiguration