by Jeff Stonacek, Principal Architect
There has been some interest from House of Brick customers running on x86 Solaris about migrating to Linux. Unlike Sparc Solaris, where there is an endian conversion to move to an x86 platform, x86 Solaris is already little endian. So, it should be possible to move the data more easily than when an endian conversion is required. We have done far too many database migrations using Oracle Data Guard to count, but they are almost always done with a homogeneous operating system. This means that the source and destination were both running the same OS and bit level, albeit potentially different versions. So, I began thinking that it may be possible to use a physical standby database (with redo apply) to accomplish a migration from x86 Solaris to Linux. Turns out, it is possible.
So what heterogeneous combinations are possible? According to Oracle, Data Guard migrations are possible with the following combinations of disparate operating systems.
The relationship is reciprocal, so the same rules apply going from destination to source.
There are some other options for heterogeneous platforms. Namely, in the RISC Unix space. For example, it is possible to set up Data Guard between Solaris on Sparc and AIX on Power. However, the vast majority of RISC Unix migrations that we see are migrations off of RISC Unix and onto Linux.
It is also possible to set up Data Guard between z/Linux and Power Linux. If you are contemplating this type of migration however, I would recommend giving it a bit more forethought.
At House of Brick, we like to verify things before passing them along in a blog. With that in mind, I set up a pair of servers to test heterogeneous Data Guard. My environment consisted of the following:
- Solaris 11 64-bit server with Oracle 12.2 installed
- A running database on the Solaris 11 server
- Linux 64-bit server with Oracle 12.2 installed
I won’t bore you with all the details involved in setting up Data Guard, that is for a different blog. The high-level steps are as follows:
- Prepare the source Solaris 11 server and database for Data Guard
- Prepare the destination Linux server for Data Guard, getting the database to a nomount state
- Perform an RMAN duplicate for standby from Solaris 11 to Linux
- Start managed recovery
All of these steps worked exactly as expected, and there were no errors or unusual behavior. Replication and switchover also worked flawlessly.
There are many reasons to migrate off of Solaris and onto Linux. The most obvious reason is that Linux is the primary port for Oracle core technology software. Oracle does all of its initial development for new releases on Linux, and therefore Linux receives the best support. This is reason enough to plan for your next hardware platform to be compatible with Linux.
Beyond the Oracle support issue, the Linux operating system has a very wide install base and enjoys extensive vendor support for third-party products like drivers and utilities. Things like network and HBA drivers, backup software and other utilities are also generally available for Linux. This makes Linux a natural choice for platform replacement, as most third-party products have a direct migration path onto Linux.
Commodity Intel hardware is both inexpensive and performant. Intel has done a great job of increasing the performance of their chips from generation to generation. In fact, today Intel chips outperform some of the more expensive options. Intel also comes with a .5 core factor for Oracle licensing, which can save a lot on licensing fees over some traditional RISC Unix platforms that still maintain a core factor of 1. I am certain there is a House of Brick blog already written that describes this in great detail.
In this blog we have discussed the possibility of using Oracle Data Guard for heterogeneous operating system platforms. This feature is especially useful for migrating off of one OS, like Windows or Solaris, onto Linux. So, if you are currently running Oracle on Windows or Solaris (on x86), the migration path for moving to Linux is easy with heterogeneous Data Guard.