oracle perf

7/30/2019 oracle perf

1/56

PeopleSoft Enterprise Performance

on Oracle 10g Database


2/56


3/56

PEOPLESO FT ENTERPRISEPERFORMANCE ON OR A C L E10G DATABASE

9 /4 /2008

Reference Number:

CRM Product(s):

CRM Release(s):

Revision Number:

Contains:

Generating Statistics Reviewing Dedicated Temporary Tables

Selecting Tablespaces

Maintaining Indexes

Using Cursor Sharing

Selecting Batch Servers

Capturing Traces

Sample Script to Gather Statistics On Tables


4/56

Copyright 2008 Oracle, Inc. All rights reserved. 4

Table of Contents

Table of Contents........................................................................................................................................................4

Chapter 1 - Introduction .............................................................................................................................................6

Structure of this Red Paper 6

Related Materials 6

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

Manually Gathering Table Statistics 7Sample DBMS_STATS Command............................................................................................................................................ 8

Generating Statistics for Data dictionary tables 9Generating System Statistics ...................................................................................................................................................... 9

Statistics at Runtime for Temporary Tables 9Example ..................................................................................................................................................................................... 9Turning off %UpdateStats .......................................................................................................................................................10Modify %UpdateStats to Use Analyze Command................................................................................................................... 10Turning Off Dynamic Sampling .............................................................................................................................................. 14

Histograms 14What Are Histograms?............................................................................................................................................................. 14Candidate Columns for Histograms within PeopleSoft Applications .......... ........... ........... .......... ........... ............ .......... ........... 14Creating Histograms................................................................................................................................................................. 15Viewing Histograms................................................................................................................................................................. 15

Chapter 3 - Reviewing Dedicated Temporary Tables............................................................................................16

What are Dedicated Temp Tables? 16Performance Tips for Dedicated Temp Tables............ ........... .......... ........... ........... ........... ........... .......... ........... .......... ........... .. 16

Application Engine Performance with Dedicated Temporary Tables 17How Do Temp Tables Work in AE?........................................................................................................................................ 17Test Case Explaining Temp Table Behavior.................. ........... ........... ........... ........... .......... ........... ........... .......... ........... ......... 17Drawbacks of Using Base Temp Table.................................................................................................................................... 18Recommendations .................................................................................................................................................................... 18

Creating PeopleSoft Temporary Tables as Oracle Global Temp Tables 19What are Global Temporary Tables? ....................................................................................................................................... 19Can GTTs Be Used in Place of Dedicated Temp Tables? ........... .......... ........... .......... ........... ........... .......... ........... ........... ....... 19

Chapter 4 - Selecting Tablespaces ........................................................................................................................21

Locally Managed Tablespaces 21Advantages of Locally Managed Tablespaces......................................................................................................................... 21Space Management .................................................................................................................................................................. 21Locally Managed - AUTO ALLOCATE................................................................................................................................. 21Locally Managed - UNIFORM EXTENT ............................................................................................................................... 22

Temporary Tablespaces 22Tempfile Based ........................................................................................................................................................................ 22

UNDO Management 22Automatic Undo Management ................................................................................................................................................. 23


5/56

9/4/2008 PeopleSoft Enterprise CRM Red Paper

5

Table/Index Partitioning 23What Is Partitioning? ............................................................................................................................................................... 23

Chapter 5 - Maintaining Indexes.............................................................................................................................24

Index Tips 24

Rebuilding of Indexes 24

Function-Based Indexes 25

Chapter 6 - Using Cursor Sharing..........................................................................................................................27

Use of Bind Variables 27AE - Reuse Flag ....................................................................................................................................................................... 27

SQR/COBOL - CURSOR_SHARING 30Example ...................................................................................................................................................................................30Pros and Cons of CURSOR_SHARING..................................................................................................................................31

Chapter 7 - Selecting Batch Servers...................................................................................................................... 33

Scenario 1: Process Scheduler And Database Server on Different Boxes 33

Scenario 2: Process Scheduler and Database Server on one BOX 33

What is the recommended scenario? 34

Chapter 8 - Capturing Traces .................................................................................................................................35

Online Performance Issues 35Settings for Single User Online Session Trace ........... ........... ........... ........... .......... ........... ........... .......... ........... .......... ........... .. 36Application Server Settings for Tracing an Online Process............... ........... ........... ........... ........... .......... ........... .......... .......... . 37

AE Performance Issues 38Configuration Settings for Tracing an AE Process on the AE.......... ........... .......... ........... .......... ........... ........... ........... .......... .. 38Configuration Settings for Tracing an AE Process on the Database.................. ........... .......... ........... ........... ........... .......... ...... 39

COBOL Performance Issues 41

SQR Reports Performance Issues 41

ORACLE Performance Issues 41

Generating Explain Plan for SQL Using sqltexplain.sql 42

Automatic Workload Repository 42Generating a HTML or Text AWR Report: ............................................................................................................................. 43AWR Report Analysis ............................................................................................................................................................. 43

Appendix A Validation and Feedback..................................................................................................................48

Appendix B Sample Script to Gather Statistics on Tables................................................................................53

Customer Validation 53Field Validation 53

Appendix C References ........................................................................................................................................54

Appendix B Revision History................................................................................................................................55Authors..................................................................................................................................................................................... 55Revision History ......................................................................................................................................................................55


6/56


9/4/2008

Chapter 1 - Introduction

This Red Paper is a practical guide for technical users, installers, system administrators, and programmers whoimplement, maintain, or develop applications for your PeopleSoft system. In this Red Paper, we discuss guidelineson how to diagnose a PeopleSoft Online Transaction environment, including PeopleSoft Internet Architecture andPortal configuration. Configuration of Batch processes is not covered in this document.

Much of the information contained in this document originated within PeopleSoft Development and is thereforebased on "real-life" problems encountered in the field. Although every conceivable problem that one couldencounter in this document, the issues that appear are the problems that prove to be the most common ortroublesome.

STRUCTURE OF THIS RED PAPER

This red paper provides guidance on how to achieve the best performance of PeopleSoft in the Oracle databaseenvironment.

Keep in mind that PeopleSoft updates this document as needed so that it reflects the most current feedback wereceive from the field. Therefore, the structure, headings, content, and length of this document is likely to vary witheach posted version. To see if the document has been updated since you last downloaded it, compare the date ofyour version to the date of the version posted on Customer Connection.

RELATED MATERIALS

We assume that our readers are experienced IT professionals, with a good understanding of PeopleSofts InternetArchitecture. To take full advantage of the information covered in this document, we recommend that you have abasic understanding of system administration, basic Internet architecture, relational database concepts/SQL, andhow to use PeopleSoft applications.

This document is not intended to replace the documentation delivered with the CRM PeopleBooks. Werecommend that before you read this document, you read the PIA related information in the PeopleToolsPeopleBooks to ensure that you have a well-rounded understanding of our PIA technology. Note: Much of theinformation in this document eventually gets incorporated into subsequent versions of the PeopleBooks.

Many of the fundamental concepts related to PIA are discussed in the following PeopleSoft PeopleBooks:

PeopleSoft Internet Architecture Administration (PeopleTools|Administration Tools|PeopleSoft InternetArchitecture Administration)

