Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Old Chestnut: Tablespace Fragmentation
Bill - My Tech. Service Manager keeps reminding me that "disk isn't so
simple anymore". You are probably on RAID for the higher read performance.
Now your file is broken across several disks. Of course, to get the straight
read, the controller can't service anyone else's requests while your scan
continues uninterrupted. Just some other thoughts.
By the way, yesterday I was able to reduce the full-table scan time
on our data warehouse from over 2 minutes to below 10 seconds. I broke the
table into 54 partitions so the most common queries were able to scan just
the minimum amount of the table they need.
Dennis Williams
DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com
-----Original Message-----
Sent: Wednesday, February 27, 2002 9:04 AM
To: Multiple recipients of list ORACLE-L
IMHO, yes you're right, but the little bit of extra disk head movement is going to be insignificant because of the overall size of the transaction. In a perfect world, no tables would ever be fragmented. But the trade off is in maintenance. You're going to go through alot of work to keep your one large table always contiguous, keep your data files always contiguous to shave a few millseconds off a long transaction.
Beth
-----Original Message-----
Sent: Wednesday, February 27, 2002 7:43 AM
To: Multiple recipients of list ORACLE-L
I know this one has been done to death: use uniform extents to avoid fragmentation; multiple extents don't hurt (within limits).
But what if:
Data Warehouse, one big table on a single disk, full table (batch) scan,
no
concurrent transactions on the database (so no contention for the disk),
no
fragmentation at the file system level, initially empty buffer cache
(startup), read-only operation so DBWR isn't doing anything on this
disk. Basically I want to read one data file from end to end. Surely
it
would make sense to have the disk read moving smoothly from one end of
the
disk to the other rather than bouncing about all over the place as it
may
do with multiple extents "randomly" allocated.
Any thoughts?
Thanks
- Bill.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Bill Buchan
INET: wbuchan_at_uk.intasys.com
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).
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).
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 Wed Feb 27 2002 - 09:53:31 CST
![]() |
![]() |