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

How to Fix Oracle 26ai Installer Error INS-13001 on RHEL 9

While deploying the new Oracle AI Database 26ai on Red Hat Enterprise Linux 9.x (RHEL 9.x), I have come across a confusing scenario where the installation goes perfectly smoothly on SERVER1 but throws a frustrating error on a seemingly identical SERVER2.

WARNING: [May 18, 2026 1:26:22 PM] Verification of target environment returned with errors. WARNING: [May 18, 2026 1:26:22 PM] [WARNING] [INS-13001] Oracle Database is not supported on this operating system. Installer will not perform prerequisite checks on the system.
CAUSE: This operating system may not have been in the certified list at the time of the release of this software.
ACTION: Refer to My Oracle Support portal for the latest certification information for this operating system. Proceed with the installation if the operating system has been certified after the release of this software..

Checking /etc/redhat-release and /etc/os-release on both machines confirms they are both pristine, matching copies of RHEL 9.6. So why is one failing while the other succeeds?

[oracle@SERVER1]$cat /etc/redhat-release
Red Hat Enterprise Linux release 9.6 (Plow)

[oracle@SERVER1]$cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="9.6 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.6"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.6 (Plow)"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9"
...etc

[oracle@SERVER2]$cat /etc/redhat-release
Red Hat Enterprise Linux release 9.6 (Plow)

[oracle@SERVER2]$cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="9.6 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.6"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.6 (Plow)"
ANSI_COLOR="0;31"

LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9"
...etc

We also did the research and found out that REHL9.6 is fully certified.

The answer usually isn't your OS version at all, it's OS security hardening policy. Here is why this happens and how to fix it in under two minutes.

The Secret Culprit: noexec on /tmp

During the initialization phase, the Oracle Universal Installer (OUI) extracts temporary architecture and OS-validation binaries into the system's /tmp directory and attempts to execute them.

On many production-hardened Linux servers, corporate security policies dictate that the /tmp partition must be mounted with the noexec flag. When the installer's background detection scripts get blocked from running, the OUI hits a generic failure and defaults to its catch-all warning: “OS not supported.”

How to Verify the Issue

Run the following command on both servers to check the mount permissions of your temporary directory:

$ mount | grep /tmp

If the failing server outputs noexec inside the configuration brackets, you have officially found the culprit.

The Solution: Redirect Oracle's Temp Directory or mount the /tmp with "exec"

You don’t need to ask your security team to compromise server hardening rules by remounting /tmp. Instead, you can simply instruct the Oracle installer to use a directory where the oracle user naturally has execution permission, such as their own home directory.

Log into your failing server as the oracle installation user, and run these commands in the terminal before launching the installer:

# 1. Create a dedicated temp directory in the oracle home folder

$ mkdir -p /home/oracle/oratmp


# 2. Redirect the installer's environment variables

$export TMP=/home/oracle/oratmp
$export TMPDIR=/home/oracle/oratmp

# 3. Launch the installer from this same terminal session

$./runInstaller

By changing these variables, the installer bypasses /tmp entirely, successfully reads your RHEL 9 configuration from /home/oracle/oratmp, and allows the setup to proceed seamlessly.

Thanks & Regards

https://oracleracexpet.com

Beyond the Basics: Master Repeatable DDL in Oracle Database 23ai

The introduction of the IF [NOT] EXISTS clause in Oracle Database 23ai is more than a syntax update it’s a fundamental shift in how we approach Schema as Code.

In my recent exploration of this feature, I found that while the "Table" examples are the most common, the real power lies in how it simplifies the management of all schema objects. Let's dive deeper into some advanced examples and how they solve daily deployment hurdles.

1. Handling Supporting Objects: Indexes and Sequences

In any production environment, a table rarely exists in a vacuum. You usually have sequences for primary keys and indexes for performance. Before 23ai, if a migration script failed halfway through, you’d have to manually check which indexes were created and which weren't.

Now, you can ensure your entire environment is ready in a single, repeatable block:

-- Safely create a sequence for Employee IDs

SQL> CREATE SEQUENCE IF NOT EXISTS emp_seq START WITH 100 INCREMENT BY 1;

-- Safely create a performance index

SQL>CREATE INDEX IF NOT EXISTS idx_emp_name ON EMPLOYEE(EMP_NAME);

Why this matters: If your deployment tool (like Jenkins or GitLab CI/CD) retries a failed job, these statements won't cause the "Object already exists" error that usually stops a pipeline in its tracks.

2. Simplifying Application Logic: Synonyms

If you manage multi-tenant environments or applications that use synonyms to point to different schema versions, you know the struggle of "cleaning up" old pointers.

-- Ensure the public pointer exists without checking metadata

SQL> CREATE SYNONYM IF NOT EXISTS emp_public FOR HR_DATA.EMPLOYEE;

-- Or, if you are decommissioning a module:

SQL> DROP SYNONYM IF EXISTS old_emp_ref;

3. The "Gotcha" Deep Dive: Understanding Object vs. Attribute

As I mentioned in my recent Oracle Sprint, there is a subtle distinction to keep in mind: Object-level existence vs. Attribute-level existence.

