Oracle Critical Patch Updates and Critical Security Patch Updates: What You Need to Know Before July 21, 2026

Oracle's security patching calendar just got a lot busier — and a lot more important to track. With a new Critical Patch Update landing this week and Critical Security Patch Updates now filling the gaps between quarterly releases, DBAs and security teams have more patch windows to plan around than ever before. Here's a rundown of what these programs are, what's changed recently, and what you should be doing right now.

What is a Critical Patch Update (CPU)?

Critical Patch Updates provide security patches for supported Oracle on-premises products. A CPU is a collection of patches addressing multiple security vulnerabilities — both in Oracle's own code and in third-party components bundled into Oracle products. These patches are usually cumulative, meaning a current CPU typically rolls up fixes from prior releases, and they're available to customers with valid support contracts.

CPUs are released on a predictable quarterly cadence: the third Tuesday of January, April, July, and October. The upcoming schedule is:

• 21 July 2026
• 20 October 2026
• 19 January 2027
• 20 April 2027

What is a Critical Security Patch Update (CSPU)?

Newer to Oracle's lineup, Critical Security Patch Updates provide targeted, high-priority security fixes in a smaller, more focused format — designed to be easier to apply with minimal disruption than a full quarterly CPU. Rather than replacing the CPU program, CSPUs complement it, giving customers more frequent opportunities to close out high-priority vulnerabilities between the big quarterly releases. Like CPUs, they require a valid support contract.

Oracle released the first Critical Security Patch Update on May 28, 2026, and has continued the cadence with a June 2026 release. Going forward, CSPUs land on the third Tuesday of February, March, May, June, August, September, November, and December — effectively filling every month that doesn't already have a CPU. The upcoming CSPU dates are:

• 18 August 2026
• 15 September 2026
• 17 November 2026
• 15 December 2026

Put together, CPUs and CSPUs mean Oracle now ships a security update essentially every month of the year.

Where things stand as of July 2026

Checking Oracle's Critical Patch Updates, Critical Security Patch Updates, Security Alerts and Bulletins page, the most recently completed quarterly release is the April 2026 CPU (Revision 2, published April 24, 2026). Since then, Oracle has issued two Critical Security Patch Updates — May 2026 (Rev 1, May 28) and June 2026 (Rev 1, June 16) — along with standalone security alerts for individual high-impact CVEs, including CVE-2026-35273 (Rev 1, June 10, 2026).

That brings us to the next big date on the calendar: July 21, 2026, when the next quarterly Critical Patch Update is due.

Why the July 2026 CPU deserves extra attention

Early advisory details point to this being a heavier-than-usual release. Reports on the pre-release notification indicate the July 2026 CPU addresses roughly 5 critical-severity vulnerabilities (CVSS 9.0+) and 12 or more high-severity flaws, spread across widely deployed products including Oracle WebLogic Server, PeopleSoft, Oracle Identity Manager, Oracle WebCenter, WebCenter Capture, and Oracle VirtualBox.

The most serious issue flagged so far is a pre-authentication remote code execution vulnerability in PeopleSoft (CVSS 9.8), which is reportedly already being actively exploited in the wild in combination with CVE-2026-35273 by a known threat actor group. Other near-maximum-severity issues include unauthenticated RCE vulnerabilities in WebLogic Server (CVSS 9.9) and Identity Manager (CVSS 9.9), plus two HTTP-exploitable RCE flaws in WebCenter Capture (CVSS 9.9 each).

If you run PeopleSoft, WebLogic, Identity Manager, or WebCenter in production, this isn't a "patch it next month" release — it's a "get it on the calendar for this week" release, especially given the active exploitation reports.

Why Oracle is pushing faster patching, not just more patches

A recent Oracle Database blog post, Prepare Now: Apply the Upcoming Oracle Database Release Update Immediately Upon Availability, makes the case for why this matters beyond any single CVE. The post urges customers to prepare now for the upcoming Database Release Update — including Oracle Database 19c Release Update 19.32 and Oracle AI Database 26ai Release Update 23.26.3 — and to apply it promptly across all systems once it's available.

AI models are accelerating both vulnerability discovery and exploitation, and are increasingly capable of chaining multiple weaknesses across the application and data stack into complex, multi-step attacks. In other words, the gap between a vulnerability becoming public and it being weaponized is shrinking, which shrinks the safe window for "we'll get to it next sprint" patching.

Oracle's specific pre-release recommendations include:

• Inventorying all database infrastructure components so nothing gets missed
• Confirming systems are running supported Long-Term Support releases
• Taking advantage of Oracle's complimentary patching and security tooling
• Building out accelerated testing procedures so patches don't stall in QA
• Reviewing high-availability technologies to enable minimal-downtime deployment
• Validating backup and recovery processes before, not after, you need them

What this means for your patch calendar

With CPUs and CSPUs now running nearly every month, ad hoc patching is no longer a workable strategy. A few practical takeaways:

1. Build the recurring cadence into your change management process now. Third-Tuesday releases are predictable — there's no reason to be caught off guard by them.
2. Treat CSPUs as real work, not optional extras. They're smaller by design, but they exist specifically to close high-priority gaps between quarterly CPUs.
3. Prioritize by exploitability, not just CVSS score. The July 2026 CPU is a good example — actively exploited flaws (like the PeopleSoft RCE) should jump the queue regardless of what else is in the release.
4. Pre-stage your testing and HA/downtime plans before the release drops, following Oracle's own guidance, so the time between "patch available" and "patch applied in production" is measured in days, not weeks.

