ADO and Two Way Storage Tiering
Posted
by Andy-Oracle
on Oracle Blogs
See other posts from Oracle Blogs
or by Andy-Oracle
Published on Mon, 9 Jun 2014 17:59:37 +0000
Indexed on
2014/06/09
21:33 UTC
Read the original article
Hit count: 240
/ILM
We get asked the following question about Automatic Data Optimization (ADO) storage tiering quite a bit. Can you tier back to the original location if the data gets hot again? The answer is yes but not with standard Automatic Data Optimization policies, at least not reliably. That's not how ADO is meant to operate. ADO is meant to mirror a traditional view of Information Lifecycle Management (ILM) where data will be very volatile when first created, will become less active or cool, and then will eventually cease to be accessed at all (i.e. cold). I think the reason this question gets asked is because customers realize that many of their business processes are cyclical and the thinking goes that those segments that only get used during month end or year-end cycles could sit on lower cost storage when not being used. Unfortunately this doesn't fit very well with the ADO storage tiering model.
ADO storage tiering is based on the amount of free and used
space in the source tablespace. There are two parameters that control this
behavior, TBS_PERCENT_USED
and TBS_PERCENT_FREE.
When
the space in the tablespace exceeds the
TBS_PERCENT_USED
value then segments specified in storage tiering
clause(s) can be moved until the percent of free space reaches the TBS_PERCENT_FREE
value. It is worth
mentioning that no checks are made for available space in the target
tablespace. Now, it is certainly possible to create custom functions to control
storage tiering, but this can get complicated. The biggest problem is insuring
that there is enough space to move the segment back to tier 1 storage, assuming
that that's the goal. This isn't as much of a problem when moving from tier 1
to tier 2 storage because there is typically more tier 2 storage available. At
least that's the premise since it is supposed to be less costly, lower
performing and higher capacity storage. In either case though, if there isn't
enough space then the operation fails.
In the case of a customized function, the question becomes do you attempt to free the space so the move can be made or do you just stop and return false so that the move cannot take place? This is really the crux of the issue. Once you cross into this territory you're really going to have to implement two-way hierarchical storage and the whole point of ADO was to provide automatic storage tiering. You're probably better off using heat map and/or business access requirements and building your own hierarchical storage management infrastructure if you really want two way storage tiering.
© Oracle Blogs or respective owner