I had a question the other day about getting going with PeopleSoft Performance Monitor so I thought I’d post a quick roundup/summary of the various material out there.

For those that don’t know, Performance Monitor is included with PeopleTools since PeopleTools 8.44. There’s a little bit to learn on setting it up / understanding it, but it’s a great tool and well worth learning.

Documentation.

You’ll certainly want to have the Performance Monitor PeopleBook handy while going through setting up Performance Monitor.

Presentations.

Back in April Oracle had an Oracle Advisor webcast on the setup and configuration of Performance Monitor. Here is the recording of that (Customer Connection/Metalink/My Oracle Support login required).

Lorne Kaufman of System Efficiency gave a great session at Collaborate this year about setting up Performance Monitor. Unfortunately, I can’t seem to find a link to the actual presentation anywhere. We’ll have to hassle Lorne about that.

David Kurtz of Go-Faster Consultancy has a nice selection of Performance Monitor presentations on his website. He also has a few different blog entries with tips and techniques on Performance Monitor. Those include some performance tuning tips for Performance Monitor itself which he figured out by having Performance Monitor monitor itself 🙂 He also mentions some issues that they had in a large scale environment where Performance Monitor was handling 20-30 million rows of history data each week! Good stuff.

Performance Monitor enhancements.

Brent Martin of ERP Associates has a writeup on their blog about how to get Performance Monitor to send emails when certain conditions are triggered.

Performance Monitor incidents

Here are some quick searches for Performance Monitor incidents by PeopleTools release.

• 8.49
• 8.48
• 8.47
• 8.46

Labels: 2009, Performance, Sysadmin

David Kurtz has a good tip on his weblog about how to get rid of an annoying little bug in the index management in Application Designer. David knows what annoys DBAs about PeopleSoft – he wrote the book on it(literally).

The underlying source of the problem has to do with the fact that some of the internal PeopleTools code still thinks that it is supporting some platforms that are actually not supported (Allbase!).

The problem of code cruft in PeopleTools is actually something that I’ve had in my list of blog topics to write about for awhile, but it’ll have to stay in the queue a bit longer. For now, check out David’s post for how to make Application Designer behave 🙂

Labels: Database, Performance

A common headache for DBAs managing PeopleSoft applications is not knowing which user a particular piece of SQL is being executed for. This happen because the SQL is being executed by the application server under a privileged user account and not the PeopleSoft user (who probably doesn’t even have a database login).

The DBA can go ahead and kill the connection at the database, but they can’t explain to the user what happened. Of course, the end user just sees it as a PeopleSoft error (PeopleSoft does not handle killed connections very gracefully) and they try it again. Which just annoys the DBA even further. A vicious circle indeed.

At the Mid-Atlantic RUG last week, this topic came up in a few different discussions. Some of the DBAs there weren’t familiar with the EnableDBMonitoring option for PeopleSoft application server domains.

When this is turned on (and it’s on by default in PeopleTools 8.43 and up), then each time the application server begins doing work on behalf of a different user than it was previously doing work for, it will set a variable in the database session with information on that user.

Platform Support.

• Oracle. You can see the information in the CLIENT_INFO field of the V$SESSION Oracle system view.
• SQL Server. The information is available in the context_info field of the sysprocesses system view in the master database. This is a varbinary field, so you’ll need to cast it as varchar to view the data. There is also a PeopleSoft version of the sp_who stored procedure (called sp_pswho) that will return this information. Unfortunately this stored procedure does not get installed automatically when you install PeopleSoft. You’ll need to do it manually. A script to install this can be found in appendix B of the SQL Server for PeopleSoft Performance Tuning Red Paper.
• DB2/zOS. The DISPLAY THREAD command will display the PeopleSoft user ID in addition to it’s regular information. Other DB2 platforms (Windows, Unix, Linux) do not support this command.
• Sybase. Later versions of Sybase support this feature, but I’m not sure about how to access the information in the database. I would assume that an additional column was added to the sysprocesses view (similar to SQL Server), but I don’t have access to a Sybase installation to verify that at the moment.
• Informix. Informix does not support this feature.

Labels: Database, Performance