Hi everyone,
A number of my clients keep talking about creating a backup server so that
they can quickly switch to the backup server in case the live database
server failed.
I was dabbling with the following idea.
If I could create a software that continuosly trapped SQL commands being
fired [or SPs being fired] on the live database [just like the Profiler] ,
filter out only the UPDATE syntaxes and fire them against a backup server,
couldn't I create a one-way replication programmatically?
Any ideas or suggestions from you guys?
Thanx
AbhayWhat about transaction log shipping? Then using applying them to the backup
database. In the event of failure, the backup system can be bought online
in a matter of minutes.
"Abhay Sobti" <stansoft@.vsnl.com> wrote in message
news:u$%23TZTyRGHA.5468@.TK2MSFTNGP14.phx.gbl...
> Hi everyone,
> A number of my clients keep talking about creating a backup server so that
> they can quickly switch to the backup server in case the live database
> server failed.
> I was dabbling with the following idea.
> If I could create a software that continuosly trapped SQL commands being
> fired [or SPs being fired] on the live database [just like the Profiler] ,
> filter out only the UPDATE syntaxes and fire them against a backup server,
> couldn't I create a one-way replication programmatically?
> Any ideas or suggestions from you guys?
> Thanx
> Abhay
>|||Bad idea. Why not use regular replication if that is what you want?
You'll have problems with things like GETDATE(), IDENTITY and GUID
columns because they will/may produce different results when the second
update is ran.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment