Coder Legion - Recent posts tagged oracle-cloud-infrastructure

OCI Generative AI Service: Enterprise-Grade LLMs on Oracle Cloud

Fri, 12 Dec 2025 09:55:53 +0000

Oracle Cloud Infrastructure (OCI) Generative AI is a fully managed service providing enterprises with access to state-of-the-art, customizable large language models through a comprehensive API. OCI positions itself as a neutral, enterprise-focused platform offering unprecedented choice and flexibility in the generative AI space.

What is OCI Generative AI?

OCI Generative AI helps enterprises seamlessly integrate advanced language comprehension capabilities into applications, providing a complete end-to-end platform for building, customizing, and deploying LLM-powered applications at scale.

Key Capabilities:

Access to pretrained foundational models from multiple leading AI providers
Flexible fine-tuning with custom datasets on dedicated infrastructure
Enterprise-grade security, compliance, and data sovereignty
Integration with Oracle's broader AI ecosystem
Support for both on-demand usage and dedicated hosting

Available Models (2025)

Cohere Models:

Command A (03-2025): 256K token context, excels at tool use, agents, RAG, and multilingual tasks
Command R/R+: 128K context for RAG and enterprise use cases
Embed models: English v3.0, Multilingual v3.0, Embed 4

Meta Llama Models:

Llama 4 Maverick: 17B active from ~400B total (mixture-of-experts)
Llama 4 Scout: 17B active from ~109B total
Llama 3.3 (70B), Llama 3.2 Vision (90B, 11B), Llama 3.1 (405B, 70B)

Google Gemini Models (Coming Soon):
Oracle will be the only hyperscaler aside from Google Cloud to offer Gemini as a managed service.

Gemini 2.5 Pro/Flash/Flash-Lite

xAI Grok Models:

Grok 4/Grok 4 Fast, Grok 3 series, Grok Code Fast 1

OpenAI Models:

gpt-oss-120b and gpt-oss-20b

Core Features

1. Pretrained Models

Chat Models: Multi-turn conversational AI
Text Generation: Content creation, code generation, documentation
Embedding Models: Vector representations for semantic search (384-1024 dimensions)
Rerank Models: Relevance scoring for search results

2. Fine-Tuning

Strategies:

T-Few & Vanilla for Cohere models (with layer-specific optimization)
LoRA for Llama 3 models (efficient parameter adaptation)

Customization:

Training epochs, learning rate, batch size
Early stopping controls
JSONL format with prompt/completion pairs

3. Dedicated AI Clusters

GPU-based compute resources exclusive to your tenancy:

Isolated infrastructure for fine-tuning
Private GPUs for hosting with zero-downtime scaling
Multiple cluster sizes (Small/Large/Large Generic 2/4 for 405B models)

4. Deployment Options

On-Demand: Pay-per-character, ideal for experimentation
Dedicated Clusters: Predictable costs for production workloads

5. OCI Generative AI Agents (2024-2025)

Fully managed RAG service combining LLMs with enterprise search.

Agent Hub Features (March 2025):

SQL Tool: Self-correction, multi-dialect support (Oracle SQL, SQLite)
Enhanced RAG Tool: Hybrid search, multi-modal parsing, multi-lingual support (7+ languages)
Integration with OCI Object Storage, OpenSearch, Oracle Database 23ai

Use Cases

Text Generation: Blog posts, marketing copy, documentation
Semantic Search: Intent-based search, recommendations, document retrieval
Document Summarization: Executive summaries, support tickets, research papers
Classification: Support ticket routing, sentiment analysis, intent detection
Question Answering: Intelligent responses from documents and knowledge bases
Enterprise Knowledge Management: RAG-powered customer support

Developer Experience

Access Methods:

OCI Console Playground
REST API
OCI CLI
SDKs (Python, Java, TypeScript, Node.js)

Framework Integration:

LangChain: Prompt templating, memory, chain-of-thought
LlamaIndex: Context-augmented applications, RAG solutions

Tool Use: Chat models can integrate with external tools and APIs for complex queries requiring external data.

Security & Compliance

Key Features:

Data isolation within your tenancy
Encryption at rest and in transit
Fine-grained IAM policies and RBAC
Comprehensive audit trails
Private endpoints and VPN connectivity

Regional Availability:

US (Chicago, Phoenix, Ashburn)
Europe (Frankfurt, London, Amsterdam)
Asia Pacific (Tokyo, Mumbai, Seoul)
Middle East (Dubai, Jeddah)
Latin America (São Paulo)
Sovereign Cloud: Oracle EU Sovereign Cloud for data residency

