Oracle8i Migration Release 8.1.5 A67774-01 |
|
This chapter guides you through the procedures to perform after you have completed a migration using the Migration utility, the Oracle Data Migration Assistant, Export/Import, or data copy. This chapter elaborates on "Step 6: Tune and Adjust the New Production Database".
This chapter covers the following post-migration steps:
Make sure you perform a complete backup of the newly migrated production database. This backup must be complete, including all datafiles, control files, online redo log files, parameter files, and SQL scripts that create objects in the new database. To accomplish a complete backup, a full database export or a cold backup is required, because a hot backup cannot afford full recoverability. This backup can be used as a return point, if necessary, in case subsequent steps adversely affect the newly migrated database.
Note: Using the Migration utility transforms the source database. Therefore, after migration, the source database ceases to exist except for the backup you created under "Preserve the Oracle7 Source Database". This backup also can serve as the first Oracle8i backup for a recovery of the newly migrated database. |
A bad date constraint involves invalid date manipulation, which is a date manipulation that implicitly assumes the century in the date, causing problems at the year 2000. The utlconst.sql
script runs through all of the check constraints in the database and sets constraints as bad if they include any invalid date manipulation. This script selects all the bad constraints at the end.
To run the utlconst.sql
script, complete the following steps:
$ORACLE_HOME/rdbms/admin
directory.
SVRMGR> CONNECT INTERNAL
SVRMGR> SPOOL utlresult.log SVRMGR> @utlconst.sql SVRMGR> SPOOL OFF
After you run the script, the utlresult.log
log file includes all the constraints that have invalid date constraints.
During migration, some bitmap indexes may become unusable. To find these indexes, issue the following SQL statement:
SELECT index_name, index_type, table_owner, status FROM dba_indexes WHERE index_type = 'BITMAP' AND status = 'UNUSABLE';
Rebuild the unusable bitmap indexes listed.
Beginning with release 8.1, parallel execution message buffers can be allocated from large pool. In past releases, this allocation was from shared pool. To avoid problems resulting from this change, you may need to adjust the following parameters in your init
sid
.ora
file:
See Also:
"Parallel Execution Allocated from Large Pool" for information about adjusting these parameters. |
Partition views are not recommended for new applications in Oracle8i, and existing partition views should be converted to partitioned tables. You can convert partition views created for Oracle7 databases to partitioned tables by using the EXCHANGE PARTITION option of the ALTER TABLE command.
See Also:
Oracle8i Administrator's Guide for information about converting partitioned views to partitioned tables and Oracle8i Concepts for background information about partition views and partitioned tables. |
The OUTLN user is created automatically during installation of Oracle8i. This user has DBA privileges. Use the ALTER USER command to change the password for this user. Oracle8i adds the OUTLN user schema to support Plan Stability. The OUTLN user acts as a place to centrally manage metadata associated with stored outlines.
Migrating or upgrading to the new release of Net8 is not required. However, Net8 provides significant advantages over SQL*Net V2, including simplified configuration and expanded functionality. The new release of Net8 also provides the following advantages over past releases of Net8 and SQL*Net:
listener.ora
file.
See Also:
Net8 Administrator's Guide for more information about the advantages of Net8 and for detailed instructions about migrating or upgrading to the new release of Net8. |
If you are using Oracle Enterprise Manager to manage database objects, your listener.ora
file must be configured with information about the database in the following manner:
sid_list_listener_name = (sid_list = (sid_desc = (global_dbname = global_database_name) (oracle_home = oracle_home) (sid_name = sid) ) )
GLOBAL_DBNAME identifies the global database name, which is a name comprised of the database name and domain name of the database. ORACLE_HOME identifies the directory where your Oracle software is installed, and SID_NAME identifies the Oracle System Identifier of the database instance.
For example, the following information is for a database with a listener name of LISTENER. The global database name of SAL.COM is referenced by an instance with a SID of SAL, using the software installed in the /oracle/product/8.1
directory:
sid_list_listener = (sid_list = (sid_desc = (global_dbname = sal.com) (oracle_home = d:/oracle/product/8.1) (sid_name = sal) ) )
If you are not using Oracle Enterprise Manager, you do not need to configure information about the database, because an Oracle8i database instance registers itself with the listener automatically.
See Also:
Net8 Administrator's Guide for more information about configuring the |
Test the Oracle8i database using the testing plan you developed in "Develop a Testing Plan". Compare the results of the test with the results obtained with the original database and make certain the same, or better, results are achieved.
Generally, the performance of the migrated Oracle8i database should be as good as, or better than, the performance of the source database. If you notice any decline in database performance with Oracle8i, make sure the initialization parameters are set properly, because improperly set initialization parameters can hurt performance.
Besides testing the migrated test database, you may run the original source database and the newly migrated Oracle8i database concurrently for a time, to make sure that the new database is configured correctly and functioning properly. To run both databases concurrently, you must modify the Oracle configuration. Of course, synchronized updates would need to be made to both databases, ideally as part of an automated process.
If you want to improve the performance of the migrated database, tune the database. Most of the actions normally used to tune Oracle7 databases and related applications either have the same effect on or are unnecessary for Oracle8i databases. Therefore, actions you used to tune your source database and applications should not impair the performance of the migrated Oracle8i database.
Getting to Know Oracle8i describes many of the new features available in Oracle8i. Determine which of these new features can benefit the migrated database and applications; then, develop a plan for using these features.
It is not necessary to make any immediate changes to begin using your migrated Oracle8i database. You may prefer to introduce these enhancements into your database and corresponding applications gradually.
Chapter 9, "Upgrading Your Applications", describes ways to enhance your applications so that you can take advantage of the new Oracle8i features. However, before you implement new Oracle8i features, test your applications and successfully run them with the migrated database.
After familiarizing yourself with the Oracle8i features, review your database administration scripts and procedures to determine whether any changes are necessary.
Coordinate your changes to the database with the changes that are necessary for each application. For example, by enabling integrity constraints in the database, you may be able to remove some data checking from your applications.