Peoplesoft Enterprise Performance On Oracle 10G Database

PeopleSoft Enterprise Performance
on Oracle 10g Database

12/8/2021 PeopleSoft Red Paper
PEOPLESOFT 8 BATCH PeopleSoft 8 Batch

PERFORMANCE ON ORACLE
9I DATABASE
Performance on Oracle 9i
Database
12 / 8 / 2 0 2 1
Reference Number:
Product(s): All Enterprise products
Release(s): PeopleSoft 8.x, 9.x
Revision Number:
Contains:
 PeopleSoft Performance Tips
 Database Tuning Tips
 SQL Query Tuning Tips
 Use of Database Features
 Capturing Traces
© Copyright © 2006 Oracle, Inc. All rights reserved. i

Table of Contents
Table of Contents..................................................................................................................................................... ii
Chapter 1 - Introduction........................................................................................................................................... 1
Structure of this Red Paper 1
Related Materials 1
Chapter 2 - Generating Statistics........................................................................................................................... 2

Manually Gathering Table Statistics 2
Sample DBMS_STATS Command:............................................................................................................................................3
Generating Statistics for Data dictionary tables 3
Generating System Statistics.......................................................................................................................................................4
Statistics at Runtime for Temporary Tables 4
Example.......................................................................................................................................................................................4
Turning off %UpdateStats...........................................................................................................................................................5
Modify %UpdateStats to use Analyze command:......................................................................................................................5
Tuning off Dynamic Sampling:...................................................................................................................................................9
Histograms 9
What are Histograms?.................................................................................................................................................................9
Candidate Columns for Histograms Within PeopleSoft Applications.....................................................................................10
Creating Histograms..................................................................................................................................................................10
Viewing Histograms..................................................................................................................................................................10
Chapter 3 - Dedicated Temporary Tables............................................................................................................. 11

What are Dedicated Temp Tables? 11
Performance Tips for Dedicated Temp Tables.........................................................................................................................11
Application Engine Performance with Dedicated Temporary Tables 12
How do temp tables work in Application Engine?...................................................................................................................12
Test case explaining temp table behavior.................................................................................................................................12
Creating PeopleSoft Temporary Tables as Oracle Global Temp Tables (GTT) 14
What are Global Temporary Tables?........................................................................................................................................14
Can GTTs be used in place of Dedicated Temp Tables?.........................................................................................................15
Chapter 4 - Tablespace Selection.......................................................................................................................... 15

Locally Managed Tablespaces 15
Advantages of Locally Managed...............................................................................................................................................15
Space Management....................................................................................................................................................................15
Locally Managed - AUTO ALLOCATE..................................................................................................................................15
Locally Managed - UNIFORM EXTENT................................................................................................................................15
Temporary Tablespaces 16
Tempfile based...........................................................................................................................................................................16
UNDO Management 16
Automatic Undo Management..................................................................................................................................................16
Table/Index Partitioning 17
What Is Partitioning?.................................................................................................................................................................17
© Copyright © 2006 Oracle, Inc. All rights reserved. ii
Chapter 5 - Maintaining Indexes............................................................................................................................ 18

Index Tips 18
Rebuilding of Indexes 18
Function Based Indexes 19
Chapter 6 - Cursor Sharing.................................................................................................................................... 21

Use of Bind Variables 21
Application Engine - Reuse Flag..............................................................................................................................................21
SQR/COBOL - CURSOR_SHARING 24
Pros and Cons of CURSOR_SHARING...................................................................................................................................25
Chapter 7 - Batch Server Selection....................................................................................................................... 27

Scenario 1: Process Scheduler And Database Server on Different Boxes 27
Scenario 2: Process Scheduler and Database Server on one BOX 27
What is the recommended scenario? 28
Chapter 8 - Capturing Traces................................................................................................................................ 29

Online Performance Issues 29
Configuration Settings for Tracing an Online Process.............................................................................................................29
Application Engine Performance Issues 31
Configuration Settings for Tracing an AE Process on the Application Engine.......................................................................31
Configuration Settings for Tracing an AE Process on the Database........................................................................................32
COBOL Performance Issues 34
SQR Reports Performance Issues 34
ORACLE Performance Issues 34
Generating Explain Plan for SQL Using “sqltexplain.sql” 35
Automatic Workload Repository (AWR) 35
Generating a HTML or Text AWR Report:..............................................................................................................................35
AWR REPORT ANALYSIS:....................................................................................................................................................36
Time Model Statistics................................................................................................................................................................37
Appendix A – Sample script to gather statistics on tables................................................................................41
Appendix B – Validation and Feedback................................................................................................................ 46

Customer Validation 46
Field Validation 46
Appendix C - References....................................................................................................................................... 47
Appendix D – Revision History............................................................................................................................. 48

Authors.......................................................................................................................................................................................48
Reviewers...................................................................................................................................................................................48
Revision History........................................................................................................................................................................48
© Copyright © 2006 Oracle, Inc. All rights reserved. iii

Chapter 1 - Introduction
This Red Paper is a practical guide for technical users, database administrators, and programmers who implement,
maintain, or develop applications for a PeopleSoft system. In this Red Paper, we discuss guidelines on how to
improve the performance of PeopleSoft applications in the Oracle 10g environment.
Much of the information contained in this document originated within the PeopleSoft Benchmarks and Global
Support Center and is therefore based on "real-life" problems encountered in the field. The issues that appear in
this document are the problems that prove to be the most common or troublesome.
STRUCTURE OF THIS RED PAPER

This Red Paper provides guidance to get the best performance of PeopleSoft in the Oracle database environment.
Keep in mind that PeopleSoft updates this document as needed so that it reflects the most current feedback we
receive from the field. Therefore, the structure, headings, content, and length of this document is likely to vary with
each posted version. To see if the document has been updated since you last downloaded it, compare the date of
your version to the date of the version posted on Customer Connection.
RELATED MATERIALS
This paper is not a general introduction to environment tuning and we assume that our readers are experienced IT
professionals, with a good understanding of PeopleSoft’s Internet Architecture and Oracle database. To take full
advantage of the information covered in this document, we recommend that you have a basic understanding of
system administration, basic Internet architecture, relational database concepts/SQL, and how to use PeopleSoft
applications.
This document is not intended to replace the documentation delivered with the PeopleTools 8 or 8.4 PeopleBooks.
We recommend that before you read this document, you read the PeopleSoft application related information in the
PeopleBooks to ensure that you have a well-rounded understanding of PeopleSoft batch process technology.
Note: Much of the information in this document eventually gets incorporated into subsequent versions of the
PeopleBooks.
Many of the fundamental concepts related to performance tuning in PeopleSoft PeopleBooks:
 PeopleSoft Installation Guide - Oracle Tuning chapter
Additionally, we recommend that you read the Oracle 10g database administration and performance tuning guides.
© Copyright © 2006 Oracle, Inc. All rights reserved. 1

Chapter 2 - Generating Statistics
When using Oracle's Cost Based Optimizer (CBO), query performance depends greatly on appropriate table and
index statistics. Maintenance of these statistics is critical to optimal database and query performance. At database
creation, Oracle 10g Scheduler contains a default nightly job which attempts to maintain these vital statistics.
You can determine whether this job exists by viewing the DBA_SCHEDULER_JOBS view. A sample SQL
statement is listed below.
SELECT *
FROM DBA_SCHEDULER_JOBS
WHERE JOB_NAME = 'GATHER_STATS_JOB';
Since this job does not/cannot take into account the requirements for PeopleSoft, it is not recommended to allow
this job to run after it has initially executed. It is recommended to disable this job after initial execution.
To disable the GATHER_STATS_JOB execute the following SQL*Plus command:
BEGIN
DBMS_SCHEDULER.DISABLE('GATHER_STATS_JOB');
END;
/
The reasoning for this recommendation is because PeopleSoft Application Engine (AE) programs use many
“standard” Oracle tables as PeopleSoft “temporary” tables. The default “GATHER_STATS_JOB” will pick up the
“temporary” tables, and re-generate statistics on them which is not desirable as many will not contain data.
Only “non-temporary” PeopleSoft tables and indexes are recommended to have their statistics updated. It is also
recommended that only tables and indexes, that are considered “stale” or “missing” by the database, have their
statistics re-generated. A sample script to provide this functionality is listed in the Appendix. By generating
statistics only on the “non-temporary” tables and indexes, the “temporary” object statistics are not updated with
improper values. By re-generating statistics only on “stale” or “missing” objects, the over all time needed to re-
generate statistics on a nightly/weekly/monthly basis is reduced.
It is not recommended that statistics be gathered on objects during peak operational hours. Cursor invalidation
could cause severe performance degradation.
It is advisable to gather statistics periodically for objects where the statistics become stale over time because of
changing data volumes or changes in column value. New statistics should be gathered after a schema object's data
or structure are modified in ways that make the previous statistics inaccurate. For example, after loading a
significant number of rows into a table, collect new statistics on the number of rows. After updating data in a table,
you need new statistics on the average row length.You should use DBMS_STATS package to update statistics. It
is not possible to recommend a single command line on how to update statistics nor the frequency on when to
update statistics since this is dependent on many factors like data distribution, business rules, time and window of
each organization. You need to work with your DBA to come up with a strategy to do that.
MANUALLY GATHERING TABLE STATISTICS

The DBMS_STATS package provides the ability to generate statistics in parallel by specifying the degree of
parallelism. The ability to generate statistics in parallel significantly reduces the time needed to refresh object
statistics.
Note: The use of procedures within DBMS_STATS is recommended exclusively. ANALYZE will be de-supported in
future releases of Oracle.

Sample DBMS_STATS Command:
EXECUTE DBMS_STATS.GATHER_TABLE_STATS( OWNNAME => 'ORAVOL'

,TABNAME => 'PS_CUSTOMER'
,PARTNAME => NULL
,ESTIMATE_PERCENT => DBMS_STATS.AUTO_SAMPLE_SIZE
,METHOD_OPT =>'FOR ALL COLUMNS SIZE AUTO'
,DEGREE => 5
,CASCADE => TRUE );
Note: Specifying “NULL” for “ESTIMATE_PERCENT” will provide the same functionality as ANALYZE’s
“COMPUTE”. Using a value of “100” is not the same as “COMPUTE”. The default value for
“ESTIMATE_PERCENT” is “DBMS_STATS.AUTO_SAMPLE_SIZE” and is the recommended value only if the data
composition is unknown. Sometimes, “AUTO_SAMPLE_SIZE” can perform slowly for large tables. Values
between “5%” and “20%” tend to provide the best balance between speed and calculation accuracy. Execute tests
to find the appropriate value.
Data distribution is also gathered when using DBMS_STATS. The most basic information about the data
distribution is the maximum value and minimum value of the column within a table. However, this level of statistics
may not be sufficient for the optimizer's needs if the data within the column is skewed. With the “METHOD_OPT”
parameter set to “For All Columns Size Auto”, Oracle will automatically determine which columns require
histograms and the number of buckets (size) of each histogram. The default value is “For All Columns Size Auto”.
The size_clause is defined as size_clause:= SIZE {integer | REPEAT | AUTO | SKEWONLY}
 integer : Number of histogram buckets: Range [1 to 254].
 REPEAT : Collects histograms only on columns that already have histograms.
 AUTO : Determines the columns to collect histograms based on data distribution and the workload of the