Sources:

• Oracle Critical Patch Updates, Critical Security Patch Updates, Security Alerts and Bulletins
• Prepare Now: Apply the Upcoming Oracle Database Release Update Immediately Upon Availability – Oracle Database Blog

 

OCFS2 setup for shareable ( Read/write) Block Volume for Multiple Cluster Compute instances

This blog explains how to create shareable block volumes and mount them across multiple OCI compute nodes. 

Step 1: Create the block volume in OCI
In the OCI console , create a block volume in the same availability domain as your compute instances. Pick size and performance to match your workload.

Step 2: Attach the volume to each cluster node

1. Open the volume (or the instance) and choose Attach block volume
2. Set Attachment type to iSCSI (not paravirtualized for this flow).
3. Set Attachment access to Read/write – shareable.

Attach the same volume to all nodes in cluster, with the same settings each time.

Step 3: Run the iSCSI commands on each node
After each attachment, OCI shows iSCSI IPv4 commands & information for that attachment.
Open it and copy the full set of `iscsiadm` commands  (discover, login, and any optional rescan steps OCI lists).

1. SSH to the node
2. Paste and run those commands as root or with `sudo`, exactly as OCI documents for your image (Oracle Linux / RHEL-style hosts usually use the `iscsiadm` sequence from the console).
Repeat on every node so each host has an active iSCSI session to the same volume.

Check: On each node run `lsblk` (or `fdisk -l`). You should see a new disk (often `/dev/sdb` or similar).

OCFS2 needs a small cluster layout file. The file must list all nodes in the cluster. `node_count` must match how many `node:` blocks you define.
Step 4: Create the config directory
On each node:
sudo mkdir -p /etc/ocfs2

Step 5: Edit `cluster.conf`
sudo vi /etc/ocfs2/cluster.conf
cluster:
    node_count = 2
    name = ocfs2

node:
    number = 0
    cluster = ocfs2
    ip_port = 7777
    ip_address = 10.0.0.94
    name = jay-db-node01

node:
    number = 1
    cluster = ocfs2
    ip_port = 7777
    ip_address = 10.0.0.95
    name = jay-db-node02

Use one cluster name (here `ocfs2`)
Private IPs your nodes use to talk to each other (often the VCN private address).
`ip_port` is commonly 7777 for OCFS2.
`number` must be unique per node (0, 1, 2, …).

copy same `cluster.conf` on every node—the full list of all nodes and their IPs must match on each machine.

Register and configure O2CB
Step 6: Register the cluster
sudo o2cb register-cluster ocfs2

That tells the system which cluster this node belongs to.

Step 7: Configure the driver (one time per node)
[root@jay-db-node01 ~]# sudo /sbin/o2cb.init configure
Configuring the O2CB driver.

This will configure the on-boot properties of the O2CB driver.
The following questions will determine whether the driver is loaded on
boot.  The current values will be shown in brackets ('[]').  Hitting
<ENTER> without typing an answer will keep that current value.  Ctrl-C
will abort.

Load O2CB driver on boot (y/n) [n]: y
Cluster stack backing O2CB [o2cb]:
Cluster to start on boot (Enter "none" to clear) [ocfs2]: ocfs2
Specify heartbeat dead threshold (>=7) [31]: 31
Specify network idle timeout in ms (>=5000) [30000]: 5000
Specify network keepalive delay in ms (>=1000) [2000]:
Specify network reconnect delay in ms (>=2000) [2000]:
Writing O2CB configuration: OK
checking debugfs...
Loading stack plugin "o2cb": OK
Loading filesystem "ocfs2_dlmfs": OK
Creating directory '/dlm': OK
Mounting ocfs2_dlmfs filesystem at /dlm: OK
Setting cluster stack "o2cb": OK
Registering O2CB cluster "ocfs2": OK
Setting O2CB cluster timeouts : OK

Step 8: Start O2CB and check status
[root@jay-db-node01 ~]# sudo o2cb register-cluster ocfs2
[root@jay-db-node01 ~]# sudo systemctl start o2cb
[root@jay-db-node01 ~]# sudo o2cb cluster-status ocfs2
Cluster 'ocfs2' is online

Mount point and format the volume
Step 9: Create the mount directory ( All Nodes)
sudo mkdir /Oradb_data

Step 10: Format the shared disk with OCFS2 (Run it one time on one node only)
[root@jay-db-node01 ~]# sudo mkfs.ocfs2 -L Oradb_data /dev/sdb -N 8
mkfs.ocfs2 1.8.6
Cluster stack: classic o2cb
Label: Oradb_data
Features: sparse extended-slotmap backup-super unwritten inline-data strict-journal-super xattr indexed-dirs refcount discontig-bg
Block size: 4096 (12 bits)
Cluster size: 4096 (12 bits)
Volume size: 2199023255552 (536870912 clusters) (536870912 blocks)
Cluster groups: 16645 (tail covers 2048 clusters, rest cover 32256 clusters)
Extent allocator size: 276824064 (66 groups)
Journal size: 268435456
Node slots: 8
Creating bitmaps: done
Initializing superblock: done
Writing system files: done
Writing superblock: done
Writing backup superblock: 6 block(s)
Formatting Journals: done
Growing extent allocator: done
Formatting slot map: done
Formatting quota files: done
Writing lost+found: done
mkfs.ocfs2 successful

When you see mkfs.ocfs2 successful, the volume is ready. Do not run `mkfs` again on the other nodes.

