PeopleTools 8.54 Features for the Oracle DBA

PeopleTools 8.54
for the Oracle DBA
David Kurtz
Go-Faster Consultancy Ltd.
david.kurtz@go-faster.co.uk
www.go-faster.co.uk

PeopleTools 8.54 for the Oracle DBA ©2015 www.go-faster.co.uk 2
• Oracle Database Specialist
• PeopleSoft
– Independent consultant
• Performance tuning
– PeopleSoft ERP
– Oracle RDBMS
• Book
– www.psftdba.com
• Oak Table
• .
Who Am I?

Resources
• The presentation is available from
• http://www.go-faster.co.uk
• It started out as a series of blog postings
– http://blog.psftdba.com/2015/02/peopletools-85
4-for-oracle-dba.html
– http://blog.psftdba.com/search/label/PeopleTool
s 8.54

Agenda
• There is lots of new stuff in PeopleTools
8.54.
– Fluid UI
– Graphical Reporting
– Upgrade & Configuration management
– Security enhancements
• This presentation looks at support for
Oracle database performance features

Agenda
• Descending Key Indexes
• Materialised Views
• Global Temporary Tables
• Partitioning
• %SQLHint Meta-SQL
• %SelectDummyTable Meta-SQL
• Multiple Security Records
• Oracle Resource Manager
• Performance Monitor enhancements
• EnableAEMonitoring

Descending Indexes
• They have gone again!
– Originally, descending fields → descending
columns in key indexes
– PT8.14 ascending indexes due to bug in Oracle 8i
– PT8.48 descending indexes reinstated. First
version not certified below Oracle 9i
– PT8.54 only ascending indexes built. Including
user indexes.

Does it matter?
• Index leaf nodes are chained in both
directions.
– So a descending index can be used for an
ascending scan and vice versa
• Min/max range scan optimisation
– Doesn’t work with descending indexes
– Ascending index can be slightly better

Ascending Scan Descending Index
WHERE name <=‘Clark’
• Descending indexes use sys_op_descend()
Ward
Smith
Martin
Jones
Ford
Allen
Turner
King
Ward
Turner
Smith
Scott
Miller
Ford
Clark
Blake
Jones
James
Allen
Adams
Martin
King

Ascending Index Scan
Adams
King
Adams
Blake
James
King
Miller
Turner
Adams
Allen
Blake
Clark
Ford
James
Jones
Turner
Ward
Miller
Scott
Smith
King
Martin

Descending Scan Ascending Index
Adams
King
Adams
Blake
James
King
Miller
Turner
Adams
Allen
Blake
Clark
Ford
James
Jones
Turner
Ward
Miller
Scott
Smith
King
Martin
• /*+INDEX_DESC()*/ hint

Limitations of Descending
Indexes
• Implemented in Oracle as function based
indexes
– Use sys_op_descend()
• A unique function-based index cannot be
used to support a primary key.
• Some things need a primary key, not just a
unique index.

Requirements of Primary Keys
• All columns in primary key must be non-
nullable
– In PeopleSoft
• All character and numeric columns are non-nullable
• Required dates are non-nullable
• Cannot index CLOB/BLOB columns
• Only leaves non-required dates.

Non-nullable unique index
• Primary key
– PK based replication of materialised views
• (more about this later)
– Star Schema transformations
– Reference partition
• Logical standby
– Doesn’t actually need primary keys
– Does need index to uniquely identify rows.
– Otherwise generates supplementary logging

Primary Keys
• Normal unique indexes on only non-
nullable columns can support primary keys
create unique index t2 on t(b);
alter table t add constraint PK_ON_FUNC
primary key (b) using index t2;

Upgrade considerations
• Lots of descending indexes,
– mostly on EFFDT
• Suggestion
– Pave the way for the upgrade
– Set Oracle initialisation parameter to prevent
creation of descending index
• _IGNORE_DESC_IN_INDEX = TRUE

Conclusion
• Replacement of descending indexes
– should produce small improvement
• especially to effective-date/sequence sub-queries
– Opens opportunity to use other Oracle features
– Why wait for PT8.54?

Materialised Views
• Snapshots introduced in Oracle7
• Renamed Materialized Views in Oracle 8i
– Table that contains results of a query
– Hidden triggers to maintain MV logs
– Oracle supplied package
• DBMS_MVIEW to maintain them
• DBMS_REFRESH
– Incremental refresh of single table MV
• Primary Key –or- ROWID
– Complete refresh of complex MV
– Populate on creation or later

Why Materialise a View?
• Performance advantages over accessing
underlying data directly
– latency
• Reduction in I/O, mostly physical
– Different database
– Subset of rows
– Subset of columns
– Different indexing

Materialised Views in PT8.54
• PeopleSoft Documentation:
– Data Management, Using Materialized Views
• New PeopleTools tables
– PSPTMATVWDEFN
• addition definition fields for the MV, build, refresh, staleness, stats.
• Doesn't contain the query, that is in PSSQLTEXTDEFN as it is for
all other views.
– PSPTMATVWDEP
• lists tables upon which MV depends.
• PeopleSoft seems to work this out for itself by parsing the SQL
query.

Example 1: Replicate part of
JOB
• Subset of columns
• Across a database link from another
database.

JOB

