RDF System Management Manual for H-Series and J-Series RVUs (RDF 1.9)

table with all its partitions onto disk on the backup system. You must use MAP NAMES to
correct the system name. Thus, $DATA.DUP.PART is now on the backup system.
If you created the duplicate table directly on the backup system, skip this step.
8. Rename the original table on the backup system whose primary partition is being
synchronized to a temporary name using the SQLCI ALTER TABLE command
($DATA.TEST.PART becomes $DATA.TEMP.PART).
9. Rename the duplicate table on the backup system to the name of the original table whose
partition is being synchronized using the SQLCI ALTER TABLE command
($DATA.DUP.PART becomes $DATA.TEST.PART).
10. Use the BACKUP utility with the PARTONLY option to back up just the partition you need
synchronized to tape (the primary partition, in this example). Remember that the duplicate
table now has the name of the original table. When this step completes, you now have on
tape just the partition that you want to use on the backup system and it now has the correct
name, although it is not yet aligned with the other partitions of the table on the backup
system.
11. Rename the duplicate table back to its original duplicate table name ($DATA. TEST.PART
becomes $DATA.DUP.PART).
12. Use SQLCI to drop the duplicate table. By renaming the duplicate table back to its original
name before dropping it, you can preserve whatever indexes exist on the backup system
that are associated with the table being synchronized.
13. Rename the original table on the backup system from its temporary name back to its original
name using the SQLCI ALTER TABLE command ($DATA. TEMP.PART becomes
$DATA.TEST.PART).
14. Use the RESTORE utility with the PARTONLY option to put the loaded primary partition
of the duplicate table into the correct location. MAP NAMES is not required because the
loaded partition now has the correct name on tape and can be restored directly.
15. When the extractor has logged the message indicating it has completed its role in the online
synchronization operation, issue the RDFCOM START UPDATE command on your primary
system.
The preceding procedure preserves indexes you might have on the backup system.
There is an alternate method that might be faster in some situations than the method described
above, although this method requires that you rebuild all indexes associated with the table on
the backup system.
1. Drop all indexes associated with the table on the backup system that has a partition in need
of synchronization.
2. Use the SQLCI LOAD command with the PARTONLY option to load the partition directly
from the primary system to the backup system (without having to create a duplicate table).
3. When the load has completed, issue the RDFCOM STOP SYNCH command.
4. Create all required indexes for the table on the backup system.
5. When the extractor has logged the message indicating it has completed its role in the online
synchronization operation, issue the RDFCOM START UPDATE command on your primary
system.
Thus, if it is faster for you to rebuild your indexes than to perform the main method above, then
this alternative method can achieve synchronization more quickly for you.
Relative Tables
This method is the same as that described for key-sequenced tables above, except that you cannot
use PARTONLY to load relative tables. For relative tables, you must load the entire table.
1. If RDF is currently running, issue a STOP RDF command on the primary system.
Synchronizing Selected Database Portions Online 181