on 11-02-2015 4:41 PM
Message from server: Message: 2601, State 2, Severity 14 -- 'Attempt to insert duplicate key row in object 'tab1' with unique index 'tab1_ix1' |
corresponding record in exception log
=============================
1> rs_helpexception 2 ,'v'
2> go
Detailed Summary of Logged Transaction # 2 on 'ServerA_rs'
Origin Site Origin User Org. Commit Date #Cmds in Xact
------------------------------ --------------- ----------------- -------------
serverA.db1 sa Nov 2 2015 5:30 3
Dest. Site Dest. User Date Logged
------------------------------ --------------- -----------------
ServerA.db2 maintuser Nov 2 2015 5:30
This transaction was skipped due to a 'resume connection' command with the 'skip transaction' option.
Rejected Records
textval
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
A0158 05iso_1distribute 1 ~";Nov 2 2015 5:30:43:013PM,2 ~"!,3 1 begin transaction ~"! npw ~"#sa osid 0
A0158 05iso_1distribute 2 ~"!,3 3 dump transaction ~!)db1 ~"620151102 17:30:43:013 0x10221d0200000000000000000000000000000032303135313130322031373a33
A0158 05iso_1distribute 1 ~";Nov 2 2015 5:30:43:013PM,2 ~"!,3 1 commit transaction
(return status = 0)
Manoj
What version of RS do yo have ?
You can use following [e]RSSD stored procedure to find all refdefs for a primary table
rs_helpreptable source_database, [owner,] table_name
But in your case --- going by the error message ---- it seems not related to any repdef.
It looks like dump transaction coammnd has gone through replication pipeline.
At your site are you using coordinated dump feature of RS ?
If not just alter the connection not to use coordinated dump
alter connection ....."dump_load" to "off"
HTH
Avinash
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Manoj
It should off on both source and target connections.
As clarified above if happened once you can skip that transaction and forget about it.
If it is happening even after setting dump_load off for the two connections then it may be time to open case/incident with SAP/Sybase folks
HTH
Avinash
Hi Manoj,
I want to take ddl of all my existing replication defination in rssd.But i do not have sybase central RSM functionality enabled to get the DDL of all repdef and subs.
Do you know any other way of getting ddl of all the exisiting repdef and subscription?
Your reply to this will be much appriciated.
Thanks.
Swapnil
If you are trying to find the repdef based on the error message in the log above. You can run the following query in the RSSD
select objname, phys_tablename from rs_objects where phys_tablename ='tab1'
go
objname will be the name of the repdef.
You can then run rs_helprep <objname> to get more details on the repdef.
regards
Terry
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Terry,
1> select * from rs_objects where objname = 'rs_in0x0100009c00000437'
2> go
prsid
objname
objid dbid objtype attributes ownertype crdate parentid ownerid rowtype
phys_tablename
deliver_as_name
phys_objowner repl_objowner has_baserepdef minvers version active_inbound attributes2
-----------
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
------------------ ----------- ------- ----------- --------- ------------------------------- ------------------ ------------------ -------
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
------------------------------ ------------------------------ ------------------ ----------- ------------------ -------------- -----------
16777372
rs_in0x0100009c00000437
0x0100009c00000443 357 R 2048 S Nov 28 2014 10:40AM 0x0000000000000000 0x0000000000000000 1
tab1l
tab1
0x0000000000000000 1260 0x0100009c00000443 0 1
attributes says " replication definition is internal only". How to drill down firther ?
Hi Manoj
What type of replication environment do you have here?
1) Is it warmstandby?
2) Is it MSA replication, by that I mean do you have a database replication definition in place?
What you are seeing here is an internal repdef and there is not much you can do with this. It would be helpful to get more details of what you are trying to accomplish overal and maybe I can assist with that.
Also could you provide the version of RS you are using. You can run the RS command
admin version
go
Regards
Terry
Hi Tarry,
Sorry for late response.
It is table level replication with publication.
Replication Server/15.7.1/EBF 21866 SP120 rs1571sp120/Linux AMD64/Linux 2.6.18-128.el5 x86_64/1/OPT64/Sun Dec 8 15:06:00 2013
Here is dump queue at target. all other command has insert statement but here I could not find.
BLOCK BEGIN q_number=360 q_type=0 blk=2704:10 cnt=3
Begin Transaction Origin User=sa Tran Name=
ENTRY ver=1100 len=224 orig=357 lorig=0 oqid=000b010081e326cd000663b70009000663b700080000a55300ff8bbe0003000000000001 lqid=2704:10:0 st=516 tr= '000b010081e3' & 'cd0009' ServerAdb1 '000001' e '00000000' comlen=83 begin transaction
ENTRY ver=1100 len=280 orig=357 lorig=0 oqid=000b010081e326cd000663b70009000663b700080000a55300ff8bbe0003000000000002 lqid=2704:10:1 st=512 tr= '000b010081e3' & 'cd0009' ServerAdb1 '000001' e '00000000' comlen=139 dump transaction db1 '20151117 15:30:25:183' 0xb067510200000000000000000000000000000032303135313131372031353a33
ENTRY ver=1100 len=204 orig=357 lorig=0 oqid=000b010081e326cd000663b70009000663b700080000a55300ff8bbe0003000000000003 lqid=2704:10:2 st=513 tr= '000b010081e3' & 'cd0009' ServerAdb1 '000001' e '00000000' comlen=63 commit transaction
Looking at the details, the transaction is "dump transaction " on source database getting replicated to target database. This happens if connection to the target has dump_load set to on. Typically used when you are using a feature called coordinated dumps. This is not governed by any repdef but by connection level setting. In my post on 2nd below I have suggested the remedy !!
HTH
Avinash
User | Count |
---|---|
93 | |
10 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.