columns.
 SKEWONLY : Determines the columns to collect histograms based on the data distribution of the columns.
Note: It is strongly recommended to read Note 237293.1 of Oracle Metalink. This note includes a set of notes which
help DBA through examples to move updating statistics from ANALYZE to DBMS_STATS.
With the “CASCADE” parameter set to “TRUE,” the associated indexes will also be analyzed. The default setting
for “CASCADE” is “FALSE”.
Note: Specifying the DEGREE will only help run gather table statistics (Partitioned or Non-Partitioned) in parallel.
The index statistics cannot make use of this flag and does not run in parallel.
GENERATING STATISTICS FOR DATA DICTIONARY TABLES

It is recommended to generate statistics on dictionary tables after initial database is loaded with data and also
whenever database size has increased considerably. An example of this command is as follows:
EXECUTE DBMS_STATS.GATHER_DICTIONARY_STATS( estimate_percent =>

DBMS_STATS.AUTO_SAMPLE_SIZE
,degree => 5
,cascade => TRUE
,options => 'GATHER AUTO' );

Generating System Statistics
When Oracle gathers system statistics, it analyzes system activity in a specified time period (workload statistics) or
simulates a workload (no workload statistics). The statistics are collected using the
DBMS_STATS.GATHER_SYSTEM_STATS procedure. It is highly recommended that system statistics be
gathered.
EXECUTE DBMS_STATS.GATHER_SYSTEM_STATS (gathering_mode => 'NOWORKLOAD');
Note: User must have DBA privileges or GATHER_SYSTEM_STATISTICS role to update dictionary or system
statistics.
STATISTICS AT RUNTIME FOR TEMPORARY TABLES

PeopleSoft uses shared and, or dedicated temporary tables in the batch processes. These temporary tables will
have few or no rows in the beginning of the process. At the end of the process, these tables will again have few or
no rows. Keeping the statistics up to-date for these tables is somewhat challenging. A temporary table’s life cycle
is as follows:
1. All rows are truncated (if dedicated) or deleted (if shared) at the beginning of an AE execution
automatically.
2. Rows are populated.
3. All rows are truncated (if dedicated) or deleted (if shared) at the end of an AE execution, if the programmer
has requested. This is not performed automatically.
Beginning with PeopleSoft 8, an AE program can use the meta-SQL “%UpdateStats ” after rows are populated into
a temporary table. Doing so would update statistics on the temporary table prior to the table’s use in following SQL
statements.
Note: Commit is required prior to executing the %UpdateStats statement. Due to the implicit commit feature that
Oracle uses when performing DDL (Statistics gathering is considered DDL), the AE will ignore the %UpdateStats
command after any uncommitted changes. Allowing the implicit commit may affect the restart capability of the
program.
Example
Command in SQL Step of an Application Engine program: %UpdateStats(%Table(INTFC_BI_HTMP))
This meta-SQL starting with Peopletools 8.48 will issue the Oracle database command:
DBMS_STATS.GATHER_TABLE_STATS (ownname=> [DBNAME], tabname=>[TBNAME],
estimate_percent=>1, method_opt=> 'FOR ALL COLUMNS SIZE 1',cascade=>TRUE);
at runtime.
Note: To reduce the increased overhead of DBMS_STATS at runtime (when compared to ANALYZE with
estimate), the ESTIMATE_PERCENT parameter was set to “1”.
Note: PeopleSoft stores the default syntax for the gather stats command in a table PSDDLMODEL. Use the
supplied script (DDLORA.DMS) to change the default setting or to add a required SAMPLE ROWS/PERCENT for
the ESTIMATE clause.

For example:
Let’s assume, we want to change the ESTIMATE_PERCENT option of LOW option to be 5% and HIGH option to
be 80%.
1. Edit the DDLORA.DMS delivered script:
The first occurrence of the DBMS_STATS is used for the LOW option of %UpdateStats. The second one is
used for the HIGH option of %UpdateStats.
4,2,0,0,$long
estimate_percent=>5, method_opt=> 'FOR ALL INDEXED COLUMNS SIZE 1',cascade=>TRUE);
//
5,2,0,0,$long
estimate_percent=>80, method_opt=> 'FOR ALL INDEXED COLUMNS SIZE 1',cascade=>TRUE);
//
2. Run the modified DDLORA.DMS through DataMover.
Make sure the temporary table statistics have been handled as shown above. If you find any temporary table that
was not updated during the run time, then plan to use a manual method of updating the statistics.
Turning off %UpdateStats
Note: Due to this change affecting the entire process scheduler, it is highly not recommended to turn this feature
off.
Having the update statistics at the runtime incurs some overhead. If this feature is to be turned off, check the
process scheduler documentation.
Modify %UpdateStats to use Analyze command:

If you suspect that DBMS_STATS is causing performance degradation of your AE process, you can review your
AE trace, and look for statements that used the “RECSTATS” command:
-- 17.44.18 .........(GL_JEHDR.InsBalT.UpdStat) (SQL)
RECSTATS PS_JCF_BAL_TAO4 LOW
/
 Row(s) affected: 1
C o m p i l e E x e c u t e F e t c h
Total
SQL Statement Count Time Count Time Count Time Time
InsBalT.UpdStat. S 2 0.0 2 19.5 0 0.0 19.5
Once you confirm that using DBMS_STATS to update statistics is causing a lot of overhead when compared to
“Analyze with estimate” when using %Updatestats, you can revert %Updatestats to use the Analyze command by
doing the followings:
Step 1: Create PSSTATS package as follows:
Login SQLPLUS as PeopleSoft Dbowner to create the following PSSTATS package.

CREATE OR REPLACE PACKAGE PSSTATS AS
PROCEDURE ANALYZE_TABLE (tab_name VARCHAR2, stats_mode varchar2);
END PSSTATS;
CREATE OR REPLACE PACKAGE BODY PSSTATS AS
PROCEDURE ANALYZE_TABLE (tab_name IN VARCHAR2, stats_mode varchar2) IS
command_text VARCHAR2(2000);
BEGIN
if stats_mode <> 'HIGH' then
command_text := 'ANALYZE TABLE '||tab_name||' ESTIMATE STATISTICS';
else
command_text := 'ANALYZE TABLE '||tab_name||' COMPUTE STATISTICS';
end if;
EXECUTE IMMEDIATE command_text;
END ANALYZE_TABLE;
END PSSTATS;
Step 2: Modify SQL#4 and SQL#5 DDL Model Defaults for Oracle Platform.
2.1) Navigate to DDL Model Defaults
Navigation: PeopleTools -> Utilities -> Administration -> DDL Model Defaults
Click the “Search” button and then choose “Oracle” Platform.

2.2) Choose SQL #4 (out of 5) for Oracle Platform.
Copy “Model SQL” from PIA page to text file so that you can revert back to using DBMS_STATS in the future if you
so choose.
2.3) Replace SQL#4 (out of 5) for Oracle Platform.

psstats.analyze_table(tab_name=>[TBNAME],stats_mode=>'LOW');
2.4) Choose SQL #5 (out of 5) for Oracle Platform.
Copy “Model SQL” from PIA page to text file so that you can revert back to using DBMS_STATS in the future if you
so choose.
2.5) Replace SQL#5 (out of 5) for Oracle Platform.
psstats.analyze_table(tab_name=>[TBNAME],stats_mode=>'HIGH');
This change will affect any PeopleSoft programs that use %UpdateStats, and DataMover import scripts with option
“Set statistics on” (On is the default value).
Note: Due to this change affecting all the programs using %UpdateStats, it is highly recommended to do
regression test throughly before implementing in Production. It is not recommended to use Analyze to update
statistics during regular database maintenance window.
Tuning off Dynamic Sampling:
Dynamic Sampling was introduced in Oracle 9i. How does Dynamic Sampling work? Oracle determines at compile
time whether a query would benefit from dynamic sampling. If so, a recursive SQL statement is issued to scan a
small random sample of the table's blocks, and to apply the relevant single table predicates to estimate predicate
selectivities. The sample cardinality can also be used, in some cases, to estimate table cardinality. Any column and
index statistics are also collected on the fly. This feature is controlled by the initialization parameter named
OPTIMIZER_DYNAMIC_SAMPLING.
Since most of PeopleSoft programs use %UpdateStats to manage statistics of our temporary tables so we
recommend to turn this parameter off by setting the following:
OPTIMIZER_DYNAMIC_SAMPLING = 0
HISTOGRAMS
What are Histograms?
Histograms provide improved selectivity estimates in the presence of data skew, resulting in optimal execution
plans with non-uniform data distributions. A histogram partitions the values of the column into bands, so that all
column values in a band fall within the same range. CBO uses data within the histograms to get accurate
estimates of the distribution of column data.

Oracle uses height-balanced histograms or frequency based histograms based on the number of distinct values
and the number of bands. Please refer to Oracle documentation for more details.
Candidate Columns for Histograms Within PeopleSoft Applications
Histograms can affect performance and should be used only when they substantially improve query plans. In
general, histograms should be created on:
1. Columns that are frequently used in WHERE clauses of queries.

2. Have a highly skewed data distribution.
3. Literal value is provided instead of using a bind variable for the given column in the where clause.
Histograms are persistent objects. So, there are maintenance and storage costs for using them.
For uniformly distributed data, the CBO can make fairly accurate estimates about the cost of executing a particular
statement without the use of histograms. Histograms, like all other optimizer statistics, are static and only change
when new statistics are generated with the “SIZE” option within the DBMS_STATS procedures.
Histograms are not useful for columns with the following characteristics:
 Column data is uniformly distributed.

 Column is not used in WHERE clauses of queries.
 Column is unique.
 Column is used in the where clause but contains a bind variable instead of a literal.
Note: “Bind Peeking” (BP) was designed to “fix” the last bullet point above. But, due to additional issues BP
causes, the use of BP is not recommended.
Columns such as PROCESS_INSTANCE, ORD_STATUS are likely candidates that benefit from histograms.
Creating Histograms
Creation of specific column histograms is no longer needed as long as “DBMS_STATS” procedures are used with
the “METHOD_OPT” parameter containing “SIZE AUTO”. Based on column usage within runtime SQL “where
clauses” and the amount of data skew within the column, the “SIZE AUTO” value instructs the “DBMS_STATS”
procedure that only columns benefiting from histograms are to be generated.
Note: If any other value for “METHOD_OPT” is provided (ex. “… SIZE 1” or “… SIZE REPEAT”), the automatic
creation of histograms is deactivated.
Viewing Histograms
Information about whether a table contains histograms can be displayed using the following dictionary views:
 USER_HISTOGRAMS
 ALL_HISTOGRAMS
 DBA_HISTOGRAMS
The number of bands within a column’s histogram can be displayed using the following dictionary views:
 USER_TAB_COLUMNS
 ALL_TAB_COLUMNS
 DBA_TAB_COLUMNS

Chapter 3 - Dedicated Temporary Tables
WHAT ARE DEDICATED TEMP TABLES?

