OraCommit | Practical Oracle Tips, Fixes & Updates

Understanding OCI Always Free Compute: Entitlements, Usage, and Reclamation Rules

Oracle Cloud Infrastructure (OCI) provides a generous Always Free tier designed to help customers explore, build, and sustain lightweight workloads at no cost. While many OCI users are familiar with compute shapes, OCPUs, and metrics, the Always Free program introduces specific usage rules that are often misunderstood—particularly around idle resource reclamation.

This blog explains what Always Free compute is, how the free usage is calculated, and why Oracle may reclaim idle instances.

What Is OCI Always Free Compute?

Always Free is a long-term entitlement within Oracle Cloud Infrastructure that allows customers to run a limited set of resources indefinitely at no charge, provided they stay within defined usage thresholds.

For compute, the most commonly used Always Free option today is:

VM.Standard.A1.Flex (Ampere Arm-based)

This shape provides a monthly free allowance equivalent to:

3,000 OCPU hours
18,000 GB memory hours

In practical terms, this allows customers to run instances totaling up to 4 OCPUs and 24 GB of RAM continuously throughout the month without incurring cost.

How Usage Is Measured (OCPU Hours Explained)

OCI bills (or tracks free usage) based on consumption, not allocation.

An OCPU hour means:

One OCPU used for one hour

Examples:

1 OCPU × 3,000 hours = 3,000 OCPU hours
2 OCPUs × 1,500 hours = 3,000 OCPU hours
4 OCPUs × 24 hours × ~30 days ≈ 2,880 OCPU hours

As long as both OCPU hours and memory hours remain within the free limits, no billing occurs.

Why Oracle Reclaims Always Free Instances

Because Always Free resources are shared and capacity-bound, Oracle enforces governance to prevent long-term reservation of unused infrastructure.

As part of this governance, idle Always Free compute instances may be reclaimed automatically.

What Does “Idle” Mean?

Oracle evaluates Always Free compute instances over a continuous 7-day period. An instance may be classified as idle if all of the following conditions are met during that period:

CPU utilization (95th percentile) is below 20%
Network utilization is below 20%
Memory utilization is below 20% (applies to A1 shapes only)

If these thresholds are consistently unmet, Oracle may stop and reclaim the instance.

Important Clarifications

Reclamation applies only to Always Free resources
Paid compute instances are not subject to this rule
Reclamation is automatic and may occur without prior notice
Boot volumes may remain, but the compute instance itself is removed
The policy is based on sustained inactivity, not brief idle periods

Practical Implications for OCI Users

For users running:

Bastion hosts
Lightweight application servers
Dev/test environments
Monitoring or automation nodes

…it is important to ensure some consistent activity exists. Instances that are powered on but doing “nothing” for extended periods are the most common candidates for reclamation.

Best Practices to Avoid Reclamation

Run periodic workloads or scheduled jobs
Ensure network traffic (even minimal) is present
Monitor CPU, memory, and network metrics
Treat Always Free as active-use infrastructure, not cold standby

Final Thoughts

OCI Always Free is a powerful offering when used as intended—for learning, development, and lightweight production use. Understanding how usage is calculated and how Oracle defines “idle” ensures you can design workloads that remain compliant, predictable, and cost-free.

Used correctly, Always Free compute can be a reliable foundation rather than a surprise outage.

Oracle AI Database 26ai Now Generally Available for On-Premises Linux x86-64 Platforms

Oracle has announced the general availability (GA) of Oracle AI Database 26ai Enterprise Edition for Linux x86-64 on-premises environments as part of the January 2026 quarterly Release Update (23.26.1). This milestone expands Oracle’s AI-native database platform beyond cloud and engineered systems into customer data centers, offering enterprises a broader choice for modern data and AI workloads.

Bringing AI-Native Data Management to the Enterprise

Oracle AI Database 26ai represents the next generation of Oracle’s converged database architecture, embedding artificial intelligence deeply into the core of the database engine. With this release now available for on-premises Linux x86-64 systems, organizations that operate critical workloads within their own data centers can leverage AI capabilities without migrating to cloud-managed environments.

This on-premises GA release ensures that enterprises with strict data sovereignty, security, compliance, or performance requirements can modernize their database platforms while taking full advantage of Oracle’s AI innovations.

Key Capabilities in Oracle AI Database 26ai

The 26ai release includes a comprehensive set of AI-enabled features and enhancements designed to transform enterprise data management:

AI Vector Search – Support for similarity search across vectorized data, enabling intelligent retrieval of related documents, images, and other unstructured data.
Globally Distributed Database with RAFT Replication – Built-in mechanisms for data replication across distributed environments.
In-Database SQL Firewall – Enhanced security controls for managing risky queries.
Quantum-Resistant Encryption – Cryptographic protections designed to withstand future computational threats.
True Cache – Performance enhancements that optimize data access patterns.
JSON Relational Duality – Unified handling of JSON and relational data within the same platform.
Apache Iceberg Lakehouse Support – Integration with modern open table formats for analytical workloads.

