Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

refresh a replication target from a live source

8 posts in ,  General Discussion General Discussion Last posting was on 2010-01-07 10:52:35.0Z
Axel Posted on 2009-12-30 01:44:39.0Z
From: "Axel" <tester@tester.cc>
Newsgroups: sybase.public.ase.general,sybase.public.rep-server
Subject: refresh a replication target from a live source
Date: Tue, 29 Dec 2009 17:44:39 -0800
Organization: Netfront http://www.netfront.net/
Lines: 15
Message-ID: <hheba7$f6g$1@adenine.netfront.net>
NNTP-Posting-Host: 208.86.39.175
X-Trace: adenine.netfront.net 1262137480 15568 208.86.39.175 (30 Dec 2009 01:44:40 GMT)
X-Complaints-To: news@netfront.net
NNTP-Posting-Date: Wed, 30 Dec 2009 01:44:40 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5843
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Path: forums-1-dub!forums-master!newssvr.sybase.com!news-sj-1.sprintlink.net!news-peer1.sprintlink.net!nntp1.phx1.gblx.net!nntp.gblx.net!nntp.gblx.net!border2.nntp.dca.giganews.com!nntp.giganews.com!newsgate.cuhk.edu.hk!news.netfront.net!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:28807 sybase.public.rep-server:8537
Article PK: 78050

It appears that if DSI is suspended on target, dump/load are performed, and
DSI is restored, duplicate inserts start coming in from the target. So it
looks like the new records created during the dump make it into the dump
file and then show up in the target, because (as I presume) the rep agent on
source collected these in parallel and the rep.server subsequently stored
them in the outbound queue.

Does anyone know a proper procedure for cloning a replica from a live
database (with autocorrection off)?
So that no transactions are lost, and at the same time there is no overlap
as well?



--- news://freenews.netfront.net/ - complaints: news@netfront.net ---


Vivek Kak Posted on 2009-12-30 08:18:18.0Z
Sender: 63d0.4b3b0702.1804289383@sybase.com
From: Vivek Kak
Newsgroups: sybase.public.ase.general
Subject: Re: refresh a replication target from a live source
X-Mailer: WebNews to Mail Gateway v1.1t
Message-ID: <4b3b0cca.6469.1681692777@sybase.com>
References: <hheba7$f6g$1@adenine.netfront.net>
NNTP-Posting-Host: 10.22.241.41
X-Original-NNTP-Posting-Host: 10.22.241.41
Date: 30 Dec 2009 00:18:18 -0800
X-Trace: forums-1-dub 1262161098 10.22.241.41 (30 Dec 2009 00:18:18 -0800)
X-Original-Trace: 30 Dec 2009 00:18:18 -0800, 10.22.241.41
Lines: 38
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:28808
Article PK: 78049

If you are using warm standby and you cannot arrange
downtime till refresh at replicate is done, use below steps:
1.Drop the physical connection to standby database.
2.Disable all dump jobs on primary database
3.Create physical connection to standby database with "use
dump marker "
4.dump database at primary site
5. Load the database dump at standby
6.Resume all threads and ensure replication is up and
running.


In case you are using table level replication and you want
to refresh the replicate with the primary dump, the best way
is to arrange the downtime with application folks till the
time you dump primary and load it at replicate.

HTH,
Vivek

> It appears that if DSI is suspended on target, dump/load
> are performed, and DSI is restored, duplicate inserts
> start coming in from the target. So it looks like the new
> records created during the dump make it into the dump
> file and then show up in the target, because (as I
> presume) the rep agent on source collected these in
> parallel and the rep.server subsequently stored them in
> the outbound queue.
>
> Does anyone know a proper procedure for cloning a replica
> from a live database (with autocorrection off)?
> So that no transactions are lost, and at the same time
> there is no overlap as well?
>
>
>
> --- news://freenews.netfront.net/ - complaints:
> news@netfront.net ---


