Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Microsoft destroys TPC-C records!

Re: Microsoft destroys TPC-C records!

From: Nuno Souto <nsouto_at_nsw.bigpond.net.au.nospam>
Date: 2000/04/05
Message-ID: <38eb200b.10535763@news-server>#1/1

On Tue, 04 Apr 2000 15:54:31 GMT, jahorsch_at_my-deja.com wrote:

>
>Dont go bashing a DBMS until you have used it.

I make mine your words. Half the interventions here are from people who have never bothered reading more than the MS-market pamphlets about ORACLE.

>Your remarks on
>devices, page size, etc clearly shows that you have not used it.

I think if you go back a few messages, you will see my CLEAR statement that I have not used the latest version. And I don't intend to in the near future. Unless you haven't noticed yet, people make lifelong investments in learning RDBMS's in depth. Not 18 months.

>Devices are gone they are only there for backward compatibiliy. There
>are now files and filegroups very similiar to tablespaces.

About frigin' bloody time! They finally woke up. Pity it took so long.

>flexible. With the horsepower that is available today most projects do
>not need to be so flexible. You do not need to tweak it as much to get
>it functioning to where your clients want it.

And here lies one of the greatest fallacies of this entire industry:

"don't worry about the design/coding/efficiency, the hardware speed will make it unnecessary"

Been hearing it since the old days of Assembler on the 360. Nothing could be more wrong.

The amount of complexity, functionality and volume required by the clients has been growing MUCH FASTER than the hardware capacity has grown. If you don't pay attention to the above issues, you can throw as many Cray's as you want at it, it will just suck them up and still not run well.

> As for as fixed blocks
>It doesnt matter since it is tied to NT. They obviously picked an
>optimal value.

Only if you format your NT partitions at 8K cluster size. And yes, it does indeed matter.

>I had heard that chaining was built into the engine but
>not implemented. I for one do not like chaining and think that 8K is
>plenty big enough for a rowsize.

Agreed. Sometimes too big. I'd rather be able to tune it for what I want. Rather than have to tune my design around a limitation of the engine.

>propritary? MS is very propritary. Thats a bad thing yes but it also
>promotes tight integration.

So did the Mac. And everybody dumped it when they started the story of "either you write and design as we do or you don't run". Same with the mainframes. MS is going exactly the same way. BTW, you think the story of MS is of tight integration? I seem to recall a little thing called VBA, that was announced as the great "unifier" and 4 years later is still all over the place...

>fat on the client side. Lock escalation is a good thing most of the
>time.

No it isn't. It's the worse thing you can do to a multi-user, multi-application RDBMS that is supposed to deliver predictable performance.

>You can control the locking if you need to but the engine
>usually will do the best thing.

No it won't. Plenty of real life examples out there when Ingres did it. Never worked. Never will.

Cheers
Nuno Souto
nsouto_at_nsw.bigpond.net.au.nospam
http://www.users.bigpond.net.au/the_Den/index.html Received on Wed Apr 05 2000 - 00:00:00 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US