Application Designer (Development Tools|Application Designer)

Application Messaging (Integration Tools|Application Messaging)

PeopleCode (Development Tools|PeopleCode Reference)


7/56



Chapter 2 - Generating Statistics

When using Oracle's Cost Based Optimizer (CBO), query performance depends greatly on appropriate table andindex statistics. Maintenance of these statistics is critical to optimal database and query performance. At databasecreation, Oracle 10g Scheduler contains a default nightly job that 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 here:

SELECT *FROM DBA_SCHEDULER_JOBSWHERE JOB_NAME = 'GATHER_STATS_JOB';

Because this job does not and cannot take into account the requirements for PeopleSoft, we recommend that younot allow this job to run after it has initially executed. We recommend that you disable this job after its initial

execution.

To disable the GATHER_STATS_JOB, run the following SQL*Plus command:

BEGINDBMS_SCHEDULER.DISABLE('GATHER_STATS_JOB');

END;/

The reasoning for this recommendation is because PeopleSoft Application Engine (AE) programs use manystandard Oracle tables and PeopleSoft temporary tables. The default GATHER_STATS_JOB picks up thetemporary tables, and regenerates statistics on them, which is not desirable because many of these tables do notcontain data.

We recommend that you update the statistics of only nontemporary PeopleSoft tables and indexes. We alsorecommend that you regenerate statistics for only tables and indexes that are considered stale or missing by thedatabase. A sample script to provide this functionality is listed in the Appendix. By generating statistics on only thenontemporary tables and indexes, the temporary object statistics are not updated with improper values.Regenerating statistics on only stale or missing objects reduces the overall time needed to regenerate statistics ona nightly, weekly, or monthly basis.

We recommended that you do notgather statistics on objects during peak operational hours. Cursor invalidationcan cause severe performance degradation.

It is advisable to gather statistics periodically for objects where the statistics become stale over time because ofchanging data volumes or changes in column values. You should gather new statistics after a schema object's dataor 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. You should also gather newstatistics on the average row length after you update data into a table. Use the DBMS_STATS package to updatestatistics. It is not possible to recommend a single command line script on how to update statistics nor how often toupdate statistics; these details depend on factors like data distribution, business rules, and time and window ofeach organization. You must work with your DBA to come up with an appropriate strategy.

MANUALLY GATHERING TABLE STATISTICS


8/56



The DBMS_STATS package provides the ability to generate statistics in parallel by specifying the degree ofparallelism. The ability to generate statistics in parallel significantly reduces the time needed to refresh objectstatistics.

Note: The use of procedures within DBMS_STATS is recommended. Oracle will no longer support ANALYZE infuture releases.

Sample DBMS_STATS Command

Here is a 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 provides the same functionality as ANALYZEs COMPUTE.Using a value of 100 is not the same as COMPUTE. The default value for ESTIMATE_PERCENT isDBMS_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 percent tend toprovide the best balance between speed and calculation accuracy. Run tests to find the appropriate value.

Data distribution is also gathered when using DBMS_STATS. The most basic information about the datadistribution is the maximum value and minimum value of the column within a table. However, this level of statisticsmay not be sufficient for the optimizer's needs if the data within the column is skewed. With the METHOD_OPTparameter set to For All Columns Size Auto, Oracle automatically determines which columns require histogramsand 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 thecolumns.

SKEWONLY: Determines the columns to collect histograms based on the data distribution of the columns.

Note: We strongly recommend that you read Note 237293.1 of Oracle Metalink. This note includes a set of notesand examples that help DBAs move updating statistics from ANALYZE to DBMS_STATS.

With the CASCADE parameter set to TRUE, the associated indexes are also analyzed. The default setting forCASCADE is FALSE.

Note: Specifying the DEGREE only helps gather table statistics (partitioned or nonpartitioned) in parallel. The indexstatistics cannot make use of this flag and does not run in parallel.


9/56



GENERATING STATISTICS FOR DATA DICTIONARY TABLES

We recommend that you generate statistics on dictionary tables after the initial database is loaded with data andalso whenever database size has increased considerably. Here is an example of this command:

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) orsimulates a workload (no workload statistics). The statistics are collected using theDBMS_STATS.GATHER_SYSTEM_STATS procedure. We highly recommend you gather system statistics.

EXECUTE DBMS_STATS.GATHER_SYSTEM_STATS (gathering_mode => 'NOWORKLOAD');

Note: A user must have DBA privileges or the GATHER_SYSTEM_STATISTICS role to update dictionary orsystem statistics.

STATISTICS AT RUNTIME FOR TEMPORARY TABLES

PeopleSoft uses shared or dedicated temporary tables in batch processes. These temporary tables have few or norows in the beginning of the process. At the end of the process, these tables again have few or no rows. Keepingthe statistics current for these tables is somewhat challenging. A temporary tables life cycle is as follows:

All rows are truncated (if dedicated) or deleted (if shared) at the beginning of an AE execution

automatically.

Rows are populated.

All rows are truncated (if dedicated) or deleted (if shared) at the end of an AE execution, if the programmerhas requested. This truncation is not performed automatically.

Beginning with PeopleSoft 8, an AE program can use the meta-SQL %UpdateStats after rows are populated into atemporary table to update statistics on the temporary table prior to the tables use in subsequent SQL statements.

Note: Commit is required prior to running the %UpdateStats statement. Due to the implicit commit feature thatOracle uses when performing DDL (statistics gathering is considered DDL), the AE ignores the %UpdateStatscommand after any uncommitted changes. Allowing the implicit commit may affect the restart capability of the

program.

Example

Here is the command in the SQL Step of an AE program: %UpdateStats(%Table(INTFC_BI_HTMP))

This meta-SQL starting with PeopleTools 8.48 issues the following Oracle database command at runtime:


10/56



DBMS_STATS.GATHER_TABLE_STATS (ownname=> [DBNAME], tabname=>[TBNAME], estimate_percent=>1,method_opt=> 'FOR ALL COLUMNS SIZE 1',cascade=>TRUE);

Note: To reduce the increased overhead of DBMS_STATS at runtime (when compared to ANALYZE withestimate), the ESTIMATE_PERCENT parameter was set to 1.

Note: PeopleSoft stores the default syntax for the gather stats command in a table PSDDLMODEL. Use thesupplied script (DDLORA.DMS) to change the default setting or to add a required SAMPLE ROWS/PERCENT for

the ESTIMATE clause.

For example: Lets assume that we want to change the ESTIMATE_PERCENT option of LOW option to 5 percentand the HIGH option to 80 percent. With this as our goal, complete the following steps:

1. Edit the DDLORA.DMS-delivered script:

The first occurrence of the DBMS_STATS is used for the LOW option of %UpdateStats. The secondoccurrence is used for the HIGH option of %UpdateStats.

4,2,0,0,$longDBMS_STATS.GATHER_TABLE_STATS (ownname=> [DBNAME], tabname=>[TBNAME], estimate_percent=>5,method_opt=> 'FOR ALL INDEXED COLUMNS SIZE 1',cascade=>TRUE);