mpeppler@peppler.org [Team Sybase] Posted on 2009-12-30 12:37:11.0Z
From: "mpeppler@peppler.org [Team Sybase]" <michael.peppler@gmail.com>
Newsgroups: sybase.public.ase.general,sybase.public.rep-server
Subject: Re: refresh a replication target from a live source
Date: Wed, 30 Dec 2009 04:37:11 -0800 (PST)
Organization: http://groups.google.com
Lines: 29
Message-ID: <c8ed1896-9791-4f0d-9e92-5afb232dfb38@v25g2000yqk.googlegroups.com>
References: <hheba7$f6g$1@adenine.netfront.net>
NNTP-Posting-Host: 78.155.28.124
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1262176631 8988 127.0.0.1 (30 Dec 2009 12:37:11 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Wed, 30 Dec 2009 12:37:11 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: v25g2000yqk.googlegroups.com; posting-host=78.155.28.124; posting-account=9rHMzAoAAADtzToS8d2WKVGlkISAvPdk
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1,gzip(gfe),gzip(gfe)
Path: forums-1-dub!forums-master!newssvr.sybase.com!news-sj-1.sprintlink.net!news-peer1.sprintlink.net!nntp1.phx1.gblx.net!nntp.gblx.net!nntp.gblx.net!border2.nntp.dca.giganews.com!nntp.giganews.com!postnews.google.com!v25g2000yqk.googlegroups.com!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:28810 sybase.public.rep-server:8539
Article PK: 78057


On Dec 30, 2:44 am, "Axel" <tes...@tester.cc> wrote:
> It appears that if DSI is suspended on target, dump/load are performed, and
> DSI is restored, duplicate inserts start coming in from the target. So it
> looks like the new records created during the dump make it into the dump
> file and then show up in the target, because (as I presume) the rep agent on
> source collected these in parallel and the rep.server subsequently stored
> them in the outbound queue.
>
> Does anyone know a proper procedure for cloning a replica from a live
> database (with autocorrection off)?
> So that no transactions are lost, and at the same time there is no overlap
> as well?
>
> --- news://freenews.netfront.net/ - complaints: n...@netfront.net ---

This should probably go in the replication group.

However - what sort of replication are you using (i.e. is it warm
standby, MSA, or table level?)
If it is warm standby or MSA you can tell rep server to only start
distribution when it sees the dump marker. For MSA it's in the
subscription definition, if I recall correctly.

Michael


Axel Posted on 2009-12-30 18:11:20.0Z
From: "Axel" <tester@tester.cc>
Newsgroups: sybase.public.ase.general,sybase.public.rep-server
Subject: Re: refresh a replication target from a live source
Date: Wed, 30 Dec 2009 10:11:20 -0800
Organization: Netfront http://www.netfront.net/
Lines: 36
Message-ID: <hhg549$qjb$1@adenine.netfront.net>
References: <hheba7$f6g$1@adenine.netfront.net> <c8ed1896-9791-4f0d-9e92-5afb232dfb38@v25g2000yqk.googlegroups.com>
NNTP-Posting-Host: 208.86.39.175
X-Trace: adenine.netfront.net 1262196681 27243 208.86.39.175 (30 Dec 2009 18:11:21 GMT)
X-Complaints-To: news@netfront.net
NNTP-Posting-Date: Wed, 30 Dec 2009 18:11:21 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5843
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Path: forums-1-dub!forums-master!newssvr.sybase.com!news-sj-1.sprintlink.net!news-peer1.sprintlink.net!newsfeed.yul.equant.net!novia!news-out.readnews.com!transit4.readnews.com!news.glorb.com!news.netfront.net!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:28811 sybase.public.rep-server:8540
Article PK: 78054

Regular, table-to-table, subscription-based, non-MSA.

"mpeppler@peppler.org [Team Sybase]" <michael.peppler@gmail.com> wrote in
message
news:c8ed1896-9791-4f0d-9e92-5afb232dfb38@v25g2000yqk.googlegroups.com...

On Dec 30, 2:44 am, "Axel" <tes...@tester.cc> wrote:
> It appears that if DSI is suspended on target, dump/load are performed,
> and
> DSI is restored, duplicate inserts start coming in from the target. So it
> looks like the new records created during the dump make it into the dump
> file and then show up in the target, because (as I presume) the rep agent
> on
> source collected these in parallel and the rep.server subsequently stored
> them in the outbound queue.
>
> Does anyone know a proper procedure for cloning a replica from a live
> database (with autocorrection off)?
> So that no transactions are lost, and at the same time there is no overlap
> as well?
>
> --- news://freenews.netfront.net/ - complaints: n...@netfront.net ---

This should probably go in the replication group.

However - what sort of replication are you using (i.e. is it warm
standby, MSA, or table level?)
If it is warm standby or MSA you can tell rep server to only start
distribution when it sees the dump marker. For MSA it's in the
subscription definition, if I recall correctly.

Michael




--- news://freenews.netfront.net/ - complaints: news@netfront.net ---


species8472 Posted on 2010-01-07 10:52:35.0Z
From: Species8472 <species8472@ergens.op.het.net>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
Newsgroups: sybase.public.ase.general,sybase.public.rep-server
Subject: Re: refresh a replication target from a live source
References: <hheba7$f6g$1@adenine.netfront.net> <c8ed1896-9791-4f0d-9e92-5afb232dfb38@v25g2000yqk.googlegroups.com> <hhg549$qjb$1@adenine.netfront.net>
In-Reply-To: <hhg549$qjb$1@adenine.netfront.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4b45bcf3$1@forums-1-dub>
Date: 7 Jan 2010 02:52:35 -0800
X-Trace: forums-1-dub 1262861555 10.22.241.152 (7 Jan 2010 02:52:35 -0800)
X-Original-Trace: 7 Jan 2010 02:52:35 -0800, vip152.sybase.com
Lines: 54
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:28843 sybase.public.rep-server:8558
Article PK: 78088


On 30/12/09 19:11 , Axel wrote:
> Regular, table-to-table, subscription-based, non-MSA.
>
> "mpeppler@peppler.org [Team Sybase]"<michael.peppler@gmail.com> wrote in
> message
> news:c8ed1896-9791-4f0d-9e92-5afb232dfb38@v25g2000yqk.googlegroups.com...
> On Dec 30, 2:44 am, "Axel"<tes...@tester.cc> wrote:
>> It appears that if DSI is suspended on target, dump/load are performed,
>> and
>> DSI is restored, duplicate inserts start coming in from the target. So it
>> looks like the new records created during the dump make it into the dump
>> file and then show up in the target, because (as I presume) the rep agent
>> on
>> source collected these in parallel and the rep.server subsequently stored
>> them in the outbound queue.
>>
>> Does anyone know a proper procedure for cloning a replica from a live
>> database (with autocorrection off)?
>> So that no transactions are lost, and at the same time there is no overlap
>> as well?
>>
>> --- news://freenews.netfront.net/ - complaints: n...@netfront.net ---
>
> This should probably go in the replication group.
>
> However - what sort of replication are you using (i.e. is it warm
> standby, MSA, or table level?)
> If it is warm standby or MSA you can tell rep server to only start
> distribution when it sees the dump marker. For MSA it's in the
> subscription definition, if I recall correctly.
>
> Michael
>
>
>
>
> --- news://freenews.netfront.net/ - complaints: news@netfront.net ---

modify repdefs to replicate all columns

suspend connection to yout replicate db.

dump

load

modify repdefs to use autocorrection

resume connection

wait until queues are drained

disable use of autocorrection on repdefs

modify repdefs to replicate minimal columns


"Mark A. Parsons" <iron_horse Posted on 2009-12-30 21:36:56.0Z
From: "Mark A. Parsons" <iron_horse@no_spamola.compuserve.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
Newsgroups: sybase.public.rep-server
Subject: Re: refresh a replication target from a live source
References: <hheba7$f6g$1@adenine.netfront.net> <c8ed1896-9791-4f0d-9e92-5afb232dfb38@v25g2000yqk.googlegroups.com> <hhg549$qjb$1@adenine.netfront.net>
In-Reply-To: <hhg549$qjb$1@adenine.netfront.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 091223-0, 12/23/2009), Outbound message
X-Antivirus-Status: Clean
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4b3bc7f8$1@forums-1-dub>
Date: 30 Dec 2009 13:36:56 -0800
X-Trace: forums-1-dub 1262209016 10.22.241.152 (30 Dec 2009 13:36:56 -0800)
X-Original-Trace: 30 Dec 2009 13:36:56 -0800, vip152.sybase.com
Lines: 70
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.rep-server:8541
Article PK: 869764

