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.McGeary AT potashcorp DOT 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 <zforray AT VCU DOT EDU>
> To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT 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 <zforray AT vcu DOT 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.McGeary AT potashcorp DOT 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 <zforray AT VCU DOT EDU>
> >> To: ADSM-L AT VM.MARIST DOT 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 AT VM.MARIST DOT 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
> >> 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
> >>
> >>
> >
> >
> > --
> > *Zoltan Forray*
> > TSM Software & Hardware Administrator
> > BigBro / Hobbit / Xymon Administrator
> > Virginia Commonwealth University
> > UCC/Office of Technology Services
> > 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
> >
>
>
>
> --
> *Zoltan Forray*
> TSM Software & Hardware Administrator
> BigBro / Hobbit / Xymon Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> 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
>
>
--
*Zoltan Forray*
TSM Software & Hardware Administrator
BigBro / Hobbit / Xymon Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
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
|