This extensive feature set allows organizations to combine transactional, analytical, and AI-centric workloads within a single, unified database platform.

What This Means for On-Premises Customers

Traditionally, advanced AI capabilities in Oracle databases were most accessible through cloud-hosted services or engineered systems such as Oracle Exadata. With the on-premises GA of Oracle AI Database 26ai for Linux x86-64, customers can now:

Preserve existing infrastructure investments while adopting state-of-the-art AI-native database technology.
Simplify architectures by reducing dependency on external AI platforms or middleware.
Accelerate application development and deployment with built-in AI functions.

This release underscores Oracle’s commitment to offering flexibility across cloud and on-premises deployment models, ensuring enterprises can align technology choices with business requirements.

Getting Started with Oracle AI Database 26ai On-Premises

Customers can download Oracle AI Database 26ai Enterprise Edition for Linux x86-64 from Oracle’s software distribution channels and begin planning upgrades or new deployments as part of their 2026 technology roadmap.

For further details on the release, feature highlights, and tutorials, Oracle provides an array of resources, including product documentation, live labs, and introductory videos.

Conclusion

The general availability of Oracle AI Database 26ai for on-premises Linux x86-64 systems marks a significant evolution in enterprise database technology. By seamlessly integrating AI capabilities into the database engine and extending them beyond cloud environments, Oracle empowers organizations to innovate faster, extract deeper insights, and maintain control over critical data–all within their own data centers.

Bringing Your Own Images into Oracle Cloud Infrastructure

Oracle Cloud Infrastructure allows customers to import external custom images; however, most of these images are originally built for environments that boot from local disks or use paravirtualized storage. While this works well for virtual machines, bare metal provisioning in OCI follows a different boot model and therefore requires additional preparation.

Why External Images Often Fail on Bare Metal

When an external image is imported into OCI and launched on a bare metal shape without modification, one or more of the following issues commonly occur:

The instance fails to complete the boot process
The operating system cannot locate the root filesystem
Network interfaces are not initialized during early boot

These behaviors are not platform defects. They indicate that the image lacks specific prerequisites required for bare metal booting in OCI.

Once these requirements are understood, the remediation is straightforward and enables the use of a single image across both virtual machine and bare metal instances.

Key Areas to Address for Image Compatibility

To ensure that one custom image works reliably across all OCI compute shapes, focus on the following three core areas.

1. Enable iSCSI Boot Support

Bare metal instances in OCI boot from network-attached storage using iSCSI. The operating system image must therefore support iSCSI during the earliest stages of the boot process.

At a minimum, the image should include:

Installation of the iSCSI initiator utilities (for example, iscsi-initiator-utils)
Required kernel parameters:
- rd.iscsi.ibft=1
- rd.iscsi.firmware=1
A rebuilt initramfs that incorporates iSCSI and networking support

With these elements in place, the operating system can:

Discover the boot volume presented by OCI
Initialize networking early enough to access the volume
Mount the root filesystem and continue the boot sequence

This configuration does not affect virtual machines, allowing the same disk layout to function on both VM and bare metal shapes.

2. Align Cloud-Init with OCI Requirements

Cloud-init is responsible for essential first-boot activities, including:

Applying SSH keys from instance metadata
Configuring network interfaces
Processing custom initialization scripts

External images frequently include outdated or incompatible cloud-init versions designed for other cloud platforms. For reliable operation in OCI, the image must:

Include cloud-init version 20.3 or later, which supports OCI as a data source
Remove or replace older cloud-init packages that may conflict
Configure Oracle Cloud Infrastructure as the authoritative metadata source

Once properly aligned, both virtual machine and bare metal instances initialize consistently and predictably.

3. Clean the Image Before Capture

Before converting the configured system into a reusable custom image, the operating system should be cleaned to remove residual state. This step prevents subtle and difficult-to-diagnose issues during future provisioning.

Recommended cleanup actions include:

Clearing cloud-init state and logs using cloud-init clean --logs
Removing old log files and temporary data

The objective is to ensure that every instance launched from the image behaves as a fresh deployment, regardless of the compute shape.

Summary

By enabling iSCSI boot support, ensuring cloud-init compatibility with OCI, and properly cleaning the image before capture, organizations can successfully reuse a single external custom image across both virtual machine and bare metal instances in Oracle Cloud Infrastructure. This approach reduces image sprawl, improves consistency, and simplifies operations across hybrid and cloud-native environments.

VCN Security List Allows Traffic to Restricted Ports – Alert Explanation and Remediation

