Oracle 19c

ORA-64307 when creating compressed table and /home

This entry was posted in Engineer Systems ExaCC Exadata Oracle 19c on by

My customer running on ExaCC (Exadata Cloud@Customer) was getting “ORA-64307: Exadata Hybrid Columnar Compression is not supported for tablespaces on this storage type” on one of his test databases.

I did test connecting to SYS and no problem. Then I try to do using his tablespace and indeed, I get the error:

Quite going around, to check what was different on the user tablespace than on others. I test a self created tablespace and it works.

Strange. Until I found that… some datafiles were not in ASM!

Seems the ASM Diskgroup is almost full and the client DBA just put the datafiles somewhere else!

Warning: OPatchauto ignores disabled components – possible licensing issues

This entry was posted in OPatch Oracle Oracle 19c Patchset Update PSU on by

Since many years at my customer I’m using “opatchauto” to perform a out-of-place patching of Oracle Restart (GI+RDBMS).

My customer is concerned about database users using not licensed options, like partitioning. To avoid it, at the installation time the partitioning option is disabled using chopt, like described at Doc ID 948061.1.

Today during a check we noticed that Partitioning option was activated everywhere, which is not the client standard! We found out the origin of the problem was the out-of-place patching with “opatchauto”.

The big advantage of using “opatchauto” is that it allows easily either a single-step or a two-step Out-of-Place patching. We just write in a properties file the name of the new Oracle Homes and it does:

  • Clone current GI + RDBMS homes to new Homes (prepare clone)
  • Patches the new homes (prepare clone)
  • Stops GI and DBs (switch clone)
  • Switches GI and DBs from current homes to new Homes (switch clone)
  • Restart everything (switch clone)
  • Runs Datapatch on DBs if not standby (switch clone)

This allows to decrease the patching downtime without RAC to about 10 minutes, with the two-step (prepare clone + switch clone) operation.

Here the steps to reproduce de bug:

– install GI + RDBMS Oracle 19c (p.e 19.24) on server

– on RDBMS ORACLE_HOME disable partitioning component as described on Doc ID 948061.1:

$ chopt disable partitioning
Writing to /u00/app/oracle/product/19.24.0/install/disable_partitioning_2025-01-09_11-40-06AM.log...
/usr/bin/make -f /u00/app/oracle/product/19.24.0/rdbms/lib/ins_rdbms.mk part_off ORACLE_HOME=/u00/app/oracle/product/19.24.0
/usr/bin/make -f /u00/app/oracle/product/19.24.0/rdbms/lib/ins_rdbms.mk ioracle ORACLE_HOME=/u00/app/oracle/product/19.24.0

– Check – partition is disabled:

$ ar -tv /u00/app/oracle/product/19.24.0/rdbms/lib/libknlopt.a | grep -E 'kkpoban|ksnkkpo'
rw-r--r-- 1000/1001 5240 Apr 17 07:25 2019 ksnkkpo.o

– Perform out of place patching of DB from GI ORACLE_HOME (single-step example here):

$ cat /staging/clone.properties
/u00/app/grid/19.24.0=/u00/app/grid/19.25.0
/u00/app/oracle/product/19.24.0=/u00/app/oracle/product/19.25.0

$ echo $ORACLE_HOME
/u00/app/grid/19.24.0

$ sudo ${ORACLE_HOME}/OPatch/opatchauto apply -phBaseDir /staging/RU_19c_OCT2024/ -outofplace -silent /staging/clone.properties

OPatchauto session is initiated at Thu Jan  9 12:30:25 2025

System initialization log file is /u00/app/grid/19.24.0/cfgtoollogs/opatchautodb/systemconfig2025-01-09_12-30-30PM.log.

Session log file is /u00/app/grid/19.24.0/cfgtoollogs/opatchauto/opatchauto2025-01-09_12-30-34PM.log
The id for this session is GAEM

