Re: backup error
2001-01-11 14:17:48
Subject: |
Re: backup error |
From: |
Richard Sims <rbs AT BU DOT EDU> |
Date: |
Thu, 11 Jan 2001 14:07:33 -0500 |
>I ran into this with an AS/400 client and what it seemed was that when the
>API went to transfer the data to the server it allocated the space in the
>diskpool but since the AS/400 first builds a saveobject before it actually
>sends the data (which compresses the data) it was larger that what was
>allocated in the storagepool. I was not able to prove this but from looking
>at both the actlog and the AS/400 messages that is what it appeared to be.
Ron - Indeed, that's another of the pesky nuances that can get you.
Most commonly, it's seen with...
ANR0534W Transaction failed for session nnnn for node xxxx - size estimate
exceeded amd server is unable to obtain storage
The delta between the low %Migr and the high %Util represents the amount
of space that has been reserved for other clients that are concurrently
being backed up: This is bitfile (Aggregate) space that has been
allocated in the storage pool for transactions that are currently in
flight.
Has been seen where client compression is turned on, and client has
large or many compressed files: *SM is fooled as compression increases
the size of an already-compressed file.
Prior to a client sending a file, the space (same as allocated on
client) is allocated in the *sm server's disk storage pool. If caching
is active in the disk storage pool, and files need to be removed to make
space, they are. But if the file grows in compression (client has
COMPRESSIon=Yes and COMPRESSAlways=Yes), the cleared space is
insufficient to contain the incoming data.
Richard Sims, BU
|
|
|