Do I really need a snapshot (to initialize transactional replication, in SQL2000)?

I have a pretty big (350 gb) OLTP database that I want to replicate in its entirety. I'm concerned about the impact of taking a snapshot of it (it is processing at some level pretty much 24x7). I know on SQL2005 there is the option to initialize from backup, but unfortunately we won't be on 2005 in time.

I'm thinking of doing something like this:

Set up the distributor, publication, and subscription Turn off distribution agent Set the publisher to "sync with backup" Backup the publisher, full then log Truncate tables MSrepl_transactions and MSrepl_commands in the distribution db (I don't have any other replication going on) Turn off "sync with backup" Restore the full and tran log backups to new subscriber db Create subscriber stored procs in subscriber Start up distribution agent

I'm looking for opinions on whether it's worth going this route to avoid taking the snapshot. Data integrity is the number one priority -- if I have to do a snapshot to ensure that, I will do it.

Thanks in advance!

Mike

OK, I just did a search and came across this:

http://support.microsoft.com/default.aspx?scid=kb;en-us;320499

However this method still requires a brief time in single user mode (ie killing all connections), whereas my method doesn't. I just don't like that my method involves deleting the MSrepl_ tables...

Distribution Agent Latency question

I am delivering replicated data from a t3
connection to a t1 connection.. My ping times to
the subscriber are pretty good.. about 40ms
consistant. I have the following rates that seem
to be really slow for distributor/subscribers on
such good connections.
delivery rate (cmds/sec) = 212.0000
latency (msec) = 26890205 <--this seems high
# trans = 12
# cmds = 83784
avg. # cmds = 6982
This latency also seems to be making my
distribution database large on my distributor.
I am using default distribution agent profiles
and it's set to run every 15min.
I don't know - does 7 hours latency sound normal to you?
Latency is occasionally wrong. It reflects the delta between the time the
transaction entered the distribution database and the time it made it to the
subscriber.
If your distribution agent is not continuous the schedule is reflected in
the latency.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Combfilter" <adsf@.asdf.com> wrote in message
news:MPG.1be9951edb17d9149896d1@.news.newsreader.co m...
> I am delivering replicated data from a t3
> connection to a t1 connection.. My ping times to
> the subscriber are pretty good.. about 40ms
> consistant. I have the following rates that seem
> to be really slow for distributor/subscribers on
> such good connections.
> delivery rate (cmds/sec) = 212.0000
> latency (msec) = 26890205 <--this seems high
> # trans = 12
> # cmds = 83784
> avg. # cmds = 6982
> This latency also seems to be making my
> distribution database large on my distributor.
> I am using default distribution agent profiles
> and it's set to run every 15min.
|||In article <uEryCWJvEHA.3624
@.TK2MSFTNGP09.phx.gbl>, hilary.cotter@.gmail.com
says...
> I don't know - does 7 hours latency sound normal to you?
> Latency is occasionally wrong. It reflects the delta between the time the
> transaction entered the distribution database and the time it made it to the
> subscriber.
> If your distribution agent is not continuous the schedule is reflected in
> the latency.
>
Anything I should start looking at to resolve why
there is such high latency for this one
subscription only? I have the log reader set to
run continuous and the dist. agent to run every
15min.
tia
-comb