An alert is generated in cloud guard when a Virtual Cloud Network (VCN) security list permits inbound traffic on ports classified as restricted. These ports are defined in the detector’s Restricted Protocol: Ports List within the input settings. Allowing such ports through ingress rules increases the attack surface and may expose workloads to unnecessary security risks.

This alert is raised to ensure that network access remains aligned with Oracle Cloud Infrastructure security best practices.

Impact

If restricted ports are allowed in VCN security list ingress rules, unauthorized or unintended access paths may be introduced. This can lead to compliance violations, increased vulnerability to network-based attacks, and deviation from established security baselines.

Recommended Resolution

Ensure that all VCN security lists do not allow any ports defined in the Restricted Protocol: Ports List through ingress (inbound) rules.

Specifically:

Review all security list ingress rules.
Remove or restrict any ports identified as restricted by the detector rule.
Validate that only explicitly required ports are permitted.

Steps to Update the Detector Rule

Sign in to the OCI Console.
Navigate to:
Oracle Cloud Guard → Detector Recipes
Open the relevant Detector Recipe.
Select Detector Rules.
Locate the rule “VCN Security List Allows Traffic to Restricted Port.”
Edit the rule and remove port 111 from the Input Settings.
Save and apply the changes.

Best Practices for Rule Customization

Controlled Configuration:
Update the Restricted Protocol: Ports List only when there is a validated business or technical requirement.
Flexible Input Options:
Restricted ports can be specified in two ways:
- Manually entering individual port numbers or port ranges.
- Referencing one or more predefined security lists by name.
Periodic Review:
Regularly review detector rules and security list configurations to ensure continued alignment with organizational security standards.

Conclusion

Proactively managing restricted ports within VCN security lists is essential to maintaining a secure OCI networking posture. By refining detector rule input settings and enforcing strict ingress controls, organizations can significantly reduce exposure to unnecessary network risks while remaining compliant with OCI security best practices.

Beyond Allow Policies: How OCI IAM Deny Policies Enhance Access Control and Risk Management

Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) traditionally follows an implicit deny model, where access is denied unless explicitly allowed. While this approach is effective, modern cloud governance often requires explicit guardrails to prevent sensitive actions—even when broad permissions exist. To address this need, OCI introduced IAM Deny Policies, enabling administrators to explicitly block specific actions and enforce stronger security controls.

What Are IAM Deny Policies?

IAM deny policies allow organizations to explicitly prohibit actions, overriding any existing allow policies. If a deny policy matches a request, the action is blocked regardless of other permissions. This capability is particularly valuable for enforcing governance standards, regulatory compliance, and operational safety in critical environments.

Deny policies are especially useful in large tenancies with multiple teams, compartments, and environments where broad access is necessary but unrestricted permissions could lead to accidental or unauthorized changes.

Key Characteristics

Explicit Opt-In

Deny policies are disabled by default and must be explicitly enabled by a tenancy administrator. Once enabled, the feature cannot be disabled, highlighting the need for careful planning before activation.

Administrator Protection

To prevent accidental lockouts, the default Administrators group in the default identity domain is exempt from deny policies. This ensures that core administrative access remains available even if restrictive deny rules are configured.

Policy Evaluation Order

During policy evaluation, deny policies take precedence over allow policies. If both apply to the same request, the deny rule always wins.

Policy Syntax Overview

Deny policies use the same structure as standard IAM policies, replacing allow with deny. This consistency makes them easy to understand and manage.

Example:

deny group DevTeam to manage bucket-family in compartment Prod
where request.operation = 'DeleteBucket'

This statement prevents the DevTeam group from deleting buckets in the production compartment, even if they have broader storage permissions.

Common Use Cases

Protecting Production Environments

Deny policies are ideal for preventing destructive actions such as deleting VCNs, databases, or object storage in production compartments.

Enforcing Separation of Duties

Organizations can restrict sensitive operations to specific teams by explicitly denying them to others, reinforcing clear responsibility boundaries.

Best Practices

Enable deny policies only after governance review and testing.
Keep deny statements narrow and condition-based to avoid unintended impact.
Regularly review deny policies as environments and teams evolve.
Document deny policies clearly to support audits and operational transparency.

Conclusion

OCI IAM Deny Policies add a powerful layer of control to cloud access management. When used thoughtfully, they help organizations protect critical resources, reduce operational risk, and enforce governance without sacrificing flexibility. As OCI environments grow in scale and complexity, deny policies become an essential tool for secure and disciplined cloud operations.

Creating Online-Patching-Compliant Table in Oracle E-Business Suite R12.2

Online patching introduced in Oracle E-Business Suite R12.2 fundamentally changed the way custom objects must be created and maintained. To ensure zero-downtime patching, every custom table must support Edition-Based Redefinition (EBR). This requires a base table, an editioning view, and an APPS synonym—created in a specific sequence using Oracle’s AD_ZD utilities.

