It has been a longer while – but the Upgrade Dev team worked very hard. And finally, the new AutoUpgrade Tool is available in March 2024. And it brings a ton of new enhancements and features. Some of them, for instance the windows services support, were awaited by you for a long time. Still, there’s much more to talk about.
Photo by Sergey Shmidt on Unsplash
Download the newest version of AutoUpgrade
As usual, you can download it from MOS Note:2485457.1 – Download AutoUpgrade. And when you check the version, you already find some of the new things jumping into your eye:
$ java -jar autoupgrade.jar -version build.version 24.1.240315 build.date 2024/03/15 14:26:29 -0400 build.hash 9109eef02 build.hash_date 2024/03/15 13:36:47 -0400 build.supported_target_versions 12.2,18,19,21,23 build.type production build.label (HEAD, tag: v24.1, origin/stable_devel, stable_devel) build.MOS_NOTE 2485457.1 build.MOS_LINK https://support.oracle.com/epmos/faces/DocumentDisplay?id=2485457.1
The tool tells you now the MOS note and the link to the MOS note, too. And we are checking whether we can offer it also for directly download soon.
New Features, Enhancements and Fixes
The list this time is longer than ever before. We have full Windows support now including the services part and so much more – see below:
New Features
============
AUPG-2602 - Create Windows service after a successful deploy
This feature allows the DBA to handle end-to-end upgrade
and patching operations in Windows. It allows to securely
create the Database Windows service after a successful
execution to leave it up and running ready for connections.
This is an extension of existing functionality on Windows
where there are certain operations to be done manually.
AUPG-2644 - Recompile only objects owned by Oracle-maintained users
This feature reduces downtime for patching and upgrading by
only recompiling invalid objects that are owned by Oracle.
AUPG-2744 - Gather performance statistics to analyze database upgrade
This feature will collect performance statistics during the upgrade
process to evaluate why whole upgrade or certain operations may have
taken long time.
AUPG-2779 - Introduced a new command line parameter to list all prechecks on console
This command will list all our prechecks so a customer can see the
type of checks AutoUpgrade could run during the ANALYZE phase.
AUPG-3097 - Support for passing username/password on environments where
OS Authentication is disabled.
This is for Oracle customers who don't use OS Authentication but
supply a username and password to invoke patching or upgrades.
This feature allows a DBA to securely set a username and password
enabling AutoUpgrade to automate the process.
AUPG-3218 - Support AutoUpgrade to run on Java Runtime Environments from Java 8
to Java 11
AUPG-3278 - Support for patching in normal mode
Patching in normal mode enables the database to stay open
in normal mode throughout the process. In most cases we
can move from the source home to the target home with only
one required restart. This feature allows your applications
to come online before the patching process completes.
AUPG-3415 - Manage parallel degree when creating pluggable databases
This feature improves performance by controlling how many parallel
execution servers are used for the clone functionality.
This is specified using the parallel_pdb_creation_clause
configuration option.
AUPG-3498 - Add -zip_exclusion_list command line option for -zip operation
We now allow an exclusion list feature for any customer who wishes
to exclude certain log files from the zip utility function in
AutoUpgrade.
AUPG-3593 - Support PDB upgrade with the -mode upgrade option
This feature allows customers to manually plug in a database into
an existing container and then upgrade the database.
Enhancements
============
AUPG-1520 - Log the content of the pfile configuration parameters
AUPG-2570 - Log mandatory changes for pfiles
AUPG-2571 - Add trace logging to OS and SQL commands
AUPG-2732 - Use modify parameter on srvctl when calling Datapatch on rollback
AUPG-2737 - If a post fixup failed the post fixup report was not generated
AUPG-2757 - Add more details when there is a database connection issue
AUPG-2760 - Remove clutter from the user log file
AUPG-2794 - Add a better error message when pdb copy option is missing
AUPG-2863 - Add Support for distributed PDBs when calling Datapatch RUs
AUPG-2883 - Synchronize Datapatch reporting
AUPG-2995 - Archive existing status/progress report
AUPG-3008 - Enhance logger to support log line number
AUPG-3031 - Enhance interface DrainStep to support error message
AUPG-3053 - Add Data Guard broker log files to AutoUpgrade zip file
AUPG-3061 - Review and enhance exception report for GRP and PreUpgrade stages
AUPG-3082 - Review and enhance exception report for check and fixup stages
AUPG-3150 - Consolidate and improve status report code
AUPG-3174 - Warn customers that AutoUpgrade is older than 180 days
AUPG-3185 - Code improvement for exception handling in upgrade stage
AUPG-3229 - Improve error handling code in class CheckForErrors
AUPG-3295 - Enhance APPL_PRINCIPAL check for a clear message
on how to resolve the problem
AUPG 3375 - Error message was not clear if the database recovery area was
not present during GRP creation
AUPG-3395 - Copy or merge mgw.ora to the target Oracle Home
AUPG-3396 - Copy or merge drdaas.ora to the target Oracle Home
AUPG-3502 - Display MOS Note and link on -version output
AUPG-3532 - Add option to remove MATERIALIZE and PARALLEL hints
AUPG-3543 - Refactoring code for AutoUpgException handling/reporting
AUPG-3544 - Update oraclepki.jar to version 23 - Update TDE tests using 23.3
AUPG-3550 - Refactoring code for error report of AutoUpgException's subclasses
AUPG-3562 - Removing unused subclasses of AutoUpgException
AUPG-3583 - Refactor code for unhandled exceptions under dispatcher
AUPG-3637 - Support Commons-cli version 1.6
AUPG-3671 - Improve ORDIM_DESUPPORT check for performance
AUPG-3728 - Refreshable Pdb clones now do one last refresh prior to
and upgrade or patch operation
BUG-31774043 - Include the application Root container for any application Pdb
that is getting upgrade.
BUG-33855672 - Autoupgrade refreshes state information into both state.html and now
in state.txt file
BUG-35565792 - Customize the frequency of status messages for -noconsole mode
This can be adjusted with json_progress_writing_interval
configuration parameter. Defaults to 30 seconds.
BUG-35719923 - Include MOS Note NUMBER for BAND4_JPEG_EXIST precheck message
BUG-35898251 - Include user VECSYS as part of Oracle's reserved users
BUG-36122220 - Validate Oracle Database editions
Change in behavior
==================
AUPG-3136 - Added MAX_CONNECTIONS_DESUPPORT check for 19c the MAX_CONNECTIONS
attribute of LOG_ARCHIVE_DEST_# parameter will be ignored and desupported
AUPG-3556 - Remove WALLET_ROOT check when converting database to a PDB
AUPG-3278 - AutoUpgrade now defaults patching to run in normal mode
patch_in_upgrade_mode=YES will revert this behavior
AUPG-3669 - Disable SC_QI_DBA_DIRECTORIES check until redesign specifically
or out-of-place patching
BUG-35566068 - AutoUpgrade on RAC now honors the role assignment of
the service when opening the pdbs
BUG-32047852 - Added CTX_SHADOW_INDEX check verifies Oracle Text (CONTEXT)
shadow indexes are not present before upgrading to 23c
BUG-32805981 - Added PERMIT_92_WRAP_FORMAT check as this initialization
parameter is deprecated in 21
BUG-33963753 - Added LCTR_REMOVE check Oracle Locator (LCTR) will be removed on
upgrade and Oracle Spatial (SDO) will be installed instead in 23c
BUG-34210203 - Added UNIFIED_AUDIT_ON check as traditional audit has been deprecated
since release 21c, is desupported starting with Release 23c
BUG-35009706 - Added OLS_OID_CONFIGURED check, starting with 23c, Oracle Label
Security (OLS) should not be configured using Oracle Internet
Directory (OID) since the feature is being desupported
BUG-35015333 - Added LCTR_SDO_CHECK check for the existence of locator objects
exist in MDSYS schema and Oracle Spatial (SDO) is not installed
yet, then SDO will be installed during the database upgrade to 23c
BUG-35165189 - Added TDE_PKI_MK_IN_USE check for 23c, the use of PKI-based
master key as the TDE master key is not supported
BUG-35165337 - Added TDE_TSENC_NON_AES_FIPS_IN_USE check verifying the use of
non-AES (Advanced Encryption Standard) algorithms for tablespace
encryption is not supported in FIPS mode for 23c
BUG-35165412 - Added TDE_COLENC_NON_AES_FIPS_IN_USE check verifying the use of non-AES
(Advanced Encryption Standard) algorithms for column encryption
is not supported in FIPS mode for 23c
BUG-35165462 - Added TDE_COLENC_SEED_GOST_IN_USE check to verify the use of SEED and GOST
algorithms for column encryption is not supported in 23c
BUG-35165494 - Added TDE_WALLET_ROOT_NOT_IN_USE Check for Transparent Data
Encryption (TDE) configuration requires use of initialization
parameters WALLET_ROOT and TDE_CONFIGURATION. sqlnet.ora parameter
ENCRYPTION_WALLET_LOCATION is desupported in 23c
BUG-35219675 - Added EM_EXPRESS_PRESENT check to verify Enterprise Manager Database Express is
no longer present. Any EM Express specific files and objects will removed
from your database during the upgrade to 23c
BUG-35510222 - Added BAND4_JPEG_EXIST check to detect JPEG compression
and decompression which cannot be applied on 4-band raster
blocks of a GeoRaster object for 23c.
Added Checks
============
AUPG-2829 - DBLINK_ISVALID Check validates that every cloned PDB will have a properly configured dblink
AUPG-2874 - COMPATIBLE_STANDBY check for both the primary and standby
databases to ensure they are the same
AUPG-3216 - OLS_DEFAULT_AUDIT_POLICY check for ORA_OLS_AUDPOL is a reserved
name for an Oracle-defined unified audit policy
AUPG-3373 - DICTIONARY_PROTECTED_OBJECTS check for objects present under
the DICTIONARY PROTECTED schema
AUPG-3414 - UPDATE_SYS_DIRECTORIES check to update sys directories in
the target home after patching
AUPG-3558 - OS_AUTHENTICATION check to verify source and target OS
authentication discrepancies
BUG-35349721 - Include Data Pump cloud roles in the ORACLE_RESERVED_USERS check
BUG-35418032 - DV_AUDIT_USED check to encourage customers to use
Unified Audit instead of Oracle Database Vault (DV)
Traditional Audit for auditing DV related activities in 23c
BUG-35431458 - Include Graph roles to the ORACLE_RESERVED_USERS check
BUG-35435649 - Remove File Group Objects from the ORACLE_RESERVED_USERS check
BUG-35809523 - UNIAUD_CLI_SWP check for Unified Audit records stored in
common logging infrastructure (CLI) SGA back-end tables should
be transferred to internal relational tables for better read
performance in 23c
Fixes added
===========
AUPG-2795 - Corrected unplug-relocate to take local pdb name in analyze mode
AUPG-2800 - noncdbtopdb with relocation on the same system produced an error
if the pdb list was not present
AUPG-2805 - Timezone upgrade missing log file when reporting errors
AUPG-3711 - Refreshable PDBs require a last refresh before stopping
AUPG-3712 - NullPointer exception occurred when configuration file option
upgradexml was set to NO
AUPG-3722 - Autoupgrade on Windows does not detect the service in
Korean and Portuguese languages
AUPG-3746 - PDBs were in mount state instead of open state in a RAC cluster
BUG-36265629 - PDBs are in the wrong state when validation if performed
Bug-36326216 - SPFILE already in use when ASM is used and not registered in RAC
Kudos to the Upgrade Development Team!!
–Mike
Hi Mike
I patched 19.19 to 19.21 with autoupgrade.jar version 24.1.240315.
1) Mandatory changes are required to perform the upgrade.
Parameter local_listener=remove
why?
2)
patch1.source_home=/oracle/orahome19
patch1.target_home=/oracle/orahome19p
patch1.sid=DBNAME
patch1.patch_in_upgrade_mode=no
Database shutdown and startup: Using parameter settings in client-side pfile /oracle/tmp/au_logs/DBNAME/temp/after_upgrade_pfile_twfa.ora
and DBUPGRADE – SUCCESS.
not spfile! with temp_pfile) bad bad bad.
and need restart database…
Hi Alex,
can you please share the logs with us?
Please collect them with:
java -jar autoupgrade.jar -config myconfig.cfg -zip
and add them to an SR. Share the SR number with me, and I share it with the dev team right away. I know that we created and tested a new version over the weekend since there was an issue with the SPFILE. And the “restart” is unfortunately still expected.
Cheers,
Mike
I also can confirm both issues.
I patched 19.21 to 19.23 with autoupgrade.jar build.version 24.4.240426 – nothing has changed( started with temp_pfile
Hi Mike,
I’ve been testing with patching in a Virtualbox VM from 19.21 to 19.22.
My Oracle Home user is a local Windows account (oracle)
I have installed the Oracle Homes using an account that is a member of ORA_DBA and has administrator privilege.
My patch,conf looks like this:
global.autoupg_log_dir=C:\app\oracle\Patch1922
#
# Database number 1 – Full DB/CDB upgrade
#
patch1.log_dir=C:\app\oracle\C19T1
patch1.sid=C19T1
patch1.source_home=C:\app\oracle\product\1921\dbhome_1
patch1.target_home=C:\app\oracle\product\1922\dbhome_1
patch1.start_time=NOW
patch1.upgrade_node=WIN2019AUTOUPG
patch1.run_utlrp=yes
patch1.timezone_upg=yes
patch1.wincredential=C:\app\oracle\Patch1922\cred
I start saving the credential for user oracle:
Set ORACLE_HOME=C:\app\oracle\product\1922\dbhome_1
%ORACLE_HOME%\jdk\jre\bin\java -jar %ORACLE_HOME%\rdbms\admin\autoupgrade.jar -config c:\app\oracle\Patch1922\patch.conf -load_win_credential patch1
C19T1.xml is created fine.
Than I start analyze, fixups and deploy (all on the same server)
%ORACLE_HOME%\jdk\jre\bin\java -jar %ORACLE_HOME%\rdbms\admin\autoupgrade.jar -config c:\app\oracle\Patch1922\patch.conf -mode deploy
Patching seems to work fine however the spfile is not created in the new %ORACLE_HOME%\database directory
error in the logfile:
2024-03-26 23:19:41.734 INFO Error opening file [C:\app\oracle\product\1922\dbhome_1\database\initC19T1.ora] for reading
2024-03-26 23:19:43.032 ERROR
DATABASE NAME: C19T1
CAUSE: ERROR at Line 4 in [Buffer]
REASON: ORA-01078: failure in processing system parameters
ACTION: [MANUAL]
DETAILS:
2024-03-26 23:19:43.047 ERROR
DATABASE NAME: C19T1
CAUSE: ERROR at Line 5 in [Buffer]
REASON: LRM-00109: could not open parameter file ‘C:\APP\ORACLE\PATCH1922\C19T1\C19T1\TEMP\AFTER_UPGRADE_PFILE_C19T1.ORA’
ACTION: [MANUAL]
DETAILS:
2024-03-26 23:19:43.047 ERROR SPFILE creation encountered the following error oracle.upgrade.autoupgrade.utils.errors.UPG1407: Creating spfile failed
…
when I try to create the spfile manually:
SQL> create spfile from pfile=’C:\APP\ORACLE\PATCH1922\C19T1\C19T1\TEMP\AFTER_UPGRADE_PFILE_C19T1.ORA’;
create spfile from pfile=’C:\APP\ORACLE\PATCH1922\C19T1\C19T1\TEMP\AFTER_UPGRADE_PFILE_C19T1.ORA’
*
ERROR at line 1:
ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file
‘C:\APP\ORACLE\PATCH1922\C19T1\C19T1\TEMP\AFTER_UPGRADE_PFILE_C19T1.ORA’
I have to grant the oracle user access to the file C:\APP\ORACLE\PATCH1922\C19T1\C19T1\TEMP\AFTER_UPGRADE_PFILE_C19T1.ORA
after the grant I can create the spfile manually.
My question:
I understand from the documentation that I should not run autoupgrade using the ORACLE_HOME user (oracle)
Can I run autoupgrade using the installation user with elevated privileges (administrator)
The user (oracle) used to run the OracleService is missing the privilege to read the file AFTER_UPGRADE_PFILE_C19T1.ORA
What exact privilege does the user running autoupgrade need?
Should I use an other directory for global.autoupg_log_dir or patch1.log_dir?
Kind regards
Erwin
Hi Erwin,
I guess you are using the new AU tool since you commented on the blog post.
Can you please create the zip file
java -jar autoupgrade.jar -config yourconfig.cfg -zip
upload to an SR, and share the SR number with me via email?
Then I have the team look into it right away – but I will need your logs.
mike.dietrich ….. at … oracle.com
Cheers,
Mike
Hi Mike,
I sent you an email containing the SR number I created at oracle support.
Cheers,
Erwin
Hi Erwin,
I forwarded it to the team. There is a new kit done right now as there was a general issue with the SPFILE.
Should be hopefully public early next week. Meanwhile, you can use the previous one – it didn’t have the issue with the SPFILE.
Sorry for that 🙁
Cheers,
Mike
Hi Mike,
I was hoping to benefit from AUPG-2602.
I guess I’ll have to wait for the new kit to be published.
I hope AUPG-2602 both addresses the creation of the Windows Service for a local Windows account and built-in Local System account, because we have customers with both types of configuration.
Thanks
Hi Erwin,
we had to create two new revisions of the tool 🙁
Please try out the most recent one.
Cheers,
Mike
Hello Mike,
I have found 2 problems in the autoupgrade tool [Severity 3 SR 3-36053929801 : autoupgrade failed with error UPG-4016]:
Call:
$ORACLE_HOME/jdk/bin/java -jar autoupgrade_20240315.jar -config config.cfg -mode deploy
config.cfg:
global.autoupg_log_dir=/WORK/DUMP/install/UPGRADE/autoupgrade_2
upg1.log_dir=/WORK/DUMP/install/UPGRADE
upg1.sid=NONCDB
upg1.source_home=/DBA/oracle/product/19.3.0.0SE
upg1.target_cdb=CDB
upg1.source_dblink.NONCDB=clone_link 300
upg1.target_home=/DBA/oracle/product/19.3.0.0EE
upg1.target_pdb_name.NONCDB=PDB2
upg1.target_pdb_copy_option.NONCDB=file_name_convert=NONE
upg1.start_time=11/04/2024 15:10:00
1 Error: clonepdb error from autoupgrade (output) autoupgrade produces a non-functioning sql
create pluggable database “PDB2” as clone FROM NONCDB@clone_link file_name_convert=NONE tempfile reuse REFRESH MODE MANUAL [with error]
create pluggable database “PDB2” FROM NONCDB@clone_link file_name_convert=NONE tempfile reuse REFRESH MODE MANUAL [without error, customized by me and executed manually]
autoupgrade with debug showed me the error:
select guid || ‘-‘ || dbid from v$containers where lower(name) = lower(‘NONCDB’);] is:
[Session altered., AutoUpgrade###login.sql DONE###AutoUpgrade, 50BB80149B022581E05385D1060ACA18-1045556296] – SQLClient.filterResult#247
select CON_ID||’:_:’||DBID||’:_:’||GUID||’:_:’||NAME||’:_:’||APPLICATION_ROOT||’:_:’||APPLICATION_PDB||’:_:’||APPLICATION_SEED||’: _:’||NVL(TO_CHAR(APPLICATION_ROOT_CON_ID),’N/A’)||’:_:’||APPLICATION_ROOT_CLONE||’:_:’||PROXY_PDB||’:_:’||CON_ID from sys. v$containers where con_id > 1 order by con_id;] is:
[Session altered.., AutoUpgrade###login. sql DONE###AutoUpgrade, 2:_:3692798199:_:10409DCFD4953D3AE06385D1060A29D0:_:PDB$SEED:_:NO:_:NO:_:NO:_:N/A:_:NO:_:NO:_:2, 3:_:825465428:_:50BB80149B022581E05385D1060ACA18: _:PDB1:_:NO:_:NO:_:NO:_:N/A:_:NO:_:NO:_:3, 4:_:1839036898:_:13FF7FD684A50E57E06385D1060A3C12:_:PDB2:_:NO:_:NO:_:NO:_:N/A:_:NO:_:NO:_:4] – SQLClient. filterResult#247
I have 2 databases with the same GUID, this came from a duplicate of the NONCDB database.
2 errors: clonedb with parallel over DBlink at EE with many CPU’s
create pluggable database “PDB2” FROM NONCDB@clone_link file_name_convert=NONE tempfile reuse REFRESH MODE MANUAL
2024-04-09T14:18:31.856345+02:00
Errors in file /DBA/nest/oracle/diag/rdbms/cdb/cdb/trace/cdb_p00u_30335.trc:
ORA-17627: ORA-01017: invalid username/password; logon denied
with
create pluggable database “PDB2” FROM NONCDB@clone_link PARALLEL 1 file_name_convert=none tempfile reuse REFRESH MODE MANUAL
there was no error over the dblink.
maybe you can make these errors known (or fix them), the troubleshooting took me a lot of time.
Hi Martin,
thanks – I alerted the team!
Cheers,
Mike
Hi, Mike. Upgrading on Windows from 12.2.0.1 to 19.22 failed à 97% twice with same error below :
2024-04-18 11:43:33.290 INFO
build.version:24.1.240315
build.hash:9109eef02
build.date:2024/03/15 14:26:29 -0400
build.max_target_version:23
build.MOS_NOTE:2485457.1
build.supported_target_versions:12.2,18,19,21,23
build.type:production
build.MOS_LINK:https://support.oracle.com/epmos/faces/DocumentDisplay?id=2485457.1
build.label:(HEAD, tag: v24.1, origin/stable_devel, stable_devel)
build.hash_date:2024/03/15 13:36:47 -0400
2024-04-18 11:43:33.384 INFO Starting
2024-04-18 11:43:33.462 INFO Starting
2024-04-18 11:44:36.789 INFO Total Number of phases is 108
2024-04-18 11:44:36.993 INFO Executing ALTER SYSTEM SET PLSQL_WARNINGS=’DISABLE:ALL’;scope1
2024-04-18 11:44:37.164 INFO Begin Upgrade on Database [scope1]
2024-04-18 11:44:37.180 INFO Replay enabled for null
2024-04-18 11:44:42.407 INFO 0%Upgraded
2024-04-18 11:46:42.897 INFO 3%Upgraded
2024-04-18 11:48:43.378 INFO 10%Upgraded
2024-04-18 11:50:43.822 INFO 19%Upgraded
2024-04-18 11:52:44.350 INFO 21%Upgraded
2024-04-18 11:54:44.880 INFO 23%Upgraded
2024-04-18 11:56:45.440 INFO 37%Upgraded
2024-04-18 11:58:45.924 INFO 41%Upgraded
2024-04-18 12:00:46.507 INFO 49%Upgraded
2024-04-18 12:02:47.026 INFO 49%Upgraded
2024-04-18 12:04:47.588 INFO 49%Upgraded
2024-04-18 12:06:48.103 INFO 88%Upgraded
2024-04-18 12:08:48.536 INFO 91%Upgraded
2024-04-18 12:10:49.003 INFO 91%Upgraded
2024-04-18 12:13:10.693 INFO 93%Upgraded
2024-04-18 12:14:43.980 ERROR
DATABASE NAME: scope1
CAUSE: ERROR at Line 100032 in [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope12.log]
REASON: SP2-0556: Invalid file name.
ACTION: [MANUAL]
DETAILS:
2024-04-18 12:14:43.996 ERROR Database Error in File [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope12.log] on Database [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope12.log]
2024-04-18 12:14:44.308 ERROR
DATABASE NAME: scope1
CAUSE: ERROR at Line 66321 in [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope13.log]
REASON: SP2-0556: Invalid file name.
ACTION: [MANUAL]
DETAILS:
2024-04-18 12:14:44.355 ERROR
DATABASE NAME: scope1
CAUSE: ERROR at Line 75360 in [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope13.log]
REASON: SP2-0556: Invalid file name.
ACTION: [MANUAL]
DETAILS:
2024-04-18 12:14:44.355 ERROR Database Error in File [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope13.log] on Database [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope13.log]
2024-04-18 12:14:44.589 ERROR
DATABASE NAME: scope1
CAUSE: ERROR at Line 53054 in [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope14.log]
REASON: SP2-0556: Invalid file name.
ACTION: [MANUAL]
DETAILS:
2024-04-18 12:14:44.605 ERROR Database Error in File [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope14.log] on Database [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope14.log]
2024-04-18 12:14:44.808 ERROR
DATABASE NAME: scope1
CAUSE: ERROR at Line 40914 in [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope15.log]
REASON: SP2-0556: Invalid file name.
ACTION: [MANUAL]
DETAILS:
2024-04-18 12:14:44.855 ERROR
DATABASE NAME: scope1
CAUSE: ERROR at Line 53520 in [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope15.log]
REASON: SP2-0556: Invalid file name.
ACTION: [MANUAL]
DETAILS:
2024-04-18 12:14:44.902 ERROR
DATABASE NAME: scope1
CAUSE: ERROR at Line 63433 in [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope15.log]
REASON: SP2-0556: Invalid file name.
ACTION: [MANUAL]
DETAILS:
2024-04-18 12:14:44.902 ERROR
DATABASE NAME: scope1
CAUSE: ERROR at Line 64994 in [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope15.log]
REASON: SP2-0556: Invalid file name.
ACTION: [MANUAL]
DETAILS:
2024-04-18 12:14:44.918 ERROR Database Error in File [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope15.log] on Database [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope15.log]
2024-04-18 12:14:45.074 ERROR
DATABASE NAME: scope1
CAUSE: ERROR at Line 36977 in [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope16.log]
REASON: SP2-0556: Invalid file name.
ACTION: [MANUAL]
DETAILS:
2024-04-18 12:14:45.164 ERROR
DATABASE NAME: scope1
CAUSE: ERROR at Line 57776 in [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope16.log]
REASON: SP2-0556: Invalid file name.
ACTION: [MANUAL]
DETAILS:
2024-04-18 12:14:45.189 ERROR Database Error in File [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope16.log] on Database [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope16.log]
2024-04-18 12:14:45.642 ERROR
DATABASE NAME: scope1
CAUSE: ERROR at Line 103916 in [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope17.log]
REASON: SP2-0556: Invalid file name.
ACTION: [MANUAL]
DETAILS:
2024-04-18 12:14:45.689 ERROR Database Error in File [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope17.log] on Database [C:\app\oracle\cfgtoollogs\autoupgrade\scope1\100\dbupgrade\catupgrd20240418114333scope17.log]
2024-04-18 12:14:45.689 ERROR UPGRADE FAILED [scope1]
2024-04-18 12:14:45.705 ERROR Exception Error in Database [UPG-1400#UPGRADE FAILED [scope1]]
2024-04-18 12:14:45.705 INFO End Upgrade on Database [scope1]
2024-04-18 12:15:45.120 INFO 97%Upgraded
2024-04-18 12:15:50.316 INFO Executing ALTER SYSTEM SET PLSQL_WARNINGS=’DISABLE:ALL’;scope1
2024-04-18 12:16:50.237 ERROR Exception Error in Database [scope1]
oracle.upgrade.autoupgrade.utils.errors.UPG1400: UPGRADE FAILED [scope1]
Please note that we are upgrading and moving to new server. It seems that the only error we’ve found in logs is “SP2-0556: Invalid file name.”. After upgrade stopped we ran autoupgrade again and POSTCHEKCS, POSTFIXUPS and SYSUPDATES stage run without any error. All components listed as upgraded.
Thanks – and I have a suspicion what this could be.
But if you want to find out (I am not a windows PRO) you would need an SR, please.
Thanks
Mike
Hello Mike,
we tried to do a very simple upgrade with the new autoupgrade release.
Single database 12c, upgrade to 19.22
no RAC, no DataGuard, no multitenant – really very simple.
The only obstacle appears to be Windows.
We get UPG-1699 and “More help is available by typing NET HELPMSG 2185” – means it has something to do with Windows-Services.
We have an SR 3-36235119421, but no solution since 3 weeks.
Hopefully you have an idea what the real problem is.
best regards
Dieter
Hi Dieter,
I did look at your SR (I am traveling for over a week now).
Unfortunately, I have no silver bullet to solve the issue. At first sight, this looks to me as an issue with the user/admin rights, and then as a result the “visibility” from one to another env.
This is all happening on the same server, right?
Then let’s try the following:
1. Grab the newest AU version from a few days ago and try again – it has better Windows support
2. Try to move away the glogin.sql – you can move it back later
3. Try to run AutoUpgrade in the source environment with “-mode analyze”, and then “-mode fixups”
Then drop the windows service for the database (I hope the tool is still “oradim”).
Move the files in “/database” to the new home (passwordfile, spfile etc).
Don’t forget the network files.
Create the new service in the new environment with oradim.
Then start the database in “upgrade” mode.
Now invoke autoupgrade.jar with “-mode upgrade”.
One thing you need to take into consideration:
When the database is in NOARCHIVELOG mode, you must set UPG1.RESTORATION=NO in the AU config file – and then you must take care on the ability to restore when it fails.
Cheers,
Mike
Hi Mike,
thank you for your help. We could solve the problem now, but it was not about your action plan. We had already the very latest AU, the glogin already removed, the DB in archive-mode and the -fixups did not reveal new items to do.
It was all about the rights!
And this is a Windows thing!
Years ago, the DB was installed by an AD-user. This user left the company and later we got another AD-useraccount to use ‘dbsupport’.
A reboot of the server, last week accomplished the mess because permissions went active after reboot.
With that, the old owner of the DB-files was not existing anymore and the new had no permissions to access the DB-files 🙁
After the reboot, we could neither start listener, DB nor services :-((
What we did was:
– check if the new user is member of the group ‘Administrators’ (it was already)
– add the user to the groups ‘ora_dba’ , ‘ORA12c_DBA’ and ‘ORA_DB19Home2_DBA’
– take over the ownership of all Oracle-relevant files (Oracle-Base, oraInventory, Datafile-firectory, FRA) and inherit to subdirectories and files.
– give ‘Full Control’ to all these directories and files for groups ‘Administrators’, ‘ora_dba’ , ‘ORA12c_DBA’ and ‘ORA_DB19Home2_DBA’
– replace the somehow corrupted listener.ora
– start the listener (the Windows-Service was created automatically, as expected)
– remove the old Windows-Services for the DB
– remove a Windows-Service for the AutoUpgrade
– create new Services by ORADIM
– start the database
– run datapatch again (it reported ‘nothing to do’)
Maybe, maybe we have given too mighty permission to too many groups. However it works with that.
On Windows one “could” install like on Linux with connecting always as local user “oracle” to the Server. This avoid such mismatch.
Hopefully, this information will find it’s way to the “administrators-reference-guide-microsoft-windows”. At least, I will write a blog about that.
best regards and I would like to say that I love your Blog.
Dieter
Thank you, Dieter!!!
And so glad you could solve it finally!
Cheers,
Mike
Hi Mike,
Yesterday we patched a number of databases from 19.20 to 19.22 with autoupgrade. Most CDB’s were finished within a reasonable time, but 1 (with 4 PDB’s) took 5 hours to complete.
I investigated this and found out that the new check “UPDATE_SYS_DIRECTORIES” was responsible for this. The runtime of this check depends on the number of directories, and these PDB’s have around 45 directories each.
The check seems to run this query:
“SELECT COUNT(1) FROM DBA_DIRECTORIES D, DBA_OBJECTS O WHERE D.DIRECTORY_PATH LIKE ‘/app/oracle/19.20_rdbms_01%’ OR D.DIRECTORY_PATH = ‘N/A’ AND D.DIRECTORY_NAME = O.OBJECT_NAME AND O.OBJECT_TYPE = ‘DIRECTORY’;”
and when I run this query, it takes about 20 minutes.
When I put the ‘OR’-part between parentheses the query takes only a few seconds, so I think that could solve the issue. For now we will skip the check for databases with a lot of directories.
Best regards,
Jan Willem
Hi Jan Willem,
thanks for this hint. I will pass this on to the team.
Could you kindly let me know if you have an SR open, and share the number with me in case you have?
Thanks for this information – this is very useful to know.
Thanks,
Mike
Hi Mike.
24.3.240419, GI 19.22, source DB Oracle 12.1.0.2.220712, target 19.22
I am getting this exception 100%. My FRA is in ASM, size 6Tb. Even if I make it smaller, or switch FRA to filesystem, I still get the space check error.
============================ check info ============================
[CDB$ROOT][DISK_SPACE_FOR_RECOVERY_AREA][ERROR]
============================ check info ============================
=========================== trace start ==============================
Exception: ArrayIndexOutOfBoundsException
Err message: 3
java.lang.ArrayIndexOutOfBoundsException: 3
at oracle.upgrade.commons.helpers.Utilities.getASMUsableSpace(Utilities.java:790)
at oracle.upgrade.commons.helpers.Utilities.getUsableSpace(Utilities.java:921)
at oracle.upgrade.commons.dbinspector.checks.disk_space_for_recovery_area.checkCode(disk_space_for_recovery_area.java:188)
I don’t know how to get around this! Can you suggest please?
Hi Nick,
I think there was an issue in the initial March version of AU.
Could you please try with a newer version we uploaded right after?
Thanks
Mike
Hi Mike
Issue was resolved when DIAG_ADR_ENABLED=NO was commented in sqlnet.ora.
Thanks for the help from your team!
Thank you, Nick!!
Cheers,
Mike
Cause:[Unexpected exception error] in DRAIN phase
Reason:Shutting down database in DRAIN phase
Action:ABORTDear Mike,
we tried AutoUpgrade-Patching on Windows-Server (CPU: 19.21 –> 19.22) with new version of AU-Tool (build.version 24.4.240426).
After the automatic deletion of the old OracleService from 19.21-Oracle-Home and creation of the new OracleService from the new 19.22-Oracle-Home we are hitting an ERROR “UPG1706” while in drain stage:
Info:Check C:\temp\AutoUpgrade\Logs\CPADBAB\100\autoupgrade_20240514.log at line 9924
ExecutionError:Yes
Error Message:[Unexpected exception error]
autoupgrade_202405.log
=====================
2024-05-14 11:11:02.675 INFO Completed starting background threads for [oracle.upgrade.autoupgrade.dispatcher.facade.subsystems.ExecuteDrain] – JobStage.startThreads#162
2024-05-14 11:11:02.675 INFO Executing stage DRAIN of job 100 – RunJobDefinition.runJob#139
2024-05-14 11:11:02.675 INFO Running JobStageAction [oracle.upgrade.autoupgrade.dispatcher.facade.subsystems.ExecuteDrain] – JobStage.executeStage#78
2024-05-14 11:11:02.706 INFO Starting drain – ExecuteDrain.executeStage#106
2024-05-14 11:12:05.461 INFO End – AutoUpgDrainActions.runDrainActions#342
2024-05-14 11:12:05.477 WARNING Execution of the JobStageAction [oracle.upgrade.autoupgrade.dispatcher.facade.subsystems.ExecuteDrain] failed due to [oracle.upgrade.autoupgrade.utils.errors.AutoUpgException] – JobStage.executeStage#82
oracle.upgrade.autoupgrade.utils.errors.AutoUpgException: AutoUpgException [The service name is invalid.
More help is available by typing NET HELPMSG 2185.
]
at oracle.upgrade.autoupgrade.drain.AutoUpgDrainActions.runDrainActions(AutoUpgDrainActions.java:260)
at oracle.upgrade.autoupgrade.dispatcher.facade.subsystems.ExecuteDrain.executeStage(ExecuteDrain.java:107)
at oracle.commons.dispatcher.JobStage.executeStage(JobStage.java:80)
at oracle.commons.dispatcher.RunJobDefinition.runJob(RunJobDefinition.java:142)
at oracle.upgrade.autoupgrade.dispatcher.v2.def.RunAutoUpgradeJob.executeDispatcher(RunAutoUpgradeJob.java:62)
at oracle.upgrade.autoupgrade.dispatcher.AutoUpgDispatcher.run_(AutoUpgDispatcher.java:261)
at oracle.upgrade.autoupgrade.dispatcher.AutoUpgDispatcher.run(AutoUpgDispatcher.java:244)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)
Caused by: oracle.upgrade.autoupgrade.utils.errors.UPG1706: The service name is invalid.
More help is available by typing NET HELPMSG 2185.
at oracle.upgrade.autoupgrade.dispatcher.helper.drainhelper.windows.WindowsWork.process(WindowsWork.java:120)
at oracle.upgrade.autoupgrade.dispatcher.helper.drainhelper.windows.StartService.action(StartService.java:102)
at oracle.upgrade.autoupgrade.dispatcher.helper.drainhelper.windows.CreateService.executeActualServiceCreation(CreateService.java:180)
at oracle.upgrade.autoupgrade.dispatcher.helper.drainhelper.windows.CreateService.runDeployUpgradeServiceCreation(CreateService.java:124)
at oracle.upgrade.autoupgrade.dispatcher.helper.drainhelper.windows.CreateService.action(CreateService.java:102)
at oracle.upgrade.autoupgrade.dispatcher.helper.DispatcherHelperEngine.executeWindowsWork(DispatcherHelperEngine.java:128)
at oracle.upgrade.autoupgrade.dispatcher.helper.DispatcherHelperEngine.windowsWork(DispatcherHelperEngine.java:176)
at oracle.upgrade.autoupgrade.drain.WindowsWork.executeStep(WindowsWork.java:61)
at oracle.upgrade.autoupgrade.drain.AutoUpgDrainActions.runDrainActions(AutoUpgDrainActions.java:258)
… 13 more
2024-05-14 11:12:05.477 INFO The status of the JobStageAction [oracle.upgrade.autoupgrade.dispatcher.facade.subsystems.ExecuteDrain] was [false] – JobStage.executeStage#86
2024-05-14 11:12:05.477 INFO Stopping background threads for [oracle.upgrade.autoupgrade.dispatcher.facade.subsystems.ExecuteDrain] – JobStage.stopThreads#169
2024-05-14 11:12:05.477 INFO Completed stopping background threads for [oracle.upgrade.autoupgrade.dispatcher.facade.subsystems.ExecuteDrain] – JobStage.stopThreads#171
2024-05-14 11:12:05.477 INFO Stopping background threads for Job – JobDefinition.stopJobThreads#132
2024-05-14 11:12:05.477 INFO [0] threads have been stopped by JobDefinition – JobDefinition.stopJobThreads#134
2024-05-14 11:12:05.477 INFO Dispatcher finished for 100 – RunJobDefinition.runJob#175
2024-05-14 11:12:05.477 INFO End – RunJobDefinition.runJob#176
2024-05-14 11:12:05.477 ERROR Dispatcher failed: AutoUpgException [The service name is invalid.
….
drain_cpadbab.log
===============
2024-05-14 11:12:05.461 INFO [B58935] End Oracle Home=C:\Oracle19\19_22 Oracle Sid=CPADBAB Run command =[net, start, OracleServiceAutoUpgradeCPADBAB] Command=None Filename=None – ExecuteProcess.doCmds#864
2024-05-14 11:12:05.461 INFO [B58935] The process ended with an exit value 2 and the following output
The service name is invalid.
More help is available by typing NET HELPMSG 2185.
– ExecuteProcess.doCmds#873
2024-05-14 11:12:05.461 INFO [B58935] Starting – ExecuteProcess.destroyProcess#900
2024-05-14 11:12:05.461 INFO [B58935] Begin Exiting process – ExecuteProcess.destroyProcess#903
2024-05-14 11:12:05.461 INFO [B58935] End Exiting process – ExecuteProcess.destroyProcess#905
2024-05-14 11:12:05.461 INFO [B58935] Finished – ExecuteProcess.destroyProcess#907
2024-05-14 11:12:05.461 INFO [B58935] Finished – ExecuteProcess.doCmds#889
2024-05-14 11:12:05.461 INFO Result: The service name is invalid.
More help is available by typing NET HELPMSG 2185.
– WindowsWork.process#111
2024-05-14 11:12:05.461 ERROR Drain failed: The service name is invalid.
More help is available by typing NET HELPMSG 2185.
– DispatcherHelperEngine.executeWindowsWork#132
credentials on oracle service user have been stored correctly in the cred-file.
best regards
Marco
Hi Marco,
I guess we had a conversation in email already with the team, right?
Cheers,
Mike
Hi Mike,
aye we did. The post was prio the email conversation.
best regards,
Marco
Hi Mike,
looks like there is still a little bug within the AU (V. 24.4.240426) while procesing postfixups:
“Database fixup failed with a runtime exception” (conName=”SFTEST”, stage=”POSTFIXUPS”, checkName=”UPDATE_SYS_DIRECTORIES”)”
we’re on CDBs (multitenant) and “check reports” is warning us:
Recreate the affected directory objects once the database has been patched in the target Oracle home to reference the new ORACLE_HOME and ORACLE_BASE directories.
Script rdbms/admin/utlfixdirs.sql can be used to accomplish this.
1) Run this script in a non-CDB in SQL*Plus:
@?/rdbms/admin/utlfixdirs.sql
2) Run this script in a CDB on command line:
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -b fixdirs -d $ORACLE_HOME/rdbms/admin -n [N pdbs in parallel] -l /tmp -r utlfixdirs.sql
after the AU-Patching is done the fixup report shows up with error “UPDATE_SYS_DIRECTORIES – Runtime Error”
Exception: SQLException Err message:
Errors executing [@@C:\Oracle19\19_22\rdbms\admin/utlfixdirs.sql Session altered.
Session altered.
Session altered.
Session altered.
AutoUpgrade###login.sql DONE###
AutoUpgrade Container: SFTEST Current ORACLE_HOME: c:\Oracle19\19_22
Original ORACLE_HOME: C:\Oracle19c SDO_DIR_ADMIN …OLD: C:\Oracle19c/md/admin
DECLARE * ERROR at line 1: ORA-65040: operation not allowed from within a pluggable database ORA-06512: at line 112 ORA-06512: at line 112 ]
[SFTEST] java.sql.SQLException: Errors executing
….
looks like AU is executing the wrong SQL for singetenant DBs.
after manually executing the correct statement “%ORACLE_HOME%/perl/bin/perl %ORACLE_HOME%/rdbms/admin/catcon.pl -b fixdirs -d %ORACLE_HOME%/rdbms/admin -n 1 -l /tmp -r utlfixdirs.sql”
all directory entries are fixed.
best regards
Marco
Hi Marco,
I think we exchanged mails about this already, right?
Thanks,
Mike
Hi Mike,
yes we did.
Regards,
Marco
Hi Mike, I have a problem with using lates AutoUpgrade Tool during database patching on Windows OS. Our database services are running under GMSA (Global Managed Service Account) because our security department requires it.
During patching the AutoUpgrade Tool crashes because a temporary Windows service is created, e.g. OracleServiceAutoUpgradeDB48DEV4 running under the target ORACLE_HOME as “Local System” but not under the GMSA account and it cannot log in to the instance using “sqlplus / as sysdba”
upg>
————————————————-
Errors in database [DB48DEV4]
Stage [DBUPGRADE]
Operation [STOPPED]
Status [ERROR]
Info [
Error: UPG-1401
Opening Database DB48DEV4 in normal mode failed
Cause: Opening database in the target home failed
For further details, see the log file located at d:\patching\DB48DEV4\logs\DB48DEV4\101\autoupgrade_20240520_user.log]
Errors in the log:
==========
DATABASE NAME: DB48DEV4
CAUSE: ERROR at Line 1 in [Buffer]
REASON: SP2-0640: Not connected
ACTION: [MANUAL]
DETAILS:
2024-05-20 16:41:14.116 ERROR Database Open Failed for db48dev4 SP2-0640: Not connected
Then I stop the service and modify it to run under the GMSA account and restart:
net stop OracleServiceAutoUpgradeDB48DEV4
sc config OracleServiceAutoUpgradeDB48DEV4 obj=DSLAB\XX_GORA_CL21$
net start OracleServiceAutoUpgradeDB48DEV4
then restore the crashed AutoUpgrade job:
upg> resume -job 101
Resuming job: [101][DB48DEV4]
and the patch will make it to the end without a problem. The temporary Windows service must be created in some special way during patching, because when you use oradim.exe normally, the service is created under the user under which ORACLE_HOME is installed. In our case DSLAB\XX_GORA_CL21$
Do you know if it is possible to somehow instruct the autoupgrade tool to create a temporary Windows service under a specific account ? Or it’s a BUG.
Hi Ales,
the windows user account topic is the most problematic part for us in the tool.
I can’t answer this blindly since I am not an expert for the Win service/user topic.
If you want, please do the following:
1. Make sure you have the brand-newest AU – we did some rapid fixes for the Windows part
2. Upload your logs collected with “java -jar autoupgrade.jar -config yourconfig -zip” to an SR
3. Share the SR number with me, and I will forward it to our windows expert in the team
Cheers,
Mike
Hi Mike, why does autoupgrade not change the Path in listener.ora ?
thanks
Regards
Chris
Hi Chris,
the listener part is a long-standing discussion. Take an environment with dozens of databases, several homes – and one single listener running for instance form the 19c home. This is actually a situation with have in our lab. Then I don’t want the listener being ripped away while my other dozens of databases are still up and running.
What you could easily do:
Use the upg1.after_action option and pass on a shell script which does the change you’d like to have.
Thanks,
Mike
Hello Mike,
I’m testing AUPG-3097 (passing user/password to the process) on a Windows Server 2016 environment with a SE 12.2.0.1.0 database (never patched apparently)
I downloaded build version 24.4.240426 for this test.
Conf is quite simple (I’m only trying to get an assessment here with an ‘analyze’ -> the db will move to new hardware) :
global.autoupg_log_dir=D:\migration
upg1.log_dir=D:\migration
upg1.sid=JDE
upg1.user=SYS
upg1.source_home=D:\oracle\product\12.2.0\dbhome_1
upg1.target_home=D:\oracle\product\19.0.0.0\dbhome_1
upg1.target_version=19
When calling AU, I end up with
d:\migration>java -jar autoupgrade.jar -config jde12c.cfg -mode analyze
AutoUpgrade 24.4.240426 launched with default internal options
Processing config file …
Unable to connect to database JDE for entry upg1
———— ERROR ————
Error Cause: invalid username/password; logon denied
I get no prompt for the password, as the documentation seems to suggest. I understand simply adding the parameter should trigger the prompt for a password.
Am I missing something about the usage of the ‘user’ parameter or did I completely misunderstood the way I should provide the user/password ? I can’t find an example neither in MOS or the documentation.
AU does never ask for the user password. The only exception would be an encrypted database where you would store your encryption password in AutoUpgrade’s keystore.
Most likely you are not using the admin account user your source database you want to upgrade has been installed with.
Please see the doc here:
https://docs.oracle.com/en/database/oracle/oracle-database/21/upgrd/autoupgrade-microsoft-windows-access-cointrol-lists.html
Cheers,
Mike
Thanks for the very quick answer !
Following your suggestion, I came to the conclusion the security team came up with some smart method that removes users from groups like… ORA_DBA and Administrators… Very good idea, indeed ! (yours not theirs)
—
Going back to this new feature :
“AUPG-3097 – Support for passing username/password on environments where OS Authentication is disabled.”
How do I pass the username and the password to AU ? Where could I find an example ?
Hi Attila,
AU does not need or accept a PW. It runs within the context of the Oracle user owning the home.
Please upload your logs to an SR – then we can check it.
java -jar autoupgrade.jar -config yourconf.cfg -zip
Cheers,
Mike
Hi Mike
I’m upgrading from 11.2 => 19.3 with the latest version of autoupgrade and it’s bombing out reading a registry value but only in deploy mode, analyze and fixups works fine
The user is administrator and has permission to read the key value, which is there and has ‘Standard’ as a value
I wondered if your team have any ideas? I’ve had an SR open for a week and we’re getting nowhere !
C:\Windows\system32>reg query HKLM\SOFTWARE\ORACLE\KEY_OraDB19Home1
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraDB19Home1
….
ORACLE_BUNDLE_NAME REG_SZ Standard
….
Fail to read value in Windows Registry HKEY=HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraDB19Home1 – ORACLE_BUNDLE_NAME – WinRegistry.readStringValue#75
2024-06-05 16:18:09.929 WARNING It was not possible to Extract Edition from Windows Registry D:\app\pulse\product\19.3.0\dbhome_1 – Bootstrap.processCLIParams#83
oracle.commonx.utils.errors.ConfigurationError: It was not possible to Extract Edition from Windows Registry D:\app\pulse\product\19.3.0\dbhome_1
at oracle.upgrade.autoupgrade.config.UpgradeConfigValidator.extractWindowsTargetEdition(UpgradeConfigValidator.java:403)
Rob,
we need the logs please.
Open an SR, upload the logs (java -jar autoupgrade.jar -config yourconf.cfg -zip) and send me the SR number.
Then I can ask our Windows expert to have a look at it if Support doesn’t solve it quickly.
Cheers,
Mike
Hi Mike,
great that Windows is supported now!
I would like to use this for patching, the Configfile is this one:
global.autoupg_log_dir=P:\temp\autoupgrade\up1
upg1.log_dir=P:\temp\autoupgrade\up1
upg1.sid=QPDB
upg1.pdbs=QPDBPDB
upg1.source_home=P:\app\oracle\product\19.c\home1
upg1.target_home=P:\app\oracle\product\19.c\home2
upg1.upgrade_node=DBUPGS.darkwing.net
upg1.restoration=no
upg1.target_cdb=TARGET
upg1.target_pdb_name=QPDBPDBClone
upg1.source_dblink.QPDBPDB=cloner
upg1.target_pdb_copy_option.QPDBPDB=file_name_convert=NONE
upg1.start_time=now
upg1.close_source=yes
As You see, I would like to clone the system via dblink before patching.
I run into this error:
Die Version der Remotedatenbank konnte nicht gefunden werden. Prüfen Sie die dblink-Konfiguration für cloner und Datenbank qpdbpdb
However, the DBLink is present and runs fine if I clone from sqlplus.
Is it not allowed to use dblink for patching?
Cheers
Christian
Hi Christian,
may I ask you to quickly open an SR, dump the
java -jar autoupgrade.jar -config yourconfig.cfg -zip
logs into it and send me the SR number via email?
Then I can forward it to the team.
Your config file looks good to me – but I have currently no capacity to do a quick test by myself.
Cheers,
Mike
Hi Mike,
why does autoupgrade not taking care on Read Only Homes ?
after patching with autoupgrade Read Only Home is disabled.
thanks and regards
Chris
Hi Chris,
AutoUpgrade does not even have a mechanism to change the type of the home.
Where and how do you suspect that AutoUpgrade could change from read-only to read-write home??
As far as I am aware of it, this is technically impossible.
But I am eager to learn from you did detect.
Cheers
Mike
Hi Mike,
is it possible to rollback an ru patch using autoupgrade after removing the restore point ?
or do I’ve to use opatch -rollback ?
thanks and regards
Chris
Hi Chris,
autoupgrade does not take care on the binaries. This is still the duty of opatch.
Thanks,
Mike
for sure.
thank you
Hi Mike, thanks for your answer.
today I ran autoupgrade -deploy to switch from 19.21 to 19.22
the 19.21er installation is a Oracle Read Only Home
before running autoupgrade I checked
orabasehome
/OraHome1/oracle/19c/homes/OraDB19Home6
spfile parameter
/OraHome1/oracle/19c/dbs/spfileTIGER.ora –> points to orabasehome
dg_broker_config_file1
/OraHome1/oracle/19c/homes/OraDB19Home6/dbs/dr1TIGER.dat –> points to orabasehome
I installed a new oracle home and applied the 19.22 ru. (out of place)
then I ran
autoupgrade -deploy
after autoupgrade has finished orabasehome points to
orabasehome
/OraHome1/oracle/19c/19.22
spfile parameter
/OraHome1/oracle/19c/19.22/dbs/spfileTIGER.ora
dg_broker_config_file1
/OraHome1/oracle/19c/19.22/dbs/dr1TIGER.dat
the Oracle Home is no longer read only
thanks and regrds
Chris
Hi Chris,
thanks for describing your process.
From what I see, you missed this step after creating the new empty 19.22 home:
$ ./roohctl -enable
You need to do this after the install is done.
Cheers,
Mike
Hey Mike, thanks for your great work! One issue we are having is that upgrade tool fails on timezone upgrade, as its failing with runtime exception OLD_TIME_ZONES_EXIST. We raised SR 3-36941595381 couple of months ago, but there are zero progress, I thinking if we as community having this issue quite frequently its worth having a bugfix, if you know someone with knowledge to look at the issue. Cheers Ed
Hi there,
sorry for my late reply. I see that Support has created even a documented since the parameter PARALLEL_MIN_PERCENT is breaking the time zone upgrade scripts which then has AutoUpgrade fail. The issue is really in the TZ upgrade scripts.
Support released:
Oracle 19c : autoupgrade fails with java.sql.SQLException: There were errors during the TimeZone Upgrade, ORA-00604, ORA-20091, ORA-12827: insufficient parallel query slaves (requested 288, available 16, parallel_min_percent 50) (Doc ID 3045208.1)
And I am chasing the owner now for a bug number. Since this isn’t an AU bug, it needs to be fixed in the time zone scripts. So, please be assured that we’ll get this fixed in the underlying scripts – and I will check with the AU team if we can do something meanwhile in the AU stack to prevent this.
Thanks for sharing the SR – this way we can learn and hope that we’ll can improve the quality.
Thanks,
Mike
Hi Mike, yesterday I patched some databases from 19.23 to 19.24 using autoupgrade build.version 24.5.240701.
After successfully completion I recognized that the database was started with init.ora instead of spfile.ora
spfile parameter was empty in v$parameter.
Also the listener.ora in the new home was damaged and listener was not able to start:
# start-delta DWH
( –> I think this line is causing the problem
LISTENER_DWH = (DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = hostname)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1527))
)
)
SID_LIST_LISTENER_DWH = (SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = DWH)
(ORACLE_HOME = /OraHome1/oracle/19c/19.24)
(SID_NAME = DWH)
)
)
# end-delta DWH
the original one looks this:
SID_LIST_LISTENER_DWH =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = DWH)
(ORACLE_HOME = /OraHome1/oracle/19c/19.0.0)
(SID_NAME = DWH)
)
)
LISTENER_DWH =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = hostname)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1527))
)
)
thanks & regards
Chris
Hi Chris,
I think this is a know issue where I have an AU in my inbox which should fix this.
Did you open an SR? If yes, can you share the SR number with me please?
Cheers,
Mike
Hi Mike, yes I’ve opened an SR but it is already closed.
I was on vacation and I lost sight of it 🙂
SR 3-37827958761 : autoupgrade does not restart database with spfile
thanks and regards
Chris
Hi Christian,
I see that the SR “answer” was pretty pointless and not helpful at all.
Let me quickly check with the team – I think this is a known issue. Meanwhile, did you have the chance to use a previous version of AutoUpgrade?
Thanks
Mike
Hi Christian,
I see now that you didn’t upload the AU logs.
Did you erase the log directory or is it still on the machine?
If it is still present, could you call please:
java -jar autoupgrade.jar -config TheConfigYouUsed.cfg -zip
Try to reopen the SR and upload the logs please. Without the logs, the developers will push back right away.
CHeers,
Mike
Hi Mike,
We have recently run into an issue while upgrading our lower environments from 19.23 –> 23ai latest, the issue being MAX_PDB_STORAGE hard limit set to a low value on one of the pdbs, and this has caused the UNDO tbs to not able to grow during the upgrade to fail and had caused DB dictionary issues.
Note:- The actual datafiles were set to autoextend ON and had plenty of space to grow though.
Hit this error in dump trace: ORA-65114: Space usage in container too high
It would be great to have this as a hard check during the autoupgrade prechecks step and alert the DBAs. We currently have an SR open and would put it in there as well. This might be helpful for others planning to upgrade meanwhile.
Thanks,
Chandra
Hi Chandra,
we would need way more context. Do you have an SR number for me, and did you upload the logs to the SR?
Then please share it with me.
Thanks,
Mike