19Tuning the Siebel Production Upgrade Scripts
Tuning the Siebel Production Upgrade Scripts
This chapter describes the ways in which you can improve the performance of the production environment upgrade by tuning the production upgrade scripts in a test environment. This chapter contains the following topics:
About Tuning the Upgrade Scripts
Upgrades: All upgrades.
Environments: Production test environment only. Does not apply to production environment.
You can tune the SQL upgrade scripts in a production test environment to improve their performance and then reuse these tested scripts in the live production environment. For example, the scripts used to upgrade your Siebel database are generic. They update your Siebel database to support all Siebel applications’ functionality. You can reduce downtime by tuning these scripts to optimize performance by eliminating SQL statements that are not required. You can then reuse these revised scripts in your production upgrade.
You can tune your production upgrade scripts at any time after upgrading the Siebel database schema in your production test environment.
Contacting Oracle’s Advanced Customer Services
You are required to contact your Oracle sales representative for Oracle Advanced Customer Services to request approval for any upgrade script tuning that you perform. If you do not, you might invalidate your support agreement. It is recommended (but not required) that you contact Oracle’s Advanced Customer Services for help with the following tasks:
Running load and unload jobs in parallel
Changing the job submission order of load and unload jobs
If you want to change the submission order of jobs other than the load and unload jobs, you must first obtain approval from Oracle’s Advanced Customer Services because many jobs have dependencies on other jobs and must be submitted in a specified sequence.
Optimizing Unload and Load Job Performance
Upgrades: All upgrades.
Environments: Production test environment only. Does not apply to production environment.
This topic describes ways in which you can improve the performance of the unload and load jobs for the production upgrade. You can do the following:
Optimize the unload and load jobs to reach maximum parallelism:
Run as many of the unload / load jobs in parallel as the DB2 subsystem can support.
Change the generated REXX exec job submission order to submit the longest running unload/load jobs first.
If all the unload jobs are run in parallel, the shortest amount of time this process can take is the length of time it takes for the longest unload job to complete.
For partitioned tables, split the unload files so that data is unloaded and loaded in parallel for each partition. Add the WHERE clause to the unload SQL to control the data that is unloaded.
Overlap load and unload jobs.
Once an unload job for a table has completed, the load job for that table can be started (assuming you have a schema structure consisting of one table for each table space). This means that load jobs can be running at the same time as unload jobs.
Add the ORDER BY clauses to the unload SQL to load data in clustering sequence (you must manually add ORDER BY clauses to the unload SQL).
The *.pretedit.jcl (pretkeys) job builds ORDER BY clauses for individual tables into the data set *.syskeys.orderby.
Use third-party utilities to accelerate the unload/load process.
Note: Before using third-party utilities, you are required to contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance.You can use the DB2 Cross Loader (an option of the IBM Load utility) to load data directly from the source to the target database, thereby eliminating the unload step.
Populate new columns as part of the unload SQL.
Note: If you want to populate new columns as part of the unload SQL, you are required to contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance.Add any large tables to *.TABLIST so that the unload and load processes use the large proc, SIEBEL.PROC(SV7LD10L), which allocates more memory, instead of using the standard proc, SIEBEL.PROC(SV7LD10S).
Adding the Statistics Clause to Load Cards
Upgrades: All upgrades.
Environments: Production test environment only. Does not apply to production environment.
If your database schema structure follows the 1:1:1 model, and if LOAD REPLACE is specified on a load card (so tables are loaded from scratch), you can improve upgrade performance by collecting statistics while running the load job rather than having to run a separate RUNSTATS job. You can do this by adding the STATISTICS clause to the load cards, for example:
STATISTICS TABLE(ALL) INDEX(ALL) UPDATE ACCESSPATH