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

Oracle Database 26ai SQL Firewall: An Additional Layer of Defense Against SQL Injection

SQL injection remains one of the most common threats facing enterprise applications. Even well-designed applications can become vulnerable due to coding errors, compromised credentials, or unexpected application behavior.

Oracle Database SQL Firewall provides an additional layer of protection by validating SQL statements before they are executed by the database.

What is SQL Firewall?

SQL Firewall allows administrators to establish a trusted set of SQL statements generated by an application. Once enforcement is enabled, SQL statements that do not match the approved allow list can be identified and handled according to the configured policy.

This approach helps organizations strengthen application security directly at the database layer.

Benefits of SQL Firewall

SQL Firewall provides several advantages for enterprise applications:

• Helps protect against SQL injection attacks
• Identifies unauthorized SQL statements
• Reduces the impact of compromised application credentials
• Improves visibility into application SQL activity
• Provides centralized administration

Because SQL validation occurs within the database, SQL Firewall complements existing security controls implemented at the application layer.

Typical SQL Firewall Workflow

A typical implementation follows these steps:

Step 1 – Enable SQL Firewall

Enable SQL Firewall using the DBMS_SQL_FIREWALL package.

SQL> EXEC DBMS_SQL_FIREWALL.ENABLE;

Step 2 – Capture Application SQL

Run the application in learning mode to capture normal SQL statements generated during typical business operations.

BEGIN 

 DBMS_SQL_FIREWALL.CREATE_CAPTURE( 

 username => 'HR', 

 top_level_only => TRUE, 

 start_capture => TRUE 

 ); 

END;

 /

If the capture already exists, you can use 
SQL> EXEC DBMS_SQL_FIREWALL.START_CAPTURE('HR');

Step 3 – Generate an Allow List

Create an allow list based on the captured SQL. This list represents the SQL statements that are expected for the application.

SQL> EXEC DBMS_SQL_FIREWALL.STOP_CAPTURE('HR');

Generate the allow list using 

SQL> EXEC DBMS_SQL_FIREWALL.GENERATE_ALLOW_LIST('HR');

Step 4 – Enable Enforcement

Once the allow list has been validated, enable enforcement so that SQL Firewall evaluates incoming SQL against the approved list.

BEGIN 

 DBMS_SQL_FIREWALL.ENABLE_ALLOW_LIST(

 username => 'HR', 

 enforce => DBMS_SQL_FIREWALL.ENFORCE_SQL, 

 block => TRUE 

 ); 

END; 

/

This configuration enforces the SQL allow list and blocks SQL statements that are not part of the approved list.

Step 5 – Monitor Violations

Regularly review SQL Firewall violations to identify unexpected SQL activity and update allow lists when legitimate application changes occur.

Review captured SQL using 

SQL> SELECT * FROM DBA_SQL_FIREWALL_CAPTURE_LOGS;

Review SQL violations using 

SQL> SELECT * FROM DBA_SQL_FIREWALL_VIOLATIONS;

Review allowed SQL using 

SQL> SELECT * FROM DBA_SQL_FIREWALL_ALLOWED_SQL;

Check SQL Firewall status.

SQL> SELECT * FROM DBA_SQL_FIREWALL_STATUS;

SQL Firewall Enforcement Modes

SQL Firewall can be configured to:

• Log Mode – Record violations without blocking SQL statements.
• Block Mode – Prevent SQL statements that are not part of the approved allow list from executing.

Many organizations begin in Log Mode to validate application behavior before enabling Block Mode in production.

Monitoring SQL Firewall

Oracle Database provides several data dictionary views for monitoring SQL Firewall activity, including:

• DBA_SQL_FIREWALL_STATUS
• DBA_SQL_FIREWALL_ALLOWED_SQL
• DBA_SQL_FIREWALL_CAPTURE_LOGS
• DBA_SQL_FIREWALL_VIOLATIONS

These views help administrators monitor configuration status, captured SQL statements, approved SQL, and detected violations.

Implementation Best Practices

When implementing SQL Firewall, consider the following recommendations:

• Capture SQL during peak business activity to build a complete allow list.
• Rebuild or append the allow list after application upgrades.
• Review SQL Firewall violations regularly.
• Test enforcement in a non-production environment before enabling it in production.
• Combine SQL Firewall with Unified Auditing and Database Vault for layered security.

Limitations and Considerations

