Oracle Consulting, Consultative Support & Remote DBA — Oracle Database, Exadata and Oracle Cloud | MinervaDB

Oracle Consulting That Reads V$VERSION Before It Reads the Marketing

Oracle Database still runs the ledgers, ERPs and billing engines that enterprises cannot afford to get wrong, and the platform has never changed faster. The patching vocabulary changed twice in 2026 (Release Updates, Monthly Recommended Patches, the new CSPU security bundles). "23ai" and "26ai" are the same code line at different RU levels, versioned 23.26.x. Oracle Database 21c has a hard support cliff on 31 July 2027 with no Extended Support behind it, while 19c Premier Support now runs to 31 December 2029. Exadata has become a family of on-premises racks, Exascale pools, ExaDB-D cloud services and Cloud@Customer, and Oracle Cloud now ships inside Azure, AWS and Google data centres.

MinervaDB's Oracle consulting practice treats all of this as engineering, not folklore. Every engagement opens by establishing the exact version and RU level from V$VERSION and DBA_REGISTRY_SQLPATCH, the edition and option footprint from DBA_FEATURE_USAGE_STATISTICS, and the management-pack entitlement from CONTROL_MANAGEMENT_PACK_ACCESS — because querying AWR on an estate that has not licensed the Diagnostics Pack is a licence event, and a consultant who does that has already cost you money. Our Oracle consultants have designed, tuned and operated Oracle Database, RAC, Data Guard, Exadata and OCI estates for FinTech, insurance, retail, telecom and SaaS companies, and we say plainly when the right answer is to stay on Oracle, to move to Oracle Cloud, or to leave.

What Oracle consulting from MinervaDB covers

• Oracle Database 19c, 21c and 26ai on Linux, AIX, Solaris and Windows — Enterprise Edition and Standard Edition 2
• Real Application Clusters, ASM and Grid Infrastructure; Standard Edition High Availability for SE2
• Data Guard, Fast-Start Failover, Active Data Guard, Far Sync and Data Guard per PDB
• Oracle Exadata X11M on-premises, ExaDB-D (ExaCS), ExaDB-XS and Exadata Cloud@Customer
• OCI Base Database, Autonomous Serverless and Dedicated, Database@Azure, @AWS and @Google
• GoldenGate 23ai, Zero Downtime Migration, Data Pump, RMAN, Flashback, Recovery Appliance
• Multitenant CDB/PDB operations, RU/MRP patching, AutoUpgrade to 26ai, non-CDB conversion
• Licence-aware operations: editions, options, packs, BYOL, ECPU and Extended Support economics

Oracle Architecture and Engineering Built From Evidence, Not Folklore

Good Oracle architecture is workload-driven, and so is good Oracle consulting. We start from the numbers the estate already produces — AWR or STATSPACK history, DB time by wait class, redo generation, segment growth, feature usage — and design outward from them: how many PDBs per CDB and under which resource plan, whether the workload needs RAC or is better served by a broker-managed Data Guard pair with Fast-Start Failover, which Exadata form fits, and which OCI service keeps the access your operations team actually needs.

Engineering follows the same discipline. Every parameter change is delivered as exact parameter, current value, proposed value, unit and scope, and states whether it applies online with ALTER SYSTEM or requires a restart. Every patch is applied out of place from a MOS gold image into a new home with the old home kept for rollback, and every RU, upgrade or destructive step is preceded by a guaranteed restore point. Every deliverable is a versioned MinervaDB document your DBAs can execute without us on the call.

-- Exact version and RU level (never trust marketing names: 26ai = 23.26.x)
SELECT banner_full FROM v$version;

SELECT patch_id, patch_type, status, action_time, description
FROM   dba_registry_sqlpatch
ORDER BY action_time;

-- Licensing gate: may we even look at AWR / ASH on this estate?
SHOW PARAMETER control_management_pack_access;   -- NONE | DIAGNOSTIC | DIAGNOSTIC+TUNING

-- Feature-usage baseline delivered in writing before anything changes
SELECT name, detected_usages, currently_used, first_usage_date, last_usage_date
FROM   dba_feature_usage_statistics
WHERE  currently_used = 'TRUE'
AND    name IN ('Partitioning (user)', 'Active Data Guard - Real-Time Query on Physical Standby',
                'In-Memory Column Store', 'Automatic Workload Repository',
                'SQL Tuning Advisor', 'SQL Profile', 'Real Application Clusters (RAC)')
ORDER BY name;

-- Multitenant floor: more than 3 user PDBs per CDB needs the Multitenant option (EE)
SELECT COUNT(*) AS user_pdbs FROM dba_pdbs WHERE pdb_name <> 'PDB$SEED';

What an Oracle consulting architecture engagement delivers

• Documented current state: version, RU, editions, options in use, every non-default parameter and why
• Target-state design: CDB/PDB layout, memory model (HugePages + ASMM), storage and ASM redundancy, HA/DR topology with RPO/RTO per pair
• Patching standard: quarterly RU currency, out-of-place from gold images, datapatch verification per container
• Capacity model for 24 months with growth assumptions written down
• Risk register and staged implementation plan with rollback per phase
• Explicit service boundary: what MinervaDB owns, what your platform team owns, what goes to Oracle Support under your CSI

