{ Abhilash Kumar Bhattaram : Follow on LinkedIn }
In my earlier blogs I have explained about automation on how handling multiple parallel patching improves operational efficiency.
More databases , more the operational overhead , so consolidation is the key
But seldom do oraganizations reliaze that you are slow piling up databases which backups , DR's and the entire lifecycle systems will have operational overhead. In other words consolidation is the key.
BEFORE CONSOLIDATION (20 Individual DB Systems)
------------------------------------------------
• 20 Separate DB Servers
• 20 Database Patches Every Cycle
• 20 GI Patches Every Cycle
• 20 Backup Schedules
• 20 DR Replications
• 20 Monitoring Configurations
• Higher Cloud OCPU + Storage Cost [Fixed]
• Fragmented Performance & Capacity
▼ CONSOLIDATE ▼
AFTER CONSOLIDATION (1 ExaCS + 10 Databases)
---------------------------------------------
• 1 ExaCS Platform Hosting All Workloads
• 10 Database Patches (≈50% Reduction)
• 1 GI Patch for Entire Platform
• Unified Backup & DR Strategy , though 20 DB's are still have individual DR setup
• Centralized Monitoring - Using Ops Insights
• Better Capacity Utilization - ExaCS Dynamic Scaling for reduced CPU resources
• Optimized OCPU/Storage = Lower Costs
• Streamlined Performance Management
1. Ground Zero: Where Challenges Start
Understand which applications and database are running , a DBA cant just be a systems guy - he should help the bussiness operations
+--------------------------------------------------------------------------------------+
| 1. Ground Zero: Where Challenges Start |
|--------------------------------------------------------------------------------------|
| - Every new application demands its own database — duplication becomes the default. |
| - Cloud provisioning is too easy → systems are created without clear ownership. |
| - Backups multiply per environment: Prod, Dev, QA, DR — unchecked. |
| - No visibility into which systems are active vs abandoned. |
| - Many databases are oversized and underutilized. |
| - Cloud invoices increase month after month — but nobody knows which DB drives cost. |
| |
+--------------------------------------------------------------------------------------+
2. Underneath Ground Zero: Finding the Real Problem
Understand and question why operations are increasing with number of databases.
+--------------------------------------------------------------------------------------+
| 2. Underneath Ground Zero: Finding the Real Problem |
|--------------------------------------------------------------------------------------|
| - No governance model for lifecycle: creation, consolidation, retirement. |
| - Application managers request isolation instead of sharing resources. |
| - DR environments are costly but often underused or misclassified. |
| - Retention policies are not standardized — stale data lives forever. |
| - No right-sizing: sizes set once, never revisited. |
| - Cloud cost attribution is missing — infra teams can’t link DBs to business units. |
| - The issue is not “too many DBs”—it’s invisible debt. |
| - 20 DB systems = 20 GI patches, 20 DB patches, 20 outages. |
| - Backup + DR multiplied 20 times (FRA, snapshots, RMAN). |
| - Idle capacity everywhere: some DBs 10% used, some choking. |
| - Fragmented performance insight—each DB is a silo. |
| - Architecture grows by project decisions, not platform plan. |
| - Reliability cannot scale when the foundation is fragmented. |
+--------------------------------------------------------------------------------------+
3. Working Upwards: From Understanding to Solution
Consolidate - Build and Manage with that in mind
+--------------------------------------------------------------------------------------+
| 3. Working Upwards: From Understanding to Solution |
|--------------------------------------------------------------------------------------|
| - Build a live, automated catalog of your DB estate (size, owner, usage). |
| - Tag and classify databases (active, inactive, critical, archive). |
| - Consolidate databases logically — reduce count without sacrificing isolation. |
| - Right-size everything: CPU, memory, storage — based on real usage. |
| - Rationalize DR and backup systems — align to actual business risk. |
| - Implement policies for lifecycle management: retire or archive unused DBs. |
| - Measure cost per DB and map it to business value — create accountability. |
| |
+--------------------------------------------------------------------------------------+
How Nabhaas helps you
At Nabhaas, we work closely with teams to uncover dependencies, knowledge gaps, and process inefficiencies to ensure the patching cycle is smooth and predictable.
TAB ( Total Automation Box ) is how we automate patching lifecycles. https://www.nabhaas.com/tab
There is no staright answer to the points mentioned above but all of them needs to be addressed as best fits the organization.
At Nabhaas we ensure we identify all the above before beginning a patch cycle. Feel free to download our whitepaper here
Top comments (0)