The administration of storage for Oracle databases has come a long way and Oracle’s Automatic Storage Management (ASM) feature has done a lot to eliminate the daily hassle of watching and provisioning storage. Gone are the days of when database administrators (DBAs) had to manage thousands of Oracle database files–watching block usage, extent allocations, file placement, file size, disk capacity, and performance hot spots. It’s almost a crime when I think of the amount of time and effort it would take to maintain Oracle storage so space wasn’t wasted and there was adequate performance.
As ASM is an Oracle Database 10g/11g feature, I’m sure many of us can still remember:
- Oracle and operating system limits on the number, size, and placement for data files
- Renaming and relocating data files to alleviate performance bottlenecks on disk
- Keeping specific object type (index, data) data files, as well as redo, control, and system files separate
- Resizing data file sizes, re-organizing objects, and recreating objects to condense or coalesce space
ASM, which is basically a file system and volume manager for Oracle data files, simplifies Oracle storage management by enabling an Oracle DBA to create disk groups. These disk groups are collections of disks and managed as a single logical unit by ASM–eliminating the need for DBAs to manage the large number of separate data files typically seen within an Oracle database. With a small number of disk groups, usually only two or three, Oracle takes control of the automatic creation, allocation, and placement of data files when created for various storage structures in Oracle. For instance, a simple CREATE TABLESPACE <tablespacename> statement will instruct ASM to handle data file creation within the default disk group.
Behind the scenes, once Oracle takes control of data file creation, allocation, and placement, Oracle will spread data files evenly across all disks in the disk group to deliver improved performance–freeing up the DBA from the mundane task of manually moving data files around to improve I/O response. It’s easy to see how ASM simplifies and helps DBAs manage dynamic database environments.
Unfortunately DBAs must still watch and then perform the task of adding and removing disks to an ASM disk group when needed. This leads back to the problem of DBAs under allocating, and worse yet, over allocating disk storage, just to be safe which recreates the problem of wasted space and leads to higher than needed storage costs.
This is where thin provisioning comes into play. Thin provisioning will automatically allocate on a just-enough and just-in-time basis which relieves the DBA from both having to watch and then add or remove disk to a disk group. For instance, Oracle’s ASM and 3PAR’s Thin Provisioning could be combined to offer a complete, end-to-end, storage solution. Oracle’s ASM feature would create, allocate, place, and rebalance data files for performance and 3PAR’s Thin Provisioning would dedicate disk space on the fly and only when needed.
Storage management has always been the bane of Oracle DBAs. We have come a long way with the help of Oracle’s ASM feature but can extend ASM to become a complete end-to-end storage solution with the addition of thin provisioning. With 3PAR’s Thin Provisioning, DBAs can now provision once and only pay for what they use and when they use it–eliminating the tedious, manual, and error prone tasks associated with database storage management.