• SQL Firewall is most effective for applications with predictable SQL workloads.
• Application upgrades or new functionality may require capturing additional SQL statements and updating the allow list.
• SQL Firewall complements secure coding practices, input validation, and application security testing—it is not a replacement for them.
• Proper testing is recommended before enabling enforcement in production to minimize the risk of blocking legitimate application SQL.

Why SQL Firewall Matters

Application security is strongest when multiple layers of protection work together.

While secure application development remains essential, SQL Firewall adds another layer of defense by validating SQL statements inside the database before execution. This additional validation helps reduce the risk associated with unexpected or unauthorized SQL activity.

SQL Firewall provides Oracle DBAs with an additional layer of protection against SQL injection and unauthorized SQL execution. By learning trusted application behavior and enforcing an approved SQL allow list, organizations can significantly strengthen database security. When combined with Transparent Data Encryption (TDE), Unified Auditing, Database Vault, and least privilege administration, SQL Firewall becomes an important component of a comprehensive defense-in-depth strategy for Oracle Database 26ai.

Securing AI-Enabled Applications with Oracle Database 26ai

Artificial Intelligence (AI) is transforming enterprise applications by enabling intelligent search, automation, and data-driven decision making. As organizations integrate AI into their business processes, protecting the underlying data becomes more important than ever.

Oracle Database 26ai builds on Oracle's comprehensive security architecture, enabling organizations to secure both traditional database workloads and AI-enabled applications using proven Oracle Database security features. Rather than requiring a separate security framework, organizations can leverage existing capabilities such as Transparent Data Encryption (TDE), SQL Firewall, Unified Auditing, Database Vault, and least privilege administration to protect sensitive information.

Why AI Security Matters

AI applications often process valuable business information, including customer records, financial data, product documentation, and operational data. Without appropriate security controls, organizations may face risks such as:

• Unauthorized access to sensitive data
• SQL injection attacks
• Stolen or compromised credentials
• Insider threats
• Data leakage
• Regulatory compliance challenges

Protecting AI-enabled applications requires multiple layers of security rather than relying on a single security mechanism.

Oracle Database 26ai Security Approach

Oracle Database 26ai provides a layered security model that helps protect enterprise data throughout its lifecycle.

Transparent Data Encryption (TDE)

Transparent Data Encryption (TDE) protects sensitive information stored in Oracle Database by encrypting data at rest without requiring application changes.

Key benefits include:

• Encryption of database data stored in encrypted tablespaces
• Protection of backup data
• Strong encryption algorithms such as AES-256
• Integration with Oracle Key Vault for centralized key management

By enabling TDE, organizations can significantly reduce the risk of unauthorized access to stored data.

SQL Firewall

Applications often generate predictable SQL statements. Oracle SQL Firewall helps improve database security by allowing only approved SQL statements to execute.

Typical benefits include:

• Helping protect applications from SQL injection attacks
• Blocking unauthorized SQL statements
• Reducing risks associated with compromised credentials
• Providing centralized SQL validation

SQL Firewall complements existing application security controls by validating SQL at the database layer.

Unified Auditing

Monitoring database activity is an important part of every security strategy.

Unified Auditing simplifies audit management by storing audit records in a single repository and supports auditing of both successful and unsuccessful activities.

Common auditing scenarios include:

• User logins
• Administrative operations
• Privilege usage
• Object access
• Security policy changes

A well-designed auditing strategy improves compliance reporting while providing valuable information during security investigations.

Database Vault

Database Vault helps organizations implement separation of duties and protect sensitive application data from unauthorized access, including privileged users.

Key capabilities include:

• Realms
• Command Rules
• Rule Sets
• Secure Application Roles

These controls provide additional protection beyond traditional privilege management.

Least Privilege Administration

One of the most effective security practices is granting users only the privileges required to perform their job functions.

Organizations should:

• Review user privileges regularly
• Avoid unnecessary system privileges
• Remove unused accounts
• Follow role-based access control whenever possible

Applying least privilege reduces the overall attack surface and minimizes the impact of compromised accounts.

Security Best Practices

When deploying AI-enabled applications on Oracle Database 26ai, consider the following recommendations:

• Enable Transparent Data Encryption
• Configure SQL Firewall for critical applications
• Enable Unified Auditing
• Protect sensitive data using Database Vault
• Follow least privilege principles
• Regularly review audit reports and security configurations

AI adoption continues to accelerate across enterprises, making database security more important than ever. Oracle Database 26ai enables organizations to secure AI-enabled applications by leveraging Oracle's mature security capabilities, including encryption, auditing, SQL Firewall, Database Vault, and least privilege administration.

