Previous	Next		Contents	Index	Glossary

Step 1 Partitioning Workflow Tables

If you are using the version of Oracle Workflow embedded in Oracle Applications, you can optionally run a script called wfupartb.sql to partition certain Workflow tables. This step is highly recommended for performance gain.

The script partitions the following tables and recreates the associated indexes:

Table	Index
WF_ITEM_ACTIVITY_STATUSES	WF_ITEM_ACTIVITY_STATUSES_PK
	WF_ITEM_ACTIVITY_STATUSES_N1
	WF_ITEM_ACTIVITY_STATUSES_N2
WF_ITEM_ACTIVITY_STATUSES_H	WF_ITEM_ACTIVITY_STATUSES_H_N1
	WF_ITEM_ACTIVITY_STATUSES_H_N2
WF_ITEM_ATTRIBUTE_VALUES	WF_ITEM_ATTRIBUTE_VALUES_PK
WF_ITEMS	WF_ITEMS_PK
	WF_ITEMS_N1
	WF_ITEMS_N2
	WF_ITEMS_N3

Before running wfupartb.sql, you should back up these four tables so that you can restore them in case the script fails.

To run the script, you must have sufficient free space on the table and index tablespaces. During the creation of the partitioned tables, the script requires slightly more diskspace than the underlying tables, in the same tablespace where the underlying tables are located. Similarly, sufficient free space is required for the index tablespace.

Additionally, you should allow sufficient time for the script to run. The amount of time needed depends on the amount of data in the tables. When the tables already contain existing data, such as after an upgrade from a previous release, the script requires more time than it does when the tables are empty, such as after a fresh installation of Oracle Workflow. To minimize the time required, run the script as early as possible in your setup process.

Attention: If you are running wfupartb.sql through SQL*Net, then you must set the TWO_TASK variable before you begin.

The script is located in the admin/sql subdirectory under $FND_TOP. Use the script as follows:

sqlplus <apps_user>/<apps_passwd> @wfupartb <fnd_user>  

<fnd_passwd> <apps_user> <apps_passwd>

For example:

sqlplus apps/apps @wfupartb applsys apps apps apps

If the script fails, you must perform any necessary cleanup manually. Since the script's operations are DDL operations running in nologging mode, rollback is not possible.

Context: You need to perform this step only once.