AMD vs Intel for SQL Servers

I know at one time AMD used to be power players for SQL Servers, but of
late, I am hearing that Intel chips are also proving to be efficient.
Can you share what you have seen in your benchmarks on some of the new
models say in the HP space using either Intel or AMD ?
ThanksOn May 3, 6:12 pm, "Hassan" <has...@.hotmail.com> wrote:
> I know at one time AMD used to be power players for SQL Servers, but of
> late, I am hearing that Intel chips are also proving to be efficient.
> Can you share what you have seen in your benchmarks on some of the new
> models say in the HP space using either Intel or AMD ?
> Thanks
We upgraded to AMD 64 bit dual opteron box with 4 gb memory and we
were completely happy with the results. That was almost 2 years ago
and back then AMD sort of swept the market with price and
performance. AMD memory access architecture for processors is far
better than performing then Intel . So I prefer AMD x64 over Intel
EMT and has been implementing most of the sql server and desktops with
AMD x64 processors|||On 04.05.2007 03:10, Bulent wrote:
> On May 3, 6:12 pm, "Hassan" <has...@.hotmail.com> wrote:
> We upgraded to AMD 64 bit dual opteron box with 4 gb memory and we
> were completely happy with the results. That was almost 2 years ago
> and back then AMD sort of swept the market with price and
> performance. AMD memory access architecture for processors is far
> better than performing then Intel . So I prefer AMD x64 over Intel
> EMT and has been implementing most of the sql server and desktops with
> AMD x64 processors
Curious: does it really make a difference? I would have guessed that
the capabilities of the IO subsystem are far more important for a DB
server than the CPU.
Kind regards
robert|||> Curious: does it really make a difference? I would have guessed that
> the capabilities of the IO subsystem are far more important for a DB
> server than the CPU.
I would not discount the importance of CPUs to that degree. It's true if
your workload is stressing something else, having more processor power
wouldn't help much. But in general, it pays to find out which processor work
s
best under what circusmstances. There are still many processing intensive
tasks. Plus, vendors are constantly trying to take advantage of the ever
increasing processor power, to trade processing for resources that may be
under stress.
Linchi
"Robert Klemme" wrote:

> On 04.05.2007 03:10, Bulent wrote:
> Curious: does it really make a difference? I would have guessed that
> the capabilities of the IO subsystem are far more important for a DB
> server than the CPU.
> Kind regards
> robert
>|||On May 4, 9:49 pm, Linchi Shea <LinchiS...@.discussions.microsoft.com>
wrote:
> I would not discount the importance of CPUs to that degree. It's true if
> your workload is stressing something else, having more processor power
> wouldn't help much. But in general, it pays to find out which processor wo
rks
> best under what circusmstances. There are still many processing intensive
> tasks. Plus, vendors are constantly trying to take advantage of the ever
> increasing processor power, to trade processing for resources that may be
> under stress.
> Linchi
>
> "Robert Klemme" wrote:
>
>
>
>
>
> - Show quoted text -
Definitely there is the IO subsystem that's very important for
database servers. The hypertransport technology and direct memory
access that amd based systems use is also far better than Intel.
Bottom line you will get better IO performance. Before you make your
decision check out the those and compare against intel and it's Core2
Duo systems and io, memory access methods.

AMD vs Intel for SQL Servers

