01
Performance Tuning
Top SQL, plan stability, statistics, indexing, memory and I/O. We check which diagnostic packs your license covers before using AWR or ASH, and use Statspack or SQL trace where it does not.
Oracle Database Consulting
Oracle Database consulting: tuning, high availability, upgrades and exit
Last reviewed by Tyler Eastridge
AceMQ delivers Oracle consulting services with partner Oracle specialists: performance tuning, high availability and disaster recovery with Data Guard and RAC, upgrades to 19c and 26ai, license-aware architecture, and an exit assessment that tells you which databases could move to PostgreSQL. It covers the database engine only, not E-Business Suite, Fusion or other Oracle applications. Every project starts with a written plan.
- 19c Premier Support ends, per Oracle
- 31 Dec 2029
- 19c Extended Support ends, per Oracle
- 31 Dec 2032
- min emergency SLA once you add support
- 15
Is This You?
You probably need this if…
- 01
A critical report or batch has slowed down and nobody can say what changed
- 02
You run 12c or 18c and have not planned the move to 19c
- 03
You run 19c and want a considered plan for 26ai, or for staying put
- 04
Your disaster recovery plan exists on paper but has never been rehearsed
- 05
The Oracle bill keeps rising and nobody knows which options and packs are actually used
- 06
A board or architect is asking which databases could leave Oracle, and nobody has a classified list
- 07
You need an outside Oracle opinion before a change board will approve a project
Outcomes
Where you are now, and where you end up
Concrete state changes, not deliverable counts. This is what actually differs about your Oracle Database estate when the engagement closes.
Before
Performance work is guesswork: parameters changed one at a time, and nobody records what helped.
After
A ranked list of the SQL and waits that cost the most, with a tested change for each and a way to prove it worked.
Before
The upgrade is described as a weekend and has no rollback story.
After
A rehearsed path with a fallback at each step, using Oracle's AutoUpgrade tool, and a clear statement of what the downtime window is.
Before
High availability is whatever was installed years ago.
After
A design that matches your recovery targets, with RAC, Data Guard or both chosen for stated reasons, and a failover runbook someone has run.
Before
Licensing is discovered during an audit.
After
A map of which features each database uses against the edition you hold, and an architecture that does not use extra-cost options by accident.
Scope
What's covered
- 02
High Availability and Disaster Recovery
RAC, Data Guard or both, sized to recovery point and recovery time targets: protection mode, standby redo logs, Fast-Start Failover, and a failover rehearsal.
- 03
Upgrades to 19c and 26ai
Release assessment, AutoUpgrade plan, non-CDB to multitenant conversion where the target needs it, rehearsal on a copy, and a fallback at each step.
- 04
License-Aware Architecture
A feature-usage inventory per database, the edition and options each design implies, and alternatives that meet the requirement without an extra-cost option. Not legal advice and not a replacement for your Oracle agreement.
- 05
Exit Assessment to PostgreSQL
A classified list of databases by Oracle-specific dependency, a proof-of-value recommendation on one database, and a plain answer on which should stay on Oracle.
- 06
Backup, Recovery and Security Design
RMAN strategy, restore testing, encryption, privilege and audit design, matched to your compliance requirements.
- 07
Consolidation and Multitenant
Whether to consolidate databases as pluggable databases, what the three-PDB license allowance covers, and what changes for patching and backup.
- 08
Health Check
The fixed-scope review that finds the first problem: a written report ranked by production risk that your team can act on alone.
- 09
Knowledge Transfer
Runbooks and working sessions with your DBAs, so the result outlasts the engagement.
The Engagement
How it actually runs
Every phase has a defined duration and a concrete artifact handed over at the end of it. You always know what stage you're in and what you've received.
- Phase 1Scoped per estate
Assessment
Inventory of releases, editions, options in use, topology, backup and standby state, and the workload. Written findings, ranked by risk, before anything changes.
You receive
- Inventory of databases, releases and features used
- Ranked findings with owners
- Recommended project scope
- Phase 2Scoped per project
Design
The plan for the work chosen: upgrade path, HA and DR design, tuning changes or exit classification, each with a rollback or fallback.
You receive
- Written design and runbooks
- Rollback plan per step
- Test and acceptance criteria
- Phase 3Scoped per project
Rehearsal and build
The change is run on a copy that mirrors production, including the fallback, so the production window holds no first attempts.
You receive
- Rehearsed procedure
- Measured downtime for each step
- Known issues checked against your configuration
- Phase 4Planned change window
Cutover and handover
AceMQ and your DBAs run the production change together, then hand over runbooks and monitoring, with optional 24/7 support afterwards.
You receive
- Change completed and verified
- Updated runbooks
- Optional move to 24/7 support
Oracle Database upgrade to 19c or 26ai: which paths are direct
Oracle's Upgrade Guides list which source releases can upgrade directly to each target. Anything not on the list needs an intermediate release first, which is where plans that say "upgrade over a weekend" usually break.
| Target | Direct upgrade from | Needs an intermediate step |
|---|---|---|
| Oracle Database 19c | 11.2.0.4, 12.1.0.2, 12.2.0.1 and 18c (all releases) | Anything earlier than 11.2.0.4, and 12.1.0.1 or 11.2.0.1 to 11.2.0.3 |
| Oracle AI Database 26ai | 19c (all releases) and 21c | 18c and every 12.x or 11.x release: a supported intermediate release first (usually 19c) |
Oracle's upgrade documentation for the 23ai and 26ai line says a non-CDB database has to become a pluggable database in a container database as part of the upgrade, so a 19c non-CDB estate carries a multitenant conversion with it. Oracle names AutoUpgrade and Replay Upgrade as the supported tools. We plan the conversion, rehearse it, and keep the platform change and the version change in separate windows.
Rule we hold
Never combine a platform change with a version upgrade in one production window. Moving hardware or storage, converting to multitenant and raising the release are three changes, each with its own fallback.
RAC, Data Guard or both: matching the design to the failure
RAC and Data Guard protect against different failures, and buying one in the hope that it covers the other is the most common design gap. RAC keeps the database up through the loss of a server. Data Guard keeps a copy on separate storage in another place, so it survives the loss of storage or a site, and gives you a recovery path from some kinds of corruption.
| Failure | RAC | Data Guard | Notes |
|---|---|---|---|
| A database server fails | Survives: the surviving instances keep serving | Fails over to the standby | RAC avoids the failover and reconnect |
| The storage array fails | Does not survive unless storage is mirrored across arrays: the instances share it | Survives: the standby has its own storage | RAC alone is not disaster recovery |
| The site is lost | Does not survive | Survives, if the standby is elsewhere | Distance and protection mode set how much you can lose |
| Rolling patch of one node | Helps: patch node by node | Standby-first patching is possible | Both lower the change window |
| Standard Edition 2 | Not available in Oracle's SE2 feature table | Not available in Oracle's SE2 feature table | SE2 estates use other designs |
Both RAC and Data Guard are Enterprise Edition features; Oracle's licensing manual lists them as unavailable on Standard Edition 2, and Active Data Guard and RAC are extra-cost options on Enterprise Edition. That makes edition a design input, not a detail. For Standard Edition 2 the 19c release offers Standard Edition High Availability for failover within a site, and disaster recovery is built with backups and other tools. We design for the edition you hold or tell you what moving editions would cost to do properly.
Oracle Database license-aware architecture: what the design implies
The design decides the license. A feature enabled for convenience can create an obligation, and the bill follows the design, not the other way round. These are the list prices Oracle publishes, to show how much a design choice can matter.
| Item | License | Annual update and support |
|---|---|---|
| Standard Edition 2 | $17,500 | $3,850 |
| Enterprise Edition | $47,500 | $10,450 |
| Real Application Clusters (option) | $23,000 | $5,060 |
| Active Data Guard (option) | $11,500 | $2,530 |
| Diagnostics Pack | $7,500 | $1,650 |
| Tuning Pack | $5,000 | $1,100 |
| Partitioning (option) | $11,500 | $2,530 |
| Multitenant (option) | $17,500 | $3,850 |
List price is not what most customers pay, and the figures exclude the processor core factor and Named User Plus minimums that decide how many licenses a server needs. The point is the relative size: an Enterprise Edition option can cost a quarter or a half of the base license. We inventory which features each database really uses and design so that extra-cost options are chosen on purpose.
What we do not do
AceMQ does not resell Oracle licenses, negotiate with Oracle or give legal advice on your agreement. We show what your databases use and what a design implies. Your contract decides what you owe.
Exit assessment: which Oracle databases could move to PostgreSQL
An exit assessment is a decision document, not a migration. It sorts the estate by how much each database depends on Oracle-specific features, so the cost of the move can be estimated database by database and the ones that should stay are named.
| Area | What we look for | Why it matters |
|---|---|---|
| Procedural code | PL/SQL packages, triggers and their size | Logic inside the database is the hardest part to move |
| Oracle-specific features | Advanced Queuing, Spatial, Text, database links, materialized views | Each needs an equivalent or a redesign |
| Scheduling and jobs | DBMS_SCHEDULER jobs and external dependencies | Jobs often hide cross-database dependencies |
| Data types and SQL | Oracle-specific types, hints, sequences, synonyms | Drives how much code needs rewriting |
| Operations | Backup, HA, monitoring and the team's PostgreSQL experience | A move changes who can run it at 3am |
We recommend a proof of value on one database before anyone commits to a program, and we say so when the right answer is to stay on Oracle. The thinking behind classifying a large estate is in a separate article.
Where this service is not a fit
- Oracle applications — E-Business Suite, Fusion, HCM, ERP and other Oracle applications are out of scope. This is database consulting. We can work on the database tier underneath an application.
- License negotiation — AceMQ does not resell Oracle licenses, negotiate with Oracle or defend an audit.
- Application code — We tell you which SQL and settings to change. Your developers make the change, or we work with them.
- Exadata and OCI — Estates on Exadata or Oracle Cloud Infrastructure are scoped case by case.
- Small estates with a good DBA — A single healthy database run by a capable DBA may need only a health check.
Typical engagements
How these engagements run
Typical engagement scenarios: what the work covers and what it delivers. They describe the service, not past results.
Oracle to PostgreSQL Assessment and Proof of Value
Regional Insurer
A typical engagement for a team weighing an exit from Oracle: classify every object by conversion effort, then convert and test one representative database before committing to the rest.
PostgreSQLOracle DatabaseOra2PgAWS DMS
Debezium Oracle LogMiner Lag Remediation
Regional Retail Bank
Bringing an Oracle change data capture pipeline back inside its batch window after nightly jobs left the Debezium connector hours behind the source.
DebeziumOracle
Kafka
KubernetesDebezium MySQL Binlog Retention and Schema History Support
Online Travel Platform
Ongoing support for a MySQL change data capture pipeline that needed a full re-snapshot after a planned outage outlasted binlog retention and a trimmed schema history topic.
Debezium
MySQLSQL ServerOracle DatabaseKafka
Amazon RDS
Oracle Data Guard Failover Readiness Review
Regional Insurer
A typical engagement to find out whether an Oracle Data Guard standby will really take over: transport and apply lag, protection mode, redo sizing, failover runbooks and client reconnection.
Oracle DatabaseData GuardRMANLinuxOracle 19c to 26ai Upgrade Planning
Industrial Manufacturing Group
A typical engagement to decide whether Oracle databases should stay on 19c or move to 26ai, and to plan the multitenant conversion, AutoUpgrade run and rollback for the ones that move.
Oracle DatabaseAutoUpgradeMultitenantLinux
Remote Oracle DBA Cover for a Small Platform Team
SaaS Platform Team
A typical engagement where a lean platform team adds remote Oracle DBA cover: on-call, restore testing, patch windows and a monthly review, without hiring a second DBA.
Oracle DatabaseRMANPrometheusLinux
FAQ
Questions about Oracle Database consulting
What does Oracle Database consulting from AceMQ include?
Performance tuning, high availability and disaster recovery design with Data Guard and RAC, upgrades to 19c and 26ai, license-aware architecture, backup and security design, and an exit assessment for moving databases to PostgreSQL. It is delivered by AceMQ engineers with partner Oracle specialists, and every project starts with a written plan. It covers the database engine, not Oracle applications such as E-Business Suite or Fusion.
Can you upgrade us from Oracle 12c or 18c to 19c?
Yes, as a planned project. Oracle supports direct upgrade to 19c from 11.2.0.4, 12.1.0.2, 12.2.0.1 and 18c, so most estates have a direct path. AceMQ assesses the release and options in use, plans the upgrade with AutoUpgrade, rehearses it on a copy of production and keeps a fallback at each step.
Should we go to 26ai or stay on 19c?
It depends on dates and requirements, not fashion. Oracle's policy gives 19c Premier Support to 31 December 2029 and Extended Support to 31 December 2032, and 26ai Premier Support to December 2031. Moving to 26ai from 19c needs non-CDB databases converted to multitenant. We lay out both paths against your lifecycle, application certification and team capacity, and recommend one.
Can you move our Oracle databases to PostgreSQL?
AceMQ starts with an exit assessment: a classified list of databases by Oracle-specific dependency, a proof-of-value recommendation on one database, and a plain view on which should stay on Oracle. That decides whether and how to commit to a program. We make no promise of timelines or cost before the assessment.
Do you consult on Oracle E-Business Suite or Fusion?
No. This service is Oracle Database only. If an application such as E-Business Suite runs on the database, we can work on the database tier, such as tuning, backups and upgrades of the database release, with the application team owning anything above it.
Let's talk
Scope an Oracle Database Project
Tell us your Oracle Database releases and editions, whether you run RAC or Data Guard, and what you want to change. We reply within 1 hour and follow with a written scope.
Get in Touch
Talk to an Oracle Database Expert
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.com66 W. Flagler St. 9th Floor
Miami, FL 33130
Miami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.