ASM & Thin Provisioning Scenario

I also found Paul's response very good. Here are my comments:

"Assumption: Because I created a new ASM data disk group, the contents of the data disk group are automatically reclaimable since I did not create a DB and add data files. So except for the small amount of meta-data at the start of the ASM disk group the rest are continuous zeros which allows for space to be reclaimed, correct?"

[YD]  You forgot to mention a critical piece of information: were the thin luns fully allocated or not? If the thin luns are fully allocated it means that their capacity if consumed in the thin pool and the discussion about reclamation is applicable. If the thin luns were not pre-allocated, only written data is being allocated at the pool at a chunk granularity (768KB). In your scenario, prior to creating the database, there is hardly any capacity consumed in the thin pool yet. Nothing really to reclaim... (although it is true that if you try to read from that space you'll get 'zeros' returned).

Let's say that the LUNs are 100% pre-allocated (their full capacity is consumed in the thin pool). Now, in your scenario it is possible to reclaim that space, since it is consumed, but mostly empty! At this time either ASRU or storage zero space reclamation utility can be used, but hold on for a second, why were these LUNs fully allocated from the first place? wasn't it so their space is spoken for and will therefore never run out of space in the pool? Unless someone has changed their mind about the allocation strategy it will not make a lot of sense to reclaim the space that was pre-allocated on purpose (although possible).

Goal: In using virtual provisioning and thin LUNs as a DBA I want to be able to allocate more disk space than is physically available. To that end the database will be configured with minimum free space and use the auto-extend to dynamically grow as needed. In this scenario there should be no need for ASRU or the symmetric zero space reclamation functionality unless the assumption is incorrect and the ASM disk group is not continuous zeros.

[YD] Like Paul said ASRU is for reclamation, not for allocation. In this example the goal is to develop a strategy for storage capacity allocation that is based on short term needs, and adjust it over time, such as not all the storage needs to be purchased up-front, and consumed, though may never be fully used (if the application never fill up the capacity expectation it started with).

In that case the safest approach will be to provision the thin pool with enough capacity for the 'short-term' needs (whichever they are, say 6 month or a year), create the Thin LUNs large enough to either fit long term expectations, or at least such as not too many changes from the host will need to take place (change control in production systems is always strict). The important part here is that we only pre-allocate the short-term capacity for these thin-luns (and accordingly create data files that are not larger than that capacity!). You can add some falvour to the strategy by limiting the ASM disk size to make sure the db won't overflow the thin pool actual capacity. Continue to monitor the thin pool allocation and if everything goes well, have the discussion at the end of the 6 month about growth. At that time if indeed growth is taking place, add capacity to the thin pool, and potentially update the ASM disks capacity (dynamic operation). In accordance, the data files can be extended to the new capacity (manually, or let them do it automatically). No changes need to take place on the host (such as new LUNs discover, reboot or rescan).

This approach fits both auto-extend or manual data file addition / resizing but again - requires good tracking of the thin pool capacity utilization and communication between dba and system/storage admins.

Yaron