Advanced Features

Configurable Parameters:

Temperature (0.0-1.0)
Top-k and top-p sampling
Frequency/presence penalties
Seed parameter for reproducibility

Performance Benchmarks:
RAG scenarios with 2,000-token prompts and 200-token responses benchmarked across cluster types.

Pricing

Free Tier: $300 credits for trial
On-Demand: Pay-per-character (input/output)
Dedicated Clusters: Predictable monthly costs

Oracle's AI Ecosystem

Oracle Database 23ai:

Native AI Vector Search
In-database LLM integration
Support for RAG workflows

MySQL HeatWave:

In-database LLMs (HeatWave GenAI)
Automated vector store

Oracle Fusion Applications:
Generative AI embedded across ERP, HCM, SCM, and CX applications.

OCI Data Science:
No-code access to open-source LLMs (Meta, Mistral AI) with Hugging Face Transformers and PyTorch.

Certification

OCI 2025 Generative AI Professional Certification covers:

LLM Fundamentals & Transformer Architecture
Prompt Engineering
Fine-Tuning Techniques
RAG Workflows & Vector Databases
Agent Development

Resources: Free tutorials, Coursera courses, Oracle MyLearn platform

Competitive Advantages

Model Choice: Access to Cohere, Meta, Google, xAI, OpenAI through unified platform
Enterprise-First: Security, compliance, data sovereignty
Cost-Effective: Better price-performance with transparent pricing
Database Integration: Unique integration with Oracle Database 23ai and MySQL HeatWave
Sovereign Cloud: Data residency guarantees

Getting Started

Create OCI account (free tier available)
Navigate to Analytics & AI → Generative AI
Choose approach: Playground, API/SDK, or Fine-tuning
Select model and configure parameters
Start building

Example: Building a Support Chatbot

Ingest documentation into Oracle Database 23ai vector store
Create embeddings using Cohere Embed models
Deploy RAG Agent
Implement chat interface with LangChain
Enable multi-turn conversations with tool calling

OCI Generative AI offers comprehensive, enterprise-focused LLM capabilities addressing real-world needs: security, sovereignty, choice, and integration. Whether building chatbots, implementing semantic search, or developing multi-agent systems, OCI provides the foundation for enterprise-grade AI applications.

Are you using OCI Generative AI? Share your experiences below

MySQL HeatWave: Creating High Availability DB Systems and Understanding Limitations

Fri, 07 Nov 2025 14:01:41 +0000

MySQL HeatWave: Creating High Availability DB Systems and Understanding Limitations

Introduction

MySQL HeatWave offers enterprise-grade high availability features that ensure your database remains operational even during hardware failures or maintenance events. Understanding how to properly configure high availability and its associated limitations is crucial for designing resilient database architectures.

This guide walks you through creating a high availability DB system and explores the important limitations you should consider when planning your deployment.

Creating a High Availability DB System

Overview of the Creation Process

Creating a high availability DB system in MySQL HeatWave follows a structured workflow with three main phases:

Set Up Basic DB System Configuration
Specify Database and Infrastructure Details
Configure Backup and Advanced Options

Let's explore each phase in detail.

Phase 1: Set Up Basic DB System Configuration

Step 1: Access the Console

Step 2: Navigate to DB Systems

Open the navigation menu
Under Databases, select HeatWave MySQL (OCI) or MySQL HeatWave (AWS)
Click DB Systems
Click Create DB System

Step 3: Choose Deployment Template

Select the Production template, which automatically configures your system for high availability with recommended settings for production workloads.

Alternatively, you can start with Development or Testing and manually enable high availability later.

Step 4: Basic Configuration

Compartment

Select the compartment where the DB system will reside
Compartments help organize resources and control access

Name Your DB System

Display Name: Provide a meaningful name (e.g., "prod-mysql-ha-primary")
Description: (Optional) Add details about the system's purpose

Database System Type

Ensure "High Availability" is selected if using the Production template
For manual setup, you can enable this option here

Phase 2: Specify Database Information

Administrator Credentials

Username Configuration

Specify the administrator username (default is typically "admin")
Avoid reserved usernames like "root", "mysql", "sys"
Username can be up to 32 characters

Password Requirements

Must be 8-32 characters long
Include at least one:
- Uppercase letter
- Lowercase letter
- Number
- Special character from: ,.~-+*;:_!
Store credentials securely (consider OCI Vault or AWS Secrets Manager)

Network Configuration

Virtual Cloud Network (VCN)

