Showing posts with label Oracle 19c. Show all posts
Showing posts with label Oracle 19c. Show all posts

Thursday, October 8, 2026

Resolving Oracle Text Index Error DRG-12255: Invalid SEC_DATATYPE in CTXSYS

When creating domain indexes on text-enabled application columns following a database upgrade or migration, database administrators may encounter an unexpected DRG-12255 error. This issue typically surfaces during the first attempt to build a text index on an instance where internal CTXSYS dictionary metadata contains corrupted datatype definitions.

In this post, we will examine the root cause behind this error, how to identify the metadata discrepancy using a side-by-side environment comparison, and the official Oracle-supported de-installation and re-installation procedure.

Executing a standard domain index creation statement fails with the following stack:

CREATE INDEX app_owner.doc_xml_idx ON app_owner.doc_catalog(xml_data)
INDEXTYPE IS CTXSYS.PATH_SECTION_INDEX
PARAMETERS ('SECTION GROUP CTXSYS.XQUERY_SEC_GROUP');

ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-20000: Oracle Text error:
DRG-12255: invalid data type for SDATA section XQUERY_SEC_GROUPTS*
ORA-06512: at "CTXSYS.DRUE", line 186
ORA-06512: at "CTXSYS.TEXTINDEXMETHODS", line 320


Technical Root Cause Analysis

The underlying issue is tracked under Unpublished Bug 39088026 (CREATING TEXT INDEX DRG-12255: INVALID DATA TYPE FOR SDATA SECTION XQUERY_SEC_GROUPTS*).

During database upgrades (e.g., from Oracle 12c to 19c), post-upgrade dictionary scripts (dr0upgrade.sql / ctxpatch.sql) can leave system section group metadata in CTXSYS.CTX_SECTION_GROUP_SECTIONS in an invalid state.

Specifically, the dictionary metric SEC_DATATYPE expects an internal datatype code of 187. In affected instances, this value is corrupted or improperly initialized during upgrade, and the internal section names fail to inherit the fully qualified CTXSYS. package namespace prefix.

To inspect the metadata and SEC_DATATYPE values for section groups in your database, run the following query as SYSDBA:

SELECT sec_owner,
sec_section_group,
sec_name,
sec_type,
sec_datatype
FROM ctxsys.ctx_section_group_sections
WHERE sec_section_group = 'XQUERY_SEC_GROUP';



Comparing a healthy instance against an affected instance highlights the missing schema prefixes in the SEC_NAME column:

Unaffected Environment:
SEC_OWNER SEC_SECTION_GROUP SEC_TYPE SEC_NAME SEC_TAG SEC_DATA
--------- ------------------------- ------------ ------------------------------ -------------------- ------
CTXSYS XQUERY_SEC_GROUP SDATA CTXSYS.XQUERY_SEC_GROUPDB* db*
CTXSYS XQUERY_SEC_GROUP SDATA CTXSYS.XQUERY_SEC_GROUPNUM* num* NUMBER
CTXSYS XQUERY_SEC_GROUP SDATA CTXSYS.XQUERY_SEC_GROUPTS* ts*

Affected Environment:

SEC_OWNER SEC_SECTION_GROUP SEC_TYPE SEC_NAME SEC_TAG SEC_DATA
----------------- ------------------------- ------------ -------------------- -------------------- --------
CTXSYS XQUERY_SEC_GROUP SDATA XQUERY_SEC_GROUPDB* db*
CTXSYS XQUERY_SEC_GROUP SDATA XQUERY_SEC_GROUPNUM* num* NUMBER
CTXSYS XQUERY_SEC_GROUP SDATA XQUERY_SEC_GROUPTS* ts*

Notice how the affected environment lacks the CTXSYS. prefix in the SEC_NAME column, which triggers the DRG-12255 invalid data type exception when parsed.

Pre-Requisite: Verifying Oracle Text Usage

Before attempting any component-level changes, DBAs must verify whether Oracle Text domain indexes or custom preferences are actively used by application schemas.

Run the following queries as SYSDBA:

-- 1. Check for Active Oracle Text Indexes
SELECT owner, index_name, table_owner, table_name, status
FROM dba_indexes
WHERE ityp_owner = 'CTXSYS'
OR ityp_name IN ('CONTEXT', 'CTXCAT', 'CTXRULE', 'PATH_SECTION_INDEX');


-- 2. Check for Custom User Preferences

SELECT pre_owner, pre_name, pre_class, pre_object
FROM ctxsys.ctx_preferences
WHERE pre_owner NOT IN ('SYS', 'SYSTEM', 'CTXSYS');


-- 3. Summary Check One-Liner

SELECT
(SELECT COUNT(*) FROM dba_indexes WHERE ityp_owner = 'CTXSYS') AS active_text_indexes,
(SELECT COUNT(*) FROM ctxsys.ctx_preferences WHERE pre_owner NOT IN ('SYS', 'SYSTEM', 'CTXSYS')) AS custom_preferences
FROM dual;


If both counts return 0, no active text indexes or custom preferences exist on the instance.

Solution or Remediation Steps

Because Oracle Development has no ETA on when an official patch or fix will be released, modifying internal CTXSYS metadata tables directly via UPDATE or ALTER statements is strictly unsupported.

If no existing Oracle Text indexes exist on the database instance, the safest and only vendor-supported path forward is to completely de-install and reinstall the Oracle Text

(CTXSYS) component.

Step 1: De-install Oracle Text Component
Connect as SYSDBA and execute the de-installation script (catnoctx.sql):

sqlplus / as sysdba

SPOOL text_deinstall.log
-- Remove Oracle Text schema and dictionary objects
@?/ctx/admin/catnoctx.sql
-- Drop remaining validation procedure
DROP PROCEDURE sys.validate_context;
SPOOL OFF


Step 2: Reinstall Oracle Text Component

Re-create the CTXSYS schema and re-initialize system preferences:

sqlplus / as sysdba

SPOOL text_install.log
-- Install Oracle Text (Default tablespace: SYSAUX, Temp: TEMP)
@?/ctx/admin/catctx.sql CTXSYS SYSAUX TEMP LOCK
-- Change CTXSYS password and unlock account
ALTER USER CTXSYS IDENTIFIED BY "<password>" ACCOUNT UNLOCK;
-- Connect as CTXSYS to load default preferences and section groups
CONNECT CTXSYS/<password>
@?/ctx/admin/defaults/drdefus.sql
-- Connect back as SYSDBA to compile invalid objects and validate
CONNECT / as sysdba
@?/rdbms/admin/utlrp.sql
SPOOL OFF


Step 3: Verification

Verify that the CTXSYS component is installed and in VALID status across the database registry:

SELECT comp_id, comp_name, version, status
FROM dba_registry
WHERE comp_id = 'CONTEXT';

Once reinstallation is complete, re-run the CREATE INDEX DDL statement. The metadata entries will correctly include the proper namespace prefixes and datatype values, allowing the text domain index build to complete cleanly.

Thanks & Regards,
https://oracleracexpert.com

Thursday, February 5, 2026

Resolving ORA-19502, ORA-16038 and ORA-27072 Errors in Oracle Database

We recently encountered errors below and there are several common causes.

 ORA-19502: write error on file "/oraarch/TESTDB/1_432678_12436018.dbf", block number 182272 (block size=512)
 ORA-16038: log 2 sequence# 432678 cannot be archived
 ORA-19502: write error on file "", block number (block size=)
 ORA-00312: online log 2 thread 1: '/redo2/TESTDB/TESTDB_1B.rdo'
 ORA-27072: File I/O error


The “ORA-27072: File I/O error” , can occur due to below are common reasons

  • Disk issue – This error can also occur if the disk or storage is inaccessible. It might be due to hardware related issues
  • File corruption- The file system where database resides might have corrupted.
  • Permission issue – If the database user does not have enough permissions, you will get this error.
  • Mount failures – when Filesystem not mounted properly

The “ORA-16038” error mainly occurs when archive log file cannot be archived. In this case if the database cannot be able to reuse redo log files, logs cannot switch, the database may hung.

The “ORA-19502” error mainly caused by insufficient disk space or file system full.

In our case, the issue was caused by a full archive log filesystem. 

When archive log file system got full, the redo log archiving failed triggering ORA-16038 and ORA-19502 errors. This eventually resulted ORA-27072 due to failed write attempts