MV Design – Thought required
• Refresh method
– Complete – mandatory for complex views
– Fast – single table only, probably across DB link
• Refresh mode
– On commit: could affect DML on source table
– On demand: manually issued refresh at specific
point
– Scheduled: database job

Build Script: MV doesn’t exist (1)
DROP VIEW PS_DMK
/
CREATE VIEW PS_DMK
(EMPLID, EMPL_RCD, EFFDT, EFFSEQ, SETID_DEPT,
DEPTID)
AS SELECT EMPLID , EMPL_RCD , EFFDT , EFFSEQ , SETID_DEPT ,
DEPTID
FROM PS_JOB@HROTHER
/
UPDATE PSPTMATVWDEFN
SET PTMAT_MATSTAT = 0, PTMAT_REFRESHSTAT = 0,
PTMAT_LASTREFRESH = TO_TIMESTAMP('1900-01-01-00.00.00.000000'
,'YYYY-MM-DD-HH24.MI.SS.FF'), PTMAT_STALENESS = 'STALE'
WHERE RECNAME = 'DMK'
/

Build Script: MV doesn’t exist (2)
DELETE FROM MV_CAPABILITIES_TABLE WHERE MVNAME = 'PS_DMK'
/
DROP VIEW PS_DMK
/
CREATE MATERIALIZED VIEW PS_DMK
(EMPLID, EMPL_RCD, EFFDT, EFFSEQ,
SETID_DEPT, DEPTID)
TABLESPACE PSMATVW
BUILD DEFERRED REFRESH FAST ON DEMAND
DISABLE QUERY REWRITE
AS SELECT EMPLID , EMPL_RCD , EFFDT ,
EFFSEQ , SETID_DEPT , DEPTID FROM PS_JOB@HROTHER
/
UPDATE PSPTMATVWDEFN
SET PTMAT_MATSTAT = 1, PTMAT_REFRESHSTAT = 0,
PTMAT_LASTREFRESH = TO_TIMESTAMP('1900-01-01-00.00.00.000000'
,'YYYY-MM-DD-HH24.MI.SS.FF'), PTMAT_STALENESS = 'STALE'
/

