Reset Global Unique Identifier when cloning PeopleSoft databases

When cloning PeopleSoft databases there are a number of data values that need to be changed in the database to reflect the new database name. The most obvious is DBNAME on PS.PSDBOWNER. This maps the name of the databases, which on Oracle must also match the TNS Service Name, to the schema that contains the database.

However, a piece of data that is often forgotten is GUID on PSOPTIONS. It is documented in PeopleBooks, and is used by both the Performance Monitor and the Environmental Hub. GUID uniquely identifies a particular PeopleSoft system. PeopleSoft assigns a unique value, referred to as a GUID, to each PeopleSoft application installation. This value can't be customized.

When a Performance Monitoring agent registers with the PeopleSoft Performance Monitor, it provides this GUID. The first time the monitoring system receives information from a monitored system, it detects the GUID. For each new GUID detected, the monitoring system creates a new monitored system definition. Unless the specified monitor is changed, the new database will be monitored by the same instance of the PeopleSoft Performance Monitor that is monitoring the source database. The monitor assumes that the agents for both systems belong to the same system. Data for both systems will be mixed up, making it unreliable.

When an Environment Management agent notifies the hub that it has found a manageable component belonging to an environment, if the GUID of the environment is not recognized, the hub creates a new environment representation. Otherwise the hub will assume that the two environments are the same, leading to confusion.

To resolve these problems, set the value of the GUID field in the PSOPTIONS table to a single space in the new copy database. The next time an application server connects to the database, the system generates a new, unique GUID. You can insert the blank value in the PSOPTIONS table using the SQL tool at your site.

Use of Windows Service Dependency in PeopleSoft

If you run the PeoleSoft Application Server on Windows, there
are advantages to configuring the domains to run as services.
Processes do not run in DOS windows, where they can accidentally
be shut down. They can run with the privileges for a different NT
user. Even if you don't want services to start automatically with
server, it can simply startup scripts to simply use the NET START/STOP
command. Then you might want to define interdependencies between
the services to make sure that dependant services are started in
the right order. Service dependencies are specified by adding the
string value DependOnService to the registry key for the
service in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
(see Microsoft support note 193888).


The services that start either the application server or process schuler should be made dependent upon the BEA ProcMGR V8.1 (Tuxedo IPC Helper) service, otherwise the domain startup will fail. I have made the PeopleSoft service dependent on both the Oracle database service and the IPC process by making DependOnService a multi-string value.


The Dependencies tab of the service properties window shows which services this service depends upon, and which services depend on this service.


When the PeopleSoft service was made dependant upon the BEA ProcMgr service, the BEA ProcMgr service also reports that the PeopleSoft service depends upon it.


Now, when the PeopleSoft process is started, it will also start the BEA ProcMgr process if it is not already started. Shutting down the BEA ProcMgr service will also cause the PeopleSoft process to shutdown first.