Recommended steps

1. Check the archive log and db_recovery_file_dest destinations

SHOW PARAMETER log_archive_dest;
SHOW PARAMETER db_recovery_file_dest;

If using FRA:

SHOW PARAMETER db_recovery_file_dest_size;
 
2. User should use “df-h” to check the diskspace

User should Pay special attention to:
  • Archive destination mount point
  • FRA mount point

3. If the file system is full Increase size by extending lun or increasing FRA size.

4. Make sure user run the backup and delete old archive logs

rman target /
DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-x';

Here X means number of days

5. In case FRA is full then user should increase the db_recovery_file_dest_size using below example

Check FRA usage using below query

SELECT name, space_limit/1024/1024 MB_LIMIT,
               space_used/1024/1024 MB_USED,
               space_reclaimable/1024/1024 MB_RECLAIMABLE
FROM   v$recovery_file_dest;  

ALTER SYSTEM SET db_recovery_file_dest_size = 200G;

6. Always check for alert.log to review errors and find the root cause.

Look for:
  • ARCn errors
  • Log switch failures
  • Repeated I/O messages
To Avoid this issue in future user can take below measures:
  • Monitor FRA usage regularly
  • Set up alerting when disk usage exceeds 80%
  • Configure proper RMAN retention policy
  • Automate archive log deletion after backup
  • Separate archive logs from other mount points
  • Monitor log switch frequency
In our environment, the archive log filesystem became completely full.

This caused:
ORA-19502 (write failure)
ORA-16038 (cannot archive log)
ORA-27072 (I/O error)

Once disk space was cleared, archiving resumed automatically and the database returned to normal operation.

Thanks & Regards,

Saturday, August 9, 2025

RMAN-03009 - RMAN Backup Failure After Applying DB RU Patch: A Resolution Guide

After applying a Database Release Update (DB RU) patch, we encountered an RMAN backup failure. The error messages provided were as follows:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of allocate command on ch1 channel at 08/09/2025 14:54:45
ORA-01403: no data found

Issue: Failure While Registering Database
When attempting to register the database with RMAN, the following output was observed:

RMAN> register database;
database registered in recovery catalog
Creating and using snapshot control file for resync
starting full resync of recovery catalog
Control file used records for BACKUP REDOLOG = 6880
Control file used records for DELETED OBJECT = 6544
Control file used records for BACKUP SET = 2720
Control file used records for ARCHIVED LOG = 2384
Control file used records for LOG HISTORY = 2336
Control file used records for BACKUP DATAFILE = 2288
Control file used records for RMAN STATUS = 2256
Control file used records for BACKUP PIECE = 2096
Control file used records for BACKUP SPFILE = 524
Resync in progress: 11000 RMAN OUTPUTrecords resynced
RMAN Command Id : 2025-08-11T14:58:25
RMAN Command Id : 2025-08-11T14:58:25
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03008: error while performing automatic resync of recovery catalog
ORA-02291: integrity constraint (RMANCAT.RLH_F1) violated - parent key
not found
RMAN Client Diagnostic Trace file :
/oracle/diag/clients/user_oracle/RMAN_3026693161_110/trace/ora_
rman_37312_1.trc
RMAN Server Diagnostic Trace file :
/oracle/diag/rdbms/ORCL/ORCL/trace/ORCL_ora_37319.trc

Root Cause: Recovery Catalog Not Current
Upon attempting to connect to the RMAN catalog, we received the following message:

$ rman catalog rmancatusr@CATDB

Recovery Manager: Release 19.0.0.0.0 - Production on Tue Aug 09 01:38:51 2025
Version 19.28.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.

recovery catalog database Password:
connected to recovery catalog database
PL/SQL package RMANCAT.DBMS_RCVCAT version 19.10.00.00. in RCVCAT database is not current
PL/SQL package RMANCAT.DBMS_RCVMAN version 19.10.00.00 in RCVCAT database is not current


This indicates that the RMAN catalog was not upgraded and was out of sync with the new database release.

Solution: Upgrade the RMAN Catalog
To resolve the issue, we needed to upgrade the RMAN catalog. The solution was to run the following command:

$ rman catalog <catalog user/passwd> @catdb
RMAN> upgrade catalog ;

The issue has been RESOLVED after upgrading the database. The user able to register database and able to run backups without any issues.

Conclusion

This issue was caused by the RMAN catalog being out of sync after applying a DB RU patch. Upgrading the catalog resolved the error, allowing successful database registration and backup operations.

Tuesday, November 19, 2024

ORA-04031: unable to allocate 12312 bytes of shared memory ("shared pool","unknown object","KKSSP^212","kglseshtTable")

We recently encountered the following error in 19c, which typically occurs when the database needs additional shared memory. In most of the cases setting MAX_SGA_SIZE to a higher value will resolve the issue.

Below are some possible cause
  •  Insufficient memory allocated via initialization parameters
  •  Fragmentation in app design
  •  Auto tuning issues
  •  A Bug causing the issue
  •  Memory leaks
ORA-04031: unable to allocate 12312 bytes of shared memory ("shared pool","unknown object","KKSSP^334","kglseshtTable")
< ORA-00604: error occurred at recursive SQL level 1 < ORA-04031: unable to allocate 40 bytes of shared memory ("shared pool","unknown object","KGLH0^f185eace","kglHeapInitialize:temp")
< ORA-04031: unable to allocate 12312 bytes of shared memory ("shared pool","unknown object","KKSSP^394","kglseshtTable")



The error message will provide the amount of memory unavailable, memory pool facing the issue and failed allocation details
 

I would highly suggest running below query to get the optimal value for SGA_TARGET
Select * from V$SGA_TARGET_ADVICE

Note that in order to initialization parameters to take into effect we need to bounce the instance.

AGLT>oerr ora 04031
04031, 00000, "unable to allocate %s bytes of shared memory (\"%s\",\"%s\",\"%s\",\"%s\")"
// *Cause: More shared memory is needed than was allocated in the shared
// pool or Streams pool.
// *Action: If the shared pool is out of memory, either use the
// DBMS_SHARED_POOL package to pin large packages,
// reduce your use of shared memory, or increase the amount of
// available shared memory by increasing the value of the
// initialization parameters SHARED_POOL_RESERVED_SIZE and
// SHARED_POOL_SIZE.
// If the large pool is out of memory, increase the initialization
// parameter LARGE_POOL_SIZE.
// If the error is issued from an Oracle Streams or XStream process,
// increase the initialization parameter STREAMS_POOL_SIZE or increase
// the capture or apply parameter MAX_SGA_SIZE.
// parameter MAX_SGA_SIZE.

Refer below links for Oracle support notes
  • This Oracle support note provides information about ORA-04031 related bugs and which release they were fixed
OERR: ORA-4031 "unable to allocate %s bytes of shared memory ("%s","%s","%s")" (Doc ID 4031.1)
  • This Oracle note provides detailed troubleshooting and diagnosing details
Troubleshooting and Diagnosing ORA-4031 Error [Video] (Doc ID 396940.1)
  • This Oracle note provides detailed understanding and tuning of the of the shared pool
NOTE:62143.1 - Troubleshooting: Understanding and Tuning the Shared Pool

Thanks & Regards,
https://oracleracexpert.com

Friday, August 30, 2024

Opatch failed with "Make failed to invoke "/usr/bin/make -f ins_net_client.mk client_sharedlib"

I encountered a patch failure while upgrading to Oracle 19.23. I received "Opatch session completed with warnings".

The error clearly indicates that the root cause is a missing "shrept.lst" file.

Make failed to invoke "/usr/bin/make -f ins_net_client.mk client_sharedlib ORACLE_HOME=/oracle/product/19.x.0.0/dbhome_1 OPATCH_SESSION=apply"....'genclntsh: genclntsh: Could not locate /oracle/product/19.x.0.0/dbhome_1/network/admin/shrept.lst