Select an existing VCN or create a new one
Subnet: Choose a private subnet for enhanced security
Public subnets are not recommended for production databases

Availability Domain Selection

Choose the preferred availability domain for your primary instance
This becomes your preferred placement
The system will automatically distribute secondary instances across different ADs or fault domains

Security Configuration

Ensure security lists or network security groups allow:
- Port 3306 for MySQL connections
- Port 33060 for MySQL X Protocol
Restrict source CIDR blocks to known application IP ranges

Hardware Configuration (Shape)

Select DB System Shape

Choose a shape that meets your performance requirements:

ECPU Shapes (Recommended)

Architecture-agnostic and future-proof
Examples: MySQL.8, MySQL.16, MySQL.32, MySQL.64, MySQL.128, MySQL.256
Can be changed after deployment
Support high availability and HeatWave clusters

Shape Characteristics

Defines CPU count, memory, and network bandwidth
Higher shapes provide better performance but cost more
Use Autopilot Shape Advisor for recommendations based on workload

Important: All OCPU shapes are deprecated and unavailable to new users created after September 5, 2024. Existing OCPU shapes will be unavailable after March 13, 2026.

Storage Configuration

Data Storage Size

Minimum: 50 GB
Maximum: 131,072 GB (128 TB)
Plan for current data plus growth projections
Storage can only be increased, never decreased

Automatic Storage Expansion

Recommended: Enable this feature
Automatically increases storage when usage approaches limits
Prevents downtime due to storage exhaustion
Based on Health Monitor read-only thresholds

Storage Performance

Higher storage allocations provide better IOPS
Storage is backed by high-performance block storage

Phase 3: Configure Backups

Enable Automatic Backups

Why Backups Matter

Protects against data loss
Enables point-in-time recovery
Required for disaster recovery planning

Backup Configuration Options

Enable Automatic Backups

Toggle: ON (highly recommended for HA systems)
Backups run automatically at scheduled times

Backup Retention Period

Range: 1 to 35 days
Recommended: At least 7 days for production
Longer retention = higher storage costs but better recovery options

Backup Window Selection

Choose a time when database activity is lowest
Typically during off-peak hours (e.g., 2:00 AM - 4:00 AM)
Avoid peak transaction periods to minimize performance impact

Point-in-Time Recovery (PITR)

Enable to restore to any point within retention period
Uses binary logs for granular recovery
Essential for recovering from accidental data modifications

Regional Backup Copy (OCI only)

Schedule automatic backup copies to another OCI region
Provides geographic redundancy
Protects against regional disasters

Advanced Backup Options

Backup Validation

Verifies backup integrity
Ensures backups are restorable
Available on supported MySQL versions

Soft Delete for Backups

Enabled by default
Backups remain in DELETED state before permanent deletion
Provides grace period for recovery of accidentally deleted backups

Additional Configuration Options

HeatWave Cluster Configuration (Optional)

If you need analytics capabilities:

Enable HeatWave Cluster

Checkbox: Select to add analytics processing
Choose HeatWave node shape (HeatWave.512GB, HeatWave.256GB, HeatWave.128GB)
Specify number of nodes (1 to 512 depending on shape and region)

Important HA Consideration: On OCI, HeatWave clusters are fully supported with high availability. On AWS, HeatWave features (including Lakehouse, GenAI, and AutoML) are currently not supported on HA DB systems.

MySQL Configuration

Configuration Selection

Use default HA-compatible configuration (recommended)
Configurations with "HA" suffix support high availability
Custom configurations must be based on HA-compatible templates

Configuration Characteristics

Defines system variables and initialization parameters
Can be changed after deployment with rolling restarts
Affects memory allocation, connection limits, and performance tuning

Tagging (Optional)

Resource Tags

Add metadata for organization
Enable cost tracking and allocation
Support automation and bulk operations

Tag Types

Defined Tags: Created by administrators with controlled vocabularies
Free-form Tags: Simple key-value pairs for flexible labeling

Finalizing Creation

Review Configuration

Before creating:

Verify all settings are correct
Check estimated monthly cost
Ensure network connectivity is properly configured
Confirm backup settings meet compliance requirements

Create DB System

Click Create to provision your high availability DB system.

Provisioning Timeline

DB system enters CREATING state
Typical creation time: 15-30 minutes for HA systems
Three instances are provisioned across availability/fault domains
Status changes to ACTIVE when ready

What Happens During Creation

Primary instance is provisioned in preferred placement
Two secondary instances created in different domains
MySQL Group Replication is configured automatically
Initial backup is taken (if enabled)
Monitoring and health checks are activated

