Hi all
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 DOT EDU] On Behalf Of
Colwell, William F.
Sent: Tuesday, June 05, 2012 9:36 PM
To: ADSM-L AT VM.MARIST DOT 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 DOT EDU] On Behalf Of
Sergio O. Fuentes
Sent: Tuesday, June 05, 2012 4:24 PM
To: ADSM-L AT VM.MARIST DOT 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
|