//5,2,0,0,$longDBMS_STATS.GATHER_TABLE_STATS (ownname=> [DBNAME], tabname=>[TBNAME], estimate_percent=>80,method_opt=> 'FOR ALL INDEXED COLUMNS SIZE 1',cascade=>TRUE);//

2. Run the modified DDLORA.DMS through DataMover.

Ensure that the temporary table statistics have been handled as shown in the code listed in step 1. If you findany temporary table that was not updated during the run time, then plan to use a manual method of updatingthe statistics.

Turning off %UpdateStats

Note: We urge you not to turn off this feature. Turning off this feature would affect the entire process scheduler.

Having the update statistics at the runtime incurs some overhead. If you want to turn off this feature, check theProcess 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 TotalSQL Statement Count Time Count Time Count Time TimeI nsBal T. UpdSt at . S 2 0.0 2 19.5 0 0.0 19.5


11/56



Once you confirm that using DBMS_STATS to update statistics is causing a lot of overhead when compared toAnalyze with estimate when using %Updatestats, you can revert %Updatestats to use the Analyze command bycompleting the following steps:

Creating the PSSTATS Package

Log in SQLPLUS as PeopleSoft Dbowner to create the following PSSTATS package.

CREATE OR REPLACE PACKAGE PSSTATS ASPROCEDURE ANALYZE_TABLE (tab_name VARCHAR2, stats_mode varchar2);END PSSTATS;/CREATE OR REPLACE PACKAGE BODY PSSTATS ASPROCEDURE ANALYZE_TABLE (tab_name IN VARCHAR2, stats_mode varchar2) IScommand_text VARCHAR2(2000);BEGIN

if stats_mode 'HIGH' thencommand_text := 'ANALYZE TABLE '||tab_name||' ESTIMATE STATISTICS';

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

end if;EXECUTE IMMEDIATE command_text;

END ANALYZE_TABLE;END PSSTATS;/

Modifying SQL#4 and SQL#5 DDL Model Defaults for Oracle Platform

1. Navigate to DDL model defaults by selecting PeopleTools, Utilities, Administration, DDL Model Defaults.

2. Click the Search button and then select Oracle Platform.

Navigating to DDL model defaults


12/56



3. Select SQL #4 (out of 5) for Oracle Platform.

DDL Model Defaults page

4. Copy Model SQL from the PeopleSoft Internet Architecture page to a backup text file so that you can revertback to using DBMS_STATS in the future if you so choose.

5. Replace the Model SQL for Oracle Platform with the following:

psstats.analyze_table(tab_name=>[TBNAME],stats_mode=>'LOW');



13/56



6. Select SQL #5 (out of 5) for Oracle Platform.


7. Copy Model SQL from the PeopleSoft Internet Architecture page to a backup text file so that you can revertback to using DBMS_STATS in the future if you so choose.

8. Replace the Model SQLfor Oracle Platform with the following.

psstats.analyze_table(tab_name=>[TBNAME],stats_mode=>'HIGH');


This change affects all PeopleSoft programs that use %UpdateStats, as well as DataMover import scripts withoption Set statistics ON (ON is the default value).


14/56



Note: Due to this change affecting all the programs using %UpdateStats, we strongly recommend that you performregression test before implementing in production. Do not use Analyze to update statistics during regular databasemaintenance window.

Turning Off Dynamic Sampling

Dynamic sampling was introduced in Oracle 9i. Oracle determines at compile time whether a query would benefitfrom dynamic sampling. If so, a recursive SQL statement is issued to scan a small random sample of the table'sblocks and to apply the relevant single table predicates to estimate predicate selectivity. The sample cardinality canalso be used, in some cases, to estimate table cardinality. Any column and index statistics are also collected on thefly. Dynamic sampling is controlled by the initialization parameter named OPTIMIZER_DYNAMIC_SAMPLING.

Because most of PeopleSoft programs use %UpdateStats to manage temporary table statistics, we recommendthat you turn off this parameter as follows:

OPTIMIZER_DYNAMIC_SAMPLING = 0

HISTOGRAMS

What Are Histograms?

Histograms provide improved selectivity estimates in the presence of data skew, resulting in optimal executionplans with nonuniform data distributions. A histogram partitions the values of a column into bands so that all columnvalues in a band fall within the same range. CBO uses data within the histograms to get accurate estimates of thedistribution of column data.

Oracle uses height-balanced histograms or frequency-based histograms based on the number of distinct valuesand the number of bands. See Oracle documentation for more details.

Candidate Columns for Histograms within PeopleSoft Applications

For uniformly distributed data, the CBO can make fairly accurate estimates about the cost of executing a particularstatement without the use of histograms. Histograms, like all other optimizer statistics, are static and change onlywhen new statistics are generated with the SIZE option within the DBMS_STATS procedures.

Histograms are persistent objects. Therefore, histograms have associated maintenance and storage costs. Usehistograms only when they substantially improve query plans. In general, create histograms:

1. On columns that are frequently used in WHERE clauses of queries.

2. On columns where highly skewed data distribution exists.

3. When a literal value is provided instead of a bind variable for the given column in the where clause.

Histograms are not usefulfor columns with the following characteristics:

Column data is uniformly distributed.

Column is not used in WHERE clauses of queries.

Column data is unique.

Column is used in the where clause but contains a bind variable instead of a literal.


15/56



Note: Bind Peeking (BP) was designed to fix the last bullet point in the previous list. However, due to additionalissues that BP causes, we do not recommend the use of BP.

Columns such as PROCESS_INSTANCE, ORD_STATUSare likely candidates that benefit from histograms.

Creating Histograms

Creation of specific column histograms is no longer needed as long as the DBMS_STATS procedures are usedwith the METHOD_OPT parameter containing SIZE AUTO. Based on column usage within runtime SQL whereclauses and the amount of data skew within the column, the SIZE AUTO value instructs the DBMS_STATSprocedure to generate only those columns that would benefit from histograms.

Note: If any other value for METHOD_OPT is provided (for example, SIZE 1 or SIZE REPEAT), theautomatic creation of histograms is deactivated.

Viewing Histograms

You can display information about whether a table contains histograms using the following dictionary views:

USER_HISTOGRAMS

ALL_HISTOGRAMS

DBA_HISTOGRAMS

You can display the number of bands within a columns histogram using the following dictionary views:

USER_TAB_COLUMNS

ALL_TAB_COLUMNS

DBA_TAB_COLUMNS


16/56



Chapter 3 - Reviewing Dedicated Temporary Tables

WHAT ARE DEDICATED

TEMP TABLES?

Batch processes written in AE usePeopleSoft-designated temporarytables (also referred to as DedicatedTemporary Tables) for betterprocessing. This technique minimizespotential locking issues and improvesprocessing time.

Dedicated temporary tables areregular Oracle tables that are flaggedas temporary in the PeopleSoftdictionary tables. When implementedon Oracle databases, PeopleSoftdesignated temporary tables are builtusing Oracle tables. Required temptables are linked to the AE program inthe program property window. Therequired number of instances isspecified for each AE program.

For example, look at the ProgramProperties page for the AE programBill Finalization (BIIF0001) at right.

The instance count specified in thisexample is the limit on the number of atemp table's instances that can beused when multiple instances of theprogram are running. If the number ofprograms run is more than thespecified count (10, in this example),then the additional processes will be abandoned or the base temp tables will be used, depending on the Runtimeoption setting.