Understanding High Availability Limitations

While MySQL HeatWave high availability provides robust fault tolerance, it's important to understand its limitations to design systems appropriately.

1. Rolling Upgrades and Brief Downtime

Characteristic: High availability DB systems require rolling upgrades for maintenance, during which there is a brief period of downtime before the newly promoted MySQL instance resumes connections.

What This Means:

During maintenance, instances are upgraded one at a time
When the primary instance is upgraded, a failover occurs
Connection strings remain the same, but applications must reconnect
Downtime is typically measured in seconds, not minutes

Best Practice:

Implement connection retry logic in applications
Use connection pooling with automatic reconnection
Schedule maintenance during low-traffic periods
Test application behavior during failovers

2. MySQL Version Requirements

Limitation: High availability is only supported for MySQL version 8.0.24 or higher.

Implications:

Older MySQL versions cannot use HA features
Must upgrade to 8.0.24+ before enabling high availability
Consider upgrading to MySQL 8.4.x (LTS) or 9.x (Innovation) for latest features

Migration Path:

Upgrade standalone DB system to 8.0.24 or higher
Ensure all prerequisites are met (primary keys, etc.)
Enable high availability after upgrade completes

3. Direct Access Limitations

Limitation: You can only access the primary MySQL instance directly; the two secondary instances cannot be accessed using MySQL Shell or any other client.

Why This Matters:

Cannot distribute read load across secondary instances for HA systems
All connections go through the primary instance
Read replicas are separate feature for read scaling (not part of HA)

Alternative Solutions:

Use Read Replicas for read scaling (separate from HA)
Read replicas can be created on HA or standalone systems
Offload analytics queries to HeatWave cluster instead

4. Transaction Size Limits Based on Shape Memory

Limitation: The maximum transaction size depends on the amount of memory of the shape.

Transaction Size Limits by Shape:

Smaller shapes have lower transaction size limits
Larger transactions require more memory for Group Replication
Exceeding limits causes transaction failure

Example Limits (approximate):

MySQL.8 (8 ECPU, 128 GB RAM): ~2 GB transaction limit
MySQL.16 (16 ECPU, 256 GB RAM): ~4 GB transaction limit
MySQL.32 (32 ECPU, 512 GB RAM): ~8 GB transaction limit

Workarounds:

Break large transactions into smaller batches
Use bulk loading features with smaller commit sizes
Select appropriate shape for your transaction patterns
Consider upgrading shape if hitting limits regularly

5. HeatWave Cluster Operations and HA Changes

Limitation: If a HeatWave cluster load or reload operation is ongoing, enabling or disabling high availability can fail.

Why This Happens:

HeatWave cluster operations lock resources during data loading
HA changes require cluster reconfiguration
Concurrent operations can cause conflicts

Best Practice:

Wait for HeatWave operations to complete before HA changes
Monitor HeatWave operation status
Schedule HA changes during maintenance windows
Avoid simultaneous infrastructure and data operations

6. HeatWave Lakehouse Compatibility

Previous Limitation: Prior to MySQL 8.3.0-u2, you could not enable high availability on a DB system with HeatWave Lakehouse enabled.

Current Status: This limitation has been lifted in MySQL 8.3.0-u2 and later versions.

Upgrade Path:

Systems on older versions must upgrade to use HA with Lakehouse
After upgrade, both features can coexist
On OCI, full support is available
On AWS, HeatWave features remain unsupported on HA systems

7. Platform-Specific Limitations

MySQL HeatWave on AWS

On AWS, MySQL HeatWave Clusters and features requiring a cluster (MySQL HeatWave Lakehouse, GenAI, AutoML) are not currently supported on high availability DB systems.

Impact:

HA systems on AWS are limited to OLTP workloads
Analytics features require standalone systems
Must choose between HA and advanced analytics on AWS

Query PrivateLink Considerations

When using Query PrivateLink endpoints, failovers and switchovers take longer than on public endpoints.

Mitigation:

Set connect_timeout to small value (e.g., 5 seconds)
Implement aggressive connection retry logic
Monitor failover times
Consider public endpoints for latency-sensitive applications

8. Configuration and Infrastructure Limitations

Bulk Ingest: The Bulk Ingest feature is not supported on high availability DB systems.

Alternative: Use standard data loading methods like LOAD DATA INFILE or MySQL Shell utilities.

PrivateLink Management: High availability cannot be enabled or disabled on a DB system with PrivateLink(s) configured.

Workaround: Delete PrivateLinks, make HA changes, then recreate PrivateLinks.

