设为首页 收藏本站
查看: 656|回复: 0

[经验分享] [转]db2diag.log的资料收集(DB2日志文件)

[复制链接]
发表于 2016-11-16 07:22:25 | 显示全部楼层 |阅读模式
  db2diag.log文件中的标记都表示什么含义?
环境:
产品: db2 udb
平台: Cross Platform
软件版本: v6, v7, v8
  问题描述:
db2diag.log文件中的标记都表示什么含义?
  解答:
对db2diag.log文件的正确分析往往是排除错误的第一步, 该文件位于数据库管理器的配置参数DIAGPATH指定的目录下.下面是db2diag.log的部分摘取, 我们来分析一下它们的含义.
  (1) 2002-05-17-17.30.32.140000 (2) Instance:DB2MPP (3) Node:000
(4) PID:2204(db2bp.exe) (5) TID:2224 (6) Appid:*LOCAL.DB2MPP.020517213032
(7) database_utilities (8) sqlubckp (9) Probe:26
DiagData
(10) 2cfc ffff
2002-05-17-20.17.20.793000 Instance:DB2MPP Node:000
PID:596(db2syscs.exe) TID:2176 Appid:
base_sys_utilities sqleMergeSqlca Probe:20 Database:SAMPLE
Received sqlcode 1496 for request 8000001e from node number 1
(11) Data Title:SQLCA PID:596 TID:2176 Node:000
sqlcaid : SQLCA sqlcabc: 136 sqlcode: 1496 sqlerrml: 0
sqlerrmc:
sqlerrp : SQLESRSU
sqlerrd : (1) 0x00000000 (2) 0x00000000 (3) 0x00000000
(4) 0x00000000 (5) 0x00000000 (6) 0x00000001
sqlwarn : (1) (2) (3) (4) (5) (6)
(7) (8) (9) (10) (11)
sqlstate:
  1. 表示记这条日志时的时间戳
2. 实例名. 该例子中的实例名是db2mpp
3. 分区号. 在单分区的数据库中该值总为0
4. 应用或代理的进程ID.
5. 应用或代理的线程ID. 该值只有在windows平台上有效.
6. 应用ID. 该值对应于LIST APPLICATIONS命令的输出.每一个应用都有唯一的应用ID.
7. 组件名称(component).
8. 报错或信息的功能模块名, 该功能模块从属于上面的组件.
9. 功能模块的probe point. 对应于返回错误和信息的功能模块的源代码的位置.
10. 诊断信息. 该例子中的db2diag.log文件来源于Windows平台, 所以dump的信息是反字节顺序的.为了把该信息转化为sqlcode, 您需要把2cfc ffff转化成为 ffff fc2c同时从十六进制转化为十进制.请注意该值并不是都能转化为有效的sqlcode的.
  如何使用 DB2 v8.2 新提供的 db2diag 执行程序对 db2diag.log 文件进行过滤和查找?
  
环境 产品:DB2 UDB
平台:跨平台
版本:v8.2
  问题 对在 DB2 v8.2 产品中提供的新的诊断辅助工具 db2diag 所常用的几个功能进行简单的举例说明。
  
解答 为了方便用户对 DB2 诊断日志文件 db2diag.log 提供的信息的理解,在 DB2 v8.2 中增加了 db2diag 这一辅助诊断工具,这里结合几个具体举例,对其常用的一些功能加以介绍。
  该可执行程序:db2diag 位于以下路径:
  Unix 平台 - $HOME/sqllib/bin
Windows 平台 - SQLLIB\BIN
  
1. 在多分区实例下,可查看 db2diag.log 文件中指定分区的所有信息。如:用户因第四个分区上的数据库出现问题而仅希望查看该分区信息时,可使用以下命令:
  db2diag -n 4
  输出的所有信息都将包含在“NODE: 004”中,参看下面的部分输出。
  2004-10-11-19.01.57.744218-300 E7115837C971 LEVEL: Event
