Oracle Automatic Storage Management (ASM) is essentially an Oracle-managed file system which manages all database data files, redo logs, control files, backup sets – essentially everything except for the Oracle software and configuration files. It is commonly used in RAC environments, but it is also relevant (and Oracle's recommendation) for single instance databases. ASM files are not visible at the o/s level although the underlying devices are. Oracle provides a CLI (
asmcmd) that provides limited visibility and functionality to the ASM files.
Over a database's normal course of operations, data files may be dropped or resized, tables truncated, archived redo logs deleted and so forth. A file system on thin provisioned volume (e.g. EXT4 mounted with the DISCARD flag) will recognize when space becomes unused through these operations, and issue trim commands to UNMAP the unused space. But ASM, on the other hand, does not issue trim commands. As a result, even though space may appear to be available from Oracle's point of view, it is not available from the storage's point of view:
Oracle considers ASM disk group FRA to be using 99 GB of storage, with 401 GB free:
However, the storage array sees over 200 GB in use
The Pure Storage array considers zeros to be free space. So, short of issuing a TRIM command, which ASM does not do, overwriting the unused space with zeros will enable the array to return the space back to the unused pool. It turns out that Oracle and 3Par developed a tool in 2010 that performs this operation. It's called ASRU (ASM Space Reclamation Utility), and it's basically a Perl script and a couple of shell scripts. (asru.zip)
Specifically, ASRU performs these steps:
- resize (shrink) the ASM disk group disks to the actual utilized size, plus some buffer (ALTER DISKGROUP foo RESIZE ALL SIZE bar)
- writes zeros to the portion of the volume not claimed by resized disk group
- resizes the disk group volumes back to their originally allocated size.
We ran the ASRU utility FRA described above.
Screen output: (note that it took approximately 22 minutes to write 404 GB)
Afterward, the storage and the database are in closer (though not exact) agreement with the space utilization.
According to the storage array
According to Oracle (same as before the ASRU operation):