Object Migrations
PeopleSoft Project Migrations- Best practice to
migrate PS definitions from one environment to other is to compare and
report from source to target, and then copy from source to target. There is no
requirement to copy a project to file.
The conventional way
is to copy the project definition (not items) to the target, copy the
target project to file, and then migrate the project is so that you will have a
backup to "backout" changes. The problem with this approach is that another
project can come in later with some of the same items. If you copy back in one
of those backup projects, it may overwrite the new changes and break the newest
change.
In other words, the
overlap of items within projects causes a file based backup strategy to fail. A
much safest approach is to use a change management system e.g. Quest STAT.
A project definition
is a pointer to other objects. Once you copy the project definition, the
project itself will "pick up" the definition that exist in the target
(PROD). So, when you copy the project to file from prod, if the objects exist
in prod, then you are copying the actual objects, even though your copy to prod
was just the project definition without items. If you copied the items too,
then you would overwrite the objects that exist in prod.
A copy of a project
definition copies the project name, description, attributes, etc and the names
of the items in the project. If you open that project in the target, and if the
target has items with the same name, then you will notice that the target
project actually does have contents. It is that contents that you are copying
to file.
Non-comparable
objects: Some of these are-
1.
XML Definitions,
2.
Message Catalog entries, - a message catalog cannot be migrated
using database copy.
3.
Portal Registery definitions,
4.
Roles and Tress,
5.
Cube definitions
Compare Options-
1) Compare language - select the language of definitions that
you want to compare and select COMMON- which specifies basic definition
characteristics and parameters that are not language sensitive. Clicking
'Select All' is a recommended default and if COMMON is not selected, basic
definition characteristics are omitted.
2) Comparison - select highest release that the two
database (source and target) have in common. Compare process labels definitions
as changed or *changed if these have been changed since the date and timestamp
of this release level.
3) Compare Type - Project or Database radio buttons
to select from.
4) Target Orientation -this selection determines how the Upgrade
checkbox in upgrade definition window are set for definitions that were
last modified by customer (customizations) in one database and last modified by
Oracle in other database.
4.1) PeopleSoft Vanilla - if this orientation is selected,
the upgrade checkbox will be set so as to preserve peoplesoft changes.
4.2) Keep Customization - this option lets Upgrade check
box to be set so that your customizations are preserved.
Report Options tab - Select Generate Browser reports
checkbox to generate compare reports that you can view through browser in
addition to app designer window.
Report Filer tab - use default settings appearing in
filter matrix unless you have a specific need.
Compare and Copy Process - after running a compare and report
through app designer, if Upgrade checkbox is not checked, this
object will not be copied to target. Compare process checks/clear this checkbox
however you can manually override this, i.e. you can FORCE migrate objects if
needed. However, you cannot check the Done checkbox, you can
only clear in need to re-migrate. Action field on upgrade
workspace window displays the action to be taken during the Copy process.
Only the definitions those have Upgrade selected and Done cleared(by compare
process or manually overridden) are copied to target during the upgrade
process.
Compare Report Analysis:
Definition Status -
1) unknown - default status for all non-comparable definitions.
2) absent - definitions found in one database and absent in other.
i.e. during an upgrade, the new PPLSOFT definitions must have Absent in target
and all the customizations will be Absent in source ( as source will be a copy
of new release and target will be a recent copy of prod) during an upgrade.
3) changed - peoplesoft modified since
the comparison release. LASTUPDOPRID=PPLSOFT, LASTUPDDTTM >
comparison release DTTM.
4) unchanged - peoplesoft modified prior to comparison
release. LASTUPDOPRID=PPLSOFT, LASTUPDDTTM <= comparison release DTTM.
5) *changed - customer modified since comparison
release. LASTUPDOPRID=cust, LASTUPDDTTM > comparison release DTTM.
6) *unchanged - customer modified prior to
comparison release. LASTUPDOPRID=cust, LASTUPDDTTM <= comparison release
DTTM.
7) same - same defined in both source and target. you will see
same-same after a successful migration.
Unchanged *
changed - Keep target i.e. do not copy
Absent *changed -
Keep target i.e. do not copy
Changed * changed -
Copy and Reapply customization
Important - if the pair shows as Any
*unchanged - raise a flag.
Migrating Roles & Permission Lists - when migrating
Permission Lists containing menu/component/page permissions from source
database to target, make sure that -
1) the
menu/component/page definition(s), already exists in target database or
2) these all
definitions are in same project as permission list
This will ensure a
successful migration of the menu/component authorizations to be stored in
PSAUTHITEM's row for the permission list being migrated. If above
requirements are not satisfied, the permission list will be partially migrated
and the required PSAUTHITEM rows will not be present in target database. In app
designer, you would see any errors rather permission list will appear to be
successfully migrated.
It is recommended to
run Portal Security Sync after migrating a project containing a
permission list.
ALTER in Place & ALTER by Table Rename - these are two
important build options which determine the build process. These have system
performance implications so need to be chosen carefully.
Alter by Table
Rename - when selected, the build process creates a temporary table as
per current definition(changes made to the original table and/or its fields).
The data from the original table is now imported into this temporary table. The
original table is then dropped and the temporary table is renamed to the
original table. The indexes on the old
table are dropped before being renamed to the new table name and the indexes
are re-created after the table is renamed to the new name.
Alter Table in Place- For this option, the index creation
process goes through the Recreated index only if modified option on the Create
tab. Thus it does not always recreate indexes if there where no changes
to the key structure. The alter place is only a good option to choose if the table
you are creating has large amounts of data and there is no change to the key
structure in App Desinger.
Performance tip-
For an Oracle database, monitor index usage by issuing
- ALTER INDEX MONITORING USAGE;
and drop index which are not being used. ALTER INDEX ... REBUILD is
faster than dropping and re-creating an index. The statement reorganize or
compact an existing index or changes its storage characteristics. This
statement uses the fast full scan feature. It reads all the index blocks using
multiblock I/O, then discards the branch blocks. A further advantage of this
approach is that the old index is still available for queries while the rebuild
is in progress.
Migrating SQRs
