ORACLE / SKILLS · GITHUB

Oracle Skills GitHub Repository

The Future of AI-Assisted Oracle DBA Operations

Oracle Skills is a practical GitHub repository designed to help DBAs, developers, and AI agents use structured, source-backed Oracle knowledge for real-world database operations.

Visit Official GitHub Repository

What is Oracle Skills?

Oracle Skills is a curated collection of practical, installable skills for Oracle technologies. It provides reusable guidance for database administration, SQL development, performance tuning, security, monitoring, migrations, DevOps, Oracle Cloud, APEX, Fusion, and GraalVM.

Official Repository:
https://github.com/oracle/skills

Why This Matters for Oracle DBAs

Traditionally, DBAs depend on MOS notes, internal SOPs, SQL scripts, documentation, and personal experience. Oracle Skills introduces a structured model where AI assistants and automation tools can use predefined, version-aware Oracle guidance.

This helps DBAs troubleshoot faster, reduce repeated manual effort, and create more consistent operational workflows.

Key Skill Domains

Domain	Purpose
Admin	Startup, backup, RMAN, patching, tablespaces, maintenance
Performance	AWR, ASH, SQL tuning, wait events, execution plans
Security	Auditing, privileges, encryption, hardening
Monitoring	Database health checks, alerts, diagnostics
Migrations	Upgrade planning, migration approach, cross-version guidance
DevOps	CI/CD, automation, database lifecycle workflows
OCI	Oracle Cloud Infrastructure related operations
APEX / ORDS	Application development and REST services guidance

Simple Example

Instead of manually searching documentation or creating SQL from scratch, a DBA can ask an AI assistant:

Find top SQL statements consuming CPU in the database.

The AI assistant can then use the relevant Oracle skill to provide more accurate and structured guidance.

Installation Example

# Install Oracle Database skills
npx skills add oracle/skills/db

# Install GraalVM skills
npx skills add oracle/skills/graal

How This Helps Oracle EBS DBAs

For Oracle E-Business Suite DBAs, the same concept can become very useful for structured troubleshooting and operational runbooks.

ADOP troubleshooting
Concurrent Manager checks
Workflow Mailer validation
Invalid object analysis
Tablespace growth monitoring
Database performance diagnostics
Patch readiness validation
Data Guard and DR checks

Important Point:

AI will not replace strong Oracle fundamentals. But DBAs who combine Oracle knowledge, automation, cloud, and AI-assisted workflows will become more productive and valuable.

Future DBA Skillset

Oracle Database fundamentals
Performance tuning and troubleshooting
Backup, recovery, and DR knowledge
Cloud and automation skills
AI-assisted database operations
Reusable SOP and runbook creation

My Final Thoughts

Oracle Skills is not just another GitHub repository. It represents the direction in which Oracle database operations are moving — structured, source-backed, reusable, and AI-assisted.

For Oracle DBAs, Apps DBAs, Cloud DBAs, and developers, this is the right time to explore how AI-assisted skills can improve daily database operations.

Official Reference

Oracle Skills GitHub Repository

Written by Punit Kumar | Oracle DBA | Oracle EBS DBA | Cloud & AI Learning Journey
punitoracledba.blogspot.com

CPU, OCPU and ECPU Explained in Simple Words

If you are moving Oracle Database from on-premises to Oracle Cloud Infrastructure, this is one concept you must understand clearly.

During Oracle Database cloud migration, many teams get confused with three words: CPU, OCPU and ECPU.

On-premises servers normally talk in terms of CPU cores. Oracle Cloud Infrastructure uses OCPU for many database services and ECPU for Autonomous Database. If we do not understand the difference, we may oversize the cloud database, increase cost, or undersize it and create performance issues.

1. The Golden Rule to Remember

1 Physical CPU Core = 1 OCPU = 2 vCPUs = 2 ECPUs

This is the most important line to remember. In simple words:

CPU Core is the on-premises language.
OCPU is the normal OCI database compute language.
ECPU is mostly used with Autonomous Database.
1 OCPU = 2 ECPUs.

10 physical cores = 10 OCPUs = 20 ECPUs

2. CPU vs OCPU vs ECPU

Term	Where Used	Simple Meaning	Easy Memory
CPU	On-premises server	Physical processor core in your server	Traditional server world
OCPU	OCI Base DB, ExaCS, ExaCC	Oracle Cloud Processing Unit	1 OCPU = 1 physical core
ECPU	Autonomous Database	Elastic CPU	1 ECPU = half OCPU

3. Do Not Copy On-Prem CPU Count Blindly

Common mistake: “We have 10 CPU cores on-premises, so let us provision 10 OCPUs in OCI.”

This approach can be costly. Your on-premises server may have 10 cores, but it may not be using all 10 cores all the time. In many production databases, CPU usage may be around 50% to 70% during normal workload, with higher peaks during batch jobs, month-end processing, or reporting.

