ADSM-L

Re: [ADSM-L] delete filespace and LOGMODE NORMAL

2011-11-23 01:09:01
Subject: Re: [ADSM-L] delete filespace and LOGMODE NORMAL
From: Roger Deschner <rogerd AT UIC DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 23 Nov 2011 00:08:27 -0600
In TSM V5, DELETE FILESPACE is extremely resource-intensive. To get rid
of this huge filespace you may have to plan to schedule it in pieces.
Set a schedule to start it every day at a quiet time, and then cancel
the process when the server needs to do something else. Doing it in
small pieces will also keep it from filling the log. Repeat for as many
days as it takes to get rid of the filespace. I don't know if it's
faster in V6, but I sure hope so, since the average Apple Mac client
node has about 1,000,000 files, and we've got many Macs. The larger log
size in V6 should help.

More comments below.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
========== "You will finish your project ahead of schedule." ===========
================= (Best fortune-cookie fortune ever.) ==================


On Tue, 22 Nov 2011, Sascha Askani wrote:

>Am 22.11.2011 12:27, schrieb Loon, EJ van - SPLXO:
>> Hi Sascha!
>> Indeed this sounds strange. I can imagine that the delete filespace pins
>> the log, which causes the log to grow, but as soon as you cancel the
>> delete filespace, the pinning should be gone and thus the log
>> utilization should be back to 0.
>
>Yes, that's what I was expecting.
>
>> This only proves my point: I have a PMR open for months about log
>> utilization. Our log continues to grow and triggers a backup several
>> times a night. We switched to normal mode, just to see what happened,
>> but this also causes the log to grow. Less (up to 60/70%) but still, the
>> log grows more than expected. When running in normal mode, the log only
>> contains uncommitted transaction. Typically large SQL Server client
>> backups tend to pin the log for a long time, but I also saw that the log
>> space isn't returned after a pinning transaction is completed.
>> Development explained that the recovery log uses a sort of a round robin
>> method and that this is the reason why space isn't returned straight
>> away.
>> The fact that a canceled delete filespace doesn't free the log only
>> proves to me that something is definitely broken/not working correctly
>> in TSM, but I can't seem convince development...
>
>While thinking about your answer I remember a had a strange behaviour
>(yes, yet another one!):
>
>After cancelling the "DELETE FILESPACE" and the log not returning to
>zero, I tried a "DELETE VOL nnnnn DISCARDD=yes" in the STGPool affected;
>after that the log returned to zero immediately, but unfortunately, I
>could not reproduce this, so maybe it was jst coincidence, who knows?

I have seen this kind of behavior. It was a coincidence. The thing that
caused the log to go back down to 0 was the simple passage of time, so
don't bother with DELETE VOL or any other trick. Sometimes it can take
several hours.

This is how TSM behaves about a lot of things, including CANCEL PROCESS.
It acts on them when it gets around to it and it decides that all the
related locks have expired, or it gets to the next file to be moved, or
whatever else it is that makes it take its time. A lot of things can be
held up by a client node restore that is underway, which will preempt
most other processes. Relax and go with the flow.

--Roger


>
>However, it feels good not being the only one having this type of problem :)
>
>BR,
>
>Sascha
>

<Prev in Thread] Current Thread [Next in Thread>