Inhaltsverzeichnis
Umstellen auf Oracle 19c - Upgrade einer Oracle Single Instance Datenbank 18c auf Oracle 19c unter MS Server 2019
Erstellt 2019/09/
Mit Oracle 12c R2 / 18c / 19c ändert sich auch leicht der Upgrade Prozess von älteren DB Versionen inkl. der 12c R1.
- Bzgl mehr Informationen zu Update auf 12c R1 siehe auch ⇒ Eine Oracle Datenbank 11g R2 auf eine neue Oracle 12c Datenbank Umgebung unter Windows 2012 R2 umziehen
- Für den Upgrade von 12c R2 auf 18c siehe auch ⇒ Umstellen auf Oracle 18c - Upgrade einer Oracle Single Instance Datenbank 12c R2 auf Oracle 18
Hier ein paar Anmerkungen zum generellen Ablauf mit Hilfe der „preupgrade.jar“ und „dbupgrade.cmd“ Tools beim Upgrade von Oracle 18 auf Oracle 19.
Ablauf
Genereller schematischer Ablauf:
- Password vom lokalen ORARUN User auf dem System heraussuchen
- DB Software in ein neues Oracle Home entpacken und Oracle Home mit Setup Programm initialisieren
- Neues DB Home mit letzten DB Patch patchen
- DB auf ungültige Objekte kontrollieren und diese möglichst aufräumen
- Pre Upgrade Scripte auf der DB in der 18c Umgebung laufen lassen und Anweisungen ausführen, DB für den Upgrade aufräumen/optimieren
- Vor dem Upgrade darauf achten das alle Materialized Views refreshed sind, Jobs dazu stoppen!
- siehe Doc ID 1406586.1 - How to Handle Materialized Views When You Upgrade or Clone a Database
- siehe Doc ID 2440801.1 - After DB Upgrade, One More Entry(COLLECTION_LEVEL=TYPICAL) is Added into DBA_MVREF_STATS_SYS_DEFAULTS View. 18c
- DB im alten Home Stoppen
- DB Service im neuen Home anlegen
- DB Upgrade im neuen Home durchführen
- Alle DB Scripte wie Backup / ETL Jobs etc. auf neues DB Home anpassen
- Prüfen ob alle Anwender sich anmelden können, SYS AS SYSDBA über SQL*Net testen
- Prüfen ob das ADRCI migriert werden muss
- Zeitzone Definition bei Bedarf aktualisieren
Installation Software 19c
Es sollten noch mindestens 7 GB Platz für die Software Installation zur Verfügung stehen.
Ein 4k Display wird nicht unterstützt, hier hilft dann nur die Windows Lupe zu verwenden, oder versuchen die DPI Eigenschaften unter „Compatible“ anzupassen.
Seit der 18c wird das Oracle Home der Datenbank Software komplett kopiert als ZIP File mitgeliefert und die Software wird in das gewünschten Verzeichnis einfach ausgepackt.
Usernamen vom ORARUN User heraussuchen!
Das Setup Programm konfiguriert dann dieses ORACLE_HOME Verzeichnis.
Ablauf:
- Download der Software Oracle Database 19c (19.3) for Microsoft Windows x64 (64-bit) über das Edelivery Portal ⇒ https://edelivery.oracle.com/ oder https://www.oracle.com/database/technologies/oracle19c-windows-downloads.html
- Prüfen der Checksum
-- (3,105,763,999 bytes) (sha256sum - 64d92018207829833bd4d00f1a7fb40c531c8a4a68ded9e430a5d6fbaedaca95) Get-FileHash .\WINDOWS.X64_180000_db_home\ -Algorithm SHA256 Algorithm Hash --------- ---- SHA256 64D92018207829833BD4D00F1A7FB40C531C8A4A68DED9E430A5D6FBAEDACA95
- Auspacken der Datei WINDOWS.X64_193000_db_home.zip mit der Oracle 19c Software in eine neues Oracle Home wie „C:\oracle\products\19.3.0.0\dbhome_1“
mkdir C:\oracle\products\19.3.0.0\dbhome_1 expand-archive -path 'D:\install\oracle\database\19c\WINDOWS.X64_193000_db_home.zip' -destinationpath 'C:\oracle\products\19.3.0.0.0\dbhome_1'
- Öffnen einer administrativen Powershell Session und starten der setup.bat Datei im Oracle Home Verzeichnis
cd C:\oracle\products\19.3.0.0\dbhome_1 .\setup.bat
Install Wizard Ablauf:
- „Software only“ Auswahl
- Single Instance
- EE oder SE Edition auswählen
- Bestehenden Oracle Run User verwenden!
- Auf das richtiges Oracle Base Verzeichnis achten, in meinen Fall „C:\oracle“
- Mit Install abschließen, die Software in dem Home wird nun konfiguriert
Nach der Software Installation wird geprüft ob ein aktueller Patch für die 19c unter Windows schon zur Verfügung steht.
Siehe dazu Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases (Doc ID 2118136.2)
Für die 19.3 ist aber noch kein RU oder gar ein RUR verfügbar ( 08.2019) , bzw. bei Windows ist das ja dann immer noch ein Bundle Patch.
Hier ein paar Link zur Oracle Release Strategie ⇒Eleanor Meritt - Oracle Open World 2017 https://static.rainfocus.com/oracle/oow17/sess/1496886539973001Z80G/PF/CON6550-NewReleaseModelForOracleDatabase-v9_1506958121732001IJYT.pptx und https://mikedietrichde.com/2017/10/24/differences-psu-bp-ru-rur/
Patch 30445947: WINDOWS DATABASE BUNDLE PATCH 19.6.0.0.200115 und OVJM 30484981, nun wie gewohnt mit Apply einspielen.
Daher die Datei $ORACLE_HOME\rdbms\admin\rdbms_postapply.sql so anpassen das der Aufruf auskommentiert ist und hoffen das das nichts wichtiges ist.
Upgarde bei Bedarf auf Zeitzone File 36
Upgrade der Datenbank
Zuvor immer das Backup der bestehenden Datenbank sicherstellen!
Darauf achten das keine „alten“ ungültigen SYS Objekte in der Datenbank mehr vorliegen! Test mit ⇒ https://github.com/gpipperr/OraPowerShell/blob/master/Ora_SQLPlus_SQLcL_sql_scripts/invalid.sql
wie X_$KGLOB:
- siehe dazu auch die Node „Invalid x_$ Objects After Upgrade (Doc ID 361757.1)
Prüfen ob das Local Temporay Tablepace = SYSTEM Problem auftritt ⇒ Ab Oracle 12c User Eigenschaft "Local Temp_Tablespace" - Upgade Fehler "local_temp_tablespace=SYSTEM" - Import Fehler ORA-12911: permanent tablespace cannot be temporary tablespace
PreCheck durchführen
Das kann alles noch im laufenden Betrieb der Umgebung vorbereitet werden.
Check der bestehenden Datenbank mit dem preupgrade.jar und erzeugen des Fixup Scripts:
# Darauf achten das noch die SID und ORACLE_HOME des ALTEN Homes in der Umgebung gesetzt sind! # Falls kein Java installiert, das der DB "ausleihen" $ORACLE_HOME/jdk/bin/java.exe cd C:\oracle\products\18.3.0.0\dbhome_1 .\jdk\bin\java.exe -jar .\rdbms\admin\preupgrade.jar TERMINAL TEXT ... ================== PREUPGRADE SUMMARY ================== C:\oracle\cfgtoollogs\GPI\preupgrade\preupgrade.log C:\oracle\cfgtoollogs\GPI\preupgrade\preupgrade_fixups.sql C:\oracle\cfgtoollogs\GPI\preupgrade\postupgrade_fixups.sql
Die erzeugten Aussgaben in C:\oracle\cfgtoollogs\GPI\preupgrade\preupgrade.log sorgfältig lesen und möglichst befolgen!
Zusätzlich werden die PreUpgrade und PostUpgrade SQL Scripte erzeugt.
Das preupgrade_fixups.sql MUSS zuvor in der alten DB Umgebung auf der zu migrierenden Datenbank aufgerufen werden!
PreCheck Script ausführen
PreUpgrade Script auf in der „alten“ DB Umgebung als sys ausführen
sqlplus / AS sysdba @C:\oracle\cfgtoollogs\GPI\preupgrade\preupgrade_fixups.sql
Anweisungen befolgen wie DB Statistik neu anlegen!
EXECUTE DBMS_STATS.GATHER_DICTIONARY_STATS;
Hidden obsolete Parameter reseten, Bespiel:
ALTER SYSTEM RESET "_some_hidden_parameter" scope = spfile;
Streams Konfiguration bei Bedarf entfernen ( z.B. falls früher eine Standby konfig im Einsatz)
EXEC DBMS_STREAMS_ADM.REMOVE_STREAMS_CONFIGURATION
Siehe ⇒ https://docs.oracle.com/database/121/STREP/best_gen.htm#STREP514
Besonderers darauf achten das in Passwörter der DB user die NUR in der Version 10g vorliegen, neu gesetzt werden!
SELECT password_versions,username FROM dba_users WHERE password_versions LIKE '%10G%';
Nach dem Upgrade können sich die User mit NUR 10g PWD nicht mehr an der DB 19c anmelden!
DB Umzug
Password vom ORARUN User heraussuchen! Wird dann später am Anlegen des DB und des Listener Service auf jeden Fall benötigt!
Init.ora und Password Datei in die neue Umgebung nach $ORACLE_HOME\database kopieren
- listener.ora / tnsnames.ora / sqlnet.ora in das neue Home nach $ORACLE_HOME\network\admin kopieren
- Pfade in der Listener.ora anpassen!
Datenbank im alten Home stoppen
- Datenbank mit shutdown immediate herunterfahren
- Alle Oracle Dienste beenden
DB Service im alten Home löschen
Als Administrative Session!
$env:ORACLE_HOME="C:\oracle\products\18.3.0.0\dbhome_1" cd $env:ORACLE_HOME\bin oradim -delete -sid GPI
Listener Service im alten Home löschen
Als Administrative Session! Auf die Dos Shell achten!
# mit SC cmd.exe sc query OracleOraDB18Home1TNSListener sc stop OracleOraDB18Home1TNSListener sc delete OracleOraDB18Home1TNSListener
Listener Service im neuen Home anlegen in dem von dort der Listener gestartet wird
Listner.ora und tnsnames.ora/sqlnet.ora aus alten Home/network/admin nach NEUES ORACLE_HOME/network/admin kopieren und anpassen
cmd als admin:
# Neues Oracle Home setzen und in das neue Oracle_Home/bin Verzeichnis wechseln! $env:ORACLE_HOME="C:\oracle\products\18.3.0.0\dbhome_1" cd $env:ORACLE_HOME\bin ./lsnrctl start
Prüfen ob der Service auch angelegt wurde und ob Autostart richtig gesetzt wurde, default ist manuell!
Problem:
Enter ORARUN's password :
TNSLSNR for 64-bit Windows: Version 19.0.0.0.0 - Production
System parameter file is C:\oracle\products\19.3.0.0\dbhome_1\network\admin\listener.ora
Log messages written to C:\oracle\diag\tnslsnr\saturn\listener\alert\log.xml
Error listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.10.10.1)(PORT=1521)))
TNS-12546: TNS:permission denied
TNS-12560: TNS:protocol adapter error
TNS-00516: Permission denied
64-bit Windows Error: 13: Permission denied
Listener failed to start. See the error message(s) above...
hmm…. Listener auf den SYSTEM User geändert, nun funktioniert es …. so sollte das aber nicht sein!
Noch keine Idee was hier falsch läuft.
DB Service im neuen Home anlegen
Pürfen das die init.ora/spfile/*.dat und pwd files vom alten Home/database in das neue Home/database kopiert wurden!
Eine Administrative PowerShell öffnen und den DB Service anlegen:
$env:ORACLE_HOME="C:\oracle\products\19.3.0.0\dbhome_1" cd $env:ORACLE_HOME\bin oradim -new -sid GPI 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!
Service kontrollieren und nach Bedarf einstellen.
Z.b. Registry prüfen „HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraDB19Home1“ ORA_VDS_AUTOSTART auf TRUE setzen, falls Autostart gewünscht.
DB im Upgrade Modus im neuen Home starten
$ENV:ORACLE_SID="GPI" 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\gpi\gpi .. adrci> set home diag\rdbms\gpi\gpi adrci> show alert -tail -f ... Completed: ALTER DATABASE OPEN MIGRATE ...
DB Upgrade mit "dbupgrade.cmd" Script durchführen
Der eigentliche Upgrade wird nun in der 19c über das Script „dbupgrade.cmd“ durchgeführt, das ruft das schon aus der 12c R1 bekannte Perl Upgrade Script auf.
Auch in sehr performanten Umgebungen lag die Laufzeit meist zwischen 40 und 60 Minuten.
$env:ORACLE_HOME="D:\oracle\product\19.3.0.0\dbhome_1" cd $env:ORACLE_HOME\bin mkdir d:\temp\19cUpgrade # pürfen ob sein sqlplus / as sysdba sich ohne Verzögerung anmeldet # sqlpath evtl. unsetten damit keine eigenen Scripte stören! # # Aufrufen: dbupgrade.cmd -n 4 -l d:\temp\19cUpgrade ...... Number of Cpus = 8 Database Name = GPI DataBase Version = 19.0.0.0.0 Parallel SQL Process Count = 4 Components in [GPI] Installed [APEX APS CATALOG CATJAVA CATPROC CONTEXT DV JAVAVM OLS ORDIM OWM SDO XDB XML XOQ] Not Installed [EM MGW ODM RAC WK] ------------------------------------------------------ Phases [0-107] Start Time:[2019_09_17 20:41:24] ------------------------------------------------------ *********** Executing Change Scripts *********** Serial Phase #:0 [GPI] Files:1 Time: 22s *************** Catalog Core SQL *************** Serial Phase #:1 [GPI] Files:5 Time: 30s Restart Phase #:2 [GPI] Files:1 Time: 3s *********** Catalog Tables and Views *********** ... ***************** Post Upgrade ***************** Serial Phase #:103 [GPI] Files:1 Time: 20s **************** Summary report **************** Serial Phase #:104 [GPI] Files:1 Time: 5s *** End PDB Application Upgrade Post-Shutdown ** Serial Phase #:105 [GPI] Files:1 Time: 6s Serial Phase #:106 [GPI] Files:1 Time: 0s Serial Phase #:107 [GPI] Files:1 Time: 44s ------------------------------------------------------ Phases [0-107] End Time:[2019_09_17 21:11:57] ------------------------------------------------------ Grand Total Time: 1834s LOG FILES: (d:\temp\19cUpgrade\catupgrd*.log) ......
Problem catcon::exec_DB_script - line does not match marker
Fehler:catcon::exec_DB_script - line does not match marker
Lösung: meine login.sql hat den Login Vorgang verzögert, das Timiming ist für das Upgarde anscheinend sehr wichtig.
Restart mit -R ⇒ https://mikedietrichde.com/2017/01/24/restarting-a-failed-database-upgrade-with-catctl-pl/
Leider klappt dann ein Restart nicht mehr, das Script behaupted, die DB sei schon upgegarded, nochmals ohne den “-R„ Schalter gestartet.
Problem apply backport_file für Bug 29766207 - bug_29766207_apply.sql
In dieser Umgebung wurde der aktuelle Patch Jan Bundle Patch 2020 vor den Upgrade eingespielt
*** WARNING: ERRORS FOUND DURING UPGRADE *** 1. Evaluate the errors found in the upgrade logs and determine the proper action. 2. Rerun the upgrade when the problem is resolved REASON: ERRORS FOUND: During Upgrade FILENAME: c:\temp\upgrade19c\catupgrd0.log AT LINE NUMBER: 811762 ------------------------------------------------------ Identifier CATPROC 20-01-27 01:21:44 SCRIPT = [C:\oracle\product\19.3.0.0\dbhome_1\rdbms\admin\rdbms_postapply.sql] ERROR = [SP2-0310: unable to open file "C:\oracle\product\19.3.0.0\dbhome_1/rdbms/admin/backport_files/bug_29766207_apply.sql"] STATEMENT = [Rem] ------------------------------------------------------
Fehler ⇒ Der Patch ändert diese Datei $ORACLE_HOME\rdbms\admin\rdbms_postapply.sql legt aber in $ORACLE_HOME\rdbms\admin\backport_files nicht die passende Datei an.
Lösung: Datei Aufruf auskommentieren und wieder mit dem “-R„ Schalter neu starten
POST Upgrade Script durchlaufen lassen
sqlplus / as sysdba startup @C:\oracle\cfgtoollogs\GPI\preupgrade\postupgrade_fixups.sql ... Executing Oracle POST-Upgrade Fixup Script Auto-Generated by: Oracle Preupgrade Script Version: 19.0.0.0.0 Build: 1 Generated on: 2019-09-17 10:38:56 For Source Database: GPI Source Database Version: 18.0.0.0.0 For Upgrade to Version: 19.3.0.0.0 Preup Preupgrade Action Issue Is Number Preupgrade Check Name Remedied Further DBA Action ------ ------------------------ ---------- -------------------------------- 10. depend_usr_tables YES None. 11. old_time_zones_exist NO Manual fixup recommended. 12. dir_symlinks YES None. 13. post_dictionary YES None. 14. post_fixed_objects NO Informational only. Further action is optional.
Test ob alles geklappt hat mit:
@?/rdbms/admin/utlusts.sql
Auf ungültige Objekte prüfen und bei Bedarf alles neu übersetzen:
sqlplus / AS sysdba @?/rdbms/admin/utlrp
Umgebung Einstellungen / Backup Scripte auf die neue DB anpassen
Default DB Home in eigenen Scripten wie dem Backup anpassen.
NLS Lang prüfen! ( HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraDB19Home1\NLS_LANG) bei Bedarf von AMERICAN_AMERICA.WE8MSWIN1252 wieder auf GERMAN_GERMANY.WE8MSWIN1252 setzen.
Umgebung prüfen
Umgebung wie PATH prüfen das alles auf das neue Oracle Home zeigt.
Falls im Einsatz .Net Klassen umziehen
Die .Net Klassen aus dem alten Home deregistrieren und neu aus dem neuen Oracle Home registrieren.
Den .NET Framework Extension, Dienst CLR Agent auf das neue Oracle Home umziehen:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\OracleOraDB12Home1ClrAgent # ImagePath anpassen an z.B. D:\Oracle\product\19.3.0.0.0\dbhome_1\bin\OraClrAgnt.exe agent_sid=CLRExtProc max_dispatchers=5 tcp_dispatchers=3 max_task_threads=10 max_sessions=50 ENVS=\"EXTPROC_DLLS=ONLY:D:\Oracle\product\19.3.0.0.0\dbhome_1\bin\oraclr19.dll\"
Bzw. besser den alten Dienst disablen ( damit die Settings nicht verloren gehen!) und wieder neu aus dem richtigen Home anlegen, Settings vom alten Dienst dann auf den neuen über den Registry Eintrag übernehmen!
SQL*Net Connect als SYS auf die DB Prüfen
Falls der Zugriff mit SQL*Plus/TOAD über SQL*NET als „SYS as SYSDBA“ User nicht funktioniert.
Testen ob Password Datei in Verwendung ist:
SELECT * FROM v$pwfile_users; -- SYS muss dabei sein!
Password Datei neu erzeugen mit orapwd file=PWD<SID>.ora password=<password> entries=10 format=12:
orapwd file=PWDGPI.ora password=xxxxxx entries=10 format=12
DB neu durchstarten und testen
ADRCI - Interne Strukturen upgarden
Problem - ADRCI Error DIA-49803: Purge not possible due to incompatible schema version.
Nach ein paar Tagen sollen die Logfiles des Listener und der DB mit adrci aufgeräumt werden:
Das Problem: DIA-49803: Purge not possible due to incompatible schema version.
adrci> set home diag\tnslsnr\v65690\listener adrci> purge -age 0 DIA-49803: Purge not possible due to incompatible schema version.
Lösung:
Als erstes darauf achten, das auch das richtige ADRCI ( das aus dem aktuellen 19'er Home ) gestartet wird!
Danach folgende Node beachten! ⇒ siehe ADRCI Error DIA-49803 - Purge Does Not Work In 12.2 If ADRCI Is Used To Access An Older ADR Home (Doc ID 2341825.1)
Das hat mir aber dann auch nicht weitergeholfen, bei mir hat folgendes geklappt:
-- für jedes Home! show homes set home adrci> migrate schema Schema migrated. adrci> purge -age 0
Compatible Parameter umstellen
show parameter compatible NAME TYPE VALUE ------------------------------------ --------------------------------- ------------------------------ compatible string 12.1.0.2.0 ALTER system SET compatible='19.0.0' scope=spfile sid='*'; -- Optimizer Features überprüfen: show parameter OPTIMIZER_FEATURES_ENABLE -- Bei Bedarf auf den Default von 19c setzen ALTER system SET compatible='19.1.0' scope=spfile sid='*'; -- neu starten startup force
Zeitzone aktualisieren
siehe auch Support Node : Updated DST Transitions and New Time Zones in Oracle RDBMS and OJVM Time Zone File Patches (Doc ID 412160.1) für die neuesten TimeZone Updates bei Bedarf, hier die mit der 19c dabei sind eingespielt und Upgrading DST using scripts - 12.2 and above - (With Example Test Case - 19.11) (Doc ID 2794427.1)
Überprüfen - Wer verwendet Timezone Abhängige Datenbank Spalten ? :
cd $ENV:ORACLE_HOME/rdbms/admin sqlplus / AS sysdba -- Script to gives how much TIMESTAMP WITH TIME ZONE data there is in a database using stats info. @?/rdbms/admin/utltz_countstats.sql .. Amount OF TSTZ DATA USING num_rows stats info IN DBA_TABLES. .. --=> prüfen ob Spalten von der Anwendung verwendet werden ---------------------------------------------------------- -- Script to approximate how much TIMESTAMP WITH TIME ZONE data there is in a database using a COUNT(*) for each -- -- table that has a TSTZ column. This script is useful when using DBMS_DST package or the scripts of -- -- utlz_upg_check.sql and utlz_upg_apply.sql scripts. @?/rdbms/admin/utltz_countstar.sql .. Estimating amount OF TSTZ DATA USING COUNT(*). .. SYS.XS$PRIN.START_DATE - 15 Total COUNT * OF SYS TSTZ COLUMNS IS : 180747 There are IN total 162 SYS TSTZ COLUMNS. . FOR non-SYS TABLES ... Note: empty TABLES are NOT listed. ... WMSYS.WM$WORKSPACES_TABLE$.LAST_CHANGE - 1 Total COUNT * OF non-SYS TSTZ COLUMNS IS : 18936 There are IN total 60 non-SYS TSTZ COLUMNS. Total Minutes elapsed : 0 --=> prüfen ob Spalten von der Anwendung verwendet werden ----------------------------------------------------------
Theoretisch muss man sich nun Gedanken machen, ob eine Änderungen Auswirkungen auf die Applikation hat.
Überprüfen ob ein Upgrade möglich mit @?/rdbms/admin/utltz_upg_check.sql
--Time zone upgrade check script @?/rdbms/admin/utltz_upg_check.sql SESSION altered. INFO: Starting WITH RDBMS DST UPDATE preparation. INFO: NO actual RDBMS DST UPDATE will be done BY this script. INFO: IF an ERROR occurs the script will EXIT sqlplus. INFO: Doing checks FOR known issues ... INFO: DATABASE version IS 19.0.0.0 . INFO: DATABASE RDBMS DST version IS DSTv18 . INFO: No known issues detected. INFO: Now detecting NEW RDBMS DST version. A PREPARE window has been successfully started. INFO: Newest RDBMS DST version detected IS DSTv32 . INFO: NEXT step IS checking ALL TSTZ DATA. INFO: It might take a while BEFORE any further output IS seen ... A PREPARE window has been successfully ended. INFO: A newer RDBMS DST version than the one currently used IS found. INFO: Note that NO DST UPDATE was yet done. INFO: Now run utltz_upg_apply.sql TO do the actual RDBMS DST UPDATE. INFO: Note that the utltz_upg_apply.sql script will INFO: restart the DATABASE 2 times WITHOUT any confirmation OR prompt.
Upgrade der Zeitzonen Definition mit @?/rdbms/admin/utltz_upg_apply.sql:
cd $ENV:ORACLE_HOME/rdbms/admin sqlplus / AS sysdba --Time zone apply script. Warning: This script will restart the database and adjust time zone data. @?/rdbms/admin/utltz_upg_apply.sql INFO: IF an ERROR occurs, the script will EXIT SQL*Plus. INFO: The DATABASE RDBMS DST version will be updated TO DSTv32 . WARNING: This script will restart the DATABASE 2 times WARNING: WITHOUT asking ANY confirmation. WARNING: Hit control-c NOW IF this IS NOT intended. INFO: Restarting the DATABASE IN UPGRADE mode TO START the DST upgrade. DATABASE closed. DATABASE dismounted. ORACLE instance shut down. ORACLE instance started. Total System Global Area 1258287416 bytes Fixed SIZE 9027896 bytes Variable SIZE 939524096 bytes DATABASE Buffers 301989888 bytes Redo Buffers 7745536 bytes DATABASE mounted. DATABASE opened. INFO: Starting the RDBMS DST upgrade. INFO: Upgrading ALL SYS owned TSTZ DATA. INFO: It might take TIME BEFORE any further output IS seen ... An upgrade window has been successfully started. INFO: Restarting the DATABASE IN NORMAL mode TO upgrade non-SYS TSTZ DATA. DATABASE closed. DATABASE dismounted. ORACLE instance shut down. ORACLE instance started. Total System Global Area 1258287416 bytes Fixed SIZE 9027896 bytes Variable SIZE 939524096 bytes DATABASE Buffers 301989888 bytes Redo Buffers 7745536 bytes DATABASE mounted. DATABASE opened. INFO: Upgrading ALL non-SYS TSTZ DATA. INFO: It might take TIME BEFORE any further output IS seen ... INFO: Do NOT START any application yet that uses TSTZ DATA! INFO: NEXT IS a list OF ALL upgraded TABLES: ... NUMBER OF failures: 0 TABLE list: "APEX_190100"."WWV_FLOW_DEBUG_MESSAGES" .. NUMBER OF failures: 0 TABLE list: "APEX_190200"."WWV_FLOW_ISSUE_NOTIFICATIONS" NUMBER OF failures: 0 INFO: Total failures during UPDATE OF TSTZ DATA: 0 . An upgrade window has been successfully ended. INFO: Your NEW Server RDBMS DST version IS DSTv32 . INFO: The RDBMS DST UPDATE IS successfully finished. INFO: Make sure TO exit this SQL*Plus SESSION. INFO: Do NOT USE it FOR timezone related selects.
Version prüfen:
SELECT * FROM v$timezone_file; FILENAME VERSION CON_ID ------------------------------------------------------------ ------------ ------------ timezlrg_32.dat 32 0
Auf Platte liege die Zeitzonen Definition hier:
cd $ENV:ORACLE_HOME\dbhome_1\oracore\zoneinfo cat readme.txt Current Structure version: 3 Current Content Version :32 Content Version 31 ------------------ Timezones updated: DSTVERSION TIME_ZONE_NAME FROM_YEAR TO_YEAR 32, Africa/Bissau, 1912,
Statistiken neun anlegen
Bei Bedarf alle Statistiken auf der Datenbank neu anlegen
z.b. mit folgenden Script: https://github.com/gpipperr/OraPowerShell/blob/master/Ora_SQLPlus_SQLcL_sql_scripts/create_all_statistic.sql
Bei Bedarf prüfen ob die Auto Advisor Jobs notwendig sind, zum ausschalten siehe auch:
- DBMS_AUTO_TASK_ADMIN.DISABLE still shows the client_name enabled in DBA_AUTOTASK_CLIENT view (Doc ID 1565768.1)
EXEC DBMS_AUTO_TASK_ADMIN.DISABLE('AUTO SPACE ADVISOR',NULL, NULL); EXEC DBMS_AUTO_TASK_ADMIN.DISABLE('SQL TUNING ADVISOR',NULL, NULL);
TFA Trace File Analyser updaten bzw. neu installieren
Trace File Analyser einrichten ⇒ Oracle 12c / 18c - Die RAC Umgebung mit Oracle Trace File Analyzer (TFA) überprüfen - 19 Autonomous Health Framework (AHF)
Allerdings gibt es den AHF noch nicht für Windows daher TFA verwenden ⇒ TFA Collector - TFA with Database Support Tools Bundle (Doc ID 1513912.1) ⇒ von hier die
ein Update ist im Prinzip eine neue Installation!
Falls schon mal installiert:
net stop "Oracle Trace File Analyzer"
Neue Installation:
mkdir C:\oracle\products\tfa\19.2.3 expand-archive -path 'D:\install\oracle\database\19c\TFA-Win_v19.2.3.zip' -destinationpath 'C:\install\oracle\database\19c\' expand-archive -path 'D:\install\oracle\database\19c\TFAWin.zip' -destinationpath 'C:\install\oracle\database\19c\TFAWin' cd C:\install\oracle\database\19c\TFAWin # get help .\install.bat #start install .\install.bat -local -tfabase C:\oracle\products\tfa\19.2.3 -perlhome C:\oracle\products\19.3.0.0\dbhome_1\perl
Konfigurieren mit:
C:\oracle\products\tfa\19.2.3\tfa\bin .\tfactl.bat menu
Unter Windows fehlen aber viele Feature wie oracheck ….. , d.h. für Windows ist das anscheinend nur für das Sammeln der Bug Infos für den Support hilfreich.
Problem mit MV (materialised view) Refreshs - Drop hängt - Refersh hängt
Nach dem Upgrade fällt auf das die DB sehr viel CPU verbraucht, eine Analyse zeigt das diese von Refesh Sessions für MV's verbraucht wird.
Der erste Verdacht ist, das vor dem Upgrade nicht sauber darauf geachtet wurde das alle MS's auch „Fresh“ sind /die Refresh Jobs auch alle beendet waren und nicht nochmal während dem Upgrade Lauf gestaret sind und nun die MV's „beschädigt“ sind.
Als erstes alle Refresh Jobs gestoppt/entfernen.
Um das Verhalten zu verstehen, dann die MV recompiliert und Trace beim Refersh um zu sehen was hier im Hintergrund soviel Leistung verbraucht:
sqlplus / AS sysdba -- set Trace ALTER SESSION SET EVENTS '10053'; ALTER SESSION SET EVENTS '10053 level 1'; -- Where is the trace on the server SELECT VALUE FROM v$diag_info WHERE name = 'Default Trace File'; -- compile ALTER MATERIALIZED VIEW APEX_GPI.MV_APEX_USER COMPILE; -- start Refresh BEGIN dbms_mview.refresh('APEX_GPI.MV_APEX_USER',method=>'C',atomic_refresh=>FALSE); END; -- switch off ALTER SESSION SET EVENTS '10053 off';
Ein sehr kleine MV ließ sich nun gleich übersetzen, etwas größere benötigen aber sehr lange für den Refresh, Im Trace wird sichtbar das viele Full Table Scans auf diese Art von Tabellen wie mvref$_stats auftauchen und das ganze sehr langsam ist.
Bei der Suche, was sich bei einem Refresh alles so einstellen lässt auf diesen Artikel gestoßen ⇒ https://www.linkedin.com/pulse/slow-mview-refresh-oracle-122-vineet-arya ( Danke an VINEET ARYA, you save my day .-) )
Bei Kontrolle der Einstellungen auf dem System fällt dann auf, das wir wohl hier auf einen BUG mit dem Upgrade gelaufen sind:
SELECT * FROM DBA_MVREF_STATS_SYS_DEFAULTS; COLLECTION_LEVEL TYPICAL COLLECTION_LEVEL TYPICAL RETENTION_PERIOD 365 RETENTION_PERIOD 31 --- SELECT * FROM sys.mvref$_stats_sys_defaults; 1 365 1 31
Hier sollten keine zwei Zeilen zurück kommen!
Laut dieser Node ist das Problem bekannt, aber wohl in 19c nicht gefixt ⇒ After DB Upgrade, One More Entry(COLLECTION_LEVEL=TYPICAL) is Added into DBA_MVREF_STATS_SYS_DEFAULTS View. (Doc ID 2440801.1)
Lösung:
Einen der beiden Einträge in der sys.mvref$_stats_sys_defaults löschen.
Sammeln der Statistik auschalten.
sqlplus / AS sysdba -- check carefully if you are on the correct database SELECT * FROM v$instance --- 1 Zeile wurde gel÷scht. SQL> SELECT * FROM sys.mvref$_stats_sys_defaults; COLLECTION_LEVEL RETENTION_PERIOD ---------------- ---------------- 1 365 SQL> SELECT * FROM DBA_MVREF_STATS_SYS_DEFAULTS; PARAMETER_NAME VALUE ---------------- ---------------------------------------- COLLECTION_LEVEL TYPICAL RETENTION_PERIOD 365 commit; --- SELECT COUNT(*) FROM DBA_MVREF_STATS COUNT(*) ---------- 1487542 -- truncate this tables TRUNCATE TABLE mvref$_stats; TRUNCATE TABLE mvref$_run_stats; TRUNCATE TABLE mvref$_change_stats; TRUNCATE TABLE mvref$_stmt_stats; SELECT COUNT(*) FROM DBA_MVREF_STATS ; COUNT(*) ---------- 0 -- To turn off refresh-stats collection: EXEC dbms_mview_stats.set_system_default('COLLECTION_LEVEL', 'NONE'); --test again BEGIN dbms_mview.refresh('APEX_GPI.MV_APEX_USER',method=>'C',atomic_refresh=>FALSE); END; SELECT * FROM DBA_MVREF_STATS_SYS_DEFAULTS; -- now we schould have no entries anymore SELECT COUNT(*) FROM DBA_MVREF_STATS COUNT(*) ---------- 0
Performance:
- NEEDS TO CREATE APPROPRIATE INDEXES ON ALL „MVREF$“ TABLES IN ORDER TO AVOID FULL TABLE SCAN (Doc ID 2549364.1)
- Patch 29783142
- Drop User Take Long Time And Some Time Just Hanging (Doc ID 2584912.1)
Patch der Datenbank 19 auf 19.5
Zwar ist aktuelle schon eine höhere Release verfügbar (Juni.´2020) aberaus Kompatibilitäts-Gründen soll die 19.3 Umgebung auf 19.5 werden.
Der Patch dazu ist unter der Support Node 1454618.1 unter „Latest Available Microsoft Windows Patches“ „19.0.0.0“ zu finden.
In unserem Fall die 19.5.0.0.19101 Bundle Patch 30151705 mit OJVM Patch 30128191 + OPatch (6880880 min. 12.2.0.1.0 release Patch 6880880: OPatch 12.2.0.1.21 for Db 12.x, 18.x, 19.x and 20.x releases (Apr 2020))
Patch 30151705: WINDOWS DATABASE BUNDLE PATCH 19.5.0.0.191015
Ablauf:
- Opatch austauschen ( %ORACLE_HOME%/OPatch in %ORACLE_HOME%/OPatch_OLD, Inhalt ZIP Patch 6880880 nach %ORACLE_HOME% kopieren )
- Dos Console starten (cmd.exe)
- Perl Pfad prüfen „set PATH=%ORACLE_HOME%\perl\bin;%PATH%“ ; unset Env Variable „set PERL5LIB= <Press Enter>“
- Patch p30151705_190000_MSWIN-x86-64.zip auspacken
- Alle Dienste aus den Oracle Home stoppen und prüfen das nichts mehr in dem Home läuft mit dem https://docs.microsoft.com/de-de/sysinternals/downloads/process-explorer
- wie net stop msdtc usw.
- In des Verzeichnis“30151705„ wechseln
- Auf Konflikte prüfen mit
%ORACLE_HOME%\OPatch\opatch prereq CheckConflictAgainstOHWithDetail -ph ./
- Bei Fehlern siehe Node MOS (DOC ID 2022382.1) , evlt. muss der letzte OVJM Patch erst zurück gerollt werden
opatch lsinventory opatch rollback -id <OJVM BP #>
- mit “%ORACLE_HOME%\OPatch\opatch apply„ die Oracle Binaries patchen
- Falls im .Net im Einsatz, Komponenten aktualiseren!
- Falls zuvor OVJM Rollback erst nach dem OVJM Patch diese Schritte durchführen! siehe 2022382.1
- DB Service und Datenbank wieder starten
- cd %ORACLE_HOME%\OPatch wechseln
- Datenbank updaten mit „datapatch -verbose“
- Datenbank mit
sqlplus / as sysdba ; @?/rdbms/admin/utlrp.sql
neu übersetzen
- Für jede Datenbank in dem Oracle Home wiederholen!
Oracle JavaVM Component 19.5.0.0.191015 on Windows
Ablauf:
- Alle Dienste aus den Oracle Home stoppen und prüfen das nichts mehr in dem Home läuft
- Patch auspacken mit
unzip -d <PATCH_TOP_DIR> p30128191_190000_MSWIN-x86-64.zip" cd <PATCH_TOP_DIR>\30128191
- Patch prüfen mit
%ORACLE_HOME%\OPatch\opatch prereq CheckConflictAgainstOHWithDetail -ph .
- opatch apply
%ORACLE_HOME%\OPatch\opatch apply
- DB Service und Datenbank wieder starten
- Datenbank im Upgrade modus wieder starten, „shutdown immediate, startup upgrade“
- cd %ORACLE_HOME%\OPatch und datapatch -verbose
- Datenbank wieder stoppen und normal starten
- Datenbank mit
sqlplus / as sysdba ; @?/rdbms/admin/utlrp.sql
neu übersetzen
- Für jede Datenbank in dem Oracle Home wiederholen!
- Am Ende den listener wieder starten!
Quellen
Web:
Oracle
Alternativ - Auto Upgarde 19:
Support:
- Oracle 19c - Complete checklist for Manual Upgrade for upgrading Oracle 12.x, 18c Container database (CDB) to Oracle 19c (19.x) (Doc ID 2549866.1)
Upgrade mit einer Physical Standby Umgebung 18c R2 auf 19c
Genereller Ablauf aus ⇒ https://docs.oracle.com/database/121/SBYDB/upgrades.htm#SBYDB4933
- Primär - Installation Software 19c in neuen Oracle Home
- Primär - Patch Software 19c im neuem Oracle Home
- Standby - Installation Software 18c in neuen Oracle Home
- Standby - Patch Software 18c im neuem Oracle Home
- Primär - PreUpgrade Steps für die noch im R1 laufenden Home laufende Datenbank durchführen
- Primär - Datenbank stoppen
- Standby - Datenbank stoppen
- Standby - DB auf neues Home umziehen, Listener aus neuen Home Starten PWD und init File ins neue Home kopieren, DB Service löschen und mit neuen Home neu anlegen, Pfade alle anpassen, wie PATH etc!
- Standby - Mount der alten Datenbank über Datagard , nur mount Status!
- Standby - Log shipping von der alten DB prüfen, Redo Apply auf the physical standby database aktivieren/prüfen
- Primär - Datenbank ins neue Home umziehen, Listener aus neuen Home Starten PWD und init File ins neue Home kopieren, DB Service löschen und mit neuen Home neu anlegen, Pfade alle anpassen, wie PATH etc!
- Primär - DB Upgarde durchführen
- Primär - DB öffnen und prüfen Standby in Sync
- Primär - dgmgrl testen , falls Fehler ORA-16714: the value of property string is inconsistent with the database setting
SHOW DATABASE orasb 'InconsistentProperties'; NCONSISTENT PROPERTIES INSTANCE_NAME PROPERTY_NAME MEMORY_VALUE SPFILE_VALUE BROKER_VALUE DGA24L DATAGUARDSYNCLATENCY 0 0 -- auf beiden systemen ALTER SYSTEM SET DATA_GUARD_SYNC_LATENCY=0 scope=BOTH sid='*';
Parameter siehe DATA_GUARD_SYNC_LATENCY
Optional den COMPATIBLE initialization parameter auf beiden Seiten anpassen