fstab and mount on every node
Step 11: Add fstab on all nodes
sudo vi /etc/fstab
/dev/sdb /Oradb_data ocfs2     _netdev,defaults   0 0

If the shared disk shows up as a different device name on another node, use a stable name (UUID or `/dev/disk/by-id/...`) so every node points at the same LUN.

Step 12: Mount on all nodes
sudo mount -a
Check with `df -h /Oradb_data` or `mount | grep Oradb_data`

[root@jay-db-node01 ~]# df -h /Oradb_data
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb        2.0T  4.2G  2.0T   1% /Oradb_data

Oracle AI World 2025: What Really Stood Out This Year

Oracle AI World 2025 felt different. Not just because the event got a new name, or because it took over Las Vegas with thousands of attendees, or even because there were two new CEOs at the helm. It felt different because Oracle finally showed what it looks like when a company built on enterprise data decides to go all-in on AI.

Most people still think of Oracle as “the database company.” And sure—that’s part of its DNA. But this year’s event made one thing very clear:Oracle is no longer just storing enterprise data. It’s activating it. With AI. Everywhere.

Below is my take on the biggest announcements, the boldest ideas, and why Oracle AI World 2025 may be one of the company’s most important conferences in years.

Big Announcements You Should Know About
AI Agent Marketplace
This was one of the most talked-about launches—an online store of pre-built AI agents that plug directly into Fusion Apps.
And these aren’t little chatbots. These are real workflow-level agents built by partners like Deloitte, Accenture, Stripe, IBM, and others.
Think of it like an App Store, but for enterprise AI automation.

AI Agent Studio  & Agent Hub
AI Agent Studio is basically the design room where you build or fine-tune AI agents for Oracle Fusion Cloud Applications. You don’t need to be a hardcore developer—it's built for no-code/low-code creation.
You can start with Oracle’s pre-built agent templates or build your own from scratch. These agents can do everything from predicting equipment failures to summarizing meetings to handling procurement tasks.
Because it’s tightly connected to Fusion Apps, the agents can securely tap into real business data and take real actions. Developers and admins use the Studio to build and deploy, while business users simply interact with the agents through AI Chat or Ask Oracle right inside their Fusion screens.

If the Studio is where you build, Agent Hub is where you run and scale.
Agent Hub, part of OCI Generative AI, helps enterprises manage, monitor, secure, and expand their AI agents across the organization. It includes an AI Agent Marketplace (so you can pull in new, pre-built agent capabilities from Oracle partners) and support for a wider range of LLMs to power more sophisticated behaviors.

Database 26ai: Oracle Rewrites Its Engine for the AI Era
The upgrade from 23ai to 26ai isn’t incremental—it’s a reinvention.

Key takeaways:

• Vector and RAG are built into the engine
• Iceberg support brings openness
• It reduces data duplication
• It enables in-database AI agents
• It’s the foundation for Oracle’s new AI lakehouse

Some people say Oracle is behind Snowflake or Databricks in vectors/RAG.
But Oracle made a simple point:

If your entire business runs on Oracle data, do you want to move it to a new AI store…
or just bring AI to where the data already lives?

OCI Infrastructure & The Zettascale Supercomputer
OCI Dedicated Region25: Bringing an entire OCI region into as little as three racks for sovereign cloud, low-latency, and regulatory control.

NVIDIA Zettascale10 AI Supercomputer: A stunning commitment to scale, announcing a potential world-largest cloud-based supercomputer with hundreds of thousands of NVIDIA GPUs and 16 zettaFLOPS peak performance, built on Oracle’s low-latency Acceleron RoCE network.

Oracle AI Data Platform :
Oracle unveiled its new Autonomous AI Lakehouse—open, multicloud, Iceberg-native, and deeply integrated with Database 26ai.
Everyone is building a lakehouse these days, but Oracle’s spin is unique:
Most vendors approach AI from the unstructured-storage angle.
Oracle approaches it from the structured-enterprise-data angle.

Fusion Apps: AI at No Extra Cost (Yes, Really)
Here’s the part that shocked a lot of people:
Oracle is bundling 600+ AI agents and 100+ new AI features directly into Fusion Apps for no additional license fee.
No AI surcharge.
No per-user pricing.
No “AI edition.”

Final Thoughts: Oracle Is Playing the Long Game
Oracle AI World 2025 felt like a company fully aligned around AI—from Larry’s long-term industry vision to Clay’s infrastructure strategy to Sicilia’s application intelligence.

If you’re an enterprise already in the Oracle ecosystem, the value story is compelling:

• AI agents included
• AI in the database
• AI in the lakehouse
• AI in every Fusion workflow
• AI-ready cloud infrastructure
• Multicloud flexibility

Oracle AI World 2025 made one thing clear: Oracle is no longer just keeping up in the AI race—it’s shaping its own lane.
 

Adding some of my favorite photos from Oracle AI World 2025. Speaking at the event was truly a highlight for me. 

 

 

 

 

 

 

 

 

 

 

 

 

  

 

Co-presented "Oracle AI Database Cloud Service: What's New and What's Next" alongside Binoy Sukumaran and Tushar Pandit.  

 

 

 

 

 

 

 

 

 

 

 

 

Guest Speaker : Modern DevX OraOperator + AI Centric App Development with Oracle Database 23ai  

 

 

 

 

 

 

 

 

OCI Ops Insights: Turning Data Into Proactive Intelligence

 What Is OCI Ops Insights? 