A layered security approach not only helps protect sensitive information but also improves compliance, reduces operational risk, and strengthens overall database security.

Resolving Tableau Messaging Service (ActiveMQ) Startup Failure After Upgrading to Tableau Server 2025.3.6

After successfully upgrading our Tableau Server environment to version 2025.3.6, we encountered an issue where the Messaging Service (ActiveMQ) failed to start on two nodes in our multi-node deployment. This caused the affected nodes to remain in a degraded state, preventing the cluster from becoming fully operational

This article describes the symptoms we observed, the troubleshooting steps we performed, and the solution that successfully restored the Messaging Service.
Problem

 The log output below has been sanitized to remove environment-specific information, and repetitive log entries have been omitted for brevity.

C:\Tableau Server\data\tabsvc\services\activemqserver_<version>\status.cmd

Java class name: com.tableausoftware.activemq.ActiveMQApp
Method name: main
Arguments: status
"currentDeploymentState": "NONE",
"details": {
"message": "Connect to localhost:8099 [localhost/127.0.0.1,
localhost/0:0:0:0:0:0:0:1] failed:
Connection refused: connect"
},
"name": "activemqserver_0",
"processStatus": "DOWN",
"version": "<2025.3.x>"
Exit code: 4

Resolution

1. Go to:
C:\Tableau Server\data\tabsvc\services\activemqserver_<version>

2. Run:
disable.cmd

Expected (sanitized):
Connecting to JMX URL:
service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi
INFO: Broker now available at:
service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi
Exit code: 0

3. Rename:
C:\Tableau Server\data\tabsvc\services\activemqserver_0\kahadb

To:
kahadb.old

4. Run:
enable.cmd

Expected (sanitized):
Java class name: com.tableausoftware.activemq.ActiveMQApp
Method name: main
Arguments: enable
Exit code: 0

5. Restart Tableau Server:
tsm restart

All Tableau Servers came online without any warnings or issues

The embedded ActiveMQ broker stores its persistent message data in the KahaDB directory. If the message store becomes corrupted or incompatible during an upgrade, ActiveMQ may fail to start. Renaming the KahaDB folder causes Tableau to create a fresh message store during startup.

Best Practices
- Take a Tableau backup before making changes.
- Verify all nodes become Active after restart.
- Review ActiveMQ logs if the problem persists.
- Contact Tableau Support if the issue continues.

In this case, disabling the Messaging Service, renaming the KahaDB folder, re-enabling the service, and restarting Tableau Server successfully restored the Messaging Service and returned all nodes to a healthy state.

Thanks

https://oracleracexpert.com

Webinar: Oracle Database 26ai Security New Features

Join us for an exclusive technical session exploring the latest security enhancements in Oracle Database 26ai. Learn how Oracle helps secure modern enterprise and AI-enabled workloads using built-in security capabilities such as SQL Firewall, Transparent Data Encryption (TDE), Unified Auditing, Database Vault, Oracle Data Safe, and modern authentication mechanisms. This session includes practical demonstrations, best practices, and real-world implementation guidance for DBAs and architects.

Date & Time
July 31st 2026 | 8:00 AM – 9:00 AM Pacific Time (GMT-07:00 | San Francisco)

This session is ideal for:

• Oracle DBAs
• Database & Solution Architects
• Security Professionals
• Oracle Developers
• Cloud Engineers

Topics covered in this webinar include:

• Oracle Database 26ai Security Overview
• AI Security and Protecting AI Workloads
• SQL Firewall Architecture and Administration
• Transparent Data Encryption (TDE)
• Unified Auditing and Fine-Grained Auditing
• Authentication using Microsoft Entra ID, IAM and Kerberos
• Database Vault and Least Privilege Administration
• Oracle Data Safe Security Assessment and Data Masking
• Oracle Database 26ai Security Best Practices
• Live Demonstration of Key Security Features

Key Takeaways

• Understand the latest Oracle Database 26ai security enhancements.
• Learn how to secure AI-enabled and enterprise database workloads.
• Implement Oracle security best practices to reduce cyber risks.
• Improve compliance using auditing, encryption, and least privilege.
• Gain practical knowledge through real-world examples and demonstrations.

How to Register

Please send an email to: SatishbabuGunukula@gmail.com to register and receive webinar passcode details.

Click here to join the Meeting
Click here to download the Presentation