apply: WITH ERRORS
When we are close to the end of datapatch, we saw an OS error: Error at line 0: Could not open logfile.
Patch 33488333 apply: WITH ERRORS
logfile: C:\app\oracle\product\12.2.0\dbhome_1\cfgtoollogs\sqlpatch\33488333\24564325/33488333_apply_ORCL_20223畸 20_16_18_23.log (errors)
Error at line 0: Could not open logfile C:\app\oracle\product\12.2.0\dbhome_1\cfgtoollogs\sqlpatch\33488333\24564325/33488333_apply_ORCL_20223畸 20_16_18_23.log
Please refer to MOS Note 1609718.1 and/or the invocation log
for information on how to resolve the above errors.
SQL Patching tool complete on Sun Mar 20 16:21:40 2022
In multibyte language environments, like Chinese or Japanese, the file name of logfile may contain unencoded or unresolvable characters which are unacceptable for Windows to create.
To conquer the problem, we switch to single-byte language at run-time. The safest language to do so is "American" and it's case-insensitive.
This guarantees that every character in logfile name is in English and the file can be created.
Please note that, NLS_LANG usually contains 3 components, we can be set only the first component, the language part. The date time format will be derived from this setting, so it's unnecessary to set the rest components in NLS_LANG.
For more language and date time format mapping, you may refer to: NLS_LANGUAGE to NLS_DATE_FORMAT Mapping Table.
Then we do it again.
Patch 33488333 apply: SUCCESS
logfile: C:\app\oracle\product\12.2.0\dbhome_1\cfgtoollogs\sqlpatch\33488333\24564325/33488333_apply_ORCL_2022Mar20_16_35_46.log (no errors)
SQL Patching tool complete on Sun Mar 20 16:37:50 2022
As you can see, the filename contains only single-byte characters, it can be created by OS, so the problem is solved.
Such error pattern we talked about in this post is pretty common before release 19c.