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