Executing OPatch prereq operations to verify patch applicability on home /u00/app/grid/19.24.0
Patch applicability verified successfully on home /u00/app/grid/19.24.0


Executing OPatch prereq operations to verify patch applicability on home /u00/app/oracle/product/19.24.0
Patch applicability verified successfully on home /u00/app/oracle/product/19.24.0


Executing patch validation checks on home /u00/app/grid/19.24.0
Patch validation checks successfully completed on home /u00/app/grid/19.24.0


Executing patch validation checks on home /u00/app/oracle/product/19.24.0
Patch validation checks successfully completed on home /u00/app/oracle/product/19.24.0


Verifying SQL patch applicability on home /u00/app/oracle/product/19.24.0
Skipping SQL patch step execution on standby database : C0201Z01_ENG1
No sqlpatch prereq operations are required on the local node for this home
No step execution required.........

Copying the files from the existing oracle home /u00/app/grid/19.24.0 to a new location. Please wait...

Copying the files from the existing oracle home /u00/app/oracle/product/19.24.0 to a new location. Please wait...
Clone of oracle home /u00/app/grid/19.24.0 is /u00/app/grid/19.25.0 on host vm01
Copying the files from the existing oracle home /u00/app/grid/19.24.0 to a new location is successful.

Clone of oracle home /u00/app/oracle/product/19.24.0 is /u00/app/oracle/product/19.25.0 on host vm01
Copying the files from the existing oracle home /u00/app/oracle/product/19.24.0 to a new location is successful.


Unlocking CRS clone home for home /u00/app/grid/19.24.0.
Prepatch operation log file location: /u00/app/oracle/crsdata/vm01/crsconfig/hapatch_2025-01-09_12-49-31AM.log
Unlocked CRS clone home successfully for home /u00/app/grid/19.24.0.


Creating clone for oracle home /u00/app/grid/19.24.0.
Clone operation successful for oracle home /u00/app/grid/19.24.0.


Creating clone for oracle home /u00/app/oracle/product/19.24.0.
Clone operation successful for oracle home /u00/app/oracle/product/19.24.0.


Performing post clone operation for oracle home /u00/app/grid/19.24.0.
Performing post clone operation was successful for oracle home /u00/app/grid/19.24.0.


Performing post clone operation for oracle home /u00/app/oracle/product/19.24.0.
Performing post clone operation was successful for oracle home /u00/app/oracle/product/19.24.0.


Start applying binary patch on home /u00/app/grid/19.25.0
Binary patch applied successfully on home /u00/app/grid/19.25.0


Start applying binary patch on home /u00/app/oracle/product/19.25.0
Binary patch applied successfully on home /u00/app/oracle/product/19.25.0


Running rootadd_rdbms.sh on home /u00/app/grid/19.25.0
Successfully executed rootadd_rdbms.sh on home /u00/app/grid/19.25.0


Running rootadd_rdbms.sh on home /u00/app/oracle/product/19.25.0
Successfully executed rootadd_rdbms.sh on home /u00/app/oracle/product/19.25.0


Update nodelist in the inventory for oracle home /u00/app/grid/19.25.0.
Update nodelist in the inventory is completed for oracle home /u00/app/grid/19.25.0.


Bringing down database service on home /u00/app/oracle/product/19.25.0
Database service successfully brought down on home /u00/app/oracle/product/19.25.0


Performing postpatch operations on CRS - starting CRS service on home /u00/app/grid/19.25.0
Postpatch operation log file location: /u00/app/oracle/crsdata/vm01/crsconfig/hapatch_2025-01-09_01-27-10PM.log
CRS service started successfully on home /u00/app/grid/19.25.0


Preparing home /u00/app/oracle/product/19.25.0 after database service restarted
No step execution required.........


Confirm that all resources have been started from home /u00/app/grid/19.25.0.
All resources have been started successfully from home /u00/app/grid/19.25.0.


Modifying  the database(s) to use new location home /u00/app/oracle/product/19.25.0.
All database(s) modified successfully to run from new location home /u00/app/oracle/product/19.25.0.


