IT其它Db2IBM db2

数据库在同一时间点报相同错误 进程为db2pclnr?

以下是6号的报错信息,昨天在同一时间点报了相同错误

相关进程是db2pclnr  

查了百度对这个进程的解释是:清除缓冲池脏页面到磁盘

但是用df -g查看文件系统使用率都是正常的 所以又觉得不是磁盘空间不足

因为百度对这个进程的相关解释过少,所以还想知道什么时候会触发这个进程db2pclnr

2020-08-06-12.34.19.068213+480 E1861220796A787      LEVEL: Error (OS)
PID     : 20775018             TID : 31962          PROC : db2sysc 0
INSTANCE: istrpt               NODE : 000           DB   : AMRPTDB 
HOSTNAME: hasmdbp01
EDUID   : 31962                EDUNAME: db2pclnr (AMRPTDB) 0
FUNCTION: DB2 UDB, oper system services, sqloLioAIOCollect, probe:100
MESSAGE : ZRC=0x850F000C=-2062614516=SQLO_DISK "Disk full."
          DIA8312C Disk was full.
CALLED  : OS, -, aio_return
OSERR   : ENOSPC (28) "No space left on device"
DATA #1 : File descriptor, 4 bytes
366
DATA #2 : unsigned integer, 8 bytes
16384
DATA #3 : signed integer, 8 bytes
175112192
DATA #4 : String, 105 bytes
Search for ossError*Analysis probe point after this log entry for further
self-diagnosis of this problem.

2020-08-06-12.34.19.069230+480 I1861221584A3234     LEVEL: Error (OS)
PID     : 20775018             TID : 30934          PROC : db2sysc 0
INSTANCE: istrpt               NODE : 000           DB   : AMRPTDB 
HOSTNAME: hasmdbp01
EDUID   : 30934                EDUNAME: db2pclnr (AMRPTDB) 0
FUNCTION: DB2 Common, OSSe, ossErrorIOAnalysis, probe:100
CALLED  : OS, -, aio_return
OSERR   : ENOSPC (28) "No space left on device"
DATA #1 : String, 132 bytes
A total of 4 analysis will be performed :
 - User info
 - ulimit info
 - Target file info
 - File system

 Target file handle = 366
DATA #2 : String, 188 bytes
  Real user ID of current process       = 1002
  Effective user ID of current process  = 1002
  Real group ID of current process      = 1002
  Effective group ID of current process = 1002
DATA #3 : String, 381 bytes
Current process limits (unit in bytes except for nofiles) :
  mem     (S/H) = unlimited / unlimited
  core    (S/H) = unlimited / unlimited
  cpu     (S/H) = unlimited / unlimited
  data    (S/H) = unlimited / unlimited
  fsize   (S/H) = unlimited / unlimited
  nofiles (S/H) = unlimited / unlimited
  stack   (S/H) = 4294967296 / 4294967296
  rss     (S/H) = unlimited / unlimited
DATA #4 : String, 41 bytes
current sbrk(0) value: 0x0000000137b86300
DATA #5 : String, 265 bytes
Target File Information :
  Size               = 1274413056
  Link               = No
  Reference path     = N/A
  Type               = 0x8000
  Permissions        = rw-------
  UID                = 1002
  GID                = 1002
  Last modified time = 1596688459
DATA #6 : String, 363 bytes
File System Information of the target file :
  Block size        = 4096 bytes
  Total size        = 5368709120 bytes
  Free size         = 0 bytes
  Total # of inodes = 2464
  FS name           = N/A
  Mount point       = /istrpt
  FSID (major,minor)= 4, 1
  FS type name      = jfs2
  DIO/CIO mount opt = None
  Device type       = N/A
  FS type           = 0x6
CALLSTCK: (Static functions may not be resolved correctly, as they are resolved to the nearest symbol)
  [0] 0x0900000009DE00E0 pdOSSeLoggingCallback + 0x59C
  [1] 0x0900000000C3387C oss_log__FP9OSSLogFacUiN32UlN26iPPc + 0x1BC
  [2] 0x0900000000C33CF0 ossLogSysRC + 0x70
  [3] 0x0900000000C5C23C ossErrorIOAnalysis__FCPC21OSSErrorAnalysisParam + 0xD7C
  [4] 0x090000000BFBBD9C sqloSystemErrorHandler + 0x514
  [5] 0x090000000BFB93A0 sqloCheckIoResults__20SQLO_LIO_HANDLE_DATAFUliP11SQLO_IO_REQ@OL@21304 + 0x1D8
  [6] 0x090000000BFBD6D8 sqloCheckIoResults__24@88@SQLO_LIO_HANDLE_DATAFUliP11SQLO_IO_REQ + 0x308
  [7] 0x090000000A0F9F50 sqloLioAIOCollect__20SQLO_LIO_HANDLE_DATAFUlP23SQLO_LIO_COLLECT_STATUSPP11SQLO_IO_REQ13SQLO_LIO_PORT + 0x1730
  [8] 0x090000000A118664 sqloLioCollectNBlocks + 0x38
  [9] 0x090000000A1464A4 sqlbClnrCollectSomeAIO__FP12SQLB_CLNR_CBUl + 0x70
  [10] 0x090000000A13EB70 sqlbClnrEntryPoint__FP12sqbPgClnrEdu + 0x30
  [11] 0x090000000A159AD0 sqlbClnrEntryPoint__FP12sqbPgClnrEdu + 0x91C
  [12] 0x090000000AECCF98 RunEDU__12sqbPgClnrEduFv + 0x34
  [13] 0x090000000A840704 EDUDriver__9sqzEDUObjFv + 0x3F0
  [14] 0x090000000A3AE4C4 sqloEDUEntry + 0x3A4
  [15] 0x0900000000567E10 _pthread_body + 0xF0
  [16] 0xFFFFFFFFFFFFFFFC ?unknown + 0xFFFFFFFF

参与8

2同行回答

tongshuaitongshuai数据库工程师北京新数科技有限公司
先看看告警时候文件系统使用率情况,这个很有可能是临时表空间存储满了。显示全部

先看看告警时候文件系统使用率情况,这个很有可能是临时表空间存储满了。

收起
互联网服务 · 2020-08-11
浏览1621
  • amsc  amsc
    感谢您的回复,但是你所提到的问题我这边都是正常的 文件系统使用率都是在正常范围没有到90%的,报错中表示挂载在/istrpt目录下,这个目录的使用率也才47% 表空间使用率跟之前每天巡检的时候是一样的,无异常
    2020-08-12
  • amsc  amsc
    刚刚看了一下临时表空间确实满了 一个系统自带的一个用户临时表空间,都满了。那么我现在再创建一个临时表空间应该能避免这个报错了吧?
    2020-08-12
atpeace331atpeace331数据库管理员银行
一楼专家正解,表空间的所在的文件系统满了。显示全部

一楼专家正解,表空间的所在的文件系统满了。

收起
银行 · 2020-08-13
浏览1381
amsc 邀答

提问者

amsc
数据库管理员wu
擅长领域: 存储灾备新核心系统

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2020-08-11
  • 关注会员:3 人
  • 问题浏览:2745
  • 最近回答:2020-08-13
  • X社区推广