- It is very difficult to estimate the time required to upgrade the database from one version to another.
- While upgrading database either manually or using DBUA the time taken for the upgrade is relatively independent from the size of the database. It rather depends upon the amount of work to be done to load the data dictionary of the target version.
- For example, upgrading a database from 10gR1 to 10gR2 will takes less time comparatively than an upgrade from 9iR2 to 10gR2, because there are fewer dictionary changes to move from 10gR1 to 10gR2 than 9iR2 to 10gR2.
- As a part of upgrade all PL/SQL is invalidated, therefore a database with more number of objects to be recompiled will take more time to upgrade than a database with fewer objects.
- The time taken to upgrade a database does not depend on size of the database, because during upgrade the data blocks are not touched. The time consuming part is the recompilation part and this depends on the number of objects to recompile and the CPU power, one good idea will be to recompile in parallel to save time, the DBUA offers this by allowing to choose the number of parallel threads if there is more than one CPU, the same can be accomplished while running utlrp.sql manually by calling it with a value of parallelism.
- During the upgrade, optimizer statistics are collected for dictionary tables that lack statistics. This statistics collection can be time consuming for databases with a large number of dictionary tables, but statistics gathering only occurs for those tables that lack statistics or are significantly changed during the upgrade. To decrease the amount of downtime incurred when collecting statistics, you can collect statistics prior to performing the actual database upgrade.
- If the database is running in archive log mode then it is a good idea to turn off archiving for the duration of upgrade to reduce the time required to complete the upgrade.
- While upgrading database either manually or using DBUA the time taken for the upgrade is relatively independent from the size of the database. It rather depends upon the amount of work to be done to load the data dictionary of the target version.
- For example, upgrading a database from 10gR1 to 10gR2 will takes less time comparatively than an upgrade from 9iR2 to 10gR2, because there are fewer dictionary changes to move from 10gR1 to 10gR2 than 9iR2 to 10gR2.
- As a part of upgrade all PL/SQL is invalidated, therefore a database with more number of objects to be recompiled will take more time to upgrade than a database with fewer objects.
- The time taken to upgrade a database does not depend on size of the database, because during upgrade the data blocks are not touched. The time consuming part is the recompilation part and this depends on the number of objects to recompile and the CPU power, one good idea will be to recompile in parallel to save time, the DBUA offers this by allowing to choose the number of parallel threads if there is more than one CPU, the same can be accomplished while running utlrp.sql manually by calling it with a value of parallelism.
- During the upgrade, optimizer statistics are collected for dictionary tables that lack statistics. This statistics collection can be time consuming for databases with a large number of dictionary tables, but statistics gathering only occurs for those tables that lack statistics or are significantly changed during the upgrade. To decrease the amount of downtime incurred when collecting statistics, you can collect statistics prior to performing the actual database upgrade.
- If the database is running in archive log mode then it is a good idea to turn off archiving for the duration of upgrade to reduce the time required to complete the upgrade.
- The best method to determine the approximate time required to upgrade an instance is to test the upgrade on an exact clone of the instance on similar hardware with a similar load. This can provide a reasonable approximation on how long to expect and if any issues may be encountered in the process.
No comments:
Post a Comment