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?

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

BR,

Sascha