Build Script: MV exists
DROP MATERIALIZED VIEW PS_DMK
/
UPDATE PSPTMATVWDEFN SET PTMAT_MATSTAT = 0, PTMAT_REFRESHSTAT = 0, PTMAT_LASTREFRESH = TO_TIMESTAMP('1900-
01-01-00.00.00.000000','YYYY-MM-DD-HH24.MI.SS.FF'), PTMAT_STALENESS = 'STALE'
/
CREATE VIEW PS_DMK (EMPLID, EMPL_RCD, EFFDT, EFFSEQ, SETID_DEPT, DEPTID) AS
SELECT EMPLID , EMPL_RCD , EFFDT , EFFSEQ , SETID_DEPT , DEPTID FROM PS_JOB@HROTHER
/
UPDATE PSPTMATVWDEFN SET PTMAT_MATSTAT = 0, PTMAT_REFRESHSTAT = 0, PTMAT_LASTREFRESH = TO_TIMESTAMP('1900-
01-01-00.00.00.000000','YYYY-MM-DD-HH24.MI.SS.FF'), PTMAT_STALENESS = 'STALE'
/
DELETE FROM MV_CAPABILITIES_TABLE WHERE MVNAME = 'PS_DMK'
/
DROP VIEW PS_DMK
/
CREATE MATERIALIZED VIEW PS_DMK (EMPLID, EMPL_RCD, EFFDT, EFFSEQ, SETID_DEPT, DEPTID)
TABLESPACE PSMATVW BUILD IMMEDIATE REFRESH FAST ON DEMAND DISABLE QUERY REWRITE AS
SELECT EMPLID , EMPL_RCD , EFFDT , EFFSEQ , SETID_DEPT , DEPTID FROM PS_JOB@HROTHER
/
UPDATE PSPTMATVWDEFN SET PTMAT_MATSTAT = 1, PTMAT_REFRESHSTAT = 1,
(PTMAT_LASTREFRESH, PTMAT_STALENESS) = (SELECT LAST_REFRESH_DATE,
STALENESS FROM USER_MVIEWS WHERE MVIEW_NAME = 'PS_DMK') WHERE RECNAME = 'DMK'
/

Must have primary key on source
table
• Application Desigenr can only build primary key
based MVs.
• If source table doesn’t have primary
ORA-12014: table 'PS_JOB' does not contain a primary key
constraint
– Because on remote database.
– If PT 8.48-8.53 then it may have a descending index!
• You have to handle this manually
– Create materialised view log manually too.

Indexing MVs
• Cannot specify indexes

Indexing MVs
• Primary key automatically inherited on
single table MV replicated by MV
• Alternate search columns on MV not
indexed
– Must handle indexes on MV manually
• Cannot define user indexes on MV
– Might be necessary because querying MV
differently to base table.

PS_JOB locally
• Create primary key on source table
• Create materialised view log on source table
• But
– Build script repeatedly rebuilds MV log and MV
• Could be a problem for large MV
– Generated build script alternated between dropping
and building MV
• You don’t know if the build script is going to do the
right thing! – clearly a bug.

MV Log created with additional
columns
CREATE MATERIALIZED VIEW LOG
ON PS_JOB
TABLESPACE PSMATVW
WITH PRIMARY KEY
, ROWID
, SEQUENCE(DEPTID, SETID_DEPT)
INCLUDING NEW VALUES
PURGE IMMEDIATE
/

MV Log created with additional
columns
SQL> desc mlog$_ps_job
Name Null? Type
----------------------------- -------- -------------------
EFFDT DATE
EFFSEQ NUMBER
EMPLID VARCHAR2(11 CHAR)
EMPL_RCD NUMBER
DEPTID VARCHAR2(10 CHAR)
SETID_DEPT VARCHAR2(5 CHAR)
M_ROW$$ VARCHAR2(255 CHAR)
SEQUENCE$$ NUMBER
SNAPTIME$$ DATE
DMLTYPE$$ VARCHAR2(1 CHAR)
OLD_NEW$$ VARCHAR2(1 CHAR)
CHANGE_VECTOR$$ RAW(255)
XID$$ NUMBER

MVs in Application Designer are more like
Views than Tables!
• MV and MV logs always built in tablespace
PSMATVW
– I can’t find a way to control!
– I would put logs in separate tablespace to MVs
• No storage clause on Materialised View
– Cannot control space allocation in block
• Need attributes of a table as well as of a view

Example 3: MV of Security View
• PS_SJT_DEPT not added
to PSPTMATVWDEP
– Because has duplicate key
SELECT …
FROM PS_DEPT_TBL DEPT
, PSOPRDEFN OPR
WHERE EXISTS (
SELECT 'X'
FROM PS_SJT_DEPT SEC
, PS_SJT_CLASS_ALL CLS
, PS_SJT_OPR_CLS SOC
…)
OR EXISTS (
SELECT 'X'
…)
OR EXISTS (
SELECT 'X'
…)

Example 3: PK validation?
ALTER TABLE PS_SJT_DEPT ADD CONSTRAINT
PS_SJT_DEPT_PK PRIMARY KEY (SCRTY_KEY1, SCRTY_KEY2,
SCRTY_KEY3, SCRTY_TYPE_CD, SETID)
Error: DMK_DPT_SEC_MVW - SQL Error. Error Position:
39 Return: 2437 - ORA-02437: cannot validate
(SYSADM.PS_SJT_DEPT_PK) - primary key violated
• Application Designer worked out that PS_SJT_DEPT was referenced by
the MV
• But it didn’t realise that it didn’t have a unique key that could be turned
into a primary key.
• The error was produced because we did have duplicate data.
• Complex MV doesn’t need PK on source tables for complete refresh.

MV_CAPABILITIES_TABLE
• This produces error during script
generation!
EXECUTE DBMS_MVIEW.EXPLAIN_MVIEW (q'[CREATE MATERIALIZED VIEW
PS_DMK_DPT_SEC_MVW (SETID, OPRID, DEPTID, DESCR, DESCRSHORT,
SETID_LOCATION, LOCATION, MANAGER_ID, COMPANY, USE_BUDGETS,
USE_ENCUMBRANCES) TABLESPACE PSMATVW BUILD DEFERRED REFRESH
FAST ON DEMAND AS
SELECT DEPT.SETID, OPR.OPRID, DEPT.DEPTID , DEPT.DESCR , DEPT.DESCRSHORT ,
DEPT.SETID_LOCATION , DEPT.LOCATION , DEPT.MANAGER_ID , DEPT.COMPANY ,
DEPT.USE_BUDGETS , DEPT.USE_ENCUMBRANCES FROM PS_DEPT_TBL DEPT , PSOPRDEFN OPR
WHERE EXISTS ( SELECT 'X' FROM PS_SJT_DEPT SEC , PS_SJT_CLASS_ALL CLS ,
PS_SJT_OPR_CLS SOC WHERE SEC.SETID = DEPT.SETID AND SEC.DEPTID = DEPT.DEPTID AND
SEC.EFFDT_NOKEY = DEPT.EFFDT AND CLS.SCRTY_SET_CD = 'PPLJOB' AND CLS.SCRTY_TYPE_CD
= '001' AND CLS.TREE = 'Y' AND CLS.SCRTY_KEY1 = SEC.SCRTY_KEY1 AND CLS.SCRTY_KEY2
= SEC.SCRTY_KEY2 AND CLS.SCRTY_KEY3 = SEC.SCRTY_KEY3 AND SOC.OPRID

Oracle RDBMS Feature:
Query ReWrite
• If I have
– an expensive query, and
– a materialised view on the same query
• Oracle can
– Rewrite the query to use the Materialised view
• If
– The query on the MV is cheaper
– the view is up to date etc.

Example: Query ReWrite
• Current department MV
CREATE MATERIALIZED VIEW PS_DMK_PER_DEP_MVW (SETID_DEPT,
DEPTID, EFFDT, DESCR)
TABLESPACE PSMATVW BUILD IMMEDIATE REFRESH COMPLETE ON DEMAND
enable query rewrite
AS SELECT A.SETID ,A.DEPTID ,A.EFFDT ,A.DESCR FROM
PS_DEPT_TBL A
WHERE A.EFFDT= ( SELECT MAX(B.EFFDT)
FROM PS_DEPT_TBL B
WHERE A.SETID =B.SETID
AND A.DEPTID= B.DEPTID
AND B.EFFDT<=TO_DATE(TO_CHAR(SYSDATE,'YYYY-MM-DD'),'YYYY-
MM-DD'))
/

Example: Query ReWrite
• However, expressions - in this case one generated to
determine the current effective dated department - are not
supported for query write.
• This could limit your use of MVs.
=B.SETID AND A.DEPTID= B.DEPTID AND
B.EFFDT<=TO_DATE(TO_CHAR(SYSDATE
*
ERROR at line 7:
ORA-30353: expression not supported for
query rewrite

Refreshing MVs
• PeopleTools►Utilities ► Administration
►Oracle Materialized Views ►
Materialized View Maintenance

Simple MV Refresh Interval
• Then run Application Engine
PTMATREFVW

Simple MV Refresh Interval
• What this AE does is
&AlterSQL = "alter materialized view " |
&mview_name | " REFRESH NEXT SYSDATE + (" |
&MatRecords.PTMAT_REFINT.Value | "/86400)";
• What this AE does is
alter materialized view PS_DMK REFRESH NEXT
SYSDATE + (4242/86400)

Creates a database job
select rname, next_date, interval from user_refresh
/
RNAME NEXT_DATE INTERVAL
---------- --------- -------------------------
PS_DMK 24-JAN-15 SYSDATE + (4242/86400)
select name, type, rname, job, next_date, interval from user_refresh_children
/
NAME TYPE RNAME JOB NEXT_DATE INTERVAL
---------- ---------- ---------- ---------- --------- -------------------------
PS_DMK SNAPSHOT PS_DMK 21 24-JAN-15 SYSDATE + (4242/86400)
Select job, next_date, next_Sec, interval, what from dba_jobs
/
JOB NEXT_DATE NEXT_SEC INTERVAL
---------- --------- -------- -------------------------
WHAT
--------------------------------------------------
21 24-JAN-15 11:48:52 SYSDATE + (4242/86400)
dbms_refresh.refresh('"SYSADM"."PS_DMK"');

MV refresh considerations
• But I might want to
– Group related materialised views into a single refresh
group and a single transaction.
– Run refresh the job at a particular time
• Eg. 2am every morning.
TRUNC(SYSDATE-2/24)+1+2/24
– Refresh a materialised view at point in a batch schedule.
• Code refresh into an exisitng application engine
• Or have the application engine submit a job that only fires once
and does not resubmit
– might wait for refresh

My MV recommendations
• Good Things
– Removal of the descending indexes and creation of
the primary key
– Very useful to be able to specify the materialised view
query in PeopleTools.
• Easier to upgrade.
– Use of EXPLAIN_MVIEW to populate
MV_CAPABILITIES_TABLE
• but the messages are obscured and should be better
documented.

My MV recommendations
• Bad Things
– No checking for non-null unique index on source table
– MV logs are totally overblown - too much data being logged.
• Additional columns are a waste of resource.
– Can't specify indexes on materialised view in Application Designer
• Primary key will be inherited automatically on single table materialised views.
• Will have to handle that manually outside PeopleTools.
– Flip-flopping of the build script is confusing
• you will never be completely sure what you have in the database.
• Too easy to drop the materialised view
– which will also drop any indexes that you have created manually!
– Not enough control over when a materialised view is refreshed.
• Just a time interval is not good enough. You probably want better control.
– It is clearly going to be difficult getting database query rewrite to work with
complex materialised views in PeopleSoft.

My MV Conclusions
• I think some of the problems stem from
• trying to graft materialised views onto the existing view record
type,
• instead of creating a new record type and building it into
Application Designer properly.
• Possibly due to residual platform agnosticism in PeopleTools
development?
– In most system the DBAs manage MVs
• They generally resist using PSFT specific tools
• Even more so when only half the job can be done in
PeopleSoft.

Global Temporary Tables
• Application temporarily needs a working storage tables.
– Introduced in Oracle 8i. Not separately licenced.
• Global because the definition is available to everyone
• Temporary because
– physical instantiation of the table is temporary
– the physical instantiation of the table is removed
• on commit preserve : when the session disconnects
• on commit delete: when the transaction is terminated
– in the temporary segment (no redo, but there is undo),
• each session gets own private copy of the table in the temp segment.
• cannot see what is in another session's temporary table
– which can make application debugging difficult.

GTT Tablespace
• New feature in Oracle 11g
– Can create separate temporary tablespace and allocate GTTs
to it.
• Good idea – separate from default temp space which can be eaten
up by ad-hoc queries
– You must do this in PT8.54
• Oracle deliver scripts to create PSGTT01
• Specify tablespace as with any other record
• But it must be a temporary tablespace
• In 12c can have a temporary undo tablespace
– Can avoid redo logging on undo on GTT

GTT uses
• Temporary Records in AE
– Batch temporary table instances where restart disabled
• Better with stand-alone AE than PSAESRV
– All on-line temporary table instances
• Can be implemented without code change
• Reduction in
– Redo
– Read consistency
– High Water Mark – full scans
– RO contention with very frequent truncate

GTTs in PT8.54
DROP TABLE PS_ST_RM2_TAO
/
CREATE GLOBAL TEMPORARY TABLE PS_ST_RM2_TAO (PROCESS_INSTANCE
DECIMAL(10) NOT NULL,
EMPLID VARCHAR2(11) NOT NULL,
GRANT_NBR VARCHAR2(10) NOT NULL,
VEST_DT DATE,
SHARES_REMAINDER DECIMAL(21, 9) NOT NULL,
DEC_PLACES SMALLINT NOT NULL) ON COMMIT PRESERVE ROWS
TABLESPACE PSGTT01
/
CREATE UNIQUE iNDEX PS_ST_RM2_TAO ON PS_ST_RM2_TAO (PROCESS_INSTANCE,
EMPLID,
GRANT_NBR,
VEST_DT)
/

GTTs in PT8.54
• New DDL model
select * from psddlmodel where statement_Type in(6,7);
STATEMENT_TYPE PLATFORMID SIZING_SET PARMCOUNT
-------------- ---------- ---------- ----------
MODEL_STATEMENT
------------------------------------------------------------------------
6 2 0 0
CREATE GLOBAL TEMPORARY TABLE [TBNAME] ([TBCOLLIST]) ON COMMIT PRESERVE
ROWS TABLESPACE [TBSPCNAME];
7 2 0 0
CREATE [UNIQUE] INDEX [IDXNAME] ON [TBNAME] ([IDXCOLLIST]);

A small problem!
• Record name length limits
– Normal records: 15 characters
– Temporary record: 13 characters
– GTTs: 11 characters
• Because you can have 9999 non-shared instances
– Makes no sense, will never have that many processes
• So, cannot retrofit GTTs into some existing
processes
– Eg GP_GL_SEGTMP in GP_GL_PREP

My Recommendation
• GTTs are a welcome addition.
• Long overdue.
• Can bring significant benefits.
• No code change required.
• Just need to fix the 11 character limit

Partitioning
• Licenced feature of Oracle Enterprise
Addition.
• Break a table into smaller pieces
– Certain data values only occur in certain pieces
– Optimiser can eliminate partitions because it
know required data cannot be found there.

Partitioning
• From Oracle 11g Database VLDB and Partitioning Guide

Partitioning prior to 8.54
• I have to declare an interest.

Partitioning prior to 8.54
• I have been partitioning PeopleSoft since PT7.54
and Oracle 8i
• It does not invalidate your support
– (not the same as E-Business Suite!)
• I have created a utility to build partition DDL
script
– Managing Oracle Table Partitioning in PeopleSoft A
pplications with GFC_PSPART
Package
• http://www.go-faster.co.uk/gfc_pspart.manual.pdf

Has Oracle shot my fox?
• Is my partitioning utility obsolete?
• How do I retrofit existing partitioning in
PeopleTools?

Example 1: Range Partitioning
PSWORKLIST
• Range Partition PSWORKLIST
– On INSTSTATUS column
• Partition on Statuses 0 and 1
– Small – current active items
• Partition on Statuses 2 and 3
– Large – historical closed items
– Application frequently uses
WHERE INSTSTATUS<2
INSTSTATUS Description
0 Available
1 Selected
2 Worked
3 Cancelled

Partitioning Utility Component
• PeopleTools►Utilities ►Partitioning Utility

• Can only specify key columns as partition
key columns.
– Can customise PPMU_RECKEYS_VW
SELECT A.RECNAME
,A.FIELDNAME
FROM PSRECFIELDALL A /* WHERE
%DecMult(%Round(%DECDIV(A.USEEDIT,2),0 ) , 2) <>
A.USEEDIT*/
, PSDBFIELD B
WHERE A.FIELDNAME = B.FIELDNAME
AND B.FIELDTYPE IN(0,2,3,4,5,6)

• Tablespace name not mandatory
– but TABLESPACE keyword present.
• MAXVALUE partition added automatically.
• Fixed 20% free space specified
• Row Movement always enabled
• Cannot control
– Name of MAXVALUE partition
– Tablespace of MAXVALUE partition
– Physical attributes of any partition – eg PCTFREE

Partition DDL in Application
Designer
• Tools ► Data Administration ► Partitioning
• Local index DDL not valid

DDL Script problems
CREATE INDEX PSBPSWORKLIST ON PSWORKLIST (OPRID,
INSTSTATUS)
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 40960 NEXT 106496 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "PSINDEX"
/
ALTER INDEX PSBPSWORKLIST NOPARALLEL LOGGING
/
CREATE INDEX PSBWORKLIST ON PSWORKLIST
('') LOCAL TABLESPACE PTTBL
/

• Meta-data not retained
• DDL Stored in CLOB in
– PS_PTTBLPARTDDL
– PS_PTIDXPARTDDL
• Other attributes are not stored
– They were typed into a derived work record
• This isn’t going to help when I
add/split/compress/remove partitions

Not integrated into Application Designer
• Data Management Guide►Administering
Databases on Oracle►Appendix E
• "Record and index partitioning is not migrated
as part of the IDE project. If you want to migrate
the partitioning metadata along with the record,
you will need to…" copy it yourself and it goes
on to recommend creating a Data Migration
Project in the Data Migration Workbench"

Example 2: Import Existing
Partitioning
CREATE TABLE sysadm.psworklist
(busprocname VARCHAR2(30) NOT NULL
…
,descr254_mixed VARCHAR2(254) NOT NULL
)
TABLESPACE PTTBL
PCTFREE 10 PCTUSED 80
PARTITION BY RANGE(INSTSTATUS)
(PARTITION psworklist_select_open VALUES
LESS THAN ('2')
,PARTITION psworklist_worked_canc VALUES
LESS THAN (MAXVALUE) PCTFREE 1 PCTUSED 90
)
ENABLE ROW MOVEMENT
PARALLEL NOLOGGING
/
…
ALTER TABLE sysadm.psworklist LOGGING
NOPARALLEL MONITORING
/
…
CREATE INDEX sysadm.ps0psworklist ON sysadm.psworklist
(transactionid
,busprocname
,activityname
,eventname
,worklistname
,instanceid
)
TABLESPACE PSINDEX
PCTFREE 10
PARALLEL NOLOGGING
/
…
CREATE INDEX sysadm.psbpsworklist ON sysadm.psworklist
(oprid
,inststatus
)
LOCAL
(PARTITION psworklistbselect_open
,PARTITION psworklistbworked_canc PCTFREE 1
)
TABLESPACE PSINDEX
PCTFREE 10
PARALLEL NOLOGGING
/
ALTER INDEX sysadm.psbpsworklist LOGGING
/
ALTER INDEX sysadm.psbpsworklist NOPARALLEL
/
Script created by
GFC_PSPART utility

Import DDL from Oracle Catalogue

Example 3: Partitioning in
GP_RSLT_ACUM
• Main payroll result table
– I have seen systems with >1 billion rows
– Range partition on EMPLID
– Sub-partition in CAL_RUN_ID
• Partitioning utility
– Cannot specify tablespace on sub-partition
template
– So swapped partition keys

Generated DDL uses template
syntax
PARTITION BY RANGE (CAL_RUN_ID)
SUBPARTITION BY RANGE (EMPLID)
SUBPARTITION TEMPLATE
(
SUBPARTITION SUB1 VALUES LESS THAN ('K9999999999'),
SUBPARTITION SUB2 VALUES LESS THAN ('KE999999999'),
SUBPARTITION SUB3 VALUES LESS THAN ('KM999999999'),
SUBPARTITION SUB4 VALUES LESS THAN ('KT999999999') ,
SUBPARTITION PE_MAXVALUE VALUES LESS THAN (MAXVALUE)
)
(
PARTITION STRM1 VALUES LESS THAN ('K9999999999') TABLESPACE GPPART1,
PARTITION STRM2 VALUES LESS THAN ('KE999999999') TABLESPACE GPPART2,
PARTITION STRM3 VALUES LESS THAN ('KM999999999') TABLESPACE GPPART3,
PARTITION STRM4 VALUES LESS THAN ('KT999999999') TABLESPACE GPPART4,
PARTITION PE_MAXVALUE VALUES LESS THAN (MAXVALUE) TABLESPACE GPPART4
)
PCTFREE 20 ENABLE ROW MOVEMENT

Partitioning in Global Payroll
• In GP with GB extensions
– 45 similarly range partitioned tables
– 2 – 6 of which are sub partitioned
• I want define a single partitioning strategy
– Apply it to 45 tables.

My opinion
• This utility doesn’t help me manage a complex
partitioning strategy over time.
• I had expected an extension to the structured metadata
in the PeopleTools tables.
– None of the attributes that I enter are stored. They are lost
when I leave the component.
– What we have is a one time DDL generator, and then we
store the DDL
• The partitioning utility component doesn’t do much I
can’t do with a text editor

%SQLHint Meta-SQL
• Processed after all other expansions and meta-SQL
– Searches SQL string
– finds nth
occurrence of SQL keword
– Inserts a string after it
• Particularly effective with %InsertSelect() meta-
SQL.
• Advantage for Oracle’s own developers
– Platform specific hints

Prior to 8.54
• This is how to hint %InsertSelect
%InsertSelect(DISTINCT, DMK,JOB J,
EMPLID= /*+LEADING(J)*/ J.EMPLID)
FROM PS_JOB J
• This example shows why it can fail
– The hint is in the wrong place
INSERT INTO PS_DMK
(EMPLID, EMPL_RCD, EFFDT, EFFSEQ, SETID_DEPT, DEPTID)
SELECT DISTINCT /*+LEADING(J)*/ J.EMPLID, J.EMPL_RCD,
J.EFFDT, J.EFFSEQ, J.SETID_DEPT, J.DEPTID
FROM PS_JOB J
…

Contrived Example
%SqlHint(INSERT,1,'/*+APPEND*/',ORACLE,ENABLE)
%SqlHint(INSERT,1,'/*Developer Comment*/',ORACLE,DISABLE)
%SqlHint(SELECT,1,'/*+LEADING(J)*/',ORACLE)
%SqlHint(SELECT,2,'/*+UNNEST(J1)*/',ORACLE)
%SqlHint(SELECT,3,'/*+UNNEST(J2)*/',ORACLE)
%InsertSelect(DISTINCT, DMK,JOB J)
FROM PS_JOB J
WHERE %Sql(DMK_CURJOB,JOB,J,J1,J2)
SQL object that contains
EFFDT and EFFSEQ
subqueries
Insert in Direct Path Mode
Disabled Hint is a nice way to
get a comment into the code
but not the SQL
Leading hint in main query
Unnest hints into sub-query in
SQL object

Result of Contrived Example
INSERT /*+APPEND*/ INTO PS_DMK (EMPLID
, EMPL_RCD
, EFFDT
, EFFSEQ
, SETID_DEPT
, DEPTID)
SELECT /*+LEADING(J)*/ DISTINCT J.EMPLID
, J.EMPL_RCD
, J.EFFDT
, J.EFFSEQ
, J.SETID_DEPT
, J.DEPTID
FROM PS_JOB J
WHERE J.EFFDT = (
SELECT /*+UNNEST(J1)*/ MAX(J1.EFFDT)
FROM JOB J1
WHERE J1.EMPLID = J.EMPLID
AND J1.EMPL_RCD = J.EMPL_RCD
AND J1.EFFDT <= TO_DATE(TO_CHAR(SYSDATE,'YYYY-MM-DD'),'YYYY-MM-DD'))
AND J.EFFSEQ = (
SELECT /*+UNNEST(J2)*/ MAX(J2.EFFSEQ)
FROM JOB J2
WHERE J2.EMPLID = J.EMPLID
AND J2.EMPL_RCD = J.EMPL_RCD
AND J2.EFFDT = J.EFFDT)

Plan Stability in Oracle
• Oracle has various technologies to control execution
plan
– SQL Outlines
– SQL Profiles
– SQL Patches
– SQL Baselines
• Application Engine can defeat these
– Different temporary table instances
– Dynamic code
– Migration of plan stability with code changes

Conclusion
• Excellent new feature
• Simple
• Effective
• I look forward to hint the places that other
techniques cannot reach!

%SelectDummyTable Meta-SQL
• Simply evaluates to DUAL
• Dual is a convenience table that provides a
single row
– PeopleSoft often uses PS_INSTALLATION
– Dual is not a table, but a memory structure
• It doesn’t even require a logical read.
– Removes risk that PS_INSTALLATION has 0
or many rows.

Example
• Instead of (see ESPP_REF_REVMAIN.PSHUP.Do When)
%Select(IF_FLAG)
SELECT 'X'
FROM PS_INSTALLATION
WHERE %Bind(ST_SEND_SRC) = 'N'
• Code this
%Select(IF_FLAG)
SELECT 'X'
FROM %SelectDummyTable
• Which resolves to
%Select(IF_FLAG)
SELECT 'X'
FROM DUAL

Conclusion
• Small, simple improvement
• I would not change code just to get this in,
but I would use it going forward

Multiple Security Records
• This is new behaviour in PeopleTools 8.54
– that could impact database performance
• Release notes:
– “PeopleTools has added an Advanced Query Security option
to Application Designer. This feature allows up to five Query
Security Records to be associated with a single record,
including the ability to associate security with non-key fields.
– “While powerful, this feature should be used sparingly
because multiple additional joins will affect query
performance.”

• Security record joined in
query by key columns in
common
Query Security prior to PT8.54

PS/Query SQL
SELECT B.EMPLID, B.DEPTID
FROM PS_JOB B, PS_EMPLMT_SRCH_QRY B1, PS_NAMES A, PS_PERALL_SEC_QRY A1
WHERE ( B.EMPLID = B1.EMPLID
AND B.EMPL_RCD = B1.EMPL_RCD
AND B1.OPRID = 'PS'
AND A.EMPLID = A1.EMPLID
AND A1.OPRID = 'PS'
AND ( B.EFFDT =
(SELECT MAX(B_ED.EFFDT) FROM PS_JOB B_ED
WHERE B.EMPLID = B_ED.EMPLID
AND B.EMPL_RCD = B_ED.EMPL_RCD
AND B_ED.EFFDT <= SYSDATE)
AND B.EFFSEQ =
(SELECT MAX(B_ES.EFFSEQ) FROM PS_JOB B_ES
WHERE B.EMPLID = B_ES.EMPLID
AND B.EMPL_RCD = B_ES.EMPL_RCD
AND B.EFFDT = B_ES.EFFDT)
AND B.EMPLID = A.EMPLID
AND A.EFFDT =
(SELECT MAX(A_ED.EFFDT) FROM PS_NAMES A_ED
WHERE A.EMPLID = A_ED.EMPLID
AND A.NAME_TYPE = A_ED.NAME_TYPE
AND A_ED.EFFDT <= SYSDATE) ))
Join on key columns in
common
Multiple query security
records often cause
performance problems

Multiple Query Security records
• Can specify join columns
– Stored in PSRECSECFLDMAPS.

PS/Query with
multiple security records
SELECT B.EMPLID, B.DEPTID
FROM PS_JOB B, PS_EMPLMT_SRCH_QRY B1, PS_EMPLMT_SRCH_QRY B4, PS_PERALL_SEC_QRY B5, PS_PERS_SRCH_QRY B6, PS_NAMES A, PS_PERALL_SEC_QRY A1
WHERE ( B.EMPLID = B1.EMPLID
AND B1.OPRID = 'PS'
AND B.EMPLID = B4.EMPLID
AND B4.OPRID = 'PS'
AND B5.OPRID = 'PS'
AND B6.OPRID = 'PS'
AND A.EMPLID = A1.EMPLID
AND A1.OPRID = 'PS'
AND ( B.EFFDT =
(SELECT MAX(B_ED.EFFDT) FROM PS_JOB B_ED
WHERE B.EMPLID = B_ED.EMPLID
AND B.EMPL_RCD = B_ED.EMPL_RCD
AND B_ED.EFFDT <= SYSDATE)
AND B.EFFSEQ =
(SELECT MAX(B_ES.EFFSEQ) FROM PS_JOB B_ES
WHERE B.EMPLID = B_ES.EMPLID
AND B.EMPL_RCD = B_ES.EMPL_RCD
AND B.EFFDT = B_ES.EFFDT)
AND B.EMPLID = A.EMPLID
AND A.EFFDT =
(SELECT MAX(A_ED.EFFDT) FROM PS_NAMES A_ED
WHERE A.EMPLID = A_ED.EMPLID
AND A.NAME_TYPE = A_ED.NAME_TYPE
AND A_ED.EFFDT <= SYSDATE) ))
A1 & B1 are original query
security records
B4, B5 and B6 are new query
security records
EMPLMT_SRCH_QRY was
joined twice

Conclusion
• Multiple query security records can be
cause of performance problems
– Must be serious if the release notes mentions it.
– Useful if joining security on non-key field
– Otherwise I might prefer to merge security
views

Oracle Resource Manager
• Resource Manager
– Restricting sessions
– Prioritising one database session over another
• Resource Plan
– Set of rules applied to some or all sessions
– Must reflect business priorities
– Requires careful design

Oracle Resource Manager in PeopleTools
8.54

PeopleSoft Executable
→Resource Map
• At process startup lookup process on
PS_PTEXEC2RESOURCE
SELECT PT_ORA_CONSUMR_GRP
FROM PS_PT_ORA_RESOURCE
, PS_PTEXEC2RESOURCE
WHERE PT_EXECUTABLE_NAME = 'PSAPPSRV'
AND PT_ORA_CONSUMR_GRP <> ' '
AND PS_PT_ORA_RESOURCE.PT_RESOURCE_NAME = PS_PTEXEC2RESOURCE.PT_RESOURCE_NAME
PT_ORA_CONSUMR_GRP
------------------------
INTERACTIVE_GROUP
• And then explicity switch group

PS_PTEXEC2RESOURCE Mappings
• I question one or two of the mappings on
PS_PTEXEC2RESOURCE
– Which you could change
SELECT * FROM PS_PTEXEC2RESOURCE …
PT_EXECUTABLE_NAME PT_RESOURCE_NAME
-------------------------------- ------------------
…
PSAPPSRV APPLICATION SERVER
PSNVS MISCELLANEOUS
PSQED MISCELLANEOUS
PSQRYSRV QUERY SERVER
…

Oracle Resource Manager
• Explicit switch overrides any automatic
switches by session attribute.
• Cannot mix
– PeopleSoft Consumer Groups &
– Oracle Consumer Group Mappings
• Eg. By MODULE/ACTION
• Resource group for a particular component
• Would have to delete mapping from
PS_PTEXEC2RESOURCE

Consumer Group Mapping
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING
(attribute => 'MODULE_NAME'
,value => 'PROCESSMONITOR'
,consumer_group => 'SYS_GROUP');
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

Consumer Group Mapping
Priority
BEGIN
DBMS_RESOURCE_MANAGER.set_consumer_group_mapping_pri (
explicit => 1,
oracle_user => 2,
service_name => 3,
client_os_user => 4,
client_program => 5,
client_machine => 6,
module_name_action => 7,
module_name => 8,
service_module_action => 9,
service_module => 10
);
END;
/
Explicit must be priority 1

Conclusion
• A good start, but need more granularity.
• Specify consumer group by
– Specific scheduled process
– Application server domain
• Eg PIA –v- IB –v- nVision
• Eg. Back office –v- Self Service
– Useful on RAC
– Essential on Multi-tenant

Performance Monitor
enhancements
• Transaction history component search
– Multiple systems
– Multiple transaction types
• Tuxedo Queuing reported
– Fixed in 8.53?
• Improvements to Archive/Purge process
• JMX support for connection to OEM?

EnableAEMonitoring
• Application Engine Instrumentation
– Calls to DBMS_APPPLICATION_INFO
– Disabled by default from PT8.52.23 & PT8.53.13
• Performance degradation in DO LOOP processing
– New Parameter to reenable
• Oracle Bug 10130415 Latch contention on "
resmgr group change latch“
– Fixed 11.2.0.3

New Parameter in psprcs.cfg
• New Parameters to re-enable instrumentation.
– This is highly recommended
[Database
Options] ;=====================================================================
====
; Database-specific configuration
options ;=======================================================================
==
…
;DMK - added to enable DBMS_APPLICATION_INFO instrumentation
EnableAEMonitoring=1

Conclusion
• Lots of new performance/management features in
PT8.54
– Clear move away from platform agnosticism in favour
of explicit support for Oracle RDBMS features.
– Some have some rough edges
– Some require more development
• It will be a while before we see some of them
used in delivered code.
– We can start to use them now.

PeopleTools 8.54 Features for the Oracle DBA

More Related Content

Similar to PeopleTools 8.54 Features for the Oracle DBA (20)

Recently uploaded (20)

PeopleTools 8.54 Features for the Oracle DBA

Editor's Notes