I know at one time AMD used to be power players for SQL Servers, but of
late, I am hearing that Intel chips are also proving to be efficient.
Can you share what you have seen in your benchmarks on some of the new
models say in the HP space using either Intel or AMD ?
Thanks
On May 3, 6:12 pm, "Hassan" <has...@.hotmail.com> wrote:
> I know at one time AMD used to be power players for SQL Servers, but of
> late, I am hearing that Intel chips are also proving to be efficient.
> Can you share what you have seen in your benchmarks on some of the new
> models say in the HP space using either Intel or AMD ?
> Thanks
We upgraded to AMD 64 bit dual opteron box with 4 gb memory and we
were completely happy with the results. That was almost 2 years ago
and back then AMD sort of swept the market with price and
performance. AMD memory access architecture for processors is far
better than performing then Intel . So I prefer AMD x64 over Intel
EMT and has been implementing most of the sql server and desktops with
AMD x64 processors
|||On 04.05.2007 03:10, Bulent wrote:
> On May 3, 6:12 pm, "Hassan" <has...@.hotmail.com> wrote:
> We upgraded to AMD 64 bit dual opteron box with 4 gb memory and we
> were completely happy with the results. That was almost 2 years ago
> and back then AMD sort of swept the market with price and
> performance. AMD memory access architecture for processors is far
> better than performing then Intel . So I prefer AMD x64 over Intel
> EMT and has been implementing most of the sql server and desktops with
> AMD x64 processors
Curious: does it really make a difference? I would have guessed that
the capabilities of the IO subsystem are far more important for a DB
server than the CPU.
Kind regards
robert
|||> Curious: does it really make a difference? I would have guessed that
> the capabilities of the IO subsystem are far more important for a DB
> server than the CPU.
I would not discount the importance of CPUs to that degree. It's true if
your workload is stressing something else, having more processor power
wouldn't help much. But in general, it pays to find out which processor works
best under what circusmstances. There are still many processing intensive
tasks. Plus, vendors are constantly trying to take advantage of the ever
increasing processor power, to trade processing for resources that may be
under stress.
Linchi
"Robert Klemme" wrote:

> On 04.05.2007 03:10, Bulent wrote:
> Curious: does it really make a difference? I would have guessed that
> the capabilities of the IO subsystem are far more important for a DB
> server than the CPU.
> Kind regards
> robert
>
|||On May 4, 9:49 pm, Linchi Shea <LinchiS...@.discussions.microsoft.com>
wrote:
> I would not discount the importance of CPUs to that degree. It's true if
> your workload is stressing something else, having more processor power
> wouldn't help much. But in general, it pays to find out which processor works
> best under what circusmstances. There are still many processing intensive
> tasks. Plus, vendors are constantly trying to take advantage of the ever
> increasing processor power, to trade processing for resources that may be
> under stress.
> Linchi
>
> "Robert Klemme" wrote:
>
>
>
> - Show quoted text -
Definitely there is the IO subsystem that's very important for
database servers. The hypertransport technology and direct memory
access that amd based systems use is also far better than Intel.
Bottom line you will get better IO performance. Before you make your
decision check out the those and compare against intel and it's Core2
Duo systems and io, memory access methods.

AMD vs Intel for SQL Servers

