Wednesday, July 4, 2012

Peoplesoft Functional indexes

This is for PeopleSoft experts.

I see a lot of functional indexes in my PeopleSoft database. This is due to the indexes created on date columns as DESC. Because of these functional indexes, full table scan is being preferred by the optimizer.
Is there any way to get around this problem?

Any help is appreciated.

Please leave your answer/comments.

PeopleSoft: Setting up a COBOL trace


Goal
How to set trace on for Application Engine, Cobol, without setting the trace in the Process Scheduler's psprcs.cfg configuration file.
Solution
For Application Engine programs, Open the Process Definition under PeopleTools, Process Scheduler.  Go to the Override tab, and on the Parameter list line select Append from the dropdown, and in the edit box next to it, enter the desired combination of traces, they all are;

Parameter List    Append    -TRACE 7 -TOOLSTRACEPC 4044  -TOOLSTRACESQL 31


Save the Definition and this program will be traced each time it is run, until this is removed.  Using Both the -TOOLSTRACEPC & -TOOLSTRACESQL together should only be done when required, as the output from both go into the same file, making it very large and difficult to read.  For normal program tracing using just the;

-TRACE 7 -TOOLSTRACEPC 4044


Give the Application Engine Trace, which traces the SQL in an Application Engine program, and the PeopleSoft Trace, which is the pcode trace.

The above settings have equivalent settings in psprcs.cfg, they are;

TraceAE=    -TRACE  output goes into Application Engine Trace (.AET)
TracePC=    -TOOLSTRACEPC  output goes into the PeopleTools trace file (.trc)
TraceSQL=  -TOOLSTRACESQL output ALSO goes into the PeopleTools trace file (.trc)

Again, depending on what the program is doing, most commonly use the -TRACE & -TOOLSTRACEPC together. The only time I use the -TOOLSTRACESQL is when we're looking for a problem with the psae program itself.

For COBOL the idea is similar, we won't be appending to the parameter list instead we'll be overriding it.  So first step is to open the appropriate  Process Type Definition, example;

Process Type: COBOL SQL
Operating System: NT Server
Database Type: Oracle

Copy the whole parameter list line into you mouse clipboard;

%%DBTYPE%%/%%DBNAME%%/%%OPRID%%/%%OPRPSWD%%/%%RUNCNTLID%%/%%INSTANCE%%//%%DBFLAG%%


Then open the Process Definition for the particular COBOL Process, go to the Override Tab, and on the Parameter list line, select Override from the drop down. Then in the Parameter Edit box, paste the whole parameter list from the Process Definition just retrieved;

%%DBTYPE%%/%%DBNAME%%/%%OPRID%%/%%OPRPSWD%%/%%RUNCNTLID%%/%%INSTANCE%%//%%DBFLAG%%


Notice at the end of the line after the %%INSTANCE%% and before the %%DBFLAGS%% there are 2 forward slashes //   Insert the desired bit map number inbetween the slashes.  Choose the bitmap  number desired for the trace, and put it between the slashes like so;

%%DBTYPE%%/%%DBNAME%%/%%OPRID%%/%%OPRPSWD%%/%%RUNCNTLID%%/%%INSTANCE%%/255/%%DBFLAG%%


Save the Process Definition and  launch the COBOL or AE program and Navigate to the Process Monitor, Details, Parameter List, and see the expanded command line with the trace value inserted;

Command Line: 
 PSRUN PTPDBTST ORACLE/E840D20P/VP1/%OPRPSWD%/1/475/255/%DBFLAG%  


With both the AE & Cobol traces done like this, every time the program runs it will be traced.  Need to undo all of this setting the override back to None in both Definitions will turn it off.

Wednesday, April 4, 2012

Peoplesoft Functional indexes

This is for PeopleSoft experts.

I see a lot of functional indexes in my PeopleSoft database. This is due to the indexes created on date columns as DESC. Because of these functional indexes, full table scan is being preferred by the optimizer.
Is there any way to get around this problem?

Any help is appreciated.

Please leave your answer/comments.

Monday, March 19, 2012

Load Generators

Load generators are used to simulate actual users while running the load tests. Load controller contact the load generators and sends the scripts on the load generators to simulate the vusers.

It is very important to have a few load generators to support the load. It is equally important to monitor the load generators during the performance test as it is important to monitor the IT architecture that is being load tested.

In our scenario, the load generators were running out of the Physical memory and hence, the response time was getting impacted. You can configure site scope to monitor all the load generators in load controller itself.

Watch for memory consumption on the load generators to make sure there is enough memory available for the vusers. CPU should not be a concern on these generators since there is no CPU intensive processing on these machines.

Specific question, concern or comment? Please leave a note and I would be glad to respond.

