ASM Extents

Every ASM disk is divided into allocation units (au). ASM files are stored as extents and an extent consists of one or more allocation unit, though it was only 11g that brought in variable sized extents. The ASM instance provides the RDBMS instance with an extent map that the RDBMS instance then uses when doing I/O.

The diagram above is meant to show the extents of a pair of ASM files distributed amongst the available drives in a disk group. Essentially this is the algorithm that ASM uses to maximise the I/O performance - spread all data across the disks in a disk group.

When you create a disk group in 11g you can specify the size of the allocation unit to be from 1MB to 64MB, the size doubling between these limits. That is you can set the size of the au for a disk group to be one of 1, 2, 4, 8, 16, 32, or 64MB.

Clearly the larger the au size chosen the less the number of extents it will take to map a file of a given size. The larger au are clearly beneficial for large data files and cuts down on SGA required to track. Each individual extent resides on a single disk.

Extents can vary in size from 1 au to 8 au to 64 au. The number of au a given extent will use is dependent on the number of extents allocated and the extent size increases at a threshold of 20,000 extents to 8 and then again at 40,000 extents to 64. Again this is designed to be beneficial to larger data files, requiring less extents to be tracked.

You can see how the extents are allocated between disks in a disk group by looking at the X$KFFXP view:


SQL> select count(*), group_kffxp, disk_kffxp
from X$KFFXP
group by group_kffxp, disk_kffxp
order by group_kffxp;


This will show you how many au have been allocated to each disk, if you have a healthy balanced system each disk in a disk group should have a similar number of au.

A very useful script for looking at all this is available on metalink, look for Note: 351117.1, diagnosing ASM space issues, well worth having a look at.

Some thoughts on the April CPU

Ok, so everyone and their granny knows that the latest and greatest Critical Patch Update has appeared. But there are a couple of things that might be missed.

First, I took out a documentation bug, bug number 6764071, on the last CPU. This was because Oracle stated at one point users in a RAC system could access the system while the post-install procedures were being executed, but the post-install instructions state quite clearly that you need a startup upgrade even in a RAC environment - hence no access to the system. I’ve already blogged about this, but a few days ago Oracle confirmed that the doc bug had been amended.

Of course Oracle make the same document bug from January in the new April CPU:

I got the feedback on the 14th, so it seems it will be included in the next CPU patch. The sentence will be changed to:
“Users can continue to access the database during the post-installation steps, except during the one-
time view recompilation.”

The second point is that the fixes introduced in the April CPU are actually included in the 10.2.0.4 patchset, metalink Note:552248.1 states the following:

1.3 Database 10.2.0.4 Patch Set

The Database 10.2.0.4 Patch Set includes the CPUApr2008 content.

I find this quite interesting on two levels, first if you need to do testing for the CPU, maybe you are as well as just doing the testing for the patchset instead, and just jumping right to 10.2.0.4 (if your apps can live with it). Secondly, is it a bit worrying that the 10.2.0.4 patchset has been available for 1 month now, but Oracle only now let on that there are these critical vulnerabilities and they have been fixed for this length of time.

Is that really good security? Yes, I know it’s all about the quarterly cycle, but is it not more important giving customers as much information as possible?

Also, it is almost like the left hand does not know what the right hand is doing, because if you look at the metalink document 10.2.0.4 Patch Set - List of Bug Fixes by Problem Type, you will see the January CPU mentioned right at the top in a section about Security Alerts Issues fixed, but there is no mention of the April CPU - but surely they must have known this when they were making the patchset!

I’m sure the instructions for the April CPU are gospel and that you will be protected if you upgrade to 10.2.0.4, but it hardly gives you a warm glow of confidence, does it now?

Hello world!

This is intended as repository of things I should know about Oracle but have only just found out.