Many critical Oracle databases still run on Solaris servers that are getting harder to maintain. We move the database, and the scripts and programs around it, to Linux, on your own servers or in the cloud, without disrupting the people who depend on it. We did exactly that for a major California city, whose applications kept working with minimal changes.
What we cover
Why move
Solaris servers that have run reliably for years eventually reach the end of their hardware support, and keeping them going gets harder each year. Linux runs on standard servers, is offered by every major cloud and is a mainstream platform for Oracle Database, so a move opens the way to newer hardware, newer Oracle releases and a later step into the cloud. The work is in doing it without disturbing the people who use the database.
The technical catch
Solaris on SPARC stores data in big-endian byte order and Linux on x86 in little-endian, so the database files cannot simply be copied across, and a Data Guard physical standby on Linux is not an option. The choice of method comes down to downtime. Data Pump export and import is simple, but its outage grows with the database. Cross-platform transportable tablespaces, with RMAN incremental backups rolled forward ahead of the switch, cut the outage to the final increment and the metadata. Oracle GoldenGate keeps a Linux database in sync with the Solaris one, so users carry on working until a short, planned switch. Solaris on x86 already has the same byte order as Linux, which widens the options.
Beyond the database
A Solaris database server rarely runs only the database. There are shell scripts that call Solaris-specific commands and paths, cron jobs, C and Pro*C programs that must be recompiled, file transfers, monitoring and backup agents, and sometimes applications in Solaris zones on the same machine. We map every one of these dependencies first, decide with you what moves, what is rewritten and what is retired, and test each on Linux before the switch. Mapping the dependencies first is what let a major California city move its mission-critical Oracle database with no disruption to public services.
Upgrade in the same move
A platform move is often the right moment to upgrade Oracle, because the database is being rebuilt anyway. Data Pump, transportable tablespaces and GoldenGate all allow the new database to run a newer release than the old one. Doing both at once saves a second project, but it also means two changes to test together, so we weigh the options with you and rehearse whichever you choose.
Where it lands
Usually the target is Linux on standard servers, in your own data center or in the cloud. Sometimes it is another platform: for a global retail bank we moved a 30 TB Oracle database from Solaris to Oracle 12c RAC on IBM AIX, kept in sync with GoldenGate, with zero downtime. And a move to Linux on your own servers leaves the database ready for a later step into the cloud, as it did for the California city.
Case studies
Client names are withheld. We are happy to share details on a call.
DeliveredNo service disruption
Local government
A major California city ran a mission-critical Oracle database on Solaris servers nearing end of life. We mapped the dependencies, confirmed the applications would work unchanged and re-platformed the database to Linux without disrupting public services.
No disruption to public servicesMinimal application changes
Delivered30 TB, zero downtime
Financial services
The bank's transaction database served thousands of users around the clock. We built the new Oracle 12c RAC platform on IBM AIX alongside the old Solaris system, kept the two in sync with Oracle GoldenGate, tested everything and switched over with no downtime and no data loss.
30 TB moved with zero downtimeZero data loss at cut-overQuestions
Applications that connect to the database over the network usually need little or no change, because the database is still Oracle. The work is in what ran on the Solaris server itself: scripts, jobs and compiled programs. For the California city, the applications needed only minimal changes.
It depends on the size of the database and the method. Data Pump needs a window that grows with the data; transportable tablespaces with incremental backups shorten it to the final increment; GoldenGate keeps users working until a short, planned switch. We time the chosen method in rehearsal, so the window is measured rather than guessed.
Yes. Data Pump, transportable tablespaces and GoldenGate all let the Linux database run a newer release. We help you decide whether to do both in one move or in two steps, depending on the risk you are willing to take and the time available.
Sometimes. If the target is already decided and the applications are ready, moving from Solaris straight to a cloud platform such as OCI or AWS saves a step. If not, moving to Linux first takes the hardware risk away quickly and leaves the database ready for the cloud later.
They are part of the dependency map. Applications in Solaris zones, file transfers and batch jobs each get a decision (move to Linux, rewrite or retire), and each is tested before the switch.
From the blog
March 7, 2023
February 27, 2023
November 16, 2022
Related services
Move to the cloud, build for it
Trusted data, reports and analytics agents
Support, security and monitoring from one MSP
On-site IT support across New Jersey, New York City and Philadelphia. Remote services wherever you are. Areas we serve →
We map the database and everything around it, and come back with the method, the downtime, the risks and a cost range, before you commit to anything.
A few lines is enough. The engineers who do this work will reply within one business day.
Or email it.services@princetonits.com or call +1 (212) 507-9350.
Princeton IT Services