Example 1: Ongoing migration with adjusted ranges
For this example, assume that you are a DBA for a nation-wide travel agency. The president of the agency wants to monitor data concerning the number of customers receiving frequent-flyer discounts. He wants to search for data by a different index, and he wants to check the data on a daily basis.
You decide to set up a decision-support database to track and report on customers receiving frequent-flyer discounts. You create a set of shadow tables and populate them with data from the production database. The production database and the decision-support database have the same primary index with differing secondary indexes. You define a log mark at a quiesce of the table spaces involved.
The following figure shows the overall process of migrating the data with an ongoing job:
You can run the ongoing job repeatedly, without changing the syntax. Notice how BMC AMI Log Master tracks the open transactions at the end of a run, and adjusts the scan range to include those transactions in the next run. BMC AMI Log Master does not reprocess any transactions that were completed during a previous run, even though it might scan part of the same log range again.
Following table provides a high-level task list for this example.
Task | References |
|---|---|
Create the decision-support database. | |
Define a filter that selects specific table space transactions. | |
Define a time frame that starts from the same point of consistency used by BMC AMI Recover, and ends at the current time. |
|
Define the time frame as an Ongoing Process. | |
Modify the output options for the default Summary report and SQL file (as needed). | |
Save your selections in a work ID. | |
Generate JCL and save it for batch submittal. |
This section contains the following topics: