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
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/prodinf...e/default.mspx
http://www.microsoft.com/sql/prodinf...enchmarks.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...
>
>
|||> (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...[vbcol=seagreen]
> 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:
|||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.googlegr oups.com...
> Sathian wrote:
> 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/prodinf...e/default.mspx
> http://www.microsoft.com/sql/prodinf...enchmarks.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
> --
>
Showing posts with label concept. Show all posts
Showing posts with label concept. Show all posts
Tuesday, February 14, 2012
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 achievi
ng
> better hardware utilization.All the applications have a chance to scale up
to
> 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/prodin...le/default.mspx
http://www.microsoft.com/sql/prodin...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 curren
t
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 marketi
ng
> 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 o
n.
> 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 pul
l
> the data, which can cause disk contention. Both machines have to calculat
e
> 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 get
s
> 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 compani
es
> 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-hour
s
> 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 the
y
> 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 wi
th
> severe contention in the disk resources as well as lots of wasted processi
ng
> 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...
>
>|||> (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:
>|||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:
> 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/prodin...le/default.mspx
> http://www.microsoft.com/sql/prodin...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
> --
>
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 achievi
ng
> better hardware utilization.All the applications have a chance to scale up
to
> 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/prodin...le/default.mspx
http://www.microsoft.com/sql/prodin...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 curren
t
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 marketi
ng
> 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 o
n.
> 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 pul
l
> the data, which can cause disk contention. Both machines have to calculat
e
> 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 get
s
> 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 compani
es
> 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-hour
s
> 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 the
y
> 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 wi
th
> severe contention in the disk resources as well as lots of wasted processi
ng
> 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...
>
>|||> (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:
>|||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:
> 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/prodin...le/default.mspx
> http://www.microsoft.com/sql/prodin...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
> --
>
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 achievi
ng
> better hardware utilization.All the applications have a chance to scale up
to
> 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/prodin...le/default.mspx
http://www.microsoft.com/sql/prodin...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 curren
t
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 marketi
ng
> 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 o
n.
> 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 pul
l
> the data, which can cause disk contention. Both machines have to calculat
e
> 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 get
s
> 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 compani
es
> 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-hour
s
> 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 the
y
> 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 wi
th
> severe contention in the disk resources as well as lots of wasted processi
ng
> 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...
>
>|||> (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...[vbcol=seagreen]
> 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:
>|||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:
> 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/prodin...le/default.mspx
> http://www.microsoft.com/sql/prodin...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
> --
>
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 achievi
ng
> better hardware utilization.All the applications have a chance to scale up
to
> 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/prodin...le/default.mspx
http://www.microsoft.com/sql/prodin...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 curren
t
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 marketi
ng
> 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 o
n.
> 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 pul
l
> the data, which can cause disk contention. Both machines have to calculat
e
> 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 get
s
> 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 compani
es
> 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-hour
s
> 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 the
y
> 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 wi
th
> severe contention in the disk resources as well as lots of wasted processi
ng
> 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...
>
>|||> (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...[vbcol=seagreen]
> 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:
>|||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:
> 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/prodin...le/default.mspx
> http://www.microsoft.com/sql/prodin...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
> --
>
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
> --
>
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
> --
>
Concept Hierarchy-
What are some strategies in categorizing items?Can you provide more details please?|||
Parent and child strategies
Computers>Laptops>Gateway
Price>Items
Can anyone think of any other strategies that can be applied to a retail enviroment for market basket anaylsis?
|||Usually I would use simple product categories as inputs rather than always using individual products. E.g. using Laptops and Ink Jet Printers rather than individual model numbers. As you learn more, you can drill down into details - e.g. which laptops indicate which printers, etc. - you can see my answer to your other question on this forum for more ideasConcept for View
Hi,
Could someone please explain to me when the view is updatable and when it
is not? I am under the impression that if the two tables are joined togethe
r
in the view, then the view is not updatable... is it correct?
ThanksSee the CREATE VIEW in the Books Online <tsqlref.chm::/ts_create2_30hj.htm>
for a detailed description of when a view is updatable.
For an updatable view containing joins, INSERT/UPDATE/DELETE statements are
allowed as long as only one underlying base table is affected. For example:
CREATE TABLE Table1
(
Col1a int NOT NULL
CONSTRAINT PK_Table1 PRIMARY KEY,
Col1b int NOT NULL
)
GO
CREATE TABLE Table2
(
Col2a int NOT NULL
CONSTRAINT PK_Table2 PRIMARY KEY,
Col2b int NOT NULL
)
GO
CREATE VIEW MyView
AS
SELECT Col1a, Col1b, Col2a, Col2b
FROM Table1 AS t1
JOIN Table2 AS t2 ON
t2.Col2a = t1.Col1a
GO
--succeeds
UPDATE MyView
SET Col1b = 1
GO
--fails
UPDATE MyView
SET Col1b = 1, Col2b = 1
Hope this helps.
Dan Guzman
SQL Server MVP
"Ed" <Ed@.discussions.microsoft.com> wrote in message
news:864C5D55-3A5D-4F97-ABF1-9DAE7B057B33@.microsoft.com...
> Hi,
> Could someone please explain to me when the view is updatable and when it
> is not? I am under the impression that if the two tables are joined
> together
> in the view, then the view is not updatable... is it correct?
> Thanks
Could someone please explain to me when the view is updatable and when it
is not? I am under the impression that if the two tables are joined togethe
r
in the view, then the view is not updatable... is it correct?
ThanksSee the CREATE VIEW in the Books Online <tsqlref.chm::/ts_create2_30hj.htm>
for a detailed description of when a view is updatable.
For an updatable view containing joins, INSERT/UPDATE/DELETE statements are
allowed as long as only one underlying base table is affected. For example:
CREATE TABLE Table1
(
Col1a int NOT NULL
CONSTRAINT PK_Table1 PRIMARY KEY,
Col1b int NOT NULL
)
GO
CREATE TABLE Table2
(
Col2a int NOT NULL
CONSTRAINT PK_Table2 PRIMARY KEY,
Col2b int NOT NULL
)
GO
CREATE VIEW MyView
AS
SELECT Col1a, Col1b, Col2a, Col2b
FROM Table1 AS t1
JOIN Table2 AS t2 ON
t2.Col2a = t1.Col1a
GO
--succeeds
UPDATE MyView
SET Col1b = 1
GO
--fails
UPDATE MyView
SET Col1b = 1, Col2b = 1
Hope this helps.
Dan Guzman
SQL Server MVP
"Ed" <Ed@.discussions.microsoft.com> wrote in message
news:864C5D55-3A5D-4F97-ABF1-9DAE7B057B33@.microsoft.com...
> Hi,
> Could someone please explain to me when the view is updatable and when it
> is not? I am under the impression that if the two tables are joined
> together
> in the view, then the view is not updatable... is it correct?
> Thanks
Concept confused... Please help
Sorry for this dump question!!!
I am confused with the concept...
I install a SQL Server and Analysis Services at home and I would like to
play around the Analysis Serverices function.
I need to build the datawarehouse on SQL Server and use Analysis Services to
Gerenrate the Queries I want in Analysis Services from datawarehouse. Am i
right?
I thought I was in the wrong impression that everything is done in Analysis
Services for datawarehouse...
I am assuming that I need to create a new database called Northwind_DW and
start to create e.g. 4 dimension tables and 1 fact table + 5 Staging tables.
Then I extract data from the Northwind database and put the data into 5
staging tables and massage the data then dump the data into the 4 dimension
tables and 1 fact table.
If this is the case, this should call a DataMart not DataWarehouse, am I
right?
Finally, I should use Analysis Services to retrieve the data from those 5
tables to build cube and pre-calulated number for the reporting puposes...
Am I right?
Well... I know this may be a long message, but I do thanks for your help
Ed
Your understanding is correct. Usually the data in the database is
transaction-based, meaning is changes frequently and has a heavy load of
real-time user access. Once your data is set and does not change as much -
it can be exported into a separate database, serving as a relational data
source for your data mart/data warehouse. Usually such databases are
designed according to star schema with fact tables and dimensions, that is
why you often would create temporary staging tables which would help you
reorganize data. Then you use your database as a source for your Analysis
Services Cubes and Dimensions.
Having a data warehouse/data mart usually helps offload your report-oriented
users from the live database, meaning they will not slow down your system
passing in large queries.
Whereas a data warehouse combines databases across an entire enterprise,
data marts are usually smaller and focus on a particular subject or
department. Some data marts, called dependent data marts, are subsets of
larger data warehouses. You can read more about the difference here:
http://www.dmreview.com/article_sub.cfm?articleId=1675
Regards,
Ilona Shulman
Senior Development Consultant, DBA
SSE Inc
http://www.sseinc.com
"Ed" <Ed@.discussions.microsoft.com> wrote in message
news:A9330538-9D99-4801-8791-A8A4A00F51CD@.microsoft.com...
> Sorry for this dump question!!!
> I am confused with the concept...
> I install a SQL Server and Analysis Services at home and I would like to
> play around the Analysis Serverices function.
> I need to build the datawarehouse on SQL Server and use Analysis Services
to
> Gerenrate the Queries I want in Analysis Services from datawarehouse. Am
i
> right?
> I thought I was in the wrong impression that everything is done in
Analysis
> Services for datawarehouse...
> I am assuming that I need to create a new database called Northwind_DW and
> start to create e.g. 4 dimension tables and 1 fact table + 5 Staging
tables.
> Then I extract data from the Northwind database and put the data into 5
> staging tables and massage the data then dump the data into the 4
dimension
> tables and 1 fact table.
> If this is the case, this should call a DataMart not DataWarehouse, am I
> right?
> Finally, I should use Analysis Services to retrieve the data from those 5
> tables to build cube and pre-calulated number for the reporting
puposes...
> Am I right?
> Well... I know this may be a long message, but I do thanks for your help
> Ed
>
I am confused with the concept...
I install a SQL Server and Analysis Services at home and I would like to
play around the Analysis Serverices function.
I need to build the datawarehouse on SQL Server and use Analysis Services to
Gerenrate the Queries I want in Analysis Services from datawarehouse. Am i
right?
I thought I was in the wrong impression that everything is done in Analysis
Services for datawarehouse...
I am assuming that I need to create a new database called Northwind_DW and
start to create e.g. 4 dimension tables and 1 fact table + 5 Staging tables.
Then I extract data from the Northwind database and put the data into 5
staging tables and massage the data then dump the data into the 4 dimension
tables and 1 fact table.
If this is the case, this should call a DataMart not DataWarehouse, am I
right?
Finally, I should use Analysis Services to retrieve the data from those 5
tables to build cube and pre-calulated number for the reporting puposes...
Am I right?
Well... I know this may be a long message, but I do thanks for your help
Ed
Your understanding is correct. Usually the data in the database is
transaction-based, meaning is changes frequently and has a heavy load of
real-time user access. Once your data is set and does not change as much -
it can be exported into a separate database, serving as a relational data
source for your data mart/data warehouse. Usually such databases are
designed according to star schema with fact tables and dimensions, that is
why you often would create temporary staging tables which would help you
reorganize data. Then you use your database as a source for your Analysis
Services Cubes and Dimensions.
Having a data warehouse/data mart usually helps offload your report-oriented
users from the live database, meaning they will not slow down your system
passing in large queries.
Whereas a data warehouse combines databases across an entire enterprise,
data marts are usually smaller and focus on a particular subject or
department. Some data marts, called dependent data marts, are subsets of
larger data warehouses. You can read more about the difference here:
http://www.dmreview.com/article_sub.cfm?articleId=1675
Regards,
Ilona Shulman
Senior Development Consultant, DBA
SSE Inc
http://www.sseinc.com
"Ed" <Ed@.discussions.microsoft.com> wrote in message
news:A9330538-9D99-4801-8791-A8A4A00F51CD@.microsoft.com...
> Sorry for this dump question!!!
> I am confused with the concept...
> I install a SQL Server and Analysis Services at home and I would like to
> play around the Analysis Serverices function.
> I need to build the datawarehouse on SQL Server and use Analysis Services
to
> Gerenrate the Queries I want in Analysis Services from datawarehouse. Am
i
> right?
> I thought I was in the wrong impression that everything is done in
Analysis
> Services for datawarehouse...
> I am assuming that I need to create a new database called Northwind_DW and
> start to create e.g. 4 dimension tables and 1 fact table + 5 Staging
tables.
> Then I extract data from the Northwind database and put the data into 5
> staging tables and massage the data then dump the data into the 4
dimension
> tables and 1 fact table.
> If this is the case, this should call a DataMart not DataWarehouse, am I
> right?
> Finally, I should use Analysis Services to retrieve the data from those 5
> tables to build cube and pre-calulated number for the reporting
puposes...
> Am I right?
> Well... I know this may be a long message, but I do thanks for your help
> Ed
>
Subscribe to:
Posts (Atom)