Ops Insights is Oracle’s intelligent observability and analytics service that provides comprehensive visibility into resource usage, capacity, and SQL performance across databases and hosts — whether they run on OCI, on-premises, or in hybrid environments.

Think of it as your command center for operational intelligence — combining analytics, automation, and AI-driven recommendations to keep your systems optimized and predictable.

Core Capabilities

 

1. Database Insights
Gain complete visibility into the performance and health of your databases.
SQL Insights – Analyze SQL performance trends, find inefficient queries, and identify tuning opportunities.
Database Performance – Track database-level metrics and diagnose bottlenecks before they impact users.
ADDM Spotlight & AWR Hub – Access Automatic Workload Repository data across your entire fleet for unified analysis.

2. Capacity Planning
Forecast capacity issues before they happen.
Monitor CPU and storage utilization across databases, hosts, and Exadata systems.
Predict growth trends to plan for future expansion or cost optimization.

3. Exadata Insights
Get specialized performance and capacity visibility for Exadata infrastructure.
Analyze workloads with Exadata Warehouse.
Explore data with Exadata Explorer to pinpoint system-level trends.

4. Dashboards & Reporting
Visualize and communicate insights effectively:
Create custom dashboards using out-of-box widgets or saved searches.
Generate news-style reports to share operational summaries with teams and management.
Use the AWR Explorer and Data Object Explorer for deep performance exploration.

5. Administration & Configuration
Seamlessly manage your monitored environment:
Configure agent-managed and Enterprise Manager-managed resources.
Enable Autonomous AI Database Full Feature for advanced analytics.
Manage endpoints, AWR Hubs, and collection configurations with ease.  

 

 

 

 

 

 

 

 

 

Securing Oracle Databases with Oracle Data Safe

 

 

 

What Is Oracle Data Safe?
Oracle Data Safe is a cloud-based, unified security control center designed specifically for Oracle Databases — whether they reside in Oracle Cloud Infrastructure (OCI), Autonomous Database, or on-premises deployments.

It simplifies the complex, manual tasks involved in securing databases and meeting compliance requirements. With a few clicks, you can evaluate risks, analyze user privileges, discover sensitive data, apply masking policies, and audit activities.

 

Features of Oracle Data Safe:

 

 

 

🔍 1. Security Assessment
The Security Assessment feature evaluates the security posture of your Oracle Databases.
It reviews configurations, user accounts, and security controls, then provides detailed findings with actionable recommendations to reduce or mitigate risks.

Key aspects:

• Analyzes configuration settings, user privileges, and security parameters.
• Compares against industry frameworks like STIG, CIS Benchmarks, EU GDPR, and Oracle best practices.
• Generates an overall Security Score and a prioritized list of vulnerabilities.
• This ensures your databases consistently align with compliance standards and internal security policies.

👥 2. User Assessment
User Assessment identifies users and accounts that may pose security risks due to excessive privileges, weak authentication, or poor password practices.
It analyzes user data stored in the database dictionary and assigns a risk score to each user.

Capabilities include:

• Identifies highly privileged or inactive accounts.
• Evaluates password policies, authentication types, and password change frequency.
• Links directly to related audit trail entries for deeper investigation.
• This enables DBAs and security teams to implement least-privilege access controls and strengthen user governance.

🧭 3. Data Discovery
Data Discovery automates the identification of sensitive data within your Oracle Databases.
It scans both data and metadata to locate information that could fall under privacy or compliance regulations.

Highlights:

• Detects data across multiple sensitivity categories — personal, financial, healthcare, employment, academic, and more.
• Offers default discovery templates or lets you define custom data models to fit your organization’s classification standards.
• Produces clear reports listing schemas, tables, and columns containing sensitive data.
• With Data Discovery, you know exactly where your critical data resides — a foundational step toward compliance and data protection.

🧩 4. Data Masking
The Data Masking feature helps organizations protect sensitive data when replicating or sharing databases for development, testing, or analytics.
It replaces real values with realistic but fictitious data, maintaining referential integrity while ensuring privacy.

Key benefits:

• Supports multiple masking formats — randomization, substitution, nullification, and lookup-based.
• Integrates seamlessly with Data Discovery results for consistent masking policies.
• Enables safe use of production-like data in non-production environments.
• This reduces the risk of data exposure and helps organizations comply with data privacy regulations.

📜 5. Activity Auditing
Activity Auditing provides continuous visibility into who is doing what in your databases.
It captures user activities — from logins and schema changes to data queries and privilege modifications.

Capabilities:

• Monitors database activity in real time.
• Generates audit reports for compliance and governance reviews.
• Detects unusual or unauthorized access patterns.
• Auditing is crucial for incident investigation, accountability, and regulatory compliance.

⚡ 6. Alerts
Alerts keep you informed of unusual or high-risk database activities as they occur.
You can define custom thresholds or use predefined alert templates to detect anomalies in user behavior or database operations.
With proactive alerting, teams can respond faster to threats, minimizing potential damage and downtime.

🧱 7. SQL Firewall (New in Oracle AI Database 26ai)
The SQL Firewall introduces an advanced layer of protection directly at the SQL level, helping safeguard databases from SQL injection attacks, compromised accounts, and unauthorized queries.
Oracle Data Safe acts as the central management hub for SQL Firewall policies across all connected databases.

Capabilities:

• Collects and baselines authorized SQL activities for each user.
• Generates allowlist-based firewall policies that define approved SQL statements and connection paths.
• Monitors and reports SQL Firewall violations in real time across your entire database fleet.
• This feature enables a zero-trust approach to database access — ensuring only verified SQL statements are executed against your most sensitive systems. 

 

Step-by-Step Configuration Guide:

• Sign in to your OCI Console with appropriate privileges (Security Administrator or tenancy-level admin).
• In the left navigation menu, go to Oracle AI Database → Data Safe - Database Security 

 

  

Step 2: Register Your Database
Before you can run any assessments or audits, your database needs to be registered with Data Safe.

Supported Target Databases:

• On-Premises Oracle AI Database
• Oracle Autonomous AI Database on Dedicated Exadata Infrastructure 
• Oracle Autonomous AI Database on Exadata Cloud@Customer
• Oracle Autonomous AI Database Serverless
• Oracle Base Database Service
• Oracle AI Database on a compute instance in Oracle Cloud Infrastructure
• Oracle Exadata Database Service on Cloud@Customer
• Oracle Exadata Database Service on Dedicated Infrastructure
• Oracle Exadata Database Service on Exascale Infrastructure
• Amazon RDS for Oracle
• Oracle Database@AWS
• Oracle Database@Azure
• Oracle Database@Google Cloud

Lets Register an Autonomous Database 

In the OCI Console, navigate to Data Safe → Targets → Register Target Database.

 

 

For Database Type, select Autonomous Database.

Under Data Safe Target Information:

• Choose the Compartment where your database resides.
• Select your database from the drop-down list of available Autonomous Databases.
• Enter a Display Name for your Data Safe target.
• (Optional) Add a Description to help identify the purpose or environment of this database (e.g., “Data Safe practice environment”).
• Choose a Compartment for the target registration and (Optional) apply Tags for easier management and automation.
• Review the connection details to ensure the selected database and compartment information are correct. 

 

Click Register to complete the process.

 

 

Step 3: Explore the Data Safe Dashboard

After completing the registration, your target database will now appear in the Targets list with an Active status — confirming a successful connection to Oracle Data Safe.

Now, let’s move to the Oracle Data Safe Dashboard, the central console where you can view, monitor, and manage all your database security operations.

 

In the OCI Console, navigate to

Oracle AI Database → Data Safe - Database Security → Dashboard and click

This will take you to the Data Safe → Security Center → Dashboard, where you can view an integrated overview of your database security posture — including assessments, user risks, sensitive data discovery, and audit summaries across all registered databases.

 

 

You can view quick summaries such as:

Security assessment:

 

User assessment:

 

From this dashboard, you can easily navigate to each of the key features:
Assessments – Run or view Security and User Assessments
Data Discovery & Masking – Identify and protect sensitive data
Auditing – Monitor and analyze database activities
SQL Firewall & Alerts – Manage SQL protection and incident notifications

This blog covers the high-level steps to set up Oracle Data Safe.
In the next post, I will share more detailed insights and advanced configurations to get the most out of Data Safe.

 

 

DML Error Logging

What Is DBMS_ERRLOG?
DBMS_ERRLOG is a built-in Oracle package that helps you manage errors during DML operations (like INSERT, UPDATE, or DELETE). Its core function is to create and use an error logging table. Instead of failing the entire statement when it encounters a bad row, database simply logs the error and moves on to the next one. 

How Does It Work?
The process is simple and involves two main steps:
    Create an Error Logging Table: use the DBMS_ERRLOG.CREATE_ERROR_LOG procedure to create a table that will store information about any rows that fail your DML statement. only need to do this once for each target table.
    Enable Error Logging in Your DML Statement: add the LOG ERRORS clause to your INSERT, UPDATE, or DELETE statement. This tells the database to use the error logging table  created.

Lets try sample table
SQL> CREATE TABLE contacts (
    contact_id NUMBER PRIMARY KEY,
    first_name VARCHAR2(50),
    last_name VARCHAR2(50)
);  

Table created.
Create an error log table for the contacts table using the DBMS_ERRLOG.CREATE_ERROR_LOG procedure. This only needs to be done once per target table.
SQL> BEGIN
  DBMS_ERRLOG.CREATE_ERROR_LOG('contacts', 'contacts_err_log');
END;
/  
PL/SQL procedure successfully completed.

Insert data to contacts table
SQL> INSERT INTO contacts (contact_id, first_name, last_name) VALUES (1, 'John', 'Doe') LOG ERRORS INTO contacts_err_log ('bulk_insert_test') REJECT LIMIT UNLIMITED;
1 row created.

SQL> INSERT INTO contacts (contact_id, first_name, last_name) VALUES (2, NULL, 'Smith') LOG ERRORS INTO contacts_err_log ('bulk_insert_test') REJECT LIMIT UNLIMITED;
1 row created.

SQL> INSERT INTO contacts (contact_id, first_name, last_name) VALUES (1, 'Jane', 'Doe') LOG ERRORS INTO contacts_err_log ('bulk_insert_test') REJECT LIMIT UNLIMITED;
0 rows created.

SQL> INSERT INTO contacts (contact_id, first_name, last_name) VALUES (3, 'Peter', 'Jones') LOG ERRORS INTO contacts_err_log ('bulk_insert_test') REJECT LIMIT UNLIMITED;
1 row created.

SQL> commit;
Commit complete.
Lets check error details from error log table:
SQL> SELECT *  FROM contacts_err_log;
   ORA_ERR_NUMBER$ ORA_ERR_MESG$                                                            ORA_ERR_ROWID$         OR ORA_ERR_TAG$                 CONTACT_ID               FIRST_NAME     LAST_NAME
