| Title: | The Replication Option for Rdb |
| Notice: | Product renamed to Replication Option for Rdb |
| Moderator: | BROKE::PROTEAU |
| Created: | Wed Mar 02 1994 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 287 |
| Total number of notes: | 1231 |
I have a customer that recently purchased two ALPHA 2100's,
as part of the purchase they RCV'ed the lastest release of rdb
version 6.1, VMS version 6.1, CDD version 6.1, and DDD version 6.0.
This customer is currently migrating the application from the lagacy
VAX cluster (1-7610 and 2-6320's) running VMS 5.5-2, RDB version 6.0
CDD version 5.3 to the ALPHA. The customer has an application requirement
of 24x7, they want to evaluate DDD v6.0 to help accomplish this task.
Question??? From what I can gather from the documentation and the
notes file DDD version 6.0 will not work with RDB
version 6.1 is this true???
Question??? I have recommended that the customer create the second
database (restore from backup), then schedule only an
extraction therefore avoiding the database creation and
later index builds (post procedure) that would be needed
in an initial replication. Does this sound reasonable???
Thank you
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 210.1 | You can use DDD 6.0 with Rdb 6.1 | BROKE::PROTEAU | Jean-Claude Proteau | Mon May 13 1996 19:07 | 21 |
> Question??? From what I can gather from the documentation and the
> notes file DDD version 6.0 will not work with RDB
> version 6.1 is this true???
DDD 6.0 will work with Rdb 6.1. So far as I know, the only thing that will
fail is the IVP. And that is because the IVP contains a 6.0 Rdb database
that the IVP does not convert to 6.1 format.
> Question??? I have recommended that the customer create the second
> database (restore from backup), then schedule only an
> extraction therefore avoiding the database creation and
> later index builds (post procedure) that would be needed
> in an initial replication. Does this sound reasonable???
I assume you intend to repeat the extractions every now and then. If
there's a large volume of data to transfer, this could take a long time
each time you do this. If you don't want to recreate the target database,
when you reexecute the transfer, the old target data must first be deleted
and then retransferred. If you have indexes on those target tables,
deleting the data is going to take a long time. Normally we recommend
dropping indexes before redoing an extraction and then adding them back in.
| |||||