Background:
I was upgrading an Oracle Database version 12c(12.2.0.1) to version 19c (19.24) on Microsoft Windows.
This is a manual command line line upgrade ( I didn’t use DBUA).
I started by doing some preparation tasks like:
:: Task #1: Run pre-upgrade checks
:: Task #2: Run the preupgrade_fixups.sql
:: Task #3: Connect to sqlplus and create pfile from pfile
:: Task #4: Stop the 12c database Windows service
:: Task #5: Stop the 12c listener
:: Task #6: Removing database service from old 12c Oracle home
:: Task #7: Copying the init.ora file to the 19c home
:: Task #8: Copying the password file to the 19c home
:: Task #9: Starting the 19c listener
:: Task #10: Creating the database 19c Windows service
:: Task #11: Starting the 12c database from the new 19c home in upgrade mode
While running “Task #11: Starting the 12c database from the new 19c home in upgrade mode”, I got the following error:
ORA-00202: control file: ‘C:\APP\ORACLE\VIRTUAL\ORADATA\PROD\CONTROL01.CTL’
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 5) Access is denied.

Some Validation Actions:
I ensured that the control file exists in the above location and with the above name.
I double checked that the user that I’m using has a full control permission on the C:\APP directory.
I restarted the machine to make sure that there is no other process locking the control files.
I made sure that there is no Antivirus blocking the access to the control files and the Oracle directories.
I made sure that the CMD window that I’m using for upgrade was opened as Administrator.
All of this didn’t help to mount the database, so, what may be the root cause?
I made another test: I renamed the current control files only, and copied the corresponding files from the latest backup. I used these backup control files to test if I can mount the database (for sure without opening it), and I was able to mount the database!. Does this mean that the current control files are corrupted? ==> may be use or may be no.
I rolled back the above action: I deleted the backup control files, and renamed the original control files to their original names.
I made another test: I made a copy from the two original control files at the same directory, for example:
C:\APP\ORACLE\VIRTUAL\ORADATA\PROD\CONTROL01.CTL ==> C:\APP\ORACLE\VIRTUAL\ORADATA\PROD\CONTROL01 – Copy.CTL
Then I deleted the original control file: C:\APP\ORACLE\VIRTUAL\ORADATA\PROD\CONTROL01.CTL
Then I renamed the copied control file to: C:\APP\ORACLE\VIRTUAL\ORADATA\PROD\CONTROL01.CTL
I did the same actions exactly for the second control file under the \flash_recovery_area directory.
Now, I used these original copies of the control files to mount the database, and I was very surprised that the database was mounted successfully!!!!.
Then, I proceed with the action to start the database in the upgrade mode:
alter database open upgrade;
I started to get errors similar to the following one with the SYSTEM data file:
ORA-19505: failed to identify file “C:\APP\ORACLE\VIRTUAL\ORADATA\PROD\SYSTEM01.dbf”
ORA-27037: unable to obtain file status
Windows Error: 2: No such file or directory
I applied the same Copy/Delete/Rename action plan that I follows with the control file with the system datafile, and it succeeded.
Now, trying to open the database, and it produces the same above error with the SYSAUX.dbf file, and then with all datafiles, temp file, undo file and redo log files.
So, I followed the same Copy/Delete/Rename action plan for all data files, temp files, undo files and redo log files, and at that time only I was able to open the database upgrade successfully!!.
So, I was able to fix the above issue with the above workaround, but what is really the root cause of this issue?
Are the files corrupted? ==> The answer must be NO. If they are corrupted, their copies must be corrupted also.
May be there are locks on these files? ==> I already restarted the machine to exclude this option.
Are the database files permissions corrupted in some way? May be.
May be the metadata of these files at the File system level are corrupted? May be.
I made a detailed discussion about this issue with my friend CHATGPT, it is a rich discussion (although we didn’t reach exactly to the root cause), it is here if you are interested:
https://chatgpt.com/share/66fb779b-db68-8008-9aa8-ff839f4b9f18
Meanwhile, if you had experience with this issue, please share your experience in the comments.
Regards
Ahmed