Performance Tips for Dedicated Temp Tables

If issues are found with parallel truncates on dedicated temporary tables, create separate table space for thesetables with a block size that is greater (if possible) than the current standard table space block size. Then,configure the initialization parameters of the database to include a separate buffer cache for this new block size. Aseparate buffer cache may lessen contention during parallel truncates.


17/56



APPLICATION ENGINE PERFORMANCE WITH DEDICATED TEMPORARY

TABLES

How Do Temp Tables Work in AE?

The number of temp tables that are associated to an AE program and the number of instances set up for theprogram determine the appropriate temp table instance that will be used during run time.

Test Case Explaining Temp Table Behavior

Below is the sample scenario that explains the temp table usage.

Temp Table Settings

In PeopleTools Options, set the value for theTemp Table Instances (Online) according tothe requirement. The Temp Table Instances(Total)is the same as the online number,unless you are using EPM.

In the AE program properties,set up theInstance Count to the required value. The instance countshould be equivalent to the number of concurrent streamsthat you are planning to run.

If you select Continue for the runtime option, the system

uses the base temp table if there are no temp tableinstances available at the time of the run.

In the AE program properties, Advanced options, if youselect the Batch Only option, the program will not beavailable for online transactions. You dont need to changethis setting unless you are advised to do so.

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 TempTable + Number of Temp Tables (Online) + Number of Temp Tables (AE Program)

Tools

AE Properties


18/56



= 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 TempTable + Number of Temp Tables (AE Program)

= 1+3 = 4

Temp Table Allocation Example

In the following example, wewill use Scenario 2 whereBatch Only option is selected.

When the program runs forthe first time, the system usestemp table instance 1.Subsequent parallel streams

use the rest of the instancesin sequence. In this example,the first three concurrentstreams will use the instancecounts 1, 2, and 3. When theuser tries to run the fourth,fifth, and sixth streams, theprogram will not find anavailable temp table instance and will use the base temp table.

Number of Concurrent Runs

The number of concurrent runs in this example is six; the number of available temp table instances is only three.

Therefore, the first three processes use the temp table instance. The final three use the base temp tables.

Drawbacks of Using Base Temp Table

For the following reasons, we do not recommend that you use base temp tables for any AE process:

1. The AE program issues a delete for the base temp tables, while it truncates the temp table instances.

2. Frequent deletes and inserts can cause fragmentation for the base temp tables.

3. Runtime table statistics on the base temp tables are ignored.

4. When multiple streams use the same base temp table, the possibility of contention exists.

Recommendations

We recommend that you:

1. Always set up an adequate number of temp table instances to achieve good performance.

2. Set up a temp table instance even if you are planning to run only one process at a time.

3. Set up a required value for the Process Scheduler server in the max concurrent field. The Max API Awarevalue should be larger than or equal to the total of Max Concurrent value set of all the process types.

AE PROCESS

TAB1 TAO

TAB2 TAO

TAB3 TAO

TAB4 TAO

TAB1 TAO1

TAB2 TAO1

TAB3 TAO1

TAB4 TAO1

TAB1 TAO2

TAB2 TAO2

TAB3 TAO2

TAB4 TAO2

TAB1 TAO3

TAB2 TAO3

TAB3 TAO3

TAB4 TAO3

AE PROCESS AE PROCESS AE PROCESAE PROCESS

AE PROCESS

Not advisable


19/56



Server Definition page

4. Set up the 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 ManagerMax Instances =12

We recommend that you use dedicated temp tables even when the process is running in single stream.

CREATING PEOPLESOFT TEMPORARY TABLES AS ORACLE GLOBAL TEMP

TABLES

What are Global Temporary Tables?

Oracle8i introduced Global Temporary Tables (GTT), which you can use as temporary processing tables for anybatch process. Instances of a GTT are created at the runtime in the user's temporary tablespace. These tables aresession specific. Table data is deleted once the session is closed or the transaction is committed. During table

creation time, you have the option to preserve or delete rows after the commit.

Can GTTs Be Used in Place of Dedicated Temp Tables?

Oracle does not provide a script or utility to create the GTTs in PeopleSoft applications. Also, there is no directmethod to specify the dedicated temp tables as GTTs. We recommend that you notcreate PeopleSoft temporarytables as GTTs.


20/56


21/56



Chapter 4 - Selecting Tablespaces

Starting from PeopleTools 8.44, the create scripts that Oracle provides create only locally managed tablespaces(LMTs).

LOCALLY MANAGED TABLESPACES

Locally Managed Tablespaces (LMTs) are the default starting in Oracle 9i. Extent management is done within thedatafile/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 nondatabase 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 that you specify in this clause must correspond with the

setting of one DB_nK_CACHE_SIZE parameter setting.

Advantages of Locally Managed Tablespaces

Here are some of the advantages of LMTs:

Reduced recursive space management.

Reduced contention on data dictionary tables and space management latches.

No coalescing required.

No rollback generated for space allocation and deallocation activities.

Fragmentations is reduced but not completely eliminated.

Space Management

Dictionary contention is reduced because space is managed at the datafile level. Information about extentallocation and deallocation are no longer stored in the dictionary tables.

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 the AUTO ALLOCATE option, Oracle manages the extent size based on the object size. AUTO ALLOCATE isthe preferable method if the tablespace holds the objects with various sizes.

Here is an example creating a LMT with AUTO ALLOCATE:


22/56



CREATE TABLESPACE TS_PERM_LOC_AUTO size 100M datafile '/perm/ora/ts_perm_loc_auto.dbf'EXTENT MANAGEMENT LOCAL AUTO ALLOCATE;

Locally Managed - UNIFORM EXTENT

With the UNIFORM EXTENT option, the size of each extent is fixed to the specified size. Ensure that you specifythe appropriate size to avoid creating a table with more extents.

The following statement creates a LMT with a fixed extent size of 128K:

CREATE TABLESPACE TS_PERM_LOC_UNI size 100M datafile '/perm/ora/ts_perm_loc_uni.dbf' EXTENTMANAGEMENT LOCAL UNIFORM SIZE 128K;

Uniform extent provides the best predictability and consistency. Having the consistent extent size eliminatesholes, or tablespace waste. Its easier for the DBA to do capacity planning, but to ensure optimum extent size, youshould do the planning. Creating different categories of tablespace, such as small, medium, and large, withdifferent uniform extent sizes and placing the tables in the appropriate tablespaces relevant for each tablesexpected size may improve performance.

TEMPORARY TABLESPACES

Every database user should be assigned a default temporary tablespace to handle the data sorts. You cannotspecify nonstandard block sizes for a temporary tablespace. In Oracle 10g, you cannot assign a regular tablespaceas the temporary tablespace. Oracle 10g flags as an error any assigned tablespace that is not a true Oracletemporary tablespace.

Tempfile Based

Oracle introduced a new tablespace type, temporary tablespace, that uses a tempfile instead of a datafile.Tempfile based tablespace is the preferred method for any temporary tablespace because it provides better extent

management and space management than datafile-based tablespace. In tempfile based tablespace, only localmanagement with UNIFORM EXTENT is allowed.

