Oracle RAC Migration with License Optimization and Virtualization

In large-scale retail, the operational continuity of database systems is the foundation for sales, logistics, and billing. The customer, a major player in the retail sector, ran its critical databases on an Oracle RAC infrastructure installed on physical servers. The environment had two main constraints:

1. Hardware obsolescence: the difficulty of sourcing physical servers with a limited number of CPUs, a necessary condition for containing Oracle license costs based on core count.
2. Heterogeneous systems: different Oracle versions and many databases with distinct functions coexisted, from test systems to production, the data warehouse, and databases dedicated to the store network. In the initial architecture, the application servers connected directly to the Oracle SCAN listeners of the physical cluster through DNS aliases.
    

The technical challenge for Miriade was to migrate the entire ecosystem to a new-generation virtual environment, minimizing the impact on retail operations and addressing three critical issues.

1. Minimize downtime, keeping the outage for users and applications during the cutover to a minimum, given the 24/7 nature of retail operations.
2. Optimize license costs (licensing) to avoid the risk of a steep increase in software costs if CPU usage could not be limited and certified through vendor-approved virtualization technologies.
3. Manage uncertainty about the performance of the new solution. This was a real concern: the new virtual environment had to deliver application responsiveness equal to or better than the physical ("bare metal") infrastructure, avoiding network and storage bottlenecks.

The work was planned around three strategic pillars. 

• The migration had to happen with near-zero downtime. The databases had to be moved over with the total outage reduced to extremely short time windows.
• One of the goals was more efficient licensing, using virtualization to manage CPU resources granularly through hard partitioning and optimize the software investment.
• Finally, a cornerstone was ensuring post-migration stability and tuning, so that the new infrastructure would resolve any latent hardware issues and deliver stable performance over the long term.

The strategy designed by Miriade moved the databases to virtual servers managed by Oracle Linux Virtualization Manager (OLVM), backed by new very high-performance storage. The architecture involved three virtual machines: two dedicated to the cluster nodes and one configured as Oracle Connection Manager (CMAN). CMAN acted as an intelligent proxy, intercepting connections from the application servers and redirecting them to the correct database. Using CMAN made it possible to migrate "step by step" (one database at a time), completely transparently for the clients. For the largest databases (out of a total of almost 20 TB migrated), Miriade adopted a targeted strategy: restoring a regular backup without stopping production, followed by periodic recovery runs to keep it aligned. On cutover day, the outage for the most critical database was limited to about 15 minutes.

During the initial testing phase, the test environment was put under stress to surface any performance issues early, rather than discover them after the migration. Here are some points to always keep in mind for optimal performance:

• Certified versions of all cluster components, disks, servers, network cables, and GBICs, as required by Oracle in its official notes.
• Error checks on all components, including the CRC (Cyclic Redundancy Check). It is a mathematical check that verifies that the data sent from point A is identical to the data received at point B. If the result does not match, the data packet was corrupted in transit along the cable. When this happens, the packet must be discarded and sent again. This slows down cluster performance significantly.
• Checking CPU power management.

The migration methodology

The migration followed these steps:

• controlled suspension of the applications and backup through the external backup suite;
• restore and recovery on the new virtual infrastructure;
• update of the CMAN configuration to point to the new database: the database on the old infrastructure is deregistered from CMAN, and the migrated database on the new infrastructure is registered;
• immediate restart of the application services with no client reconfiguration.

With 8 databases migrated, for a total of almost 20 TB of data, restore and recovery times varied.
For the two largest databases, a slightly different strategy was applied. A regular backup was restored without stopping production, and periodic recovery runs followed on migration day to minimize the outage, which, as noted above, was about 15 minutes for the most critical database.

Because the databases were physically restored with the RMAN utility, query execution plans did not change, so no improvements could come from that side. Nevertheless, the data flows ran faster thanks to the infrastructure change alone. Moving to a virtual infrastructure also made it possible to fix the number of CPUs and limit license costs.
 

The migration required a careful combination of enterprise technologies and in-depth infrastructure tuning techniques.

• Oracle RAC (Real Application Clusters): the core database engine, for maximum reliability.
• Oracle Linux Virtualization Manager (OLVM): chosen to certify hard partitioning and keep CPU license costs within Oracle's licensing rules.
• Oracle Connection Manager (CMAN): used as a key proxy to route traffic and ensure a smooth migration with no application interruptions.
• Oracle RMAN (Recovery Manager): for physical restores that kept query execution plans intact.

Recommendations

Migrating mission-critical systems requires proactive infrastructure design. In this case, the following practices proved useful:

• Adopt orchestration tools such as CMAN to manage traffic smoothly and transparently for the applications during the cutover.
• Do not underestimate hardware tuning, and pay attention to parameters such as processor power saving; the correct versions of the hardware components involved can have a significant impact on database performance in a virtual environment.
• Plan rigorous tests, using development/test databases to surface the infrastructure's limits before moving on to production systems.
• Keep constant watch on wait events and I/O performance to ensure operational stability over time.