1 - suspend all activity in the PDB, make sure repagent is at the end of the log, make sure DSI is up, make sure
replication is quiesced, resync RDB from PDB (eg, dump-n-load, bcp, etc), resume activity in PDB

-------

2 - enable autocorrection to address any issues with duplicate/missing transactions; disable autocorrection once you're
past the issue

-------

3 - implement your own 'dump marker' logic to throw away unwanted transactions in the RDB

Notice that most (but not all!!) transactions into the RDB end with a call to rs_update_lastcommit, so you could modify
rs_update_lastcommit to discard (ie, rollback tran begin tran) any unwanted transactions based on @origin_time)

Issues:

a - need to be able to come up with a PDB datetime value that distinguishes between the transactions you want to ignore
and the transactions you want to keep; this would typically require a brief suspension of PDB activity to insure you
have a clear cut datetime value to separate 'good' and 'bad' transactions [this PDB datetime value could be placed in an
RDB table and referenced by the modified rs_update_lastcommit stored proc]

b - some DSI activity takes place outside of a transaction (eg, truncate table); you would have to insure said activity
does not take place in the PDB until after the RDB has been synced; in the example case of 'truncate table' you'd have
to modify your subscriptions to *not* subscribe to the 'truncate table' command, then modify them again to subscribe to
'truncate table' once you're past the potential duplicate/missing value stage

