Schneider, John wrote:
Greetings,
We are running TSM 5.4.3.0 server on AIX 5.3
We have a situation where our disk storage pools are becoming 70%
full in the middle of the night, which kicks off the automatic migration
cycle. Last night it happened at about 01:00. But a couple hours
later, while migration was still running, we had a few backup clients
fail because of this error:
07/16/08 03:18:16 ANR0534W Transaction failed for session 10529 for
node
PMMREPORTING (SQLsafe) - size estimate exceeded
and
server is unable to obtain additional space in
storage
pool T1DISK00. (SESSION: 10529)
This is a classic case. SQL backups do an estimate of the size of the
backups, (ref diffestimate) If that size is exceeded, the trnsaction
fails, maybe unless nothing happened in your diskpool since the start of
that transaction (unlikely). The decision to go to the next stgpool is
made before the transaction starts, once it's underway, there is no way
back.
So the transaction fails. Unfortunately, most TDPs don't retry with a
bigger size estimate, so that night's backup just failed.
(same can happen when you have compression on and commpressalways on as
well for normal client backups)
Apparently there was not enough contiguous storage in the storage pool
to fit the large file in this transaction. Fair enough. But this
storage pool is configured to migrate into a tape storage pool, and
indeed migration was running. I thought that in this case TSM would
mount a tape for this session to write to, and not cause it to fail.
Why didn't TSM mount a tape in the next storage pool? We know there
were tape drives available. Here is the description of the storage
pool:
Storage Pool Name: T1DISK00
Storage Pool Type: Primary
Device Class Name: DISK
Estimated Capacity: 1,263 G
Space Trigger Util: 10.9
Pct Util: 10.9
Pct Migr: 10.2
Pct Logical: 100.0
High Mig Pct: 70
Low Mig Pct: 10
Migration Delay: 1
Migration Continue: Yes
Migration Processes: 1
Reclamation Processes:
Next Storage Pool: SUN2079-POOL1
Reclaim Storage Pool:
Maximum Size Threshold: No Limit
Access: Read/Write
Description: Tier 1 Random Storage
Overflow Location:
Cache Migrated Files?: No
Collocate?:
Reclamation Threshold:
Offsite Reclamation Limit:
Maximum Scratch Volumes Allowed:
Number of Scratch Volumes Used:
Delay Period for Volume Reuse:
Migration in Progress?: No
Amount Migrated (MB): 1,181,053.02
Elapsed Migration Time (seconds): 26,336
Reclamation in Progress?:
Last Update by (administrator): SCHNJD
Last Update Date/Time: 05/22/08 11:31:59
Storage Pool Data Format: Native
Copy Storage Pool(s):
Active Data Pool(s):
Continue Copy on Error?: Yes
CRC Data: No
Reclamation Type:
Overwrite Data when Deleted:
We may begin working on getting more disk storage pool, or changing the
backup times so migration doesn't hit the disk so much, but that is not
the question I am asking. I want the storage pools to operate as a
hierarchy.
Best Regards,
John D. Schneider
Lead Systems Administrator - Storage
Sisters of Mercy Health Systems
3637 South Geyer Road
St. Louis, MO 63127
Phone: 314-364-3150
Cell: 314-750-8721
Email: John.Schneider AT Mercy DOT net
This e-mail contains information which (a) may be PROPRIETARY IN NATURE OR
OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only for the
use of the addressee(s) named above. If you are not the addressee, or the
person responsible for delivering this to the addressee(s), you are notified
that reading, copying or distributing this e-mail is prohibited. If you have
received this e-mail in error, please contact the sender immediately.
--
Met vriendelijke groeten,
Remco Post, PLCS
|
