Hot failover.

Hot failover.

Post by Obewah » Thu, 17 Apr 2003 20:41:50



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
edition.

Replication is not an option as these are purchase applications and
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.

Any help?

Thanks for your time.

 
 
 

Hot failover.

Post by twigg » Thu, 17 Apr 2003 20:57:26


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.

Quote:>-----Original Message-----
>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
Quote:>edition.

>Replication is not an option as these are purchase
applications and
>databases that we cannot adjust the schema.  Snapshot

replication isn't real
Quote:>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.

>Any help?

>Thanks for your time.

>.


 
 
 

Hot failover.

Post by Flicke » Fri, 18 Apr 2003 01:34:00


http://www.sql-server-performance.com/sql_server_log_shipping.asp


Quote:> 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
> edition.

> Replication is not an option as these are purchase applications and
> 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.

> Any help?

> Thanks for your time.

 
 
 

1. Hot failover options

Hi-

I've been reading a lot about replication and clustering for SQL Server
- but have absolutely no production experience with either one.
Presently the application I support uses db backup and restore, SQL
Server 7.0 sp2 to a failover machine.  The desire is to have that
machine be a hot failover with accurate data we could immediately point
to if the primary db fails.  I'm investigating the options and related
considerations.  Please let me know if I have missed something or am
just completely wrong...I really am taking some stabs in the dark here.
Thanks in advance for your feedback.

Immediate Update Transactional Replication
Advantages...db data is up to date as of the time the primary db server
fails
Drawbacks...If one server goes down, are they both down?  Network speed
is slow...Also concerned about how much extra load the transaction
logging might create on the primary db server.

Merge Replication
Advantages...if one server is down the other is still accessible, also
when the primary server is back up it will re-merge with the failover db
and both be synched again
Drawbacks... the db data would only be up to date with the last
scheduled merge data prior to primary db server failing ...Also
concerned about how much extra load would be created on the primary db
server.

Log Shipping
This option was rejected due to the perceived time it would take to
transfer, update and restore the logs...also not sure if this really
would provide the updated data that is desired.

Clustering
Advantages...sounds like a good option
Drawbacks...sounds expensive and quite complicated to implement.

2. Export File

3. HOT HOT HOT HOT ORACLE POSITIONS !!!

4. Linked server Problem

5. HOT HOT HOT ORACLE POSITIONS !!!!

6. TN-NASHVILLE-66705--C-C++-Windows Development-Visual C++-ORACLE-Lead Programmer ( 2 positions open)

7. HOT HOT HOT ORACLE POSITIONS !!!

8. Reports- Database changes

9. (PDXJOBS) Oracle/Informix DBA - HOT HOT

10. HOT! HOT! HOT!