c - ... there are probably some other issues to consider depending on what other commands are being replicated, or what
options are in place with the DSI, ymmv

Axel wrote:
> Regular, table-to-table, subscription-based, non-MSA.
>
> "mpeppler@peppler.org [Team Sybase]" <michael.peppler@gmail.com> wrote in
> message
> news:c8ed1896-9791-4f0d-9e92-5afb232dfb38@v25g2000yqk.googlegroups.com...
> On Dec 30, 2:44 am, "Axel" <tes...@tester.cc> wrote:
>> It appears that if DSI is suspended on target, dump/load are performed,
>> and
>> DSI is restored, duplicate inserts start coming in from the target. So it
>> looks like the new records created during the dump make it into the dump
>> file and then show up in the target, because (as I presume) the rep agent
>> on
>> source collected these in parallel and the rep.server subsequently stored
>> them in the outbound queue.
>>
>> Does anyone know a proper procedure for cloning a replica from a live
>> database (with autocorrection off)?
>> So that no transactions are lost, and at the same time there is no overlap
>> as well?
>>
>> --- news://freenews.netfront.net/ - complaints: n...@netfront.net ---
>
> This should probably go in the replication group.
>
> However - what sort of replication are you using (i.e. is it warm
> standby, MSA, or table level?)
> If it is warm standby or MSA you can tell rep server to only start
> distribution when it sees the dump marker. For MSA it's in the
> subscription definition, if I recall correctly.
>
> Michael
>
>
>
>
> --- news://freenews.netfront.net/ - complaints: news@netfront.net ---