make: *** [ins_net_client.mk:143: client_sharedlib] Error 1
'
Make failed to invoke "/usr/bin/make -f ins_rdbms.mk client_sharedlib ORACLE_HOME=/oracle/product/19.x.0.0/dbhome_1 OPATCH_SESSION=apply"....'genclntsh: genclntsh: Could not locate /oracle/product/19.x.0.0/dbhome_1/network/admin/shrept.lst
make: *** [ins_rdbms.mk:56: client_sharedlib] Error 1
'
Make failed to invoke "/usr/bin/make -f ins_ldap.mk ldapsearch ORACLE_HOME=/oracle/product/19.x.0.0/dbhome_1 OPATCH_SESSION=apply"....'genclntsh: genclntsh: Could not locate /oracle/product/19.x.0.0/dbhome_1/network/admin/shrept.lst

make: *** [/oracle/product/19.x.0.0/dbhome_1/ldap/lib/env_ldap.mk:2474: /oracle/product/19.x.0.0/dbhome_1/lib/libclntsh.so] Error 1
'
The following make actions have failed :

Re-link fails on target "client_sharedlib".
Re-link fails on target "client_sharedlib".
Re-link fails on target "ldapsearch".

Do you want to proceed? [y|n]
y
User Responded with: Y
Patch 36233263 successfully applied.
Sub-set patch [34765931] has become inactive due to the application of a super-set patch [36233263].
Please refer to Doc ID 2161861.1 for any possible further required actions.
OPatch Session completed with warnings.
Log file location: /oracle/product/19.x.0.0/dbhome_1/cfgtoollogs/opatch/opatch2024-08-24_22-25-17PM_1.log

I have reviewed the opatch log file to verify the error and I can see the the same error.

[Aug 24, 2024 11:32:40 PM] [INFO] Deleted the file "/oracle/product/19.x.0.0/dbhome_1/.patch_storage/unzip_action/1723357551241/inventory/Templates/perl/bin/zipdetails"

[Aug 24, 2024 11:32:40 PM] [INFO] --------------------------------------------------------------------------------
[Aug 24, 2024 11:32:40 PM] [INFO] The following warnings have occurred during OPatch execution:
[Aug 24, 2024 11:32:40 PM] [INFO] 1) OUI-67200:Make failed to invoke "/usr/bin/make -f ins_net_client.mk client_sharedlib ORACLE_HOME=/oracle/product/19.x.0.0/dbhome_1 OPATCH_SESSION=apply"....'genclntsh: genclntsh: Could not locate /oracle/product/19.x.0.0/dbhome_1/network/admin/shrept.lst
make: *** [ins_net_client.mk:143: client_sharedlib] Error 1

'
[Aug 24, 2024 11:32:40 PM] [INFO] 4) OUI-67124:Re-link fails on target "client_sharedlib".
Re-link fails on target "client_sharedlib".
Re-link fails on target "ldapsearch".
[Aug 24, 2024 11:32:40 PM] [INFO] --------------------------------------------------------------------------------
[Aug 24, 2024 11:32:40 PM] [SEVERE] OUI-67008:OPatch Session completed with warnings.
[Aug 24, 2024 11:32:40 PM] [INFO] Finishing UtilSession at Sat Aug 24 23:32:40 PDT 2024
[Aug 24, 2024 11:32:40 PM] [INFO] Log file location: /oracle/product/19.x.0.0/dbhome_1/cfgtoollogs/opatch/opatch2024-08-24_22-25-44PM_1.log

we found that shrept.lst file was missing and have rollback the patch using
$ opatch rollback -id <xxxxxx>

We copied the shrept.lst file from another environment, re-applied the patch using "opatch apply," and the process completed successfully without any issues.

Thanks & Regards
https://oracleracexpert.com

Friday, January 5, 2024

Oracle Agile Application or Quick Search performance issue and how to resolve?

When you come across any performance issue on agile first, you need to verify schema integrity by running agile9_check.sql.

The agile9_check.sql it verifies Database Schema version with Agile Schema version, and it MUST match. Also, it validates schema objects against Agile schema version and report any errors or warnings.

You may see ERRORS/WARNINGS
ERROR: Missing or INVALID index (columns) XXXXXXXXX on table XXXXX.
ERROR: Missing or INVALID FTS CTX indexes XXXXXXX.
WARNING: ACTIVITY_BASELINE_XXXXX does not belong to AGILE DB. Please Drop the Table if not required.

In case of any Errors/Warnings you need we need to fix the issue. If you have created any custom objects you will see WARNING that object doesn't  below to Agile DB and you can ignore. 

Once user fix the schema integrity download listFTSInfo.sql and run the script as Agile user and it will generate listFTSInfo_xxxxxxxxxx.log file. You need to search for "029", where it says "List Index Percent of Fragmentation" where you can see the indexes that has fragmentation.

If you see any fragmentation, it will effect Quick search and stuck threads will be generated.

<[STUCK] ExecuteThread: '19' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "1,247" seconds working on the request "Http Request Information: weblogic.servlet.internal.ServletRequestImpl@2f2fb94[GET /Agile/PCMServlet]
", which is more than the configured time (StuckThreadMaxTime) of "1,200" seconds in "server-failure-trigger". Stack trace:
java.net.SocketInputStream.socketRead0(Native Method)


To resolve the issue, Log into sqlplus as agile database user, and run agile_ctx_recreate.sql found under %Oracle_base%\admin\{SID}\create\{agile_schema_username} to rebuild CTX indexes.

Oracle support recommends stopping Agile application, run agile_ctx_recreate.sql and Start the Application.

It is highly advisable to run complie_Invalid_objects.sql, agile9stats.sql to recompile invalid objects and collect stats to improve the performance.

Refer Oracle Agile support doc for Full Text search (FTS) Enablement, synchronization, Indexing and optimization.

Frequently Asked Questions on Agile Product Lifecycle Management (PLM) Full Text Search (FTS) Enablement, Synchronization, Indexing, and Optimization (Doc ID 1503311.1)

For Agile Stuck thread issue, refer below Oracle support Doc ID

Agile Managed Servers Goes to Warning State, Having Stuck Thread at com.agile.cs.query.QuerySessionBean (Doc ID 2919154.1)

Thanks & Regards
https://oracleracexpert.com, Oracle ACE

Thursday, November 9, 2023

ORA-29861: domain index is marked LOADING/FAILED/UNUSABLE

When users performing the transactions on tables where DOMAIN,SPATIAL indexes are part of it they may receive below error and unable to proceed.

SQL> DELETE FROM USER_URL where CXT_ID=8484884;
ERROR at line 1: ORA-29861: domain index is marked LOADING/FAILED/UNUSABLE

The main reason for this error is user might have copied the table/index using export/import or different method but the CREATE INDEX and failed.

Find out what caused the failure of CREATE INDEX. In many cases not having enough space on the Tablespace where you are creating the index is the culprit.

SQL> SELECT INDEX_NAME, TABLE_NAME STATUS,DOMIDX_STATUS,DOMIDX_OPSTATUS FROM DBA_INDEXES WHERE DOMIDX_OPSTATUS='FAILED';

INDEX_NAME     TABLE_NAME STATUS   DOMIDX_STATUS  DOMIDX_OPSTATUS
------------------ --------------- ---------- --------------------- -------------------------  
USER_URL_IDX  USER_URL      VALID    VALID                    FAILED


When verified I found that schema refreshed recently, and index not created successfully.

ORA-31693: Table data object "FIN"."USER_URL" failed to load/unload and is being skipped due to error:
ORA-29861: domain index is marked LOADING/FAILED/UNUSABLE

If you need workaround to proceed with transactions immediately, then drop the index.
The permanent fix will be drop and recreate index successfully.

To avoid this type of issues, make sure you perform following checks.

1. Before refresh verify the tablespace or file systems has enough space and add required space
2. After import check the data pump or import log file and fix all failures
3. Run utlrp.sql to recompile all invalid objects.

Thanks & Regards


Friday, October 20, 2023

ORA-02304: invalid object identifier literal and ORA-39083 errors during impdp

Users might receive below error during the import.

ORA-39083: Object type TYPE:"ORCL"."OID_TAB1" failed to create with error:
ORA-02304: invalid object identifier literal


Failing sql is:
CREATE EDITIONABLE TYPE "ORCL"."OID_TAB1" OID 'FB3CF41KK327B011D053F114ABBC878C' AS OBJECT (
className1 VARCHAR2(200),
id1 NUMBER)


Run below query in the database and check for TPYE_ODI exists or not
 
SQL> select OWNER, TYPE_NAME from DBA_TYPES where TYPE_OID='FB3CF41KK327B011D053F114ABBC878C ';

