topic Re: Compress issue - in replica environment in Data Management Questions

Compress issue - in replica environment

AntonyPaul_M1 — Mon, 26 Nov 2012 06:11:50 GMT

Hi All,

I am having one way replication enabled towards the site. We were faced few hick ups in synchronisation and now all sorted out and the synch working fine for the last two weeks. The issue currently have is the compress is not clearing the delta tables which is happening after each synch.

select id,name from sde.gdb_replicas;

        ID NAME
---------- --------------------------------
         6 IO_ANT
        11 IOENVIRON

In that 11 IOENVIRON is working ok. IO_ANT is having heaps version still exist. I have queried to check whether any orphan version exist that preventing from clearing the delta tables. There are no orphan version exist

SQL> select name from versions order by name;

05_07_10
AB_Nov_VMI
AF_Edits
Agha_edit
DD_Edits
DEFAULT
SYNC_SEND_11_93
SYNC_SEND_6_29
SYNC_SEND_6_30
SYNC_SEND_6_31
SYNC_SEND_6_32
SYNC_SEND_6_33
SYNC_SEND_6_34
SYNC_SEND_6_35
SYNC_SEND_6_36
SYNC_SEND_6_37
SYNC_SEND_6_38
SYNC_SEND_6_39
SYNC_SEND_6_40
SYNC_SEND_6_41
SYNC_SEND_6_42
SYNC_SEND_6_43
SYNC_SEND_6_44
SYNC_SEND_6_45
SYNC_SEND_6_46
SYNC_SEND_6_47
SYNC_SEND_6_48
SYNC_SEND_6_49
SYNC_SEND_6_50
SYNC_SEND_6_51
SYNC_SEND_6_52
SYNC_SEND_6_53
SYNC_SEND_6_54
SYNC_SEND_6_55
SYNC_SEND_6_56
SYNC_SEND_6_57
SYNC_SEND_6_58
SYNC_SEND_6_59
SYNC_SEND_6_60
SYNC_SEND_6_61
SYNC_SEND_6_62
SYNC_SEND_6_63
SYNC_SEND_6_64
SYNC_SEND_6_65
SYNC_SEND_6_66
SYNC_SEND_6_67
SYNC_SEND_6_68
SYNC_SEND_6_69
SYNC_SEND_6_70
SYNC_SEND_6_71
SYNC_SEND_6_72
SYNC_SEND_6_73

SYNC_SEND_6_29 - if you look above query the issue starting from this version onwards this version date is two months ago which I doubt created when we were facing synch failiure, from here onwards it is keeping all versions till today. Which accumulating the delta layers.
SYNC_SEND_6_73 is todays version and 73 is the replica state.
Is there any way to get rid of the version staring from SYNC_SEND_6_29 to SYNC_SEND_6_72 so that I can perform a compress and get cleared my delta tables. At the moment I am facing serious performance issuses while rendering the layers.

Your help is really appreciated

Cheers
Antony

Re: Compress issue - in replica environment

LeoDonahue — Mon, 26 Nov 2012 12:34:42 GMT

Did you reconcile and post from the correct child versions to the parent versions?

I've seen this happen before when we create versions owned by the wrong user, then try to reconcile and post to the wrong parent and synchronize changes.

In our environment (sde schema):
We have a "data owner account" that does nothing but load data into the geodatabase. No other users own any featureclasses.
Our "sde" account owns the versions on our production geodatabase.
Our "sde" account also owns the replicas on our production geodatabase, and we replicate (one way) to a "data owner" account on the publication database.

I suppose a painful solution to this would be to reconcile/post, un-register layers as versioned and delete the versions and replicas and start over. Maybe someone else has a better solution.

Re: Compress issue - in replica environment

HeatherMcCracken — Mon, 26 Nov 2012 14:43:16 GMT

Replication will leave the "sync_send_" versions around until the relative replica has acknowledged getting the changes.

Question - are you syncing via delta files? ie. exporting changes to a delta XML or a delta geodatabase, and then importing those changes on the target?

If yes - then what you need to do is Export an Acknowledgement message from the relative replica. Then, import that acknowledgement to the sender (the geodatabase whose versions you list below).

Also - we have a white paper that talks about replication and compression - how to achieve the most effective compress with replicas on your system. This will give you guidance as well.

http://support.esri.com/en/knowledgebase/whitepapers/view/productid/19/metaid/1603

Let me know how this goes.
Thanks,
Heather

Re: Compress issue - in replica environment

AntonyPaul_M1 — Tue, 27 Nov 2012 07:01:53 GMT

Hi Heather,

We are running the synch through python scripts as batch file and scheduled it on a daily basis.

I got a hint from the old forum thread regarding the acknowledgment message from child replica and one of them suggesting to do a manual synch via catalog even if there is no edits. I did the same and then I could see all the synch versions which listed previously removed from the version list and did a compress that get rid of my 70% delta entries.

Is there any way to ensure the acknowledgment mesage from child replica in python script itself?

Is there any better way to do the synch rather than pyhton script? I must do it on daily basis after business hours so it is not posible for me to do manual synch.

Please advice..

Thanks
Antony

Re: Compress issue - in replica environment

HeatherMcCracken — Tue, 27 Nov 2012 15:11:08 GMT

Hi Antony,

Python is a great way to automate replication workflows (any workflow really) - you can schedule them to run at whatever interval using the windows scheduler which sounds like exactly what you need.

http://resources.arcgis.com/en/help/main/10.1/#/ListReplicas/018w00000003000000/
http://resources.arcgis.com/en/help/main/10.1/#/Replica/018w00000013000000/

Take a look at the help topic above. The Data Access module in python lets you get a list of replicas from a workspace - and then via the replica class, specific information about a replica. The "lastReceive" will give you the dateTime that a message was last receieved from the relative replica (either an acknowledgement, or data changes (which implicitly acknowledges as well). You can compare that value to the "lastSend" to see the discrepancy. In ArcObjects - you are able to check the generation numbers... which are numbers that track which changes have been sent and receieved. But as those aren't available in python - the lastSend/lastReceive will help you.

-Heather