Release 8.0
A54650_01
 Library |
 Product |
 Contents |
 Index |
| Oracle8
Server Migration Release 8.0 A54650_01 |
|
This chapter describes the tasks that must be performed before a production database can be migrated. Steps 1 through 3 of the migration process outlined in Chapter 1, "Migration Overview" are also discussed.
The information in this chapter is generic and applies generally to Oracle7 and Version 6 production databases. For migration procedures specific to Oracle8, see Chapter 3, "Migrating to Release 8.0.3 by Migration Utility" or Chapter 4, "Migrating to Release 8.0.3 by Export/Import", and Chapter 5, "After Migrating the Database".
If you are migrating a pre-Oracle8 database system that has Advanced Replication installed, you must also refer to Oracle8 Server Replication, Appendix B, "Migration and Compatibility."
This step comprises several related preparatory actions, which are discussed in the following sections:
Performing these preparatory steps can help ensure that the full migration proceeds smoothly.
Before you plan the migration process, become familiar with the new features of the Oracle8 database. Appendix A, "Oracle8 Enhancements" is good starting point for learning how an Oracle8, Release 8.0.3 database differs from Release 7.3. This appendix lists new features and changes from Release 7.3 and gives specific references for more information about each new feature. If you are using the Parallel Server option, you should also see Oracle8 Parallel Server Concepts & Administration for changes in the Parallel Server.
Attention: You should also take one or more Oracle8 training classes to learn how to take full advantage of the functionality available with Oracle8.
Estimate the system resources required for successful migration by each potential method of migrating the existing source database to Oracle8. Consider the configuration requirements for both the operating system and hardware, the size of the existing production database, and possible size adjustments to it associated with implementing Oracle8. See Appendix F, "General System Requirements for Migration to Oracle8" for details.
Three methods are available for migrating or upgrading a database to Oracle8:
Table 2-1 on page 2-4 summarizes features, advantages, and disadvantages of these three migration methods.
The ultimate success of a migration depends strongly on the design and execution of an appropriate fall back strategy. To formulate such a strategy, carefully take into account the answers to questions such as:
The following sections describe each of the three methods, the relative amounts of time and space they require, and the situations in which they are particularly appropriate. Table 2-1 summarizes the advantages and disadvantages of the three methods.
The Migration Utility converts files and structures in the Oracle7 source database to Oracle8 format, changing only the file headers and possibly changing the definitions of the data in the files. Migration does not affect the data portions of the datafiles, leaving their format and content unchanged.
Advantages and Disadvantages of Migration Methods
The primary advantages of using the Oracle8 Migration Utility are speed and ease of use. The Oracle8 Migration Utility takes significantly less time than Export/Import, and its use entails a standardized series of specific, easy steps.
The Migration Utility is especially good for quickly migrating an entire source database. Unlike Export/Import, the Migration Utility cannot selectively migrate specific datafiles. For databases with large amounts of data, large datatypes, and some other large Oracle7 features, the Migration Utility may be the only practical tool for migration to Oracle8.
The Migration Utility requires only enough temporary space in the SYSTEM tablespace to hold both the Oracle7-source and Oracle8-target data dictionaries simultaneously.
The Migration Utility converts the entire database, including database files, rollback segments, and the control file. At any point before actually migrating the Oracle7 database, you can open and access data with the Oracle7 instance. However, once the Migration Utility has migrated the Oracle7 source database to Oracle8, you can go back to Oracle7 only by restoring a full backup of the Oracle7 source database.
For detailed information about using the Migration Utility, see Chapter 3, "Migrating to Release 8.0.3 by Migration Utility".
Unlike the Migration Utility, the Export/Import utilities physically copy data in the source database to a new database. The source database's Export utility copies specified parts of the source database into an export file. The Oracle8 Import utility can then load the exported data into the new Oracle8 database. However, the new Oracle8 target database must already have been created before the Import utility can be used to migrate the export file.
The following subsections discuss aspects of Export/Import operations that may be pertinent to selecting Export/Import for a migration path. For further information on using Export/Import for migration, see Chapter 4, "Migrating to Release 8.0.3 by Export/Import" and also Oracle8 Server Utilities.
The Export/Import method of migration does not change the source database, which therefore can remain available throughout the migration process; however, if a consistent snapshot of the database is required (for data integrity or other purposes), the source database must be up in restricted mode or otherwise protected from changes during the export procedure. This behavior could, for example, allow an existing Oracle7 production database to continue running while a new Oracle8 database is being built in parallel by Export/Import. (To maintain complete database parallelism no change to the data in the Oracle7 database can be allowed without making the same change to the data in the Oracle8 database.)
The Export/Import method can be used also to upgrade, reverse migrate, or downgrade releases. For example, the transformation of an Oracle8 database back into an Oracle7, Release 7.3, database can be accomplished using the Export/Import method.
The most important effect of the Export/Import operation is that the end result is a completely new database. Although the source database ultimately will contain a copy of the specified data, the resulting migrated database may perform differently from the original source database. As a result of data defragmentation, database restructuring by the DBA, or the upgrade to Oracle8, expect changes in performance, data growth patterns, shared resource usage, data dictionary size, and object organization.
Careful planning and expert implementation and testing are required to take advantage of the possible positive effects of Export/Import on the database; otherwise, the database changes may create problems. If the database was restructured during migration, and the resulting migrated database behaves differently, it may be difficult to determine what changes to attribute to the Export/Import versus what to attribute to the migration to Oracle8. In any event, such a full database rebuild is a major project for a DBA.
Data migration by Export/Import can provide several benefits:
Using Export/Import for migration has several limitations, for example:
Migrating an entire database by Export/Import can take a long time, especially compared with using the Migration Utility. Therefore, you may need to schedule the migration during non-peak, production hours or make provisions for propagating to the new target database any changes that are made to the source database during the migration.
The time and system resources (particularly disk space) required for Export/Import migration depend on DBA skill, database size, and the type of data, particularly the number/size/type of indexes that must be rebuilt.
For example, a relatively simple 6-gigabyte, Oracle7 database was migrated to Oracle8 by the Migration Utility in about an hour. That same Oracle7 database was exported, which produced a single 2-gigabyte export dump file. To import that one export dump file took 20 hours. The complete migration using the steps described in "Migrate the Pre-Oracle8 Source Database Using Export/Import" on page 4-2 took two days.
The extended time Export/Import requires for full database migration of other than small, simple databases typically necessitates attention to several considerations:
When importing data from an earlier version, the Oracle8 Import utility makes appropriate changes to data definitions as it reads earlier versions' export dump files. That is, it handles dump files produced by the Export utilities of Oracle Version 6, Oracle7, and Oracle8. If the export source database is earlier than Oracle Version 6, the source database must first be upgraded to at least Version 6 before the export is performed.
You can copy data from one Oracle database to another Oracle database using database links. For example, you can copy data from a source database table to a target database table with the SQL*Plus COPY command, or you can create new tables in a target database and fill the tables with data from the source database by using the INSERT INTO command, the CREATE TABLE ... FROM command, the CREATE TABLE ... AS command.
Copying data and Export/Import offer the same advantages for migration. By using either for migration you can also defragment data files and restructure the database (that is, create new tablespaces or modify existing tables or tablespaces). You can also migrate only specified database objects or users.
Copying data, however, unlike Export/Import, allows the selection of specific rows of tables to be placed into the target database. Copying data is thus a good method for migrating only part of a database. (In contrast, using the Export/Import utilities to migrate data from Oracle7 to Oracle8, you can load only entire tables.)
For example, to create a new table (NEW_EMP) that contains a subset of the data in an existing table (EMP@V7DB, only those employees in departments 10, 20, and 30), you could use the following Oracle8 or Oracle7 SQL statement:
CREATE TABLE NEW_EMP
(EMPNO NUMBER(4),
ENAME VARCHAR2(10),
JOB VARCHAR2(9),
MGR NUMBER(4),
HIREDATE DATE,
SAL NUMBER(7,2),
COMM NUMBER(7,2),
DEPTNO NUMBER(2)) AS SELECT EMPNO, ENAME, JOB, MGR,
HIREDATE, SAL, COMM, DEPTNO
FROM EMP@V7DB WHERE DEPTNO IS (10, 20, 30);
Copying data requires less disk space and memory buffer space for migration than Export/Import. Copying data requires only that source database and target database both be online. There is no need to allocate large amounts of extra space for temporary files or for Export/Import files.
The SQL COPY command is useful for working with large clustered tables. Further, the SQL*Plus COPY command can move portions of the cluster in parallel using Net8 (or SQL*Net). For more information about copying data from one database to another, refer to the CREATE TABLE command in the Oracle8 Server SQL Reference and to the COPY command in the SQL*Plus User's Guide and Reference.
You need a series of carefully designed tests to validate all stages of the migration process. Executed rigorously and completed successfully, these tests should ensure that the process of migrating the production database will be well understood, predictable, and successful. Perform as much testing as possible before migrating the actual production database. Do not underestimate the importance of such a test program.
Failing to test rigorously before migration is risky and may lead to unpredictable results. The testing plan must include the following types of tests:
Migration testing entails planning and testing the migration path from the source database to the new migrated database, whether you use the Migration Utility, Export/Import, or other data-copying methods to migrate the production database data to the target database. These methods are discussed in Chapter 3, "Migrating to Release 8.0.3 by Migration Utility" and Chapter 4, "Migrating to Release 8.0.3 by Export/Import".
Regardless of what migration method you choose, you must establish, test, and validate a migration plan.
Minimal testing entails moving all or part of an application on the source database to the target database and running the application without enabling any new, target database features. Minimal testing is a very limited type of testing that may not reveal potential issues you may encounter under a production environment. However, any application startup or invocation problems will be revealed immediately.
Functional testing is a set of tests in which new and existing functionality of the system are tested after migrating. Functional testing includes all components of the RDBMS system, networking, and application components. The objective of functional testing is to verify that each component of the system functions as it did before migrating.
Integration testing tests the interaction of each component of the system.
Performance testing of a target database compares the performance of various SQL statements in the target database with the statements' performance in the source database. Before migrating, you should understand the performance profile of the application under the source database. Specifically, you should understand the calls the application makes to the database kernel.
Note: To thoroughly understand the application's performance profile under the source database, enable SQL_TRACE and profile with TKPROF. For more information, see Oracle8 Server Tuning.
Volume and load stress testing tests the entire newly migrated database under high volume and loads. (Volume describes the amount of data being manipulated. Load describes the level of concurrent demand on the system.) The objective of volume and load testing is to emulate how a production system might behave under various volumes and loads.
Volume and load stress testing is crucial, but is commonly overlooked. Oracle Corporation has found that customers often do not conduct any kind of volume or load stress testing. Instead, customers often rely on benchmarks that do not characterize business applications. Benchmarks of the application should be conducted to uncover unknown problems relating to functionality, performance and integration, but they cannot replace volume and load stress testing.
After the source database has been successfully migrated, you should test the data to ensure that all data is accessible and that the applications function properly. You should also determine whether any database tuning is necessary. If possible, you should automate these testing procedures.
The testing plan should be representative of the work performed at the site. You should test the functionality and performance of all applications on the source production databases. Gather performance statistics for both normal and peak usage.
Be sure your testing plan includes:
Collecting this information will help you compare the source and target databases.
Use EXPLAIN PLAN on both the source and target databases to determine the execution plan Oracle follows to execute each SQL statement. Use the INTO parameter to save this information in tables.
After migrating, you can compare the execution plans of the migrated database with the execution plans of the source database. If there is a difference, execute the command on the migrated database and compare the performance with the performance of the command executed on the source database.
Create a test environment that will not interfere with the current production database. Your test environment will depend on the migration method you have chosen.
Practice migrating the database on that test version. Do not migrate the actual production (source) database until after you successfully migrate a test subset of this database and test it with applications, as described in the next step.
Note: The best migration test, if possible, is performed on an exact copy of the database to be migrated, rather than on a downsized copy or test data.
In either case, be sure to upgrade any OCI and precompiler applications that you plan to use with your Oracle8 database. You can then test these applications on a sample Oracle database before migrating your production database.
Refer to the operating system-specific Oracle documentation for information on how to configure a test database so that no operating system variables defined for the production database are affected by the test database.
Perform the planned tests on the Oracle7 source database and on the test database that was migrated to Oracle8. Compare the results, noting anomalies. Repeat Step 1, Step 2, and Step 3, as necessary.
Test the newly migrated Oracle8 test database with existing applications to verify that they operate properly with a migrated Oracle8 database. You might also test enhancing the applications by adding features to use the available Oracle8 functionality. However, you should first make sure that the applications operate in the same manner as they did in the source database. For more information on using the applications with Oracle8, see Chapter 6, "Upgrading Oracle7 Applications".
|
 Copyright © 1997 Oracle Corporation. All Rights Reserved. |
|