Conference orarep::nomahs::dec_data_distributor

    
    I suggest you try an experiment to determine if the problem involves
    Data Distributor or if the problem occurs without it.
    
    You already have the target database, MRD_DEV on the remote system,
    IB001.  Table GEARS_96 exists and has 1946033 rows of data in it.
    
    The error occurred while Data Distributor was trying to add a unique
    index on GEARS_96(DDAL$DBKEY).  I'd like you to try to create such an
    index by using interactive SQL rather than Data Distributor.  Log into
    your local system, attach to the remote MRD_DEV database on IB001 using
    the proxy account NEAR_ADM.  Try creating the index remotely, just as
    Data Distributor did.  If you get an "exceeded quota" error, it means
    that the problem is between you and Rdb and that Data Distributor is
    not really the issue.
    
    Claude

   Claude,



      We'll check what you suggest in .1 tomorrow or during this weekend,
   because we've already deleted the GEARS_96 table in the remote database
   and we're loading it using two transfers (one million records for each),
   when we've checked thhis, we'll put here the resoults.


   Thank you very much indeed for your quick response.

   Regards,


   Marta

    
    Marta,
    
    How are you loading the one target table, GEARS_96, using two
    transfers?  You couldn't actually have tried to do this because it
    won't work using replication transfers.  I'll explain why not if you ask.
    
    Why are you trying to load the one table using two transfers?  Are
    you trying to get around some quota or performance problem?
    
    Claude

If I had to guess, I would say that the remote server process was running 
out of PGFLQUO or ENQLM. These are typicaly the most common causes of 
EXQUOTA errors.

Cheers,

Mark.

   Claude,


     You're absolutely right, we can't use two replication transfers to load
   the table.

	Neverthless we've done what you mentioned in .1, we've redefined
   a replication transfer to load the GEARS_96 table and we've got the same
   error when the DDAL tried to create the index, so we've tried to create
   it from the local machine and we've got no problems, so it seems to be 
   DDAL and no RDB. So now we've got the table and the index in the target 
   database, but 

	- what could happen if we start the transfer once again?(as it finished
	  with an error status); 

	- would it begin from the beginning or would it only try to transfer 
	  the updated records (the normal behavior in replication transfers)?

	- if the transfer begins from the beginning, is there any workaround
	  so that the next time it starts it only transfers the updated rows?
	  could we change something in the local and/or remote databases?
	  or in the DDAL database ?


    Awaiting for your comments, and thanks a lot for your help.


   Regards,


     Marta 

Marta,

I need some clarification to be sure I correctly understand your comments.

>	Neverthless we've done what you mentioned in .1, we've redefined
>   a replication transfer to load the GEARS_96 table and we've got the same
>   error when the DDAL tried to create the index, so we've tried to create
>   it from the local machine and we've got no problems, so it seems to be 

When you say, "we've tried to create it from the local machine," do you mean
that you did a remote index creation and that worked alright?  That is, the
local machine is the one on which Data Distributor is installed and the remote
machine is the one with the target database.  You used the same attach string
and remote account to get to the target database via SQL, right?

>   DDAL and no RDB. So now we've got the table and the index in the target 
>   database, but
>
>	- what could happen if we start the transfer once again?(as it finished
>	  with an error status); 

The transfer will try to do the same thing over again.  That is, because it
remembers that the transfer failed, it will drop the target indexes, delete
the data in the target tables, retransfer the data, and try to create the
indexes.  Therefore it will fail again.

>	- would it begin from the beginning or would it only try to transfer 
>	  the updated records (the normal behavior in replication transfers)?

From the beginning.  Data Distributor has no way of knowing that you corrected
the problem manually.

>	- if the transfer begins from the beginning, is there any workaround
>	  so that the next time it starts it only transfers the updated rows?
>	  could we change something in the local and/or remote databases?
>	  or in the DDAL database ?

Hm, maybe you could change the status code in the transfer database so that it
thinks the transfer succeeded.  The information is in the following table and
columns: DDAL$TRANSFERS_STATUS(DDAL$TRANSFER_NAME, DDAL$TRANSFER_STATE,
DDAL$LAST_COMPLETION_STATUS, DDAL$LAST_TRANSFER_TIME).  For the given transfer,
you'll probably see a state value of 4, meaning suspended.  Change that to 5,
unscheduled.  The last_transfer_time will probably have a value of 0 (or null).
Store some non-0 datetime value in that column.  Data Distributor uses that
to determine that the initial replication transfer has been done and that the
next time the transfger is run it should do a replication update.  I'm not
sure if the last_completion_status column needs to be changed.  I believe it
contains a VMS status code, one of the codes from the DDAL$MESSAGE.EXE file.
If you can check the value in this column for some other transfer that was
successful, put that same value in this column for the transfer you're trying to
get to work.

I don't guarantee that this will all work because I haven't tried it, but this
will probably get you by.
    
    Claude

  Claude,


     Thank you very much for your help, we haven't checked the workaround
  you suggestted us yet, as we've changed our minds and perhaps we don't need 
  to transfer the whole table. But in case we have to transfer it, we'll check 
  it and send you the resoults.

  Once again, thank you very much for your help

  Regards,


     Marta.

   Claude,


     We've modify the DDAL$TRANSFER_STATUS relation in the DDAL database, as
   you mentioned in your last reply, the we've start once again the replica-
   tion transfer, and it has worked (it has run as un update replication trans-
   fer and not an initial one).

   Thank you very much indeed for all your help.

   Best regards,


      Marta.

    
    Marta,
    
    You're welcome.  I'm glad that it worked out well for you.
    
    Claude