This content has been marked as final. Show 10 replies
The ILM Assistant does not create new tablespaces when it detects a necessary relocation of a partition; therefore, it needs to know where partitions can be placed. To do that, the user must assign tablespaces to a particular storage tier. Now, since we have two types of data (read-write and read-only), we may need to know about two tablespaces per tier: one to receive read-write data and one to receive read-only data. That's where the preferred tablespaces come into play. You must choose a preferred read-write tablespace that will receive any read-write partitions that enter the tier, and you must choose a preferred read-only tablespace to receive any read-only partitions that enter the tier.
As an optimization, we have set up the concept of a secondary tablespace. This is just a convenience the allows a current tablespace containing partitions to be associated with a storage tier. If we determine that a particular partition belongs to a tier, normally, we would state that it must be moved to the preferred tablespace for that tier. However, by assigning the partition's tablespace to a tier, the ILM Assistant is smart enough to leave the partition where it is since the tablespace is already on the tier.
Does this help?
Is it so that active data is read-write and old data is read-only?
And does the most active data go on the read-write preferred tablespace and the less active data on the read-write secondary tablespace?
It's not yet that sophisticated. :)
If your lifecycle says that read write data must be moved, then ILMA will recommend that you move the data to the preferred read-write tablespace for the intended storage tier. If your lifecycle says that your data must be read-only and is currently in a read-write tablespace, then ILMA will recommend that you move the data to your preferred read-only tablespace on the intended storage tier.
A secondary tablespace comes into play when the recommendation is formed. If ILMA says your data should be on tier XYZ, then unless your data is already in the preferred tablespace for tier XYZ, it will recommend a move. Now, if your current tablespace for data just happens to be on tier XYZ, then you can let ILMA know that it is a secondary tablespace. In which case, ILMA will leave the data where it currently resides, in a secondary tablespace on the correct tier.
Hope this helps. :)
It's still rather complicated :S
Can a tier have only 1 read-write preferred tablespace, even if ILMA is managing more than 1 table in the database?
You must have at least 1 read-write or read-only preferred tablespace. The secondary tablespaces are optional.
I have another question.... :)
Is it important which tablespace you choose to be a read-write preferred, or can any tablespace be choosen to be a read-write preferred?
If it is important, how do you determine which tablespace should be a read-write preferred?
the read-write preferred tablespace is the one which is used by default by the script generation programme to move data to that tablespace. Therefore, don't select a tablespace that you don't want data to be moved to.
If you need to move to multiple tablespaces then you will need to specify one so that the script works and then manually edit the generated script
Notice in the tutorial that
e.g there are 10 tablespaces and 6 are allocated to the different tiers of storage:
- High Performance (tbs 1-3)
- Low Cost (tbs 4-5)
- Archived (tbs 6)
and there are 4 remaining tablespaces. Where will they reside if they are not allocated in any of the tiers?
or its just that
1) Establish connections with 3 tiers of storage (as stated above)
2) Create tablespaces in respectived/intended storage-tiers
3) If the tbs 7-8 is at High-Performance tier and 9-10 in Low-Cost tier, then its optional whether
I wants to put them in ILM under 'Secondary tablespace'.
In this manner, i am not classifying them and made used of in LIfe-Cycle Definition ???? is that right???
Hi, no response for the last question?
Sorry ... just noticed this ...
If tablespaces are not specifically marked as preferred or secondary, the Assistant will never move data into those tablespaces. However, if the Assistant detects managed table data residing in one of those unmarked tablespaces, it may try to relocate the data to a preferred tablespace or a clone of a preferred tablespace. This is where secondary tablespaces are helpful. If a tablespace is marked as a secondary, the Assistant will not place any new data in the tablespace, but it will leave existing managed data there if the secondary tablespace matches the placement criteria specified in the Lifecycle Definition. The secondary tablespace mark is just a convenient way to leave well-enough alone.
Here are the basic rules for tablespaces:
1. If read-write data needs to be moved to target tier, ILMA picks the preferred read-write tablespace to receive the data.
2. If read-only data needs to be moved to target tier, ILMA picks the preferred read-only tablespace and clones it to receive the data. If no preferred read-only is found, it picks the preferred read-write tablespace and clones it.
3. If read-write data resides on tier, but does not reside in either the preferred read-write or a secondary write-enabled tablespace, ILMA will move the data to the preferred read-write tablespace.
4. If read-only data resides on tier, but does not reside in a read-only secondary tablespace, ILMA will clone either the preferred read-only or read-write tablespace and move the data.
5. ILMA automatically designates ILMA-cloned tablespaces as secondary tablespaces.
6. ILMA never moves data into existing secondary tablespaces.
Hope this helps.