upgrade_to_oracle_19c
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| upgrade_to_oracle_19c [2020/03/27 14:03] – stuart | upgrade_to_oracle_19c [2026/03/17 09:56] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ==== Oracle | + | ==== Mike Dietrich Classroom sessions 2020 ==== |
| + | * [[https:// | ||
| + | |||
| + | |||
| + | * [[https:// | ||
| + | |||
| + | Active Data Guard is more than just the Read-Only Standby | ||
| + | * [[https:// | ||
| + | |||
| + | ==== A worked example of a manual | ||
| + | * [[http:// | ||
| + | |||
| + | ==== Oracle 19c changes and desuppoerted features ==== | ||
| + | * [[https:// | ||
| === Using Mike Dietrich' | === Using Mike Dietrich' | ||
| + | This is really the only way to go from now on. It makes life so much easier for the dba. See my [[AutoUpgrade]] page for my real life working document. | ||
| * [[https:// | * [[https:// | ||
| * [[https:// | * [[https:// | ||
| * [[https:// | * [[https:// | ||
| + | * [[http:// | ||
| + | |||
| + | ==== Upgrade to 19c and also apply the latest RU patch at the same time ==== | ||
| + | * [[https:// | ||
| + | |||
| + | ==== A word on 10g passwords and compatibility ==== | ||
| + | * [[https:// | ||
| + | * [[https:// | ||
| + | * [[http:// | ||
| + | |||
| + | There are two things that influence access to the database with 10g passwords. | ||
| + | * SQLNET.ALLOWED_LOGON_VERSION_SERVER. If this is set to a value lower than 12, the database engine will (also) **generate** a 10g type password when < | ||
| + | * If there are users with ONLY a 10g password, they will not be able to login unless SQLNET.ALLOWED_LOGON_VERSION_SERVER is set to 11 (and listener restarted). | ||
| + | * Parameter SEC_CASE_SENSITIVE_LOGON. If set to false, 10g password is used for authentication (password column in user$). If it is set to true, the 11g, 12c etc. password is used for authentication (spare4 in user$) | ||
| + | |||
| === Download the Hands-On Lab === | === Download the Hands-On Lab === | ||
| Line 11: | Line 41: | ||
| === This is the main setup page for the HOL === | === This is the main setup page for the HOL === | ||
| [[https:// | [[https:// | ||
| + | |||
| + | ==== Pre-requisites ==== | ||
| + | Autoupgrade sets a guaranteed restore point before it does the upgrade in case anything goes wrong.\\ | ||
| + | I have done an upgrade that went wrong so to make life a lot easier, use a FRA! | ||
| + | === Ensure a FRA exists to hold the flashback logs === | ||
| + | Note: Flashback does not need to be enabled for this to work. | ||
| + | < | ||
| + | alter system set db_recovery_file_dest_size = 10g scope=both; | ||
| + | alter system set db_recovery_file_dest = ‘/ | ||
| + | |||
| + | SQL> sho parameter recovery | ||
| + | |||
| + | NAME | ||
| + | ------------------------------------ ----------- ------------------------------ | ||
| + | db_recovery_file_dest | ||
| + | db_recovery_file_dest_size | ||
| + | recovery_parallelism | ||
| + | </ | ||
| ==== An example of an autoupgrade config file that has worked successfully ==== | ==== An example of an autoupgrade config file that has worked successfully ==== | ||
| Line 36: | Line 84: | ||
| </ | </ | ||
| + | === Run the autoupgrade in analyse mode to check that the upgrade will likely succeed === | ||
| + | < | ||
| + | export CFGS="/ | ||
| + | export OH19=" | ||
| + | echo $OH19 | ||
| + | / | ||
| + | " | ||
| + | </ | ||
| + | |||
| + | === Run the autoupgrade in deploy mode requesting it to undo what it did should it fail === | ||
| + | < | ||
| + | " | ||
| + | </ | ||
| + | |||
| + | ==== Downgrade in case of failed application testing ==== | ||
| + | If the application testing shows that this database version is not going to work there are options. | ||
| + | === Compatible parameter was not updated === | ||
| + | * If the compatible parameter is still the same as what it was before the upgrade and the restore point is still intact, we can restore the database back to the restore point in a few seconds.\\ | ||
| + | NOTE: The whole database will be rewound - dictionary and data! | ||
| + | < | ||
| + | select * from v$restore_point; | ||
| + | shu immediate | ||
| + | startup mount; | ||
| + | flashback database to restore point &grp; | ||
| + | alter database open resetlogs; | ||
| + | </ | ||
| + | |||
| + | * If the compatible parameter is still the same as what it was before the upgrade and irrespective of whether the restore point is still intact, we can restore the database by downgrading it. This may take 20-30 minutes but works.\\ | ||
| + | The advantage of this method is that the dictionary is downgraded but the data remains as it is. | ||
| + | < | ||
| + | shutdown immediate | ||
| + | startup downgrade | ||
| + | set echo on termout on serveroutput on timing on | ||
| + | spool / | ||
| + | @?/ | ||
| + | shutdown immediate | ||
| + | exit | ||
| + | </ | ||
| + | Switch back to the old ORACLE_HOME. A duplicated entry in /etc/oratab helps here. | ||
| + | < | ||
| + | export ORACLE_SID=aarct_11 | ||
| + | . oraenv | ||
| + | </ | ||
| + | Start the instance up in upgrade mode to to complete the downgrade! | ||
| + | < | ||
| + | startup upgrade | ||
| + | set echo on termout on timing on | ||
| + | spool / | ||
| + | @?/ | ||
| + | shutdown immediate | ||
| + | </ | ||
| + | Startup and recompile any uncompiled objects | ||
| + | < | ||
| + | startup | ||
| + | @?/ | ||
| + | </ | ||
| + | |||
| + | === Compatible parameter was updated === | ||
| + | * If the compatible parameter was set to the upgraded verson, the only option to return to the old database version is to export the database and import it into ia database in the original home. This obviously takes a lot longer depending on the size of the database. | ||
upgrade_to_oracle_19c.txt · Last modified: 2026/03/17 09:56 by 127.0.0.1