The following statement creates a temporary tablespace with uniform extent size of 500K:

CREATE TEMPORARY TABLESPACE TS_TEMP_LOC_UNI size 100M tempfile'/temp/ora/ts_temp_loc_uni.dbf' EXTENT MANAGEMENT LOCAL UNIFORM SIZE 500K;

Advantages

Here are some of the advantages of temporary tablespaces using tempfile:

Space management (extent allocation and deallocation) 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 asegment (and potentially many extents) for each sort.

UNDOMANAGEMENT


23/56



Automatic Undo Management

Automatic undo management is the preferred method of undo management and is the default when you create anew 10g database. If a database is upgraded from 9i, convert the database to use automatic undo managementinstead of rollback segments.

Automatic undo management enables you to allocate undo space in a single undo tablespace, instead of

distributing undo space in a set of statically allocated rollback segments. The Oracle server automatically handlesthe creation and allocation of space among the undo segments.

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 undomanagement requires that you specify an undo tablespace.

Here is an example of creating the database with undo tablespace:

CREATE DATABASE INVDBDATAFILE '/data3/oradata/INVDB/system/system01.dbf' SIZE 1024M

EXTENT MANAGEMENT LOCALLOGFILE

.DEFAULT TEMPORARY TABLESPACE TEMPTS1

UNDO TABLESPACE UNDOTSDATAFILE '/data4/oradata/INVDB/undo/undots01.dbf' SIZE 5048M;

TABLE/INDEX PARTITIONING

What Is Partitioning?

Partitioning is a data volume management technique that mayhave performance benefits; however, partitioning ismost effective on multiprocessor machines when implemented with increased db_writers and degree of parallelism.Partitioning addresses the key problem of supporting very large tables and indexes by enabling you to decomposethese tables and indexes into smaller and more manageable pieces called partitions. Once you define thepartitions, SQL statements can access and manipulate the partitions rather than managing entire tables or indexes.


24/56



Chapter 5 - Maintaining Indexes

PeopleSoft-supplied indexes are generic in nature. Depending on the customer's business needs and datacomposition, index requirements may vary. The following few tips will help DBAs manage indexes more efficiently.

INDEX TIPS

Here are some indexing tips:

1. Review the index recommendation document supplied by the product to see if any of the suggestions apply toyour installation.

2. Run the Oracle trace/TKPROF report for a process and check the access paths to determine the usage ofindexes.

Note: We recommend that you do not use the Index Skip Scan access method because it can be very slowwhen accessing large indexes.

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 ofInsert/Update/Delete DML.

Sometimes, an index that is omitted from a batch process may still be useful with an online page. The reversemay also be true. Perform thorough system analysis before deleting any index. Index deletion can severelyimpact another programs performance.

REBUILDING OF INDEXES

We recommend that you rebuild an index when a SQL execution plan accesses an index either by a range scanor full index scan and reveals a significant number of logical I/Os (as well as physical I/Os) in a relatively smallnumber of rows returned by the scan.

Typically significant I/Os can happen when a large number of rows have been deleted from the table. Within theindex, all the rows are logically deleted, but physically they still linger within until you rebuild the index. To improveruntime performance, Oracle does not coalesce near-empty blocks or rebalance physical index blocks. As a result,deleted blocks linger within the index until you rebuild it. During a range scan and a full index scan, thesedeleted/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 toOracle 10g. Three metalink notes were found that might provide a little insight as to when to rebuild or coalesce anindex.

Note 77574.1 Guidelines on When to Rebuild a B-Tree Index, dated October 20, 2005: This note islabeled for Oracle 7.0 to 9i inclusive. May indirectly be usable for Oracle 10.x. This note is referenced bynote 122008.1.

Note 99618.1 ORACLE8i - Coalescing Indexes, dated October 20, 2005: This note is labeled for versionOracle 8i only, but does describe index coalescing and discuss the pros and cons for using coalescingindexes.


25/56



Note 122008.1 Script: Lists All Indexes that Benefit from a Rebuild, dated May 6, 2005: This note islabeled for Oracle 7.3 to 10.2 inclusive. This note provides a script that may be used to determine whetheran index may be a candidate for rebuilding. This note uses the suggested values from note 77574.1 andprovides a good basis for determining whether an index should be rebuilt. Please read note 77574.1 beforeusing this script.

Note: If a 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 containinga package function. We recommend that you contact customer support before you create a functional index.

Here is a test case:

Table PS_CUSTOMER has an index PS0CUSTOMER with NAME1 as the 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 it doesnt return any rows.

If data is stored in mixed case such as the above example, the only way to get the result using a consistentcase 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----- --------------- -----------------SHARE 1008 Adventure 54

Query does not use the PS0CUSTOMER index, so it takes a long time to return a result. However, the datathat it returns 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----- --------------- -----------------SHARE 1008 Adventure 54

Query uses the PSFCUSTOMER index, returns the query faster, and provides the correct output.

Note: Review the Oracle documentation pertaining to function-based indexes before you try to create them.

Starting with PeopleTools 8.48, PeopleTools generates indexes with DESCENDING columns. These indexes areconsidered function-based indexes in Oracle. Here is an example:


26/56



CREATE UNIQUE INDEX PS_GL_ACCOUNT_TBL ON PS_GL_ACCOUNT_TBL (SETID,ACCOUNT, EFFDT DESC) TABLESPACE PSINDEX STORAGE (INITIAL 45056 NEXT 100000MAXEXTENTS UNLIMITED PCTINCREASE 0) PCTFREE 10 PARALLEL NOLOGGING

When you select the descending column name from DBA_IND_COLUMNS, the index will show something likeSYS_NC00033$, which is a system-generated column name. To find the real column name, you must look inCOLUMN_EXPRESSION of DBA_IND_EXPRESSIONS.

select a.index_name,a.index_type,b.column_name from dba_indexes a,dba_ind_columns b, whereb.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, whereindex_name='PS_GL_ACCOUNT_TBL';