OWNER TYPE_OID
------------------------------------------ --------------------------------
ORCL      FB3CF41KK327B011D053F114ABBC878C

In most cases you will see the ODI is already exists in the database. The ODI already exists, and you cannot create ODI with same name that’s why it failed. You need to follow one of the options.

1. Create the object with new ODI – You can remove the ODI clause from the statement and run again. The database will generate new ODI for the object.

2. Drop the existing TYPE_ODI and reimport - DROP the object and reimport so that object will create with same ODI

3. In “impdp” use the parameter transform=oid:n - Using the parameter during the impdp will import TYPES with new ODI.

I have used all 3 methods based upon different scenarios.

Thanks & Regards,
http://oracleracexpert.com




Monday, October 16, 2023

WARNING: inbound connection timed out (ORA-3136)

The ORA-3136 will be written into alert.log when users fails to provide credentials and cannot authenticate within the set timeout value.

The default value set for below parameters in sqlnet.ora is 60 seconds.

SQLNET.INBOUND_CONNECT_TIMEOUT
INBOUND_CONNECT_TIMEOUT_listener_name

You will see below error in the alert.log file

Fatal NI connect error 12170.
VERSION INFORMATION:
TNS for Linux: Version 19.0.0.0.0 - Production
Oracle Bequeath NT Protocol Adapter for Linux: Version 19.0.0.0.0 - Production
TCP/IP NT Protocol Adapter for Linux: Version 19.0.0.0.0 - Production
Version 19.5.0.0.0
Time: 14-OCT-2023 18:06:02
Tracing not turned on.
Tns error struct:
ns main err code: 12535

TNS-12535: TNS:operation timed out
ns secondary err code: 12606
nt main err code: 0
nt secondary err code: 0
nt OS err code: 0
Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=xxx.xx.xxx.xx)(PORT=51290))
2023-10-12T16:06:02.222415-07:00
WARNING: inbound connection timed out (ORA-3136)
2023-10-12T16:15:18.866821-07:00


In the above log you can see the client IP and port, you can able to check corresponding entry in the listener log as well. Also, you can see the time stamp of user initiated the connection and time stamp when user got error, it will be more than 60 sec.

The main reason for the error is …

1. When user or application trying to connect using wrong credentials or no attend made under 1 min threshold default value of the instance.

You can able to reproduce the issue by entering wrong credentials
 
SQL> sqlplus HR/xxxx@orcl
SQL*Plus: Release 19.0.0.0.0 - Production on Fri Oct 13 19:31:30 2023
Version 19.18.0.0.0
Copyright (c) 1982, 2022, Oracle. All rights reserved.

ERROR:
ORA-01017: invalid username/password; logon denied

$ tail -f orcl_alert.log
Fri Oct 13 19:32:31 2023
WARNING: inbound connection timed out (ORA-3136)

2. If the database has some performance issues or any network delay can cause long time and cannot authenticate user within default time out i.e. 60 seconds

If the database has some load causing the slowness, then increasing SQLNET.INBOUND_CONNECT_TIMEOUT to higher value will help to reduce the errors.

No DB restart required when you make the change in sqlnet.ora but note that it will be applicable to next server process.

3. The server receives the request but cannot be able to authenticate with in default time out i.e. 60 seconds

Find out what causing the delay in authentication if required increase the time out value.

If you are receiving error frequently you can enable tracing using below command
SQL> alter system set events '3136 trace name errorstack level 3';
 
You can trun off tracing using
SQL> alter system set events '3136 trace name context off';

Note that tracing will be generated under USER_DUMP_DEST or BACKGROUND_DUMP_DEST

If you still seeing these warnings I would suggest to raise a ticket with oracle support

Thanks,
https://oracleracexpert.com

Monday, August 14, 2023

Article: Mastering Data History using Oracle's Flashback Data Archive Feature

The Historical data is key for business decisions and having reliable data is very important for organizations. There are frequent implications for both financial and legal data for organizations and having a secure and accurate history of change of data is crucial for business.

Oracle Flashback technology offers significant benefits for database management and recovery. 

Please see the below article how it will help to meet the organizational needs.



Thanks,
https://oracleracexpert.com

Thursday, June 8, 2023

Oracle 19c import issues ORA-31693, ORA-02354, ORA-39002, ORA-39405

When performing import come across the following issue

ORA-31693: Table data object "ORCL"."ITEMCG" failed to load/unload and is being skipped due to error:
ORA-02354: error in exporting/importing data
ORA-39840: A data load operation has detected data stream format error .
ORA-39844: Bad stream format detected: [klaprs_62] [139751105749101] [139751105749012] [4] [2] [2065583] [] []

User may encounter this issue when new column added to a table with cokumn optimization enabled and the same column was modified.

Below are the workarounds

  • Use access_method=EXTERNAL_TABLE during export
  • Prior export add and drop a dummy column to the problematic table using
SQL> ALTER TABLE <table_name> ADD dummy number;
SQL> ALTER TABLE <table_name> DROP dummy number;
  • Take export of failed table and import using CONTENT=DATA_ONLY as tableau structure already imported.

The fix for this bug was initially available on 19.13 and above see if it helps.

Also, I come across below issues when importing data

ORA-39002: invalid operation
ORA-39405: Oracle Data Pump does not support importing from a source database with TSTZ version 33 into a target database with TSTZ version 32.

User may encounter this issue when export from higher time zone version and importing into lower time zone version.
  • Patch the target database to higher or equal to source time zone patch or DST TZ version
  • Create a database with same time zone and perform export/import
For latest DST patches refer,
  • Oracle RDBMS and OJVM DST-related notes
  • Updated DST Transitions and New Time Zones in Oracle RDBMS and OJVM Time Zone File Patches (Doc ID 412160.1)

Hope this helps,

Thanks & Regards

Active Sessions, Proxy Sessions and Locked objects in Oracle

I have received few requests from Oracle User community to provide SQL queries related to active sessions, proxy sessions and locked objects in a session. Here are few SQL queries which you can use in day to day monitoring.
 
--------------------------------------------------------
--Script : ACTIVE SESSIONS
--Author : oracleracexpert.com
--------------------------------------------------------
SET PAGESIZE 1000
SET LINESIZE 600

COLUMN username FORMAT A10
COLUMN osuser FORMAT A10
COLUMN sid FORMAT 9999
COLUMN serial# FORMAT 999999999
COLUMN status FORMAT A10
COLUMN machine FORMAT A20
COLUMN program FORMAT A40
COLUMN module FORMAT A35
COLUMN action FORMAT A15
COLUMN logon_time FORMAT A20

SELECT s.username,
s.osuser,
s.sid,
s.serial#,
p.spid,
s.lockwait,
s.status,
s.machine,
s.program,
s.module,
s.action,
TO_CHAR(s.logon_Time,'MM-DD-YYYY HH24:MI:SS') AS logon_time,
s.blocking_session_status AS BlockStatus
FROM v$session s, v$process p
WHERE s.paddr = p.addr
AND s.status = 'ACTIVE'
ORDER BY s.username, s.osuser;

------------------------------------
--Script : Active Session waits
--Author : oracleracexpert.com
------------------------------------
SET PAGESIZE 1000
SET LINESIZE 600

COLUMN username FORMAT A10
COLUMN osuser FORMAT A10
COLUMN sid FORMAT 9999
COLUMN serial# FORMAT 999999999
COLUMN spid FORMAT A10
COLUMN state FORMAT A10
COLUMN wait_class FORMAT A20
COLUMN seconds_in_wait FORMAT 999999999
COLUMN module FORMAT A35
COLUMN blocking_session FORMAT A20
COLUMN blocking_session_status FORMAT A20

SELECT s.username,
       s.osuser,
       s.sid,
       s.serial#,
   p.spid, 
       s.state,
   s.wait_class,
       s.seconds_in_wait,
       s.module,
       TO_CHAR(s.logon_Time,'MM-DD-YYYY HH24:MI:SS') AS logon_time,
   s.blocking_session,
       s.blocking_session_status AS BlockStatus
FROM   v$session s, v$process p
WHERE  s.paddr  = p.addr
AND    s.status = 'ACTIVE'
ORDER BY 1,2;


--------------------------------------------------------
--Script : PROXY SESSIONS
--Author : oracleracexpert.com
--------------------------------------------------------

