ADSM-L

Re: [ADSM-L] ANR3497W

2015-04-23 11:27:20
Subject: Re: [ADSM-L] ANR3497W
From: Zoltan Forray <zforray AT VCU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 23 Apr 2015 11:25:13 -0400
I can relate.  See the same thing every day. When upgrading to 6.3.5.100,
IBM/Tivoli by default disable almost all database reorgs by adding these to
the dsmserv.opt:

DISABLEREORGTable
DISABLEREORGIndex
BF_AGGREGATED_BITFILES,BF_BITFILE_EXTENTS,BACKUP_OBJECTS,ARCHIVE_OBJECTS
DISABLEREORGCleanupindex

I have tried removing these from some of my servers without any detriment
since I don't do deduping.

I also read the daunting section on manual reorging (no thanks - I was
promised I wouldn't have to be a DBA when V6 came around.  I have had to
learn way more DB2 than I ever wanted to.  I keep bugging my ex-DB2 (we
only do Oracle now) DBA for help in deciphering various DB2 messages.



On Thu, Apr 23, 2015 at 11:11 AM, Thomas Denier <Thomas.Denier AT jefferson DOT 
edu
> wrote:

> We have a number of TSM server instances running under zSeries Linux.
> These were created with 6.2.2.0 server codes, subsequently upgraded to
> 6.2.5.0, and upgraded to 6.3.5.0 in early April. One of the server
> instances is now displaying the message:
>
> PM ANR3497W Reorganization is required on excluded table BACKUP_OBJECTS.
> The reason code is 2.
>
> every few days. The messages manual and various technotes mention the
> following three options:
>
> 1.Do nothing, and risk ongoing growth in disk space  used by the database
> and ongoing decline in performance.
> 2.Enable online reorgs of BACKUP_OBJECTS, lock out smaller reorgs for
> periods that might stretch into months, and risk crashing the server.
> 3.Take the server down for "many hours" to perform an offline reorg.
>
> The discussion of the advantages and disadvantages of each option is
> maddening vague. All sorts of things "might" happen, but hardly anything
> "will" happen. Timing is discussed only in terms like "many hours". As far
> as I can tell, the writers' main goal was to ensure that IBM will never be
> blamed for giving bad advice, and they achieved this goal by the simple
> expedient of refusing to give any advice.
>
> Is there any documentation available that provides real help in deciding
> which option would be best for our situation?
>
> Thomas Denier
> Thomas Jefferson University
> The information contained in this transmission contains privileged and
> confidential information. It is intended only for the use of the person
> named above. If you are not the intended recipient, you are hereby notified
> that any review, dissemination, distribution or duplication of this
> communication is strictly prohibited. If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message.
>
> CAUTION: Intended recipients should NOT use email communication for
> emergent or urgent health care matters.
>



--
*Zoltan Forray*
TSM Software & Hardware Administrator
Xymon Monitor Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html

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