Because of bugs (#4939157 and 5092688) that caused wrong results or core dumps from queries using functionalindexes, PeopleSoft had recommended disabling functional indexes. However, disabling of functional indexes maycause SQLs that rely on these indexes to perform in an inefficient manner. We suggest that you go to the followinglink to check the availability of patches and apply them accordingly to fix the bugs and to remove the_disable_function_based_index=TRUE initialization parameter:

http://www4.peoplesoft.com/psdb.nsf/0/33440EC2DE7C886788257051005AEB72?OpenDocument


27/56



Chapter 6 - Using Cursor Sharing

When you run a SQL statement that does not exist in the shared pool, Oracle must fully parse that statement.Oracle must allocate memory for the statement from the shared pool, check the statement syntactically andsemantically, and so on. This process is referred to as a hard parse and is costly both in terms of CPU used and inthe number of latches that are performed.

Hard parsing happens when the Oracle server parses a query and cannot find an exact match for the query in thelibrary cache. Sometimes hard parsing causes excessive CPU usage. This problem occurs due to inefficientsharing of SQL statements. You can avoid this problem by using bind variables instead of literals in queries.

The number of hard parses can be identified in a PeopleSoft AE trace (128). Below is an example of the AE trace(128). Notice the compile count of 252 for the same SQL statement.

C o m p i l e E x e c u t e F e t c h TotalSQL Statement Count Time Count Time Count Time Time

BL6100.10000001.S 252 0.6 252 1.5 0 0.0 2.1

In Oracle Trace output, such statements appear 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 issomewhat difficult.

Oracle introduced this new parameter CURSOR_SHARING as of Oracle8i. By default, the parameters of this valueis set to EXACT, which means that the database looks for an exact match of the SQL statement while parsing.

Note: Setting the CURSOR_SHARING value at the instance level is not recommended in a PeopleSoftenvironment.

USE OF BIND VARIABLES

You can reduce the number of hard parses to one per multiple runs of the same SQL statement by coding thestatement with bind variables instead of literals.

Most of the PeopleSoft programs written in AE, SQR, and COBOL have been rewritten to address this issue. Insome situations, there are some steps in AE processes that are not using bind variables. This happens whencertain kinds of statements cannot handle bind variables in some platforms. As Oracle deals with bind variablesefficiently, such statements can typically be made to use bind variables.

The following section gives some guidelines on using bind variables.

AE - Reuse Flag

PeopleSoft AE programs use bind variables in the SQL statements, but these are PeopleSoft-specific variables.When the statement is passed to the database, the AE programs send the statement with literal values. The onlyway to tell the AE program to send the bind variables is by selecting the Reuse option for that statement that needsto use the bind variable.

If you decide to customize, we recommend that you select the Reuse option for all program steps..


28/56



Example: Statement in PC_PRICING.BL6100.10000001

UPDATE PS_PC_RATE_RUN_TAOSET RESOURCE_ID = %Sql(PC_COM_LIT_CHAR,%NEXT(LAST_RESOURCE_ID),1,20,20)WHERE PROCESS_INSTANCE = %ProcessInstanceAND 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 Reuse 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

C o m p i l e E x e c u t e F e t c h TotalSQL Statement Count Time Count Time Count Time TimeBL6100.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 = 10000561WHEREPROCESS_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 0Execute 1 0.01 0.01 0 2 5 1Fetch 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: 1Optimizer goal: CHOOSEParsing user id: 21 (PROJ84)

Rows Row Source Operation------- ---------------------------------------------------

1 UPDATE PS_PC_RATE_RUN_TAO2 INDEX RANGE SCAN (object id 16735)


29/56



Rows Execution Plan------- ---------------------------------------------------

0 UPDATE STATEMENT GOAL: CHOOSE1 UPDATE 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 presented in the previous example.

Statement with Reuse Option

AE Trace

-- 16.57.57 ......(PC_PRICING.BL6100.10000001) (SQL)UPDATE PS_PC_RATE_RUN_TAO SET RESOURCE_ID = :1 WHERE PROCESS_INSTANCE = 420AND BUSINESS_UNIT = :2 AND PROJECT_ID = :3 AND ACTIVITY_ID = :4 ANDRESOURCE_ID = :5 AND LINE_NO = :6/-- Bind variables:-- 1) 10000751-- 2) US004-- 3) PRICINGA1-- 4) ACTIVITYA1-- 5) VUS004VA10114050

-- 6) 1-- Row(s) affected: 1

C o m p i l e E x e c u t e F e t c h TotalSQL Statement Count Time Count Time Count Time TimeBL6100.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 = :1WHEREPROCESS_INSTANCE = 420 AND BUSINESS_UNIT = :2 AND PROJECT_ID = :3 ANDACTIVITY_ID = :4 AND RESOURCE_ID = :5 AND LINE_NO = :6


Misses in library cache during parse: 1Optimizer goal: CHOOSEParsing user id: 21 (PROJ84)


30/56



Rows Row Source Operation------- ---------------------------------------------------

252 UPDATE PS_PC_RATE_RUN_TAO504 INDEX RANGE SCAN (object id 16735)

Rows Execution Plan------- ---------------------------------------------------

0 UPDATE STATEMENT GOAL: CHOOSE252 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 notusing 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 SQLstatement. Oracle replaces the literal values with the system-bind variables and treats them once as a singlestatement and parses.

Setting the value at the session level is more appropriate. If you identify the program (SQR/COBOL) that is notusing the bind variables and must force them to use the binds at the database level, then adding the ALTERSESSION command at the beginning of the program is a better option.

If you are not willing to change the application program, then implementing the session level command through atrigger may provide you more flexibility.

Session level (using trigger): Here is sample trigger code that you can use to implement the session-level option:

CREATE OR REPLACE TRIGGER MYDB.SET_TRACE_INS6000BEFORE UPDATE OF RUNSTATUS ON MYDB.PSPRCSRQSTFOR EACH ROWWHEN ( NEW.RUNSTATUS = 7AND OLD.RUNSTATUS != 7AND NEW.PRCSTYPE = 'SQR REPORT'AND NEW.PRCSNAME = 'INS6000'

)BEGINEXECUTE IMMEDIATE 'ALTER SESSION SET CURSOR_SHARING=FORCE';

END;/

Note: You must give ALTER SESSION privilege to MYDB to make this trigger work.

Example

Here is an example SQL statement issued from a SQR/COBOL program:

SELECT .FROMPS_PHYSICAL_INV PI, PS_STOR_LOC_INV SLI WHERE.NOT EXISTS (SELECT 'X' FROMPS_PICKZON_INV_VW PZI WHERE PZI.BUSINESS_UNIT = 'US008' AND PZI.INV_ITEM_ID= 'PI000021' AND ..) ORDER BY ..

This example statement uses literal values in the whereclause, which causes a hard parse for each run. Everyhard parse has some amount of performance overhead. Minimizing these hard parses boosts performance.


31/56



This example statement gets run for every combination of BUSINESS_UNIT and INV_ITEM_ID. As per the datacomposition used in this benchmark, there were about 13,035 unique combinations of BUSINESS_UNIT andINV_ITEM_ID and about 19,580 total runs.

Oracle TKPROF Output with CURSOR_SHARING=FORCE