------------------ ------------------------------------------------------------------------ ---------------------- -- ---------------------------- ------------------------ -------------- ----------------
                 1 ORA-00001: unique constraint (SYS.SYS_C008882) violated                                         I  bulk_insert_test             1                        Jane           Doe

The output will show you the specific error codes and messages for each failed row, allowing you to easily identify and correct the data issues.

Oracle Optimizer Hints

What Exactly is an Optimizer Hint?
A hint is a comment placed within an SQL statement (after SELECT, UPDATE, INSERT, MERGE, or DELETE) that instructs the Cost-Based Optimizer (CBO) to use a particular execution approach, even if the CBO might calculate that path to be more "expensive."
Hints are enclosed in special comment syntax: /*+ hint_name(arguments) */.
For example, to prioritize the fastest return of the first 10 rows:
SELECT /*+ FIRST_ROWS(10) */ employee_id, last_name FROM employees;
While powerful for testing and troubleshooting, remember: hints are extra code to manage and can become obsolete or even detrimental after database changes. For long-term stability, tools like SQL Plan Baselines are often preferred.

Types of Hints: Scope of Influence
Oracle hints are categorized by the scope of the SQL they affect, determining the specific part of the statement they influence:
    Single-Table Hints: These are specified on a single table or view within the query. They are used to influence operations directly against that specific object. An example is the INDEX hint, which instructs the optimizer to use a particular index when accessing the table.
    Multi-Table Hints: Similar to single-table hints, but they can specify one or more tables or views, often to influence the relationship or order between them. The LEADING hint is a prime example, used to enforce a specific order in which tables are joined. Note that a hint like USE_NL(table1 table2) is often just a shorthand for two single-table hints.
    Query Block Hints: These hints operate on an entire query block, such as the main query or a named subquery. They typically affect transformations or high-level execution strategies for that block. Examples include STAR_TRANSFORMATION and UNNEST.
    Statement Hints: These apply to the entire SQL statement, regardless of complexity or query blocks. They often control global execution parameters. The ALL_ROWS hint, which optimizes for best overall throughput rather than fastest initial response, is a common statement hint.

Hints by Category:
Oracle's many hints are logically grouped into categories, providing granular control over different phases of query optimization and execution:
1. Hints for Optimization Approaches and Goals:
These hints set the overarching objective for the optimizer, overriding the session or system settings:
    ALL_ROWS
    FIRST_ROWS(n)
2.Hints for Enabling Optimizer Features
This hint allows you to maintain plan stability across database versions:
    OPTIMIZER_FEATURES_ENABLE
3.Hints for Access Paths
These hints instruct the optimizer to use a specific method for accessing data in a table:
    FULL
    CLUSTER
    HASH
    INDEX and NO_INDEX
    INDEX_ASC and INDEX_DESC
    INDEX_COMBINE
    INDEX_JOIN
    INDEX_FFS and NO_INDEX_FFS
    INDEX_SS and NO_INDEX_SS
    INDEX_SS_ASC and INDEX_SS_DESC
4.Hints for Join Orders
These hints suggest the order in which tables should be joined:
    LEADING
    ORDERED
5.Hints for Join Operations
These hints instruct the optimizer on the algorithm to use for joining tables:
    USE_NL and NO_USE_NL
    USE_NL_WITH_INDEX
    USE_MERGE and NO_USE_MERGE
    USE_HASH and NO_USE_HASH
6.Hints for Online Application Upgrade
These specialized hints manage concurrency during Edition-Based Redefinition (EBR) upgrades:
    CHANGE_DUPKEY_ERROR_INDEX
    IGNORE_ROW_ON_DUPKEY_INDEX
    RETRY_ON_ROW_CHANGE
7.Hints for Parallel Execution
These hints control whether and how the SQL statement should be executed in parallel:
    PARALLEL and NO_PARALLEL
    PARALLEL_INDEX and NO_PARALLEL_INDEX
    PQ_DISTRIBUTE
8.Hints for Query Transformations
These hints allow you to enable or disable specific logical rewrites of the SQL statement:
    NO_QUERY_TRANSFORMATION
    USE_CONCAT
    NO_EXPAND
    REWRITE and NO_REWRITE
    MERGE and NO_MERGE
    STAR_TRANSFORMATION and NO_STAR_TRANSFORMATION
    FACT and NO_FACT
    UNNEST and NO_UNNEST
9.Additional Hints
This is a collection of hints for various other specific needs and behaviors:
    APPEND, APPEND_VALUES, and NOAPPEND
    CACHE and NOCACHE
    PUSH_PRED and NO_PUSH_PRED
    PUSH_SUBQ and NO_PUSH_SUBQ
    QB_NAME
    CURSOR_SHARING_EXACT
    DRIVING_SITE
    DYNAMIC_SAMPLING
    MODEL_MIN_ANALYSIS

A key addition in Oracle Database 23ai is related to vector data processing, essential for AI-driven similarity searches:
    VECTOR_INDEX_SCAN: This hint instructs the optimizer to explicitly use a Vector Index to satisfy the query. This is vital for accelerating similarity searches on vector data, ensuring the database leverages its specialized vector processing capabilities for these modern data types.
    
    

Why Local Indexes Stay Usable in Oracle Partitioned/Subpartitioned Tables

Understanding the Players: Partitioning and Indexes
Before we jump into TRUNCATE, let's quickly recap the two stars of our show:
    Partitioning: Imagine your massive database table as a giant book. Partitioning is like dividing that book into smaller, more manageable chapters (partitions) and even sections within those chapters (subpartitions). This helps with performance, maintenance, and data lifecycle management.
 Indexes: Indexes are like the index at the back of our book. They help Oracle quickly find specific rows without scanning the entire table.
