[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::dec_data_distributor

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

275.0. "DDAL-E-BADDBKSTO error" by ORAREP::NWD002::REID_PA (SI - Lookin' for a bigger hammer) Sun Apr 06 1997 12:16

	I'm having a problem storing a record on the target database.  The
transfer is a replication transfer with no delete.  I've validated that the
records associated with the TSER do not exist in the target database.

	System specifics:

	Source:   VMS V6.1            Target:  VMS V6.2-1H3
	          Rdb V6.0-15                  Rdb V6.1-04
		  DDD V6.0-11                  DDD V6.0-11

	I know that I can manually remove the records from rdb$changes, but
I'd rather not because there is a MODIFY transaction in rdb$changes that 
affects this record and 23 other records.  I don't feel like manually moving
these records.

	I've attached the transfer log file and the rdb$changes dump.  Let
me know if there is any other info that would be helpful.

Thanks ... Paul

p.s. I do have this call logged with Oracle.  Don Green is looking into it
     from his end, but we could both use any ideas and help!


$ SET VERIFY
$ SHOW = "SHOW"
$ RUN = "RUN"
$ LOGOUT = "LOGOUT"
$ SHOW PROCESS 

 4-APR-1997 09:30:50.13   User: SYSTEM           Process ID:   0000378C
                          Node: HQ               Process name: "DDAL_COPY_01   "

Terminal:           MBA774:
User Identifier:    [SYSTEM]
Base priority:      4
Default file spec:  SYS$SYSROOT:[SYSMGR]
$ DEFINE DDAL$CP_CONTINUE "SUCCESS"
$ DEFINE/TRANS=TERMINAL DDAL$TRANSFER_NAME HQ_MRS_DAILY_SALES_TABLE_XFER
$ DDAL$CP_ACTION :== U
$ DDAL$CP_RETRY_ITERATION == 00
$ RUN DDAL$COPY_PROCESS

Product version:	DEC Data Distributor V6.0-11

-----  4-APR-1997 09:30:50.57 ----- Process         -------------------------
Process name:  DDAL_COPY_01                  Priority:  4                       
Username:  SYSTEM                            UIC:  [SYSTEM]                     
Nodename:  HQ                                PID:  0000378C                     
Privileges currently enabled:
    CMKRNL, CMEXEC, SYSNAM, GRPNAM, ALLSPOOL, DETACH, DIAGNOSE, LOG_IO, GROUP, 
    ACNT, PRMCEB, PRMMBX, PSWAPM, ALTPRI, SETPRV, TMPMBX, WORLD, MOUNT, OPER, 
    EXQUOTA, NETMBX, VOLPRO, PHY_IO, BUGCHK, PRMGBL, SYSGBL, PFNMAP, SHMEM, 
    SYSPRV, BYPASS, SYSLCK, SHARE, UPGRADE, DOWNGRADE, GRPPRV, READALL, 
    SECURITY

Image privileges:
    SYSPRV, BYPASS, SYSLCK, SECURITY

Image name:
    HQ$DKF0:[SYS0.SYSCOMMON.][SYSEXE]DDAL$COPY_PROCESS.EXE

Transfer database = DISK$WSF_USER:[DDAL]DDAL$TR_DB
Transfer name     = HQ_MRS_DAILY_SALES_TABLE_XFER  
Transfer option   = U (Replication update transfer)

09:30:50  %DDAL-I-READTRDEF, reading the transfer definition from the transfer database
09:30:52  %DDAL-I-ATTACHSDB, attaching to source database POS_PROD:[DB]POSDB_PROD_HQ.RDB
09:33:21  %DDAL-I-ATTACHTDB, attaching to target database MRS::MRS_COMMON:[DB]MRSDB_DATABASE.RDB
09:33:21  %DDAL-I-STADATTRM, starting data transfer/modification
-----  4-APR-1997 09:44:25.66 ----- Error           -------------------------
%DDAL-E-BADDBKSTO, store to the destination database failed (relation
 "USER_SESSION" DBKEY "01A3000051B1000B")

$ @DDAL$EPILOGUE DISK$WSF_USER:[DBA.DB_TOOLS]SUBMIT_PUR_RDB$CHANGES.COM 
$ GOTO Skip_Comments
$ Skip_Comments:
$
$!  Save the return status from the DDAL$COPY_PROCESS image in DDAL$SAVE_STATUS.
$
$	DDAL$SAVE_STATUS :== %X0126839B
$	ON SEVERE_ERROR THEN GOTO Cleanup
$
$!  DEFINE DDAL$CP_CONTINUE based on the status value received from the
$!  DDAL$COPY_PROCESS image.
$!
$!  SUCCESS   = DDAL$COPY_PROCESS succeeded
$!  RETRY     = DDAL$COPY_PROCESS failed but should be retried
$!  PRO_RETRY = The prologue failed.  The transfer should be retried.
$!  PRO_FAIL  = The prologue failed.  The transfer should not be retried.
$!  FAIL      = Anything else should be a copy process failure that should not
$!		be retried.
$
$	IF DDAL$SAVE_STATUS .EQ. %X012683AB
$	ELSE
$	    IF DDAL$SAVE_STATUS .EQ. %X012683A3
$	    ELSE
$		IF DDAL$SAVE_STATUS .EQ. %X0126C44B
$		ELSE
$		    IF DDAL$SAVE_STATUS .EQ. %X0126C453
$		    ELSE
$			DEFINE DDAL$CP_CONTINUE "FAIL"
%DCL-I-SUPERSEDE, previous value of DDAL$CP_CONTINUE has been superseded
$		    ENDIF
$		ENDIF
$	    ENDIF
$	ENDIF
$
$!  Now execute the user's epilogue procedure named in the transfer definition.
$
$	@DISK$WSF_USER:[DBA.DB_TOOLS]SUBMIT_PUR_RDB$CHANGES.COM
$!++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$!
$! PROCEDURE submit_pur_rdb$changes.com
$!
$! This command file is use to submit the manual RDB$CHANGES purge job.
$! The procedure is called from the DDD replication process as an epilog
$! command process.  Basically, this procedure looks to see if another purge
$! process is executing.  If it finds it then the procedure simply exits.
$! Otherwise, it will submit the purge process and exit.
$!
$! Author:    Paul Reid   11-Mar-1997
$!
$! Modifications:
$!
$!
$!------------------------------------------------------------------------------
$    entry_number = F$GETQUI ("DISPLAY_ENTRY", "ENTRY_NUMBER", -
                              "MONITOR_PUR_RDB$CHANGES", "BATCH")
$
$    IF entry_number .GT. 0
$    ENDIF
$
$    SUBMIT /nonotify /noprint /log=POS_LOG: -
            disk$wsf_user:[dba.db_tools]monitor_pur_rdb$changes
Job MONITOR_PUR_RDB$CHANGES (queue SYS$BATCH, entry 842) started on SYS$BATCH
$    EXIT
$
$!  Reconstruct the exit status so that the transfer monitor will understand
$!  what happened.
$
$ 	RESULT :== FAIL
$
$	IF RESULT .EQS. "SUCCESS"   THEN $EXIT %X012683AB
$	IF RESULT .EQS. "FAIL"      THEN $EXIT %X0126839B
$ LOGOUT
  SYSTEM       job terminated at  4-APR-1997 09:44:28.44

  Accounting information:
  Buffered I/O count:             265         Peak working set size:  50000
  Direct I/O count:            338923         Peak page file size:   119248
  Page faults:                  75972         Mounted volumes:            0
  Charged CPU time:           0 00:07:42.17   Elapsed time:     0 00:13:38.97


************************************************************************

Start Transaction: TSER = 2936417  journal version = 2


Logical record:     type = CFT$K_STORE     length  = 81

    Relation name:  USER_SESSION
    DBK Value:      01A30000 51B1000B
    AFTER image: 
         20202020 20202035 333301CA 353B0001 ..;5�.335        0000
         238ED564 4C40009B 238ECC22 9BA02020   .."�.#..@Ld�.# 0010
         234A6FC6 C0000000 00030000 0020009B .. ........��oJ# 0020
                        00 FE4E0000 0002009B ......N�.        0030


Logical record:     type = CFT$K_END_STORE


Logical record:     type = CFT$K_STORE     length  = 81

    Relation name:  USER_SESSION
    DBK Value:      01A30000 51B1000C
    AFTER image: 
         20202020 20202035 333301CA 353E0001 ..>5�.335        0000
         2393F1E6 0520009B 2393D0D1 64602020   `d��.#.. .��.# 0010
         234A6FC6 C0000000 00030000 0020009B .. ........��oJ# 0020
                        00 FE4E0000 0002009B ......N�.        0030


Logical record:     type = CFT$K_END_STORE


Logical record:     type = CFT$K_STORE     length  = 81

    Relation name:  USER_SESSION
    DBK Value:      01A30000 51B1000D
    AFTER image: 
         20202020 20202020 373201CA 35420001 ..B5�.27         0000
         00000000 0000009B 239AF4D9 C5802020   .���.#........ 0010
         234A6FC6 C0000000 00030000 019B0000 ...........��oJ# 0020
                        08 FE4E0000 0002009B ......N�.        0030


Logical record:     type = CFT$K_END_STORE


Logical record:     type = CFT$K_STORE     length  = 81

    Relation name:  USER_SESSION
    DBK Value:      01A30000 51B20000
    AFTER image: 
         20202020 20202033 393201CA 35450001 ..E5�.293        0000
         00000000 0000009B 23A0EC59 CF802020   .�Y�.#........ 0010
         234A6FC6 C0000000 00030000 01AF0000 ..�........��oJ# 0020
                        08 FE4E0000 0002009B ......N�.        0030


Logical record:     type = CFT$K_END_STORE


Logical record:     type = CFT$K_COMMIT    Commit time:  3-APR-1997 11:26:45.50


************************************************************************
T.RTitleUserPersonal
Name		DateLines
275.1We'll be discussing this Monday morningBROKE::PROTEAUJean-Claude ProteauSun Apr 06 1997 16:4712
    Yes, I got a mail message from Don about this.  He and I will discuss
    it Monday morning (barring another blizzard).  I think we'll have to
    run debugging images to see what is going on.  We have three choices:
    (1) to put debugging software on your system to see what is happening,
    (2) to get a copy of your databases or some subset of the database
    files so that we can go after the problem in our lab, or (3) modify our
    software to get more detailed information about what is going on.
    
    (1) is usually undesireable because you are running in a production
    environment.  (2) I'll be discussing with Don and others to see what
    minimum subset of files we might need.  (3) I can't comment on without
    looking at our code to see what more we might do.