Batch processes written in Application
Engine use PeopleSoft designated
temporary tables (also called as
“Dedicated Temporary Tables”) for
better processing. This technique
minimizes potential locking issues and
improves processing time.
These are regular Oracle tables but

flagged as temporary in the
PeopleSoft dictionary tables. When
implemented on Oracle databases,
PeopleSoft designated temporary
tables are built using Oracle tables.
Required temp tables are linked to the
AE program in the program property
window. And the required number of
instances is also specified for each
AE program.
Here is the property window for the AE

program Bill Finalization (BIIF0001):
The instance count specified here is

the limit on the number of a temp
table's instances that can be used
when multiple instances of the
program are run. If the number of
programs run are more than the
specified count (10 in this example),
then the additional processes will be
abandoned or the base temp tables
will be used depending on the Runtime
radio button selection in the above window.
Performance Tips for Dedicated Temp Tables
If issues are found with parallel truncates on dedicated tempory tables, create seperate tablespace for the these
tables with a block size that is greater (if possible) than the current standard tablespace block size. Then, configure
the initialization parameters of the database to include a seperate buffer cache for this new block size. This may
lessen the contention during parallel truncates.
APPLICATION ENGINE PERFORMANCE WITH DEDICATED TEMPORARY TABLES

How do temp tables work in Application Engine?
Based on the number of temp tables that are associated to an application engine program and the number of
instances setup for the program, the appropriate temp table instance will be used during the runtime.
Test case explaining temp table behavior
Here is the sample scenario that explains the temp table usage.
Tools
Temp table settings
Properties
Setup the Temp Tble Instance (online)
as per the requirement. Temp Tble
Instance (Total) will be same as the
online number, unless you are using
EPM.
Setup the Instance Count to the required value. This should

AE Properties be equivalent to the number of concurrent streams you are
planning to run.
Choosing the Continue for the runtime option will use the base
temp table if there are no temp table instances available at the
time of run.
If the Batch Only option is selected, that means

that the program will not be called from online. You
PROCESS
don’t need to change this setting unless you are
PROCESS
4
advised to do so.
5
Number of temp table instances
Number of Temp Tables (Online) = 3
Number of Temp Tables (AE Program) = 3
Scenario 1: ‘Batch Only’ option is not selected
Total number of temp table instances created for each temp table associated to the AE program = Base Temp
Table + Number of Temp Tables (Online) + Number of Temp Tables (AE Program)
= 1+3+3 = 7
Scenario 2: ‘Batch Only’ option is selected
Total number of temp table instances created for each temp table associated to the AE program = Base Temp
Table + Number of Temp Tables (AE Program)
= 1+3 = 4

In this example we will be looking at Scenario 2.
Not advisable
Temp table
AE PROCESS
allocation AE PROCESS
STREAM 4 AE PROCESS AE PROCESS AE PROCESS
AE PROCESS
STREAM 5
When the program STREAM 6 STREAM 1 STREAM 2 STREAM 3
runs for the first time,
temp table instance 1
will be used. The TAB1_TAO TAB1_TAO1 TAB1_TAO2 TAB1_TAO3
subsequent parallel
streams will use the TAB2_TAO TAB2_TAO1 TAB2_TAO2 TAB2_TAO3
rest of the instances
in sequence. In this
example, the first TAB3_TAO TAB3_TAO1 TAB3_TAO2 TAB3_TAO3
three concurrent
streams will use the TAB4_TAO TAB4_TAO1 TAB4_TAO2 TAB4_TAO3
instance counts 1,2,
and 3. When the user tries to run the 4 th,5th, and 6th streams, the program will not find an available temp table
instance and will use the base temp table.
Number of concurrent executions
The number of concurrent executions in this example is 6, where as the number of available temp table instances
are just 3. So, the first three processes are using the temp table instance. The final three are using the base temp
tables.
Drawbacks
Use of base temp tables for any AE process is not recommended due to the following reasons.
1. AE Program issues a delete for the base temp tables while it truncates the temp table instances.
2. Frequent deletes and inserts could cause fragmentation for the base temp tables.
3. Runtime table statistics on the base temp tables are ignored.
4. As multiple streams use the same base temp table, there could be a possibility of contention.
Recommendations
1. Always setup an adequate number of temp table instances to achieve good performance.
2. To overcome the drawbacks described above, setup a temp table instance even if you are planning to run
only one process at a time.
3. Setup required value for the process scheduler server in the max concurrent field. Max API Aware value
should be larger than or equal to the total of Max Concurrent value set of all the process types.

4. Setup required number of PSAESERV processes on the process scheduler server.

[PSAESRV]
;=========================================================================
; Settings for Application Engine Tuxedo Server
;=========================================================================
;-------------------------------------------------------------------------
; The max instance should reflect the max concurrency set for process type
; defined with a generic process type of Application Engine as defined
; in the Server Definition page in Process Scheduler Manager
Max Instances =12
5. Use of DTTs is recommended even when the process is running in single stream.
CREATING PEOPLESOFT TEMPORARY TABLES AS ORACLE GLOBAL TEMP

TABLES (GTT)
What are Global Temporary Tables?
Oracle8i introduced Global Temporary Tables (GTT), which can be used as temporary processing tables for any
batch process. Instances of a global temporary table will be created at the runtime in the user's temporary
tablespace. These tables are session specific. Table data is deleted once the session is closed or the transaction
is committed. During the table creation time, it gives the option to preserve or delete the rows after the commit.
Can GTTs be used in place of Dedicated Temp Tables?
As of now PeopleSoft does not provide a script or utility to create the GTTs. Also, there is no direct method to
specify the dedicated temp tables as GTTs. Creating PeopleSoft temporary tables as GTTs is not recommended.
Important caution while using the GTTs is Application Engine's ability to restart: Since GTTs lose the data when
the session ends, there is no way to restart the program.
Chapter 4 - Tablespace Selection

PeopleSoft's supplied create scripts will create only Locally Managed tablespaces. The creation of dictionary
managed tablespaces is scheduled for de-support by Oracle.
LOCALLY MANAGED TABLESPACES

Locally Managed Tablespaces (LMT) are the default starting in Oracle 9i. Extent management is done within the
datafile/tempfile using the bitmaps. Object storage clause specification is not required (and is ignored) with these
tablespaces. You can use the BLOCKSIZE clause to specify a non-database default block size for the tablespace.
In order to use different block sizes in a database, you must have the DB_CACHE_SIZE and at least one
DB_nK_CACHE_SIZE parameter set, and the integer you specify in this clause must correspond with the setting of
one DB_nK_CACHE_SIZE parameter setting.
Advantages of Locally Managed

 Reduced recursive space management
 Reduced contention on data dictionary tables and space management latches
 No coalescing required
 No rollback generated for space allocation and de-allocation activities.
 Fragmentations is reduced but not completely eliminated.
Space Management
 Free extents recorded in bitmap (so some part of the tablespace is set aside for bitmap)
 Each bit corresponds to a block or group of blocks
 Bit value indicates free or unused
 Common views used are DBA_EXTENTS and DBA_FREE_SPACE
Locally Managed - AUTO ALLOCATE
With this option, the extent size is managed by Oracle depending on the object size. This is the preferable method
if the tablespace holds the objects with various sizes.
CREATE TABLESPACE TS_PERM_LOC_AUTO size 100M datafile '/perm/ora/ts_perm_loc_auto.dbf'
EXTENT MANAGEMENT LOCAL AUTO ALLOCATE;
With this option, extent size allocation is performed by Oracle.
Locally Managed - UNIFORM EXTENT
With this option, the size of each extent would be fixed to the specified size. Make sure to specify appropriate size
to avoid the table creation with more number of extents.
CREATE TABLESPACE TS_PERM_LOC_UNI size 100M datafile '/perm/ora/ts_perm_loc_uni.dbf'
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 128K;
Uniform extent gives best predictability and consistency. Having the consistent extent size eliminates wastage of
tablespace as "holes". It will be easier for the DBA to do capacity planning but proper planning should be done to
determine the optimum extent size. Planning to create different category tablespaces such as small, medium, and
large with different uniform extent sizes and placing the tables in an appropriate tablespace depending on its size
may give optimal performance.
TEMPORARY TABLESPACES
Every database user should be assigned a default temporary tablespace(s) to handle the data sorts. You cannot
specify nonstandard block sizes for a temporary tablespace. In Oracle 10g, a regular tablespace cannot be
assigned as the temporary tablespace. It flags as an error when the tablespace assigned is not a true Oracle
temporary tablespace.
Tempfile based
Oracle introduced this new type that uses tempfile instead of datafile. This should be a preferred method for any
Temporary Tablespace. This will give better extent management and space management than the datafile based
ones. In this type of tablespace, only the Locally Managed with UNIFORM EXTENT management is allowed.
CREATE TEMPORARY TABLESPACE TS_TEMP_LOC_UNI size 100M tempfile
'/temp/ora/ts_temp_loc_uni.dbf' EXTENT MANAGEMENT LOCAL UNIFORM SIZE 500K;
Advantages :
 Space management (extent allocation and de-allocation) is locally managed.
 The sort segment created for each instance is reused.
 All processes performing sorts reuse existing sort extents of the sort segment, rather than allocating a
segment (and potentially many extents) for each sort.
UNDO MANAGEMENT
Automatic Undo Management
This is the preferred method of undo management and is the default when creating a new 10g database. If a
database is up-graded from 9i, convert the database to use automatic UNDO management instead of rollback
segments.
Automatic undo management lets you allocate undo space in a single undo tablespace, instead of distributing undo
space in a set of statically allocated rollback segments. Oracle server handles the creation and allocation of space
among the undo segments automatically.
You need to specify the UNDO_TABLESPACE initialization parameter to tell oracle which tablespace to use for
undo and then create that tablespace while creating the database. The ONLY way to have automatic undo
management requires you specify an undo tablespace.
Example :
CREATE DATABASE INVDB
…
DATAFILE '/data3/oradata/INVDB/system/system01.dbf' SIZE 1024M
EXTENT MANAGEMENT LOCAL
LOGFILE
….
DEFAULT TEMPORARY TABLESPACE TEMPTS1
………
UNDO TABLESPACE UNDOTS
DATAFILE '/data4/oradata/INVDB/undo/undots01.dbf' SIZE 5048M;

Chapter 5 - Maintaining Indexes
PeopleSoft supplied indexes are generic in nature. Depending on the customer's business needs and data
composition, index requirements may vary. The following few tips will assist the DBA to manage indexes
efficiently.
INDEX TIPS
1. Review the index recommendation document supplied by the product to see if any of the suggestions apply
to your installation.
2. Run the Oracle trace/TKPROF report for a process and check the access paths to determine the usage of
indexes.
Note about use of “Index Skip Scan” access method: “Index Skip Scan” is not a recommended access
method as it can be very slow when accessing a large index.
3. Consider adding additional indexes depending on your processing/performance needs.

