Benutzer-Werkzeuge

Webseiten-Werkzeuge


dba:upgrade_18c_windows_2016_to_19c

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.

Hier ein paar Anmerkungen zum generellen Ablauf mit Hilfe der „preupgrade.jar“ und „dbupgrade.cmd“ Tools beim Upgrade von Oracle 18 auf Oracle 19.

Achtung - mit MS Windows Server 2019 ist der Defender per Standard aktiv, Oracle Exe + Datenbank Verzeichnisse vom Virenscanner ausnehmen!

Ablauf

Genereller schematischer Ablauf:

  1. Password vom lokalen ORARUN User auf dem System heraussuchen
  2. DB Software in ein neues Oracle Home entpacken und Oracle Home mit Setup Programm initialisieren
  3. Neues DB Home mit letzten DB Patch patchen
  4. DB auf ungültige Objekte kontrollieren und diese möglichst aufräumen
  5. Pre Upgrade Scripte auf der DB in der 18c Umgebung laufen lassen und Anweisungen ausführen, DB für den Upgrade aufräumen/optimieren
  6. Vor dem Upgrade darauf achten das alle Materialized Views refreshed sind, Jobs dazu stoppen!
    1. siehe Doc ID 1406586.1 - How to Handle Materialized Views When You Upgrade or Clone a Database
    2. siehe Doc ID 2440801.1 - After DB Upgrade, One More Entry(COLLECTION_LEVEL=TYPICAL) is Added into DBA_MVREF_STATS_SYS_DEFAULTS View. 18c
  7. DB im alten Home Stoppen
  8. DB Service im neuen Home anlegen
  9. DB Upgrade im neuen Home durchführen
  10. Alle DB Scripte wie Backup / ETL Jobs etc. auf neues DB Home anpassen
  11. Prüfen ob alle Anwender sich anmelden können, SYS AS SYSDBA über SQL*Net testen
  12. Prüfen ob das ADRCI migriert werden muss
  13. 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.

Überprüfen ob alle Dateien die in $ORACLE_HOME\rdbms\admin\rdbms_postapply.sql hinterlegt sind auch wirklich vorhanden sind! Bug mit Jan 2020 Patch 30445947: WINDOWS DATABASE BUNDLE PATCH 19.6.0.0.200115! Datei \backport_files\bug_29766207_apply.sql fehlt!

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:

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

  1. Datenbank mit shutdown immediate herunterfahren
  2. 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!

Siehe auch Listener Fehler bei einer Installation unter Windows 8.1 wie TNS-12546 - TNS-00516 - 64-bit Windows Error: 13: Permission denied

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

ORACLE_PATH und SQLPATH auf null setzen! Keine eigene login.sql darf aktiv sein! Gefahr von Seitenefekten mit eigenen Einstellungen!!
Überprüfen ob alle Dateien die in $ORACLE_HOME\rdbms\admin\rdbms_postapply.sql hinterlegt sind auch wirklich vorhanden sind! Bug mit Jan 2020 Bundle Patch! Datei bug_29766207_apply.sql fehlt!
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

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.

Prüfen das ein sqlplus / as sysdba sich sehr schnell anmelden kann! In meinen Fall hat die Verzögerung dazu geführt das sich das Upgrade im ersten Schritt nicht durchführen ließ und im zweiten Versuchen, nach dem Fix des eigentlichen Problemes, NICHT mehr durchführen ließ! DB defekt :-\
 $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.

Siehe Oracle 12c PL/SQL - Verwendung von .Net Libraries in PL/SQL - eine ".NET stored procedures" anlegen und aufrufen

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:

--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.
DB wird neu gestartet!!! Administrative Schell verwenden!

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:

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

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


Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
dba/upgrade_18c_windows_2016_to_19c.txt · Zuletzt geändert: 2022/07/27 10:06 von gpipperr

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki