Is there anyway to check that the extents are contiguous ?
-Original Message-
[mailto:[EMAIL PROTECTED]]
Sent: February 28, 2002 2:48 AM
To: Multiple recipients of list ORACLE-L
If you have only 1 Table in that Tablespace and only 1 File on that disk,
even if you had multiple
rem
rem file: mapper.sql
rem location: $HOME/sql
rem parameters: the tablespace name being mapped
rem
rem Sample invocation:
rem @mapper SYSTEM
rem
rem This script generates a mapping of the space usage
rem (free space vs used) in a tablespace. It graphically
rem shows segment and free space
If you have only 1 Table in that Tablespace and only 1 File on that disk,
even if you had multiple extents, you might expect them to be contiguous.
Then, the only issue would be that the extent size should be a proper
multiple
of db_block_size*db_file_multiblock_read_count (or max_io_size).
Your best best is to quantify this mathematically. Take the following
example:
Case 1: 100GB table, one extent
Case 2: 100GB table, 1000 extents
Assume:
a) track to track seeks are 'free'
b) random seeks are 20ms
c) Block size is 16KB
d) db_file_multiblock_read_count=16
e)
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
Unknown address, This address isn't in our system. This person is not
employed here anymore, or has never been employed here. Please remove this
address from your address
book...
Have A Nice Day
Gerald T. Bray
Email Administrator
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
Bill,
It sounds like you are describing an ideal situation. Is this scan being
done by only one user at a time? Then you are describing a dedicated
database to one user?
Lets face it, the above is not even remotely probable in todays world. And
furthur, if you decided that the above setup is
Bill,
I believe in that case your query will spend most time on data transfer and the
percent of seeking
time will be tiny provided that number of extents is reasonable. One thing to note:
sizes of extents
should be multiple of db_file_multiblock_read_count in order to minimize number of I/O
Bill,
I believe in that case your query will spend most time on data transfer and the
percent of seeking
time will be tiny provided that number of extents is reasonable. One thing to note:
sizes of extents
should be multiple of db_file_multiblock_read_count in order to minimize number of I/O
Thanks to everyone for their comments on this. You've convinced me. I'll
go away and worry about something else instead now!
- Bill.
At 04:43 27/02/02 -0800, you wrote:
I know this one has been done to death: use uniform extents to avoid
fragmentation; multiple extents don't hurt
11 matches
Mail list logo
