we have been reviewing the possibilities of scale-out technology such as
data partitioning, federated servers, peer to peer repl, clustering, etc.

It appears that scaling out will be very difficult to implement for SQL
Server. Does anyone know of any plans in SQL2008 or greater for something
similar to Oracle's RAC (real application clusters). From the white paper I
read, it appears to be 1 database being managed by multiple servers or nodes
- and you can add to or remove w/out much difficulty. There does NOT appear
to be any data partitioning or replication of data between nodes etc.

regards,
chris

Oracle RAC is good for some workloads and bad for others. This is not
necessarily an indictment of RAC because no solution is good at all the
workloads. But the point is that RAC is definitely not a cure all scale-out
solution, and for some workloads you still need to partition your data to get
the desired scalability.

And ultimately, to scale real big, I'd argue that you must employ some types
of partitioning. What matters is to what extent the DBMS can help cover the
gory details, thus making it easy to deploy and support. Some DBMS does a
better job than others in this respect.

At this point, SQL Server doesn't have a coherent general-purpose scale-out
solution. And if you read the Microsoft public marketing responses to the RAC
question, you probably shouldn't hold your breath for a RAC-like scale-out
solution any time soon. Well, that's just my personal take, and I have no
specific knowledge what MS may be planning on delivery in this area. But I
have no doubt that Microsoft will come out with some type of SQL Server
scale-out solution because the market is demanding it and competition is
forcing it. It can't afford to ignore it.

For now, you can still develop scale-out solution with SQL Server. You just
have to analyze your data and workloads and tailor a solution to fit the
requirements. For instance, your data and workload may be such that you can
do hash partitioning at the app level and have the queries directed to
multiple database servers.

Linchi

"Chris" wrote:

Oracle RAC is good for some workloads and bad for others. This is not
necessarily an indictment of RAC because no solution is good at all the
workloads. But the point is that RAC is definitely not a cure all scale-out
solution, and for some workloads you still need to partition your data to get
the desired scalability.

And ultimately, to scale real big, I'd argue that you must employ some types
of partitioning. What matters is to what extent the DBMS can help cover the
gory details, thus making it easy to deploy and support. Some DBMS does a
better job than others in this respect.

At this point, SQL Server doesn't have a coherent general-purpose scale-out
solution. And if you read the Microsoft public marketing responses to the RAC
question, you probably shouldn't hold your breath for a RAC-like scale-out
solution any time soon. Well, that's just my personal take, and I have no
specific knowledge what MS may be planning on delivery in this area. But I
have no doubt that Microsoft will come out with some type of SQL Server
scale-out solution because the market is demanding it and competition is
forcing it. It can't afford to ignore it.

For now, you can still develop scale-out solution with SQL Server. You just
have to analyze your data and workloads and tailor a solution to fit the
requirements. For instance, your data and workload may be such that you can
do hash partitioning at the app level and have the queries directed to
multiple database servers.

Linchi

"Chris" wrote:

Oracle RAC is good for some workloads and bad for others. This is not
necessarily an indictment of RAC because no solution is good at all the
workloads. But the point is that RAC is definitely not a cure all scale-out
solution, and for some workloads you still need to partition your data to get
the desired scalability.

And ultimately, to scale real big, I'd argue that you must employ some types
of partitioning. What matters is to what extent the DBMS can help cover the
gory details, thus making it easy to deploy and support. Some DBMS does a
better job than others in this respect.

At this point, SQL Server doesn't have a coherent general-purpose scale-out
solution. And if you read the Microsoft public marketing responses to the RAC
question, you probably shouldn't hold your breath for a RAC-like scale-out
solution any time soon. Well, that's just my personal take, and I have no
specific knowledge what MS may be planning on delivery in this area. But I
have no doubt that Microsoft will come out with some type of SQL Server
scale-out solution because the market is demanding it and competition is
forcing it. It can't afford to ignore it.

For now, you can still develop scale-out solution with SQL Server. You just
have to analyze your data and workloads and tailor a solution to fit the
requirements. For instance, your data and workload may be such that you can
do hash partitioning at the app level and have the queries directed to
multiple database servers.

Linchi

"Chris" wrote:

Oracle RAC is good for some workloads and bad for others. This is not
necessarily an indictment of RAC because no solution is good at all the
workloads. But the point is that RAC is definitely not a cure all scale-out
solution, and for some workloads you still need to partition your data to get
the desired scalability.

And ultimately, to scale real big, I'd argue that you must employ some types
of partitioning. What matters is to what extent the DBMS can help cover the
gory details, thus making it easy to deploy and support. Some DBMS does a
better job than others in this respect.

At this point, SQL Server doesn't have a coherent general-purpose scale-out
solution. And if you read the Microsoft public marketing responses to the RAC
question, you probably shouldn't hold your breath for a RAC-like scale-out
solution any time soon. Well, that's just my personal take, and I have no
specific knowledge what MS may be planning on delivery in this area. But I
have no doubt that Microsoft will come out with some type of SQL Server
scale-out solution because the market is demanding it and competition is
forcing it. It can't afford to ignore it.

For now, you can still develop scale-out solution with SQL Server. You just
have to analyze your data and workloads and tailor a solution to fit the
requirements. For instance, your data and workload may be such that you can
do hash partitioning at the app level and have the queries directed to
multiple database servers.

Linchi

"Chris" wrote:

Oracle RAC is good for some workloads and bad for others. This is not
necessarily an indictment of RAC because no solution is good at all the
workloads. But the point is that RAC is definitely not a cure all scale-out
solution, and for some workloads you still need to partition your data to get
the desired scalability.