Now, when you have a partitioned table, you can have two main types of indexes:
 Global Indexes: These are like a single, comprehensive index for the entire book. They don't care about your chapters; they just list every keyword and its page number, no matter which chapter it's in.
 Local Indexes: These are the game-changers for partitioned tables. With a local index, for every chapter (or sub-chapter), you get its own mini-index. So, "Chapter 1 Index," "Chapter 2 Index," and so on. Critically, the local index is partitioned exactly the same way as its table. This means the index entries for data in Chapter 1 only reside in Chapter 1 Index.

Power of TRUNCATE
The TRUNCATE command is a Data Definition Language (DDL) operation. Unlike DELETE (which logs every row deletion and generates undo), TRUNCATE rapidly deallocates all space used by the data in a table or partition/subpartition. It essentially "resets" the high-water mark, making it incredibly efficient for emptying large segments.

Why TRUNCATE Keeps Local Indexes Usable
This is where the magic happens! When you TRUNCATE a subpartition (or a partition):
 Direct Correspondence: Because a local index subpartition is explicitly linked, one-to-one, with its corresponding table subpartition, Oracle knows exactly which part of the index needs to be cleared.
 Atomic Operation: When you issue TRUNCATE SUBPARTITION, Oracle doesn't just clear the data. It simultaneously and atomically truncates the associated local index subpartition. The index entries belonging to that specific data segment are removed right alongside the data.
 No Inconsistency: Since the index entries are removed from their respective local index subpartition, there are no "dangling pointers" or inconsistencies. The local index remains valid and perfectly synchronized with its remaining data. Other local index subpartitions (for untouched data) are completely unaffected.
 No Rebuild Needed: This is the best part! Because the local index subpartition is reset and ready, there's no need for a costly ALTER INDEX REBUILD operation. Your index is immediately usable for any new data inserted into the truncated subpartition.

Contrast this with Global Indexes: If you TRUNCATE a subpartition when you have a global index, that global index will become UNUSABLE. Why? Because it contains entries from all subpartitions. When one goes away, the global index is left with pointers to non-existent data, making it inconsistent and requiring a full rebuild.

What is "enq: TX - index contention"?

At its core, "enq: TX - index contention" signifies that multiple sessions are trying to acquire a Transaction (TX) enqueue on the same index block concurrently. An enqueue is a locking mechanism used by Oracle to protect shared resources. When sessions are waiting on a TX enqueue for an index, it means they are effectively "stuck" trying to modify (insert, update, or delete) rows that would impact the same small portion of an index.  

Think of it like this: Imagine a very popular book in a library. Many people want to borrow it, but there's only one copy. Everyone lines up, waiting for their turn. In our database analogy, the "book" is a specific index leaf block, and the "people" are concurrent transactions trying to write to it. The "line" is the "enq: TX - index contention" wait.

The Root Causes: Why Does This Happen?
"enq: TX - index contention" isn't random; it stems from specific access patterns that create "hot spots" within your indexes.

1. The Monotonically Increasing Key (The Most Common Culprit)
This is by far the leading cause. When you have an index built on a column whose values are always increasing, like:
    Sequence-generated Primary Keys (e.g., ID NUMBER DEFAULT MY_SEQ.NEXTVAL)
    DATE or TIMESTAMP columns using SYSDATE / SYSTIMESTAMP
    Application-generated unique identifiers that increment sequentially

Every new INSERT operation will attempt to add a new entry to the "right-hand side" or the highest value end of the index. If you have many sessions inserting concurrently, they all converge on the same few index leaf blocks at the "end" of the index. This creates a severe bottleneck as sessions contend for exclusive access to these blocks, leading to:
    Frequent Block Splits: As the hot block fills up, Oracle has to split it into two blocks to make room for new entries. This is an expensive operation and exacerbates contention.
    Increased Buffer Cache Activity: The hot block is constantly being read into and written from the buffer cache.
    High Interconnect Traffic (in RAC): In a RAC environment, these hot blocks are constantly "ping-ponging" between instances as different nodes try to insert into them, leading to high "gc buffer busy" waits in addition to "enq: TX" waits.

Example Scenario:
Imagine an ORDER table with ORDER_ID as a primary key, populated by ORDER_SEQ.NEXTVAL. In a busy e-commerce application, hundreds of orders are placed per second. Each INSERT INTO ORDERS (ORDER_ID, ...) attempts to write a new, higher ORDER_ID into the ORDER_PK index. All these inserts bottleneck on the same few index leaf blocks, resulting in "enq: TX - index contention."

2. Heavy Deletes Followed by Inserts (Index Fragmentation)
While less common than monotonic keys, this can also contribute. If you perform large-scale DELETE operations on a table, the index entries are marked as deleted but the space isn't immediately reclaimed. Subsequent INSERT operations might then try to reuse this freed space. If many concurrent sessions are attempting to insert into these "fragmented" or "sparse" index blocks, it can lead to contention as they fight for ITL (Interested Transaction List) slots or space within those blocks.