I know at one time AMD used to be power players for SQL Servers, but of
late, I am hearing that Intel chips are also proving to be efficient.
Can you share what you have seen in your benchmarks on some of the new
models say in the HP space using either Intel or AMD ?
ThanksOn May 3, 6:12 pm, "Hassan" <has...@.hotmail.com> wrote:
> I know at one time AMD used to be power players for SQL Servers, but of
> late, I am hearing that Intel chips are also proving to be efficient.
> Can you share what you have seen in your benchmarks on some of the new
> models say in the HP space using either Intel or AMD ?
> Thanks
We upgraded to AMD 64 bit dual opteron box with 4 gb memory and we
were completely happy with the results. That was almost 2 years ago
and back then AMD sort of swept the market with price and
performance. AMD memory access architecture for processors is far
better than performing then Intel . So I prefer AMD x64 over Intel
EMT and has been implementing most of the sql server and desktops with
AMD x64 processors|||On 04.05.2007 03:10, Bulent wrote:
> On May 3, 6:12 pm, "Hassan" <has...@.hotmail.com> wrote:
>> I know at one time AMD used to be power players for SQL Servers, but of
>> late, I am hearing that Intel chips are also proving to be efficient.
>> Can you share what you have seen in your benchmarks on some of the new
>> models say in the HP space using either Intel or AMD ?
> We upgraded to AMD 64 bit dual opteron box with 4 gb memory and we
> were completely happy with the results. That was almost 2 years ago
> and back then AMD sort of swept the market with price and
> performance. AMD memory access architecture for processors is far
> better than performing then Intel . So I prefer AMD x64 over Intel
> EMT and has been implementing most of the sql server and desktops with
> AMD x64 processors
Curious: does it really make a difference? I would have guessed that
the capabilities of the IO subsystem are far more important for a DB
server than the CPU.
Kind regards
robert|||> Curious: does it really make a difference? I would have guessed that
> the capabilities of the IO subsystem are far more important for a DB
> server than the CPU.
I would not discount the importance of CPUs to that degree. It's true if
your workload is stressing something else, having more processor power
wouldn't help much. But in general, it pays to find out which processor works
best under what circusmstances. There are still many processing intensive
tasks. Plus, vendors are constantly trying to take advantage of the ever
increasing processor power, to trade processing for resources that may be
under stress.
Linchi
"Robert Klemme" wrote:
> On 04.05.2007 03:10, Bulent wrote:
> > On May 3, 6:12 pm, "Hassan" <has...@.hotmail.com> wrote:
> >> I know at one time AMD used to be power players for SQL Servers, but of
> >> late, I am hearing that Intel chips are also proving to be efficient.
> >>
> >> Can you share what you have seen in your benchmarks on some of the new
> >> models say in the HP space using either Intel or AMD ?
> >
> > We upgraded to AMD 64 bit dual opteron box with 4 gb memory and we
> > were completely happy with the results. That was almost 2 years ago
> > and back then AMD sort of swept the market with price and
> > performance. AMD memory access architecture for processors is far
> > better than performing then Intel . So I prefer AMD x64 over Intel
> > EMT and has been implementing most of the sql server and desktops with
> > AMD x64 processors
> Curious: does it really make a difference? I would have guessed that
> the capabilities of the IO subsystem are far more important for a DB
> server than the CPU.
> Kind regards
> robert
>|||On May 4, 9:49 pm, Linchi Shea <LinchiS...@.discussions.microsoft.com>
wrote:
> > Curious: does it really make a difference? I would have guessed that
> > the capabilities of the IO subsystem are far more important for a DB
> > server than the CPU.
> I would not discount the importance of CPUs to that degree. It's true if
> your workload is stressing something else, having more processor power
> wouldn't help much. But in general, it pays to find out which processor works
> best under what circusmstances. There are still many processing intensive
> tasks. Plus, vendors are constantly trying to take advantage of the ever
> increasing processor power, to trade processing for resources that may be
> under stress.
> Linchi
>
> "Robert Klemme" wrote:
> > On 04.05.2007 03:10, Bulent wrote:
> > > On May 3, 6:12 pm, "Hassan" <has...@.hotmail.com> wrote:
> > >> I know at one time AMD used to be power players for SQL Servers, but of
> > >> late, I am hearing that Intel chips are also proving to be efficient.
> > >> Can you share what you have seen in your benchmarks on some of the new
> > >> models say in the HP space using either Intel or AMD ?
> > > We upgraded to AMD 64 bit dual opteron box with 4 gb memory and we
> > > were completely happy with the results. That was almost 2 years ago
> > > and back then AMD sort of swept the market with price and
> > > performance. AMD memory access architecture for processors is far
> > > better than performing then Intel . So I prefer AMD x64 over Intel
> > > EMT and has been implementing most of the sql server and desktops with
> > > AMD x64 processors
> > Curious: does it really make a difference? I would have guessed that
> > the capabilities of the IO subsystem are far more important for a DB
> > server than the CPU.
> > Kind regards
> > robert- Hide quoted text -
> - Show quoted text -
Definitely there is the IO subsystem that's very important for
database servers. The hypertransport technology and direct memory
access that amd based systems use is also far better than Intel.
Bottom line you will get better IO performance. Before you make your
decision check out the those and compare against intel and it's Core2
Duo systems and io, memory access methods.

