Concept of Oracle Grid Architecture

Dear All,
We knew that there is a concept called Oracle Grid Architecture through
which we can utilise
resources of an under utilised Server in Multiple Server environemnt.
For Eg :
Pool the clusters of servers to make a single logical entity using Oracle
10g Grid architecture.More flexibility to adapt to peak loads thus achieving
better hardware utilization.All the applications have a chance to scale upto
to the maximum capacity of the Grid rather then individual server maximum
capacity.Manage many as one. e.g. 5 Servers each of 3 GB RAM in a Grid
results in 15 GB of RAM available for utilization. Whereas in the current
method each application associated with a server can only scale upto 3 GB.
Do we have something similar in SQL Server Scenario?
Your replies would be highly appreciated.
Regards
SathianSathian wrote:
> Dear All,
> We knew that there is a concept called Oracle Grid Architecture through
> which we can utilise
> resources of an under utilised Server in Multiple Server environemnt.
> For Eg :
> Pool the clusters of servers to make a single logical entity using Oracle
> 10g Grid architecture.More flexibility to adapt to peak loads thus achieving
> better hardware utilization.All the applications have a chance to scale upto
> to the maximum capacity of the Grid rather then individual server maximum
> capacity.Manage many as one. e.g. 5 Servers each of 3 GB RAM in a Grid
> results in 15 GB of RAM available for utilization. Whereas in the current
> method each application associated with a server can only scale upto 3 GB.
> Do we have something similar in SQL Server Scenario?
> Your replies would be highly appreciated.
>
> Regards
> Sathian
Microsoft just sees the architecture slightly differently. It advocates
implementing the application cluster through a .NET tier rather than
the database tier. Actually Microsoft claims there have been working
examples of application clusters using SQL Server 2000 since before
Oracle did the same.
More at:
http://www.microsoft.com/sql/prodinfo/compare/oracle/default.mspx
http://www.microsoft.com/sql/prodinfo/compare/benchmarks.mspx
--
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||No. Being able to simply plug a second server in and double the capacity or
to fully take advantage of an "underutilized" server is a bunch of marketing
BS. The real-world implementation isn't even close to the marketing.
Take the pure Oracle point of view and take a hard look at what is going on.
I have 5 servers each with 3 GB of RAM in them setup in a "grid"
architecture. That's great. Do I get to utilize 100% of the 15GB? Nope.
There are several reasons. User1 executes "nasty query 1" by using the
resources on server3. At the same time, User2 executes "nasty query 1"
using the resources on server4. So, both are going after exactly the same
data from this shared database on the backside. Both machines have to pull
the data, which can cause disk contention. Both machines have to calculate
the results, because I'm not aware of any ability for a machine to start a
calc on one server and finish it on another, so you are duplicating the
work. The data cache can possibly contain 2 copies of the same data set
which is in effect wasted memory. The whole thing gets even more
interesting when two people change the same piece of data routed through 2
different servers and now Oracle has to arbitrate a winner and someone gets
a failure sent back to them. The list of issues goes on and on and on.
This isn't as simple a "plug in another server". I've worked with companies
who implemented Oracle RAC. I know of a couple who got very good results
from it with near linear scaling, but they spent thousands of DBA man-hours
re-architecting applications, redesigning databases, beefing up
infrastructure, and very carefully analyzing data access patterns before
implementing it and they got near linear scaling up to 4 nodes because they
had access patterns which guaranteed that data requests would not overlap.
I know of several companies that added a second server and only got about a
50% increase and it dropped off very rapidly after that to the point where
the 4th server only gained them about 5% of the total capacity that was
added, because they had lots of these overlapping requests and wound up with
severe contention in the disk resources as well as lots of wasted processing
time.
--
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Sathian" <sathian.t@.in.bosch.com> wrote in message
news:dsslp4$k99$1@.ns2.fe.internet.bosch.com...
> Dear All,
> We knew that there is a concept called Oracle Grid Architecture through
> which we can utilise
> resources of an under utilised Server in Multiple Server environemnt.
> For Eg :
> Pool the clusters of servers to make a single logical entity using Oracle
> 10g Grid architecture.More flexibility to adapt to peak loads thus
> achieving
> better hardware utilization.All the applications have a chance to scale
> upto
> to the maximum capacity of the Grid rather then individual server maximum
> capacity.Manage many as one. e.g. 5 Servers each of 3 GB RAM in a Grid
> results in 15 GB of RAM available for utilization. Whereas in the current
> method each application associated with a server can only scale upto 3 GB.
> Do we have something similar in SQL Server Scenario?
> Your replies would be highly appreciated.
>
> Regards
> Sathian
>|||RAC is different from GRID.
A lot of the issues that you are describing are RAC issues (Real Application
Clusters) where multiple servers share a common database. RAC is the current
name/evolution/version of what used to be called the Oracle Parallel System
(OPS), which in one form or another goes back to Oracle 6.2 (before SQL
Server existed, as such).
Grid is a different approach, as I understand it. It is closer to the old
Tandem Non-Stop/Stratus envrionment where application processes are assigned
to various servers in a cluster or Grid (like electrical power lines and
substations.) If you have excess cpu capacity on 1 server, you can have it
run a clone application process. Also if your processing needs for a given
application which has multiple processes have decreased, you can drop one of
the processes and reassign the resources elsewhere. Additionally, if a
server goes down then the application process can be assigned to another
server to minimize downtime. At least this is the sales pitch.
GRID sits on RAC, so if you have RAC problems your GRID will suffer, but
GRID is something different.
--
Joseph R.P. Maloney, CSP,CCP,CDP
"Michael Hotek" wrote:
> No. Being able to simply plug a second server in and double the capacity or
> to fully take advantage of an "underutilized" server is a bunch of marketing
> BS. The real-world implementation isn't even close to the marketing.
> Take the pure Oracle point of view and take a hard look at what is going on.
> I have 5 servers each with 3 GB of RAM in them setup in a "grid"
> architecture. That's great. Do I get to utilize 100% of the 15GB? Nope.
> There are several reasons. User1 executes "nasty query 1" by using the
> resources on server3. At the same time, User2 executes "nasty query 1"
> using the resources on server4. So, both are going after exactly the same
> data from this shared database on the backside. Both machines have to pull
> the data, which can cause disk contention. Both machines have to calculate
> the results, because I'm not aware of any ability for a machine to start a
> calc on one server and finish it on another, so you are duplicating the
> work. The data cache can possibly contain 2 copies of the same data set
> which is in effect wasted memory. The whole thing gets even more
> interesting when two people change the same piece of data routed through 2
> different servers and now Oracle has to arbitrate a winner and someone gets
> a failure sent back to them. The list of issues goes on and on and on.
> This isn't as simple a "plug in another server". I've worked with companies
> who implemented Oracle RAC. I know of a couple who got very good results
> from it with near linear scaling, but they spent thousands of DBA man-hours
> re-architecting applications, redesigning databases, beefing up
> infrastructure, and very carefully analyzing data access patterns before
> implementing it and they got near linear scaling up to 4 nodes because they
> had access patterns which guaranteed that data requests would not overlap.
> I know of several companies that added a second server and only got about a
> 50% increase and it dropped off very rapidly after that to the point where
> the 4th server only gained them about 5% of the total capacity that was
> added, because they had lots of these overlapping requests and wound up with
> severe contention in the disk resources as well as lots of wasted processing
> time.
> --
> Mike
> http://www.solidqualitylearning.com
> Disclaimer: This communication is an original work and represents my sole
> views on the subject. It does not represent the views of any other person
> or entity either by inference or direct reference.
>
> "Sathian" <sathian.t@.in.bosch.com> wrote in message
> news:dsslp4$k99$1@.ns2.fe.internet.bosch.com...
> > Dear All,
> >
> > We knew that there is a concept called Oracle Grid Architecture through
> > which we can utilise
> > resources of an under utilised Server in Multiple Server environemnt.
> >
> > For Eg :
> > Pool the clusters of servers to make a single logical entity using Oracle
> > 10g Grid architecture.More flexibility to adapt to peak loads thus
> > achieving
> > better hardware utilization.All the applications have a chance to scale
> > upto
> > to the maximum capacity of the Grid rather then individual server maximum
> > capacity.Manage many as one. e.g. 5 Servers each of 3 GB RAM in a Grid
> > results in 15 GB of RAM available for utilization. Whereas in the current
> > method each application associated with a server can only scale upto 3 GB.
> >
> > Do we have something similar in SQL Server Scenario?
> >
> > Your replies would be highly appreciated.
> >
> >
> > Regards
> >
> > Sathian
> >
> >
>
>|||> (OPS), which in one form or another goes back to Oracle 6.2 (before SQL
> Server existed, as such). <
Oracle 6.2 & SQL Server 1.0 were both released in 1989.
As for Oracle's history with clustering, anyone who worked with the these
technologies in the early '90's would remember that Oracle's clulster
technology was, well, .. a toy.. This was one of the main reasons why Oracle
bought DEC Rdb - to get at DEC's SSI clustering technology, which they
eventually wove in a half-baked way (in the RDBMS but without OS support)
into Oracle RAC.
If RAC / GRID is a successful technology, why does Oracle continue to post
higher TPC-C records on single machines than on clusters? If the technology
really scaled, surely putting two of those big boxes they run the single
TPC-C's on side by side in a GRID would produce a bigger TPC-C score? Note
also that their last TPC-C was only 50% of that posted by IBM, so lack of
motivation is no excuse..
Regards,
Greg Linwood
SQL Server MVP
"jrpm" <jrpm@.discussions.microsoft.com> wrote in message
news:B2711833-380B-4675-9919-51A6C7F03387@.microsoft.com...
> RAC is different from GRID.
> A lot of the issues that you are describing are RAC issues (Real
> Application
> Clusters) where multiple servers share a common database. RAC is the
> current
> name/evolution/version of what used to be called the Oracle Parallel
> System
> (OPS), which in one form or another goes back to Oracle 6.2 (before SQL
> Server existed, as such).
>
> Grid is a different approach, as I understand it. It is closer to the old
> Tandem Non-Stop/Stratus envrionment where application processes are
> assigned
> to various servers in a cluster or Grid (like electrical power lines and
> substations.) If you have excess cpu capacity on 1 server, you can have it
> run a clone application process. Also if your processing needs for a given
> application which has multiple processes have decreased, you can drop one
> of
> the processes and reassign the resources elsewhere. Additionally, if a
> server goes down then the application process can be assigned to another
> server to minimize downtime. At least this is the sales pitch.
> GRID sits on RAC, so if you have RAC problems your GRID will suffer, but
> GRID is something different.
> --
> Joseph R.P. Maloney, CSP,CCP,CDP
>
> "Michael Hotek" wrote:
>> No. Being able to simply plug a second server in and double the capacity
>> or
>> to fully take advantage of an "underutilized" server is a bunch of
>> marketing
>> BS. The real-world implementation isn't even close to the marketing.
>> Take the pure Oracle point of view and take a hard look at what is going
>> on.
>> I have 5 servers each with 3 GB of RAM in them setup in a "grid"
>> architecture. That's great. Do I get to utilize 100% of the 15GB?
>> Nope.
>> There are several reasons. User1 executes "nasty query 1" by using the
>> resources on server3. At the same time, User2 executes "nasty query 1"
>> using the resources on server4. So, both are going after exactly the
>> same
>> data from this shared database on the backside. Both machines have to
>> pull
>> the data, which can cause disk contention. Both machines have to
>> calculate
>> the results, because I'm not aware of any ability for a machine to start
>> a
>> calc on one server and finish it on another, so you are duplicating the
>> work. The data cache can possibly contain 2 copies of the same data set
>> which is in effect wasted memory. The whole thing gets even more
>> interesting when two people change the same piece of data routed through
>> 2
>> different servers and now Oracle has to arbitrate a winner and someone
>> gets
>> a failure sent back to them. The list of issues goes on and on and on.
>> This isn't as simple a "plug in another server". I've worked with
>> companies
>> who implemented Oracle RAC. I know of a couple who got very good results
>> from it with near linear scaling, but they spent thousands of DBA
>> man-hours
>> re-architecting applications, redesigning databases, beefing up
>> infrastructure, and very carefully analyzing data access patterns before
>> implementing it and they got near linear scaling up to 4 nodes because
>> they
>> had access patterns which guaranteed that data requests would not
>> overlap.
>> I know of several companies that added a second server and only got about
>> a
>> 50% increase and it dropped off very rapidly after that to the point
>> where
>> the 4th server only gained them about 5% of the total capacity that was
>> added, because they had lots of these overlapping requests and wound up
>> with
>> severe contention in the disk resources as well as lots of wasted
>> processing
>> time.
>> --
>> Mike
>> http://www.solidqualitylearning.com
>> Disclaimer: This communication is an original work and represents my sole
>> views on the subject. It does not represent the views of any other
>> person
>> or entity either by inference or direct reference.
>>
>> "Sathian" <sathian.t@.in.bosch.com> wrote in message
>> news:dsslp4$k99$1@.ns2.fe.internet.bosch.com...
>> > Dear All,
>> >
>> > We knew that there is a concept called Oracle Grid Architecture through
>> > which we can utilise
>> > resources of an under utilised Server in Multiple Server environemnt.
>> >
>> > For Eg :
>> > Pool the clusters of servers to make a single logical entity using
>> > Oracle
>> > 10g Grid architecture.More flexibility to adapt to peak loads thus
>> > achieving
>> > better hardware utilization.All the applications have a chance to scale
>> > upto
>> > to the maximum capacity of the Grid rather then individual server
>> > maximum
>> > capacity.Manage many as one. e.g. 5 Servers each of 3 GB RAM in a Grid
>> > results in 15 GB of RAM available for utilization. Whereas in the
>> > current
>> > method each application associated with a server can only scale upto 3
>> > GB.
>> >
>> > Do we have something similar in SQL Server Scenario?
>> >
>> > Your replies would be highly appreciated.
>> >
>> >
>> > Regards
>> >
>> > Sathian
>> >
>> >
>>|||There were application clusters working against SQL Server since before SQL
Server 2000. I worked on one piece of a custom solution that utilized SQL
Server 7.0. So, custom implementations are definitely out there.
--
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1139925420.358264.146430@.g43g2000cwa.googlegroups.com...
> Sathian wrote:
>> Dear All,
>> We knew that there is a concept called Oracle Grid Architecture through
>> which we can utilise
>> resources of an under utilised Server in Multiple Server environemnt.
>> For Eg :
>> Pool the clusters of servers to make a single logical entity using Oracle
>> 10g Grid architecture.More flexibility to adapt to peak loads thus
>> achieving
>> better hardware utilization.All the applications have a chance to scale
>> upto
>> to the maximum capacity of the Grid rather then individual server maximum
>> capacity.Manage many as one. e.g. 5 Servers each of 3 GB RAM in a Grid
>> results in 15 GB of RAM available for utilization. Whereas in the current
>> method each application associated with a server can only scale upto 3
>> GB.
>> Do we have something similar in SQL Server Scenario?
>> Your replies would be highly appreciated.
>>
>> Regards
>> Sathian
> Microsoft just sees the architecture slightly differently. It advocates
> implementing the application cluster through a .NET tier rather than
> the database tier. Actually Microsoft claims there have been working
> examples of application clusters using SQL Server 2000 since before
> Oracle did the same.
> More at:
> http://www.microsoft.com/sql/prodinfo/compare/oracle/default.mspx
> http://www.microsoft.com/sql/prodinfo/compare/benchmarks.mspx
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>