Mit der Oracle 12c R2 ändert sich auch leicht der Upgrade Prozess von älteren DB Versionen inkl. der 12c R1.
Bzgl mehr Informationen zu Update auf R1 im Detail siehe auch Eine Oracle Datenbank 11g R2 auf eine neue Oracle 12c Datenbank Umgebung unter Windows 2012 R2 umziehen
Hier ein paar Anmerkungen zum generellen Ablauf.
Fehler „ORA-1017 Invalid Username or Password“ nach 12c Upgrade
Hinweis! Falls noch 10g Clients z.B. über OCI Applikation in Einsatz sind, per Default wird das 10g Password nicht mehr unterstützt! ⇒ https://docs.oracle.com/database/122/UPGRD/case-insensitive-passwords-ora-1017-invalid-username-password.htm#UPGRD-GUID-FDA9C77A-12F4-4410-9448-9BCC13960C27, setzen von SQLNET.ALLOWED_LOGON_VERSION_SERVER=11 in der sqlnet.ora als temporäre Lösung bis alle Clients umgestellt auf 12c R2 umgestellt sind! ⇒ siehe auch Oracle 12c R2 - Password Handing - ORA-1017 Invalid Username or Password - Identified by Values
Zuvor immer das Backup der bestehenden Datenbank sicherstellen!
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/jdk7/bin/java.exe cd C:\oracle\products\12.2.0.1\dbhome_1\rdbms\admin java -jar .\preupgrade.jar TERMINAL TEXT ... Preupgrade generated files: C:\oracle\cfgtoollogs\GPI\preupgrade\preupgrade_fixups.sql C:\oracle\cfgtoollogs\GPI\preupgrade\postupgrade_fixups.sql
Es werde die PreUpgrade und PostUpgrade SQL Scripte erzeugt.
Das preupgrade_fixups.sql MUSS 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;
Besonderers darauf achten, dass die Passwörter der DB User die NUR in der Version 10g vorliegen, neu gesetzt werden!
SELECT password_versions,username FROM dba_users;
Nach dem Upgrade können sich die User mit NUR 10g PWD nicht mehr an der DB 12c R2 anmelden!
Das kann alles noch im laufenden Betrieb der Umgebung vorbereitet werden.
Password vom ORARUN User heraussuchen!
Dienst beenden
$env:ORACLE_HOME="D:\oracle\product\12.1.0.2\dbhome_1" cd $env:ORACLE_HOME\bin oradim -delete -sid VDS
Als Administrative Session!
# mit SC cmd.exe sc query OracleOraDB12Home1TNSListener sc stop OracleOraDB12Home1TNSListener sc delete OracleOraDB12Home1TNSListener
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! set ORACLE_HOME=C:\oracle\products\12.2.0.1\dbhome_1 cd C:\oracle\products\12.2.0.1\dbhome_1\bin lsnrctl start
Prüfen ob der Service auch angelegt wurde und ob Autostart richtig gesetzt wurde, default ist manuel!
init.ora/spfile/*.dat und pwd files vom alten Home/database in das neue Home/database legen
Eine Administrative PowerShell öffnen und den DB Service anlegen:
$env:ORACLE_HOME="D:\oracle\product\12.1.0.2\dbhome_1" cd $env:ORACLE_HOME\bin oradim -new -sid VDS Enter password for Oracle service user: Instance created.
Tritt ein „O/S-Error: (OS 5) Access is denied.“ Fehler auf, prüfe ob wirklich eine administrative PowerShell Session gestartet wurde!
Service kontrollieren und nach Bedarf einstellen.
Z.b. Registry prüfen „HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraDB12Home1“ ORA_VDS_AUTOSTART auf TRUE setzen, falls Autostart gewünscht.
$ENV:ORACLE_SID="VDS" sqlplus / as sysdba startup upgrade exit
Zur Überwachung des Alert Logs der DB diese mit einem Tail in zweiten Fenster anzeigen lassen:
adrci adrci> show homes ADR Homes: diag\rdbms\vds\vds diag\tnslsnr\12CWIN2012ORA01\listener adrci> set home diag\rdbms\vds\vds adrci> show alert -tail -f ... Completed: ALTER DATABASE OPEN MIGRATE ...
Der eigentliche Upgrade wird nun in der 12c R2 ü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\12.1.0.2\dbhome_1" cd $env:ORACLE_HOME\bin mkdir d:\temp\12cR2Upgrade dbupgrade.cmd -n 4 -l d:\temp\12cR2Upgrade .... ------------------------------------------------------ Phases [0-115] Start Time:[2017_10_07 13:09:04] ------------------------------------------------------ ... ------------------------------------------------------ Phases [0-115] End Time:[2017_10_07 13:51:47] ------------------------------------------------------ Grand Total Time: 2563s
sqlplus / as sysdba startup @C:\oracle\cfgtoollogs\GPI\preupgrade\postupgrade_fixups.sql ... For Source Database: GPI Source Database Version: 12.1.0.2.0 For Upgrade to Version: 12.2.0.1.0 Fixup Check Name Status Further DBA Action ---------- ------ ------------------ depend_usr_tables Failed Manual fixup recommended. old_time_zones_exist Failed Manual fixup recommended. post_dictionary Passed None ...
Problem : depend_usr_tables Failed Manual fixup recommended. ⇒ see 12.2 DB Post Upgrade:postupgrade_fixups.sql shows „depend_usr_tables Failed Manual fixup recommended“ (Doc ID 2266026.1), kann in meinen Fall ignoriert werden
Auf ungültige Objekte prüfen und bei Bedarf alles neu übersetzen:
sqlplus / AS sysdba @?/rdbms/admin/utlrp ...(15:06:35) Starting validate_apex FOR APEX_050100 ORA-20001: MISSING GRANT: GRANT EXECUTE ON "MDSYS"."SDO_DIM_ARRAY" TO APEX_050100 ORA-20001: MISSING GRANT: GRANT EXECUTE ON "MDSYS"."SDO_DIM_ELEMENT" TO APEX_050100 ORA-20001: MISSING GRANT: GRANT EXECUTE ON "MDSYS"."SDO_POINT_TYPE" TO APEX_050100 ...(15:06:37) GRANT EXECUTE ON "SYS"."DBMS_CRYPTO_INTERNAL" TO APEX_050100 ...(15:06:37) GRANT EXECUTE ON "SYS"."DIANA" TO APEX_050100 ...(15:06:37) GRANT EXECUTE ON "SYS"."DIUTIL" TO APEX_050100 ...(15:06:37) GRANT EXECUTE ON "SYS"."KU$_DDL" TO APEX_050100 ...(15:06:37) GRANT EXECUTE ON "SYS"."KU$_DDLS" TO APEX_050100 ...(15:06:37) Checking missing sys privileges ...(15:06:37) Recompiling ...(15:06:39) Checking FOR objects that are still invalid ...(15:06:39) KEY object existence CHECK ...(15:06:40) Setting DBMS registry FOR APEX TO INVALID ...(15:06:40) Exiting validate_apex
Problem: Rechte wie vorgeschlagen vergeben und neu übersetzen! Danach Apex revalidieren:
sqlplus / AS sysdba -- rechte wie oben gewünscht vergeben @?/rdbms/admin/utlrp -- apex validieren SET serveroutput ON EXECUTE sys.validate_apex
siehe auch ⇒ APEX is Invalid After Upgrading to 12.2 - ORA-20001: MISSING GRANT(Doc ID 2274616.1)
Default DB Home in eigenen Scripten wie dem Backup anpassen.
NLS Lang prüfen! ( HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraDB12Home1\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\12.2.0.1\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\12.2.0.1\dbhome_1\bin\oraclr12.dll\"
Oracle
Web:
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