|
Synchronization and recovery overview. |
|
|
Synchronization report and implementation steps. |
|
|
Backing file recovery when there are decreases in PRT configuration components. |
Synchronization and recovery overview
The PRT Collector manages discrepancies or corruption in the PRT backing files as follows.
Synchronize data
When the project is not running a user can have the PRT Collector synchronization PRT and TADB.
During synchronization PRT data overwrites TADB data.
Note: Any items in TADB that are assigned to regions in TADB, but are not in PRT are deleted. PRT values overwrite TADB values.
Recover data
When a project starts PRT Collector validates the data between PRT backing files and TADB.
If PRT backing files are corrupt the PRT Collector will:
Delete the corrupt backing files.
Create new blank backing files.
Query the TADB database for the data needed to recover the backing files.
Recover the data from the database.
Synchronization report and implementation steps
|
Open the Synchronization Report window. |
|
|
Create a new PRT vs. TADB Validation Report. |
|
|
Review and copy report data. |
|
|
Synchronize PRT backing files and TADB. |
Backing File Recovery when there are Decreases in PRT Configuration Components
When the PRT configuration changes after items have been logged to the database involve reductions, e.g. fewer regions, fewer locations, fewer items in a location, recovery attempts to:
Maintain the item
sequence.
Maintain item
associations.
When warranted, move items to the
next location or region.
Report all changes and issues in
the Status Log.
The following examples portray two possible situations.
Example 1
REGION1's capacity initially is 200.
The capacity is reduced to 150.
Recovering items from the database starts at Location 1.
Items are recovered from 1-150.
At 150, the revised capacity is full; there is no more room for items.
Item 151 is not recovered.
An initial warning and failure are logged to the status log that:
Item count %d
<200> exceeds Item capacity
%d<150> for region
<REGION1>.
Location %d<151> for Item %s<widgets> exceeds
region <REGION1> locations
%d<150>.
Reports about all items over 151 are also logged to the Status Log.
Note: The recovery maintains the initial integrity of items/location. If the location allows 2 items and only 1 item is in the location at the time of recovery, the location will continue to have only 1 item.
Example 2
The location capacity in REGION1 is initially is 3 items.
The capacity is reduced to 2 items.
If the database contains 3 items in a location recovery will attempt to fulfill three requirements.
Maintain the item
sequence.
Maintain item
associations.
Reduce the number of items
in the location to 2 or 1.
The recovery starts with the first item in the location.
The following table displays how database items in locations that previously allowed 3 items are allocated during recovery.
|
Location |
Database Items |
Recovered Items |
|
1 |
1A, 1B, 1C |
1A, 1B |
|
2 |
2A, 2B, 2C |
1C |
|
3 |
3A, 3B, 3C |
2A, 2B |
|
4 |
4A, 4B |
2C |
|
5 |
5A, 5B, 5C |
3A, 3B |
|
6 |
6A, 6B |
3C |
For each instance that an item is
re-assigned to the next location a report is logged in the Status
Log.
Adjusted %s<1C> location from %d<1> to %d<2> during recovery. Updating TADB to match.
For each instance that there is an
attempt to re-assign an item and the region/location capacity is
exceeded, a report is logged in the Status Log.
Adjusted location %d<7> from %d<4> for %s<4A> exceeds %s<REGION1> %d<6> locations.
Note: If an unforeseen error occurs while
recovering an item from the TADB, the following message is logged
to the status log.
Failed recovery %s to %s at adjusted location %d, %d orig.
Where the message components are:
Failure to recover <item> to <region> at adjusted location <attempted location>, <database location>.
|
|
TADB overview. |