SELECT FROMPS_PHYSICAL_INV PI, PS_STOR_LOC_INV SLI WHERE ..NOT EXISTS (SELECT :SYS_B_09 FROM PS_PICKZON_INV_VW PZIWHERE 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 overall processing time is reduced significantly.

This table presents the overall statistics with no bind variables:

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS


Misses in library cache during parse:13190Misses in library cache during execute: 1

OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

call count cpu elapsed disk query current rows------- ------ -------- ---------- ---------- ---------- ---------- ----------

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

Misses in library cache during parse: 65

This table presents the overall statistics withbind variables:

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS


Misses in library cache during parse: 64Misses in library cache during execute: 1

OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

call count cpu elapsed disk query current rows------- ------ -------- ---------- ---------- ---------- ---------- ----------Parse 356 0.08 0.10 0 0 0 0Execute 357 0.47 0.48 0 5568 228 228


32/56



Fetch 667 0.00 0.01 0 1333 0 552------- ------ -------- ---------- ---------- ---------- ---------- ----------total 1380 0.55 0.59 0 6901 228 780

Misses in library cache during parse: 1

From these trace statistics, you can see that the number of library cache misses decreased dramatically with the

use of bind variables.

Original Timing Time with CURSOR_SHARING option %Gain

197 Sec 102 Sec 48%


33/56



Chapter 7 - Selecting Batch Servers

Process Scheduler runs PeopleSoft batch processes. Just as in the PeopleSoft architecture, you can set up theProcess Scheduler (batch server) to run from a database server or any other server.

SCENARIO 1:PROCESS SCHEDULERAND DATABASE SERVER ON

DIFFERENT BOXES

Running the Process Scheduler on a box other than the database server uses a TCP/IP connection to connect tothe database. Because the batch process may involve extensive SQL processing, this TCP/IP comes with a lot ofoverhead and may impact processing times. The impact is more evident in a process where excessive row-by-rowprocessing is done. In processes where the majority of SQL statements are set based, TCP/IP overhead is likelyreduced.

Dedicate a network connection between the batch server and the database to minimize the overhead.

SCENARIO 2:PROCESS SCHEDULER AND DATABASE SERVER ON ONE BOX

SERVER2Database Server / BatchServer

Use LocalConnection

OracleDB

Process Scheduler

SERVER1

Batch Server

SERVER2

Database Server

OracleDB

Process Scheduler

TCP/IP


34/56



Running the Process Scheduler on the database server eliminates the TCP/IP overhead and improves theprocessing time. However, keep in mind that this scenario does use additional server memory.

Set the following value in the Process Scheduler configuration file "psprcs.cfg" to use the direct connection insteadof TCP/IP:

UseLocalOracleDB=1

This kind of set up is useful for 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, we recommend Scenario 2,which eliminates connection overhead. Sometimes, it may not be possible to run the extensive batch processes onthe database server due to the limited availability of server resources.

A fair judgment depends on your environment and usage. You can set up both scenarios in your environment andthen select which scenario to use based on the time of the run and the complexity of the process. You can run allthe CRITICAL jobs using Scenario 2 and all reporting jobs using Scenario 1.


35/56



Chapter 8 - Capturing Traces

PeopleTools provides tracing facilities to capture online, as well as batch program flows. Oracle DBMS alsoprovides utilities to capture traces for details on SQL execution during a database session. The following are basicrecommendations that can assist you in capturing various traces in order to identify performance issues. Ensurethat you reset the values back to zero (that is, stop tracing) after you capture the needed trace files. Therecommendations provided here meet typical needs; specific scenarios may require additional settings to captureneeded details. Refer to PeopleTools documentation for complete discussion.

Note: Running a production environment with any of these settings may cause significant performance degradationdue to the overhead introduced by tracing.

ONLINE PERFORMANCE ISSUESTo debug performance issues within online pages, it is important to capture trace files for SQL and PeopleCodeevents. The following minimum trace settings are recommended for debugging.

SQL trace settings:

SQL statements

SQL statement variables

SQL connect, disconnect, commit, rollback

SQL fetch

All other SQL API calls except SSBs

PeopleCode trace settings:

Program starts

External function calls

Internal function calls

Function parameter values

Function return values

The trace file is written in the corresponding application server log directory on the machine where this applicationserver is running. Heres an example name for the file:

VP1_dhcp-psft-F-2nd-west-10-138-222-59.us.oracle.com.tracesql

within the directory:

/data2/ora/pt84803b/appserv/HRMSDB/LOGS

There are multiple ways to capture traces of online applications. Using the online runtime settings for a single useris the most efficient method and has the least performance impact on the system. Alternatively, you can set thetrace settings in the application servers configuration file. However, the application server trace settings will affectall users using the server and thus have a wider performance impact on the overall system.


36/56



Note: We do not recommend turning on trace on an application server in a production environment. Having traceon at the server level may cause significant performance degradation due to the overhead introduced by tracing.

Settings for Single User Online Session Trace

You can turn on tracing for a single user session. This is the recommended online trace method, and has the leastperformance impact on the system.

To turn on tracing for a user session:

1. Append &trace=yto your PeopleSoft Internet Architecture login URL

For example, http://ss-intel10:9100/psp/ps/?cmd=login&trace=y

2. Set your trace settings on the login page below before log in:

Oracle PeopleSoft Enterprise login page


37/56



Application Server Settings for Tracing an Online Process

Due to overhead introduced by trace, we do notrecommend application server tracing in a production environment.

You can set up various tracing parameters in the application server configuration file. You can turn on dynamicchanges in the application server by setting Allow Dynamic Changes=Y.

When setting the values for TraceSQL and TracePC within the application servers configuration file, the sum of theoptions requested becomes the value in which TraceSQL and TracePC are set.

When tracing SQL (TraceSQL), the following options are requested to be traced:

1 - SQL statements2 - SQL statement variables4 - SQL connect, disconnect, commit, and rollback8 - Row fetch (indicates that it occurred, not data)

+ 16 - All other API calls except ssb====

31 - The value TraceSQL is to be set.

We recommend a value of 31 when tracing with TraceSQL.

When tracing PeopleCode (TracePC), the following options are requested to be traced:

64 - Trace start of programs128 - Trace external function calls256 - Trace internal function calls512 - Show parameter values

+ 1024 - Show function return value======1984 - The value TracePC is to be set.

We recommend a value of 1984 when tracing with TracePC.

Here are sample option settings 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 TraceSqlMaskTraceSql=31TraceSqlMask=12319

;-------------------------------------------------------------------------; PeopleCode Tracing Bitfield;; Bit Type of tracing; --- ---------------; 1 - Trace entire program


38/56



; 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 TracePCMaskTracePC=1984TracePCMask=4095

Note: Performing online tracing at the database level (especially on a production environment) is difficult mainlybecause online sessions share database connections. As database connections are used, a single web serversession can use many different database connections. If tracing at the application server level is not adequate,contact customer support for more assistance.

AEPERFORMANCE ISSUES

Configuration Settings for Tracing an AE Process on the AE

When tracing is enabled for AE programs, the Process Scheduler creates a subdirectory under the processscheduler/log/output directory for each AE process. As an example, the trace directory created for the FS_BPprocess 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 the TraceSQL, as previously explained. Therecommended TraceSQL value is 31.

When tracing AE (TraceAE), the following options are requested to be traced:

1 - Trace STEP execution sequence to AET file2 - Trace Application SQL statements to AET file4 - Trace Dedicated Temp Table Allocation to AET file

+ 128 - Timings Report to AET file=====135 - The value TraceAE is to be set.

We recommend a value of 135 when tracing with TraceAE.

Here are sample option settings from psprcs.cfg:

;-------------------------------------------------------------------------; AE Tracing Bitfield;

; Bit Type of tracing; --- ---------------; 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; 16 - not yet allocated; 32 - not yet allocated; 64 - not yet allocated; 128 - Timings Report to AET file; 256 - Method/BuiltIn detail instead of summary in AET Timings Report; 512 - not yet allocated; 1024 - Timings Report to tables


39/56



; 2048 - DB optimizer trace to file; 4096 - DB optimizer trace to tablesTraceAE= 135

If tracing PeopleCode steps with an AE program is necessary, the following settings are needed within the ProcessScheduler configuration file to capture both SQL and PeopleCode events during a run.

PeopleCode tracing is not generally necessary, but is helpful when trying to debug procedural issues. Pleaseremember to restore original configuration values after you complete the trace.

We recommend a value of 31 when tracing with TraceSQL.

We recommend a value of 1984 when tracing with TracePC.

Here are sample option settings from psprcs.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; 1024 - SQL Informational Trace; Dynamic change allowed for TraceSql and TraceSqlMaskTraceSQL=31

;-------------------------------------------------------------------------; PeopleCode Tracing Bitfield;; Bit Type of tracing; --- ---------------; 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 TracePCTracePC=1984

Configuration Settings for Tracing an AE Process on the Database

There are two ways to generate a database trace file for an AE process:

1. You can set a value in the AE trace section of the Process Scheduler configuration file.

A raw SQL trace file generated by this setting is created within the UDUMP directory on the database server.The raw trace file contains details of each SQL statement that was run on the database, including the runtimeexecution plan of each statement. The raw trace is used as input to the tkprof database utility to generate aformatted trace report.

The calculation for the TraceAE value is the same as for TraceSQL, as previously outlined.


40/56



We recommend a value of 2183 when using this method.

Here is a sample option setting from psprcs.cfg:

;-------------------------------------------------------------------------

; AE Tracing Bitfield;

; Bit Type of tracing; --- ---------------; 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; 16 - not yet allocated; 32 - not yet allocated; 64 - not yet allocated; 128 - Timings Report to AET file; 256 - Method/BuiltIn detail instead of summary in AET Timings Report; 512 - not yet allocated; 1024 - Timings Report to tables; 2048 - DB optimizer trace to file; 4096 - DB optimizer trace to tablesTraceAE=2183

Note: This setting does not provide wait events and bind variable information. If you need this information, usethe second method.

2. Create a trigger 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 because the trace captures wait andbind information for all SQL.

For example, to generate trace for AE process PO_PO_CALC, you must create the following trigger. MYDB isthe database name and SET_TRACE_POCALC is the trigger name.

CREATE OR REPLACE TRIGGER MYDB.SET_TRACE_POCALCBEFORE UPDATE OF RUNSTATUS ON MYDB.PSPRCSRQSTFOR EACH ROWWHEN ( NEW.runstatus = 7AND OLD.runstatus != 7AND 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 tracefileidentifier.

Note: Drop or disable the trigger once the trace is captured.

Once the raw database trace is captured, run the tkprof program with following sort options:


41/56



tkprof sys=no explain=/sort=exeela,fchela,prscpu,execpu,fchcpu

Note: We discourage enabling tracing at the database instance level.

COBOLPERFORMANCE ISSUES

The following settings are needed within the process schedulers configuration file to capture summary reportinformation for a COBOL process. This report, as well as the database SQL trace, helps to debug performanceissues.

; 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; 1024 - SQL Informational Trace; Dynamic change allowed for TraceSql and TraceSqlMaskTraceSQL=128

SQRREPORTS PERFORMANCE ISSUES

Creating a trigger is the only way to generate SQL trace file for SQR reports. Here is an example trigger creationcommand for a SQR report:

CREATE OR REPLACE TRIGGER MYDB.SET_TRACE_INS6000BEFORE UPDATE OF RUNSTATUS ON MYDB.PSPRCSRQSTFOR EACH ROWWHEN ( NEW.runstatus = 7AND OLD.runstatus != 7AND NEW.prcstype = 'SQR REPORT'AND NEW.prcsname = 'INS6000'

)BEGINEXECUTE 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;/

ORACLEPERFORMANCE ISSUES

When you report performance issues in a Oracle database to PeopleSoft Global Support Center, you must:

1. Confirm that the required minimum patches are installed:


42/56



a) Generate a patch inventory list:

Log on to the DB server.

Change the directory to cd $ORACLE_HOME/Opatch.

Issue the following command: opatch lsinventory.

b) Verify you applied all required minimum patches:

Log on to Oracles PeopleSoft Customer Connection to make sure that

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: The Customer Connection website also documents initialization parameters that impactperformance.

2. Send PeopleSoft Global Support Center a copy of your init.ora or spfile.ora.

Note: You can use Remote Diagnostic Agent (RDA) to collect the information listed here. For instructions on how

to run RDA, see Note:414970.1 in Oracle Metalink.

GENERATING EXPLAIN PLAN FOR SQLUSING SQLTEXPLAIN.SQL

For enhanced Explain Plan and diagnostic information for one SQL statement, the sqltexplain utility is useful andrecommended. The details of this utility are provided in Oracle Meta Link Note 215187.1.

AUTOMATIC WORKLOAD REPOSITORY

Oracle 10g provides an automatic database performance monitoring tool called Automatic Workload Repository(AWR), which replaces the manual STATSPACK method that was provided in earlier versions. AWR automaticallygenerates snapshots of the system performance data once every hour (by default) and collects the statistics in theworkload repository. The various metrics collected by AWR include:

Wait events, such as Disk I/O wait, Network wait, lock wait, and commit wait.

Session history details showing top SQL taking most time and resource.

Operating system metrics for CPU, disk, network, and memory.

This information is useful for solving performance issues and finding the database load at any point in time in thepast. We highly recommend keeping this AWR running with default frequency. History of the snapshots is retainedfor seven days (by default) and usually does not occupy more than 300 MB within the SYSAUX tablespace. If thesystem has an average of more than 10 active concurrent sessions, you may need more room.

You must set the database initialization parameter STATISTICS_LEVEL to TYPICAL or ALL. TYPICAL is thedefault, and the parameter TIMED_STATISTICS must be set to TRUE to allow the database to properly populatethe workload repository.


43/56



Generating a HTML or Text AWR Report:

To generate an HTML or text AWR report:

1. Log in with a user that has the DBA role and run the awrrpt.sql script from within SQL*Plus :

@$ORACLE_HOME/rdbms/admin/awrrpt.sql

2. Specify whether you want a HTML or a text report.

Enter a value for report_type: html.

3. Specify the number of previous days you want snapshots to be listed.

Enter a value for num_days: 2.

A list appears displaying the snapshot IDs and the corresponding times when the snapshots weregenerated .

4. 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:

Use the report name awrrpt_1_150_160.

The AWR report is generated.

If you want to diagnose a specific issue, you can create a snapshot just prior to and then again just after executinga questionable program. Typically, this is not necessary.

Here is an example of how to manually create a snapshot via SQL*Plus:

BEGINDBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();

END;/

AWR Report Analysis

Most of the time, the database tuning activity is triggered by users complaining about the response time of atransaction or a batch job. The response time analysis consists of finding out where time is being spent in adatabase. The response time of a given transaction in the database always consists of the following two parts:

Response Time = Service Time + Wait Time

Service timeis CPU consumption by the database; wait timeis 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. Using this list, you can quicklyidentify the main areas on which you want to focus. In situations where CPU usage is much more significant thanwait time, it is less likely that investigating wait events will produce significant savings in response time. Therefore,we recommend that you compare the time taken by the top five timed events and direct the tuning effort to thebiggest consumers.


44/56



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 this table, the system is CPU bound with 75.2 percent of the processing time spent in CPU. To

drill further into the details of the CPU consumption, 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

Documents

oracle perf