RE: (Fwd) Re: (Fwd/Oracle) Does NT write to random locations on d

Eric, you are a scholar and a gentleman, thanks for your response. Thanks for the final clarifications. I agree the tape/delete/rewrite scenario is extreme.... as far as defragging, i've seen just great performance out of NT afterwards, but, I am not a "power user" and have never done os-level defragging of dbfs on ntfs...

Ross

-----Original Message-----
From: Eric D. Pierce [mailto:PierceED_at_csus.edu] Sent: Monday, March 12, 2001 6:10 PM
To: Multiple recipients of list ORACLE-L Subject: RE: (Fwd) Re: (Fwd/Oracle) Does NT write to random locations on d

On 12 Mar 2001, at 13:17, Mohan, Ross scribbled with alacrity and cogency:

Date sent:              Mon, 12 Mar 2001 13:17:18 -0800 To:                     Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>

> I don't see the logic in the last post: "You can't have fast and best."

Dude,

thanks for the feedback.

My interpretation (not that I know the "right" answer, or agree with him completely):

fast = fragmented (especially for writes?) best = completely non-fragmented (perhaps "theoretically" better        for non-random reads)

>
> First, he doesn't define terms. "Fast"?  Is that peak I/O? Streaming I/O?
> Single block read? Seek time? Write time? Come on, trying to reduce this
> to an undifferentiated "fast" or "slow" verges on the useless unless one
> takes the effort to provide an EXPLICITLY CITED METRIC for speed. And this
> fellow didn't.

agreed. the comments were a bit glib.

the good news is that they were free. :)

>
> Second, it's confusing: why is "fast" set against "best" as though the one
> is somehow the enemy of the other? Huh?

well, er..    uh.....

I think all he was trying to state, oversimplified, was that, generally, there might be tradeoffs between arriving at a nirvana of defragmentation and disk performance (DUH!).

>
> Third, it leaves out any discussion of the effect of on-disk and
> on-controller
> cache. (Not to mention system-level cache.)  As far as the application is
> concerned, it does not see the "disk" alone....it sees controller and disk
> cache and disk as an amalgam, performance-wise....)

Indeed. eg, Netware3 has no need (and as far as I know, no user controlled mechanism) for disk defragmentation. Oversimplifying, the Netware3 OS is basically a giant cache system, so even if you have relatively "dumb" I/O hardware, it is fairly fast.

eg, copying a large (100+ MB) file on-disk w/ Netware3 is fairly efficient. However, it is notoriously easy to bring Netware3 to its knees by doing the same exact file "copy" over-the-wire (on the network).

>
> Fourth, since WHEN did the choice become forced into "Do you want a fast
> hard
> disk array with lots of fragments, or a slow disk array with minimal
> fragments?"

My guess is that he was trying to say that in general, there is a break even point where disk defragging methods in the OS can become counterproductive ("fancy writes" slow down reads?). Still guessing, this "conventional wisdom" is probably more likely to have some veracity with reference to an "average" file server system (lots of small files), as opposed to a db server (fewer large files).

> Geez, can I have a slow disk array with lots of fragments?
>
> The only statement I agree with, either logically or from experience is the
> bit
> about OS vendors keeping a bit secret from the world on their...well,
> "secret sauce".
> Sure, you can keep a little bit secret, but come on, folks, it's not like MS
> has
> any other/better/special MoJo than any other vendor. What? when the aliens
> landed
> on the Redmond campus and revealed their special VASTLY SUPERIOR alien OS
> technology,
> no one else noticed?

Agreed. At least I've never heard that any MS/windows file system is "state of the art".

As I've said before, most of the basis of most computer technology ultimately goes WAY back to various research institutes, some private sector, but also much public sponsored "basic science" research at DOD, the space program, and so forth.

>
> The fact is, data access through a system is.....data access through a
> system. The
> *whole* system -- including caches -- counts. And, logic will tell you that
> long-stride
> streaming I/O ( think Oracle Video Server, e.g. ) will work FASTER and
> therefore BETTER
> on a DEFRAGMENTED disk. (geez)

well... that seems like a classic example of optimizing "reads".

>
> I guess this one needs someone who really cares enough to actually test it.

I guess we should feel lucky that Oracle is saving billions of $, and therefore "only" increasing prices by 50% to 100% to cover the drop in stocks. Now that I think about it in a more clear light, it does seem ridiculous to insist that they actually do some work to help customers figure out how to use the stuff best? :)

I'll forward an additional list of related URLs I'm trying to go through. From what I've seen so far, there isn't going to be any explicit answer, although the material sems to reinforce what I take to be the "conventional wisdom" that NT disk systems require fairly frequent user-initiated defragging. (one does have to wonder if the authors of some of the material might have connections with the defragging vendors.)

regards,
ep

ps, did you like the idea that one of the NT folks had of deleting the db files after doing a tape backup, defragging the "system", then restoring the db files in order to get rid of defragmentation in the db files? seemed a bit extreme to me.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Eric D. Pierce
  INET: PierceED_at_csus.edu


Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).