Help Needed - How Can I Set Up a Backup SQL Server Machine as an Exact Copy of My Production SQL Server

[Michael Orlando]

Any help would be greatly appreciated.

My problem is that I need to set up a backup SQL Server 2000 machine
which can be used in case of a failure to my primary. All databases
(30 as of now) must be an up to the minute exact copy of production
and include most recent changes in data as well as any structure
changes (Tables, Views, SP's, Triggers, Users . . etc).

When I tried this using Transactional Replication, the replication
process gets fouled up once I introduce any kind of structure changes
to the DB. I've considered the idea of doing periodic backups and
restoring it to my backup SQL server, but this does not give me the
concurrency needed with 0 latency.

I've seen articles that recommend using Transaction Replication with
'Scheduled Table Refresh', and also doing database dumps to restore on
the backup machine, but I have not been able to find any documentation
regarding this to try out. How can I implement this type of backup
strategy in SQL 2000?

[Greg D. Moore \(Strider\)]

"Michael Orlando" <mj*******@campsystems.com> wrote in message
news:35**************************@posting.google.c om...

Any help would be greatly appreciated.

My problem is that I need to set up a backup SQL Server 2000 machine
which can be used in case of a failure to my primary. All databases
(30 as of now) must be an up to the minute exact copy of production
and include most recent changes in data as well as any structure
changes (Tables, Views, SP's, Triggers, Users . . etc).
Clustering.

Though technically that's not a copy.


When I tried this using Transactional Replication, the replication
process gets fouled up once I introduce any kind of structure changes
to the DB. I've considered the idea of doing periodic backups and
restoring it to my backup SQL server, but this does not give me the
concurrency needed with 0 latency.
If you use transactional replication you have to use sp_repladdcolumn and
sp_repldropcolumn for adding dropping columns. All other schema changes
generally have to be run against both copies.

Note also there's no guarantee as to the latency that Transactional
replication will introduce.

Log shipping will allow exact copies, but again with a built in latency.
I'd recommend picking up "SQL Server 2000 High Availability " from MS Press
and reading that.

I've seen articles that recommend using Transaction Replication with
'Scheduled Table Refresh', and also doing database dumps to restore on
the backup machine, but I have not been able to find any documentation
regarding this to try out. How can I implement this type of backup
strategy in SQL 2000?

[Simon Hayes]

mj*******@campsystems.com (Michael Orlando) wrote in message news:<35**************************@posting.google. com>...

Any help would be greatly appreciated.

My problem is that I need to set up a backup SQL Server 2000 machine
which can be used in case of a failure to my primary. All databases
(30 as of now) must be an up to the minute exact copy of production
and include most recent changes in data as well as any structure
changes (Tables, Views, SP's, Triggers, Users . . etc).

When I tried this using Transactional Replication, the replication
process gets fouled up once I introduce any kind of structure changes
to the DB. I've considered the idea of doing periodic backups and
restoring it to my backup SQL server, but this does not give me the
concurrency needed with 0 latency.

I've seen articles that recommend using Transaction Replication with
'Scheduled Table Refresh', and also doing database dumps to restore on
the backup machine, but I have not been able to find any documentation
regarding this to try out. How can I implement this type of backup
strategy in SQL 2000?

What exactly do you mean by 'up to the minute'? The only other
'instant' alternative to transactional replication is clustering,
which would also avoid your schema change issues.

I don't know much about replication myself, so you might want to post
to microsoft.public.sqlserver.replication with your backup question.
Also, have a look at the October 2003 issue of SQL Server Magazine,
which had a number of articles on various high-availability solutions.

Simon