The better approach is to check real workload data from AWR and ASH reports. Size based on actual peak CPU usage, not just the number of cores installed on the physical server.

4. Simple Sizing Formula

Use this easy formula:

OCPUs Needed = Peak CPU Usage × Physical Cores + 15% to 20% Safety Buffer

Example

Suppose your on-premises database server has:

10 physical CPU cores
Peak CPU usage around 70%
You want to add 20% safety buffer

0.70 × 10 = 7 OCPUs Add 20% buffer: 7 × 1.20 = 8.4 Round up: 9 OCPUs

So instead of blindly provisioning 10 OCPUs, you may start with around 9 OCPUs, validate workload performance, and then adjust if needed.

5. What About ECPU?

If you are moving to Autonomous Database, Oracle uses ECPU. Since 1 OCPU = 2 ECPUs, you simply double the OCPU number.

9 OCPUs = 18 ECPUs

Autonomous Database also supports auto-scaling. This means it can automatically add more ECPUs during workload spikes and scale down when the load reduces.

For ADB: Start with the right base ECPU count, keep auto-scaling enabled, monitor usage, and then right-size.

6. Which OCI Database Service Uses Which Unit?

OCI Database Service	Compute Unit	Best For
Base Database VM	OCPU	Lift-and-shift migrations, full DBA control, predictable workloads
Exadata Cloud Service	OCPU	Large, mission-critical, high-performance databases
Exadata Cloud@Customer	OCPU	Customers who need Exadata performance but must keep data in their data center
Autonomous Database	ECPU	Managed database, auto-scaling, less administration, variable workloads

7. Why More OCPUs or ECPUs Improve Performance

Think of CPU like workers in a kitchen. More workers can handle more orders in parallel. Similarly, more OCPUs or ECPUs allow Oracle Database to process more work at the same time.

Faster queries: More CPU can help large queries run faster using parallel processing.
More concurrent users: More sessions can be served without waiting for CPU.
Shorter batch window: Nightly jobs, reports, and month-end jobs can finish faster.
Better workload handling: More compute gives better room during peak business hours.

8. Exadata Point to Remember

Exadata is different from normal servers because of features like Smart Scan. Smart Scan can offload some work to Exadata storage cells, which means the database server CPU does not have to do all the heavy lifting.

On ExaCS or ExaCC, you may sometimes need fewer OCPUs than a normal server because Exadata architecture can process Oracle workloads more efficiently.

9. Important Checks Before Final Sizing

CPU is only one part of database sizing. Before finalizing your OCI configuration, check the complete picture.

Collect 90 days of AWR/ASH data to understand real peak usage.
Check RAM requirement because CPU alone cannot solve memory pressure.
Check storage IOPS and throughput because many databases are I/O-bound, not CPU-bound.
Understand batch windows such as month-end, payroll, reporting, and large data loads.
Validate Oracle licensing because OCPU count can directly impact license cost.
Add 15% to 20% buffer for growth and unexpected peaks.
Test with real workload before production cutover.

10. Quick Cheat Sheet

On-Premises Situation	OCI Sizing Thought Process	Recommended Check
10 physical cores	Start by mapping to 10 OCPUs or 20 ECPUs	Then reduce or adjust based on AWR peak usage
70% peak CPU usage	10 × 70% = 7 OCPUs	Add 15% to 20% buffer
Steady workload	OCPU-based service may be suitable	Base DB VM, ExaCS, or ExaCC
Variable or bursty workload	ECPU-based ADB may be suitable	Enable auto-scaling and monitor
Mission-critical workload	Consider Exadata options	Evaluate ExaCS or ExaCC

11. Key Takeaways

1 Physical Core = 1 OCPU = 2 ECPUs = 2 vCPUs.
CPU is on-premises language.
OCPU is used for OCI Base DB, ExaCS, and ExaCC.
ECPU is used for Autonomous Database.
Do not copy on-prem CPU count blindly.
Use AWR/ASH reports to check actual peak CPU usage.
Always add 15% to 20% buffer.
Check CPU, memory, storage, IOPS, licensing, and real workload testing.
Right-sizing can save cost and avoid performance problems.

Easy memory line: CPU is on-prem, OCPU is OCI, ECPU is Autonomous DB. 1 OCPU = 2 ECPUs. Always size from AWR peak usage plus 20% buffer.

Conclusion

CPU, OCPU and ECPU look confusing at first, but the concept becomes simple once we remember the conversion rule. The biggest mistake during cloud migration is copying on-premises CPU count directly into OCI sizing.

The right approach is to collect AWR/ASH data, understand real peak usage, add a practical safety buffer, validate licensing, and test with real workload before production cutover.

For DBAs and cloud architects, this understanding is very important because it directly impacts performance, Oracle licensing, and monthly cloud cost.

Database Consultant (Passionate about Database & Cloud Technologies)

Sunday, May 10, 2026