"Mark A. Parsons" <iron_horse Posted on 2009-12-30 21:56:36.0Z
From: "Mark A. Parsons" <iron_horse@no_spamola.compuserve.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
Newsgroups: sybase.public.rep-server
Subject: Re: refresh a replication target from a live source
References: <hheba7$f6g$1@adenine.netfront.net> <c8ed1896-9791-4f0d-9e92-5afb232dfb38@v25g2000yqk.googlegroups.com> <hhg549$qjb$1@adenine.netfront.net> <4b3bc7f8$1@forums-1-dub>
In-Reply-To: <4b3bc7f8$1@forums-1-dub>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 091223-0, 12/23/2009), Outbound message
X-Antivirus-Status: Clean
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <4b3bcc94$1@forums-1-dub>
Date: 30 Dec 2009 13:56:36 -0800
X-Trace: forums-1-dub 1262210196 10.22.241.152 (30 Dec 2009 13:56:36 -0800)
X-Original-Trace: 30 Dec 2009 13:56:36 -0800, vip152.sybase.com
Lines: 123
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.rep-server:8542
Article PK: 869765

... continuation of the 'roll your own dump marker' logic ...

issue c - if the RDB contains data from multiple PDBs then you'll need to modify the rs_update_lastcommit proc to check
both the origin and the origin time of the transaction (eg, store the origin and threshold datetime value in a local RDB
table)

issue d - if you choose to implement multiple threshold datetime values (eg, PDB tables resync'd at different times),
remember that there is no easy way to tell, inside of rs_update_lastcommit, what table(s) were processed in the current
transaction; and of course (?) you run into a big mess if multiple tables are modified in the same transaction, but each
table has a different PDB-related threshold datetime value

issue e - this proposed 'roll your own dump marker' logic is probably not supported by Sybase Tech Support so you'll be
responsible for thoroughly testing this solution if you choose to proceed with it


While I've used this method in a couple situations, each situation was fairly 'simple' (ie, no 'truncate table', simple
INSERT/UPDATE/DELETE activity, had the ability to suspend DML activity in the PDB for about 30 seconds to insure a clear
delineation between 'good' and 'bad' transactions, quiesce replication, perform a last tran log dump/load, etc).

Is this doable? yes

Does it require a lot of work/testing? perhaps, ymmv

Is it easier than just turning on autocorrection? perhaps though probably not, ymmv

--------

Another option ... don't worry about duplicate/missing data ... just run rs_subcmp to resync the PDB and RDB.

You could use rs_subccmp to a) perform the actual (re)sync or b) tidy up the RDB after performing your normal (re)sync
steps.

Unless you're working with a smallish volume of data, rs_subcmp probably isn't a viable option in terms of performance
and/or (potential) complexity.

It's probably much easier to enable autocorrection.

