====== Autoupgrade to 19c ======
* [[https://support.oracle.com/epmos/faces/DocumentDisplay?id=2118136.2|Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases (Doc ID 2118136.2)]]
* [[https://updates.oracle.com/download/6880880.html|Oracle Global Lifecycle Management - Latest version of OPatch]]
===== General autoupgrade help =====
* [[https://mikedietrichde.com/database-upgrade-hands-on-lab-oracle-18c-and-19c/hol-19c-main-index-page-oracle-database-19c-hands-on-lab/|Mike Dietrich - Hands-on Lab]]
* [[https://www.oracle.com/downloads/community/vts-hands-on-labs-downloads.html|Mike Dietrich - Hands-on Lab downloads]]
* [[https://docs.oracle.com/en/database/oracle/oracle-database/19/upgrd/autoupgrade-command-line-parameters.html|Autoupgrade commmand line parameters]]
* [[https://support.oracle.com/epmos/faces/DocumentDisplay?id=2485457.1|Download the latest version of the AutoUpgrade Tool (Doc ID 2485457.1) (every 4 to 6 weeks)]]
===== Preupgrade =====
* Put database in maintenance mode
https://mon.cegeka.be
* Handy to have this setup
export OH19="$ORACLE_BASE/product/19.9.0/dbhome_1"
* Create a sample config file if not already prepared
ORACLE_HOME="${OH19}"
java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar -create_sample_file config
* Protect listener.ora and tnsnames.ora (if updated already)
cd $OH19/network/admin
cp sqlnet.ora sqlnet.ora.preupgrade_${ORACLE_SID}.$(date '+%Y%m%d%H%M')
cp listener.ora listener.ora.preupgrade_${ORACLE_SID}.$(date '+%Y%m%d%H%M')
cp tnsnames.ora tnsnames.ora.preupgrade_${ORACLE_SID}.$(date '+%Y%m%d%H%M')
ls -altr *ora.preupgrade*
cd -
* Ensure current sqlnet.ora contains (only) these (19c is already like this)
cp -p $TNS_ADMIN/sqlnet.ora $TNS_ADMIN/sqlnet.ora.preupgrade_${ORACLE_SID}.$(date '+%Y%m%d%H%M')
vi $TNS_ADMIN/sqlnet.ora
NAMES.DIRECTORY_PATH = (TNSNAMES, HOSTNAME)
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 11
SQLNET.EXPIRE_TIME = 10
* create a pfile and check for links parameters
echo "create pfile from spfile;"|sqlplus / as sysdba
grep links ${ORACLE_HOME}/dbs/init${ORACLE_SID}.ora
If links found, remove the parameters from the pfile
vi ${ORACLE_HOME}/dbs/init${ORACLE_SID}.ora
* Enable FRA if not already done
sqlplus / as sysdba
show parameter recovery
* If not set, set one up so we can create a restore point
Use this method if no common FRA is setup
col data_dir new_value ndata_dir
select min((substr(file_name,1,instr(file_name,'/',-1)-1))) data_dir from dba_data_files where tablespace_name = 'SYSTEM';
host mkdir -p &ndata_dir/fra
alter system set db_recovery_file_dest_size = 10g scope=both;
alter system set db_recovery_file_dest = '&ndata_dir/fra' scope=both;
show parameter recovery
* For non-prod, a common NFS mounted filesystem could be used (eg. /fra)
Ensure this has the correct mount options though, otherwise it will not work
host mkdir -p /fra/&&HOST/&&SID
alter system set db_recovery_file_dest_size = 10g scope=both;
alter system set db_recovery_file_dest = '/fra/&HOST/&SID' scope=both;
show parameter recovery
* Check that both of the following queries do something. If one says No rows selected, there’s something wrong with the recovery_file_dest
set lines 1000
col name for a45
col file_type for a28
select r.name
, r.space_limit/1024/1024 megs_limit
, r.space_used/1024/1024 megs_used
, r.space_reclaimable/1024/1024 megs_reclaimable
, r.number_of_files
from sys.v$recovery_file_dest r
, sys.v$parameter p
where r.name = p.value
and p.name = 'db_recovery_file_dest'
/
select * from v$recovery_area_usage
/
* Test the fra
create restore point test19c guarantee flashback database;
drop restore point test19c;
* Check for past bad DST upgrade (https://minimalistic-oracle.blogspot.com/2018/02/dstupgradestate-set-to-datapump1-when.html)
set lines 200
col property_name for a30
select property_name, substr(property_value, 1, 30) value
from database_properties
where property_name like 'DST_%'
order by property_name
/
If dst_upgrade_state = 'DATAPUMP (1)', run these:
alter session set events '30090 trace name context forever, level 32';
exec dbms_dst.unload_secondary;
select property_name, substr(property_value, 1, 30) value
from database_properties
where property_name like 'DST_%'
order by property_name
/
value should now say 'NONE'
* Deprecated parameters
* remote_os_authent and utl_file_dir are no longer used and event will cause the upgrade to fail
alter system reset remote_os_authent sid='*' scope=spfile;
alter system reset utl_file_dir sid='*' scope=spfile;
alter system reset event sid='*' scope=spfile;
* Make sure we have enough sga. Ensure mem parameters are 0, sga is at least 3G and pga is at least 800M
sho parameter memory_max_target
sho parameter memory_target
sho parameter sga_max_size
sho parameter sga_target
sho parameter pga
alter system set sga_max_size = 3G scope=spfile;
alter system set sga_target = 3G scope=spfile;
alter system reset pga_aggregate_limit sid='*' scope=spfile;
alter system set pga_aggregate_target = 800M scope=both;
* Check db_domain, service_names and local_listener parameters
* If db_domain contains a value, reset it
show parameter db_domain
alter system reset db_domain sid='*' scope=spfile;
* If db_domain was set, ensure the service_names have a non '.world' and a '.world' version
show parameter service_names
alter system set service_names = '&&SID, &SID..world';
show parameter local_listener
host tnsping listener_&SID
* check audit files go to $ORACLE_BASE/admin/$ORACLE_SID/adump and not somewhere else
sho parameter audit_file_dest
* Prevent AWR_DBIDS_PRESENT post-fixup error in case there are multiple DBIDs present
* and allow capturing of AWR result set for future comparisons
* If this query returns any rows
select dbid
from wrm$_wr_control wwc
where wwc.dbid != (select dbid from v$database)
/
* then AWR database will need to be cleaned otherwise post-upgrade will fail
exec dbms_swrf_internal.cleanup_database;
* Capture stats for possible future comparison. This will now work if AWR is clean.
@/oracle/scripts/.shb/capture_awr.sql
@/oracle/scripts/.shb/capture_cc.sql
-- Check dba_registry components are all valid
set lines 1000
col comp_name for a60
select comp_id, comp_name, version, status from dba_registry
/
-- Ensure there are no compilation errors for sys objects
@?/rdbms/admin/utlrp
* or
@?/rdbms/admin/utlprp 1
* Compile materialised views
set serveroutput on
declare
l_retval number := 0;
begin
dbms_output.enable(null);
dbms_mview.refresh_all_mviews (l_retval,'C','', true, false);
dbms_output.put_line ('returned: '||l_retval);
end;
/
-- Check for remaining invalid objects (make sure none are sys)
set lines 1000 pages 1000
column owner for a30
column object_name for a30
select owner,
object_type,
object_name,
status
from dba_objects
where status = 'INVALID'
order by owner, object_type, object_name
/
* Log_archive_dest
* Change to log_archive_dest_1 if not already done. Verify the path if it is already done.
show parameter log_archive_dest
alter system reset log_archive_dest sid='*' scope=both;
alter system set log_archive_dest_1='location=&log_arch_dir';
host ls -al &log_arch_dir
* Purge DBA recyclebin
purge dba_recyclebin;
* Make sure backups are not running
select * from v$backup WHERE status != 'NOT ACTIVE';
* Remove pending (in doubt) distributed transactions
select 'exec dbms_transaction.purge_lost_db_entry('''||local_tran_id||''');commit;' from sys.dba_2pc_pending;
* Remove all hidden parameters
* Get a list of all _ parameters
set lines 1000 pages 100
select 'alter system reset "'||name||'" sid = ''*'' scope = spfile;' from v$parameter where name like '\_%' escape '\';
* 10g Passwords
There was/is a big change when upgrading from a version less than 12.2 to one greater, namely sqlnet.ora parameter SQLNET.ALLOWED_LOGON_VERSION_SERVER is set by default to 12. This meant that 10g passwords were no longer generated when doing ‘alter user’
If 10g passwords are not generated on the database server, clients attempting to connect with a client version less that 11 cannot connect to the database. This will not affect upgrade to 19c as the minimum client level is 11.2.0.4 anyway.
Where it will have an effect on the upgrade to 19c is where there are database users with ONLY 10g passwords. This should be a rare situation and can only happen where a user, originally setup in a 10g environment, has never had its password changed since the database was 10g.
This is the only case where passwords will have to be reset using 'alter user'. Doing a reset with 'identified by values' will not work.
sqlnet.ora parameter SQLNET.ALLOWED_LOGON_VERSION_SERVER can still be set to 11 but it is not advised.
SEC_CASE_SENSITIVE_LOGON. This parameter is now deprecated in favour of the sqlnet.ora parameter SQLNET.ALLOWED_LOGON_VERSION_SERVER and no longer seems to make any difference.
===== Autoupgrade =====
* Check version
$OH19/jdk/bin/java -jar $OH19/rdbms/admin/autoupgrade.jar -version
If not latest
cp /oracle/Patches/autoupgrade.jar.19.10.0 $OH19/rdbms/admin/autoupgrade.jar
* If db_domain was not empty
sqlplus / as sysdba<
* Autoupgrade with analyse option
$OH19/jdk/bin/java -jar $OH19/rdbms/admin/autoupgrade.jar -config /oracle/scripts/.shb/autoupgrade/autoupgrade_${ORACLE_SID}.cfg -mode analyze
* Pre-upgrade results
------------------- Final Summary --------------------
Number of databases [ 1 ]
Jobs finished [1]
Jobs failed [0]
Jobs pending [0]
Please check the summary report at:
/home/oracle/logs/autoupgrade_${ORACLE_SID}/cfgtoollogs/upgrade/auto/status/status.html
/home/oracle/logs/autoupgrade_${ORACLE_SID}/cfgtoollogs/upgrade/auto/status/status.log
* Autoupgrade with deploy option
$OH19/jdk/bin/java -jar $OH19/rdbms/admin/autoupgrade.jar -config /oracle/scripts/.shb/autoupgrade/autoupgrade_${ORACLE_SID}.cfg -mode deploy
* Upgrade results
------------------- Final Summary --------------------
Number of databases [ 1 ]
Jobs finished [1]
Jobs failed [0]
Jobs pending [0]
---- Drop GRP at your convenience once you consider it is no longer needed ----
Drop GRP from ${ORACLE_SID}: drop restore point AUTOUPGRADE_9212_CLND121020
Please check the summary report at:
/home/oracle/logs/autoupgrade_${ORACLE_SID}/cfgtoollogs/upgrade/auto/status/status.html
/home/oracle/logs/autoupgrade_${ORACLE_SID}/cfgtoollogs/upgrade/auto/status/status.log
* Clear a properly failed upgrade
select * from v$restore_point;
shu immediate
startup mount;
flashback database to restore point &grp;
alter database open resetlogs;
exit
or
$OH19/jdk/bin/java -jar $OH19/rdbms/admin/autoupgrade.jar -config /oracle/scripts/.shb/autoupgrade/autoupgrade_${ORACLE_SID}.cfg -restore -all_failed
$OH19/jdk/bin/java -jar $OH19/rdbms/admin/autoupgrade.jar -config /oracle/scripts/.shb/autoupgrade/autoupgrade_${ORACLE_SID}.cfg -mode analyse -clear_recovery_data
* If the issue was with the startup file...
vi /home/oracle/logs/autoupgrade/${ORACLE_SID}/${ORACLE_SID}/temp/*pfile_${ORACLE_SID}.ora
Note: changing the real one will have no effect!
* If necessary, disable one or more fixups: https://docs.oracle.com/en/database/oracle/oracle-database/19/upgrd/how-to-override-default-fixups.html
===== Post-upgrade =====
* Duplicate and comment out the old line in oratab
vi /etc/oratab
* Check listener startup
vi /etc/lsnrtab
* When listener and tnsnames are setup in 19c home, comment them out in the old home
vi $ORACLE_HOME/network/admin/listener.ora
vi $ORACLE_HOME/network/admin/tnsnames.ora
* Reinitialise database environment in 19c
. oraenv
export TNS_ADMIN="${ORACLE_HOME}/network/admin"
* Check the end time on this file for the end of the upgrade
ls -al /oracle/autoupgrade/logs/${ORACLE_SID}/${ORACLE_SID}/*/postupgrade/postupgrade.log
If POST-UPGRADE erors:
cat /home/oracle/autoupgrade/logs/${ORACLE_SID}/${ORACLE_SID}/*/postfixups/failed_postfixups.log
* Change the password file format
* The format of the password file has changed (new format is version 12.2). It is possible to run 19c database with a legacy password file but sysdba, sysbackup, etc… passwords cannot be changed unless the new format is used (by creating a new password file). This also introduces minimum password complexities that cannot be overruled.
orapwd describe file=${ORACLE_HOME}/dbs/orapw${ORACLE_SID}
orapwd file=${ORACLE_HOME}/dbs/orapw${ORACLE_SID} password=$password force=y
orapwd describe file=${ORACLE_HOME}/dbs/orapw${ORACLE_SID}
* Check for symbolic links in directory names
@?/rdbms/admin/utldirsymlink.sql
* Manage database users
alter profile default limit password_life_time unlimited;
alter user dbsnmp identified by &password account unlock;
alter user system account lock;
alter user sys account lock;
* Remove just upgraded static connection from listener.ora.19c
vi $TNS_ADMIN/listener.ora.19c
* Check 19c tnsnames and listener.ora are not corrupted
If you have static connections, you may find all the homes have changed!
cd $OH19/network/admin
diff sqlnet.ora.19c sqlnet.ora
diff listener.ora.19c listener.ora
diff tnsnames.ora.19c tnsnames.ora
cd -
* Restart listeners
for i in $(ps -ef | grep [t]ns|grep "LSNR_HN"|grep '/19'|awk '{print $10}'); do
echo $i
lsnrctl stop $i
lsnrctl start $i
done
* Check appli connection is in tnsnames.ora
sqlplus cgkmon/$monpass@appli
* Test connection via tns
sqlplus cgkmon/$monpass@"${ORACLE_SID}"
* Change ORACLE_HOME in OEM and Commvault and run a full backup
* Now do user testing
===== Time to set compatible to 19? =====
select * from v$restore_point;
drop restore point &restore_point;
alter system reset db_recovery_file_dest_size sid='*' scope=spfile;
alter system reset db_recovery_file_dest sid='*' scope=spfile;
create pfile from spfile;
* change compatible to '19.0.0'
vi $ORACLE_HOME/dbs/init${ORACLE_SID}.ora
sqlplus / as sysdba <
* Check the password file format is still correct
orapwd describe file=${ORACLE_HOME}/dbs/orapw${ORACLE_SID}
* Check database setup in OEM
* Oracle database : Target Setup : Monitoring Configuration
===== Errors during upgrade =====
$OH19/jdk/bin/java -jar $OH19/rdbms/admin/autoupgrade.jar -config /oracle/scripts/.shb/autoupgrade/autoupgrade_${ORACLE_SID}.cfg -mode analyze
AutoUpgrade tool launched with default options
Processing config file ...
Unable to determine DB unique name for entry upg1
No idea why it fixed the issue but... restrt the database and try again!
https://support.oracle.com/epmos/faces/DocumentDisplay?id=2616365.1
To avoid Java errors like this, XML component must be installed in database.
ERRORS FOUND: During Upgrade
------------------------------------------------------
Identifier CATJAVA 19-04-03 05:53:52
SCRIPT = [/u01/app/oracle/product/18.4.0/dbhome_1/rdbms/admin/initjms.sql]
ERROR = [ORA-29532: Java call terminated by uncaught Java exception:]
STATEMENT = [call sys.dbms_java.loadjava('-v -f -r -s -g PUBLIC rdbms/jlib/aqapi.jar')]
Bug 30483521 is fixed in 20c, but until then:
sqlplus / as sysdba
@?/xdk/admin/initxml.sql
An upgrade failed due to:
BEGIN xdk_drop_package('org/w3c/dom/validation'); END;
*
ERROR at line 1:
ORA-06550: line 1, column 7:
PLS-00905: object SYS.XDK_DROP_PACKAGE is invalid
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
DISK_SPACE_FOR_RECOVERY_AREA:
* Problem
Database check with running exception” (conName="monproda",stage="PRECHECKS",checkName="DISK_SPACE_FOR_RECOVERY_AREA")
and in the log file I see:
2020-06-03 16:49:24.734 INFO
build.hash:255dd7d
build.version:19.9.0
build.date:2020/04/23 15:01:36
build.max_target_version:19
build.supported_target_versions:12.2,18,19
build.type:production
build.label:HEAD
* Solution
create pfile from spfile;
vi init.ora
Check the db_recovery_dest parameter. It had a linefeed in it!
Database [historyt] on stage [POSTFIXUPS] has reported an ERROR status\\
Database [historyt] on stage [POSTFIXUPS] has reported an ERROR status but since -restore_on_fail is set\\
the database will be restored and left as was found. For further details about what caused
the errors, review the log file /home/oracle/autoupgrade/logs/historyt/historyt/121/autoupgrade_20200621_user.log
Processing table WRH$_AWR_TEST_1
declare
*
ERROR at line 1:
ORA-00904: "CON_DBID": invalid identifier
ORA-06512: at line 218
ORA-06512: at line 162
ORA-06512: at line 162
Bug.
19.x:Autoupgrade fails with ORA-00904: “CON_DBID”: Invalid Identifier Error (Doc ID 2602216.1)
* Problem
Issue is identified and triaged under
Bug 29202461 – ORA-00904: “CON_DBID”: INVALID IDENTIFIER EXECUTING AWRUPD12.SQL
* Solution
a) Apply patch 29202461 on 19.x database home ,patch can be downloaded from https://updates.oracle.com/download/29202461.html\\
b) Rerun upgrade\\
or if the prereq's were performed as specified, this will no longer happen.