I'm kinda new to this DBA lark, so this may seem like a stupid question,
but the ASE Replicator docco for 12.5.4 doesn't say anything one way or
the other.

I've been asked to replicate a database from one machine to another.
Replication Server isn't an option, so I'm looking at ASE Replicator.
I think the performance will probably be adequate.

However. First thing every day a bcp is done into this database. I had
understood that having bulkcopy enabled on a database basically screws up
transaction-log dumps. The database also has "trunc on checkpoint" enabled
though I could probably get that removed.

Is this bcp going to make Replicator unsuitable?

Thanks.

Matt

--
* Matt McLeod | mail: matt@boggle.org | blog: http://abortrephrase.com/ *
--- People can do the work, so machines have time to think ---

On Apr 10, 7:45*pm, Matt McLeod <m...@boggle.org> wrote:
> I'm kinda new to this DBA lark, so this may seem like a stupid question,
> but the ASE Replicator docco for 12.5.4 doesn't say anything one way or
> the other.
>
> I've been asked to replicate a database from one machine to another.
> Replication Server isn't an option, so I'm looking at ASE Replicator.
> I think the performance will probably be adequate.
>
> However. *First thing every day a bcp is done into this database. *I had
> understood that having bulkcopy enabled on a database basically screws up
> transaction-log dumps. *The database also has "trunc on checkpoint" enabled
> though I could probably get that removed.
>
> Is this bcp going to make Replicator unsuitable?
>
> Thanks.
>
> Matt
>
> --
> * Matt McLeod | mail: m...@boggle.org | blog:http://abortrephrase.com/*
> * * *--- People can do the work, so machines have time to think ---

Can't speak for Replicator but for RepServer:

1) "trunc log on chkpt." must go on the source side.
2) Fast bcp operations, (since they are "mininimally logged" will not
get replicated. Silently.
Because the REP_AGENT doesn't even see them.
3) Slow bcp operations, however, should get replicated, but w/
RepServer at least you have to
be careful about the batch size since it's easy to overwhelp
RepServer and clog up the
stable queue.

A couple of notes:

a) The only way to control whether bcp is fast or slow, near as I can
tell, is
create / drop the indices on a table.
b) While minimially logged bcp ops won't get replicated, minimally
logged SELECT INTO
ops will, if you're careful about permissioning (DDL gets
replicated as the user on the primary,
whomever that may be, which includes the implied CREATE TABLE; ..
DML, including the
implied INSERT ... SELECT get replicated as maintenance user, with
no opportunity to
issue a GRANT INSERT ... between the two...).

Keith

In <f9325459-168e-4b21-b714-fe4c1283b794@s50g2000hsb.googlegroups.com>, Keith wrote:
> Can't speak for Replicator but for RepServer:
[...]

Thanks for the info.

After testing Replicator I've decided it's too easy to confuse, so I'm
going to resort to writing scripts to do transaction log dumps on the
primary host and load them on the secondary every few minutes.

It's not ideal, but probably the best I can do without buying RepServer.

Matt

--
* Matt McLeod | mail: matt@boggle.org | blog: http://abortrephrase.com/ *
--- People can do the work, so machines have time to think ---