Blogs

Permalink

How to Keep your Oracle Solaris Apps Running when your Hardware is Retired Part Two

By Sandy Levitt posted 12-07-2022 09:44 AM

  

Oracle owners sometimes deal with legacy systems during the lifetime of applications. The legacy servers hosting these apps get older and become hard to keep in service without hardware downtime. Oracle managers who have faced this legacy problem understand their challenge lies in hardware, not the software.

This is why emulation has become a tool of transformation for Oracle customers. Sometimes the emulation means that the Oracle database must run in an emulated SPARC environment, right alongside the legacy application. There are other instances, though, where migrating Oracle to a new version plays a role in preserving a legacy system.

We’ve worked with one Oracle customer in the financial sector who faced a migration via emulation. Their database was a candidate for a move away from SPARC and the Solaris OS. In this financial datacenter, there was a clear path to host Oracle outside a SPARC server.

Our product, Charon SSP, uses x86 hardware to emulate a SPARC system. It can transform legacy hardware for an application in tandem with a fresh version of Oracle—both running on x86.

The original implementation at the datacenter was on two separate SPARC servers. An Oracle database server ran on Solaris. Alongside it, a customized application ran on Solaris on its own SPARC server.

The application used Oracle’s network connectivity for the database. The connection went out over the network and back into the other server. This architecture made it easier for the mix of new Oracle and preserved application.

In every Oracle legacy transformation, you assess server workloads. The SPARC processors had 10-20 percent usage during Western Hemisphere waking hours. Later, there was a period of a few hours where the load dropped to 2-3 percent. The situation provided an opportunity to utilize virtualization by going to the cloud.

Hosting Oracle on a cloud

Now you look at what’s needed to get a Oracle database to migrate properly. There was a clean upgrade path with no extraordinary data types — the types that would cause issues with migrations to a different platform. In addition, the system used no external procedures.  That datacenter installed a newer version of Oracle, hosted in the cloud on Linux.

One advantage of splitting the migration into separate servers is the shape of the computing cloud. We know that cloud shapes can become expensive. The financials firm got a cloud shape that was optimized for the needed performance. As a separate server on a Linux platform, the Oracle instance in the cloud was less costly.

Transformation tools helped pave the way. Moving software off SPARC involved making a Big Endian to Little Endian migration. A replication tool like Golden Gate can do this migration with almost no downtime. By using a traditional export-import, you need a larger window of time, but ease of use is greater. Without the cost of the replication tool, the expense is considerably lower.

Now the financials firm is looking at the application piece. We installed and configured Charon SSP in a cloud shape that delivers good performance. It didn't take a very big cloud shape. With today’s fast processor speeds, the public cloud offerings have improved a lot over the last few years.

Since Oracle would run on Linux instead of Solaris, we migrated the database to a version of Oracle on Linux. On the application side, the Charon SSP emulator can use a cloud shape with Linux and the SPARC emulator pre-installed. Oracle offers this on its Oracle Cloud, so a datacenter can just pick that out of Oracle’s service catalog.

In the financial firm’s case, we had specific requirements that made it easier to do it ourselves, rather than modify a premade template. But the premade template works great in lots of cases.

Finally, there’s the issue of the Oracle license impact while changing from a SPARC version to a Linux version. The extent of the impact depends on your original licensing scenario. Some are written to a site license, so there’s no impact. Some are written before Oracle’s processor metric was introduced. This makes it easier to migrate.

If you're migrating to a cloud service, Oracle defines those as one to one in terms of processor cores that are allocated to your virtual machine. Much of the impact depends on your current contract.

Migrating Oracle while you emulate your applications offers a good way to shape a cloud for top performance and low expense. Emulation while using Oracle is a secure and cost-effective way to keep legacy systems reliable.