by Kevin Klapak, Larry McIntosh, Randal Sagrillo, and Ken Kutzer
This article demonstrates how to use commonly available and understood tools to migrate, convert, and upgrade Oracle Database instances when moving from Linux to Oracle Solaris–based systems with Software in Silicon.
| Table of Contents
| |
|
Oracle Optimized Solutions provide tested and proven best practices for how to run software products on Oracle systems. Learn more.
|
|
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 engineering, end-to-end testing, and documented best practices.
Oracle's Software in Silicon hardwires key software processes directly onto Oracle's SPARC processors to enable high-speed analytics and advanced security features that are not achievable with alternative processor architectures. Oracle's Software in Silicon technology is available in all servers, engineered systems, and Oracle Cloud offerings built utilizing Oracle's SPARC processors.
In this article, we explore the unique capabilities available through Oracle's SPARC processors and Software in Silicon technology and provide a step-by-step how-to guide to lift and shift Oracle Database from a VMware vSphere 6 environment on Red Hat Enterprise Linux (RHEL) to a virtualized Oracle Solaris environment on Oracle's SPARC servers.
Additional articles that might be of interest include "Architecture Matters, Part 1: Assessing Application Migration Impact," which discusses premigration planning considerations, and "Architecture Matters, Part 3: Next Steps—Optimizing for Database Performance, Security, and Availability," which provides an overview of Software in Silicon technology when it is used with Oracle Database 12_c_.
Advantages of Oracle's Software in Silicon–Based Platforms
Performance-demanding needs such as large-scale analytics and long-key cryptographic functions are challenging the limits of traditional processor architectures where incremental gains in clock speed and bandwidth have become the norm. Oracle's Software in Silicon technology represents an alternate approach to address traditional limits by incorporating processing of common algorithms directly in the processor hardware to deliver extreme efficiency and step gains in performance.
Deep integration between Oracle Database 12_c_ and SPARC Software in Silicon technology provides unique advantages for running mixed workloads and analytics and provides increased security through protection against memory errors or attacks and complex data encryption. Unique capabilities include
- Data Analytics Accelerator (DAX) units: Specialized areas on the processor that perform high-speed processing of algorithms common in database queries and analytics. Data moves directly from memory to the DAX units for analysis and only the query results pass to the processor cores, making for extremely fast and efficient analytics processing.
- In-Line Decompression: Hardware-accelerated decompression of data in memory performed by the DAX units, which enables analysis of larger datasets at speed, yielding real-time answers to business analysis questions.
- Silicon Secured Memory: Real-time data integrity checking that guards against the pointer-related software errors and vulnerabilities usually employed by malware.
- Cryptographic acceleration units: Provide high-speed data encryption and decryption with negligible performance overhead and minimal administration. Integrated encryption helps protect both intellectual property and personal information that is increasingly covered under data security regulations.
Accelerating Mixed Workload Environments
Gaining real-time insight into the latest activities is often an organizational goal; however, data on dedicated reporting and analytics systems often lags production systems. To understand up-to-the-minute activities, most online transaction processing (OLTP) production systems provide some reporting functions, but they are generally limited because even moderate reporting or ad hoc queries can affect performance guarantees for interactive users. Using analytic indexes can accelerate query and reporting functions by avoiding large table scans, but indexes also slow down interactive users. As the number of indexes that are used grows, so does the impact on performance.
Oracle Database In-Memory addresses this trade-off and allows serving mixed workloads without the traditional compromises explained above. In addition to the typical row-based data format, Oracle Database In-Memory introduces an in-memory (IM) column store, which holds data in a column-based format that is better suited for reporting and queries (see Figure 1). Normal OLTP operations (for example, inserts, updates, or simple SQL fetches) are serviced out of the row-based datastore while analytics operations are served out of the IM column store, providing optimal performance for both types of operations.
Figure 1: Analytic queries on OLTP databases perform column access instead of row access.
As noted earlier, DAX units are specialized areas on SPARC processors that perform high-speed processing of algorithms that are common in queries and analytics. The DAX units accelerate queries by processing data stored in the IM column store, which leaves processor cores and software licenses free to perform other tasks such as OLTP or application processing. The result, as depicted in Figure 2, is a more efficient system that is able to deliver high performance for mixed workloads using fewer cores and licenses. For more technical information on Software in Silicon and DAX units, please see "Architecture Matters: Accelerate Analytics with Oracle Database In-Memory and Software in Silicon, Part 1 and Part 2."
Figure 2: Software in Silicon efficiencies with the Oracle Database In-Memory option.
A recent Enterprise Strategy Group (ESG) lab report verified the performance acceleration and advantages of Oracle's SPARC servers for mixed Oracle Database workload environments and for pure analytical environments. 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 cores.
High Efficiency of the Oracle Virtualization Stack
A recent Edison Group report has shown that VMware vSphere virtualization contributes to a 7 percent 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. Due to this more efficient platform, Oracle systems can perform more work with fewer processors and licenses, resulting in acquisition and operational savings.
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.
Implications of Migrating Between Processor Types
Oracle's SPARC processors with Software in Silicon use big-endian byte ordering while Intel processors utilize little-endian byte ordering. Therefore, when a database is migrated from a typical Intel system running Linux, a conversion will need to take place. Oracle Recovery Manager (Oracle RMAN) provides for easy conversion during the migration process. Additionally, if a database incorporates stored procedures, those procedures will require a recompile step to ensure they operate properly in the new environment.
Figure 3: Database migration example with endianness conversion.
Summary of the Migration Steps
The following summary outlines steps for performing an Oracle Database instance migration from RHEL x86 to a SPARC server running Oracle Solaris:
- 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.
- 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. 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 accessible by both the source and target systems.
- 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.
- Run the
impdp command to import the exported database. This will import the tablespaces and metadata files generated earlier on the x86 system.
- 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.
- Run validation tests on the database to determine if the database has been migrated properly.
- (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.
Detailed Step-by-Step Migration Example
The following procedure provides detailed step-by-step instructions for migrating and upgrading an Oracle Database instance. A Sales Order Entry (SOE) tablespace is migrated from RHEL 7 over VMware (rhel-vmware-db) to a SPARC S7 processor–based system running Oracle Solaris 11 (oos-sn1-01). The SOE tablespace was created through Swingbench, which is a free load generator (and benchmarks) designed to stress test Oracle Database 11_g_ or 12_c_.
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: This was checked to make sure the time zone matches on both the source and destination. Problems can occur during the import if there is 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 a 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
Replatforming Oracle Database is a frequently used, well-defined, and low-risk process that organizations should not view as a barrier to infrastructure upgrades. Additionally, new capabilities in Oracle's SPARC-based systems are enablers for both enhanced data security and more-intensive analytics to gain deeper insights into business data.
The technique outlined above provides a straightforward method for organizations to perform their own database migration and upgrades. For mission-critical migrations, other techniques are available that minimize or eliminate downtime associated with migrations. Additionally, Oracle Consulting offers migration services for groups that want to leverage outside expertise in their infrastructure redesign and database migrations.
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.
Ken Kutzer is a team lead for Oracle Optimized Solution for Secure Oracle Database and is responsible for driving the strategy and efforts to help raise customer and market awareness for Oracle Optimized Solutions. Kutzer holds a Bachelor of Science degree in electrical engineering and has over 20 years of experience in the computer and storage industries.