Highlighted
slucido
3 Argentium

ASM & Thin Provisioning Scenario

Jump to solution

Givens:

  • New LUNs/ASM disks are provisioned to this host for the 1st time
  • A new ASM data disk group was created
  • A DB has NOT been created (yet) using the new ASM data disk group
  • Thin LUN

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?

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.

Thanks for your help!

0 Kudos
1 Solution

Accepted Solutions
yd1
1 Copper

Re: ASM & Thin Provisioning Scenario

Jump to solution

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

7 Replies
PaulCork
3 Argentium

Re: ASM & Thin Provisioning Scenario

Jump to solution

Sam,

the first assumption is correct.. however I'll expand on the second piece. 

In using thin provisioning as a DBA, you will only ever have the potential to use the capacity that is visible to your host. 

If the host sees 1TB of storage then that is all it can or ever will be able to use until additional devices are mapped and masked to the host. Virtual provisioning doesn't change this.  

Virtual Provisioning makes it possible to provision storage for applications without providing the physical storage upfront. This means that administrators can assign enough storage to last the lifetime of the application without needing to purchase all the physical storage in advance. This approach is called over-provisioning or oversubscription.

When working in a virtual provisioning environment that is using an oversubscription method is is necessary to have some controls in place to ensure that procedures exist to ensure that an out of space situation will never occur. This means monitoring of pool resources by the storage team and an agreement between the storage and database guys that X amount of capacity will always be available for growth. 

Alerts exist by default in EMC arrays and are customizable so that admins are warned when freespace hits the predefined thresholds.  When this happens additional space can be added on the fly and the pools expanded to ensure continued growth can be accomodated.   The new devices are added to the pool for capacity and the pool can be rebalanced to redistribute the load across all hypers increasing the stripe size of the pool.

In fact adding additional devices can have benefits to performance, Yaron has a nice paper showing the effects of this.  Implementing Virtual Provisioning on EMC Symmetrix VMAX with Oracle Database 10g and 11g— Applied Technology

The use of oracle auto extend with ordinary tablespaces will auto extend at the file level.  With Big tablespaces it is at the Table space level..  These features can provide benefits. 

As you stated the ARSU is not so much of a play in growth scenarios however if you are dropping tablespaces and want to reclaim the space to the pool then this comes into effect.

We have just published a paper showing the effects of the zero space reclaim after a migration, moving from thick to thin provisioning. 

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/h8870-emc-migrate-oracle-dw-v...

The other benefit is that thin provisioning opens the doors to FAST VP for sub lun tiering

Hope this helps

slucido
3 Argentium

Re: ASM & Thin Provisioning Scenario

Jump to solution

Paul,

Thanks for the detailed reply. I'm also working on posting the Technical Note you referenced on Powerlink to the Oracle Community as it is very useful.

0 Kudos
jweinshe
2 Bronze

Re: ASM & Thin Provisioning Scenario

Jump to solution

To be clear: you are using ASM with RDMs or VMDKs? I'm guessing RDMs but want to make sure.

0 Kudos
slucido
3 Argentium

Re: ASM & Thin Provisioning Scenario

Jump to solution

The initial discussion is all physical with no virtualization involved. If interested we can start another discussion adding the virtualization layer into the topic.

0 Kudos
slucido
3 Argentium

Re: ASM & Thin Provisioning Scenario

Jump to solution

The Technical Note referenced in Paul's reply above has been posted on the Oracle Community:

EMC Migration of an Oracle Data Warehouse

https://community.emc.com/docs/DOC-12918

0 Kudos
SKT2
4 Tellurium

Re: ASM & Thin Provisioning Scenario

Jump to solution

in a thick volume scenario when you create disk group(consider no data at this tim) will be as equal to 99% free space at disk group level and you can drop a member and reclaim that LUN; 

Now consider the when DB is created and the usage is at 25% . We can recliam the 50% unused if needed with thick volume. ASM disk group is striped and effectivley those 25% of data is laid out across all the LUNs(members used). Drop some members(50%) and perform the rebalance again at ASM level

How does the recliam is possible in the same  situation WHEN i am with thin LUNs?how does this exactly work? In earlier case dba drop the member and let storage folks know which member/lun to reclaim

0 Kudos
yd1
1 Copper

Re: ASM & Thin Provisioning Scenario

Jump to solution

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