Case Study
- Order Spikes Analysis
- Product Data Hub Implementation
- EXADATA Hardware Migration - X9 to X10
- Legacy System Migration to Oracle with Golden Gate
- Migration of PeopleSoft HCM to Workday HCM
- Standardizing Item, UOM and XRef Processes with EBS
- EBS Item-Vendor Sync Resolution
- PlannerSync PDH
- Dynamic System Integration
- Agile OU Operations
- IaC Enablement Process
- Oracle EBS Optimization Initiative
- Security Patching with Ansible
- Automated Patch Management
- MC Product Hub
- Scalable Division Setup Without Hard Coding
- Data Cleanup
- Multi Unit Integration Under Single Responsibility
- CDH Enablement for Grocery
- OMS Online
- SourceLink, UAM, MESA - Angular and Java
- SailPoint IIQ
- QA Test Automation
- Devops
- Optimizing Testing Strategies in the LedgerIQ
- Java Revamp
- Enhancing Academic Efficiency Through Digitization
- API Management
- OMS Batch Modernization
- Linux Server Automation with Ansible
- Securing Servers through Standardized Hardening
- Azure Recoverability Initiative
- DC Ops Analytics
- Katalon Automation
- Linux Administration
- Leveraging AI in IoT Systems
- Intelligent Discrepancy Resolution Assistant
- AI-Driven Supply Chain Anomaly Detection and Risk Insights
- AI-Driven Traceability Platform
EXADATA Hardware Migration - X9 to X10
As part of an EXADATA hardware upgrade, the client planned to migrate from X9 servers to X10 servers, beginning with NON-PROD environments, followed by PRODUCTION and the recently upgraded 19c databases. While the PROD and NON-PROD migrations were successful, significant challenges arose in stabilizing the 19c upgraded instances. To resolve this, critical system adjustments were made, ensuring operational stability and enabling further upgrades.
Problem
Statement
The migration of 19c upgraded instances presented several challenges that hindered progress:
-
The client could not proceed with further upgrades until the existing 19c instance issues were addressed.
-
A critical autoconfig issue in the 4-NODE RAC environment needed resolution.
-
The issue became a showstopper, preventing any further upgrade activities.
Solution
Proposed
To restore system stability, all XML and TNS file modifications directing configurations to the new X10 servers were removed and the process was restarted from scratch.
After attempting 30+ solutions and consulting an external Centroid DBA without success, the issue was finally resolved after 25 days of troubleshooting using a combination of four key solutions:
-
Redirecting TNS entries to the GLOBAL name instead of PDB or CDB.
-
Configuring the correct limit values in SQLNET.ORA.
-
Ensuring proper service parameter settings for the GRID listener.
-
Setting LOCAL LISTENER values to use the hostname instead of the IP address, following 19c best practices.
Post-implementation testing confirmed that all systems were fully operational.
Business
Values
With the issue resolved, the client was able to proceed with the next upgrade instance, which had been on hold for over a month. The successful migration allowed the upgrade process to continue, leading to the decommissioning of the legacy X9 servers and a smooth transition to the X10 infrastructure.