4. Examine the available indexes and remove any of the unused indexes to boost the performance of
Insert/Update/Delete DML. Sometimes, an index not used within a batch process may be useful with an
online page. The reverse may also be true. Perform thorough system analysis prior to deleting any index.
Index deletion could severely impact other program’s performance.
REBUILDING OF INDEXES
It is recommended that an index should be rebuilt when a performance issue is found where a SQL execution plan
is accessing an index either by a “range scan” or “full index scan” and a significant number of logical IOs (and may
be physical IOs) are witnessed for a relatively small number of rows returned by the scan.
Typically this can happen when a large number of rows have been deleted from the table. Within the index, all the
rows are logically deleted, but physically they still linger within until the index is rebuilt. For runtime performance
reasons, Oracle has consciously decided to not coalesce near-empty blocks or re-balance physical index blocks.
This decision causes the deleted blocks to linger within the index until it is rebuilt. During “Range Scan” and “Full
Index Scan”, these deleted/empty blocks must still be read, causing the performance degradation.
As of this writing, little information about index rebuilding criteria seems to be available pertaining specifically to
10g. Three metalink notes were found that might provide a little insight as to when to rebuild or coalesce an index.
 Note 77574.1 “Guidelines on When to Rebuild a B-Tree Index”, Dated 20-OCT-2005: This note is labeled
for versions 7.0 to 9i inclusive. May indirectly be usable for version 10.x. This note is referenced by note
122008.1.
 Note 99618.1 “ORACLE8i - Coalescing Indexes”, Dated 20-OCT-2005: This note is labeled for version 8i
only, but does provide the describing what “index coalescing” is, pros and cons for selecting it and index
rebuilding.
 Note 122008.1 “Script: Lists All Indexes that Benefit from a Rebuild”, Dated 06-MAY-2005: This note is
labeled for versions 7.3 to 10.2 inclusive. This note provides a script that may be used to determine
whether an index may be a candidate for rebuilding. It uses the suggested values from note 77574.1 and
provides a good basis for determining whether an index should be rebuilt. Please read note 77574.1
before using this script.

Note: If a very very large index is evaluated, a threshold of “5 or more” levels may be too shallow.
FUNCTION BASED INDEXES

A function-based index is an index on an expression, such as an arithmetic expression or an expression containing
a package function. It is recommended that customer support be contacted prior to a functional index creation.
Test case:
Table PS_CUSTOMER has an index PS0CUSTOMER with NAME1 as leading column:
SELECT SETID,CUST_ID,NAME1 FROM PS_CUSTOMER WHERE NAME1 LIKE 'Adventure%';

SQL>
SETID CUST_ID NAME1
----- --------------- -----------------
SHARE 1008 Adventure 54
Query uses index PS0CUSTOMER and returns the result faster.
SELECT SETID,CUST_ID,NAME1 FROM PS_CUSTOMER WHERE NAME1 LIKE 'ADVENTURE%';

SQL>
No rows selected
Query uses index PS0CUSTOMER and returns the result faster. But, gives no rows.
If data is stored in mixed case such as the above example, the only way to get the result using a consistent
case filter is by using the function “UPPER.”
SELECT SETID,CUST_ID,NAME1 FROM PS_CUSTOMER WHERE UPPER(NAME1) LIKE 'ADVENTURE%';

SQL>
SETID CUST_ID NAME1
----- --------------- -----------------
Query does not use the PS0CUSTOMER index so it takes a long time to return. But, the data returned is
correct.
In such cases, the use of function-based indexes is helpful.
CREATE INDEX ON PSFCUSTOMER ON PS_CUSTOMER (UPPER(NAME1));
SELECT SETID,CUST_ID,NAME1 FROM PS_CUSTOMER WHERE UPPER(NAME1) LIKE 'ADVENTURE%';

SQL>
SETID CUST_ID NAME1
----- --------------- -----------------
Query uses the PSFCUSTOMER index, returns the query faster, and provides the correct output.
Note: Please review the documentation pertaining to function based indexes prior to their creation.
Starting with PeopleTools 8.48, PeopleSoft generates indexes with DESCENDING column. These indexes are
considered as Function-based indexes in Oracle. Here is an example:
CREATE UNIQUE INDEX PS_GL_ACCOUNT_TBL ON PS_GL_ACCOUNT_TBL (SETID,
ACCOUNT, EFFDT DESC) TABLESPACE PSINDEX STORAGE (INITIAL 45056 NEXT 100000
MAXEXTENTS UNLIMITED PCTINCREASE 0) PCTFREE 10 PARALLEL NOLOGGING

When you select the descending column name from DBA_IND_COLUMNS, it will show something like
SYS_NC00033$ which is a system-generated column name. To find the real column name, you have to go look in
COLUMN_EXPRESSION of DBA_IND_EXPRESSIONS.
select a.index_name,a.index_type,b.column_name from dba_indexes a,dba_ind_columns b where

b.index_name='PS_GL_ACCOUNT_TBL' and a.index_name=b.index_name order by column_position;
select index_name,column_expression,column_position from dba_ind_expressions where

index_name='PS_GL_ACCOUNT_TBL';
Because of multiple Bugs (# 4939157 and 5092688) which cause wrong results or core dump from queries using
functional indexes, PeopleSoft had recommended to disable the functional indexes causing sql(s) that were relying
on these indexes to perform in an inefficient manner. We suggested that you go to the following link
http://www4.peoplesoft.com/psdb.nsf/0/33440EC2DE7C886788257051005AEB72?OpenDocument
to check the availability of patches and apply them accordingly to fix the problem and remove the following
initialization parameter:
_disable_function_based_index=TRUE

Chapter 6 - Cursor Sharing
When a SQL statement that does not exist in the shared pool is executed, it has to be parsed fully. Oracle has to
allocate memory for the statement from the shared pool, check the statement syntactically and semantically, etc.
This is referred to as a hard parse and is very expensive in both in terms of CPU used and in the number of latch
gets performed.
Hard parsing happens when the Oracle server parses a query and cannot find an exact match for the query in the
library cache. This occurs due to inefficient sharing of SQL statements and can be improved by using bind
variables instead of literal in queries. Some times hard parsing causes excessive CPU usage.
The number of hard parses can be identified in a PeopleSoft Application Engine trace (128). The following is an
example of of the AE trace(128):
C o m p i l e E x e c u t e F e t c h Total
BL6100.10000001.S 252 0.6 252 1.5 0 0.0 2.1
In Oracle Trace output such statements are shown as individual statements and each statement parses once.
Relying on Oracle trace output to identify the SQL that are hard parsed due to literal instead of bind variables is
somewhat difficult.
Oracle introduced this new parameter CURSOR_SHARING as of Oracle8i. By default its values is set to EXACT.
That means, the database looks for an exact match of the SQL statement while parsing.
Setting the CURSOR_SHARING value at the instance level is not recommended in a PeopleSoft environment.
USE OF BIND VARIABLES

The number of hard parses can be reduced to ‘one,’ per multiple executes of the same SQL statement by coding
the statement with bind variables instead of literals.
Most of the PeopleSoft programs written in Application Engine, SQR, and COBOL have been rewritten to address
this issue. In some situations, there are some steps in AE processes that are not using bind variables. This
happens when certain kinds of statements cannot handle bind variables in some platforms. As Oracle deals with
bind variables efficiently, such statements can typically be made to use bind variables.
The following section gives some guidelines to follow to use the bind variables.
Application Engine - Reuse Flag
PeopleSoft Application Engine programs use bind variables in the SQL statements, but these variables are just
PeopleSoft specific. When the statement is passed to the database it sends the statement with literal values. The
only way to tell the application engine program to send the bind variables is by specifying the Re-Used flag for that
statement that needs to use the bind variable.
If any customizations are performed, it is recommended that the Reuse Flag be set to “Yes” for all program steps.
Example: Statement in PC_PRICING.BL6100.10000001

UPDATE PS_PC_RATE_RUN_TAO
SET RESOURCE_ID = %Sql(PC_COM_LIT_CHAR,%NEXT(LAST_RESOURCE_ID),1,20,20)

WHERE PROCESS_INSTANCE = %ProcessInstance

AND BUSINESS_UNIT = %Bind(BUSINESS_UNIT)
AND PROJECT_ID = %Bind(PROJECT_ID)
AND ACTIVITY_ID = %Bind(ACTIVITY_ID)
AND RESOURCE_ID = %Bind(RESOURCE_ID)
AND LINE_NO = %Bind(LINE_NO)
Statement without Re-Use flag:
AE Trace
-- 16.46.00 ......(PC_PRICING.BL6100.10000001) (SQL)
UPDATE PS_PC_RATE_RUN_TAO SET RESOURCE_ID = 10000498 WHERE PROCESS_INSTANCE =
419 AND BUSINESS_UNIT = 'US004' AND PROJECT_ID = 'PRICINGA1' AND ACTIVITY_ID
= 'ACTIVITYA1' AND RESOURCE_ID = 'VUS004VA10114050' AND LINE_NO = 1
/
-- Row(s) affected: 1
Total
BL6100.10000001.S 252 0.6 252 1.5 0 0.0 2.1
Oracle Trace Output
********************************************************************************
UPDATE PS_PC_RATE_RUN_TAO SET RESOURCE_ID = 10000561

WHERE
PROCESS_INSTANCE = 419 AND BUSINESS_UNIT = 'US004' AND PROJECT_ID =
'PRICINGA1021' AND ACTIVITY_ID = 'ACTIVITYA2042' AND RESOURCE_ID =
'VUS004VA10210124050' AND LINE_NO = 1
call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.01 0.01 0 2 5 1
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 0.01 0.01 0 2 5 1
Misses in library cache during parse: 1

Optimizer goal: CHOOSE
Parsing user id: 21 (PROJ84)
Rows Row Source Operation

------- ---------------------------------------------------
1 UPDATE PS_PC_RATE_RUN_TAO
2 INDEX RANGE SCAN (object id 16735)
Rows Execution Plan

------- ---------------------------------------------------
0 UPDATE STATEMENT GOAL: CHOOSE
1UPDATE OF 'PS_PC_RATE_RUN_TAO'
2 INDEX GOAL: ANALYZED (RANGE SCAN) OF 'PS_PC_RATE_RUN_TAO'
(UNIQUE)
********************************************************************************
You will see 252 different sqls in the tkprof similar to the one above.
Statement with Re-Use flag:
AE Trace
-- 16.57.57 ......(PC_PRICING.BL6100.10000001) (SQL)
UPDATE PS_PC_RATE_RUN_TAO SET RESOURCE_ID = :1 WHERE PROCESS_INSTANCE = 420
AND BUSINESS_UNIT = :2 AND PROJECT_ID = :3 AND ACTIVITY_ID = :4 AND
RESOURCE_ID = :5 AND LINE_NO = :6
/
-- Bind variables:
-- 1) 10000751
-- 2) US004
-- 3) PRICINGA1
-- 4) ACTIVITYA1
-- 5) VUS004VA10114050
-- 6) 1
-- Row(s) affected: 1
Total
BL6100.10000001.S 1 0.0 252 0.4 0 0.0 0.4
Oracle Trace Output
********************************************************************************
UPDATE PS_PC_RATE_RUN_TAO SET RESOURCE_ID = :1