This article provides a clear, step-by-step guide to creating an online-patching-compliant table along with its editioning view (EV) in R12.2. It also outlines how to manage future structural changes through XDF metadata or AD_ZD utilities.

1. Create the Base Table in the Owning Schema

Begin in the Run edition, logged in as the appropriate product schema (for example, APPLSYS or a custom application schema).
At this stage, only the base database objects are created.

Typical actions include:

Creating the table using standard DDL.
Defining supporting indexes.
Using APPS_TS_* tablespaces depending on the object type.
Preferring unique indexes instead of primary key constraints, in line with R12.2 object standards.

At this point, no editioning view exists. The table is still non-compliant with online patching.

2. Upgrade the Table to Create the Editioning View and APPS Synonym

Once the base table is ready, convert it into an online-patching-aware object using Oracle’s AD_ZD package:

EXEC AD_ZD_TABLE.UPGRADE('<OWNER_SCHEMA>', '<TABLE_NAME>');

This action generates two critical components:

Editioning View (EV):
Created in the owning schema with the name <TABLE_NAME>#.
This view becomes the layer through which the application interacts with the table.
APPS Synonym:
A synonym named <TABLE_NAME> is created in the APPS schema, pointing to the EV.

From this point forward, all application components—Forms, OAF, PL/SQL APIs, reports—must reference the APPS synonym. This ensures that future table changes are transparently managed through the EV without breaking online patching rules.

3. Generate and Deploy the XDF Metadata

To package this custom table for deployment across environments, Oracle requires an XDF (XML Definition File) representation.

Steps:

Insert at least one row into the new table (mandatory for XDF generation).
Run xdfgen.pl from the Run edition to produce the .xdf file containing the metadata for the table, indexes, and associated objects.
Include this .xdf in your custom application patch.
During patch application, xdfcmp.pl automatically creates the base table and invokes AD_ZD_TABLE.UPGRADE, ensuring that the EV and APPS synonym are generated in all target instances.

This makes your object fully compliant with the R12.2 adoption and deployment model.

4. Managing Future Structural Changes

When enhancements or structural modifications are required—such as adding new columns—you must preserve online patching compliance.

Two methods are supported:

a. Preferred Method: Update via XDF

Modify the XDF file and apply it using xdfcmp.pl.
This ensures consistent behavior across environments and adheres to Oracle's standards.

b. Direct DDL in Development

If a table is altered manually in a development instance:

EXEC AD_ZD_TABLE.PATCH('<OWNER_SCHEMA>', '<TABLE_NAME>');

This regenerates the EV mapping to align it with the updated table structure.

Conclusion

Building online-patching-compliant objects is essential for long-term maintainability in Oracle E-Business Suite R12.2. By creating the base table, generating the editioning view through AD_ZD utilities, and managing future changes via XDF or AD_ZD_TABLE.PATCH, you ensure seamless behavior during both Run and Patch editions.

Understanding Oracle Unified Auditing: Quick Checks for DBAs

Oracle Unified Auditing consolidates all audit records into a single, unified framework, simplifying how auditing is configured, managed, and reviewed. As more environments move toward stricter compliance and security standards, DBAs increasingly rely on Unified Auditing to track database activity efficiently.

This short guide highlights how to quickly check whether Unified Auditing is enabled and how to review the audit policies configured in your database.

✅ How to Check if Unified Auditing Is Enabled

Unified Auditing can run in two modes:

Mixed Mode (default)
Pure Unified Auditing Mode

To verify the status, check the database options:

SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';

TRUE → Unified Auditing is enabled
FALSE → Unified Auditing is disabled

If the database is running in pure mode, it was enabled during installation or via relinking.

View Enabled Unified Audit Policies

To see which audit policies are currently active:

SELECT DISTINCT policy_name 
FROM audit_unified_enabled_policies;

This lists all enabled policies, including Oracle-supplied and user-defined ones.

View All Available Unified Audit Policies

To list every policy defined in the system:

SELECT DISTINCT policy_name 
FROM audit_unified_policies;

This helps you understand what policies exist, even if they’re not currently enabled.

Check Audit Options Associated with Each Policy

To see which audit options belong to each policy:

SELECT audit_option, policy_name 
FROM audit_unified_policies 
GROUP BY policy_name, audit_option;

This provides insight into what actions are being audited under each policy.

Summary

Oracle Unified Auditing centralizes and simplifies auditing. With just a few queries, DBAs can quickly validate:

Whether Unified Auditing is active
Which policies are enabled
What audit actions are tied to each policy

These checks are essential for maintaining security, ensuring compliance, and understanding the audit footprint of your Oracle environment.