EP,
I don't see the logic in the last post: "You can't have fast and best."
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.
Second, it's confusing: why is "fast" set against "best" as though the one
is somehow the enemy of the other? Huh?
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....)
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?"
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?
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)
I guess this one needs someone who really cares enough to actually test it.
- Ross
-----Original Message-----
From: Eric D. Pierce [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 12, 2001 3:37 PM
To: Multiple recipients of list ORACLE-L
Subject: (Fwd) Re: (Fwd/Oracle) Does NT write to random locations on di
Dick & folks,
"the plot thickens" (or something) .... see below for comments
from some of the NT listserv folks...
side note: clearly Oracle's internal NT development groups(s)
have considerable knowledge of NT's file system, and they
would presumably have a good idea of how to approach this
issue. Why that knowledge isn't easily propagated out to/through
Oracle Tech Support seems mysterious/weird.
regards,
ep
------- Forwarded message follows -------
Date sent: Fri, 9 Mar 2001 13:35:33 -0800
[via Date sent: Fri, 9 Mar 2001 18:26:32 -0500
Send reply to: Windows NT/2000 Discussion List <[EMAIL PROTECTED]>
To: Recipients of WINNT-L digests <[EMAIL PROTECTED]> ]
The OS does decide where to put files based on its own algorythms.
This is a big secret with NT (it is part of their "Intelligence")
All OSes have some form of system for writing data optimally to a
disk or drive array. They may give you bits and pieces of how it
works, but the details will remain MS confidential.
There are a couple of industry wide accepted examples with no
heuristics or intelligence built in.
Generally there is a big tradeoff in optimizing writes and reads on a
hard disk. The more time which is spent in figuring out where
something goes, the slower disk access is. Do you want a fast hard
disk array with lots of fragments, or a slow disk array with minimal
fragments? The choice is yours, you can't have both fast and best.
Eric
-----Original Message-----
Sent: Friday, March 09, 2001 1:19 PM
To: Levinson, Eric
Until a few days ago I would have agreed entirely with what you've
said. However, about a week or so back, I ran into a problem with a disk
that was so badly fragmented that Drive Image couldn't create an image of
it. I ran Diskkeeper on the drive, in fact several passes. At least 3 of
them were after I removed ~ half of the files, so that I had around 4Gb
free on this 8Gb drive. The fragmentation improved only very
slightly. Several files had in excess of 100 fragments. Since I was
preparing for a machine upgrade anyway, I copied all the files off to
another location, formatted the drive, then restored the files via
xcopy. Much to my surprise, while the fragmentation was much less, I had
several large files that still were badly fragmented. In fact the worst
offender was a 100Mb file which still consisted of 123 fragments. I'm not
attempting to disprove your thinking here, but I'm curious if you have any
thoughts on possible reasons for this anomaly?
At 12:16 PM 3/9/2001 -0800, you wrote:
>Yes, file fragmentation is a big issue for products that run out of the OS.
>Oracle is kind of an exception, meaning the files it creates it manages.
>Yes, your database files may be fragmented, but it probably doesn't affect
>your database speed as much as tablespace fragmentation would, so I would
>just ignore it. Oracle manages how the database files are used pretty
>efficiently, even if they are fragmented.
>
>If you REALLY wanted to defragment your database files, there is a really
>easy way. Most online defrag utilities (like diskkeeper) simply copies the
>file to another location on the disk, hoping it will reduce the number of
>fragments. On a nearly full disk it will _increase_ the number of
>fragments, so this won't work.
>
>Best thing would be to back up all your database files to tape a few times.
>
>Delete all the database files from your disks. Also REMOVE all non
>essential files like the contents of your temp directory, IE cache, etc.
>
>Defrag your hard disk (if the option is available in your defragger, choose
>"Free Space Defragmentation")
>
>Restore your database files to your hard disk. These files should be
>written to your hard disk in a contiguous fashion by default, if you have a
>hunk of open space on your drives.
>
>Another option would be to use a Raw file system for Oracle. I am not sure
>if they support this on NT, I know Oracle supports this on Sun, basically
>you don't put a file system on the drive. You give to Oracle partitions,
>and it manages everything.
>
>Hope this helps!
>Eric
>
>
>-----Original Message-----
>From: Mike Soultanian [mailto:[EMAIL PROTECTED]]
>Sent: Friday, March 09, 2001 12:01 PM
>To: [EMAIL PROTECTED]
>Subject: Re: (Fwd/Oracle) Does NT write to random locations on disk?
>
>
>I don't know the answer to your question, but if you didn't already
>know, there is diskeeper for NT. Plus, they have a frag guard thing
>that will defrag on the fly, or something like that. I haven't tried
>it, I just get their newsletter all the time :)
>
>Later,
>mike
>
>"Eric D. Pierce" wrote:
> >
> > ------- Forwarded message follows -------
> > Date sent: Fri, 09 Mar 2001 11:00:31 -0800
> > To: Multiple recipients of list ORACLE-L
><[EMAIL PROTECTED]>
> > From: "Boivin, Patrice J" <[EMAIL PROTECTED]>
> > Subject: Does NT write to random locations on disk?
> >
> > Using a little utility called contig I noticed that the Oracle 8.1.6
> > datafiles on my test NT server are quite fragmented, an average of 177
> > fragments per file, 118 fragments for the OEM repository datafile. The
>poor
> > utility couldn't do anything with the database files, they are too large
> > perhaps.
> >
> > These were created on an empty server, 8i release 2 went on it after a
> > defrag, then the OEM. This is on a hard disk with 1.2G of free space,
>none
> > of the datafiles come close to that.
> >
> > Why so many fragments? Oracle created those files in one pass, does NT
> > write randomly to disk or what?
> >
> > Won't this have an impact on my NT database's performance?
> >
> > Oracle says tablespace fragmentation is not a big deal, but
fragmentation
>at
> > the OS level matters. Supposedly that's why NT and WndowsXX came with
> > defragmentation tools.
> >
> > ???
> >
> > Is there a registry setting somewhere to tell NT to write contiguously
to
> > disk?
...
>
>--------------------------------------------------------------------------
>The WINNT-L list is hosted on a Windows NT(TM) machine running L-Soft
>international's LISTSERV(R) software. For subscription/signoff info
>and archives, see http://peach.ease.lsoft.com/archives/winnt-l.html .
----------------------------------------
Good, Fast, Cheap... Pick any two
----------------------------------------
------- End of forwarded message -------
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Eric D. Pierce
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