Consider the ALTER TABLE command.

 

• The Success: ALTER TABLE IF EXISTS employee ADD (department_id NUMBER); — This works perfectly because Oracle checks if the table "employee" exists.
  
  
• The Failure: If you run that same command again, it will fail.

The Reason: Even though the table exists, the column "department_id" also now exists. The IF EXISTS clause doesn't currently look inside the table to see if the column is already there. For column-level idempotency, you still need to be strategic with your migration scripts.

4. Avoiding the Conflict: "REPLACE" vs. "IF NOT EXISTS"

This is a frequent point of confusion. You might be tempted to write: CREATE OR REPLACE VIEW IF NOT EXISTS emp_v AS SELECT...

Oracle will throw ORA-11541. * Use OR REPLACE when you want the object to be updated with new logic (common for Views, Procedures, and Functions).
Use IF NOT EXISTS when you want to ensure you don't overwrite something that is already there (common for Tables, Sequences, and Indexes).

Strategic Summary

The "Idempotent DDL" approach in 23ai removes the "fear of the second run." By incorporating these clauses into your standard SQL scripts, you:

1. Reduce Boilerplate: No more 10-line PL/SQL blocks for a 1-line DDL.
2. Increase Pipeline Uptime: Fewer "false positive" failures in CI/CD.
3. Improve Readability: Your intent is clear to any developer reading the code.

Final Thought for the Community

As we move toward more automated, AI-driven database management, these small syntax changes are what make large-scale automation possible. Are you planning to refactor your legacy migration scripts to use these new clauses, or are you saving them for new projects only?

Let's discuss in the comments!

Thanks & Regards

https://oracleracexpert.com

Using Assertions to Prevent Scheduling Conflicts in Oracle 23ai and beyond

Hospitals manage hundreds of surgeries every day across multiple operating rooms. To ensure patient safety, efficient use of resources, and smooth hospital operations, having a reliable scheduling system is critical.

However, conflicts often occur when multiple staff members or systems try to book the same operating room at overlapping times. Left unchecked, these conflicts can cause delays, coordination issues, and even risks to patients.

A reliable solution is to use assertions in the database. With Oracle Database 23c, hospitals can enforce complex scheduling rules directly at the database level, ensuring no two surgeries are scheduled in the same operating room at the same time. This eliminates human error and protects hospital operations.
The Problem: Double Booking Operating Rooms

Surgery scheduling in hospitals typically follows this workflow:

 

1. A surgeon requests a procedure.
2. An operating room is assigned.
3. Start and end times for the surgery are set.

Even with this workflow, overlapping bookings can happen if the database does not strictly enforce scheduling rules.

Example of a scheduling conflict:

Room	Surgery	Start Time	End Time

OR-305

Knee Replacement

7:00

9:00

OR-305

Hip Replacement

8:15

10:15

Here, the surgeries overlap by 45 minutes, which can lead to:

• Delays in procedures
• Staff coordination problems
• Risk to patient safety
• Inefficient use of operating rooms

Relying solely on application logic or manual checks is risky—especially when multiple systems interact with the same database. 

Enforcing Scheduling Rules with Assertions

Assertions are database-level rules that guarantee certain conditions are always true. For hospital scheduling, the main rule is:

An operating room cannot host more than one surgery at the same time.

This ensures that time intervals for surgeries in the same room never overlap.
Example Data Model

Operating Rooms Table:

SQL> CREATE TABLE operating_rooms(
or_id NUMBER PRIMARY KEY,
or_name VARCHAR2(50),
department VARCHAR2(50)
);

Surgeons Table:

 
SQL> CREATE TABLE surgeons(
surgeon_id NUMBER PRIMARY KEY,
surgeon_name VARCHAR2(100),
surgeon_specialty VARCHAR2(50)
);


Surgery Schedule Table:

SQL> CREATE TABLE surgery_schedule(
surgery_id NUMBER PRIMARY KEY,
surgeon_id NUMBER,
or_id NUMBER,
start_time TIMESTAMP,
end_time TIMESTAMP,
CONSTRAINT fk_surgeon FOREIGN KEY (surgeon_id) REFERENCES surgeons(surgeon_id),
CONSTRAINT fk_room FOREIGN KEY (or_id) REFERENCES operating_rooms(or_id)
);

Without assertions, the database could allow conflicting schedules:

Room	Surgery	Start Time	End Time
OR-305	Knee Replacement	7:00	9:00
OR-305	Hip Replacement	8:15	10:15

How Assertions Detect Conflicts

An assertion prevents overlapping surgeries by checking time intervals:

 
CREATE ASSERTION no_room_schedule_conflict
CHECK (
NOT EXISTS (
SELECT s1.or_id
FROM surgery_schedule s1
JOIN surgery_schedule s2
ON s1.or_id = s2.or_id
AND s1.surgery_id <> s2.surgery_id
WHERE s1.start_time < s2.end_time
AND s2.start_time < s1.end_time
)
);

Logic:

Two surgeries conflict if:

• Surgery A start < Surgery B end
• AND Surgery B start < Surgery A end

If a conflict exists, the assertion fails and the database blocks the transaction, preventing overlapping surgeries.

Example:

Valid Schedule:

Room	Surgery	Start Time	End Time
OR-402	Appendectomy	6:30	7:30
OR-402	Gallbladder Removal	7:30	9:00

Conflict Attempt:

Room	Surgery	Start Time	End Time
OR-402	Appendectomy	6:30	7:30
OR-402	Hernia Repair	7:00	8:00

Result: ERROR – assertion NO_ROOM_SCHEDULE_CONFLICT violated.

The conflicting schedule is automatically blocked. 

Why Hospitals Should Use Assertions

Assertions provide several advantages in hospital scheduling systems:

1. Prevent Critical Operational Errors – Conflicts are blocked immediately.
2. Protect Patient Safety – Eliminates risks caused by overlapping surgeries or delays.
3. Ensure Centralized Data Integrity – Works across multiple systems like hospital administration portals, scheduling apps, and emergency systems.
4. Simplify System Design – Reduces reliance on triggers, manual checks, or complex application validations.

Other Healthcare Applications

Assertions can also help manage:

• Surgeon availability – Prevents double booking of surgeons.
• ICU bed allocation – Ensures ICU reservations never exceed capacity.
• Medical equipment scheduling – Avoids conflicts for MRI, X-ray, or CT scanners.
• Staff shift compliance – Keeps nursing shifts within legally allowed hours.

Conclusion

Oracle Database 23c’s assertions provide a powerful mechanism for enforcing complex business rules directly in the database. In hospitals, where scheduling mistakes can have serious consequences, assertions ensure no operating room conflicts occur, safeguarding both patients and operations.

Webinar: Mastering the Convergence of AI & Security in Oracle 26ai

Join us for an exclusive technical session exploring the leap from 23ai to the new Oracle Database 26ai. As the 2026 Long-Term Support (LTS) release, 26ai introduces "Agentic AI" while doubling down on post-quantum security. We will demonstrate how to build AI-driven applications that are secure by design, ensuring your private data never leaves the database.

Date & Time:
March 12th 2026 | 7:30 AM – 8:30 AM Pacific Time (GMT-07:00 | San Francisco)

This session is ideal for:

· Database Administrators (DBAs) looking to manage Vector workloads.
· IT Security Professionals concerned about AI data leakage.
· Oracle Architects & Developers building "GenDev" applications.

Topics covered in this webinar include:

· The 23ai to 26ai Evolution: What’s new in the 2026 Long-Term Support release.
· AI Vector Search & RAG: Implementing semantic search without external Vector DBs.
· The Private Agent Factory: Building autonomous AI agents securely.
· Post-Quantum Cryptography: Defending against future threats with ML-KEM.
· Native SQL Firewall & MFA: Hardening the kernel against modern injection attacks.
· Select AI: Harnessing Natural Language to SQL interfaces.

How to Register:  

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

Click here to join the Meeting
Click here to view the Presentation

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,

https://oracleracexpert.com

ORA-51801 Fix: How to Resolve Vector Dimension Mismatch in Oracle 26ai

As users adopt AI features in Oracle 26ai, I see one error appearing frequently

“ORA-51801: VECTOR dimension mismatch”

Users face this error when the dimension of the vector being inserted or queried does not match the VECTOR column definition. Pls note that Oracle 26ai requires consistency between VECTOR column definition and the embedding being inserted or used in queries.

Here are few common Embedding Dimensions

Model Type                      Typical Dimension
MiniLM                            384 or 768
BERT variants                  768
OpenAI embeddings        1536
Large transformer models  1024+

For example 1: The below table has 768 dimension and inserting 1536, it will result ORA-51801 error.

SQL> CREATE TABLE documents (
id NUMBER,
embedding VECTOR(768)
);

SQL> INSERT INTO documents VALUES (1, :embedding_1536);

ORA-51801: VECTOR dimension mismatch

If you plan to use a 1536-dimension model, you must recreate the table with VECTOR(1536), since VECTOR dimensions cannot be altered directly.

For example 2: User can get ORA-51801 error while querying as well

SELECT * FROM documents
ORDER BY VECTOR_DISTANCE(embedding, :query_vector)
FETCH FIRST 8 ROWS ONLY;

If :query_vector dimension ≠ column dimension user will receive the error.

How to avoid these errors

• Develops should define embedding model centrally and make sure they document its output dimensions.
• Validate dimensions before insert, pls find below example

              if len(embedding) != 768:
                    raise ValueError("Invalid embedding dimension")

You can prevent ORA-51801 by creating a metadata table and validating dimensions at runtime.

 
SQL> CREATE TABLE embedding_config (
model_name VARCHAR2(100),
dimension NUMBER);

If user encounters the issue, then you should check what the VECTOR column dimension is, embedding model output and queries using same model using below query

SQL> SELECT column_name, data_type, data_length
FROM user_tab_columns
WHERE table_name = 'DOCUMENTS';

or 

SQL> DESC DOCUMENTS;

The output shows

EMBEDDING VECTOR(768)

Always remember “Your VECTOR column dimension must exactly match your embedding model output”. Note that even single value difference will trigger ORA-51801

Thanks & Regards,

https://oracleracexpert.com