Professional Documents
Culture Documents
Administration Tips
KEY
~ 25,
SIZEOF(SEG$)
~ 50, 5 *
SIZEOF(UET$)
/*
~ 150 */ IOR I */
Page 1 of 3
29/10/2001
Administration Tips
Here we see Oracle (this happens to be a Version 9i sql.bsq, so it may have changed from previous versions) expecting each entry in the cluster to take 225 bytes thats 25 bytes for the cluster key, 50 bytes for the segment record itself, plus 30 bytes per extent entry for that segment, with an assumption that each segment will have no more than 5 extents. Now if there is only one segment per cluster block, then potentially a 4K block could house around 130 extents for that segment (25 bytes for the cluster key, 50 bytes for the segment record itself, plus 130 x 30 bytes for the extent entries in UET$. Thats 3975 bytes in total). Similar maths suggests an 8K system could store around 270 extents In a cluster block if there was only one segment to worry about. To achieve that number of extents within a cluster block, however, youd have to create a segment and allocate all its extents in one sitting, and make sure that nothing else was going on elsewhere in the database. Its therefore unlikely that you would ever be able to squeeze the theoretical maximum number of extents into a single cluster block. The precise number you could manage would depend on the exact circumstances the database encountered during the creation of various segments. Yet the design of the cluster is based around an assumption of 5 extents under whatever Oracle thinks of as typical conditions. So somewhere between 5 and 130 for a 4K system, or 5 and 270 for an 8K system, and the cluster can cope. But if the number of extents exceeds these admittedly vague values, then you'll induce chaining on the cluster. Row chaining is what happens when a single record can't fit within a single Oracle block and it means you have to perform additional I/O to retrieve the full record. Additional I/O means poorer performance. So a humungous number of extents does impact performance, not because the segment acquiring the extents gives a damn, because it doesn't, but because the data dictionary requires additional I/Os to read the relvant cluster efficiently. Now, it is true that you could manually edit sql.bsq before attempting to create a database, and thereby minimise this problem. That's a fairly risky thing to do, though, and most people don't do it, content as they are to accept defaults which Oracle has planned and designed into the system. But even if you did customise sql.bsq, there's another aspect to consider: this data about what extents a segment has is read into the Data Dictionary Cache of the Shared Pool whenever a SQL statement referencing that segment is issued against the database. The Dictionary Cache is of finite size, so Oracle has an ageing mechanism (an LRU List) to determine which segment definitions get aged out in which order. The presence in that cache of a large record from the C_FILE#_BLOCK# cluster will tend to cause space pressure in the Dictionary Cache for starters, and will, on average, cause that record to remain at the MRU end of the cache's LRU List -causing other records to be aged out unnecessarily. Basically, a large number of extents for a segment will distort the normal workings of the
29/10/2001
Page 2 of 3
Administration Tips
Data Dictionary Cache -and that will slow down performance for everyone, as their Parse phases take longer to complete. So, aiming for 1 extent is just a waste of time. But exceeding 270 extents or so (for an 8K system) is going to affect things... and the more you exceed 270, the bigger the effect is going to be (300 extents probably won't kill you, but 600 might well be noticeable). There's yet another aspect to consider: way back in Version 6 of Oracle, the maximum number of extents a segment could acquire was absolutely fixed. For a 2K system, it was impossible to acquire more than 121 extents. For a 4K system, the number was 255. And for an 8K system, the maximum was 504 extents. Although the maximum possible number of extents was made unlimited from Version 7 onwards, there were actually good reasons for the old fixed numbers. The problem is the extent map of the segment, which is contained within the segment header block for every segment. That map is consulted whenever DML is performed against a segment, and therefore being able to read it in one I/O has distinct performance advantages over having to read it in multiple I/Os. Guess what: the old hard limits were arrived at precisely because those numbers of extents could be fitted into one Oracle block (hence the reason why the maximum permitted number of extents used to depend on block size). So exceeding the old hard limits is perfectly possible, but doing so slows down DML, because the extent map for that segment now has to be read in multiple passes, not one. In conclusion, therefore, we can say that: 1 extent might be nice, but is totally unnecessary to strive for. The dictionary cluster mechanism suggests that around 5 extents under typical conditions is ideal, but that you can stretch up to possibly 270 extents (for an 8K system). But around 500 extents (again for an 8K system) should be considered an absolute maximum, because of the segment header extent map size issue.
So there is no precise right number of extents its all a bit vague. But its somewhere between 1 and a few hundred. Anything more than that, and performance trouble will be encountered.
29/10/2001
Page 3 of 3