3. Low PCT_FREE for the Index
PCT_FREE specifies the minimum percentage of free space reserved in each data block for future updates. While more critical for data blocks, a very low PCT_FREE on an index could theoretically contribute to contention if updates to existing index entries cause the blocks to become excessively full, leading to more frequent splits or difficulty in allocating ITL slots for concurrent transactions. This is a less frequent direct cause but can be a contributing factor.
The Impact: How Does It Hurt Performance?
The consequences of "enq: TX - index contention" are significant:
    Reduced Throughput: Transactions wait, slowing down overall DML operations.
    Increased Response Times: User experience suffers as applications become sluggish.
    High CPU Utilization: Index block splits, consistent read generation, and frequent buffer cache operations consume more CPU.
    Increased I/O (Indirectly): While primarily a CPU/contention issue, increased block splits can indirectly lead to more I/O.
    RAC-Specific Woes: In RAC, this contention translates directly to high "gc buffer busy" waits, as instances spend excessive time transferring the same hot blocks back and forth across the interconnect.

The Fixes: Solutions to Alleviate Index Contention
Once you've identified "enq: TX - index contention" as a problem (typically via AWR reports showing high waits for this event and pinpointing the exact index), here are the most effective strategies:

Solution 1: Reverse Key Indexes (The Go-To for Monotonic Keys)
    A reverse key index physically reverses the byte order of the column's values before storing them in the index. This effectively scrambles the sequence of monotonically increasing keys, distributing them randomly across the index's leaf blocks instead of concentrating them at one end.
    When to Use: Ideal for indexes on sequence-generated primary keys or other monotonically increasing values where range scans are not critical.
    -- Original index (if it exists)
    DROP INDEX my_table_pk;
    -- Create a reverse key index
    CREATE UNIQUE INDEX my_table_pk ON my_table (id) REVERSE;
    Pros: Highly effective at eliminating hot blocks and reducing contention for inserts.
    Cons: Significantly degrades performance for index range scans (e.g., WHERE ID BETWEEN 100 AND 200). This is because the values are no longer stored in logical order. You would need to perform a full index scan or a full table scan for such queries, which can be much slower.
    Consideration: Use this only if your application primarily performs direct lookups (WHERE ID = 123) and high-volume inserts. If range scans are frequent, look at other solutions first.

Example:
If ORDER_ID is a sequence, creating CREATE UNIQUE INDEX ORDER_PK ON ORDERS (ORDER_ID) REVERSE; would distribute new order inserts across the index. Queries like SELECT * FROM ORDERS WHERE ORDER_ID = 54321; would still be efficient, but SELECT * FROM ORDERS WHERE ORDER_ID BETWEEN 1000 AND 2000; would likely be slow.

Solution 2: Hash Partitioned Global Indexes (Requires Partitioning License)
    Concept: If you have the Oracle Partitioning option, you can create a Global Hash Partitioned Index. Oracle applies a hash function to the index key, distributing the index entries across multiple partitions. This effectively spreads out the hot spot caused by monotonic keys over multiple physical index segments.
    When to Use: When you need the benefits of distributing contention but also require efficient range scans (which reverse key indexes sacrifice).

    -- Assuming MY_TABLE is already hash partitioned by some column,
    -- or you just want to partition the index itself.
    CREATE UNIQUE INDEX my_table_pk ON my_table (id)
    GLOBAL PARTITION BY HASH (id)
    (
        PARTITION p1,
        PARTITION p2,
        PARTITION p3,
        PARTITION p4
    );

    Pros: Excellent for distributing inserts and maintaining good range scan performance.
    Cons: Requires the Oracle Partitioning option (additional license). Can be more complex to manage than simple indexes.

Solution 3: Increase Sequence CACHE Size
    If your index key is derived from a sequence (e.g., MY_SEQ.NEXTVAL), increasing the CACHE size for that sequence can help. Instead of fetching one number at a time, each session (or instance in RAC) can fetch a block of numbers (e.g., 100 or 1000). This reduces the contention on the sequence object itself. More importantly, in RAC, using CACHE with NOORDER allows different instances to use different ranges of sequence numbers simultaneously, indirectly distributing the inserts across the index.
    When to Use: Always consider this if sequences are generating your contended keys.
    ALTER SEQUENCE my_schema.my_sequence CACHE 1000 NOORDER;
    (Adjust 1000 based on your concurrency, often 10000 or more for very high volumes).
    Pros: Simple to implement, no impact on index scan performance.
    Cons: Does not directly address the index block contention but reduces pressure on the sequence and can help distribute inserts if combined with other factors like different session start times. It's more of a complementary solution.

Solution 4: Rebuild/Shrink Indexes After Large Deletes
If your contention arises after massive DELETE operations (which leave "holes" in the index), rebuilding or shrinking the index reclaims the space and reorganizes the index structure. This can reduce contention by ensuring blocks are full and contiguous, minimizing splits when subsequent inserts occur.
    When to Use: After significant data purges.

    ALTER INDEX my_schema.my_index REBUILD ONLINE; -- Rebuilds index
    -- OR
    ALTER INDEX my_schema.my_index SHRINK SPACE; -- Shrinks index (less disruptive)

    Pros: Reclaims space, improves index efficiency, can reduce future block splits.
    Cons: Rebuilds can be resource-intensive and lock the index (though ONLINE mitigates this).

Solution 5: Increase PCT_FREE for the Index (Less Common Primary Fix)
PCT_FREE reserves space within blocks. If index blocks are consistently filling up too fast, increasing PCT_FREE provides more space for new entries and ITL slots, potentially reducing immediate contention.

When to Use: If analysis shows contention is due to rapid block filling and ITL waits.
    ALTER INDEX my_schema.my_index PCTFREE 20; -- Default is 10
    Pros: Simple change.
    Cons: Can increase index size (less efficient storage), and often not the primary solution for monotonic key contention.