SQL Server 2005 - Still not upto it

Trolling before someone else does -)

http://www.eweek.com/article2/0,1759,1776048,00.asp

Oh geez. I guess a car must be a death trap if no crash test reports are
available six months before release, eh?

"rkusenet" <usenet.rk@gmail.com> wrote in message
news:39oknrF63d4tbU1@individual.net...[color=blue]
> Trolling before someone else does -)
>
> http://www.eweek.com/article2/0,1759,1776048,00.asp[/color]

Interesting article but a couple months back Infoweek carried an
article that stated that the beta version was missing the optimizer.
If I was in charge of the project I would want the otimizer beta tested
also, but just because I think all the code should be beta tested does
not mean MS's approach is wrong. It does however raise questions about
why the beta engine is claimed to be non-optimizing. It could be that
MS is having trouble getting the optimizer to work correctly, or they
could be planning to spring a surprise. In another few months we will
find out.

-- Mark D Powell --

You forgot the bit where they ask 12 unattributed individuals who say off
the record that they are seriously considering switching to Ford instead...

It of course true that we still don't know how an unreleased product runs
software that no-one uses to do anything other than generate marketing. I'll
not sleep easy tonight no sir.

--
Niall Litchfield
Oracle DBA
http://www.niall.litchfield.dial.pipex.com
"Aaron [SQL Server MVP]" <ten.xoc@dnartreb.noraa> wrote in message
news:e0r8CpYKFHA.3500@TK2MSFTNGP14.phx.gbl...[color=blue]
> Oh geez. I guess a car must be a death trap if no crash test reports are
> available six months before release, eh?
>
>
>
>
>
> "rkusenet" <usenet.rk@gmail.com> wrote in message
> news:39oknrF63d4tbU1@individual.net...[color=green]
>> Trolling before someone else does -)
>>
>> http://www.eweek.com/article2/0,1759,1776048,00.asp[/color]
>
>[/color]

> not mean MS's approach is wrong. It does however raise questions about[color=blue]
> why the beta engine is claimed to be non-optimizing. It could be that
> MS is having trouble getting the optimizer to work correctly, or they
> could be planning to spring a surprise.[/color]

Personally, I think there is some value in getting the functionality
perfected before you start optimizing performance. It's the same approach I
take with many of my development efforts. Of course, when you get down to
the final few tweaks, the impact of each can affect the other in minor ways.
But there was a large portion of completely new functionality in this
release, and I'm glad they focused on having new functions return the right
answer, rather than return the wrong answer a little bit faster.

But I agree, we will have to wait and find out. eWeek's statements that
because no TPC-C score is available now, performance in the release will
suck, are just asinine.

A

The article said ... "TPC benchmarks are one of several criteria
customers use to choose a high-end, scalable database"

Guess we can all chip in with how knowledgeable the writer is about how
the database selection process is, eh?

> Interesting article but a couple months back Infoweek carried an[color=blue]
> article that stated that the beta version was missing the optimizer.[/color]

I'd like to see that article. :-)
The execution engine cannot execute an SQL query. It needs a execution plan. The execution plan is
generated by the optimizer.

Now, the optimizer might not have been as polished at that point in time as it will be in the
released version, but that is of course the case with all parts of a product.

--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/

"Mark D Powell" <Mark.Powell@eds.com> wrote in message
news:1110919612.865818.22150@l41g2000cwc.googlegro ups.com...[color=blue]
> Interesting article but a couple months back Infoweek carried an
> article that stated that the beta version was missing the optimizer.
> If I was in charge of the project I would want the otimizer beta tested
> also, but just because I think all the code should be beta tested does
> not mean MS's approach is wrong. It does however raise questions about
> why the beta engine is claimed to be non-optimizing. It could be that
> MS is having trouble getting the optimizer to work correctly, or they
> could be planning to spring a surprise. In another few months we will
> find out.
>
> -- Mark D Powell --
>[/color]

> I'd like to see that article. :-)[color=blue]
> The execution engine cannot execute an SQL query. It needs a execution[/color]
plan. The execution plan is[color=blue]
> generated by the optimizer.[/color]

I was going to make the same comment but I think the difference between "the
optimizer" and "an optimized optimizer" might have been lost.
[color=blue]
> Now, the optimizer might not have been as polished at that point in time[/color]
as it will be in the[color=blue]
> released version, but that is of course the case with all parts of a[/color]
product.

