Container Storagepooldirectory is full and now???

master07

Newcomer
Joined
Jun 22, 2011
Messages
4
Reaction score
0
Points
0
PREDATAR Control23

Hi there,

we got the problem that our filesystem that is defined as storagepooldirectory for STGPOOL1 was full and now all new backups get the Error Message in the activity log
ANR2081E The STGPOOLDIRECTORY STGPOOLDIRECTORY in STGPOOL STGPOOL is full.

When we see that message in the act log we resize the filesystem and restart the tsm-server, but the clients get still produce the ANR2081E activity log entries.

We see that there a some containers are unavailable.
We also made already an audit container on the containers that are unavailable but there a still unchanged with state unavailable.
On the filesystem the unavailable containers have all 0 bytes.
here is the show sdpool stgpool1 command output
FsCapacity: 109025280 MB
FsFreeSpace: 1239122 MB
CntrAllocSpace: 108980607 MB
CntrUsedSpace: 72545862 MB
CntrFreeSpace: 300 MB
PoolCapacity: 108980607 MB
PoolFree: 36434745 MB
Reserved Space: 0 MB
is still only a few megabytes. Maybe that is the problem that the clients can make any backups anymore?

We use 7.1.7 tsm-server

We really need your help. thank you
 
PREDATAR Control23

For the directories that are unavailable, can you access them and view the content from the operating system?
 
PREDATAR Control23

not the directories are unavailable the container files in the stgpooldirectory are unavailable
the stgpooldirectory has readwrite access.

is defining a new stgpooldirectory the only way to solve this?
 
PREDATAR Control23

is defining a new stgpooldirectory the only way to solve this?
No, but it's a way to get space to get your backups going.

not the directories are unavailable the container files in the stgpooldirectory are unavailable
the stgpooldirectory has readwrite access
That wasn't my question. Can you see them from the OS, outside Spectrum Protect.
 
PREDATAR Control23

yes, i can see them in the operating system that they have 0 bytes and that they are existing. that is what I meant (sorry to be not so specific)
 
PREDATAR Control23

There are a lot of fixes to 7.1.7.x code with respect to container storage. You need to open a pmr and give information about your issues.

You can also move containers without prealloc space.
http://www-01.ibm.com/support/docview.wss?uid=swg22004973

Conatiners that goes unavailable: There is an apar for this too, and an efix to match. Open a pmr.

Orphan extents: Data not used by nodes, but exist in tsm. There is a big db2 select statement you can run to check this

Orphan chunks are chunks that have non-zero reference counts that in fact do not have any references.

Use this SQL selects to verify (IBM Lvl2 informed us about this at TSM Symposium 2017)

db2 "select count as dedup_count_orphaned_and_replicated from
sd_chunk_locations sdcl where refcount>0 and not exists (select 1 from
sd_recon_order sdro where sdro.chunkid=sdcl.chunkid) and exists (select 1
from sd_replicated_chunks sdrc where sdrc.chunkid=sdcl.chunkid and
sdrc.flags=0) for read only with ur"


db2 "select count as dedup_count_orphaned_not_replicated from
sd_chunk_locations sdcl where refcount>0 and not exists (select 1 from
sd_recon_order sdro where sdro.chunkid=sdcl.chunkid) and not exists (select
1 from sd_replicated_chunks sdrc where sdrc.chunkid=sdcl.chunkid) for read
only with ur"


If you get a positive result you are experiencing chunk level bloat,
contact IBM support to get assistance with the removal
 
PREDATAR Control23

Hi Trident,

with your sql statement I got following error:
SQL0204N "TSM.SD_CHUNK_LOCATION" is an undefined name. SQLSTATE=42704
 
PREDATAR Control23

Hi Trident,

with your sql statement I got following error:
SQL0204N "TSM.SD_CHUNK_LOCATION" is an undefined name. SQLSTATE=42704

Please show entire output, from connecting to DB2 and onwards.

I think you are missing an 's' in your query.
 
PREDATAR Control23

Please show entire output, from connecting to DB2 and onwards.

I think you are missing an 's' in your query.
That or didn't set the schema properly. It's looking in TSM.SD..., instead of TSMDB1.SD...
 
Top