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.
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...
Kind regards,
Eric van Loon
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Sascha Askani
Sent: maandag 21 november 2011 15:20
To: ADSM-L AT VM.MARIST DOT EDU
Subject: delete filespace and LOGMODE NORMAL
Hi List,
Again, I'd like to tap into your (almost) infinite wisdom regarding TSM
;)
I have a 5.5.4.1 / Solaris server running here with a node that has
approx. 36 Million objects stored. I already exported this node to a
newer (in terms of Hardware and TSM version) server and switched
backups.
Now I want to get rid of the filespace on the old server. Since deleting
36 million objects will fill up the recovery log pretty fast and often,
I thought setting the logmode to "normal" would result in a nice cleanup
without triggering the DBBACKUPtrigger every n minutes.
So I set the logmode to normal but this didn't keep the log from filling
up until 78% where I cancelled the DELETE FILESPACE. Interestingly, the
log didn't go back to 0% utilization as I would have expected it. So I
did a manual DBBACKUP which zeroed the log.
I also opened a PMR with IBM, my contact told me that cancelling the
DELETE FILESPACE, backing up the DB and resuming the DELETE FILESPACE
was the correct way to do it. So I set the logmode back to ROLLFORWARD
and defined the Trigger to 32 incremental backups; this way I didn't
have to have an eye on the server while deleting the filespace.
So (finally) my question is: Does "Logmode Normal" not prevent a fill-up
of the log in this case? Sounds like a bug to me somehow. And why did
the log not revert back to zero when I cancelled the DELETE?
Sorry for the long mail and thanks in advance!
Sascha
********************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain confidential and
privileged material intended for the addressee only. If you are not the
addressee, you are notified that no part of the e-mail or any attachment may be
disclosed, copied or distributed, and that any other action related to this
e-mail or attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately by return
e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
employees shall not be liable for the incorrect or incomplete transmission of
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
Airlines) is registered in Amstelveen, The Netherlands, with registered number
33014286
********************************************************
|