PID : 119664 TID : 1 PROC : db2star2
INSTANCE: dimi NODE : 004
FUNCTION: DB2 UDB, base sys utilities, DB2StartMain, probe:911
MESSAGE : ADM7513W Database manager has started.
START : DB2 DBM
DATA #1 : Build Level, 124 bytes
....
  
2. 要显示 db2diag.log 文件中所有关于 119664 进程的信息,可利用以下命令:
  db2diag -pid 119664
  2004-10-11-19.01.56.555034-300 I7109918C313 LEVEL: Event
PID : 119664 TID : 1 PROC : db2star2
INSTANCE: dimi NODE : 000
FUNCTION: DB2 UDB, config/install, sqlfLogUpdateCfgParam, probe:30
CHANGE : CFG DBM: "Instance_Memory" <automatic> From: "11126" To: "11126"
....
  结合上述两种用法,以下命令将抽取 db2diag.log 文件中分区 0 和 4 上所有 119664 进程的相关信息:
  db2diag -pid 119664 -n 0,4
  
3. 为显示 db2diag.log 文件中包含的时间戳“2004-11-02-11.00.907665-360”之后的所有信息,可用下述命令:
  db2diag -time 2004-11-02-11.00.907665-360
  
4. 另外一个较有用的选项是“-rc”。对于以前的 DB2 版本,用户经常希望了解的 db2diag.log 中的常出现十六进制返回码所提示的信息,在 v8.2 上,如果使用该选项便可得到关于这些十六进制返回码的解释。如对于以下一段信息:
  2004-10-19-12.19.46.033037-300 I7202340C354 LEVEL: Severe
PID : 139048 TID : 1 PROC : db2hmon 4
INSTANCE: dimi NODE : 000
FUNCTION: DB2 UDB, routine_infrastructure, sqlerFmpOneTimeInit, probe:100
MESSAGE : DiagData
DATA #1 : Hexdump, 4 bytes
0x2FF225B0 : FFFF FBEE ....
......
  为了解十六进制 0xFFFF FBEE 所提示的信息,可使用下面的命令:
  db2diag -rc FFFFFBEE
  其输出为:
  Input ECF string 'FFFFFBEE' parsed as 0xFFFFFBEE (-1042).
ERROR: ../sqz/sqlzwhatisrc.C:
Input ZRC 0xFFFFFBEE (-1042) cannot be identified as a V7 or V6 ZRC value
  即该返回码提示的错误码为:SQL1042C,用户可使用:
  db2 "? sql1042"
  获得关于这个错误的具体解释。
  
5. 为显示 db2diag.log 中所记录的严重错误,使用:
  db2diag -gi "level=severe"
  输出可参看例 4 中提供的。
  
如果要得到有关该工具的更多选项的帮助信息,可使用:
  db2diag -h
  使用db2diag工具的高级选项过滤查找db2diag.log诊断日志记录
  内容
提要 db2diag.log是DB2中非常重要的诊断日志,一般出现问题后,首先就要查看db2diag.log文件。但是很多时候特别是在多分区数据库中, 查看db2diag.log变得非常费时。因为所有分区所有应用程序的诊断日志都会写到DB2的诊断日志中。从DB2版本8.2开始,DB2提供了 db2diag工具可以用来过滤查找特定的日志,您可以参见下面的文档获得使用db2diag的基本方法: http://www-900.ibm.com/cn/suppor ... DocId=1807545B21000
有时候我们需要做一些更高级的过滤查询,以便帮助我们进一步诊断问题,该文章通过例子对于db2diag中的高级选项做了介绍。
正文 首先简单介绍db2diag.log中的条目构成,如下所示为一条标准的db2diag.log日志条目:
2005-12-26-19.09.14.702039+480 I84831569A398 LEVEL: Severe
PID : 1060946 TID : 1 PROC : db2agent (XXXX) 0
INSTANCE: db2inst1 NODE : 000 DB : XXXX
APPHDL : 0-222 APPID: C0A86402.OD11.03F806110349
FUNCTION: DB2 UDB, relation data serv, sqlrr_fetch, probe:20
RETCODE : ZRC=0x80120086=-2146303866=SQLR_PRTCLE "DRDA Protocol Error"
  其中上面的黑体字部分是我们的每条诊断日志的不同列标识。其中FUNCTION包含:PRODUCT,COMPONENT,FUNCNAME,PROBE, 这几个也是可以单独搜索的列标志。
  利用db2diag工具的-g选项可以对每一个列标志进行搜索,下面是-g选项的说明:
  -g: 搜索符合搜索一系列“<列标志>=<列值>”条件的诊断日志记录,条件中间使用逗号分开。搜索区分大小写。
