Yikes - you must have huge systems/databases. We have been toying with looking at deduping some of our servers. Looks like at a minimum I need to bump the actlogsize on all servers to 128GB just to be sure!. Thanks for details!
On Tue, Jan 6, 2015 at 10:33 AM, Matthew McGeary < matthew.mcge...@potashcorp.com> wrote: > Zoltan, > > Yes, the default before 6.3.5.1 / 7.1.1 was to allow reorgs of all > tables. The new options are an attempt to get around the larger tables > causing issues for shops running dedupe with a large database. Fun fact, > the maximum log size in TSM 7.1.1 is 512 GB and when I attempted an online > reorg of the 'problem tables,' it exhausted the log even at that size. > > __________________________ > > *Matthew McGeary* > Technical Specialist - Operations > PotashCorp > T: (306) 933-8921 > *www.potashcorp.com* <http://www.potashcorp.com> > > > > > > From: Zoltan Forray <zfor...@vcu.edu> > To: ADSM-L@VM.MARIST.EDU > Date: 01/06/2015 08:06 AM > Subject: Re: [ADSM-L] 6.3.5.1 TSM server brings new annoyances > Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > ------------------------------ > > > > Matthew, > > Thanks for the link. I assume the default before 6.3.5.1 was NOT excluding > anything from regular reorg/reindexing so I don't see why I should have a > problem, now. I will make sure to max the actlog to 128GB to be sure I > don't run out. I see it automagically added these DISABLEs to the > dsmserv.opt file. > > On Tue, Jan 6, 2015 at 8:52 AM, Zoltan Forray <zfor...@vcu.edu> wrote: > > > Thanks. I assume the default before 6.3.5.1 was NOT excluding anything > > from regular reorg/reindexing so I don't see why I should have a problem, > > now. I will make sure to max the actlog to 128GB to be sure I don't run > > out. > > > > On Tue, Jan 6, 2015 at 8:43 AM, Matthew McGeary < > > matthew.mcge...@potashcorp.com> wrote: > > > >> Zoltan, > >> > >> You can remove the exemption from that table in your dsmserv.opt. If > you > >> are not running dedupe, I would guess that the online reorg would work > ok > >> but there is a chance that the reorg process will exhaust the active log > >> and halt the server. > >> > >> See this for info on the dsmserv option: > >> > >> > >> > https://www-01.ibm.com/support/knowledgecenter/SSGSG7_7.1.1/com.ibm.itsm.srv.ref.doc/r_opt_server_disablereorgindex.html > >> __________________________ > >> > >> *Matthew McGeary* > >> Technical Specialist - Operations > >> PotashCorp > >> T: (306) 933-8921 > >> *www.potashcorp.com <http://www.potashcorp.com>* > >> > >> > >> > >> > >> From: Zoltan Forray <zfor...@vcu.edu> > >> To: ADSM-L@VM.MARIST.EDU > >> Date: 01/05/2015 02:25 PM > >> Subject: [ADSM-L] 6.3.5.1 TSM server brings new annoyances > >> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > >> ------------------------------ > > >> > >> > >> > >> Recently updated all of my TSM Linux servers to 6.3.5.1 and am seeing > >> 2-issues. > >> > >> The first is related to a RedHat Kernel issue. Originally thought to be > >> RHEL 6.6 / 2.6 kernel problem but now seems to go back to 6.5 (per the > >> IBM > >> person I am working with). The doc is here: > >> > >> > http://www-01.ibm.com/support/docview.wss?uid=swg21691823 > > >> > >> The second issue I am seeing is there messages popping up on most if not > >> all servers. > >> > >> 1/5/2015 2:38:09 PM ANR3497W Reorganization is required on excluded > table > >> BACKUP_OBJECTS. The reason code is 2. > >> > >> What is the recommended way to resolve this? I have read some docs and > >> they talk about doing offline reorgs (no, I do not want to do this). We > >> are not doing dedup and all servers are beefy with 48GB+ of memory - > most > >> at 96GB so that should not be an issue. > >> > >> Suggestions? > >> -- > >> *Zoltan Forray* > >> TSM Software & Hardware Administrator > >> BigBro / Hobbit / Xymon Administrator > >> Virginia Commonwealth University > >> UCC/Office of Technology Services > >> zfor...@vcu.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 > >> > >> > > > > > > -- > > *Zoltan Forray* > > TSM Software & Hardware Administrator > > BigBro / Hobbit / Xymon Administrator > > Virginia Commonwealth University > > UCC/Office of Technology Services > > zfor...@vcu.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 > > > > > > -- > *Zoltan Forray* > TSM Software & Hardware Administrator > BigBro / Hobbit / Xymon Administrator > Virginia Commonwealth University > UCC/Office of Technology Services > zfor...@vcu.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 > > -- *Zoltan Forray* TSM Software & Hardware Administrator BigBro / Hobbit / Xymon Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.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