Right, I guess most people have forgotten that we're not even at beta 3 yet.

<<Personally, I think there is some value in getting the functionality
perfected before you start optimizing performance. It's the same
approach I take with many of my development efforts. >>

This statement I disagree with. I have seen to many software projects
fail (not just RDBMS project's, but others, as well) because
performance was not designed into the application from day one.
Usually performance is directly related to application design.

I can create a Fred Flintstone car tomorrow that I move with my legs
that is totally functional, but it probably wouldn't sell too well.

Regards,

Steve

> This statement I disagree with.

That's fine. Your analogy of a Flintstone car is incorrect, however. I
wouldn't consider a car that you "drive" with your feet fully functional.
In addition, you failed to identify that it's not a one-or-the-other thing.
You do both, but fine-tuning performance (not designing for general
performance, that's always a goal when implementing the design from the
start) doesn't need to be done until you're sure the tool does what it's
supposed t.

It's just a different approach, not a right/wrong thing. Maybe the software
projects you've seen fail just didn't have the right people.

--
Please post DDL, sample data and desired results.
See http://www.aspfaq.com/5006 for info.

Aaron [SQL Server MVP] wrote:[color=blue][color=green]
>>This statement I disagree with.[/color]
>
>
> That's fine. Your analogy of a Flintstone car is incorrect, however. I
> wouldn't consider a car that you "drive" with your feet fully functional.
> In addition, you failed to identify that it's not a one-or-the-other thing.
> You do both, but fine-tuning performance (not designing for general
> performance, that's always a goal when implementing the design from the
> start) doesn't need to be done until you're sure the tool does what it's
> supposed t.
>
> It's just a different approach, not a right/wrong thing. Maybe the software
> projects you've seen fail just didn't have the right people.
>[/color]

As Stephen, I have to disagree with that you. Delivering performance within
the defined constraints (the system must be able to support X transactions
within m seconds; this transaction may not take longer than n seconds...;
the system must meet this criteria for the next y years with a growth rate g in
datavolume/transactions) is a functional requirement. Either you meet that
requirement by designing for it, or you don't. Sometimes it might be impossible
to meet some requirements (Cary Milsap has a very good example in his book
on Oracle performance) but you don't tune after the fact.

And the analogy of a flintstone car holds perfectly well. Look at your own
statement:
[color=blue]
> I wouldn't consider a car that you "drive" with your feet fully functional.[/color]

Well, who said a car has to have an engine? My four-year-old son would be
perfectly happy with the flintstone edition. Oh, well let's finetune and
add an engine. Damn, now we need something to keep the fuel in. No worries,
I can fix that....

If the requirement is that the car must reach a minimal speed you can
either let it roll down a hill crying "See? it can reach 20 MPH, I didn't know
you wanted to go uphill" or you design the car to reach that speed everytime
upfront.

My 2 eurocents
Holger

You both have missed my distinction between "designing for performance"
(which should be a given in any development effort) and "fine-tuning
performance" (which doesn't need to be a cart in front of the horse).

So go ahead and disagree with me all you like, but I don't think we're as
far apart as you're implying.

"Holger Baer" <holger.baer@science-computing.de> wrote in message
news:d19p23$rqn$1@news.BelWue.DE...[color=blue]
> Aaron [SQL Server MVP] wrote:[color=green][color=darkred]
> >>This statement I disagree with.[/color]
> >
> >
> > That's fine. Your analogy of a Flintstone car is incorrect, however. I
> > wouldn't consider a car that you "drive" with your feet fully[/color][/color]
functional.[color=blue][color=green]
> > In addition, you failed to identify that it's not a one-or-the-other[/color][/color]
thing.[color=blue][color=green]
> > You do both, but fine-tuning performance (not designing for general
> > performance, that's always a goal when implementing the design from the
> > start) doesn't need to be done until you're sure the tool does what it's
> > supposed t.
> >
> > It's just a different approach, not a right/wrong thing. Maybe the[/color][/color]
software[color=blue][color=green]
> > projects you've seen fail just didn't have the right people.
> >[/color]
>
> As Stephen, I have to disagree with that you. Delivering performance[/color]
within[color=blue]
> the defined constraints (the system must be able to support X transactions
> within m seconds; this transaction may not take longer than n seconds...;
> the system must meet this criteria for the next y years with a growth rate[/color]
g in[color=blue]
> datavolume/transactions) is a functional requirement. Either you meet that
> requirement by designing for it, or you don't. Sometimes it might be[/color]
impossible[color=blue]
> to meet some requirements (Cary Milsap has a very good example in his book
> on Oracle performance) but you don't tune after the fact.
>
> And the analogy of a flintstone car holds perfectly well. Look at your own
> statement:
>[color=green]
> > I wouldn't consider a car that you "drive" with your feet fully[/color][/color]
functional.[color=blue]
>
> Well, who said a car has to have an engine? My four-year-old son would be
> perfectly happy with the flintstone edition. Oh, well let's finetune and
> add an engine. Damn, now we need something to keep the fuel in. No[/color]
worries,[color=blue]
> I can fix that....
>
> If the requirement is that the car must reach a minimal speed you can
> either let it roll down a hill crying "See? it can reach 20 MPH, I didn't[/color]
know[color=blue]
> you wanted to go uphill" or you design the car to reach that speed[/color]
everytime[color=blue]
> upfront.
>
> My 2 eurocents
> Holger[/color]

"Holger Baer" <holger.baer@science-computing.de> wrote in message
news:d19p23$rqn$1@news.BelWue.DE...[color=blue]
> Aaron [SQL Server MVP] wrote:[color=green][color=darkred]
>>>This statement I disagree with.[/color]
>>
>>
>> That's fine. Your analogy of a Flintstone car is incorrect, however. I
>> wouldn't consider a car that you "drive" with your feet fully functional.
>> In addition, you failed to identify that it's not a one-or-the-other
>> thing.
>> You do both, but fine-tuning performance (not designing for general
>> performance, that's always a goal when implementing the design from the
>> start) doesn't need to be done until you're sure the tool does what it's
>> supposed t.
>>
>> It's just a different approach, not a right/wrong thing. Maybe the
>> software
>> projects you've seen fail just didn't have the right people.
>>[/color]
>
> As Stephen, I have to disagree with that you. Delivering performance
> within
> the defined constraints (the system must be able to support X transactions
> within m seconds; this transaction may not take longer than n seconds...;
> the system must meet this criteria for the next y years with a growth rate
> g in
> datavolume/transactions) is a functional requirement. Either you meet that
> requirement by designing for it, or you don't. Sometimes it might be
> impossible
> to meet some requirements (Cary Milsap has a very good example in his book
> on Oracle performance) but you don't tune after the fact.
>
> And the analogy of a flintstone car holds perfectly well. Look at your own
> statement:
>[color=green]
> > I wouldn't consider a car that you "drive" with your feet fully
> > functional.[/color]
>
> Well, who said a car has to have an engine? My four-year-old son would be
> perfectly happy with the flintstone edition. Oh, well let's finetune and
> add an engine. Damn, now we need something to keep the fuel in. No
> worries,
> I can fix that....
>
> If the requirement is that the car must reach a minimal speed you can
> either let it roll down a hill crying "See? it can reach 20 MPH, I didn't
> know
> you wanted to go uphill" or you design the car to reach that speed
> everytime
> upfront.
>
> My 2 eurocents
> Holger[/color]

automotive performance analogy reference: www.overhaulin.com

they make sure the chasis and drive train can handle the high-performance
engine during the spec & design phase

++ mcs

On Tue, 15 Mar 2005 15:51:38 -0500, Aaron [SQL Server MVP] wrote:

[color=blue]
> Personally, I think there is some value in getting the functionality
> perfected before you start optimizing performance. It's the same approach I[/color]

Functionality is what you sell the customer. Performance is what keeps it sold.

The former can be handled with prototype code. While I agree with Aaron's
sentiments in other fibres in this thread (about designing with
performance vs fine tuning), too often organizations simply throw the
prototype over the wall and expect THAT to be 'fine tuned'.

Further, there are a lot of people who believe that designing can be
vendor-independent, not accepting the fact that beauty (the SQL) is only
skin deep. However, the internal workings can, and do, make a huge
difference in how the design needs to be approached.

/FGB

Mark D Powell" <Mark.Powell@eds.com> wrote in message
news:1110919612.865818.22150@l41g2000cwc.googlegro ups.com...[color=blue]
> Interesting article but a couple months back Infoweek carried an
> article that stated that the beta version was missing the optimizer.[/color]
Meaning what, that there was no optimizer, in which case I'd not believe the
article.
That it was the sql 2000 optimizer, in which case I'd not believe the
article - the read-committed level wouldn't work, period.

That it was not the completed optimizer, in which case the article is
probably correct, but is stating that the beta software currently available
isn't the final product.

Like others, I'd like to see the article.

--
Niall Litchfield
Oracle DBA
http://www.niall.litchfield.dial.pipex.com

Aaron [SQL Server MVP] wrote:[color=blue]
> You both have missed my distinction between "designing for performance"
> (which should be a given in any development effort) and "fine-tuning
> performance" (which doesn't need to be a cart in front of the horse).
>
> So go ahead and disagree with me all you like, but I don't think we're as
> far apart as you're implying.
>[/color]

It's probably because I don't consider fine-tuning an developement thing:
If an application is designed and written for optimal performance, then
and only then fine-tuning may happen but, at least for database projects
this goes more in the direction of the administrators by balancing the different
pools correctly, spreading I/O etc. thus getting the most of the given
hardware.

But since most developers I've seen lately fail on the design stage, there is
not much so-called fine-tuning going on.

And if you don't mind, I'll quote your original statement:
[color=blue]
> Personally, I think there is some value in getting the functionality
> perfected before you start optimizing performance. It's the same approach I
> take with many of my development efforts.[/color]

I don't see any fine-tuning mentioned here, nor did you indicate
that design for performance was part of getting the functionality
perfected.

So I'll happily disagree with you and this will be my last post because
I just realized that we're crossposting which I don't do.

Meet me at c.d.o.s if you like.

Cheers
Holger

>> Personally, I think there is some value in getting the functionality[color=blue][color=green]
>> perfected before you start optimizing performance. It's the same approach I
>> take with many of my development efforts.[/color]
>
> I don't see any fine-tuning mentioned here,[/color]

Sorry, the word I used initially was "optimizing."

"Holger Baer" <holger.baer@science-computing.de> wrote in message
news:d1bgsk$5ci$1@news.BelWue.DE...[color=blue]
> Aaron [SQL Server MVP] wrote:[color=green]
> > You both have missed my distinction between "designing for performance"
> > (which should be a given in any development effort) and "fine-tuning
> > performance" (which doesn't need to be a cart in front of the horse).
> >
> > So go ahead and disagree with me all you like, but I don't think we're[/color][/color]
as[color=blue][color=green]
> > far apart as you're implying.
> >[/color]
>
> It's probably because I don't consider fine-tuning an developement thing:
> If an application is designed and written for optimal performance, then
> and only then fine-tuning may happen but, at least for database projects
> this goes more in the direction of the administrators by balancing the[/color]
different[color=blue]
> pools correctly, spreading I/O etc. thus getting the most of the given
> hardware.
>
> But since most developers I've seen lately fail on the design stage, there[/color]
is[color=blue]
> not much so-called fine-tuning going on.
>
> And if you don't mind, I'll quote your original statement:
>[color=green]
> > Personally, I think there is some value in getting the functionality
> > perfected before you start optimizing performance. It's the same[/color][/color]
approach I[color=blue][color=green]
> > take with many of my development efforts.[/color]
>
> I don't see any fine-tuning mentioned here, nor did you indicate
> that design for performance was part of getting the functionality
> perfected.
>
> So I'll happily disagree with you and this will be my last post because
> I just realized that we're crossposting which I don't do.
>
> Meet me at c.d.o.s if you like.
>
> Cheers
> Holger[/color]
Agree, Performance is part of the day to day job and not something you "bolt
on" later. That said, everything is a balance, but one should keep focus on
performance as a day to day part of the job.
Jim

> Agree, Performance is part of the day to day job and not something you
"bolt[color=blue]
> on" later. That said, everything is a balance, but one should keep focus[/color]
on[color=blue]
> performance as a day to day part of the job.[/color]

I give up. Clearly I do not advocate throwing performance concerns out the
window and focusing only on the features until the very last minute. I was
merely trying to point out that there are different aspects of performance
tuning... from overall, sensible design, which should go without saying in
this crowd absolutely has performance elements involved (even at whiteboard
/ paper napkin stage), all the way to fine-tuning once the functionality is
complete.

And all I was doing was hypothesizing that this is the way Microsoft is
proceeding ... that of course they have performance in mind throughout the
design phase (in fact I know that they do), but it makes little sense to
release TPC-C numbers now when the functionality isn't complete and they
haven't approached the fine-tuning side of performance.

Since everyone continues to disagree with their perception of my initial
comment rather than my explanations thereafter, I'm going to bow out and let
you all keep feeling good about yourselves. But please, go on, keep
disagreeing with your perception of what I was implying in my first
response, rather than what I've been forced to elaborate multiple times
because I can't make myself clear enough for you. Enjoy.

--
Please post DDL, sample data and desired results.
See http://www.aspfaq.com/5006 for info.

Not trying to go off a tangent, but when I think SQL*Server, I remember
the importance of semantics, as does Oracle. See my SQL*Plus session
below::

SQL> drop table t;

Table dropped.

SQL> create table t(t_pk number(11) not null primary key,name
varchar2(40));

Table created.

SQL> create or replace procedure invalid_proc
2 is
3 begin
4 insert into t(wrong_column,wrong_column_again) values (1,'Arun');
5 end;
6 /

Warning: Procedure created with compilation errors.

SQL> show errors
Errors for PROCEDURE INVALID_PROC:

LINE/COL ERROR
--------
-----------------------------------------------------------------
4/1 PL/SQL: SQL Statement ignored
4/28 PL/SQL: ORA-00904: "WRONG_COLUMN_AGAIN": invalid identifier

This behavior is expected. However, when I worked with SQL*Server a
few years ago, it wouldn't check for semantics. So, the above procedure
would actually compile in SQL*Server, and I wouldn't know this
procedure is wrong until I call it.

I posted my observation on one of Tom Kyte's useful discussions,
http://asktom.oracle.com/pls/ask/f?p...:3512483632553
, hoping someone would chime in and say "You're wrong. SQL*Server does
check for semantics". Instead, someone posted
saying this behavior still exists in SQL Server 2000.

So, optimization aside, how about an engine that can compile?

Regards,
Arun

You code adapted for SQL Server:

create table t(t_pk int not null primary key,name varchar(40));

create procedure invalid_proc AS
insert into t(wrong_column,wrong_column_again) values (1,'Arun');

Above fails with error:
Server: Msg 207, Level 16, State 1, Procedure invalid_proc, Line 2
Invalid column name 'wrong_column'.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/

"Arun Mathur" <themathurs@gmail.com> wrote in message
news:1111519291.575794.188420@f14g2000cwb.googlegr oups.com...[color=blue]
> Not trying to go off a tangent, but when I think SQL*Server, I remember
> the importance of semantics, as does Oracle. See my SQL*Plus session
> below::
>
> SQL> drop table t;
>
> Table dropped.
>
> SQL> create table t(t_pk number(11) not null primary key,name
> varchar2(40));
>
> Table created.
>
>
> SQL> create or replace procedure invalid_proc
> 2 is
> 3 begin
> 4 insert into t(wrong_column,wrong_column_again) values (1,'Arun');
> 5 end;
> 6 /
>
> Warning: Procedure created with compilation errors.
>
> SQL> show errors
> Errors for PROCEDURE INVALID_PROC:
>
> LINE/COL ERROR
> --------
> -----------------------------------------------------------------
> 4/1 PL/SQL: SQL Statement ignored
> 4/28 PL/SQL: ORA-00904: "WRONG_COLUMN_AGAIN": invalid identifier
>
> This behavior is expected. However, when I worked with SQL*Server a
> few years ago, it wouldn't check for semantics. So, the above procedure
> would actually compile in SQL*Server, and I wouldn't know this
> procedure is wrong until I call it.
>
> I posted my observation on one of Tom Kyte's useful discussions,
> http://asktom.oracle.com/pls/ask/f?p...:3512483632553
> , hoping someone would chime in and say "You're wrong. SQL*Server does
> check for semantics". Instead, someone posted
> saying this behavior still exists in SQL Server 2000.
>
> So, optimization aside, how about an engine that can compile?
>
> Regards,
> Arun
>[/color]

Thank you Tibor. I found a machine running SQL Server 2000, and was
able to reproduce the behavior you posted. I misunderstood the
checkmark button, thinking it checks both syntax and semantics when it
appears that both checks occur when the user clicks the green play
button, and not the checkmark button. At this point, the only
difference I observed is that SQL Server would not store the
invalid_proc procedure in its data dictionary, whereas Oracle will, and
mark it invalid.

Regards,
Arun

SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

re: SQL Server 2005 - Still not upto it

Similar DB2 Database bytes

/bytes/development

/bytes/it

/bytes/about