WHERE
PROCESS_INSTANCE = 420 AND BUSINESS_UNIT = :2 AND PROJECT_ID = :3 AND
ACTIVITY_ID = :4 AND RESOURCE_ID = :5 AND LINE_NO = :6

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 252 0.22 0.22 0 509 1284 252
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 253 0.22 0.22 0 509 1284 252

Optimizer goal: CHOOSE
Parsing user id: 21 (PROJ84)

Rows Row Source Operation

------- ---------------------------------------------------
252 UPDATE PS_PC_RATE_RUN_TAO
504 INDEX RANGE SCAN (object id 16735)
Rows Execution Plan

------- ---------------------------------------------------
0 UPDATE STATEMENT GOAL: CHOOSE
252 UPDATE OF 'PS_PC_RATE_RUN_TAO'
504 INDEX GOAL: ANALYZED (RANGE SCAN) OF 'PS_PC_RATE_RUN_TAO'
(UNIQUE)
********************************************************************************
SQR/COBOL - CURSOR_SHARING
Most of the SQR and COBOL programs are written to use bind variables. If you find any programs that are not
using bind variables and are not able to modify the code, then the CURSOR_SHARING option FORCE is useful.
With this setting, the database looks for a similar statement excluding the literal values that are passed to the SQL
statement. Oracle replaces the literal values with the system bind variables and treats them as single statement
and parses once.
Setting the value at the session level is more appropriate. If you identify the program (SQR/COBOL) that is not
using the bind variables and need to force them to use the binds at the database level, then adding the ALTER
SESSION command at the beginning of the program should be a better option.
If you are not willing to change the application program then implementing the session level command though a
trigger to give you more flexibility.
Session Level (using trigger): Following sample trigger code can be used to implement the session level option.
CREATE OR REPLACE TRIGGER MYDB.SET_TRACE_INS6000
BEFORE UPDATE OF RUNSTATUS ON MYDB.PSPRCSRQST
FOR EACH ROW
WHEN ( NEW.RUNSTATUS = 7
AND OLD.RUNSTATUS != 7
AND NEW.PRCSTYPE = 'SQR REPORT'
AND NEW.PRCSNAME = 'INS6000'
)
BEGIN
EXECUTE IMMEDIATE 'ALTER SESSION SET CURSOR_SHARING=FORCE';
END;
/
Note: Make sure to give ALTER SESSION privilege to MYDB to make this trigger work.
Example:
Sql Statement issued from SQR/COBOL program:

SELECT ……….
FROM
PS_PHYSICAL_INV PI, PS_STOR_LOC_INV SLI WHERE………….
NOT EXISTS (SELECT 'X' FROM
PS_PICKZON_INV_VW PZI WHERE PZI.BUSINESS_UNIT = 'US008' AND PZI.INV_ITEM_ID
= 'PI000021' AND ………..) ORDER BY …..
Above statement uses a literal values in the where clause there by causing a hard parse for each execute.
Every hard parse has some amount of performance overhead. Minimizing them will boost the performance.
This statement gets executed for every combination of BUSINESS_UNIT and INV_ITEM_ID. As per the data
composition used in this benchmark there were about 13,035 unique combinations of BUSINESS_UNIT and
INV_ITEM_ID and about 19,580 total executes.
Oracle TKPROF Output with CURSOR_SHARING=FORCE

SELECT ………
FROM
PS_PHYSICAL_INV PI, PS_STOR_LOC_INV SLI WHERE …………..
NOT EXISTS (SELECT :SYS_B_09 FROM PS_PICKZON_INV_VW PZI
WHERE PZI.BUSINESS_UNIT = :SYS_B_10 AND PZI.INV_ITEM_ID = :SYS_B_11 AND
……..) ORDER BY …..
Pros and Cons of CURSOR_SHARING
By setting the above parameter at the session level the over all processing time reduced significantly.
Over all statistics with no bind variables:
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 26389 98.27 99.54 0 1074 0 0
Execute 404647 51.09 50.11 1757 242929 371000 78376
Fetch 517618 47.85 47.43 3027 1455101 235446 189454
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 948654 197.21 197.08 4784 1699104 606446 267830

Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 27118 5.35 5.06 0 49 1 0
Execute 33788 2.42 2.22 0 5577 235 229
Fetch 54988 2.44 2.57 1 97241 0 47621
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 115894 10.21 9.85 1 102867 236 47850
Over all statistics with bind variables:

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 26389 15.44 15.69 0 0 0 0
Execute 404647 44.02 43.51 173 231362 333538 78376
Fetch 517618 45.47 43.02 2784 1439571 235104 189454
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 948654 104.93 102.22 2957 1670933 568642 267830

Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse 356 0.08 0.10 0 0 0 0

Execute 357 0.47 0.48 0 5568 228 228
Fetch 667 0.00 0.01 0 1333 0 552
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 1380 0.55 0.59 0 6901 228 780
From the above trace statistics, it can be seen that the number of library cache misses decreased with the use of
bind variables.
Original Timing Time with CURSOR_SHARING option %Gain
197 Sec 102 Sec 48%

Chapter 7 - Batch Server Selection
Process Scheduler executes PeopleSoft batch processes. As per the PeopleSoft architecture, process scheduler
(Batch Server) can be setup to run from database server or any other server.
SCENARIO 1: PROCESS SCHEDULER AND DATABASE SERVER ON DIFFERENT

BOXES
Scenario 1
SERVER1 SERVER2
Batch Server Database Server
TCP/IP
Process Scheduler Oracle
DB
Running the Process Scheduler on a box other than the database server will use a TCP/IP connection to connect
to the database. As the batch process may involve extensive SQL processing, this TCP/IP can be a big overhead
and may impact processing times. The impact is more evident in a process where excessive row-by-row
processing is done. For the processes where majority of SQL statements are of set based, the impact due to
TCP/IP overhead may not be that big.
Have a dedicated network connection between the batch server and the database to minimize the overhead.
SCENARIO 2: PROCESS SCHEDULER AND DATABASE SERVER ON ONE BOX

Scenario 2
SERVER2
Database Server / BatchServer
Oracle
DB
Use Local
Connection
Process Scheduler

Running the Process Scheduler on the database server will eliminate the TCP/IP overhead and improve the
processing time. At the same time it does use the additional server memory.
Set the following value in the process scheduler configuration file "psprcs.cfg" to use the direct connection instead
of TCP/IP
UseLocalOracleDB=1
This kind of setup is useful for the programs that do excessive row-by-row processing.
WHAT IS THE RECOMMENDED SCENARIO?

Considering the performance impact due to TCP/IP for the row-by-row processing, the scenario 2 is recommended
where the connection overhead is eliminated. At the same time, it may not be possible to run the extensive batch
processes on the database server due to the limited availability of server resources.
Make fair judgment depending on your environment and usage. You could setup both scenarios in your
environment and use a specific scenario depending on the time of the run and the complexity of the process. All
the CRITICAL jobs can be run using scenario 2. All the Report jobs can be run using scenario 1.

Chapter 8 - Capturing Traces
People Tools provides tracing facilities to capture online as wells as batch program flows. Oracle DBMS also
provides utilities to capture traces for details on SQL execution during a database session. The following is basic
recommendations that can assist in capturing various traces in order to identify performance issues. Make sure to
reset the values back to “zero” (a.k.a. stop tracing) after capturing the needed trace files. These recommends are
typical but specific scenarios may require additional settings to capture needed details. Please refer to
documentation for complete discussion.
Note: Running a production environment with any of theses settings may cause significant performance
degradation due to the overhead introduced by tracing.
ONLINE PERFORMANCE ISSUES

To debug performance issues within online pages, it is important to capture trace files for SQL and PeopleCode
events. The following minimum settings are recommended within application server’s configuration file. The trace
file will be written in the corresponding application server log directory on the machine where this application server
is running. An example name for the file might be:
VP1_dhcp-psft-F-2nd-west-10-138-222-59.us.oracle.com.tracesql
within the directory:
/data2/ora/pt84803b/appserv/ORAVOL/LOGS
Configuration Settings for Tracing an Online Process
When setting the values for “TraceSQL” and “TracePC” within the application server’s configuration file, the sum of
the options requested become the values in which “TraceSQL” and “TracePC” is set.
Example for tracing SQL (TraceSQL):
The following options are requested to be traced:
1 - SQL statements
2 - SQL statement variables
4 - SQL connect, disconnect, commit and rollback
8 - Row Fetch (indicates that it occurred, not data)
+ 16 - All other API calls except ssb
====
31 - The value “TraceSQL” is to be set.
“31” is the recommended value when tracing with “TraceSQL”.
“1984” is teh recommended value when tracing with “TracePC”.
Sample snippet from psappsrv.cfg
;-------------------------------------------------------------------------
; SQL Tracing Bitfield
;
; Bit Type of tracing
; --- ---------------
; 1 - SQL statements
; 2 - SQL statement variables

; 4 - SQL connect, disconnect, commit and rollback

; 8 - Row Fetch (indicates that it occurred, not data)
; 16 - All other API calls except ssb
; 32 - Set Select Buffers (identifies the attributes of columns
; to be selected).
; 64 - Database API specific calls
; 128 - COBOL statement timings
; 256 - Sybase Bind information
; 512 - Sybase Fetch information
; 4096 - Manager information
; 8192 - Mapcore information
; Dynamic change allowed for TraceSql and TraceSqlMask
TraceSql=31
TraceSqlMask=12319
;-------------------------------------------------------------------------
; PeopleCode Tracing Bitfield
;
; --- ---------------
; 1 - Trace entire program
; 2 - List the program
; 4 - Show assignments to variables
; 8 - Show fetched values
; 16 - Show stack
; 64 - Trace start of programs
; 128 - Trace external function calls
; 256 - Trace internal function calls
; 512 - Show parameter values
; 1024 - Show function return value
; 2048 - Trace each statement in program
; Dynamic change allowed for TracePC and TracePCMask
TracePC=1984
TracePCMask=4095
Note: It is extremely difficult to perform on-line tracing at the database level (especially on a production
environment). This is mainly due to on-line sessions sharing of the database connections; and as database
connections are used, a single web server session could use many different database connections. If tracing at the
application server level is not adequate, contact customer support for more assistance.
You can also turn on the tracing for a user session by doing the followings:
Login using your PIA URL appended with “&trace=y”:
For example:
PIA URL: http://pbnt0020:4090/psp/ps/?cmd=login
Log on using the following: http://pbnt0020:4090/psp/ps/?cmd=login&trace=y
You can set your trace settings from the page below before log in:

APPLICATION ENGINE PERFORMANCE ISSUES
Configuration Settings for Tracing an AE Process on the Application Engine
When tracing is enabled for AE programs, the process scheduler will create a subdirectory under “process
scheduler/log/output” directory for each AE process. As an example, the trace directory created for “FS_BP”
process might be “AE_FS_BP_7233” containing file named “AE_FS_BP_7233.AET
The calculation for the “TraceAE” value is the same as for “TraceSQL” explained above.
“135” is the recommended value when tracing with “TraceAE”.
Sample snippet from psprcs.cfg

;-------------------------------------------------------------------------
; AE Tracing Bitfield
;
; --- ---------------
; 1 - Trace STEP execution sequence to AET file
; 2 - Trace Application SQL statements to AET file
; 4 - Trace Dedicated Temp Table Allocation to AET file
; 8 - not yet allocated

; 128 - Timings Report to AET file

; 256 - Method/BuiltIn detail instead of summary in AET Timings Report
; 1024 - Timings Report to tables
; 2048 - DB optimizer trace to file
; 4096 - DB optimizer trace to tables
TraceAE= 135
If tracing PeopleCode steps with an AE program is necessary, the following settings are needed within the process
scheduler configuration file to capture both SQL and PeopleCode events during an execution
PeopleCode tracing is not generally necessary, but is helpful when trying to debug procedural issues. Please
remember to restore original configuration values after completing the trace.
“31” is the recommended value when tracing with “TraceSQL”.
“1984” is the recommended value when tracing with “TracePC”.
; --- ---------------
; to be selected).
; 1024 - SQL Informational Trace
TraceSQL=31
;-------------------------------------------------------------------------
; PeopleCode Tracing Bitfield
;
; --- ---------------
; 1 - Trace Evaluator instructions (not recommended)
; 2 - List Evaluator program (not recommended)
; 4 - Show assignments to variables
; 8 - Show fetched values
; 16 - Show stack
; 64 - Trace start of programs
; 128 - Trace external function calls
; 256 - Trace internal function calls
; 512 - Show parameter values
; 1024 - Show function return value
; 2048 - Trace each statement in program (recommended)
; Dynamic change allowed for TracePC
TracePC=1984
Configuration Settings for Tracing an AE Process on the Database
There are two ways to generate a database trace file for AE process:
1. Setting value in AE trace section of process scheduler configuration file. A raw SQL trace file generated by
this setting will be created within the “UDUMP” directory on the database server.

The raw trace file will contain details of each SQL statement that was executed on the database including
its runtime execution plan. The raw trace will be used as input to the “tkprof” database utility to generate a
formatted trace report.
The calculation for the “TraceAE” value is the same as for “TraceSQL” explained above.
“2183” is the recommended value when using this method.
;-------------------------------------------------------------------------
; AE Tracing Bitfield
;
; --- ---------------
; 1 - Trace STEP execution sequence to AET file
; 2 - Trace Application SQL statements to AET file
; 4 - Trace Dedicated Temp Table Allocation to AET file
; 128 - Timings Report to AET file
; 256 - Method/BuiltIn detail instead of summary in AET Timings Report
; 1024 - Timings Report to tables
; 2048 - DB optimizer trace to file
; 4096 - DB optimizer trace to tables
TraceAE=2183
Note: This setting does not provide wait events and bind variable information. If this information is needed,
use the second method.
2. A trigger is created to start SQL tracing on the database side for an AE process with customized trace
settings. Generally Level 12 trace is useful to identify SQL performance problems and this captures wait
and bind information for all SQL. For example, to generate trace for an AE process PO_PO_CALC the
following trigger needs to be created. MYDB is the database name and SET_TRACE_POCALC is the
trigger name.
CREATE OR REPLACE TRIGGER MYDB.SET_TRACE_POCALC
FOR EACH ROW
WHEN ( NEW.runstatus = 7
AND OLD.runstatus != 7
AND NEW.prcstype = 'Application Engine'
AND NEW.prcsname = 'PO_PO_CALC'
)
BEGIN
EXECUTE IMMEDIATE
'ALTER SESSION SET TIMED_STATISTICS = TRUE';
EXECUTE IMMEDIATE
'ALTER SESSION SET MAX_DUMP_FILE_SIZE = UNLIMITED';
EXECUTE IMMEDIATE
'ALTER SESSION SET TRACEFILE_IDENTIFIER = ''POCALC''';
EXECUTE IMMEDIATE
'ALTER SESSION SET EVENTS = ''10046 TRACE NAME CONTEXT FOREVER, LEVEL
12''';
END;
/
Modify the trigger creation command with the proper values for database name, process name, and
tracefile identifier.

Note: Drop or disable the trigger once the trace is captured.
Once the raw database trace is captured, execute the program “tkprof” with following sort options:
tkprof <trace_input_file> <rpt_output_file> sys=no explain=<user_id>/<password>

sort=exeela,fchela,prscpu,execpu,fchcpu
Note: Enabling tracing at the database instance level is never recommended.
COBOL PERFORMANCE ISSUES

The following settings are needed within the process scheduler’s configuration file to capture summary report
information for a COBOL process. This report, along with database SQL trace, will help to debug performance
issues.
; --- ---------------
; to be selected).
; 1024 - SQL Informational Trace
TraceSQL=128
SQR REPORTS PERFORMANCE ISSUES

Creating a trigger is the only way to generate SQL trace file for SQR reports. The following is an example trigger
creation command for one a SQR report.
CREATE OR REPLACE TRIGGER MYDB.SET_TRACE_INS6000

FOR EACH ROW
WHEN ( NEW.runstatus = 7
AND OLD.runstatus != 7
AND NEW.prcstype = 'SQR REPORT'
AND NEW.prcsname = 'INS6000'
)
BEGIN
EXECUTE IMMEDIATE
'ALTER SESSION SET TIMED_STATISTICS = TRUE';
EXECUTE IMMEDIATE
'ALTER SESSION SET MAX_DUMP_FILE_SIZE = UNLIMITED';
EXECUTE IMMEDIATE
'ALTER SESSION SET TRACEFILE_IDENTIFIER = ''INS6000''';
EXECUTE IMMEDIATE
'ALTER SESSION SET EVENTS = ''10046 TRACE NAME CONTEXT FOREVER, LEVEL 12''';
END;
/

ORACLE PERFORMANCE ISSUES

The followings are needed when reporting Performance issues in Oracle database to PeopleSoft Global Support
Center:
1. Confirm that our required minimum patches are installed:

 Generate a Patch Inventory list:
a. Log on to DB server
b. Change directory to :
cd $ORACLE_HOME/Opatch
c. Issue the following command:
opatch lsinventory
 Logon to Customer Connection to make sure that all required minimum Patches are being applied. Use
this link to do so:
http://www4.peoplesoft.com/psdb.nsf/0/33440EC2DE7C886788257051005AEB72?OpenDocument
Search for “Required Operating System, RDBMS & Third Party Product Patches Required for Installation”
Select the Tools Release that you are on.
Note: We also document initialization paramaters that could impact performance in here.
2. Send us a copy of your init.ora or spfile.ora.
Note: You can use RDA (Remote Diagnostic Agent) to collect the above informations. For instructions how to run
RDA, please refer to Note:414970.1 in Oracle Metalink
GENERATING EXPLAIN PLAN FOR SQL USING “SQLTEXPLAIN.SQL”

For enhanced Explain Plan and diagnostic info for one SQL statement, sqltexplain utility is very useful and
recommended. The details of this utility are provided in Oracle Meta Link Note 215187.1.
AUTOMATIC WORKLOAD REPOSITORY (AWR)

Oracle 10g provides an automatic database performance monitoring tool called AWR, replacing the manual
“STATSPACK” method in earlier versions. AWR automatically generates snapshots of the performance data once
every hour (by default) and collects the statistics in the workload repository. The various metrics collected by AWR
include:
1. Wait events such as Disk I/O wait, Network wait, lock wait, commit wait etc.
2. Session history details showing top SQL taking time and resource.
3. Operating system metrics of CPU , Disk, Network and Memory.
This information is very useful for solving performance issues and finding the database load at any point in time in
the past. It is highly recommended to keep this AWR running with default frequency. History of the snapshots is
retained for 7 days (by default) and usually does not occupy more than 300 MB within the SYSAUX tablespace. If
the system has an average of more than 10 active concurrent sessions, more room may be needed.

Database initialization parameter “STATISTICS_LEVEL” must be set to “TYPICAL” or “ALL” (“TYPICAL” is the
default) and the parameter “TIMED_STATISTICS” must be set to “TRUE” to allow the database to populate the
workload repository properly.
Generating a HTML or Text AWR Report:
To generate an HTML or text AWR report:
1. Run the awrrpt.sql script from within SQL*Plus and logged in with a user having the DBA role:
@$ORACLE_HOME/rdbms/admin/awrrpt.sql
2. First, specify whether a HTML or a text report is wanted.
Enter value for report_type: html
3. Specify the number of previous day’s snapshots are to be listed.
Enter value for num_days: 2
4. A list displaying the snapshot id and time the snapshot was generated will display. Enter the beginning and
ending snapshot ID for the AWR report.
Enter value for begin_snap :
Enter value for end_snap:
5. Enter a output report name or accept the default name:

Enter value for report_name:
Using the report name awrrpt_1_150_160
6. The AWR report will be generated.
If there is need to diagnose a particularly specific issue, a snapshot can be manually created just prior and then
again just after executing a questionable program. Typically, this is not necessary.
Example of manually creating a snapshot via SQL*Plus:

BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
END;
/
AWR report analysis:
Most of the time, the database tuning activity is triggered by users complaining about response time of a
transaction or a Batch job. The response time analysis consists of finding out where time is being spent in a
database. The response time of a given transaction in the database always consists of the following two parts:
Response Time = Service Time + Wait Time
Where “Service Time” is CPU consumption by the database, and “Wait time” is the sum of all the Wait events in the
database.

The most important part of the AWR report is the Top 5 Timed Events section. With such a list one can quickly
identify the main areas to focus on. In situations where CPU usage is much more significant than Wait Time, it is
less likely that investigating Wait Events will produce significant savings in response time.Therefore, it is
recommended to compare the time taken by the top 5 timed events and direct the tuning effort to the biggest
consumers.
For example:
Top 5 Timed Events
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
CPU time 114 75.2
db file sequential read 4,658 26 12 13.4 User I/O
db file scattered read 8,883 12 5 8.5 User I/O
log file parallel write 10,336 9 1 1.4 System I/O
control file sequential read 28,284 9 0 1.3 System I/O
After a glance at the above, the system is CPU bound with 75.2% of the processing time being spent in CPU. To
drill further into the details of the CPU consumption, one needs to look at the Time Model Statistics section.
Time Model Statistics
Statistic Name Time (s) % of DB Time
DB CPU 114.19 75.20
sql execute elapsed time 92.92 59.33
parse time elapsed 11.67 8.71
hard parse elapsed time 3.40 2.54
failed parse elapsed time 1.37 1.02
connection management call elapsed time 0.79 0.59
hard parse (sharing criteria) elapsed time 0.16 0.12
PL/SQL execution elapsed time 0.07 0.05
sequence load elapsed time 0.01 0.01
repeated bind elapsed time 0.00 0.00
DB time 134.02
background elapsed time 66.65
background cpu time 31.67

From the above, 59% of the total DB CPU is spent in sql execute elapsed time, one will need to look at the Sql
Statistics section to look for problem sql’s (such as sql that have high Gets, high physical Reads, High Parse,..)
SQL STATISTICS:
 SQL Ordered by Elapsed Time: Includes SQL statements that took significant execution time during
processing.
 SQL Ordered by CPU Time: Includes SQL statements that consumed significant CPU time during its
