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-
- XML Definitions,
- Message Catalog entries, - a message catalog cannot be migrated using database copy.
- Portal Registery definitions,
- Roles and Tress,
- 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
Change Management & Object Locking
Change Management & Object Locking
Posts
No comments:
Post a Comment