Architecture Matters, Part 4: Migrating Oracle Database from RHEL on x86 to Oracle Solaris on SPARC S7 and SPARC M7 Processor–Based Servers

Version 8

    by Kevin Klapak, Larry McIntosh, and Randal Sagrillo

     

    This article discusses how the latest Oracle-on-Oracle solutions optimize business-critical applications and database analytics.

     

    Introduction

    Oracle applications, middleware, and database software technologies operate on a wide variety of non-Oracle hardware platforms. However, only by running Oracle software on Oracle hardware can you take advantage of Oracle's comprehensive applications-to-disk coengineering, end-to-end testing, and documented best practices.

     

    As we saw in Part 1 of this series, "Architecture Matters, Part 1: Assessing Application Migration Impact," migrating an enterprise's business-critical databases to a new platform might seem daunting, but planning ahead will lead to success. In "Architecture Matters, Part 2: Navigating Database Replatforming—An Example, " we explored a real-world example of migrating an Oracle Database instance from IBM AIX to Oracle Solaris, demonstrating the simplicity and ease of operation made possible by using tools built into Oracle Database.

    OOS_Logo_small125.png
    Oracle Optimized Solutions provide tested and proven best practices for how to run software products on Oracle systems. Learn more.

     

    Then, in "Architecture Matters, Part 3: Next Steps—Optimizing for Database Performance, Security, and Availability," we saw the benefits of migrating to the unique hardware and software features of an end-to-end Oracle Optimized Solution based on Oracle's latest SPARC servers, the Oracle Solaris operating system, and Oracle Database software.

     

    At the center of Oracle's latest servers are Oracle's SPARC S7 and SPARC M7 processors, which utilize the new Software in Silicon features. In this article, we explore how you can capitalize on the benefits and greatly reduced overhead of Oracle-on-Oracle solutions by migrating your database from an x86-64 VMware vSphere 6 environment on Red Hat Enterprise Linux (RHEL) to a SPARC M7 or SPARC S7 processor–based server from Oracle and Oracle Solaris virtualization.

     

    All the articles in this "Architecture Matters" series are located here:

     

     

    Why Migrate to Oracle Solaris on a SPARC M7 or SPARC S7 Processor–Based Server?

     

    Part 3 of this series demonstrated Oracle's ongoing efforts to move in-memory database functions and hardwired data protection directly onto Oracle's SPARC M7 processor. The SPARC M7 and SPARC S7 processors' Software in Silicon features offload common database actions to special-purpose functions built into the hardware. As a result, these SPARC processors can deliver up to four times greater OLTP database performance compared to other processors, and up to 11 times faster reporting and analytics runs than alternative systems without these unique technologies. Here's how:

     

    • The SPARC M7 and SPARC S7 processors include Data Analytics Accelerator (DAX) coprocessors which provide offload engines to perform analytics processing on compressed data, freeing the SPARC cores to handle other workloads simultaneously and with virtually no overhead.
    • Silicon Secured Memory real-time data integrity checking guards against the pointer-related software errors and vulnerabilities usually employed by malware.
    • Accelerated on-chip cryptography performs encryption and decryption operations at hardware speeds, eliminating the performance and cost barriers typically associated with the high level of secure computing that is increasingly essential for all business applications.

     

    But when critical business analytics reports are run along with logistics, financials, customer management, and human resources reports all on the same operational database system, the impact that Software in Silicon features have on database performance really become apparent.

     

    Optimizing performance in such mixed workloads presents a difficult balancing act—OLTP workloads frequently operate on database rows (for example, to perform inserts or simple SQL fetches), while analytical queries access data along columns.

     

    f1.png

    Figure 1: Analytic queries on OLTP databases perform column access instead of row access.

     

    Traditional databases are designed to support row-oriented OLTP transactions, causing column-oriented analytical queries to run with degraded performance.  Using the Oracle Database In-Memory option in Oracle Database 12c and the eight on-chip DAX coprocessors greatly improves overall analytics performance along with OLTP transactions and general throughput. The Oracle Database In-Memory column format is compressed using Oracle-only algorithms that optimize space and performance. Queries execute against compressed data directly and decompress when only required. With hardware decompression in the DAX coprocessors, up to three times more data can fit in the same memory footprint. This means that larger objects, such as entire database tables, can now take advantage of the Oracle Database In-Memory option without a performance penalty.

     

    Also, by offloading analytical query processing to the DAX coprocessors, the SPARC M7 and SPARC S7 processor cores are available for other tasks, greatly improving overall performance for mixed workloads on the same system. These SPARC processors are unique in this regard.

     

    f2.png

    Figure 2: Software in Silicon efficiencies with the Oracle Database In-Memory option.

     

    And the results are tangible. A recent Enterprise Strategy Group (ESG) lab report verified that Software in Silicon delivers high performance to large in-memory database analytics workloads. When ESG compared the SPARC M7 processor–based SPARC T7-1 system to an x86-based E5 v3 system, their tests showed that Oracle Database achieved 5.4 times faster queries overall and demonstrated over 7 times more throughput, even though the x86 system had more chips and more cores.

     

    This is just one of the advanced features of the SPARC M7 and SPARC S7 processors—and this feature is not available on x86-based platforms.

     

    Moving from VMware vSphere to Oracle Virtualization

     

    A recent Edison Group report has shown that VMware vSphere virtualization contributes to a 7 to 17 percent performance loss on simple I/O and networking operations compared to native performance. Oracle VM Server for SPARC and Oracle Solaris Zones on Oracle's latest SPARC servers demonstrated a less than 1 percent performance difference compared to native performance for CPU-intensive workloads.

     

    This reduced overhead is the result of building virtualization directly into Oracle Solaris and integrating it all the way down to the processor. Unlike commodity hardware using VMware virtualization, this level of Oracle-on-Oracle integration translates into lower latency and overhead than solutions available for RHEL that are not engineered to work in concert.

     

    The Edison Group report also points out that to match the cloud and high-availability capabilities inherent to Oracle Solaris, RHEL required third-party add-on modules, along with additional risk, overhead, and management complexity.

     

      

    The "Endianness" of Going from x86 to SPARC

     

    What about endianness, the ordering of bytes in a data word in memory?  Oracle's SPARC processors use "big-endian" while x86 processors traditionally use "little-endian" byte order.  While these memory formats are incompatible, Oracle Database provides easy conversion from one to the other using the Oracle Recovery Manager (Oracle RMAN).

     

    Converting an Oracle Database instance running on x86 to big-endian format is a necessary step before migrating to a SPARC-based platform.

     

    f3.jpg

    Figure 3: Database migration example with endianness conversion.

     

      

    Steps for Performing a Migration

     

    Perform the following steps to migrate an Oracle Database instance from RHEL x86 to a SPARC M7 or SPARC S7 processor–based server running Oracle Solaris:

     

    1. Run the expdp command to export the tablespaces. This command exports the necessary metadata needed to import the data on the destination system as a .dmp file in the dump directory.
    2. Use the rman command to convert tablespaces from RHEL x86-64 "little-endian" to Oracle Solaris 64-bit "big-endian" format. rman converts the selected database tablespaces to the proper endianness, and outputs the converted tablespace as a .dbf file at the location specified by the format parameter.
    3. Move the exported files to a directory on the target SPARC M7 or SPARC S7 processor–based system. To access the files just generated by rman and expdp on the target Oracle Solaris system, copy them directly to the machine or to a shared storage device that can be mounted by the target system.
    4. On the target Oracle Solaris system, do some initial setup (for example, time zone, locks, and so on) and set parameters to locate the import and destination directories.
    5. Run the impdp command to import the exported database. This will import the tablespaces and metadata files generated earlier on the x86 system.
    6. Bring the imported database online. Tablespaces will still be in read-only mode after the import, so you need to set them back to read/write mode.
    7. Run validation tests on the database to determine if the database has been migrated properly.
    8. (Optional) Check the locations of the tablespace datafiles and move the datafiles into the Oracle Automatic Storage Management (Oracle ASM) disk group if necessary.

     

    These general steps should apply for most database applications.

     

    The next section provides a real migration example.

     

    Example Migration Run

     

    In this example, we will be migrating the soe tablespace running on RHEL 7 over VMware (rhel-vmware-db) to a SPARC S7 processor–based server running Oracle Solaris (oos-sn1-01).

     

    1. Connect to the SQL server on RHEL:

     

    [oracle@rhel-vmware-db]$ sqlplus / as sysdba

     

    SQL*Plus: Release 11.2.0.4.0 Production on Tue Jun 16 22:39:21 2015

     

    Copyright (c) 1982, 2013, Oracle.  All rights reserved.

     

    Connected to:

    Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

    With the Partitioning, Automatic Storage Management, OLAP, Data Mining

    and Real Application Testing options

                  

    SQL>

     

    2. Create a directory for the exported tablespace metadata dump files and grant permissions:

     

    SQL> create directory dpump_dir as '/shared/dpump';

     

    Directory created.

     

    SQL> GRANT EXECUTE ON DBMS_LOCK TO SYS;

     

    Grant succeeded

     

    Note: You need EXP_FULL_DATABASE privilege to export from other schemas and IMP_FULL_DATABASE privilege to import into other schemas, which SYS has by default.

     

    3. Check the endian format of the source and destination to determine whether endianness conversion is needed:

     

    SQL> SELECT * FROM V$TRANSPORTABLE_PLATFORM;

     

     

    PLATFORM_ID PLATFORM_NAME                           ENDIAN_FORMAT

    --------------------------------------------------- --------------

              1 Solaris[tm] OE (32-bit)                 Big

              2 Solaris[tm] OE (64-bit)                 Big

     

              7 Microsoft Windows IA (32-bit)           Little

             10 Linux IA (32-bit)                       Little

              6 AIX-Based Systems (64-bit)              Big

              3 HP-UX (64-bit)                          Big

              5 HP Tru64 UNIX                           Little

              4 HP-UX IA (64-bit)                       Big

             11 Linux IA (64-bit)                       Little

     

             15 HP Open VMS                             Little

              8 Microsoft Windows IA (64-bit)           Little

              9 IBM zSeries Based Linux                 Big

             13 Linux x86 64-bit                        Little

             16 Apple Mac OS                            Big

             12 Microsoft Windows x86 64-bit            Little

             17 Solaris Operating System (x86)          Little

             18 IBM Power Based Linux                   Big

             19 HP IA Open VMS                          Little

             20 Solaris Operating System (x86-64)       Little

             20 Apple Mac OS (x86-64)                   Little

     

    4. Export the tablespace metadata using the Oracle Data Pump expdp export command:

     

    [oracle@rhel-vmware-db dev]$ expdp system/demo15@odbonrhel FULL=Y TRANSPORTABLE=ALWAYS VERSION=12 directory=dpump_dir dumpfile=par_odbonrhel.dmp

     

     

    Export: Release 11.2.0.4.0 - Production on Tue Jul 21 06:20:12 2015

     

    Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

    ;;;

    Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

    With the Partitioning, Automatic Storage Management, OLAP, Data Mining

    and Real Application Testing options

    Starting "SYSTEM"."SYS_EXPORT_FULL_01":  system/********@odbonrhel TRANSPORTABLE=ALWAYS FULL=Y VERSION=12 directory=dpump_dir dumpfile=soe.dmp

    Estimate in progress using BLOCKS method...

    Processing object type DATABASE_EXPORT/PLUGTS_FULL/FULL/PLUGTS_TABLESPACE

    Processing object type DATABASE_EXPORT/PLUGTS_FULL/PLUGTS_BLK

    Processing object type DATABASE_EXPORT/EARLY_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA

    Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/TABLE_DATA

    Processing object type DATABASE_EXPORT/NORMAL_OPTIONS/VIEWS_AS_TABLES/TABLE_DATA

    Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA

    Total estimation using BLOCKS method: 87.62 MB

    ...

    ...

    ...

    Processing object type DATABASE_EXPORT/PRE_SYSTEM_IMPCALLOUT/MARKER

    . . exported "SYSTEM"."REPCAT$_USER_AUTHORIZATIONS"          0 KB       0 rows

    . . exported "SYSTEM"."REPCAT$_USER_PARM_VALUES"             0 KB       0 rows

    . . exported "SYSTEM"."SQLPLUS_PRODUCT_PROFILE"              0 KB       0 rows

    Master table "SYSTEM"."SYS_EXPORT_FULL_01" successfully loaded/unloaded

    ******************************************************************************

    Dump file set for SYSTEM.SYS_EXPORT_FULL_01 is:

      /hdisk0/datafiles/bkp/soe.dmp

    ******************************************************************************

    Datafiles required for transportable tablespace SOE:

    +DATA/odbonrhel/datafile/soe.275.885484559

     

    Datafiles required for transportable tablespace USERS:

      +DATA/odbonrhel/datafile/users.259.881417871

     

    Job "SYSTEM"."SYS_EXPORT_FULL_01" successfully completed at Tue Jul 21 06:23:06 2015 elapsed 0 00:02:53

     

    5. Set the tablespaces required for export (listed in the expdp output) to read-only mode:

     

    SQL> alter tablespace soe read only;

     

    Tablespace altered.

     

    SQL> alter tablespace users read only;

     

    Tablespace altered.

     

    SQL> quit

     

     

    6. Convert the tablespace using rman:

     

    [oracle@rhel-vmware-db dev]$ rman target /

     

    Recovery Manager: Release 11.2.0.4.0 - Production on Wed Jun 17 09:54:52 2015

     

    Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

     

    connected to target database: ODBONRHE (DBID=2884168843)

     

    RMAN> convert tablespace soe

     

    2> to platform "Solaris[tm] OE (64-bit)"

     

    3> format "/shared/converted/soe.dbf";

     

    Starting conversion at source at 17-JUN-15

    using target database control file instead of recovery catalog

    allocated channel: ORA_DISK_1

    channel ORA_DISK_1: SID=39 device type=DISK

    channel ORA_DISK_1: starting datafile conversion

    input datafile file number=00005 name=+DATA/odbonrhel/datafile/soe.275.882517531

    converted datafile=/shared/converted/soe.dbf

    channel ORA_DISK_1: datafile conversion complete, elapsed time: 01:33:17

    Finished conversion at source at 17-JUN-15

    RMAN> quit

     

     

    7. Transfer the following files to the destination server or sharable storage:

     

    soe.dmp

    soe.dbf

    users.dbf

     

    8. Connect to the destination database server:

     

    oracle@oos-sn1-01:~$ sqlplus / as sysdba

     

    SQL*Plus: Release 12.1.0.2.0 Production on Fri Jan 22 04:28:50 2016

     

    Copyright (c) 1982, 2014, Oracle.  All rights reserved.

     

    Connected to:

    Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

    With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

    SQL>

     

    9. Create a directory for the metadata import and grant permissions:

     

    SQL> create directory dpump_dir as '/shared/dpump_dir';

     

    Directory created.

     

    SQL> GRANT EXECUTE ON DBMS_LOCK TO PUBLIC;

     

    Grant succeeded

     

    Note: You need EXP_FULL_DATABASE privilege to export from other schemas and IMP_FULL_DATABASE privilege to import into other schemas, which SYS has by default.

     

    10. Verify the time zone and set it if it is not the same as that of the source database:

     

    SQL> select dbtimezone from dual;

     

    DBTIME

    ------

    +00:00

     

    1 row selected.

     

    SQL> alter database SET TIME_ZONE '+00:00'

     

    Database restart required if changing timezone

     

    SQL> quit

     

    Note: Checked to make sure the time zone matches on both the source and destination, because we ran into problems during the import if there was a mismatch.

     

    11. Drop the current users tablespace:

     

    SQL> alter database default tablespace system;
    SQL> drop tablespace users including contents and datafiles;
    SQL> quit

     

    12. Using a text editor, create the file par.f with these import parameters:

     

    FULL=Y

    DUMPFILE=soe.dmp

    DIRECTORY=dpump_dir

    TRANSPORT_DATAFILES=

    '/shared/converted/soe.dbf',

    '/shared/converted/users.dbf'

    LOGFILE=import.log

     

    Note: /shared/ is a shared NFS file system.

     

    13. Run the import command with the par.f import parameters:

    oracle@oos-sn1-01:~$ impdp system/demo15 parfile='par.f'

     

    14. Bring the tablespace back online and change it from read-only mode to read/write mode:

     

    SQL> alter tablespace soe read write;
    SQL> alter tablespace users read write;

    Tablespace altered.

     

    15. Verify that the database is operational on the SPARC S7 processor–based server:

     

    oracle@oos-sn1-01:~$ sqlplus / as sysdba

     

    SQL*Plus: Release 12.1.0.2.0 Production on Fri Jan 22 04:28:50 2016

     

    Copyright (c) 1982, 2014, Oracle.  All rights reserved.

     

    Connected to:

    Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

    With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

     

    SQL> conn soe/soe

     

    Connected.

     

    SQL> select count(*) from product_descriptions;

     

      COUNT(*)

    ----------

          1000

     

    SQL> select count(*) from logon;

     

      COUNT(*)

    ----------

    357447600

    ...

     

    (Optional) Check the Datafile Locations and Move the Datafiles into the Oracle ASM Disk Group if Necessary

     

    1. Connect to SQL*Plus and take the tablespaces offline:

     

    SQL> ALTER TABLESPACE SOE OFFLINE;

     

    Tablespace altered.

     

    SQL> ALTER TABLESPACE USERS OFFLINE;

     

    Tablespace altered.

     

    2. Check where your datafiles are located on Oracle ASM:

     

    SQL> SELECT NAME FROM V$DATAFILE;

     

    FILE_NAME

    --------------------------------------------------------------------------------

    +DATA/ORCL/DATAFILE/system.272.915393283

    /shared/converted/users.dbf

    +DATA/ORCL/DATAFILE/sysaux.264.915393239

    +DATA/ORCL/DATAFILE/undotbs1.263.915393341

    +DATA/ORCL/DATAFILE/undotbs2.273.915393435

    /shared/converted/soe.dbf

     

    6 rows selected.

     

    3. Log out from SQL*Plus, start an Oracle RMAN session, and execute the copy command:

     

    Note: You only need to pass the disk group name when copying data to a disk group.

     

    RMAN> copy datafile '/shared/converted/soe.dbf' to '+DATA';

     

    Starting backup at 26-JUN-16

    using channel ORA_DISK_1

    channel ORA_DISK_1: starting datafile copy

    input datafile fno=00006 name='/shared/converted/soe.dbf'

    output filename=+DATA/ORCL/DATAFILE/soe.265.915570847 tag=TAG20160626T062616 recid=1 stamp=915570848

    channel ORA_DISK_1: datafile copy complete, elapsed time: 00:10:04

    Finished backup at 26-JUN-16

     

    RMAN> copy datafile '/shared/converted/users.dbf' to '+DATA';

     

    Starting backup at 26-JUN-16

    using channel ORA_DISK_1

    channel ORA_DISK_1: starting datafile copy

    input datafile fno=00002 name='/shared/converted/soe.dbf'

    output filename=+DATA/ORCL/DATAFILE/users.275.915571183 tag=TAG20160626T062616 recid=1 stamp=915571184

    channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:05

    Finished backup at 26-JUN-16

     

    4. Start an SQL*Plus session, and rename the old file to the name of the new Oracle ASM file:

     

    oracle@oos-sn1-01:~$ sqlplus / as sysdba

     

    SQL*Plus: Release 12.1.0.2.0 Production on Mon Jun 27 17:28:54 2016

     

    Copyright (c) 1982, 2014, Oracle.  All rights reserved.

     

    Connected to:

    Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

    With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,

    Advanced Analytics and Real Application Testing options

     

    SQL> alter database rename file '/shared/converted/soe.dbf' to '+DATA/ORCL/DATAFILE/soe.265.915570847';

     

    Database altered.

     

    SQL> alter tablespace soe online;

     

    Tablespace altered.

     

    SQL> alter database rename file '/shared/converted/users.dbf' to '+DATA/ORCL/DATAFILE/users.275.915571183';

     

    Database altered.

     

    SQL> alter tablespace soe online;

     

    Tablespace altered.

     

    5. Check to see the changes:

     

    SQL> SELECT NAME FROM V$DATAFILE;

     

    FILE_NAME

    --------------------------------------------------------------------------------

    +DATA/ORCL/DATAFILE/system.272.915393283

    +DATA/ORCL/DATAFILE/users.275.915571183

    +DATA/ORCL/DATAFILE/sysaux.264.915393239

    +DATA/ORCL/DATAFILE/undotbs1.263.915393341

    +DATA/ORCL/DATAFILE/undotbs2.273.915393435

    +DATA/ORCL/DATAFILE/soe.265.915570847

     

    6 rows selected.

     

    6. Remove the old datafiles:

    oracle@oos-sn1-01:~$ rm /shared/converted/soe.dbf /shared/converted/users.dbf

     

    Conclusion

     

    As demonstrated in the previous article in this series and verified in the recent report from ESG Lab, migration to Oracle-on-Oracle technology is now easier than ever. Using proven Oracle Optimized Solutions best practices and tools, databases can be converted and not only migrated, but also upgraded quickly to take advantage of new features in Oracle Database, Oracle Solaris, and the underlying SPARC M7 or SPARC S7 processor, all working together.

     

    Also, the analysis by the Edison Group reports that the latest SPARC servers from Oracle running Oracle Solaris are nearly 30 percent more cost-effective than competing commodity x86 RHEL-based systems.

     

    Take advantage of these unique Oracle-engineered efficiencies by migrating Oracle Database from x86 RHEL/VMware platforms to the latest SPARC M7 or SPARC S7 processor–based servers with built-in Oracle Solaris virtualization. The SPARC M7 and SPARC S7 processors' Software in Silicon technology and the Oracle Database In-Memory option working together offer extreme performance and outstanding security for business analytics over mixed workloads, demonstrating that architecture does matter when it comes to complex business-critical processes.

     

    See Also

     

     

    About the Authors

     

    Kevin Klapak is a product manager on the Oracle Optimized Solutions team. He joined the team in January 2015 after completing his master's degree from Carnegie Mellon University. He has a background in computer science and over five years of IT experience. Since joining Oracle, he has been working on database migration,  Apache Spark/big data analytics, and systems security.

     

    Larry McIntosh is the chief architect within the Oracle Optimized Solutions team. He has designed and implemented highly optimized computing, networking, and storage technologies for both Sun Microsystems and Oracle. McIntosh has over 40 years of experience in the computer, network, and storage industries and has been a software developer and consultant in the commercial, government, education, and research sectors and an information systems professor. He has directly contributed to the product development phases of Oracle Exadata Database Machine and various Oracle Optimized Solution architectures. His most recent contribution has been in the design, development, testing, and deployment of Oracle Optimized Solution for Secure Oracle Database.

     

    Randal Sagrillo is a solutions architect for Oracle. He has over 35 years of IT experience and is an expert in storage and systems performance, most recently applying this expertise to next-generation data center architectures, integrated systems, and Oracle engineered systems. Sagrillo is also a frequent and well-attended speaker on database platform performance analysis and tuning, and he has spoken at several industry conferences including Oracle OpenWorld, Collaborate, Computer Measurements Group, and Storage Networking World. In his current role, he is responsible for solution architecture and development around Oracle Optimized Solutions. Before joining Oracle, he held a variety of leadership roles in product management, program management, and hardware/software product development engineering.

     

     

    Revision 1.1, 06/29/2016