[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | DBSTARS Conference |
|
| Moderator: | BROKE::BASTINE |
|
| Created: | Wed Feb 02 1994 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 791 |
| Total number of notes: | 1521 |
756.0. "-DDAL-E-SUPP, -RDMS-F-INDNOTEXI" by BROKE::BITHER () Wed Apr 02 1997 10:57
From: BROKE::BITHER "Please reply to [email protected]" 2-APR-1997 09:34:40.37
To: PROTEAU
CC: BITHER
Subj: resolved ddd issue but still one outstanding question (really 2!),thx
Hi Claude,
I had a ddd customer with a problem which we have since resolved. Just
wanted to run by you and make sure it's expected behavior. Also I had
one question about it.
Customer had 6 replication transfers that all needed to be reinitialized.
5 ran fine and one failed w/the following in the log file:
Leaf#01 BgrOnly RDB$RELATION_FIELDS Card=629
BgrNdx1 RDB$RFR_REL_NAME_FLD_ID_NDX [1:1] Fan=8
13:36:21 %DDAL-I-DELETINDX, deleting index DDAL$DBKEY_INDEX1_2
----- 1-APR-1997 13:36:22.56 ----- Error -------------------------
%DDAL-E-ERRACCDSTDB, error occurred accessing the destination database
-DDAL-E-SUPP, %RDB-E-NO_META_UPDATE, metadata update failed
-DDAL-E-SUPP, -RDMS-F-INDNOTEXI, index DDAL$DBKEY_INDEX1_2 does not exist in
this database
Turns out the customer had dropped the table in the target database BEFORE
running the reinitialization. As a consequence, the ddal$dbkey_index1_2
on the ddal$dbkey column for the table was no longer defined. I gave him
two workarounds:
1. Recreate the table in the target including the ddal$dbkey column
and recreate index ddal$dbkey_index1_2 on this column, OR
2. Drop the transfer, redefine and run it.
He tried #1 and it worked. My question is:
Is this expected behavior for a reinitialized transfer? That is, if you
are going to reinitialize, does the transfer count on the table and index
being there in order to run so it can drop it, AND where does this
index information come from? I was looking for the information in
the ddal system tables in the transfer and source db but couldn't find it.
Thanks, Diane
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 756.1 | answer | BROKE::BITHER | | Wed Apr 02 1997 10:58 | 34 |
| I will write this article later today.
From: BROKE::PROTEAU "DTN 381-2725" 2-APR-1997 09:56:21.22
To: BITHER
CC:
Subj: The owner table entries were not deleted
Diane,
Yes this is expected behavior. This is a transfer to an existing database.
When the transfer is reexecuted after a REINITIALIZE, ROR needs to delete the
data in the target tables so that it can replace the data with a new batch from
the source database. Deleting and reinserting goes much faster if you don't
have indexes to constantly update. So ROR drops indexes on the target tables.
The ROR logic could be smarter and this avoid the error your customer saw.
Very roughly the transfer is executed with these steps:
1) Drop indexes on the target tables
2) Delete data in the target tables
3) Transfer new data into the target tables
4) Recreate the indexes
ROR does not actually check the Rdb system tables to see if the indexes still
exist (nor if the tables still exist for that matter). It assumes they do.
If a customer deletes them, that's an error. ROR gets its index names in dif-
ferent ways depending on the method of transfer. For shared write transfers
(which I presume this is not) it looks up the names in a DDAL$INDEXES table.
For other transfer methods, it looks up the index name in the RDBVMS$TRANSFER_
OWNER table or the DDAL$TRANSFER_OWNER table. When the customer dropped the
index and table, s/he probably forgot do drop the entries in the owner table.
Claude
|
| 756.2 | 3 workarounds | BROKE::BITHER | | Wed Apr 02 1997 11:50 | 24 |
| So actually 3 workarounds:
For replication update transfers:
1. recreate table and index
2. drop and redefine transfer
3. when drop table - also delete columns in rdbvms$transfer_owner (Rdb)
or ddal$transfer_owner (all other dbs) tables in transfer database.
SQL> select * from RDBVMS$TRANSFER_OWNER
cont> ;
RDBVMS$TRANSFER_OWNER_ID RDBVMS$TRANSFER_OBJECT_NAME
RDBVMS$TRANSFER_OBJECT_TYPE
1 KIDS
1
1 DDAL$DBKEY_INDEX1_1
3
2 rows selected
SQL> delete from RDBVMS$TRANSFER_OWNER where RDBVMS$TRANSFER_OWNER_ID=1;
2 rows deleted
|