9. Rolling Restart for Configuration Changes

Behavior: When updating configuration of a high availability DB system that changes only dynamic variables, a rolling restart is performed, which shortens downtime and causes a change in current primary placement.

What Happens:

Configuration updated on primary instance
Controlled failover to secondary instance
Original primary updated and becomes secondary
System automatically rebalances if needed
HeatWave data reloaded automatically if cluster attached

Implications:

Brief connection interruption during rolling restart
Current placement may differ from preferred placement
Applications must handle reconnections
HeatWave queries may be briefly unavailable during reload

Best Practices for HA DB Systems

1. Application Design

Connection Management

Implement exponential backoff for reconnection attempts
Use connection pooling with health checks
Set appropriate timeout values
Handle transient errors gracefully

Transaction Design

Keep transactions small and fast
Avoid long-running transactions that span minutes
Break large data modifications into batches
Monitor transaction sizes against shape limits

2. Monitoring and Alerting

Key Metrics to Monitor

Replication lag between primary and secondary instances
Storage utilization and growth trends
Transaction throughput and latency
Failover events and frequency
Backup success rates

Set Up Alerts For

Failover events
High replication lag
Storage approaching limits
Backup failures
Configuration change events

3. Testing and Validation

Regular Testing

Perform manual switchovers during maintenance windows
Test application behavior during failovers
Validate backup and restore procedures
Verify monitoring and alerting systems

Chaos Engineering

Simulate instance failures
Test network partition scenarios
Validate automatic recovery mechanisms
Document recovery procedures

4. Maintenance Planning

Scheduling

Plan configuration changes during low-traffic periods
Coordinate with application teams for maintenance windows
Avoid changes during critical business periods
Document rollback procedures

Pre-Change Validation

Test configuration changes in non-production first
Verify compatibility with HA requirements
Ensure backups are current
Have rollback plan ready

5. Cost Optimization

Resource Planning

Start with appropriate shape size
Monitor utilization with Autopilot Shape Advisor
Adjust shapes based on actual workload patterns
Balance performance needs with cost constraints

Backup Management

Set retention periods based on compliance requirements
Use regional backup copies only when needed
Enable backup validation selectively
Clean up old backups per policy

When NOT to Use High Availability

While high availability is excellent for many use cases, it may not be appropriate when:

Development/Testing: Standalone systems are more cost-effective
Analytics-Heavy on AWS: HA doesn't support HeatWave features on AWS
Very Large Transactions: Shape memory limits may be restrictive
Budget Constraints: HA requires 3x compute resources vs standalone
Read-Heavy Workloads: Read replicas might be more appropriate than HA

Alternative High Availability Strategies

If MySQL HeatWave HA limitations are too restrictive:

Read Replicas for Read Scaling

Distribute read traffic across multiple instances
Works with both standalone and HA systems
Up to 10 read replicas per DB system
Better for read-heavy workloads

Multi-Region Deployment

Deploy separate DB systems in different regions
Use application-level failover logic
Replicate data using MySQL replication channels
Provides geographic redundancy

Hybrid Architectures

Use HA for OLTP workloads
Separate standalone system with HeatWave for analytics (AWS)
Replicate data between systems using channels
Best of both worlds but adds complexity

Conclusion

MySQL HeatWave high availability provides enterprise-grade fault tolerance with automatic failover, data protection, and minimal downtime. Understanding the limitations—particularly around rolling upgrades, transaction sizes, and platform-specific constraints—is essential for designing robust database architectures.

By following best practices for application design, monitoring, and maintenance, you can build resilient systems that meet stringent uptime requirements while staying within the boundaries of high availability limitations.

The key is matching your requirements to the capabilities: if you need maximum uptime for OLTP workloads with automatic failover, MySQL HeatWave HA is an excellent choice. If you need advanced analytics features on AWS or have very specific requirements, consider alternative architectures that better fit your needs.

Additional Resources:

Oracle Cloud Infrastructure: Compartment Quotas and Service Limits Management

Thu, 16 Oct 2025 08:19:31 +0000

Oracle Cloud Infrastructure provides powerful resource management capabilities through service limits and compartment quotas, enabling organizations to control consumption, manage costs, and ensure resource availability across their cloud deployments. Understanding these mechanisms is essential for effective cloud governance and financial management.

Understanding Service Limits

What are Service Limits?

Service limits are resource allowances that limit what resources you can use in your tenancy. They are established when you create your tenancy, but can be changed on request.

Key Characteristics:

Oracle-Defined: Service limits are set by Oracle based on your subscription
Tenancy-Wide: Apply across your entire OCI tenancy
May Change Automatically: Can be adjusted based on subscription changes or upgrades
Request-Based Modification: Can be increased by submitting service limit increase requests

Service Limit Scope:

Per Availability Domain: Some limits apply to individual availability domains
Per Region: Other limits apply to entire regions
Per Tenancy: Global limits apply across all regions
Resource-Specific: Some limits are specific to individual resources (e.g., one NAT Gateway per VCN)

Purpose of Service Limits

Cost Protection:
Protect you from unplanned surges in consumption and cost by ensuring your users can only use the amount of resources you have predefined.

Resource Availability:
Inform Oracle of the resources you need to run your workload so those resources are always available to you.

Capacity Management:
Help Oracle plan and provision infrastructure capacity based on customer requirements.

Understanding Compartment Quotas

What are Compartment Quotas?

Compartment quotas are policies that allow administrators to allocate resources to specific compartments with a high level of flexibility. Similar to service limits, the biggest difference is that service limits are set by Oracle, and compartment quotas are set by customer administrators using policy statements.

Key Characteristics:

Customer-Controlled: Administrators define and manage quotas
Flexible Allocation: High level of flexibility in resource distribution
Policy-Based: Set using declarative policy statements
Compartment-Specific: Apply to individual compartments or compartment hierarchies

Service Limits vs. Compartment Quotas

Service Limits:

Set by Oracle based on your subscription
Apply at tenancy or regional level
Require support requests to modify
Define maximum capacity available

Compartment Quotas:

Set by customer administrators
Apply at compartment level
Modified through policy statements
Define resource allocation within available service limits

Relationship:
Compartment quotas cannot exceed service limits—they subdivide available capacity within the limits Oracle has set for your tenancy.

Compartment Fundamentals

What are Compartments?

Compartments help you organize and isolate your cloud resources, providing logical containers for grouping and managing OCI resources.

Compartment Hierarchy:

Root Compartment: Your tenancy is the root compartment
Nested Structure: Compartments can go six levels deep
Policy Inheritance: Child compartments inherit policies from parent compartments
Organizational Flexibility: Structure compartments by department, environment, project, or any organizational need

Compartment Use Cases

Organizational Structure:

Separate compartments for different business units
Development, testing, and production environments
Project-based resource isolation
Geographic or regional separation

Access Control:

Role-based access through IAM policies
Separation of duties across teams
Fine-grained resource permissions
Audit and compliance boundaries

Cost Management:

Cost center allocation and tracking
Budget management per compartment
Chargeback and showback reporting
Resource usage monitoring

Quota Policy Statements

Three Types of Quota Policies

Compartment quotas are set using policy statements written in a simple declarative language that is similar to the IAM policy language.

1. SET Statement:
Sets the maximum number of a cloud resource that can be used for a compartment.

Syntax:

set <service-family> quota <quota-name> to <value> in compartment <compartment-name>

Example:

set compute-core quota standard-e4-core-count to 240 in compartment MyCompartment

This limits the MyCompartment to using a maximum of 240 OCPUs for Standard.E4 compute shapes.

2. UNSET Statement:
Resets quotas back to the default service limits, removing any custom restrictions.

Syntax:

unset <service-family> quota <quota-name> in compartment <compartment-name>

Example:

unset database quota atp-dedicated-ecpu-count in tenancy

This removes any custom quota limits for ATP dedicated ECPUs, reverting to service limits.

3. ZERO Statement:
Removes access to a cloud resource for a compartment, completely blocking resource usage.

Syntax:

zero <service-family> quotas in compartment <compartment-name>

Example:

zero email-delivery quotas in compartment TestCompartment

This prevents any email delivery service usage in TestCompartment.

Quota Scope Options

Quotas can have different scopes depending on the resource type and administrative requirements:

Availability Domain Scope:
Quota applies to a specific availability domain within a region.

Example:

set compute-core quota standard-e4-core-count to 240 in compartment MyCompartment where request.ad = 'US-ASHBURN-AD-1'

Regional Scope:
Quota applies to a specific region.

Example:

set compute-core quota standard-e4-core-count to 240 in compartment MyCompartment where request.region = 'us-phoenix-1'

Global/Tenancy Scope:
Quota applies across all regions and availability domains.

Example:

set compute-core quota standard2-core-count to 240 in tenancy

Important Note: When setting a quota with availability domain scope without specifying a specific AD, the quota is allocated to EACH availability domain.

Fleet Administrator Role in Dedicated Infrastructure

Dedicated Infrastructure Management

