What is db2sysc doing? (AIX)

[Rigido]

Hi,
today I just come back to work and found one of a customer SP server (8.1.12.100) on AIX (7200-05-02-2114) almost stuck.
I run nmon and found that db2sysc process is the TOP I/O process and it is reading more than 1,5GGB/sec and more than 40000 iops from the database volume group:

│Name          Disks AvgBusy      Read|WriteKB/s TotalMB/s xfers/s BlockSizeKB                   
...
│tsmdb              4  99.7% 1880388.1|0.0       1836.3   39288.7   47.9                         
...
│  PID       %CPU     Size      Res     Res      Res     Char    RAM      Paging         Command
│            Used       KB      Set     Text     Data     I/O     Use   io   other repage       
│ 3867356   303.9  1182560  1182464      104  1182360  1528007    1%      0      0      0 db2sysc

This morning I tried to cancel a node session started more than three days ago but session is still in Cancel Pending.

Any hints on how to check what is db2sysc doing?
I read db2pd should help on db2 performance issues and I tried to check db2pd files that servermon creates, but it is out of my skills.

Thanks.

 

[marclant]

Any hints on how to check what is db2sysc doing?

db2sysc is the process that runs the DB2 database for the Spectrum Protect server. So it's perfectly normal that it is busy.

 

[Rigido]

Ciao Marclant,
I know what db2sysc is and I think it is not normal to see Spectrum Protect server stuck (nmon didn't show any I/O from the dsmserv process), with sessions running more than 3 days and no more data sent and such values from db2sysc process.
Ex colleague from the support did a quick investigation and told me it could be IT37113.

I'm going to open a PMR and let you know...

 

[marclant]

(nmon didn't show any I/O from the dsmserv process)

That is normal too, dsmserv doesn't do the database i/o, DB2 does. dsmserv just sends the instructions to DB2.

I think it is not normal to see Spectrum Protect server stuck

That is not normal, what I meant that is normal is the db2sysc is busy.

Ex colleague from the support did a quick investigation and told me it could be IT37113.

If your customer is already at 8.1.12.100, they would already have a fix for that APAR. So opening a case is the right path.

 

[Rigido]

If your customer is already at 8.1.12.100, they would already have a fix for that APAR. So opening a case is the right path.

It looks like it will be fixed in 8.1.12.200 or 8.1.13

****************************************************************
* RECOMMENDATION:                                              *
* Apply fixing level when available. This problem is currently *
* projected to be fixed in levels 8.1.12.200 and 8.1.13. Note  *
* that this is subject to change at the discretion of IBM.     *
****************************************************************

BTW, case opened and it is going to Devs.

 

[marclant]

Ah, the Local Fix was misleading:

Local fix

• . Roll back to previous level.
  Or
  . Uprade to 8.1.12.0 level