2012年3月7日星期三

Disadvantage "trunc. log on chkpt."?

Hi NG
In a published db (transactional), anytime
the option "trunc. log on chkpt."( for fast BCP) is active.
I have set
<PublicationDatabaseName>', 'sync with backup', 'true'
<DisributionDatabaseName>', 'sync with backup', 'true'
for full recovery in desaster case.
Is it a problem?
BOL says, if sync with backup = true
then trunc. log on chkpt must be false!
How can I bypass this circumstance?
Stop Logreader and Distritask?
Regards,
Thomas
the same question
for option: 'select into/bulkcopy'
On Mon, 16 Aug 2004 09:16:47 GMT, tohas@.freenet.de (Thomas Hase)
wrote:

>Hi NG
>In a published db (transactional), anytime
>the option "trunc. log on chkpt."( for fast BCP) is active.
>I have set
><PublicationDatabaseName>', 'sync with backup', 'true'
><DisributionDatabaseName>', 'sync with backup', 'true'
>for full recovery in desaster case.
>Is it a problem?
>BOL says, if sync with backup = true
>then trunc. log on chkpt must be false!
>How can I bypass this circumstance?
>Stop Logreader and Distritask?
>Regards,
>Thomas
|||If you have to switch recovery models you are breaking the log chain. You
will have to change your recovery model back to full, backup your databases
(distribution and publication) and restore them on the subscriber with the
keep_replication switch.
Then start shipping the logs again.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"Thomas Hase" <tohas@.freenet.de> wrote in message
news:41227e0d.67962859@.news.t-online.de...
> the same question
> for option: 'select into/bulkcopy'
>
> On Mon, 16 Aug 2004 09:16:47 GMT, tohas@.freenet.de (Thomas Hase)
> wrote:
>

没有评论:

发表评论