SET PAGESIZE 1000
SET LINESIZE 600

COLUMN username FORMAT A10
COLUMN osuser FORMAT A10
COLUMN sid FORMAT 9999
COLUMN serial# FORMAT 999999999
COLUMN status FORMAT A10
COLUMN machine FORMAT A20
COLUMN program FORMAT A40
COLUMN module FORMAT A35
COLUMN action FORMAT A15
COLUMN logon_time FORMAT A20

SELECT s.username,
s.osuser,
s.sid,
s.serial#,
p.spid,
s.lockwait,
s.status,
s.machine,
s.program,
s.module,
s.action,
TO_CHAR(s.logon_Time,'MM-DD-YYYY HH24:MI:SS') AS logon_time,
s.blocking_session_status AS BlockStatus
FROM  v$session s, v$process p, v$session_connect_info sci
WHERE s.paddr = p.addr
AND s.sid = sci.sid
AND s.serial# = sci.serial#
AND sci.authentication_type = 'PROXY'
ORDER BY s.username, s.osuser;

--------------------------------------------------------
--Script : LOCKED OBJECT SESSIONS
--Author : oracleracexpert.com
--------------------------------------------------------

SET PAGESIZE 1000
SET LINESIZE 600

COLUMN sid FORMAT 9999
COLUMN serial# FORMAT 999999999
COLUMN status FORMAT A10
COLUMN owner FORMAT A20
COLUMN object_owner FORMAT A20
COLUMN object_name FORMAT A30
COLUMN object_type FORMAT A15
COLUMN oracle_username FORMAT A15
COLUMN locked_mode FORMAT A15
COLUMN os_user_name FORMAT A15

SELECT s.sid,
s.serial#,
s.status,
do.owner,
do.object_name,
do.object_type,
lo.oracle_username,
Decode(lo.locked_mode, 0, 'None',
1, 'Null (NULL)',
2, 'Row-S (SS)',
3, 'Row-X (SX)',
4, 'Share (S)',
5, 'S/Row-X (SSX)',
6, 'Exclusive (X)',
lo.locked_mode) locked_mode,
lo.os_user_name
FROM v$locked_object lo, dba_objects do, v$session s
WHERE lo.session_id = s.sid
AND do.object_id = lo.object_id
ORDER BY 1, 2, 3, 4;

Thanks & Regards,
https://oracleracexpert.com

Tuesday, May 30, 2023

Errors ORA-12154, ORA-29003 when connecting to Autonomous Data Warehouse using Django

When connection to Autonomous Data Warehouse Using Django web framework first we come across “ORA-12154” error. That means Django cannot be able to connect to the Oracle Database service name with the settings in settings.py file.

File "C:\django\db\backends\oracle\base.py", line 254, in get_new_connection return Database.connect( cx_Oracle.DatabaseError: ORA-12154: TNS:could not resolve the connect identifier specified

First copy the tnsnames.ora into local system and test tnsping.

C:\> tnsping <service Name>

If the tnsping is working fine, then below are the passible reason for ORA-12154 error
  • TNS_ADMIN might not be configured or set the right path
  • There might be a typo in service name
  • Connection details in settings.py might not be correct
We found that TNS_ADMIN is not set to the right path and updating the correct path resolved the issue. But we have received new error

ORA-29003: SSL transport detected mismatched server certificate

Django supports Oracle Database 19c or higher versions but cx_oracle python driver required. We verified that required driver is installed. We try to connect using SQL*PLUS but still receiving same error. That means there is no issue with the settings.

After research we found that 12c client is not supported for new mTLS authentication as per document “ALERT: Action Required for Autonomous Databases (Doc ID 2911553.1)”

We have installed Oracle 19c client and were able to connect without any issues.

Below are the options to resolve the issue

1. Install certified oracle client versions 11.2.0.4.220719 (or later), 18.19 (or later), 19.2 (or later), 21 (base release or later)

2. Update Autonomous database instance to allow both TLS and mTLS authentication.
  • Goto Autonomous Database Details page --> Network --> click Edit in the Mutual TLS (mTLS) Authentication field.
  • Change the value to allow TLS authentication, deselect Require mutual TLS (mTLS) authentication
  • Click Update
3. Use ssl_server_dn_match=no in the connect string (when using 12c client updating the value to “no” didn’t help )

I hope this helps.

Thanks
Satishbabu G, Oracle ACE Pro

Thursday, March 2, 2023

Oracle AutoUpgrade with source and Target Database on different servers

AutoUpgrade utility can be used on upgrading databases from 12c R2 release (12.2 + DBJAN2019RU and newer) and it has Analyze, Fixup, Deploy and Upgrade processing modes. 

Before you proceed make sure you meet following requirements.
  • create config file
  • Source Database should be running in original oracle home
  • The Database server should be registered in DNS
  • JAVA8 required for Autoupgrade to run. Oracle 12c R2 (12.2.0.1) or newer oracle homes have a java version by default.
  • If you run AutoUpgrade in batch or script mode use “noconsole” parameter
From Oracle 19c (10.3) autoupgrade.jar file exists by default, for earlier releases you must download latest autoupgrade.jar file from Oracle support.

There are four AutoUpgrade modes and each mode performs different steps
  •  Analyze Mode: Setup, Pre-checks.
  • Fixups Mode: Setup, Pre-checks, and Pre-fixups.
  • Deploy Mode: Setup, Guaranteed Restore Point, Pre-upgrade, Pre-checks, Pre-fixups, Drain,      Database Upgrade, Post-checks, Post-fixups, and Post-upgrade.
  • Upgrade Mode: Setup, Database Upgrade, Post-checks, and Post-fixups.
Analyze Mode: This mode runs few checks to see weather database is ready for upgrade. In this mode it only reads data from database to analyze and does not perform any changes.

You can run this step on source database before you setup target.

Run below command to start AutoUpgrade Analyze

$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar – config /home/oracle/autoupgrade/config.txt -mode analyze

Make sure you analyze output files for errors and run fixup on Source database server. You should see SID.html and SID_preupgrade.log files

Note that this mode also generates status files such as status.json, progress.json which can be located under cfgtoollogs/upgrade/auto/status.

Status.json – This file contains High level status of upgrade.
Progress.json – This file has contains status of progress of all upgrades

In case if target database is not on the same server then you must set the source home path in the configuration file, so that Autoupgrade analyze can run on source oracle home.

For example,
upgrade1.source_home=/home/oracle/product/12.2.0.1/dbhome_1 # Source ORACLE_HOME Path
upgrade1.target_home=/home/oracle/product/19.0.0.0/dbhome_1 # Target ORACLE_HOME Path

Fixups Mode : This mode performs all required automated fix up that are required before you start an upgrade. In this mode it creates guaranteed restore point.

Run below command on source Database server to run fixups.

$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar – config /home/oracle/autoupgrade/config.txt -mode fixups

Deploy Mode: This mode performs all required actions for an upgrade, which include analyze, fixups, upgrade and post upgrade steps. You will use this mode when source and target Oracle Home’s are on the same server. This mode also creates guaranteed restore point.

Run below command on source Database server to run fixups.

$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar – config /home/oracle/autoupgrade/config.txt -mode Deploy

Move the database from source to Target Database server and perform Upgrade mode.

Upgrade Mode: You will run this Autoupgrade mode when you are moving database to Target server or don’t have source Oracle home access. This mode is used only when you are moving to new server. But note that this mode doesn’t create guaranteed restore point and it doesn’t perform the post upgrade steps.

Before you perform upgrade make sure you copy the during_upgrade_pfile_dbname.ora from source to target Oracle Home with default name init<SID>.ora. You can also create the spfile using during_upgrade_pfile_dbname.ora which can be found under temp directory.

SQL> create spfile from pfile=' /home/oracle/autoupgrade/au21/TESTDB/temp/during_upgrade_pfile_testdb.ora';

On Target database server start the database in upgrade mode and run below command to upgrade

$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar – config /home/oracle/autoupgrade/config.txt -mode upgrade

After upgrade make sure you perform post upgrade steps manually

· Copy network files sql.net ora, listener,ora, tnsnames.ora files..etc
· Restart of database in case of RAC
· Remove guaranteed restore point

Thanks & Regards,
https://oracleracexpert.com, Oracle ACE

Wednesday, February 22, 2023

Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class

When launching Database configuration assistant (DBCA) you may encounter this error. The “java.lang.NoClassDefFoundError” error encounter when it could not initialize class “sun.awt.X11.XToolkit”. 

This normally occur when launching Graphic user interface (GUI)

No protocol specified
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class sun.awt.X11.XToolkit
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at java.awt.Toolkit$2.run(Toolkit.java:860)
at java.awt.Toolkit$2.run(Toolkit.java:855)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:854)
at com.jgoodies.looks.LookUtils.isLowResolution(LookUtils.java:484)
at com.jgoodies.looks.LookUtils.<clinit>(LookUtils.java:249)
at com.jgoodies.looks.plastic.PlasticLookAndFeel.<clinit>(PlasticLookAndFeel.java:135)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at javax.swing.SwingUtilities.loadSystemClass(SwingUtilities.java:1879)
at javax.swing.UIManager.setLookAndFeel(UIManager.java:582)
at oracle.install.commons.util.Application.startup(Application.java:976)
at oracle.install.commons.flow.FlowApplication.startup(FlowApplication.java:181)
at oracle.install.commons.flow.FlowApplication.startup(FlowApplication.java:198)
at oracle.assistants.common.base.driver.AssistantApplication.startup(AssistantApplication.java:336)
at oracle.assistants.dbca.driver.DBConfigurator.startup(DBConfigurator.java:378)
at oracle.assistants.dbca.driver.DBConfigurator.main(DBConfigurator.java:513)