-gi: 功能等同于-g,搜索不区分大小写。
-gv: 搜索不符合一系列“<列标志>=<列值>”条件的诊断日志记录,条件中间使用逗号分开。搜索区分大小写。
-gvi:功能等同于-gv,搜索不区分大小写。
  另外我们的条件表达式支持如下几种:
  = 全字精确匹配查询
:= 部分匹配模糊查询
!= 查找不符合全字精确匹配查询条件的记录
!:= 查找不符合部分匹配模糊查询条件的记录
^= 选择查找列中以后面的查找条件开头的记录
!^= 选择查找列中不以后面的查找条件开头的记录
  关于高级查找功能的帮助,您可以随时通过"db2diag -h filter" 获得。
  另外db2diag还对于特定的列标志提供了快捷选项,如LEVEL,可以使用-l选项指定,NODE可以使用-n选项指定。下面我们就以几个例子演示一下如何使用高级查找功能:
  1、查找应用程序句柄APPHDL为0-222的所有诊断日志条目:
  db2diag -g APPHDL="0-222"
  2、查找应用程序句柄APPHDL为0-222在分区0上的所有诊断日志条目:
  db2diag -g APPHDL="0-222",NODE=000
  3、查找进程1060946的所有严重错误(Severe):
  db2diag -g PID=1060946,LEVEL=Severe
  4、查找所有FUNCTION名称中包饭fetch的诊断日志条目:
  db2diag -g FUNCTION:=fetch
  5、查找所有component名称以"base sys"开头的诊断日志条目:
  db2diag -g "COMPONENT^=base sys"
  6、查找所有返回码为"ZRC=0x80120086"的记录:
  db2diag -g RETCODE:=0x80120086
  除了过滤查找之外,db2diag还可以格式化输出。您可以指定查找结果的输出格式。关于格式化输出的详细帮助,请使用"db2diag -h fmt"命令查看。下面简单介绍一个例子:
  db2diag -time 2005-12-22 -node "0,1,2" -level "Severe, Error" |db2diag -fmt "Time: %{ts} Partition: %node Message Level:%{level} \nPid: %{pid} Tid: %{tid} Instance:%{instance}\nMessage: @{msg}\n"
  该命令将查找2005年12月22日以来在分区0,1,2上错误级别为Severe和Error的错误,并按照下面的格式输出:
  Time: 2005-12-28-14.32.01.067843 Partition: 000 Message Level:Error
Pid: 1871948 Tid: 1 Instance:db2inst1
Message: ZRC=0x860F000A=-2045837302=SQLO_FNEX "File not found."
DIA8411C A file "" could not be found.
  db2diag工具非常强大,您可以查看DB2信息中心获得db2diag的进一步使用帮助:
  http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/core/r0011728.htm
  参考资料:
1、DB2 Information Center: http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp
  本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/anyoneking/archive/2007/11/29/1907206.aspx

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-300893-1-1.html 上篇帖子: DB2 "APP_CTL_HEAP_SZ" 堆中没有足够的存储器可用来处理语句 下篇帖子: DB2,用控制中心连接远程数据库
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表