Log shipping is definately the answer. I'm at most 2
minutes behind my production server. And if my transaction
log is not corrupted when the db goes down I can grab the
last of the transaction and be within seconds.
If you using 7 your going to have write your own. 2000
comes with it, but is not all the good.
Basically backup your database. Restore it on a replica
with the standby option on. This will leave your database
read only, but you can restore logs to it ( only if no one
else is connected though ).
Then start backing up your transaction log a little less
then the interval you want to be behind. Have a program
check for new files in a directory on an interval and then
have it copy it to the backup server.
Then you'll need a job on the backup server to restore
this log to the backup.
There is some third party software out there that is
actually much better then SQL 2000 implementation of log
shipping. You might want to look into that.
>I need all to reply here and thanks for doing so.
>We need as close to a hot failover as possible. We're
using SQL 7 standard
>Replication is not an option as these are purchase
>databases that we cannot adjust the schema. Snapshot
replication isn't real
>time aware thus not an option.
>If we could use some sort of log shipping that would put
us 15 minutes
>behind the production server then that would be ok.
>Thanks for your time.