In Autonomous Database Dedicated Infrastructure deployments, fleet administrators manage both service limits and compartment quotas.

Fleet Administrator Responsibilities:

Service Limit Management: Request and track service limit increases
Quota Policy Creation: Define and implement compartment quotas
Capacity Planning: Monitor usage and plan for growth
Budget Management: Control costs through quota allocation
Resource Distribution: Allocate resources across compartments

Dedicated Infrastructure Quotas:
Fleet administrators can set quotas for:

ECPUs for Autonomous Data Warehouse (ADW) dedicated deployments
ECPUs for Autonomous Transaction Processing (ATP) dedicated deployments
Total data storage for dedicated autonomous databases
Autonomous VM Clusters (AVMC)
Autonomous Container Databases (ACD)

Viewing Limits, Quotas, and Usage

Cloud Console Access

Navigation:
Tenancy limits, quotas, and usage can be viewed using the Oracle Cloud Console.

Access Path:

Navigate to Governance & Administration
Under Tenancy Management, select Limits, Quotas and Usage

Console Features:

View current service limits for all services
Monitor resource usage against limits
Track quota policies and their impact
Request service limit increases
Create quota policy stubs automatically

Information Available

Service Limits:

Current limits for each service
Scope (availability domain, region, tenancy)
Available vs. used resources
Limit increase history

Compartment Quotas:

Active quota policies
Quota policy statements
Affected compartments
Usage against quotas

Usage Metrics:

Current resource consumption
Historical usage trends
Utilization percentages
Capacity planning projections

Creating and Managing Quotas

Automatic Policy Generation

Console Workflow:
Compartment quotas are available on the Console's Limits, Quotas and Usage page, which you can use to automatically generate quota statements.

Steps:

Navigate to Limits, Quotas and Usage page
Select the service, scope, resource, or compartment
In the table, select the Actions menu (three dots)
Select Create Quota Policy Stub
System automatically generates appropriate quota policy statement
Review and customize the generated statement
Create the policy in the Quota Policies section

Manual Policy Creation

Prerequisites:
Ensure you have appropriate permissions to create quotas through IAM policies.

Required Permission:

Allow group QuotaAdministrators to manage quota-policies in tenancy

Policy Creation Steps:

Navigate to Governance & Administration > Quota Policies
Click Create Quota Policy
Provide policy name and description
Enter quota statements using declarative syntax
Specify target compartment
Review and create

Sample Quota Policies

Autonomous Database Example:

set database quota atp-dedicated-ecpu-count to 40 in compartment MyCompartment
set database quota adw-dedicated-ecpu-count to 80 in compartment MyCompartment
set database quota atp-serverless-ecpu-count to 20 in compartment DevCompartment

Compute Resources Example:

set compute-core quota standard-e4-core-count to 100 in compartment Production
set compute-core quota standard2-core-count to 50 in compartment Testing
zero compute-core quotas in compartment Archived

Regional Quota Example:

set compute-core quota standard-e4-core-count to 240 in compartment MyCompartment where request.region = 'us-phoenix-1'
set compute-core quota standard-e4-core-count to 120 in compartment MyCompartment where request.region = 'us-ashburn-1'

Block Storage Example:

set block-storage quota volume-count to 100 in compartment Production
set block-storage quota total-storage-gb to 50000 in compartment Production

Best Practices for Quota Management

Planning and Design

Compartment Structure:
Design compartment hierarchy before implementing quotas to ensure logical resource allocation.

Quota Hierarchy:
Remember that quotas set at a parent compartment level limit resource use for that compartment and all of its children.

Parent Quota Calculation:
When setting quotas for parent compartments, include usage in child compartments to avoid unexpected restrictions.

Scope Selection:
Identify the scope of compartment quotas (availability domain, regional, or global) based on workload requirements.

Capacity Management

Growth Planning:

Leave room for growth when setting quotas
Monitor usage trends and adjust quotas proactively
Plan for seasonal or cyclical demand variations
Consider disaster recovery capacity requirements

Failover Consideration:
Ensure sufficient gap between current service limit and maximum usage to accommodate failover scenarios—failed resources may count against limits until successfully terminated.

Monitoring:

Regular review of quota utilization
Automated alerts for approaching quota limits
Trending analysis for capacity planning
Documentation of quota changes and justification

Cost Control

Budget Alignment:
Along with compartment budgets, compartment quotas create a powerful toolset to manage spending in OCI tenancies.

Cost Protection:

Set quotas to prevent unexpected cost overruns
Align quotas with approved budgets
Review and adjust quotas during budget cycles
Monitor actual spending against quota allocations