processing.
 SQL Ordered by Gets: These SQLs performed a high number of logical reads while retrieving data.
 SQL Ordered by Reads: These SQLs performed a high number of physical disk reads while retrieving data.
 SQL Ordered by Parse Calls: These SQLs experienced a high number of reparsing operations.
 SQL Ordered by Sharable Memory: Includes SQL statements cursors which consumed a large amount of
SGA shared pool memory.
 SQL Ordered by Version Count: These SQLs have a large number of versions in shared pool for some
reason.
To get the details of wait events, one should go to Wait Events Statistics section.
Wait Events
Event Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn
db file sequential read 4,658 0.00 26 12 1.02
db file scattered read 8,883 0.00 12 5 1.00
log file parallel write 10,336 0.00 9 1 1.16
control file sequential read 28,284 0.00 9 0 3.18
db file parallel write 6,547 0.00 8 1 0.74
control file parallel write 10,839 0.00 6 1 1.22
The followings are the most common wait events found in Oracle database:
The most common I/O related wait events is “db file sequential read”. It occurred on single block read for index
data or table data accessed through an index. If this wait event is high then tune it as followed:
1. Find the Top SQL statements with Physical Reads in SQL ordered by Reads section. Generate the explain
plan of the sql statements.

a. If Index Range scans are involved, more blocks than necessary could be being visited if the index
is unselective. By creating a more selective index, we can access the same table data by visiting
fewer index blocks (and doing fewer physical I/Os).
b. If indexes are fragmented, again we have to visit more blocks because there is less index data per
block. In this case, rebuilding the index will compact its contents into fewer blocks.
c. If the index being used has a large Clustering Factor, then more table data blocks have to be
visited in order to get the rows in each Index block. By rebuilding the table with its rows sorted by
the particular index columns we can reduce the Clustering Factor and hence the number of table
data blocks that we have to visit for each index block. For example, if the table has columns A, B,
C & D and the index is on B, D then we can export the table data in order by B,D, and reload the
table.
2. If there is no particular SQL statement with bad execution plan, then one of the following may be
happening:
a. I/Os on particular datafiles may be being serviced slower due to excessive activity on their disks. In
this case, looking at the File I/O Statistics section of the AWR report will help us find such hot disks
and spread out the I/O by manually moving datafiles to other storage or by making use of Striping,
RAID and other technologies to automatically perform I/O load balancing for us.
3. If there is no SQL with suboptimal execution plans and I/O is evenly spread out with similar response times
from all disks then a larger Buffer Cache may help. In Oracle Database 10g, Automatic Shared Memory
Management (ASMM) feature is introduced to automatically determine the size of Database buffer cache
(default pool), Shared pool,Large pool and Java pool by setting the parameter SGA_TARGET. For more
details about ASMM, please refer to this metalink Note 257643.1.
Another common I/O related wait event is “db file scattered read”. It occurs when multiblock reads from disk are
performed into non-contiguous buffers in the Buffer Cache. Such reads are issued for up to the number of blocks
specified by this parameter DB_FILE_MULTIBLOCK_READ_COUNT at a time.These typically happen for Full
Table Scans and for Fast Full Index scans. If this wait event is high then the Top SQL statements with Physical
Reads in SQL ordered by Reads section can be investigated to see if their execution plans contain Full Table or
Fast Full Index scans. In cases where such multiblock scans are necessary, it is possible to tune the size of
multiblock I/Os issued by Oracle by setting the instance parameter DB_FILE_MULTIBLOCK_READ_COUNT to be
as below:
DB_BLOCK_SIZE x DB_FILE_MULTIBLOCK_READ_COUNT = max_io_size of system
Starting with Oracle10g Release 2, the initialization parameter DB_FILE_MULTIBLOCK_READ_COUNT is now

automatically tuned to use a default value when this parameter is not set explicitly. This default value corresponds
to the maximum I/O size that can be performed efficiently. This value is platform-dependent and is 1MB for most
platforms. Because the parameter is expressed in blocks, it will be set to a value that is equal to the maximum I/O
size that can be performed efficiently divided by the standard block size.
Another common I/O related wait event is “control file parallel write'” It occurs when Oracle is writing physical
blocks to all controlfiles and is waiting for the IO/s to complete. The details of this wait is reported in Background
Wait Events section. If systemwide waits for this wait event are significant then this either indicates numerous
writes to the controlfile (too many control files copies), or slow performance of writes to the controlfiles. Possible
solutions can be:
 Reduce the number of controlfile copies to the minimum that ensures that not all copies can be lost at the
same time.
 Enable asynchronous I/O or move the controlfiles to less I/O saturated disks.

Another popular wait event is “log file sync”. It occurs when a user session issues a COMMIT and is waiting for
LGWR to finish flushing all redo from the log buffer to disk.
To understand what is delaying the log file sync, there is a need to examine some other wait events such as
“LGWR wait for redo copy”, “log file parallel write”, “log file single write” and the redo statistics.
Some general tuning tips for this wait event are:
 Move all the log members to high speed disks
 Move log members to low I/O activities disk controllers
Starting with Oracle 10gR2, Oracle introduces an Asynchronous Commit. It is enabled with the initialization
parameter COMMIT_WRITE to change the commit behaviour on SYSTEM- as well as on SESSION-LEVEL.
To read more about this feature, please refer to Metalink Note 336119.1.
As a general rule, systems where CPU time is dominant usually need less tuning than the ones where wait time is
dominant. On the other hand, heavy CPU usage could be caused by poor Sql access paths or badly written SQL so
one should not neglect it.
In addition, the proportion of CPU time to WAIT time always tends to decrease as load on the system increases. A
steep increase in wait times is a sign of contention and need to be addressed for good scalability. A snapshot of the
database workload taken periodically throughout the day is necessary to detect such performance issues.
Below is a list of metalink reference notes that can useful for database tuning.
Note 190124.1 THE COE PERFORMANCE METHOD
Note 30286.1 I/O Tuning with Different RAID Configurations
Note 30712.1 Init.ora Parameter "DB_FILE_MULTIBLOCK_READ_COUNT" Reference Note
Note 1037322.6 WHAT IS THE DB_FILE_MULTIBLOCK_READ_COUNT PARAMETER?
Note 47324.1 Init.ora Parameter "DB_FILE_DIRECT_IO_COUNT" Reference Note
Note 45042.1 Archiver Best Practices
Note 62172.1 Understanding and Tuning Buffer Cache and DBWR
Note 147468.1 Checkpoint Tuning and Troubleshooting Guide
Note 76713.1 8i Parameters that Influence Checkpoints
Note 76374.1 Multiple Buffer Pools

Appendix A – Sample script to gather statistics on tables
The script is written based on the assumption that a PS temp table is defined in PSRECDEFN as having a
rectype=7 and PS regular table is defined as having a rectype =0. It then will generate the appropriate update
statistics command for regular table and indexes while skipping PS temp tables and indexes. It may require
changes and modifications to suit your need.
SET SERVEROUTPUT ON SIZE UNLIMITED

SET LINESIZE 1000
SET PAGESIZE 10000
/**
** Oracle USA, Inc.
** Date: 16-Jan-2007
**
** Format: SQL*Plus (10g) DBA script.
**
** Purpose:
** To generate statistics on all non-system schema table and index objects
** that are considered by the database to be stale and/or missing, while not
** generating statistics for PeopleSoft "temporary" tables and indexes.
**
** Please note:
** For this script to function properly, the executing user
** may need the DBA role. This script directly accesses:
** DBA_INDEXES
** DBMS_STATS
** All the table/index objects within all the schemas in the database.
**
** Other rights may also be needed.
**/
DECLARE
lot_ObjectsNeedingStats dbms_stats.objecttab;
lts_StartTime TIMESTAMP(2);
lts_FinishTime TIMESTAMP(2);
lvc_tableowner VARCHAR2(30);
lvc_tablename VARCHAR2(30);
lvc_PSRecordName VARCHAR2(30);
lint_tmp NUMBER(2,0);
lb_IsTempTable BOOLEAN;
sql_stmt VARCHAR2(2000);
BEGIN
/**
** Delete Old Status Info here
**
** If an external table is used to hold the log
** of the executions, truncate it here.
**/
/**
** Flush Monitoring info
**
** This forces the database to "flush" the modification data
** so that dbms_stats can tell whether the stats are stale.

** Documentation says this is not needed. Doing it just in case.

**/
DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO;
/**
** Find all tables and indexes that have stale stats
**/
DBMS_STATS.GATHER_DATABASE_STATS ( cascade => TRUE
,options => 'LIST AUTO'
,objlist => lot_ObjectsNeedingStats );
FOR i IN NVL( lot_ObjectsNeedingStats.first, 0 ) .. NVL( lot_ObjectsNeedingStats.last, 0

)
LOOP
/**
** Filter out all the system objects
**/
IF lot_ObjectsNeedingStats( i ).ownname NOT IN ( 'SYS'
,'SYSTEM'
,'SYSMAN'
,'CTXSYS'
,'DBSNMP' ) THEN
/**
** Non System object
**
** Determine whether this object is an "INDEX" or "TABLE"
**/
IF lot_ObjectsNeedingStats( i ).objtype = 'INDEX' THEN
SELECT table_owner
,table_name
INTO lvc_tableowner
,lvc_tablename
FROM dba_indexes
WHERE 1 = 1
AND owner = lot_ObjectsNeedingStats( i ).ownname
AND index_name = lot_ObjectsNeedingStats( i ).objname;
ELSE
lvc_tableowner := lot_ObjectsNeedingStats( i ).ownname;
lvc_tablename := lot_ObjectsNeedingStats( i ).objname;
END IF; /** Object Type checking **/
/**
** Trim off the default "PS_" from the table name if it exists
**/
IF SUBSTR( lvc_tablename, 1, 3 ) = 'PS_' THEN
lvc_PSRecordName := SUBSTR( lvc_tablename, 4 );
ELSE
lvc_PSRecordName := lvc_tablename;
END IF; /** Strip "PS_" **/
/** Set the temp table trap **/

lb_IsTempTable := FALSE;
/** rectype = 7 denotes a PeopleSoft temp table **/

sql_stmt := 'SELECT 1 FROM ' || lvc_tableowner || '.PSRECDEFN WHERE recname =
:b1 and rectype = 7';
/**
** Check to see if the record
** is a base temp table.
**
** Example Table name = PS_TEMP_TAO
**/
BEGIN
EXECUTE IMMEDIATE sql_stmt
INTO lint_tmp
USING lvc_PSRecordName;
-- If we make it here, we found a record

lb_IsTempTable := TRUE;
EXCEPTION
WHEN NO_DATA_FOUND THEN
/**
** Record was not a base temp table
**
** Check if record is a single digit temp instance
**
** Example Table name = PS_TEMP_TAO1
**/
IF SUBSTR( lvc_PSRecordName, LENGTH( lvc_PSRecordName ), 1 ) BETWEEN '0'
AND '9' THEN
/** Remove the last digit **/
lvc_PSRecordName := SUBSTR( lvc_PSRecordName, 1,
LENGTH( lvc_PSRecordName ) - 1 );
/**
** Do the Check
**/
BEGIN
INTO lint_tmp

