2.4 Data Migration Considerations

2.4.1 Data Portability, Well-Known Issues, and Solutions

Data migration is one of the most challenging tasks in the porting process. Data migration activity is primarily divided into two parts:

If the migrated data is to be readable on the target system, data conversion from one format to another, is an important component of any porting effort. Data migration can involve file systems, file content, applications, and database content. Data migration becomes more challenging when the stored data is in an encoded format or it is in a format that is incompatible with the receiving system.

Fortunately, most systems, including Oracle Linux systems, use ASCII to store textual data and a standard text file format. Many data migration tools and toolkits are available in the market, and there are also many free or paid support services offered by database vendors for migrations. By using such services, you can realize significant time and cost savings during the migration and testing process.

Oracle Linux provides many common GNU and legacy applications and utilities for managing data. For example, the GNU tape archive utility (gtar) uses a similar data format and provides common options in both environments. If you are already familiar with another Linux environment, you can usually work seamlessly on Oracle Linux without having to move from your favorite tools and utilities. This commonality is true for many other applications and utilities, and it can yield significant benefits during and after the data migration.

2.4.1 Data Portability, Well-Known Issues, and Solutions

File systems are neutral to endianness in general, and swapping files is not an issue between SPARC/RISC and x86/x86-64 versions of the same operating system. However, applications storing raw data that needs to be shared across platforms can become an issue.

For example, if an application on a SPARC platform writes the data structures in a raw format to the files, the data stored in these files would be endian-dependent. Reading from or writing to these same data files from a system that is based on an x86-64 processor can create problems regarding the endianness of the data. Binary (raw) data stored in a file is generally not transferable between SPARC/RISC and x86/x86-64 platforms.

Applications that share data between platforms can handle the endianness issues in one of the following two ways:

  • Store data in an application-defined, endian-neutral format using text files and strings.

  • Choose either the big-endian or little-endian convention and do byte swapping (potentially using enabling technology such as XDR) when required.

The need for cross-platform compatibility is so well understood that major applications have been available on big-endian and little-endian Linux environments for years without problems. They range from personal productivity applications to major database management systems from Oracle and other vendors.

While there are many similarities between a database running on SPARC or RISC and one running on x86 or x86-64, moving a database from one platform to the other usually requires some data transformation. If the database product is available on both platforms from the same vendor, this task might become as simple as exporting the database to a standardized file format and then importing it into a new database. When the port also involves a change in database vendors, more extensive data transformations might be required. Most enterprise applications rely on information stored in databases to satisfy user requests.

The choice of whether to use an open-source database such as MySQL or a proprietary database such as Oracle Database is driven by cost, application requirements, and business needs. If the same database vendor can be maintained on both platforms, the migration process is much simpler and straightforward.

Although it is challenging to move data between proprietary databases, most database vendors provide tools to assist data migration. For information about migrating from various proprietary databases to Oracle Database, see http://www.oracle.com/technetwork/products/migration/index-084442.html.