Space reclamation is the ability to reclaim disk space back to the storage pool after data has been removed from a server(s). For example, if I created a 100GB LUN and mapped it to a server, then I loaded 50GB of data onto that LUN. Essentially, I have taken up 50GB worth of disk space from my storage pool. Now let say that I deleted that 50GB of data, without space reclamation, that 50GB of space is still taken from my storage pool. Yes, that 50GB is still available on that server for future use but nowhere else. If I want to allocate that 50GB to another server, I cannot do so without space reclamation. If that is what you preferred, then may as well use JBOD instead of an intelligent SAN.
Ever wonder what happens to disk space when you hit that ‘Delete’ store procedure on a tablespace or a database? Does the space occupied get freed up automatically so the next set of data can use it? The answer is it depends! How so you might ask – let’s find out!
I remember back in 2004, Oracle came out with a tool (ASRU) to reclaim space in Oracle ASM. As a matter of fact, Oracle and 3PAR teamed together to extend storage efficiency for Oracle database environments.
Keep in mind that space reclamation has a pre-requisite on the storage array side, and that is thin provisioning. Here is an excerpt from Oracle ASRU white paper with a very good explanation on the benefits on thin provisioning, and why space reclamation is a good thing:
“Thin provisioning is a feature common to many storage arrays. Thin provisioning offers a different approach for provisioning storage where the storage array allocates capacity to the thin provisioned storage volume as application writes data over time, not upfront at time of storage volume creation. This approach is justified because for most enterprises, since written storage utilization for most applications operates between 20 and 45 percent. With Thin provisioning, written storage utilization can be increased to near 100 percent. As a result, IT users can significantly reduce the storage capacity that is required to support their Oracle databases. Oracle has actively supported storage vendors’ thin provisioning feature in conjunction with a database feature known as “autoextend.” Autoextend enables a file’s size used for tablespace to grow when applications add new data to database tables.
Oracle is introducing new capability to ASM for extending support of thin provisioning. Previously, space inside a storage array supporting thin provisioning could only grow as a tablespace became larger. If a tablespace shrunk or even if an entire database were removed from an ASM disk group, space that had previously been allocated inside the array could not be freed for allocation to a different application. This new capability takes the form of an administrative ASM command that enables a storage array to detect unused space after it is freed by ASM and return that space to an unallocated status inside the storage array.”
Below is the link to the Oracle ASRU white paper in case you want to learn the inner workings of Oracle DB space deallocation http://www.oracle.com/technetwork/database/oracle-automatic-storage-management-132797.pdf
Given the benefits of thin provisioning, Nimble Storage supports it natively on all volume allocations by default. Now what about space reclamation for Oracle DB running on ASM? You bet! Here is proof along with instructions on how to go about validating it:
Simple steps taken to validate:
- Provision a thin provisioned volume to DB server
- Create a diskgroup on the thin provisioned volume
- Create a tablespace on the diskgroup
- Bulk insert data into the tablespace
- Check space usage/free on ASM AND Nimble volume
- Drop the tablespace
- Reclaim space using ASRU – This is for Oracle ASM
- Enjoy newly reclaimed free space J
Detail steps with supporting diagrams:
- - Created a thin provisioned LUN and mapped to a database server.
- - Created a diskgroup named “TESTDG”.
- - Created a tablespace named “TESTTS”
- - Inserted 58,000,000 records in a table
- - Checked the tablespace size
- - Checked the diskgroup size
- - Checked the physical LUN size with compression
The reason you see that only 4GB used on the LUN vs. 22GB on the diskgroup is because of compression on the Nimble Storage.
- - Here is the physical LUN size without compression
- - Drop tablespace TESTTS
- - Checked ASM diskgroup size after drop
Noticed the diskgroup size is freed up but the physical LUN size is not. Also the used disk space increased a tiny bit because of compression without data. When the tablespace was deleted, the Oracle ASM extents no longer contain data.
With compression after tablespace was deleted
Without compression after the tablespace was deleted
- - Executed the ASRU command
- - After the ASRU operation completed, the physical LUN space is freed up.
Not only can I reclaim space on the physical LUN but I got very good compression rate on the LUN too. Take a look at the TESTDG diskgroup space usage after I loaded 58,000,000 records in a table. The TESTDG diskgroup took up 22GB of space while the physical LUN showed only 4GB was taken. Now, how is that for storage efficiency?