The main causes of the issue is
1. The DISPLAY variable is NOT set or value is not correct.
2. X Windows is not installed
3. Oracle user not added to ACL (Access Control List)

If launching from server make sure you have any X Windows software installed and install org-x11-apps.x86_64 package

If you are launching from a local workstation, make sure you have XGraphics software such as Exceed, VLC…etc tools installed. Then You can set DISPLAY by using below command

CSH
$ setenv DISPLAY <IP Address of workstation or server>:0

SSH or KSH
$ export DISPLAY=<IP Address of workstation or server>:0

In Some cases, users may face issue when installing Oracle software on Ubuntu or Linux environment.

>>> Could not execute auto check for display colors using command /usr/bin/xdpyinfo. Check if the DISPLAY variable is set. Failed <<<<

Some requirement checks failed. You must fulfill these requirements before
continuing with the installation,
Continue? (y/n) [n] Y

>>> Ignoring required pre-requisite failures. Continuing...
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2019-08-01_12-17-01PM. Please wait ....oracle$:~$ No protocol specified
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class sun.awt.X11.XToolkit

In this scenario, verify weather JDK installed on the system or not using below command
$ java -version

If not installed then installing required JDK will resolve the issue. If the problem persists, then run below command by logging as root

$ xhost +

Switch back to Oracle user and run the installation.

Thanks,
https://oracleracexpert.com, Oracle ACE Pro

Thursday, February 16, 2023

Upgrade Oracle Database using AutoUpgrade Utility

Autoupgrade is used to upgrade one or more databases using command line. Using the tool, you can run pre-upgrade tasks that will provide the fixups, all recommended fixups must be executed before upgrading the database and finish the upgrade by running the post-upgrade tasks. By using this utility you can upgrade hundreds of databases with one command.

It is always recommending that you run AutoUpgrade in Analyze mode before running in Fixup mode. Note that fixup mode can make changes to the source database. The Autoupgrade includes automatic retry and fallback, schedule upgrades and modify or remove the initialization parameters which are deprecated.

AutoUpgrade utility can be used on upgrading databases from 12c R2 release (12.2 + DBJAN2019RU and newer)

You need to download AutoUpgrade utility for Databases 12c R2 and 18c. From 19.3 (19c) and later the autoupgrade.jar file exists by default.

Oracle home must contain JAVA to use AutoUpgrade Tool. Always download latest AutoUpgrade.jar file

Create a sample config.txt file for database ugrade

upgrade1.sid=TESTDB                       # ORACLE_SID of source DB
upgrade1.run_utlrp=no                       # Optional. To run utlrp after upgrade select YES
upgrade1.timezone_upg=no                # Optional. To run the timezone upgrade select YES
upgrade1.start_time=now                    # Optional Use “NOW” or specify future upgrade time and date [+XhYm (X hours, Y minutes) | dd/mm/yyyy hh:mm:ss]      
upgrade1.upgrade_node=localhost    # Optional. Default is 'localhost'
upgrade1.target_version=19               # Only required if target database version is 12.2
upgrade1.log_dir= /home/oracle/cfgtoollogs/autoupgrade/TESTDB # Log dir path for the upgrade job
upgrade1.source_home=/home/oracle/product/12.2.0.1/dbhome_1  # Source ORACLE_HOME Path 
upgrade1.target_home=/home/oracle/product/19.0.0.0/dbhome_1   # Target ORACLE_HOME Path 

AutoUpgrade with source and Target Database on same server
  • Run below command to start AutoUpgrade Analyze
$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar – config /home/oracle/autoupgrade/config.txt -mode analyze
AutoUpgrade utility launched with default options
Processing config file ...
+--------------------------------+
| Starting AutoUpgrade execution |
+--------------------------------+
1 databases will be analyzed
Type 'help' to list console commands
upg> Job 100 completed
------------------- Final Summary --------------------
Number of databases [ 1 ]
Jobs finished [1]
Jobs failed [0]
Jobs pending [0]
------------------- JOBS FINISHED SUCCESSFULLY --------------------
Job 100 for TESTDB

All the logs are under the job id . Pls review all the logs for any errors and information.

You can see the warnings and errors in html file.

 

  • Run below command to start deployment of upgrade on same server
$ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/rdbms/admin/autoupgrade.jar – config /home/oracle/autoupgrade/config.txt -mode deploy

AutoUpgrade utility launched with default options
Processing config file ...
+--------------------------------+
| Starting AutoUpgrade execution |
+--------------------------------+
1 databases will be processed
Type 'help' to list console commands
upg>


upg> lsj
+----+-------+---------+---------+-------+--------------+--------+---------------+
|Job#|DB_NAME| STAGE|OPERATION| STATUS| START_TIME| UPDATED| MESSAGE|
+----+-------+---------+---------+-------+--------------+--------+---------------+
| 102| TESTDB|DBUPGRADE|EXECUTING|RUNNING|21/05/12 15:03|15:35:22|95% Upgraded |
+----+-------+---------+---------+-------+--------------+--------+---------------+
Total jobs 1

Once upgrade is completed verify upg_summary.log for any errors

/u01/home/oracle:DBA>cat upg_summary.log
Oracle Database Release 19 Post-Upgrade Status Utility 04-30-2021 11:07:0
Database Name: TESTDB
Component Current Full Elapsed Time
Name Status Version HH:MM:SS
Oracle Server UPGRADED 19.10.0.0.0 00:09:54
JServer JAVA Virtual Machine VALID 19.10.0.0.0 00:01:12
Oracle XDK UPGRADED 19.10.0.0.0 00:00:38
Oracle Database Java Packages UPGRADED 19.10.0.0.0 00:00:05
Oracle Text UPGRADED 19.10.0.0.0 00:00:23
Oracle Workspace Manager UPGRADED 19.10.0.0.0 00:00:22
Oracle Real Application Clusters OPTION OFF 19.10.0.0.0 00:00:00
Oracle XML Database UPGRADED 19.10.0.0.0 00:00:51
Oracle Multimedia UPGRADED 19.10.0.0.0 00:01:47
Datapatch 00:01:41
Final Actions 00:01:44
Post Upgrade 00:00:16

Total Upgrade Time: 00:17:31

Database time zone version is 26. It is older than current release time
          zone version 32. Time zone upgrade is needed using the DBMS_DST package.

          Grand Total Upgrade Time: [0d:0h:20m:20s]


If you select upgrade1.timezone_upg=YES then Time zone will be upgraded as part of the Database upgrade. 

AutoUpgrade Stages

AutoUpgrade utility go through series of steps called stages but the actions performed during every stage defined by the “processing mode”. For AutoUpgrade we have Analyze, Fixups, Deploy, and Upgrade processing modes.