EXCEPTION
/**
** Record was not a single digit temp instance.
**
** Check if record is a double digit temp instance
**
** Example Table name = PS_TEMP_TAO26
**/
IF SUBSTR( lvc_PSRecordName, LENGTH( lvc_PSRecordName ), 1 )
BETWEEN '1' AND '9' THEN
/** Remove the 2nd to last digit **/
lvc_PSRecordName := SUBSTR( lvc_PSRecordName, 1, LENGTH(
lvc_PSRecordName ) - 1 );
/**
** Do the Check
**/
BEGIN
INTO lint_tmp

EXCEPTION
-- We have not found a temp table!
NULL;
WHEN OTHERS THEN
RAISE;
END; /** 2 digit dedicated temp table Check **/
END IF; /** Check 2nd last char for digit **/
WHEN OTHERS THEN
RAISE;
END; /** single digit dedicated temp table Check **/
END IF; /** Checking last digit **/

WHEN OTHERS THEN
IF SQLCODE = -942 THEN /** table or view does not exist **/
/** Non PeopleSoft Table/Index found.
** Treat as though it was not a temp table.
** Generate Stats
**/
NULL;
ELSE
/** Unexpected error **/
RAISE;
END IF;
END; /** base temp table check**/
IF lb_IsTempTable = FALSE THEN

lts_StartTime := SYSTIMESTAMP;
dbms_output.put_line( 'Generating stats on ' ||
LOWER( lot_ObjectsNeedingStats( i ).objtype ) || ' ' || lot_ObjectsNeedingStats( i ).ownname
|| '.' || lot_ObjectsNeedingStats( i ).objname || '.' );
IF lot_ObjectsNeedingStats( i ).objtype = 'INDEX' THEN

/*
PROCEDURE GATHER_INDEX_STATS
Argument Name Type In/Out Default?
------------------------------ ----------------------- ------ --------
OWNNAME VARCHAR2 IN
INDNAME VARCHAR2 IN
PARTNAME VARCHAR2 IN DEFAULT
ESTIMATE_PERCENT NUMBER IN DEFAULT
STATTAB VARCHAR2 IN DEFAULT
STATID VARCHAR2 IN DEFAULT
STATOWN VARCHAR2 IN DEFAULT
DEGREE NUMBER IN DEFAULT
GRANULARITY VARCHAR2 IN DEFAULT
NO_INVALIDATE BOOLEAN IN DEFAULT
STATTYPE VARCHAR2 IN DEFAULT
FORCE BOOLEAN IN DEFAULT
*/
EXECUTE IMMEDIATE '
BEGIN
DBMS_STATS.GATHER_INDEX_STATS(
ownname => ''' || lot_ObjectsNeedingStats( i ).ownname || '''
,indname => ''' || lot_ObjectsNeedingStats( i ).objname || '''
,partname => ''' || lot_ObjectsNeedingStats( i ).partname || '''
,estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE
,degree => DBMS_STATS.AUTO_DEGREE
);
END;
';
ELSE
/*
PROCEDURE GATHER_TABLE_STATS
Argument Name Type In/Out Default?
------------------------------ ----------------------- ------ --------
OWNNAME VARCHAR2 IN
TABNAME VARCHAR2 IN
PARTNAME VARCHAR2 IN DEFAULT
ESTIMATE_PERCENT NUMBER IN DEFAULT
BLOCK_SAMPLE BOOLEAN IN DEFAULT
METHOD_OPT VARCHAR2 IN DEFAULT
DEGREE NUMBER IN DEFAULT
GRANULARITY VARCHAR2 IN DEFAULT
CASCADE BOOLEAN IN DEFAULT
STATTAB VARCHAR2 IN DEFAULT
STATID VARCHAR2 IN DEFAULT
STATOWN VARCHAR2 IN DEFAULT
NO_INVALIDATE BOOLEAN IN DEFAULT

STATTYPE VARCHAR2 IN DEFAULT
FORCE BOOLEAN IN DEFAULT
*/
EXECUTE IMMEDIATE '
BEGIN
DBMS_STATS.GATHER_TABLE_STATS(
ownname => ''' || lot_ObjectsNeedingStats( i ).ownname || '''
,tabname => ''' || lot_ObjectsNeedingStats( i ).objname || '''
,partname => ''' || lot_ObjectsNeedingStats( i ).partname || '''
,estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE
,block_sample => FALSE
,method_opt => ''FOR ALL COLUMNS SIZE AUTO''
,degree => DBMS_STATS.AUTO_DEGREE
,cascade => FALSE
);
END;
';
END IF;
lts_FinishTime := SYSTIMESTAMP;
/**
** Create status string here.
**
** If so inclined.
**/
ELSE
dbms_output.put_line( 'NOT Generating stats on temp ' ||
LOWER( lot_ObjectsNeedingStats( i ).objtype ) || ' ' || lot_ObjectsNeedingStats( i ).ownname
|| '.' || lot_ObjectsNeedingStats( i ).objname || '.' );
END IF; /** Gen Stats **/
/**
** Insert status info
**
** If so inclined
**
COMMIT;
**/
END IF; /** System object filter **/
END LOOP; /** Object stale stats loop **/
END;
/

Appendix B – Validation and Feedback
This section documents that real-world validation that this Red Paper has received.
CUSTOMER VALIDATION
PeopleSoft is working with PeopleSoft customers to get feedback and validation on this document. Lessons
learned from these customer experiences will be posted here.
FIELD VALIDATION
PeopleSoft Consulting has provided feedback and validation on this document. Additional lessons learned from
field experience will be posted here.

Appendix C - References
1. Peoplesoft Installation Guide - Oracle Tuning chapter
2. http://www.oracle.com/oramag/
3. http://metalink.oracle.com

Appendix D – Revision History
Authors
Jayagopal Theranikal, Senior Manager, Application Performance
Having more than 15 years of Oracle database experience and more than 6 years of Peoplesoft
Application tuning experience. Worked on SCM application tuning and benchmarks in Performance &
Benchmarks group.
Rama Tiruveedhula, Principal Performance Engineer
Lawrence Schapker, Principal Performance Engineer
15 years of Oracle database experience as a production DBA, development DBA, systems engineer, and
developer. 2+ years experience with PeopleSoft applications tuning. Worked on SCM applications tuning
within Performance & Benchmarks group.
Michelle Lam, Consulting Performance Engineer
10+ years of experience with PeopleSoft applications tuning, and 12 years of Oracle database experience.
Worked on Fusion/Enterprise applications architecture within Performance & Benchmarks group.
Glenn Low, Principal Performance Engineer
Reviewers
The following people reviewed this Red Paper:
Revision History
1. 02/01/2007: Created document.
2. 02/29/2007:
Peoplesoft Enterpise Performance on Oracle 10g Database
Jan 2007
Author: Jayagopal Theranikal
Contributing Authors: Rama Tiruveedhula

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Copyright © 2006, Oracle. All rights reserved.
This document is provided for information purposes only and the

contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any

other warranties or conditions, whether expressed orally or implied
in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document and no contractual obligations
are formed either directly or indirectly by this document. This document
may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle

Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.

Peoplesoft Enterprise Performance On Oracle 10G Database

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Peoplesoft Enterprise Performance On Oracle 10G Database

Uploaded by

Copyright:

Available Formats

PeopleSoft Enterprise Performance

on Oracle 10g Database

PEOPLESOFT 8 BATCH PeopleSoft 8 Batch

Product(s): All Enterprise products

Release(s): PeopleSoft 8.x, 9.x

 PeopleSoft Performance Tips

 Database Tuning Tips

 SQL Query Tuning Tips

 Use of Database Features

© Copyright © 2006 Oracle, Inc. All rights reserved. i

Chapter 2 - Generating Statistics........................................................................................................................... 2

Chapter 3 - Dedicated Temporary Tables............................................................................................................. 11

Chapter 4 - Tablespace Selection.......................................................................................................................... 15

Chapter 5 - Maintaining Indexes............................................................................................................................ 18

Chapter 6 - Cursor Sharing.................................................................................................................................... 21

Chapter 7 - Batch Server Selection....................................................................................................................... 27

Chapter 8 - Capturing Traces................................................................................................................................ 29

Appendix A – Sample script to gather statistics on tables................................................................................41

Appendix B – Validation and Feedback................................................................................................................ 46

Appendix D – Revision History............................................................................................................................. 48

© Copyright © 2006 Oracle, Inc. All rights reserved. iii

STRUCTURE OF THIS RED PAPER

Many of the fundamental concepts related to performance tuning in PeopleSoft PeopleBooks:

 PeopleSoft Installation Guide - Oracle Tuning chapter

© Copyright © 2006 Oracle, Inc. All rights reserved. 1

Chapter 2 - Generating Statistics

To disable the GATHER_STATS_JOB execute the following SQL*Plus command:

MANUALLY GATHERING TABLE STATISTICS

© Copyright © 2006 Oracle, Inc. All rights reserved. 2

Sample DBMS_STATS Command:

EXECUTE DBMS_STATS.GATHER_TABLE_STATS( OWNNAME => 'ORAVOL'

The size_clause is defined as size_clause:= SIZE {integer | REPEAT | AUTO | SKEWONLY}

 integer : Number of histogram buckets: Range [1 to 254].

 REPEAT : Collects histograms only on columns that already have histograms.

GENERATING STATISTICS FOR DATA DICTIONARY TABLES

EXECUTE DBMS_STATS.GATHER_DICTIONARY_STATS( estimate_percent =>

© Copyright © 2006 Oracle, Inc. All rights reserved. 3

Generating System Statistics

STATISTICS AT RUNTIME FOR TEMPORARY TABLES

Command in SQL Step of an Application Engine program: %UpdateStats(%Table(INTFC_BI_HTMP))

© Copyright © 2006 Oracle, Inc. All rights reserved. 4

1. Edit the DDLORA.DMS delivered script:

Turning off %UpdateStats

Modify %UpdateStats to use Analyze command:

Step 1: Create PSSTATS package as follows:

Login SQLPLUS as PeopleSoft Dbowner to create the following PSSTATS package.

© Copyright © 2006 Oracle, Inc. All rights reserved. 5

CREATE OR REPLACE PACKAGE PSSTATS AS

PROCEDURE ANALYZE_TABLE (tab_name VARCHAR2, stats_mode varchar2);

CREATE OR REPLACE PACKAGE BODY PSSTATS AS

PROCEDURE ANALYZE_TABLE (tab_name IN VARCHAR2, stats_mode varchar2) IS

if stats_mode <> 'HIGH' then

command_text := 'ANALYZE TABLE '||tab_name||' ESTIMATE STATISTICS';

command_text := 'ANALYZE TABLE '||tab_name||' COMPUTE STATISTICS';

EXECUTE IMMEDIATE command_text;

2.1) Navigate to DDL Model Defaults

Click the “Search” button and then choose “Oracle” Platform.

© Copyright © 2006 Oracle, Inc. All rights reserved. 6

2.2) Choose SQL #4 (out of 5) for Oracle Platform.

2.3) Replace SQL#4 (out of 5) for Oracle Platform.

© Copyright © 2006 Oracle, Inc. All rights reserved. 7

2.4) Choose SQL #5 (out of 5) for Oracle Platform.

2.5) Replace SQL#5 (out of 5) for Oracle Platform.