For a two-node Oracle RAC database with each instance running on two VMs on separate ESXi hosts, you can migrate one VM with the Oracle RAC database instance from one ESXi host to another. During a cold migration, the VM is offline and the Oracle RAC database instance that is running in the VM guest is down. During a hot migration, both the VM and the Oracle RAC database instance are online and operational. Use the hot migration feature to avoid a planned downtime of the database instance during server hardware or software maintenance of the ESXi host by moving a live VM with its operational Oracle database instance to a different ESXi host.

Hot migration

To launch a hot migration by vMotion:

1. Log in to vCenter and locate the VM that you want to migrate.

2. Right-click the VM and select Migrate.

  The migration options are displayed, as shown in the following figure:

Figure 21.          VM migration using vMotion

3. Select Change compute resource only and click Next.
4. Select a compute resource, network, and vMotion for the migration.

The migration wizard validates the compatibility of the target resource. If any compatibility problem exists, it is displayed in the Compatibility panel. Resolve the issue or select another host or cluster.

5. Click Finish to complete the migration.
6. Monitor the migration progress in the Recent Tasks window, as shown in the following figure:

Figure 22.          Migration progress

7. While the VM on which the database instance is running is in migration to other ESXi hosts, log in to the database instance to view the number of user sessions that are connecting to it.

We performed this check to confirm that the database instance was functioning during the migration. The database instance showed 10 active connections from TPC-C users. This number was the same as before the migration, as shown in the following figure:

Figure 23.          Viewing database connections during a migration

Transaction throughput

We ran the HammerDB OLTP workload test on both RAC database nodes during the migration.

The following figures show the database throughput transactions per minute (TPM) before, during, and after vMotion migrations. As shown, no performance change occurred due to vMotion operation.

Figure 24.          HammerDB throughput TPM before and after vMotion starts

 Figure 25. HammerDB throughput TPM during a vMotion migration

Figure 26. HammerDB throughput TPM after vMotion migration completes

VM2 migration

The following figures show the VM2 migration.

Before the migration, VM2 was running on ESXi host2 (IP address ending with 23):

Figure 27. Premigration: VM2 on ESXi host2

After the migration, VM2 was moved to ESXi host1 (IP address ending with 22):

Figure 25.          Postmigration: VM2 on ESXi host1

CPU utilization

We also reviewed the CPU utilization changes for both ESXi hosts.

The following figure shows the CPU utilization of ESXi host2 (with an IP address ending in 23) as:

• 40% before migration
• 70% during migration
• 1.8% after migration

Figure 26.          CPU utilization change during migration: ESXi host2

The following figure shows the CPU utilization of ESXi host1 (with an IP address ending 22), the host to which the VM was migrated, as:

• 35% before migration
• 39% during migration
• 65% after migration

Figure 27.          CPU utilization change during the migration: ESXi host1