Mark A. Parsons wrote:
> 1 - suspend all activity in the PDB, make sure repagent is at the end of
> the log, make sure DSI is up, make sure replication is quiesced, resync
> RDB from PDB (eg, dump-n-load, bcp, etc), resume activity in PDB
>
> -------
>
> 2 - enable autocorrection to address any issues with duplicate/missing
> transactions; disable autocorrection once you're past the issue
>
> -------
>
> 3 - implement your own 'dump marker' logic to throw away unwanted
> transactions in the RDB
>
> Notice that most (but not all!!) transactions into the RDB end with a
> call to rs_update_lastcommit, so you could modify rs_update_lastcommit
> to discard (ie, rollback tran begin tran) any unwanted transactions
> based on @origin_time)
>
> Issues:
>
> a - need to be able to come up with a PDB datetime value that
> distinguishes between the transactions you want to ignore and the
> transactions you want to keep; this would typically require a brief
> suspension of PDB activity to insure you have a clear cut datetime value
> to separate 'good' and 'bad' transactions [this PDB datetime value could
> be placed in an RDB table and referenced by the modified
> rs_update_lastcommit stored proc]
>
> b - some DSI activity takes place outside of a transaction (eg, truncate
> table); you would have to insure said activity does not take place in
> the PDB until after the RDB has been synced; in the example case of
> 'truncate table' you'd have to modify your subscriptions to *not*
> subscribe to the 'truncate table' command, then modify them again to
> subscribe to 'truncate table' once you're past the potential
> duplicate/missing value stage
>
> c - ... there are probably some other issues to consider depending on
> what other commands are being replicated, or what options are in place
> with the DSI, ymmv
>
>
>
>
> Axel wrote:
>> Regular, table-to-table, subscription-based, non-MSA.
>>
>> "mpeppler@peppler.org [Team Sybase]" <michael.peppler@gmail.com> wrote
>> in message
>> news:c8ed1896-9791-4f0d-9e92-5afb232dfb38@v25g2000yqk.googlegroups.com...
>> On Dec 30, 2:44 am, "Axel" <tes...@tester.cc> wrote:
>>> It appears that if DSI is suspended on target, dump/load are
>>> performed, and
>>> DSI is restored, duplicate inserts start coming in from the target.
>>> So it
>>> looks like the new records created during the dump make it into the dump
>>> file and then show up in the target, because (as I presume) the rep
>>> agent on
>>> source collected these in parallel and the rep.server subsequently
>>> stored
>>> them in the outbound queue.
>>>
>>> Does anyone know a proper procedure for cloning a replica from a live
>>> database (with autocorrection off)?
>>> So that no transactions are lost, and at the same time there is no
>>> overlap
>>> as well?
>>>
>>> --- news://freenews.netfront.net/ - complaints: n...@netfront.net ---
>>
>> This should probably go in the replication group.
>>
>> However - what sort of replication are you using (i.e. is it warm
>> standby, MSA, or table level?)
>> If it is warm standby or MSA you can tell rep server to only start
>> distribution when it sees the dump marker. For MSA it's in the
>> subscription definition, if I recall correctly.
>>
>> Michael
>>
>>
>>
>>
>> --- news://freenews.netfront.net/ - complaints: news@netfront.net ---


Vivek Kak Posted on 2009-12-30 09:03:19.0Z
Sender: 63d0.4b3b0702.1804289383@sybase.com
From: Vivek Kak
Newsgroups: sybase.public.rep-server
Subject: Re: refresh a replication target from a live source
X-Mailer: WebNews to Mail Gateway v1.1t
Message-ID: <4b3b1757.65b0.1681692777@sybase.com>
References: <hheba7$f6g$1@adenine.netfront.net>
NNTP-Posting-Host: 10.22.241.41
X-Original-NNTP-Posting-Host: 10.22.241.41
Date: 30 Dec 2009 01:03:19 -0800
X-Trace: forums-1-dub 1262163799 10.22.241.41 (30 Dec 2009 01:03:19 -0800)
X-Original-Trace: 30 Dec 2009 01:03:19 -0800, 10.22.241.41
Lines: 40
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.rep-server:8538
Article PK: 869758

If you are using warm standby and you cannot arrange
downtime till refresh at replicate is done, use below steps:
1.Drop the physical connection to standby database.
2.Disable all dump jobs on primary database
3.Create physical connection to standby database with "use
dump marker "
4.dump database at primary site
5. Load the database dump at standby
6.Resume all threads and ensure replication is up and
running.


In case you are using table level replication and you want
to refresh the replicate with the primary dump, the best way
is to arrange the downtime with application folks till the
time you dump primary and load it at replicate.

HTH,
Vivek

> It appears that if DSI is suspended on target, dump/load
> are performed, and DSI is restored, duplicate inserts
> start coming in from the target. So it looks like the new
> records created during the dump make it into the dump
> file and then show up in the target, because (as I
> presume) the rep agent on source collected these in
> parallel and the rep.server subsequently stored them in
> the outbound queue.
>
> Does anyone know a proper procedure for cloning a replica
> from a live database (with autocorrection off)?
> So that no transactions are lost, and at the same time
> there is no overlap as well?
>
>
>
> --- news://freenews.netfront.net/ - complaints:
> news@netfront.net ---