To begin, let’s review how DBAs have historically allocated disk space to Oracle – so that we have a baseline to compare against, and thus see how much simpler ASM makes the overall picture, which generally translates to easier setup and management. Figure 1 shows the traditional options.
Figure 1
Figure 1 shows that there were essentially two choices to be made: raw versus cooked and with or without a LVM. These pictures could further be complicated since what’s labeled a disk might in fact be a pseudo-disk. For example in an EMC disk array, disks are referred to as spindles and can be sub-divided into hyper disks. And in Linux, what we label as a disk is simply the device reference – which might just be a partition of an actual disk. To keep things manageable and thus discussable, let’s assume that a disk is not subdivided. Each disk in the diagram represents a separate physical disk drive.
The New Methods
Now let’s look at Automated Storage Management or ASM in more detail. Figure 2 shows both 9i’s Oracle Managed Files (OMF) and 10g’s ASM. Like many of Oracle’s powerful features, there were incremental steps in delivering ASM – namely 9i’s OMF, although we did not know it at the time; hence why I show these two technologies side by side.
Figure 2
In many respects, OMF was a first step at internalizing within the Oracle database engine the concept of automatic file management. However, even as just an incremental offering, it had some real usefulness. For those DBAs abstracting disk complexity away from the database (i.e. the black box extreme scenario from my introduction above), they merely had to provide Oracle with a single file destination – via the DB_CREATE_FILE_DEST parameter. That parameter value can only represent a single file system based storage location – although it could be either a single pseudo-disk representing multiple physical disks hidden behind hardware RAID or a single logical volume combining numerous physical disks. Either way, Oracle 9i automatically manages all the file system files. The main disadvantages (besides the obvious single storage location) are that it does not work with raw devices and still requires using native operating system based file systems. Even the Oracle manuals suggest that OMF is limited as follows:
· Databases that are supported by the following:
o A logical volume manager that supports striping/RAID and dynamically extensible logical volumes
o A file system that provides large, extensible files
· Low end or test databases (which I think kind of makes a statement in itself)
Now look again at Figure 2 and concentrate on ASM (right most example). There is no need for either a Logical Volume Manager or file systems. There are simply disk groups under ASM management and available for tablespace consumption. And while the file management is again automatic as with OMF, it is now 100 percent internal. There are no file systems to mount via the /etc/fstab file and no files to access using operating system file commands such as ls, cp, tar, etc. You now query the database to see all such information.
Furthermore, ASM can stripe or mirror your data at the file level – versus by disk with other methods. And Oracle automatically manages keeping everything fully mirrored or striped for you whenever disks within the disk groups are added, dropped, or fail – and all with the database completely online. Oracle accomplishes this via new and highly efficient methods that are radically different than the simple arithmetic algorithms in use by many Logical Volume Managers. Although you might make the point that there’s an additional ASM Oracle instance required, it’s actually tiny, quite easy to setup, and permits 100 percent effective, efficient and automatic storage management – and can do so for all your database instances.
ASM is the wave of the future – in fact, Oracle sources have said that 60 percent of new RAC installs utilize ASM. Thus like UNDO tablespaces making rollback segments a thing of the past, ASM may well make Oracle data files visible at the operating system level a distant memory J
Oh and by the way, Toad® with the optional DBA Module has the ability to manage ASM instances (see screen snapshot below where I’m connected to a RAC setup where the database instance= RAC1 and the ASM Instance = +ASM1).
