Erstellt 2019/09/
Mit Oracle 12c R2 / 18c / 19c ändert sich auch leicht der Upgrade Prozess von älteren DB Versionen inkl. der 12c R1.
Hier ein paar Anmerkungen zum generellen Ablauf mit Hilfe der „preupgrade.jar“ und „dbupgrade.cmd“ Tools beim Upgrade von Oracle 18 auf Oracle 19.
Genereller schematischer Ablauf:
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:
-- (3,105,763,999 bytes) (sha256sum - 64d92018207829833bd4d00f1a7fb40c531c8a4a68ded9e430a5d6fbaedaca95) Get-FileHash .\WINDOWS.X64_180000_db_home\ -Algorithm SHA256 Algorithm Hash --------- ---- SHA256 64D92018207829833BD4D00F1A7FB40C531C8A4A68DED9E430A5D6FBAEDACA95
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'
cd C:\oracle\products\19.3.0.0\dbhome_1
.\setup.bat
Install Wizard Ablauf:
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.
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:
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
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!
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!
Password vom ORARUN User heraussuchen! Wird dann später am Anlegen des DB und des Listener Service auf jeden Fall benötigt!
Als Administrative Session!
$env:ORACLE_HOME="C:\oracle\products\18.3.0.0\dbhome_1" cd $env:ORACLE_HOME\bin oradim -delete -sid GPI
Als Administrative Session! Auf die Dos Shell achten!
# mit SC cmd.exe sc query OracleOraDB18Home1TNSListener sc stop OracleOraDB18Home1TNSListener sc delete OracleOraDB18Home1TNSListener
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.
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.
$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 ...
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) ......
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.
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
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
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 wie PATH prüfen das alles auf das neue Oracle Home zeigt.
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!
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
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
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
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,
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:
EXEC DBMS_AUTO_TASK_ADMIN.DISABLE('AUTO SPACE ADVISOR',NULL, NULL); EXEC DBMS_AUTO_TASK_ADMIN.DISABLE('SQL TUNING ADVISOR',NULL, NULL);
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.
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:
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))
Ablauf:
%ORACLE_HOME%\OPatch\opatch prereq CheckConflictAgainstOHWithDetail -ph ./
opatch lsinventory opatch rollback -id <OJVM BP #>
sqlplus / as sysdba ; @?/rdbms/admin/utlrp.sql
neu übersetzen
Ablauf:
unzip -d <PATCH_TOP_DIR> p30128191_190000_MSWIN-x86-64.zip" cd <PATCH_TOP_DIR>\30128191
%ORACLE_HOME%\OPatch\opatch prereq CheckConflictAgainstOHWithDetail -ph .
%ORACLE_HOME%\OPatch\opatch apply
sqlplus / as sysdba ; @?/rdbms/admin/utlrp.sql
neu übersetzen
Web:
Oracle
Alternativ - Auto Upgarde 19:
Support:
Genereller Ablauf aus ⇒ https://docs.oracle.com/database/121/SBYDB/upgrades.htm#SBYDB4933
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