PeopleSoft: Students Transcript Report

In Campus Solutions module from PeopleSoft applications, students as well as Advisors can run the Transcript report. In our instance, the final step, 'View Report', that triggers the XML publisher was taking close to 30 seconds.

The App server log shows that 20 seconds or more out of total 30 seconds were being spent in converting the RTF template to XSL template. We removed this step by using the XSL template directly.

Results were phenomenal. Our transcript report is now completing in 10 seconds.

Specific questions/comments/concerns? Please leave a comment and I would gladly answer.

Thursday, March 1, 2012

PeopleSoft Tuxedo Trace

Ever wondered how much time each service takes within the Application Server?

Well, there is a way to get that information. Just enable the TUXEDO Service Trace for the duration of the load. Once the trace is turned off, you can use txrpt utility to get the output in a nice format summarized on an hourly basis.

I ran a load test for about 3 hours under Tuxedo Service Trace and here is what I got from txrpt.


     SERVICE SUMMARY REPORT


SVCNAME         17p-18p     18p-19p     19p-20p     20p-21p             TOTALS
                Num/Avg     Num/Avg     Num/Avg     Num/Avg             Num/Avg
--------------- --------    --------    --------    --------            -------
ICScript        2803/0.13   13708/0.14  12907/0.14  4202/0.14           33620/0.14
ICPanel         1856/2.14   12973/1.83  12511/1.76  3942/1.80           31282/1.82
HomepageT       306/0.06    1183/0.05   1082/0.05   361/0.05            2932/0.05
FileAttach      59/0.02     510/0.02    526/0.02    171/0.02            1266/0.02
PortalRegistry  636/0.03    254/0.03    8/0.02      1/0.02              899/0.03
GetCertificate  206/0.09    105/0.09    6/0.10      214/0.02            531/0.06
KeyStore        4/0.05      0/0.00      0/0.00      0/0.00              4/0.05
PpmMonSvc       4/0.14      0/0.00      0/0.00      0/0.00              4/0.14
GetWebProfile   2/0.41      0/0.00      0/0.00      0/0.00              2/0.41
--------------- -------     -------     -------     -------             -------
TOTALS          5876/0.75   28733/0.90  27040/0.88  8891/0.87           70540/0.88

As you can see clearly, ICPanel is the one taking the most time. This information can be used to assign LOAD factor to the above listed services and hence, it helps in LOAD BALANCING the queues to the application server process.

Here is how we enable the tuxedo service trace.

Default Entry in PSAPPSRV.UBX file

#
# PeopleSoft Application Server
#
PSAPPSRV        SRVGRP=APPSRV
                SRVID=1
                MIN={$PSAPPSRV\Min Instances}
                MAX={$PSAPPSRV\Max Instances}
                RQADDR="APPQ"
                REPLYQ=Y

                CLOPT="-o \"{REL_LOG}{FS}stdout\" -e \"{REL_LOG}{FS}stderr\" {$PSAPPSRV\Spawn Server} -s@psappsrv.lst -- -D {$Domain Settings\Domain ID} -S PS
APPSRV"

Modified Entry in PSAPPSRV.UBX file

#
# PeopleSoft Application Server
#
PSAPPSRV        SRVGRP=APPSRV
                SRVID=1
                MIN={$PSAPPSRV\Min Instances}
                MAX={$PSAPPSRV\Max Instances}
                RQADDR="APPQ"
                REPLYQ=Y

                CLOPT="-r -o \"{REL_LOG}{FS}stdout\" -e \"{REL_LOG}{FS}stderr\" {$PSAPPSRV\Spawn Server} -s@psappsrv.lst -- -D {$Domain Settings\Domain ID} -S PS
APPSRV"
The only addition is "-r" . This flag will turn on the tuxedo service trace and can provide a great deal of information.

Have any specific questions? Please leave a comment and I would be glad to answer that. 


Wednesday, January 11, 2012

Why is my query not using parallel slaves?

Oracle support parallel query for DML statements that include INSERT, UPDATE and DELETE statements. This is a great way to speed up these DML statements when you are trying to process those millions or records.

Not a big deal! you already knew about it. Infact, you have used parallel query on your DML statements. Have you ever been in a situation when your parallel DML that used to complete quickly enough is not completing today?????

To your surprise, it is entirely possible that your Parallel DML is not using parallel slaves because there are some restrictions for using parallel query on DML. Two of the most important ones are below

1) Triggers on the underlying tables. If the table used in your DML statement has triggers on it, it cannot use Parallel query
2) Referential integrity constraint: The underlying table, if it has referential integrity constraint, will not be able to use Parallel query.

This is true even if there is sufficient parallel slaves available for your query.

So, next time you run into this situation, you know what to check.