ADSM-L

Re: Log pinning issue, not quite sure what's going on...

2006-05-04 15:10:35
Subject: Re: Log pinning issue, not quite sure what's going on...
From: Joni Moyer <joni.moyer AT HIGHMARK DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 4 May 2006 15:04:32 -0400
Hey Everyone,

As an update, I have checked the firmware levels of the drives and they are
all the same and I have also checked the attributes on the drives and they
are the same as well.   Also, we have an SL8500 STK library housing the
LTO2 drives.  I am at a loss at this point in time as to what might be
causing this issue.

Gresham just allows me to share the library between our 2 TSM servers.  It
has the drive definitions in them, but they have not been modified, so that
shouldn't effect this issue.

If anyone has other suggestions I am open to listen to them.  This problem
has me stumped.

Thanks Richard for your suggestions on checking the drive firmware level
and the attributes!

********************************
Joni Moyer
Highmark
Storage Systems, Senior Systems Programmer
Phone Number: (717)302-9966
Fax: (717) 302-9826
joni.moyer AT highmark DOT com
********************************



             "Richard Sims"
             <rbs AT bu DOT edu>
                                                                        To
             05/04/2006 01:49          "Joni Moyer"
             PM                        <joni.moyer AT HIGHMARK DOT COM>
                                                                        cc

                                                                   Subject
                                       Re: Log pinning issue, not quite
                                       sure what's going on...










Joni - I don't have your drive type or Gresham; but whereas it seems
like
        a certain drive, I would compare its firmware level with that of
its companion drives and see if any difference.

Beyond that, I would inspect recent migration statistics and see if that
drive seems to be a lot slower than the others, for some reason.
Another thing I'd do, at least for my own curiosity, would be like
'lsattr -El rmt0' and see if all the drives exhibit the same attributes:
TSM should be setting them the same, but something might interfere that
I'm not familiar with (Gresham?).

     Richard Sims

On May 4, 2006, at 1:32 PM, Joni Moyer wrote:

> Hello everyone,
>
> Earlier in the week I had an issue with the log being pinned by a
> migration
> task.  I have thus experienced the issue again this morning and it
> appears
> as if another migration task has it pinned again.  The weird thing
> is that
> in all cases the migration task that has it pinned it the same
> drive each
> time.  It just seems to sit there and does not continue after a
> certain
> point in time.
>
> I have a TSM 5.2.1.7 server on AIX 5.2 which runs Gresham EDT
> 7.4.0.5 with
> ACSLS 7.1.0.24 and LTO2 tape drives.  We have had the drive
> replaced today,
> but I am still seeing this bizarre issue happening with the
> migration task
> and that particular drive.
>
> Does anyone have any suggestions/ideas?
>
> And also, I will be changing this recovery log to rollforward mode
> within
> the next day.  Thanks for the suggestion Richard!
>
>   Sess Comm.  Sess     Wait   Bytes   Bytes Sess  Platform Client Name
>
> Number Method State    Time    Sent   Recvd Type
> ------ ------ ------ ------ ------- ------- ----- --------
> --------------------
>     11 Tcp/Ip Run      0 S   10.9 K  30.7 G Node  WinNT    HMCH1143
>
>     54 Tcp/Ip IdleW    0 S    4.6 K   4.8 K Node  WinNT    HMCH1143
>
>  2,004 Tcp/Ip Run      0 S        0      42 Admin WebCons  DCOPS
>
>                                                    ole
>
>  2,295 Tcp/Ip IdleW   32 S    1.3 G   1.2 K Node  TDP      LNPITTA02
>
>                                                    Domino
>
>                                                    AIX
>
>  2,466 HTTP   Run      0 S        0       0 Admin WebBrow  LIDZR8V
>
>                                                    ser
>
>
> Dirty page Lsn=5493127.198.1518, Last DB backup Lsn=5493128.7.1110,
> Transaction table Lsn=5491887.53.2214, Running DB backup Lsn=0.0.0,
> Log
> truncation Lsn=5491887.53.2214
>
> Lsn=5491887.53.2214, Owner=DB, Length=56
> Type=Update, Flags=82, Action=SetIcb, Page=5543936, Tsn=0:2734908799,
> PrevLsn=0.0.0, UndoNextLsn=0.0.0, UpdtLsn=0.0.0 ===> Bit Offset = 454
> (80) Generating SM Context Report:
> (80)  *** no sessions found ***
> (52) Generating SM Context Report:
> (52)  *** no sessions found ***
> (52)   procNum=9, status=Examined 2684470 objects, deleting 365892
> backup
> objects, 99 archive objects, 0 DB backup volumes, 0 recovery plan
> files; 0
> errors encountered.
> , cancelInProgress=False
> (52)   descr=Expiration, name=EXPIRE INVENTORY, cancelled=False
> (36) Generating SM Context Report:
> (36)  *** no sessions found ***
> (62) Generating SM Context Report:
> (62)  *** no sessions found ***
> (62)   procNum=8, status=Disk Storage Pool WINDOWS, Moved Files:
> 12914,
> Moved Bytes: 9,273,446,400, Unreadable Files: 0, Unreadable Bytes: 0.
> Current Physical File (bytes): 12,546,048 Current output volume:
> T01486. ,
> cancelInProgress=False
> (62)   descr=Migration, name=MIGRATION, cancelled=False
> No session or process assoicated with this transaction can be
> located, or
> one or more session and process found.
>
>  Process Process Description  Status
>
>   Number
> -------- --------------------
> -------------------------------------------------
>        8 Migration            Disk Storage Pool WINDOWS, Moved Files:
> 12914,
>                                Moved Bytes: 9,273,446,400, Unreadable
> Files: 0,
>                                Unreadable Bytes: 0. Current
> Physical File
>
>                                (bytes): 12,546,048 Current output
> volume:
>
>                                T01486.
>
>        9 Expiration           Examined 2688075 objects, deleting
> 365892
> backup
>                                objects, 99 archive objects, 0 DB
> backup
>
>                                volumes, 0 recovery plan files; 0
> errors
>
>                                encountered.
>
>
> ********************************
> Joni Moyer
> Highmark
> Storage Systems, Senior Systems Programmer
> Phone Number: (717)302-9966
> Fax: (717) 302-9826
> joni.moyer AT highmark DOT com
> ********************************