| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: (Fwd) Re: (Fwd/Oracle) Does NT write to random locations on d
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 BETTERon a DEFRAGMENTED disk. (geez)
I guess this one needs someone who really cares enough to actually test it.
-----Original Message-----
From: Eric D. Pierce [mailto:PierceED_at_csus.edu]
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
[via Date sent: Fri, 9 Mar 2001 18:26:32 -0500 Send reply to: Windows NT/2000 Discussion List <WINNT-L_at_PEACH.EASE.LSOFT.COM> To: Recipients of WINNT-L digests <WINNT-L_at_PEACH.EASE.LSOFT.COM> ]
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:msoultan_at_CSULB.EDU]
>Sent: Friday, March 09, 2001 12:01 PM
>To: WINNT-L_at_PEACH.EASE.LSOFT.COM
>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
><ORACLE-L_at_fatcity.com>
> > From: "Boivin, Patrice J" <BoivinP_at_mar.dfo-mpo.gc.ca>
> > 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 .
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). Received on Mon Mar 12 2001 - 15:40:20 CST
 |
 |