Alternatives to CURSORs

Hi all

I have often come across discussions on this forum saying that CURSORs are expensive in time (processing power?).

Having used CURSORs to processing a mere 2000+ record (not much at all) which took a fair while to complete, I now realize why you guys are saying CURSORs are expensive.

But is there alternatives to using CURSORs in the situation where I try to process every records returned by a particular query?

Say for example, i want to update columns that comes from different tables for every record that is returned by a SELECT JOIN query. there is no way that i can do that with a single UPDATE statement cause i can't do JOIN with UPDATE query.

All comments welcome

James :)well u can :
update a set aa= b.bb
from table_a a
inner join table_b b on a.key = b.key

since in cursors u use loops try :
loop on numeric key in table

select @.i = Min(int_key) From Tablename
while @.i <= (select @.Max(int_key) From Tablename)
begin
.
.

end|||yes you can join tables in the from clause of an update statement
[BOL] UPDATE (described)

check out example 'C' at the bottom of the help document|||Thank you guys.

Is it standard ANSI to use join in an update query? Although it would make sense that it is. I have tried it before without success for some reason. :( I will try it again.

James :)|||No, JOIN operations in an UPDATE are explicitly forbidden by the ISO, and were never addressed by ANSI. While JOIN operations in an UPDATE can be convenient, they violate most of the rules of relational algebra. Sybase and Microsoft are the only commercially successful engines I can think of that support them.

-PatP|||Really?

So in Oracle, for instance, you can't execute a statement like:

update A
set A.Column = NewValue
from A
inner join B on A.Key = B.Value

?

ANSI or not, that's pretty simple and pretty convenient too.|||Originally posted by Pat Phelan
No, JOIN operations in an UPDATE are explicitly forbidden by the ISO, and were never addressed by ANSI. While JOIN operations in an UPDATE can be convenient, they violate most of the rules of relational algebra. Sybase and Microsoft are the only commercially successful engines I can think of that support them.

-PatP

Nope...even DB2 OS/390 can do it now...it's just extremely painful...

But we did have a very good thread where we discussed how I "crossed the line" and broke the rules...

I gotta look it up...|||Here it is...

Bookmarked it...

http://www.dbforums.com/showthread.php?threadid=989508|||subqueries are useful here, as they provide for the referencing of tables.
normally in a complex update or delete i will create a query that doesnt change the data and after i recieve the correct results, i will use it as a subquery for the update\delete stmt. especially if the sarg is a dynamic value.

update t1
set c2 = x
where col3 in (select col3 from t2
where col4 = x)

however, be carefull with subqueries as they can have some definite disadvantages. specifically correlated subqueries

in addition when you join tables in an update\delete, the sql optimizer has a great deal of flexibility with the join operations where in the subquery the inner and outer queries kind of restrict the optimizers options.|||Originally posted by blindman
Really?

So in Oracle, for instance, you can't execute a statement like:

update A
set A.Column = NewValue
from A
inner join B on A.Key = B.Value

?

ANSI or not, that's pretty simple and pretty convenient too. I rarely think of Oracle, or at least I try not to.

I didn't realize that DB2 supported this form of blaspheme. I'm sure that it is great fun listening to Celko on this topic!

-PatP|||It's just so damn useful...in the (DB2) old days when it didn't, you had to either use a cursor, or genrate the satements and then execute them in a batch...|||As far back as I can remember, DB2 supported sub-queries. Sub-queries are safe to use in an UPDATE as long as they are stochastic and deterministic. I don't know when DB2 added support for JOIN operations within an UPDATE.

-PatP|||I think it was back in V5...

and whoah...

had to look that one up

http://www.hyperdictionary.com/dictionary/stochastic|||Ooops, my bad. I meant non-stochastic. Sorry.

-PatP|||Thought it was kind of like oil and water...