Trying to apply SQL patch on home /u00/app/oracle/product/19.25.0
Skipping SQL patch step execution on standby database : C0201Z01_ENG1
No SQL patch operations are required on local node for this home


OPatchAuto successful.

--------------------------------Summary--------------------------------

Patching is completed successfully. Please find the summary as follows:

Host:vm01
SIHA Home:/u00/app/grid/19.24.0
Version:19.0.0.0.0
Summary:

==Following patches were SKIPPED:

Patch: /staging/RU_19c_OCT2024/36866740/36916690/36758186
Log: /u00/app/grid/19.24.0/cfgtoollogs/opatchauto/core/opatch/opatch2025-01-09_12-33-55PM_1.log
Reason: /staging/RU_19c_OCT2024/36866740/36916690/36758186 is not required to be applied to oracle home /u00/app/grid/19.24.0


==Following patches were SUCCESSFULLY applied:

Patch: /staging/RU_19c_OCT2024/36866740/36878697
Log: /u00/app/grid/19.25.0/cfgtoollogs/opatchauto/core/opatch/opatch2025-01-09_12-51-54PM_1.log

Patch: /staging/RU_19c_OCT2024/36866740/36916690/36912597
Log: /u00/app/grid/19.25.0/cfgtoollogs/opatchauto/core/opatch/opatch2025-01-09_12-51-54PM_1.log

Patch: /staging/RU_19c_OCT2024/36866740/36916690/36917397
Log: /u00/app/grid/19.25.0/cfgtoollogs/opatchauto/core/opatch/opatch2025-01-09_12-51-54PM_1.log

Patch: /staging/RU_19c_OCT2024/36866740/36916690/36917416
Log: /u00/app/grid/19.25.0/cfgtoollogs/opatchauto/core/opatch/opatch2025-01-09_12-51-54PM_1.log

Patch: /staging/RU_19c_OCT2024/36866740/36916690/36940756
Log: /u00/app/grid/19.25.0/cfgtoollogs/opatchauto/core/opatch/opatch2025-01-09_12-51-54PM_1.log


Host:vm01
SIDB Home:/u00/app/oracle/product/19.24.0
Version:19.0.0.0.0
Summary:

==Following patches were SKIPPED:

Patch: /staging/RU_19c_OCT2024/36866740/36916690/36917397
Reason: This patch is not applicable to this specified target type - "oracle_database"

Patch: /staging/RU_19c_OCT2024/36866740/36916690/36758186
Reason: This patch is not applicable to this specified target type - "oracle_database"

Patch: /staging/RU_19c_OCT2024/36866740/36916690/36940756
Reason: This patch is not applicable to this specified target type - "oracle_database"


==Following patches were SUCCESSFULLY applied:

Patch: /staging/RU_19c_OCT2024/36866740/36878697
Log: /u00/app/oracle/product/19.25.0/cfgtoollogs/opatchauto/core/opatch/opatch2025-01-09_13-09-38PM_1.log

Patch: /staging/RU_19c_OCT2024/36866740/36916690/36912597
Log: /u00/app/oracle/product/19.25.0/cfgtoollogs/opatchauto/core/opatch/opatch2025-01-09_13-09-38PM_1.log

Patch: /staging/RU_19c_OCT2024/36866740/36916690/36917416
Log: /u00/app/oracle/product/19.25.0/cfgtoollogs/opatchauto/core/opatch/opatch2025-01-09_13-09-38PM_1.log


Patching session reported following warning(s):
_________________________________________________

[Note]: Please verify the database is running from the desired Oracle home, if not then manually execute
 $ORACLE_HOME/bin/srvctl modify database command to fix the problem


Out of place patching clone home(s) summary
____________________________________________
Host : vm01
Actual Home : /u00/app/grid/19.24.0
Version:19.0.0.0.0
Clone Home Path : /u00/app/grid/19.25.0

Host : vm01
Actual Home : /u00/app/oracle/product/19.24.0
Version:19.0.0.0.0
Clone Home Path : /u00/app/oracle/product/19.25.0


OPatchauto session completed at Thu Jan  9 13:32:41 2025
Time taken to complete the session 62 minutes, 16 seconds

– Check – partition component is enabled on the new Oracle Home:

$ ar -tv /u00/app/oracle/product/19.25.0/rdbms/lib/libknlopt.a | grep -E 'kkpoban|ksnkkpo'
rw-r--r-- 1000/1001 5144 Oct 11 13:17 2024 kkpoban.o

This problematic is also true for the other components: Advanced Analytics, OLAP and Real Application Testing.

And probably happens also when using Opatchauto with RAC (not tested), as described here at Doc ID 2419319.1.

I’ve open a Bug/SR today on Oracle Support site and will let here know when I’ve more information.

Solve “OGG-08224 Error: CONTAINER option was specified though the database does not support containers” error

This entry was posted in GoldenGate Oracle 19c on by

Quick post to add info about the following Goldengate error:

OGG (http://localhost:9300 test1 as ogg_pdb1@CDB2) 10> REGISTER EXTRACT E_TEST1 DATABASE CONTAINER (pdb1)

2024-12-08T17:16:58Z ERROR OGG-08224 Error: CONTAINER option was specified though the database does not support containers.

This means that you are connected directly to the PDB, and not to CDB$ROOT.

To register Goldengate 21 extracts you need to connect to the Root container with a common user.

OGG (http://localhost:9300 test1 as ogg_pdb1@CDB2) 12> DBLOGIN USERIDALIAS ogg_cdb2
Successfully logged into database CDB$ROOT.

OGG (http://localhost:9300 test1 as ogg_cdb2@CDB2/CDB$ROOT) 13> REGISTER EXTRACT E_TEST1 DATABASE CONTAINER (pdb1)
2024-12-08T17:20:36Z  INFO    OGG-02003  Extract group E_TEST1 successfully registered with database at SCN 8039188.

Well, in the future this is not anymore true, as new version from Goldengate and DBs will work only at PDB level.

The DBT-16051 when creating a standby database using DBCA is still around. 7 years after.

This entry was posted in DataGuard Oracle Oracle 19c on by

Sometimes I ask myself why some bugs are not solved. When looking for DBT-16071 we find a blog post from Frank Pachot from more than 7 years ago. He shows that with Oracle 12.2 you can “create” standby databases directly with dbca. But that the script does only a duplicate for standby and nothing more.

I decided to try with 19.22 to see how the situation evolved. It didn’t.

The first thing I got was a DBT-16051 error:

$ dbca -createDuplicateDB -gdbName anjodb01 -primaryDBConnectionString "anjovm01.local.wsl/anjodb01_s1.local.wsl" -sid anjodb01 -createAsStandby -dbUniqueName anjodb01_s2 -silent
Enter SYS user password:
*****
[FATAL] [DBT-16051] Archive log mode is not enabled in the primary database.
   ACTION: Primary database should be configured with archive log mode for creating a duplicate or standby database.

Quick check shows the primary is correctly in archivelog mode. The problem is the Easy Connect string. The string I gave “anjovm1.local.wsl/anjodb1_s1.local.wsl” works well on sqlplus, but not with dbca. There you need to specify the port, also when you are just using the default one:

$ dbca -createDuplicateDB -gdbName anjodb01 -primaryDBConnectionString "anjovm01.local.wsl:1521/anjodb01_s1.local.wsl" -sid anjodb01 -createAsStandby -dbUniqueName anjodb01_s2 -silent
Enter SYS user password:
*****
[WARNING] [DBT-10331] Specified SID Name (anjodb01) may have a potential conflict with an already existing database on the system.
   CAUSE: The specified SID Name without the trailing numeric characters ({2}) may have a potential conflict with an already existing database on the system.
   ACTION: Specify a different SID Name that does not conflict with existing databases on the system.
Prepare for db operation
22% complete
Listener config step
44% complete
Auxiliary instance creation
67% complete
RMAN duplicate
89% complete
Post duplicate database operations
100% complete

The warning DBT-10331 appears because I’ve a “anjodb02” in the same VM, and this could create a problem, as they share the prefix “anjodb”. I don’t expect on a single instance environment that to be a problem though.

And it starts the new standby in ‘read only’ mode, which requires adequate licenses. 

SQL> select name, db_unique_name, database_role, open_mode, dataguard_broker from v$database;

NAME      DB_UNIQUE_NAME                 DATABASE_ROLE    OPEN_MODE            DATAGUAR
--------- ------------------------------ ---------------- -------------------- --------
ANJODB01 ANJODB02_S2                  PHYSICAL STANDBY READ ONLY            DISABLED

For the moment, I’ll stay with my set of scripts which do the operations in the right way.

Install Oracle Linux 9 and Oracle Database 19c on Windows WSL 1

This entry was posted in Linux Multitenant Oracle Oracle 19c on by

Since a few days I’ve a Oracle Database 19c running on my laptop (4 year old i5 processor with 16GB memory) under the Windows Subsystem for Linux with the latest Oracle Linux 9.3. It is working great for testing functionalities. It survives without problem sleep and restart without first shutting down correctly the database.

While there are no snapshot possibility like with Virtualbox, it is possible to export the running image and re-import later.

Below I describe the main steps to quickly install the system.

(more…)

New “OPatch util DeleteInactivePatches” tool for reducing the $ORACLE_HOME size

This entry was posted in OPatch Oracle Oracle 19c on by

When you are a sensible person, you patch regularly your Oracle database. After a few years, maybe you noticed that the $ORACLE_HOME increased size from new ~7 GB to …. 26 GB!

$ du -hs /u00/app/oracle/product/19.18.0
26G     /u00/app/oracle/product/19.18.0

Looking better, you find the culprit is the hidden directory $ORACLE_HOME/.patch_storage :

$ du -hs /u00/app/oracle/product/19.18.0/.patch_storage
17G     /u00/app/oracle/product/19.18.0/.patch_storage

Today I show how a new option from OPatch allowed me to regain 11 GB of disk space in a couple of minutes. In a supported way.

Last year I had already presented other options to recover space from Oracle Patching. Below I remind them, but todays post is about the latest and improved way that OPatch tool has to keep only the usual needed patch backups.

Read More

How to workaround Oracle Text primary key limitations (and DRG-10528)

This entry was posted in bug Oracle Oracle 19c on by

One of my clients had a quite easy desire to try Oracle Text for an existing application. Oracle Text allows to use “standard SQL to index, search, and analyze text and documents stored in the Oracle database, in files, and on the web”.

It seemed simple, until we tried to implement on table named after the city where I studied: T_COIMBRA

create table T_COIMBRA (COL_ID timestamp not null, COL_TXT varchar2(100));

create unique index COIMBRA_IDX_ID on T_COIMBRA(COL_ID);

alter table T_COIMBRA add constraint PK_COIMBRA primary key (COL_ID) using index COIMBRA_IDX_ID;

create index COIMBRA_IDX_TXT ON T_COIMBRA(COL_TXT) indextype is ctxsys.context;

Nothing special it seems. But we get an error:

create index COIMBRA_IDX_TXT ON T_COIMBRA(COL_TXT) indextype is ctxsys.context

Error report -
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-20000: Oracle Text error:
DRG-10528: primary keys of type TIMESTAMP(6) are not allowed
ORA-06512: at "CTXSYS.DRUE", line 186
ORA-06512: at "CTXSYS.TEXTINDEXMETHODS", line 320
29855. 00000 -  "error occurred in the execution of ODCIINDEXCREATE routine"
*Cause:    Failed to successfully execute the ODCIIndexCreate routine.
*Action:   Check to see if the routine has been coded correctly.

Below I show how to workaround this and keep an “unsupported” column as unique identifier of the table.

Read More

Upgrade to 19c: only 6 months left with support from Oracle

This entry was posted in Oracle 11g Oracle 12c Oracle 19c and tagged Oracle support upgrade on by

Oracle updated on 7 June 2023 the Release Schedule of Current Database Releases (Doc ID 742060.1) was updated, clarifying that only until December 2023 is possible to get support from Oracle ACS to perform the Upgrade the databases to the version 19c, the current stable release.

Below the updated slide from Oracle showing the support timelines of each version. Oracle 19c has also “Waived Extended Fee” support until 30 April 2025, even if that is not yet marked in the slide.

Don’t miss this opportunity!

The OPatch, .patch_storage and its space issues: the solutions!

This entry was posted in OPatch Oracle Oracle 19c on by

[a new solution is available as of 2023. Read here about the new OPatch util DeleteInactivePatches option.]

I love database patching and apart of the tiring coordination work or the applications that keep to not automatically reconnect to the database, all is usually perfect and issue free. Well, almost. The most common error are space issues.

You can try to follow the Oracle guidelines and have a 100 GB partition for the $ORACLE_HOME(s). Initially it only uses 7 or 8 GB per home, but after few years you are fighting against the space pressure.

There are several strategies to prevent or act against this space problem when patching:

Solution 1 – Recreate separate Oracle Home from scratch

It is a clean solution, when you make really from scratch, meaning no home cloning, no opatchauto apply -outofplace, and then apply only the latest patch there. This solution is quite easy to do for DB home. However when you have Grid Home this is a bit more hassle.

Solution 2 – Use the opatch hidden “archive” feature

This feature allows to move out from .patch_storage folder some patches in a zip format. It was “documented” by Mike Dietrich in his blog. Unfortunately to have a common archive between different Oracle Homes you need to do some hand work: archive on one Oracle Home, delete the patches from remaining homes and copy the $ORACLE_HOME/OPatch/.patch_storage/.patch_archive_mapping.xml file to the other homes. Of course this works when all Homes have exactly the same features installed and patches. Keep in mind that before rollback you need to use the “unarchive” option and that the rollback procedure will restore the files that were changed, and this can vary depending on the state of the oracle home at the moment of patch. Use opatch util archive -help for more info.

Here we are not saving any space, just moving the problem away. The other partition can be a remote slower location, but the patching will also then be slower, as it will need to copy files there. Use: TARGET=<partition>/patch_storage ; mv $ORACLE_HOME/.patch_storage $TARGET ; ln -s $TARGET $ORACLE_HOME/.patch_storage

Solution 4 – Remove unneeded patches from .patch_storage

In $ORACLE_HOME/.patch_storage the whole history of patches you applied is kept. You can rollback one after the other and bring the Oracle Home several steps behind. However, the most of the cases you are ok to just be able to move one step backward. The older history of the home is past. If that is you case, then there is this nice Python script clean_patch_storage.py which is based on the premise of Oracle Doc ID 550522.1 which states you can “remove all the sub-directories from $ORACLE_HOME/.patch_storage that are not present in the list of installed patches”. The list directories you can delete is exactly what the script do.

Maybe you have other solutions or tricks, please share in the comments.

Datapatch and Tablespace Full

This entry was posted in OPatch Oracle Oracle 19c on by

Yesterday on a simple 19.13 patching session, got a nice error during datapatch: ORA-01691: usable to extend lob segment in Tablespace SYSTEM ! Got a bit scared, but simple added more space to the tablespace, run datapatch again and all was ok. Maybe patch/datapatch should check also for free space in the SYSTEM Tablespace ?

Here the error:

DBD::Oracle::st execute failed: ORA-01691: unable to extend lob segment SYS.SYS_LOB0000323098C00008$$ by 128 in tablespace SYSTEM
ORA-06512: at line 2 (DBD ERROR: OCIStmtExecute) [for Statement "BEGIN
           INSERT INTO sys.dba_registry_sqlpatch_ru_info
             (patch_id,
              patch_uid,
              patch_descriptor,
              ru_version,
              ru_build_description,
              ru_build_timestamp,
              patch_directory)
           VALUES
             (:patch_id,
              :patch_uid,
              :patch_descriptor,
              :ru_version,
              :ru_build_description,
              TO_TIMESTAMP(:ru_build_timestamp, 'YYMMDDHH24MISS'),
              :patch_directory);
           COMMIT;
         END;" with ParamValues: :patch_descriptor=OCIXMLTypePtr=SCALAR(0x468b0a0), :patch_directory='PK........▒LOS▒.
▒. ..▒[..
...33192793.xml▒][.۸.~..
▒.v▒▒▒.x.▒▒q*.o▒▒*.'s▒▒▒(.-qL▒l.ji▒▒/@Im        8 .$.I▒<▒0j▒.>\.▒.▒~.▒▒▒K▒vE▒▒▒.~K..▒6▒▒b▒▒▒a▒?=F.▒..▒]▒\▒5▒▒▒▒.?|▒▒y4f▒▒{X▒▒▒..▒"▒▒|?d.▒..I▒.E.▒▒▒▒=▒▒▒▒▒..▒▒▒.▒▒5.Wg▒w.ۺ▒..▒v}Q%}.▒..▒▒.▒▒.-▒▒▒▒▒\%▒▒׿▒vE.▒▒xsU▒▒)%ħa@.r▒▒.▒Kۢ▒.▒}..y▒▒.~j2▒▒â.=▒▒▒.▒▒▒O.▒▒<▒wm▒▒▒d▒.▒vw▒▒▒▒....▒o޼.▒}▒▒▒.I.▒x▒.▒▒.▒▒▒▒.▒▒.▒x▒o▒)▒▒wo.vxۿ{|\▒,.i]5▒6▒▒..▒▒.b.g▒b▒▒7Ew▒▒▒▒./▒.▒▒o.▒/▒.▒.▒▒6▒#▒.▒.▒...▒▒..▒▒▒▒ߵ▒l▒▒▒▒...▒▒.▒.▒▒.a(▒.▒?|▒.▒
X▒▒{+▒▒v▒=.▒{▒▒▒▒9Íui▒▒.H.▒▒▒▒▒▒▒▒S.▒^▒|▒9.▒%▒,▒▒▒SU▒.▒. zZ.▒..c;.▒vحY▒B...▒▒▒▒/▒▒.▒▒▒▒.▒▒▒..H{.7}f.▒..▒j.▒mۿ▒.▒S.▒7▒.:§.▒+p▒%▒..w▒.▒.▒{7▒.▒k▒..▒6▒6▒▒>v▒bwMU▒..▒Y_▒+▒IG▒<.|4▒▒\▒4.▒i▒*▒▒;G▒-V.ε▒▒.p.▒▒▒▒
G̍1▒.▒]▒▒▒.1O▒v▒^.▒▒▒.▒:.Wy._q7▒▒.*▒&▒▒`/▒I߹...pW.
▒▒▒▒C.v▒j▒[▒▒.▒▒~▒▒.▒.bo▒▒.U▒..▒V▒▒
.`n▒▒N7▒.`nyup▒▒.w▒.]▒▒B▒.▒▒5D7▒.w.#w.▒.▒m▒▒ܬ▒.p▒.3p.▒▒.▒.l▒.▒▒Z;▒0.\bm▒J▒...', :patch_id="33192793", :patch_uid="24462514", :ru_build_description="Release_Update", :ru_build_timestamp="211004165050", :ru_version="19.13.0.0.0"] at /u01/oracle/db19s/sqlpatch/sqlpatch.pm line 5876, <LOGFILE> line 110.