| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 688.1 | Expected behavior - don't try workaround | BROKE::BITHER | | Wed Jun 05 1996 15:08 | 72 |
| 688.2 | Answers | BROKE::BITHER | | Fri Jun 14 1996 14:17 | 110 |
| 688.3 | another workaround if not production | BROKE::BITHER | | Tue Feb 11 1997 15:15 | 12 |
| If just a test system and not a production system, here's an easier
workaround:
1. attach to target db
2. drop each target table
3. drop data dist tables (rdbvms$transfer_owner, rdb$vintage)
4. commit
5. attach to source db
6. stop transfer transfer_name
7. reinitialize transfer transfer_name
8. start transfer transfer_name
9. exit
|
| 688.4 | cleanest way | BROKE::BITHER | | Fri Feb 14 1997 09:31 | 15 |
| Cleanest way is to:
1. attach to target db
2. drop target table
3. drop data dist tables (rdbvms$transfer_owner, rdb$vintage)
4. commit
5. attach to source db
6. stop transfer transfer_name
7. reinitialize transfer transfer_name
8. start transfer transfer_name
9. exit
Disadvantage is that existing indexes and triggers on target tables are
gone and need to be recreated once the transfer takes place and recreates
the table.
|
| 688.5 | solution tested by customer | BROKE::BITHER | | Tue Apr 01 1997 16:39 | 56 |
| #1 below was tried by the customer and worked. Write article with
this solution only.
-------------------------------------------------------
Received: FEBRUARY 14, 1997 04:14 Sent: FEBRUARY 14, 1997 04:13
From: DBITHER.US.ORACLE.COM <DBITHER.US.ORACLE.COM>
To: [email protected]
Subject: replication option owner problem
Cc: d
Hi Ed,
Here are the 2 alternatives we currently have for you to try and
make replication option think your copy process owns the target tables.
1. Restore your test source and target databases again from a production
backup so they are in synch and we have rdb$vintage and rdbvms$transfer_owner
again in the target db. Since your transfer name is the same as what
is already in the table, the only field you should have to change is
the rdb$vintage_transfer_node to the nodename that the source database
exists on. I have no way of testing this but have discussed this
method w/engineering and this looks like it should work.
2. This method is for you to try given the state of your databases
right now. That is, rdb$vintage and rdbvms$transfer_owner no longer exist
in the transfer database. I was able to test this and got it to work.
a) Run a transfer even though it will fail.
This creates the two tables rdb$vintage and rdbvms$transfer_owner.
Additionally, it will create an entry in the rdb$vintage table
for your transfer.
b) Note the value of column rdb$vintage_transfer_id from the rdb$vintage
table.
c) drop the ddal$dbkey_index1_X index from each target table. This index
will be recreated when the transfer executes successfully.
d) For each target table:
insert a row into table rdbvms$transfer_owner with the following
column values:
rdbvms$transfer_owner_id = rdb$vintage_transfer_id
rdbvms$transfer_object_name = name of target table
rdbvms$transfer_object_type = 1
Thanks, Diane
---- End of Message ----
|
| 688.6 | Final - sent to Marilyn 4/18/97 | BROKE::BITHER | | Fri Apr 18 1997 16:43 | 76 |
| From: BROKE::BITHER "Please reply to [email protected]" 18-APR-1997 15:41:24.26
To: M5::MGULLIKS
CC: BITHER
Subj: New STARS article
TITLE: DDAL-E-TRANOTOWN Running a Replication Update Transfer
PRODUCT: Replication Option for Rdb 6.*
OP/SYS: OpenVMS VAX, OpenVMS AXP
SOURCE: Oracle Worldwide Customer Support
PROBLEM:
Running a replication update transfer results in the following error:
DDAL-E-TRANOTOWN, the transfer in progress does not own target object.
PROBLEM CAUSE ONE:
The replication transfer does not own (has not created) the table being
replicated in the target database. This situation can occur when a new
replication transfer is defined to transfer data to an already existing table
in a target database which has been defined by some other process or
application.
This is expected behavior. The first time a replication transfer runs and
each time it is reinitialized, all data in the target table is deleted and all
the data from the source table is transferred to the target table. As a
result, if replication transfers were allowed to write to existing tables not
created by them, they have the potential to delete data written by other
applications or users. This is also the reason why it is undesirable to have
local applications writing to tables owned by a replication option transfer.
SOLUTION:
The solution to this problem is to delete the target table from the
target database and let the transfer create the table when it executes.
PROBLEM CAUSE TWO:
The source and target databases have been restored from backup onto
a different system. Thus the transfer name is the same but the node
on which the transfer is run is different. The transfer owner consists of
both the transfer name and the node name on which the transfer
executes. Because the node name is different the transfer will fail.
SOLUTION:
1. You could drop the target table and reinitialize the transfer again.
This has a couple of disadvantages. First, you incur the extra overhead of
reinitializing a transfer, thus having the entire source table replicated
again. Secondly, you lose any existing indexes and triggers on the target
table.
2. If the target database is an Rdb database, then:
Modify field RDBVMS$VINTAGE_TRANSFER_NODE in table RDB$VINTAGE to contain
the new node name where RDBVMS$VINTAGE_TRANSFER_NAME is equivalent to
the transfer name.
If the target database is not an Rdb database, then:
Modify field DDAL$TRANSFER_NODE in table DDAL$TRANSFER_INFO to contain the
new node name where DDAL$TRANSFER_NAME is equivalent to the transfer name.
\
\ CONTRIBUTORS:
\
\ Technical: Diane Bither
|