SQL Anywhere database replication - Merging 1 remote user into the consolidated DB

Author

Merging 1 remote user into the consolidated DB

Oliver Schulze L.

2006-02-14, 3:23 am

Hi,
I have a remote user (remote db) that have some problem
with synchronization (primary key, etc)

I have had a bug in my DB. So, I want to unload all the
data from the remote user starting in some date, delete
the same data in the consolidated DB and later load the
unloaded data back into the consolidated DB.

I wonder if this can be done without touching the .log file
and not disturbing my SQL Remote setup.

Using ASA 6.0.4 here

Regards,
Oliver

Rob Waywell

2006-02-14, 9:23 am

The big effort here is in reconciling the data between the remote and the
consolidated. Once you have done that the cleanest approach is likely to
re-extract this one database.

--
-----------------------------------------------
Robert Waywell
Sybase Adaptive Server Anywhere Developer - Version 8
Sybase Certified Professional

Sybase's iAnywhere Solutions

Please respond ONLY to newsgroup

EBF's and Patches: http://downloads.sybase.com
choose SQL Anywhere Studio >> change 'time frame' to all

To Submit Bug Reports:
http://case-express.sybase.com/cx/c...sc?CASETYPE=Bug

SQL Anywhere Studio Supported Platforms and Support Status
http://my.sybase.com/detail?id=1002288

"Oliver Schulze L." <news.oliver@samera.com.py> wrote in message
news:43f1955e@forums
-1-dub...
> Hi,
> I have a remote user (remote db) that have some problem
> with synchronization (primary key, etc)
>
> I have had a bug in my DB. So, I want to unload all the
> data from the remote user starting in some date, delete
> the same data in the consolidated DB and later load the
> unloaded data back into the consolidated DB.
>
> I wonder if this can be done without touching the .log file
> and not disturbing my SQL Remote setup.
>
> Using ASA 6.0.4 here
>
> Regards,
> Oliver

Oliver Schulze L.

2006-02-14, 8:24 pm

The merging won't affect the other remote users?
Thats my main concern.

Will test a development environment and see what happend.

Thanks
Oliver

Rob Waywell wrote:
> The big effort here is in reconciling the data between the remote and the
> consolidated. Once you have done that the cleanest approach is likely to
> re-extract this one database.
>

Rob Waywell

2006-02-15, 11:23 am

How are you doing the merging?
At the end of the day, you want the data at all of the nodes to be
correct. Correct in this case usually requires human interpretation at some
point. For example you look at the remote and it has Record 1 that doesn't
exist at the Consolidated, is that because it was added at the remote and
due to the 'problem' never replicated or is it a record that was deleted at
the Consolidated and should have been deleted at the Remote? If it should
exist now, then you want it inserted at the Consolidated *and* replicated
out to any other Remote nodes that *should* have this record. In more
complex scenarios if you have had foreign key relationships mixed up then
you will have a much harder time sorting things out.

As I mentioned yesterday, my experience has been that the real challenge
is in identifying the changes that I need to make to the consolidated. After
that the existing replication logic will handle the insert/update/delete
operations that I do execute just fine.

--
-----------------------------------------------
Robert Waywell
Sybase Adaptive Server Anywhere Developer - Version 8
Sybase Certified Professional

Sybase's iAnywhere Solutions

Please respond ONLY to newsgroup

EBF's and Patches: http://downloads.sybase.com
choose SQL Anywhere Studio >> change 'time frame' to all

To Submit Bug Reports:
http://case-express.sybase.com/cx/c...sc?CASETYPE=Bug

SQL Anywhere Studio Supported Platforms and Support Status
http://my.sybase.com/detail?id=1002288

"Oliver Schulze L." <news.oliver@samera.com.py> wrote in message
news:43f28573@forums
-1-dub...[color=darkred]
> The merging won't affect the other remote users?
> Thats my main concern.
>
> Will test a development environment and see what happend.
>
> Thanks
> Oliver
>
> Rob Waywell wrote:

Oliver Schulze L.

2006-02-17, 7:24 am

I have a setup that data in every remote user is not modified by another
remote user.

So, I do this (more or less)
remote user:
- select * ... ># table1.txt

consolidated db:
- SET TEMPORARY OPTION PUBLIC.FIRE_TRIGGERS = 'OFF'
- delete * ...
- load table ... table1.txt
- dbxtract remote user

I keep all my Primary Keys pools in one table, so thats helps also.

Will post the result,
Oliver

Sponsored Links