RE: Oracle Book Mal-practice...

From: Bobak, Mark <>
Date: Tue, 26 May 2009 10:07:06 -0400
Message-ID: <>

But Peter, if it's fast now, after no reorg for two years, just think how much faster your application would go if you re-instituted index reorgs! :-)

-----Original Message-----
From: [] On Behalf Of Schauss, R. Peter (IT Solutions) Sent: Friday, May 22, 2009 4:07 PM
To: Oracle L
Subject: RE: Oracle Book Mal-practice...

FWIW, I have a heavily used 36gb SQL Server database on which I quietly stopped reorganizing the indexes more than two years ago. I have had no performance complaints on this database which could be traced back to the database. If you read the SQL Server list on Lazy DBA everyone recommends periodic reorganizing of indexes.

  • Peter Schauss

-----Original Message-----
[] On Behalf Of Robert Freeman Sent: Friday, May 22, 2009 3:21 PM
To:; Oracle L Subject: Re: Oracle Book Mal-practice...

Interesting thoughts on SQL Server... I'm starting a bit of a surface self-education on SQL Server. It's interesting how I'm hearing things about it that sound so similar to the Oracle 7 days....Give 'em 10 more years and maybe the "expert" maturity will be such that they will have the same "Old" days discussions that we do.



 Robert G. Freeman
Oracle ACE
OCP: Oracle Database 11g Administrator Certified Professional Study Guide (Sybex) Oracle Database 11g New Features (Oracle Press) Portable DBA: Oracle (Oracle Press) Oracle Database 10g New Features (Oracle Press) Oracle9i RMAN Backup and Recovery (Oracle Press) Oracle9i New Features (Oracle Press) Other various titles out of print now... Blog: The LDS Church is looking for DBA's. You do have to be a Church member in good standing. A lot of kind people write me, concerned I may be breaking the law by saying you have to be a Church member. It's legal I promise! :-)

  • Original Message ---- From: Rich Jesse <> To: Oracle L <> Sent: Friday, May 22, 2009 12:42:42 PM Subject: RE: Oracle Book Mal-practice...

In a way, the "malpractice" in those kinds of books helps me, at least for
Oracle, which I've worked with for 12+ years now. Like the idea of rebuilding indexes, which came up recently. I believe from past experience
and research that b-tree index rebuilding in Oracle is usually unnecessary.
But when tasked with "It'll save space, so why not?", I chose to bolster my
belief using other trusted sources (this list's and Tom Kyte's many postings
among them) and use this information to back my assertion. The "malpractice" of index rebuilding refreshed my understanding of Oracle's b-tree indexes. This is a good thing for me as a "solo" DBA.

OTOH, my <2yrs experience with SQueaL Server is leading me to find all sorts
of questionable information as to how to properly maintain that fine excuse
for an enterprise database. For example, based on information given on several websites (including documentation), it seems that SS suffers from
some sort of entropy where time and data contribute to poor performance, index page corruption, and fragmentation within the table structure causing
disk thrashing, but all only if indexes are not regularly rebuilt or at least reorg'd. Really? Can someone show me how these theorems were proven?

The difference between these is that I consider myself to be a Sr-level in
Oracle and only a Jr in SS land. But that doesn't mean I should blindly accept any and all advice given for either. It just makes it more difficult
to catch all of the BS as a Jr. And I've missed a few well-flung pieces so

My $.02,

Disclaimer: I like Fridays.

> The next version of the book should indicate that table and index data
> separated onto different solid state drives or ram modules when in
memory :)
> Seriously these conversations give me such a headache, and usually I
am able
> to point to the source being out of date, like a website that hasn't
> updated since 1997. But this is made even more difficult with current
> sources (books/site/articles etc.) perpetuating these myths.
> On the other hand if everyone learned the proper way to design,
> test, tune and run their systems, the best dba's/developers among us
> be common and our rate/salaries would reflect that.



Received on Tue May 26 2009 - 09:07:06 CDT

Original text of this message