And ultimately, to scale real big, I'd argue that you must employ some types
of partitioning. What matters is to what extent the DBMS can help cover the
gory details, thus making it easy to deploy and support. Some DBMS does a
better job than others in this respect.

At this point, SQL Server doesn't have a coherent general-purpose scale-out
solution. And if you read the Microsoft public marketing responses to the RAC
question, you probably shouldn't hold your breath for a RAC-like scale-out
solution any time soon. Well, that's just my personal take, and I have no
specific knowledge what MS may be planning on delivery in this area. But I
have no doubt that Microsoft will come out with some type of SQL Server
scale-out solution because the market is demanding it and competition is
forcing it. It can't afford to ignore it.

For now, you can still develop scale-out solution with SQL Server. You just
have to analyze your data and workloads and tailor a solution to fit the
requirements. For instance, your data and workload may be such that you can
do hash partitioning at the app level and have the queries directed to
multiple database servers.

Linchi

"Chris" wrote:

Oracle RAC is good for some workloads and bad for others. This is not
necessarily an indictment of RAC because no solution is good at all the
workloads. But the point is that RAC is definitely not a cure all scale-out
solution, and for some workloads you still need to partition your data to get
the desired scalability.

And ultimately, to scale real big, I'd argue that you must employ some types
of partitioning. What matters is to what extent the DBMS can help cover the
gory details, thus making it easy to deploy and support. Some DBMS does a
better job than others in this respect.

At this point, SQL Server doesn't have a coherent general-purpose scale-out
solution. And if you read the Microsoft public marketing responses to the RAC
question, you probably shouldn't hold your breath for a RAC-like scale-out
solution any time soon. Well, that's just my personal take, and I have no
specific knowledge what MS may be planning on delivery in this area. But I
have no doubt that Microsoft will come out with some type of SQL Server
scale-out solution because the market is demanding it and competition is
forcing it. It can't afford to ignore it.

For now, you can still develop scale-out solution with SQL Server. You just
have to analyze your data and workloads and tailor a solution to fit the
requirements. For instance, your data and workload may be such that you can
do hash partitioning at the app level and have the queries directed to
multiple database servers.

Linchi

"Chris" wrote:

Oracle RAC is good for some workloads and bad for others. This is not
necessarily an indictment of RAC because no solution is good at all the
workloads. But the point is that RAC is definitely not a cure all scale-out
solution, and for some workloads you still need to partition your data to get
the desired scalability.

And ultimately, to scale real big, I'd argue that you must employ some types
of partitioning. What matters is to what extent the DBMS can help cover the
gory details, thus making it easy to deploy and support. Some DBMS does a
better job than others in this respect.

At this point, SQL Server doesn't have a coherent general-purpose scale-out
solution. And if you read the Microsoft public marketing responses to the RAC
question, you probably shouldn't hold your breath for a RAC-like scale-out
solution any time soon. Well, that's just my personal take, and I have no
specific knowledge what MS may be planning on delivery in this area. But I
have no doubt that Microsoft will come out with some type of SQL Server
scale-out solution because the market is demanding it and competition is
forcing it. It can't afford to ignore it.

For now, you can still develop scale-out solution with SQL Server. You just
have to analyze your data and workloads and tailor a solution to fit the
requirements. For instance, your data and workload may be such that you can
do hash partitioning at the app level and have the queries directed to
multiple database servers.

Linchi

"Chris" wrote:

Oracle RAC is good for some workloads and bad for others. This is not
necessarily an indictment of RAC because no solution is good at all the
workloads. But the point is that RAC is definitely not a cure all scale-out
solution, and for some workloads you still need to partition your data to get
the desired scalability.

And ultimately, to scale real big, I'd argue that you must employ some types
of partitioning. What matters is to what extent the DBMS can help cover the
gory details, thus making it easy to deploy and support. Some DBMS does a
better job than others in this respect.

At this point, SQL Server doesn't have a coherent general-purpose scale-out
solution. And if you read the Microsoft public marketing responses to the RAC
question, you probably shouldn't hold your breath for a RAC-like scale-out
solution any time soon. Well, that's just my personal take, and I have no
specific knowledge what MS may be planning on delivery in this area. But I
have no doubt that Microsoft will come out with some type of SQL Server
scale-out solution because the market is demanding it and competition is
forcing it. It can't afford to ignore it.

For now, you can still develop scale-out solution with SQL Server. You just
have to analyze your data and workloads and tailor a solution to fit the
requirements. For instance, your data and workload may be such that you can
do hash partitioning at the app level and have the queries directed to
multiple database servers.

Linchi

"Chris" wrote:

Oracle RAC is good for some workloads and bad for others. This is not
necessarily an indictment of RAC because no solution is good at all the
workloads. But the point is that RAC is definitely not a cure all scale-out
solution, and for some workloads you still need to partition your data to get
the desired scalability.

And ultimately, to scale real big, I'd argue that you must employ some types
of partitioning. What matters is to what extent the DBMS can help cover the
gory details, thus making it easy to deploy and support. Some DBMS does a
better job than others in this respect.

At this point, SQL Server doesn't have a coherent general-purpose scale-out
solution. And if you read the Microsoft public marketing responses to the RAC
question, you probably shouldn't hold your breath for a RAC-like scale-out
solution any time soon. Well, that's just my personal take, and I have no
specific knowledge what MS may be planning on delivery in this area. But I
have no doubt that Microsoft will come out with some type of SQL Server
scale-out solution because the market is demanding it and competition is
forcing it. It can't afford to ignore it.

For now, you can still develop scale-out solution with SQL Server. You just
have to analyze your data and workloads and tailor a solution to fit the
requirements. For instance, your data and workload may be such that you can
do hash partitioning at the app level and have the queries directed to
multiple database servers.

Linchi

"Chris" wrote: