Wednesday, April 1, 2026

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:

RoomSurgeryStart TimeEnd Time
OR-305Knee Replacement7:009:00
OR-305Hip Replacement8:1510: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:

RoomSurgeryStart TimeEnd Time
OR-305Knee Replacement7:009:00
OR-305Hip Replacement8:1510: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:

RoomSurgeryStart TimeEnd Time
OR-402Appendectomy6:307:30
OR-402Gallbladder Removal7:309:00

Conflict Attempt:

RoomSurgeryStart TimeEnd Time
OR-402Appendectomy6:307:30
OR-402Hernia Repair7:008: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.

Wednesday, February 25, 2026

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

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,

Wednesday, January 7, 2026

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,

Wednesday, November 12, 2025

Avoiding ORA-04068 Using RESETTABLE Packages in Oracle 26ai

In Oracle prior Oracle 26ai, if a PL/SQL package is loaded the variable values are retained across multiple calls in the same session. That means the package will keep their state within a user session. However, if a package was recompiled or modified all the active sessions that has the package will receive ORA-04068 errors.

The RESETTABLE clause introduced in Oracle 26ai, it is beneficial to avoid -ORA04068 error when the existing state of the package has been discarded.

The RESETTABLE clause can be used in package or package body during the creation. But note that users cannot be able to use RESETTABLE clause in combination with the SERIALLY_REUSABLE pragma.

Syntax: - CREATE OR REPLACE PACKAGE [BODY] RESETTABLE

Using below sample package and package body for demonstration

SQL> CREATE OR REPLACE PACKAGE sales_pkg AS
g_total_sales NUMBER := 0;
PROCEDURE add_sale;
END sales_pkg;
/
Package created

SQL> CREATE OR REPLACE PACKAGE BODY sales_pkg AS
PROCEDURE add_sale IS
BEGIN
g_total_sales := g_total_sales + 100; -- adds a fixed sale amount
DBMS_OUTPUT.PUT_LINE('Total Sales = ' || g_total_sales);
END;
END sales_pkg;
/
Package body created

We will use two different sessions for demonstration

Session 1: execute the package
SQL> EXEC sales_pkg.add_sale;

Total Sales = 100

Session 2: recompile the package

SQL> ALTER PACKAGE sales_pkg COMPILE;
Package altered

Return to Session 1:

SQL> EXEC sales_pkg.add_sale;

ORA-04068: existing state of packages has been discarded
ORA-04061: existing state of package "SALES_PKG.ADD_SALE" has been invalidated
ORA-04065: not executed, altered or dropped package "SALES_PKG.ADD_SALE"
ORA-06508: PL/SQL: could not find program unit being called: "SALES_PKG.ADD_SALE"
....

The main reason you are receiving this error because Oracle discards the package state when it is recompiled. When user run next time, it will reinitialize the package.

SQL> EXEC sales_pkg.add_sale;
Total Sales = 100

SQL> EXEC sales_pkg.add_sale;
Total Sales = 200

Now we will modify our sample code with RESETTABLE clause

SQL> CREATE OR REPLACE PACKAGE sales_pkg RESETTABLE AS
g_total_sales NUMBER := 0;
PROCEDURE add_sale;
END sales_pkg;
/
Package created

SQL> CREATE OR REPLACE PACKAGE BODY sales_pkg RESETTABLE AS
PROCEDURE add_sale IS
BEGIN
g_total_sales := g_total_sales + 100; -- adds a fixed sale amount
DBMS_OUTPUT.PUT_LINE('Total Sales = ' || g_total_sales);
END;
END sales_pkg;
/
Package body created

We will repeat the same exercise to observe how the RESETTABLE clause affects the package’s behavior.

Session 1: execute the package

SQL> EXEC sales_pkg.add_sale;
Total Sales = 100

Session 2: recompile the package

SQL> ALTER PACKAGE sales_pkg COMPILE;
Package altered

Return to Session 1: execute the package again

SQL> EXEC sales_pkg.add_sale;
Total Sales = 100

SQL> EXEC sales_pkg.add_sale;
Total Sales = 200

In the second scenario, when Oracle detects that a package’s state is no longer valid, it automatically reinitializes the package instead of raising an ORA-04068 error. By using the RESETTABLE clause, the package can safely discard its state and reinitialize without causing any errors to user session.