Distributed databases in a cluster

Hello gurus!
I know that SQL 2000 and very probably Yukon SQL do not support a shared
disk cluster.
So, in the shared nothing schema is possible to (in a Active/Active):
having one SQL 2000 instance running in the Active1 Server with on Database
(like pubs) and in the Active2 Server another database (like northwind)
I want that the virtual Server redirect the query automatically to one
instance or to another and in case of failure of the Active1 Server, the
Avtive2 take the Active1 works and in case of failure of the Active2 Server,
the Active1 take the work of the Active2

Thanks a lot again
AA
The concept of data partitioning across servers is attractive on teh
surface, but has a lot of complexities. SQL 2000 has a distributed
partitioned view feature that applies this technology in a limited fashion.
SQL generally scales up, not out. If you want a faster system, purchase a
bigger box. There are very few real-world applications that cannot be done
with scale-up, even with current technology.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"AA" <aa@.personal.net.py> wrote in message
news:eXm5cOXIEHA.2480@.tk2msftngp13.phx.gbl...
> Hello gurus!
> I know that SQL 2000 and very probably Yukon SQL do not support a shared
> disk cluster.
> So, in the shared nothing schema is possible to (in a Active/Active):
> having one SQL 2000 instance running in the Active1 Server with on
Database
> (like pubs) and in the Active2 Server another database (like northwind)
> I want that the virtual Server redirect the query automatically to one
> instance or to another and in case of failure of the Active1 Server, the
> Avtive2 take the Active1 works and in case of failure of the Active2
Server,
> the Active1 take the work of the Active2
>
> Thanks a lot again
>
> AA
>
|||Actually, I'd disagree on the scale-up part. There are apps that would
bring even the largest commerically available servers to their knees if you
tried to run all of the transactions on a single machine.
The biggest part in here is that there is no technology inside SQL Server to
allow a transaction to automatically be continued on another node in the
event of a failover. This is possible, but it has to be coded into your
applications.
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com
|||I did qualify the statement about scale up. There are some environments
that simply cannot be scaled up to given current technology. However, I
consider those to be the exception, not the rule.
I also agree on the transaction failover issue. Smarter client tools and
faster failover on large systems will help, but scale out will need to be
addressed at some point. When and how is probably a marketing decision.
Unfortunately, none of those will help the original poster now. For his
application, he needs to start thinking about scale up if he wants to use
the current tool kit.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Michael Hotek" <mhotek@.nomail.com> wrote in message
news:OBcGddeIEHA.3276@.TK2MSFTNGP09.phx.gbl...
> Actually, I'd disagree on the scale-up part. There are apps that would
> bring even the largest commerically available servers to their knees if
you
> tried to run all of the transactions on a single machine.
> The biggest part in here is that there is no technology inside SQL Server
to
> allow a transaction to automatically be continued on another node in the
> event of a failover. This is possible, but it has to be coded into your
> applications.
> --
> Mike
> Principal Mentor
> Solid Quality Learning
> "More than just Training"
> SQL Server MVP
> http://www.solidqualitylearning.com
> http://www.mssqlserver.com
>
sql