These three server options were added at 6.3.5 and 7.1.1 (per APAR IC95301).
In the case of DISABLEREORGTable, if no table names are listed, no table
reorgs are disabled. So in Zoltan's example, all table reorgs are enabled.
Note that reason code 2 in the ANR3497W message indicates that the reorg is
needed on the index, not on the table (and BACKUP_OBJECTS is on the default
list for DISABLEREORGIndex). See the "Disabling reorganization for selected
tables" section of technote 1452146 (
http://www.ibm.com/support/docview.wss?uid=swg21452146#disable_reorg ).
IIRC, index reorgs are disabled entirely by default in 6.x, but enabled by
default in 7.1.1 (that technote says index reorgs default to enabled in
6.3.5, too, but that does not seem to be the case on my 6.3.5 server). It
wouldn't matter anyway, though, on tables that are excluded.
I'm currently in the situation described near the end of that technote where
I get the weekly ANR3497W indicating index reorgs are needed on a couple of
the tables that are excluded. That leaves me in the same boat of figuring
out what to do about those indexes that need reorgs. I suspect I'll have to
roll offline reorgs for this in with major TSM upgrades in some annual
maintenance window...
=Dave
On 04/23/2015 10:25 AM, Zoltan Forray wrote:
> 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?
>>
--
Hello World. David Bronder - Systems Architect
Segmentation Fault ITS-EI, Univ. of Iowa
Core dumped, disk trashed, quota filled, soda warm. david-bronder AT uiowa
DOT edu
|