AutoUpgrade has the following stages: 
  • SETUP: The initial stage in which it starts the job.
  • PREUPGRADE: The stage in which it performs readiness for upgrade such as sufficient space
  • PRECHECKS: The stage in which it performs pre-checks on source Oracle home to meet requirements for upgrade.
  • GRP: Backup database using guaranteed restore point (GRP) before upgrade, this option only available in Enterprise Edition only
  • PREFIXUPS: The stage in which it performs preupgrade fixups before upgrade
  • DRAIN: The stage during which it shuts down the database to release resources.
  • DBUPGRADE: The stage in which it performs the actual upgrade.
  • POSTCHECKS: The stage in which it performs post upgrade checks on the target Oracle home before executing any postupgrade fixups.
  • POSTFIXUPS: The stage in which it performs processing of postupgrade fixups, timezone upgrade is part of this step.
  • POSTUPGRADE: The stage in which in copies or merges the required files from to the target Oracle home for ex:- listener, tns files
There are 2 operational modes during Autoupgrade, i.e. PREPARING and EXECUTING

There are 4 state messages
  • RUNNING – AutoUpgrade is still running
  • FINISHED - AutoUpgrade is successfully completed
  • ERROR – AutoUpgrade has some Errors
  • ABORTED - AutoUpgrade aborted response to user request.
Refer useful oracle support notes
Thanks & Regards,
https://oracleracexpert.com, Oracle ACE

Tuesday, November 8, 2022

Physical Standby Recovery or Sync Using Recover from Service from 18c

The RECOVER FROM SERVICE is used to recover data guard database which is out of sync or lagging standby. Before 12c the user needs to determine the current SCN, take a backup and apply, start managed recovery of standby and but in 12c they automated these steps but user still needs to perform few manual steps such as control file update. 

This feature has been improved in Oracle 18c and covers all the steps that DBA used to perform manually

Primary : DBPRI
Standby: DBSTB

Steps if the database is Oracle 18c or above

1. Check the Data Guard Broker configuration.

DGMGRL> show configuration
Configuration – dg_config
Protection Mode: MaxPerformance

Members:
dbpri - Primary database
Error: ORA-16724: cannot resolve gap for one or more members

  dbstb - Physical standby database
  Warning: ORA-16809: multiple warnings detected for the member

Fast-Start Failover: Disabled

Configuration Status:
ERROR (status updated 5 seconds ago)

We can see that both Primary and Physical standby are out of sync

2. Stop Recovery Managed process on the standby

DGMGRL> edit database DBSTB set state=APPLY-OFF;

Or

RMAN> alter database recover managed standby database cancel;

3. Run roll forward command

$rman target /

Recovery Manager: Release 19.0.0.0.0 - Production on Thu Mar 11 12:12:48 202
Version 19.5.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.

connected to target database: DBSTB (DBID=xxxxxxxx)
RMAN> recover standby database from service DBPRI
Starting recover at 11-MAR-22
using target database control file instead of recovery catalog
Oracle instance started…….

media recovery complete, elapsed time: 00:00:00
Finished recover at 05-MAR-22
Executing: alter system set standby_file_management=auto
Finished recover at 05-MAR-22

4. Enable the Recovery Managed process on the standby

DGMGRL> edit database DBSTB set state=APPLY-ON;

Or

RMAN> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;


5. Verify the Data Guard configuration status

DGMGRL> show configuration

Configuration - dg_config
Protection Mode: MaxPerformance

Members:
dbpri - Primary database
  dbstb - Physical standby database

Fast-Start Failover: Disabled

Configuration Status:
SUCCESS (status updated 56 seconds ago)

Now standby Database has been recovered and in sync with the primary.

Thanks & Regards

Thursday, September 8, 2022

RMAN-04009: warning from auxiliary database: ORA-28002: the password will expire within 6 days

I have come across an issue when trying to duplicate a database by connection to Recovery catalog database. You will come across this warning when the user profile has reached PASSWORD_LIFE_TIME value limit and you have entered into PASSWORD_GRACE_TIME value

RMAN-04009: warning from auxiliary database: ORA-28002: the password will expire within 6 days

First check the profile that user has been assigned.

SQL> select username , profile from dba_users where username=’RMAN’;
username profile
------------- ---------------
RMAN DEFAULT

Check the current status of the user
SQL> select USERNAME, ACCOUNT_STATUS from dba_users where USERNAME = ‘RMAN’;
USERNAME ACCOUNT_STATUS
------------- ----------------- --------------------------------
RMAN EXPIRED(GRACE)

Check the RESOUCE_NAME, LIMIT for the Default profile.
SQL> select RESOURCE_NAME,LIMIT from dba_profiles where PROFILE='DEFAULT';

RESOURCE_NAME LIMIT
---------------------------  -------------------------------------------------
COMPOSITE_LIMIT UNLIMITED
SESSIONS_PER_USER UNLIMITED
CPU_PER_SESSION UNLIMITED
CPU_PER_CALL UNLIMITED
LOGICAL_READS_PER_SESSION UNLIMITED
LOGICAL_READS_PER_CALL UNLIMITED
IDLE_TIME UNLIMITED
CONNECT_TIME UNLIMITED
PRIVATE_SGA UNLIMITED
FAILED_LOGIN_ATTEMPTS 10
PASSWORD_LIFE_TIME 180
RESOURCE_NAME LIMIT
PASSWORD_REUSE_TIME UNLIMITED
PASSWORD_REUSE_MAX UNLIMITED
PASSWORD_VERIFY_FUNCTION NULL
PASSWORD_LOCK_TIME 1
PASSWORD_GRACE_TIME 7
INACTIVE_ACCOUNT_TIME UNLIMITED

As we see password PASSWORD_LIFE_TIME set to 180 days

First you need to change the password for the issue to resolve.
SQL> Alter user rman identified by rman_new_password;

As current password life time set 180 days, You can change the password life time to avoid this issue in future. Either you can set to specific number of days or UNLIMITED.

SQL> ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;
Profile altered.

You can check the modified resource limit for PASSWORD_LIFE_TIME
SQL> select RESOURCE_NAME,LIMIT from dba_profiles where PROFILE='DEFAULT' and RESOURCE_NAME='PASSWORD_LIFE_TIME';

RESOURCE_NAME   LIMIT
---------------------------  -------------------------------------------------
PASSWORD_LIFE_TIME UNLIMITED

Hope this helps

Thanks & Regards
http://oracleracexpert.com, Oracle ACE Pro

Tuesday, September 6, 2022

Automatic Indexing in Oracle 19c & 21c

The DBA’s are responsible for Index management, which includes monitor index, add, change and remove based upon workload and ad-hoc manner. It will be difficult to decide type of index, when to create, change or drop and measure the impact, so there will be both positive and negative effects.

In Oracle 19c, the automatic indexing feature introduced and it automatically creates, rebuilds, and drops indexes to improve the performance based upon application workload and changes. This helps to optimize the database and improve performance without any user intervention.

The DBMS_AUTO_INDEX package is used for managing the automatic indexing and user can find out the current automatic index configuration by querying CDB_AUTO_INDEX_CONFIG view.

  • CONFIGURE Procedure - Configures automatic indexing.
  • DROP_AUTO_INDEXES Procedure - Drop the automatically created indexes manually by overriding the retention parameter.
  • DROP_SECONDARY_INDEXES Procedure -Deletes all the indexes, except the ones used for constraints
  • REPORT_ACTIVITY Function - Generate Report of the automatic indexing operations
  • REPORT_LAST_ACTIVITY Function - Generate Report of the last automatic indexing operation
AUTO_INDEX_MODE : The automatic indexing is controlled using the AUTO_INDEX_MODE property, It defines different modes of operation.

  • REPORT ONLY: Turn on automatic indexing and new indexes are invisible and not available for SQL operations
  • IMPLEMENT: Turn on automatic indexing and new indexes are visible available for SQL operations
  • OFF: Turn OFF automatic indexing but does not disable existing auto indexes.
SQL> exec dbms_auto_index.configure('AUTO_INDEX_MODE','REPORT ONLY');
SQL> exec dbms_auto_index.configure('AUTO_INDEX_MODE','IMPLEMENT');
SQL> exec dbms_auto_index.configure('AUTO_INDEX_MODE','OFF');


AUTO_INDEX_SCHEMA Procedure - When automatic indexing enabled all schemas will be used for auto indexes and you can exclude or include any schemas by using AUTO_INDEX_SCHEMA parameter

