Just ran successfully on a 6.2.4.0 Linux server. Hardware is 16Core machine with 24GB memory with DB and log on SSD disks.
Here are the results
550 million rows in the BF_AGGREGATED_BITFILES table.
bfagg_nocluster_97.db2 script ran for 35 minutes.
RUNSTATS after starting the server took 30 minutes.
Index size went from 88GB to 48GB.
If you have any doubt of running this yourself I recommend contacting IBM,
Kind Regards
Stefan Thor
Basis
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Colwell, William F.
Sent: Tuesday, June 05, 2012 9:36 PM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: Thoughts and experiences on Technote: Local fix information for APAR IC82886
Hi Sergio,
I ran the fix up procedure on 2 small 6.3.1 instances and at went well, no problems.
I didn't have to run anything more than the directions.
If you plan to do a lot of dedup running this is a good idea before your instances gets too big.
I will not be running it on my 6.1 servers where the table in each instance has > 3 billion rows, the outage would be too long.
The text says "Because of the required server outage and the fact that not all server users experience
the problem, the server does not perform this reconfiguration automatically" so the 6.3.3 fix will not do this automatically.
Bill Colwell
Draper Lab
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Sergio O. Fuentes
Sent: Tuesday, June 05, 2012 4:24 PM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Thoughts and experiences on Technote: Local fix information for APAR IC82886
Hello all,
We have three TSM servers with versions between 6.3.0 to 6.3.1 range. According to the technote here:
http://www-304.ibm.com/support/docview.wss?uid=swg21592404&myns=swgtiv&mynp=OCSSGSG7&mync=E
it states that for any server CREATED on TSM version below the fix for APAR IC82886 (6.3.3 is targeted) should apply the local fix regardless if you're experiencing errant DB growth and utilization. That would include anyone on versions TSM 6.1, 6.2, and 6.3.2 or below. Anyone out there have experience in implementing this fix? Is the local fix complete, or is there something to do after all the reorgs, runstats and create index processes run to reclaim space? Were there major outages for your environment? Our largest DB is 250GB but the BF_AGGREGATED_BITFILES table is relatively small (about 10 million objects). Do you recommend opening a PMR with IBM to hold my hand during the process? Would the fix in 6.3.3 actually do the local fix for us?
Considering that EVERYONE who has TSM V6 has created a DB on a non-patched version of TSM everyone should probably consider running the local fix... unless the 6.3.3 level fixes earlier versions of the DB.
Thoughts, experiences? Thanks for your help!
Sergio
U. of Maryland