Platforms and variants we engineer

• Oracle Database 19c, 21c and 26ai — Enterprise Edition and Standard Edition 2, single instance, RAC and SEHA
• Exadata X11M on-premises, ExaDB-D, ExaDB-XS (Exascale) and Exadata Cloud@Customer
• OCI Base Database Service, Autonomous Serverless and Dedicated, Oracle Database@Azure, @AWS and @Google
• Oracle on AWS EC2 / RDS for Oracle and Azure VMs where SE2, modest scale or exit optionality dominate
• GoldenGate 23ai microservices, OCI GoldenGate, Zero Downtime Migration 26.1, Recovery Appliance and ZRCV

Oracle Performance Tuning Validated Against a Baseline

Performance work in our Oracle consulting engagements follows an application-first ladder: SQL and access paths before indexes, indexes before memory, memory before hardware. We read execution plans with DBMS_XPLAN.DISPLAY_CURSOR and ALLSTATS LAST, audit hints with HINT_REPORT, and stabilize plans the supported way — SQL Plan Management baselines, which are Enterprise Edition features that need no pack, and SQL patches through DBMS_SQLDIAG when a statement cannot be edited. SQL Profiles and Real-Time SQL Monitoring are used only where the Tuning Pack is licensed.

Most "the plan flipped overnight" tickets on estates upgraded from 12c trace to adaptive statistics; we keep the 19c-and-later defaults (OPTIMIZER_ADAPTIVE_PLANS=TRUE, OPTIMIZER_ADAPTIVE_STATISTICS=FALSE) and prove regressions from V$SQL.IS_RESOLVED_ADAPTIVE_PLAN and DBA_SQL_PLAN_DIRECTIVES. Memory is HugePages plus ASMM on Linux — never Automatic Memory Management, which is incompatible with HugePages — sized from the advice views rather than folklore. Every recommendation is measured against a captured baseline with the same queries that found the problem.

-- 1. Inspect the plan and row-source statistics of the statement in question
SELECT * FROM TABLE(dbms_xplan.display_cursor('&sql_id', NULL, 'ALLSTATS LAST +HINT_REPORT'));

-- 2. Load the known-good plan from the cursor cache as an accepted baseline
DECLARE
  n PLS_INTEGER;
BEGIN
  n := dbms_spm.load_plans_from_cursor_cache(sql_id => '&sql_id', plan_hash_value => &good_phv);
  dbms_output.put_line('baselines loaded: ' || n);
END;
/

-- 3. Verify: ENABLED = YES, ACCEPTED = YES; regressions now cannot replace it silently
SELECT sql_handle, plan_name, enabled, accepted, fixed, origin
FROM   dba_sql_plan_baselines
WHERE  sql_text LIKE '%&marker%';

-- Evidence: V$SGA_TARGET_ADVICE shows estd_db_time falling 18% at 1.25x current SGA
SELECT sga_size, sga_size_factor, estd_db_time, estd_db_time_factor, estd_physical_reads
FROM   v$sga_target_advice ORDER BY sga_size;

-- Parameter : SGA_TARGET   Current: 48G   Proposed: 60G   Unit: bytes   Scope: SPFILE (restart)
-- Pre-req   : HugePages reserved for 60G + overhead; USE_LARGE_PAGES = ONLY; MEMORY_TARGET unset
-- Rollback  : ALTER SYSTEM SET sga_target = 48G SCOPE = SPFILE; restart in the same window
ALTER SYSTEM SET sga_target = 60G SCOPE = SPFILE SID = '*';

Oracle Consultative Support and Remote DBA That Complement Oracle Support

MinervaDB's 24×7 Oracle support is consultative — Oracle consulting at incident speed. The engineer who answers a severity-1 page at 03:00 is a senior Oracle DBA who already knows your RU level, your Data Guard topology and your last restore-drill timings, not a triage script. Coverage is follow-the-sun from our Bengaluru anchor and global engineering bench, with severity-1 response in 15 minutes, severity-2 in 12 hours, severity-3 in 24 hours and severity-4 in 48 hours. Remote DBA adds the proactive calendar: quarterly RUs and monthly MRPs or CSPUs applied out of place, backup verification, Data Guard lag watch, statistics hygiene, monthly AWR-trend and capacity reports, and quarterly restore and switchover drills.

We are explicit about the service boundary. Product defects, one-off patches and most My Oracle Support notes belong to Oracle Support under your CSI — we never download Oracle software under our own credentials for a client, and a lapsed-support estate gets its exposure documented rather than "sourced" patches. We open the SR with a complete evidence package (AHF/TFA diagcollect, AWR, alert.log, ORA-600/ORA-7445 trace files) and drive it to resolution. Database design, SQL and access-path performance, patching execution, HA/DR engineering, upgrades, migrations and licence-aware cost control are ours. The split is written into every engagement so nobody discovers it during an incident.

Support tiers, per-database and per-rack pricing and fair-use terms are documented in the MinervaDB Oracle support agreement (MDB-SA series). The same engagement model runs our Db2 LUW and z/OS, SQL Server and MySQL practices.