The below examples adds the SALES schema to AUTO INDEXES exclusion list

begin
dbms_auto_index.configure(
parameter_name => 'AUTO_INDEX_SCHEMA',
parameter_value => 'SALES',
allow => FALSE);
end;


The below examples removes the SALES schema from AUTO INDEXES exclusion list

begin
dbms_auto_index.configure(
parameter_name => 'AUTO_INDEX_SCHEMA',
parameter_value => 'SALES',
allow => NULL);
end;


The below example removes all the schemas from AUTO INDEXES exclusion list.

begin
dbms_auto_index.configure(
parameter_name => 'AUTO_INDEX_SCHEMA',
parameter_value => NULL,
allow => TRUE);
end;


You can also define retention period that you want auto indexes. The below example sets the retention period of auto indexes to 30 days.

begin
dbms_auto_index.configure(
parameter_name => 'AUTO_INDEX_RETENTION_FOR_AUTO',
parameter_value => '30');
end;


By default automatic indexes created in default permanent tablespace and you can change this by using AUTO_INDEX_DEFAULT_TABLESPACE

SQL> exec dbms_auto_index.configure('AUTO_INDEX_DEFAULT_TABLESPACE','AUTO_INDEX_TBS');

You can also allocate percentage of the tablespace can be used for auto indexes. In below example you can use 10%

SQL> exec dbms_auto_index.configure(‘AUTO_INDEX_SPACE_BUDGET’, ‘10’);



DROP_AUTO_INDEXES Procedure: Using this procedure you can Drop the automatically created indexes manually by overriding the retention parameter.

The below example will drop a single index in SALES schema and it allow recreate. If you do not want to recreate set the value to FALSE

begin
dbms_auto_index.drop_auto_indexes(
owner => ‘SALES’,
index_name => '”SYS_AI_45rfg54nxvjcty”',
allow_recreate => TRUE);
end;
/

The below example will drop all auto indexes owned by SALES and will not allow recreate as allow_recreate set to FALSE

begin
dbms_auto_index.drop_auto_indexes(
owner => 'SALES',
index_name => NULL
allow_recreate => FALSE);
end;
/

DROP_SECONDARY_INDEXES Procedure – This procedure deletes all the indexes, except the ones used for constraints

The below example deletes all auto indexes except the ones used for constraints

begin
dbms_auto_index.drop_secondary_indexes;
end;

The below example deletes all auto indexes from the REGION table in the SALES schema except the ones used for constraints

begin
dbms_auto_index.drop_secondary_indexes('SALES', 'REGION');
end;


The below example deletes all auto indexes in the SALES schema except the ones used for constraints

begin
dbms_auto_index.drop_secondary_indexes('SALES');
end;

REPORT_ACTIVITY Function – By using this function you can generate Report of the automatic indexing operations

The below example generates automatic indexing operations report executed in the last 24 hours.

declare
act_report clob := null;
begin
act_report := dbms_auto_index.report_activity();
end;

or

SQL> select dbms_auto_index.report_activity() from dual;


The below example generates HTML automatic indexing operations report executed in the last 6 hours activity.

SQL> select dbms_auto_index.report_activity(activity_start => systimestamp-0.25, activity_end => systimestamp-1, type => 'HTML') from dual;

REPORT_LAST_ACTIVITY Function -The below example generates report of the last automatic indexing executed in a database.

declare
act_report clob := null;
begin
act_report := dbms_auto_index.report_last_activity();
end;

or

SQL>  select dbms_auto_index.report_last_activity() from dual;


The Oracle 21c comes with an enhancement in Automatic indexing, which helps to reduce the over head of the cursor invalidations during automatic index creation and also added new enhancements to improve query performance.

Thanks & Regards
http://oracleracexpert.com, Oracle ACE

Wednesday, May 25, 2022

Multitenant: DBCA PDB Remote Clone or Relocate in Oracle 19c

In Oracle 19c, you can clone or relocate a pluggable database (PDB) from one CDB (multitenant container database) to another using the DBCA (Database Configuration Assistant).

The following pre-requisites must met

• The local and remote PDBs must be in the archive log mode and local undo mode.
• It must have the CREATE PLUGGABLE DATABASE privilege in the local CDB root container.
• The database user in the remote PDB that the database link connects must have the CREATE       PLUGGABLE DATABASE, SYSOPER and SESSION privileges.
• The same database options installed on local and remote PDB’s

You can use below query to verify database has local undo mode and archive log mode enabled

SQL> select property_name, property_value from database_properties
where property_name = 'local_undo_enabled';
SQL> select log_mode from v$database;

First, create a user that is used in the database link automatically to connect during the cloning operation. When using DBCA we need to supply the credentials only and no need to create database link

SQL> CREATE USER c##remote_user1 IDENTIFIED BY password CONTAINER=ALL;
SQL> GRANT create session, create pluggable database TO c##remote_user1 CONTAINER=ALL;


You can launch DBCA in silent mode to clone PDB1 from CDB1 as PDB11 in CDB11

$dbca -silent -createPluggableDatabase -createFromRemotePDB -remotePDBName PDB1 -remoteDBConnString CDB1 -remoteDBSYSDBAUserName SYS -remoteDBSYSDBAUserPassword xxxxxxxx -sysDBAUserName sys -sysDBAPassword xxxxxxxx -dbLinkUsername c##remote_user1 -dbLinkUserPassword xxxxxxxx -sourceDB CDB11 -pdbName PDB11

Prepare for db operation
50% complete
Create pluggable database using remote clone operation
100% complete
Pluggable database "PDB11" plugged successfully.
Look at the log file "/oracle/cfgtoollogs/dbca/CDB11/PDB11/CDB11.log" for further details.

You can connect to CDB11 and check the status.

$sqlplus sys@CDB11 as sysdba

SQL> SHOW PDBS
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB11 READ WRITE NO

If you have cloned PDB11 as part of some testing and need to cleanup then use below commands by connecting to CDB11 as SYS

SQL> alter pluggable database PDB11 close;
SQL> drop pluggable database PDB11 including datafiles;



You can also use DBCA to delete the pluggable database that was cloned.

$dbca -silent -deletePluggableDatabase -sourceDB CDB11 -pdbName PDB11

Prepare for db operation
25% complete
Deleting Pluggable Database
40% complete
82% complete
94% complete
100% complete
Pluggable database "PDB11" deleted successfully.
Look at the log file "/oracle/cfgtoollogs/dbca/CDB11/PDB11/CDB11.log" for further details.

You can also use DBCA delete the instance using below command in silent mode

$dbca -silent -deleteDatabase -sourceDB CDB11 -sysDBAUserName sys -sysDBAPassword xxxxxxxxx

The relocatePDB command relocates a PDB from a remote CDB to a local CDB.

$dbca -relocatePDB
-pdbName name_of_the_local_pdb_to_create
-sourceDB database_name_of_the_local_pdb
-remotePDBName name_of_the_remote_pdb_to_relocate
-remoteDBConnString db_connection_string_of_the_remote_pdb
-sysDBAUserName name_of_the_sysdba_user
-sysDBAPassword password_of_the_sysdba_user
-dbLinkUsername name_of_the_dblink_user_of_the_remote_pdb
-dbLinkUserPassword password_of_the_dblink_user_of_the_remote_pdb

Example:
$ dbca -silent -relocatePDB -pdbName PDB11 -sourceDB CDB11  -remotePDBName PDB1 -remoteDBConnString TESTDB -remoteDBSYSDBAUserName sys  -remoteDBSYSDBAUserPassword xxxxxxx  -dbLinkUsername c##remote_user1 -dbLinkUserPassword xxxxxxx

Prepare for db operation
50% complete
Create pluggable database using relocate PDB operation
100% complete
Pluggable database "PDB11" plugged successfully.
Look at the log file "/oracle/cfgtoollogs/dbca/CDB11/PDB11/CDB11.log" for further details.


Refer Oracle documentation for more details and syntax

When running the DBCA in silent mode the outcome will be reported as exit codes. These exit codes helps to identify the command is successful or failed.

Exit Code Description
0  : Command execution successful
6  : Command execution successful but with warnings
-1 : Command execution failed
-2 : Invalid input from user
-4 :  Command canceled by user

Thanks & Regards,
http://oracleracexpert.com, Oracle ACE