Resource Optimization:

Identify underutilized quotas for reallocation
Optimize quota distribution based on actual usage
Implement zero quotas for inactive compartments
Regular audit of quota efficiency

Service Limit Increases

Requesting Limit Increases

When to Request:

Approaching current service limits
Planning major deployments or migrations
Disaster recovery capacity needs
Business growth requirements

Request Process:

Navigate to Limits, Quotas and Usage
Find the service and resource requiring increase
Click Request a Service Limit Increase
Provide justification and required limit
Submit request for Oracle review
Track request status in console

Best Practices:

Request increases well in advance of need
Provide clear business justification
Document capacity planning assumptions
Keep records of all limit increase requests

Fixed Service Limits

Unchangeable Limits:
Be aware that some resources have fixed, unchangeable service limits that might impact your applications.

Examples:

Maximum 5 security lists per subnet
Maximum 500 policy statements per tenancy (hard limit)
One NAT Gateway per VCN
Specific API rate limits

Mitigation Strategies:
Make appropriate architectural adjustments when fixed limits impact design:

Use Network Security Groups in addition to security lists
Implement Tag-Based Access Control (TBAC) to reduce policy statement count
Design around fixed limits rather than requesting increases

Advanced Quota Scenarios

Multi-Environment Management

Development, Testing, Production:

# Production - highest allocation
set compute-core quota standard-e4-core-count to 500 in compartment Production

# Testing - moderate allocation
set compute-core quota standard-e4-core-count to 200 in compartment Testing

# Development - limited allocation
set compute-core quota standard-e4-core-count to 100 in compartment Development

# Archived - no allocation
zero compute-core quotas in compartment Archived

Department-Based Allocation

Organization Structure:

# Finance department
set compute-core quota standard-e4-core-count to 300 in compartment Finance
set database quota atp-serverless-ecpu-count to 50 in compartment Finance

# Engineering department
set compute-core quota standard-e4-core-count to 600 in compartment Engineering
set database quota atp-serverless-ecpu-count to 100 in compartment Engineering

# Marketing department
set compute-core quota standard-e4-core-count to 150 in compartment Marketing

Geographic Distribution

Regional Allocation:

# US East operations
set compute-core quota standard-e4-core-count to 400 in compartment USEast where request.region = 'us-ashburn-1'

# US West operations
set compute-core quota standard-e4-core-count to 400 in compartment USWest where request.region = 'us-phoenix-1'

# Europe operations
set compute-core quota standard-e4-core-count to 200 in compartment Europe where request.region = 'eu-frankfurt-1'

Monitoring and Troubleshooting

Quota Monitoring

Usage Tracking:

Regular review of quota utilization in console
Automated alerts for quota thresholds (80%, 90%, 95%)
Trending analysis for forecasting
Integration with budget monitoring

Common Issues:

Quota limits blocking legitimate resource provisioning
Misconfigured quota statements preventing operations
Parent compartment quotas unintentionally restricting children
Quota and budget misalignment causing confusion

Troubleshooting Steps

Resource Provisioning Failures:

Check service limits first
Verify compartment quotas
Review parent compartment quotas
Validate scope (AD, region, tenancy)
Confirm IAM permissions

Quota Policy Errors:

Validate syntax using policy stub generator
Check service family names in documentation
Verify quota names are correct
Ensure target compartment exists
Confirm proper IAM permissions for policy creation

Conclusion

Oracle Cloud Infrastructure's service limits and compartment quotas provide comprehensive resource governance capabilities, enabling organizations to control costs, manage capacity, and ensure resource availability while maintaining operational flexibility.

Key Takeaways:

Service Limits:

Oracle-defined resource allowances at tenancy level
Can be increased through support requests
Define maximum capacity available
Apply at various scopes (AD, region, tenancy)

Compartment Quotas:

Customer-defined resource allocation within service limits
Set using flexible policy statements
Enable fine-grained resource control
Support organizational and cost management objectives

Management Approach:

Design compartment structure before implementing quotas
Use quota policy stub generator for accuracy
Monitor usage and adjust quotas proactively
Combine with budgets for comprehensive cost management
Document quota policies and changes

Fleet Administrator Role:
In dedicated infrastructure deployments, fleet administrators manage both service limits and compartment quotas, providing centralized governance while enabling self-service provisioning within defined boundaries.

By effectively leveraging service limits and compartment quotas, organizations can optimize resource utilization, control costs, and ensure that critical workloads always have the capacity they need while preventing unexpected consumption and spending overruns.