Redundant SQL server

Hi, good day everyone.

I would like to have a question here,

I want to configure a redundant SQL server. Let's said if server A is down, then server B can take over the workload of server A, and this is transparent to users which means they won't notify server A is down.

Besides the failover clustering method, is there any other solution?

My requirement is needed to run in Microsoft SQL 2000 standard edition and Microsoft Windows 2000 standard edition

Thanks,First, you need to determine what the business is willing to pay for that type of solution. I often find if it costs $100,000 to provide a undetectable failover with no data loss versus paying $5,000 to have a slightly detectable failover with up to 5 minutes of data loss, the business chooses the latter 95% of the time.

Once you've got budget commitment, you decide what approach you use.

In the real world, you are expected to do it for free. However, I always ask the above question the first time. That way, they're prepared the next time.

The answer to the question you are asking is entirely dependent on knowing the resources you have available to do it. Once you know that, let us know the details on what you have committed to do and we'll help you. You should expect hardware to not be an issue because you must have at least the same firepower as your production to ensure you can handle the load for an indefinite time.

Finally, the highest % (by a landslide) of failures that require you to failover are due to user error - for example, a 'DBA' forgetting a WHERE clause. You can handle that with the $5,000 option.|||FWIW: I would think that Windows Server 2003 might be a better option for the OS...|||a redundant server for SQL 2k is known as a standby server
in the absence of a clustered solution, log shipping can be used to copy transaction logs from server a to server b
the logs can be copied at any interval you wish and are restored to the server b database with the standby option.
with standby restores logs to the database places the db in a read only state and allows the subsequent restoration of tlog backups to server b until you change the with standby clause to with recovery.

the switch from SA to SB is much quicker than in prior editions becuase of the addition of stored procedures that will allow the mapping of logins and the changing of server roles.

Books Online {log shipping}|||Scott, that would be nice, except...Log Shipping is avalable only in EE, not standard. You can simulate log shipping behavior by doing it yourself through scheduled tasks, or you can ask someone to make copies of system stored procedures from the enterprise edition and semi-emulate its behavior.

EDITED: wait a minute, does it mean that SQL Server can qualify for "open source product" label?|||you might want to take some of your glycerin before you read this old man.

Scott, that would be nice, except...Log Shipping is avalable only in EE, not standard. You can simulate log shipping behavior by doing it yourself through scheduled tasks, or you can ask someone to make copies of system stored procedures from the enterprise edition and semi-emulate its behavior.

EDITED: wait a minute, does it mean that SQL Server can qualify for "open source product" label?

as you notice i invoked the "with standby" clause of restore and the phrase "standby server". this was to illustrate that it is a process available to all editions
while the sqlmaint process of log shipping and the sp's are exclusive to ent, standby servers are available to all systems.

let' s do lunch next week.|||blah-blah-blah...

OK, lunch sounds great! I'll give you a call.