db2问题诊断的几个原则
其实做Problem Diagnostic是有一定思路和方法的。看到有些朋友不太得法，故抛砖引玉先。
希望有经验的朋友能跟帖把自己的经验和思路也分享一下，大家共同进步。
1）DB2诊断信息在DB2DUMP目录中
2）db2diag.log通常是db2问题诊断第一个需要看的东东也是最重要的东东。
其他信息如FODC, Trap文件, dump文件等了解问题大概情况后再看。
3）First Failure Occurence原则。
即在db2diag.log中找到”待诊断问题“ 的 ”第一次出现”位置。这点非常重要。
检查db2diag.log时，FFO错误位置之前和之后的内容都要看。特别是ERROR/SEVERE信息，WARNING的也要注意。
db2diag.log的信息还是很人性化的。经常去看db2diag.log，时间长了根据这些message你就能猜测出db2说的是什么。
4）定位、排除原则。
观察->猜测->验证->排除..。
通过这个过程逐步排除、缩小怀疑范围从而定位问题
希望有经验的朋友能跟帖把自己的经验和思路也分享一下，大家共同进步。
1）DB2诊断信息在DB2DUMP目录中
2）db2diag.log通常是db2问题诊断第一个需要看的东东也是最重要的东东。
其他信息如FODC, Trap文件, dump文件等了解问题大概情况后再看。
3）First Failure Occurence原则。
即在db2diag.log中找到”待诊断问题“ 的 ”第一次出现”位置。这点非常重要。
检查db2diag.log时，FFO错误位置之前和之后的内容都要看。特别是ERROR/SEVERE信息，WARNING的也要注意。
db2diag.log的信息还是很人性化的。经常去看db2diag.log，时间长了根据这些message你就能猜测出db2说的是什么。
4）定位、排除原则。
观察->猜测->验证->排除..。
通过这个过程逐步排除、缩小怀疑范围从而定位问题
52同行回答
举一个刚发生的例子。
某客户的OLTP系统，某天cancel一个online backup操作时，发现transaction throughput整体性能降幅明显。这个问题可以在测试系统上重现。
先不公布答案。
自己思考，然后对比答案思路可能效果更好。
大家有什么思路嘛？
比如，都需要收集哪些数据？有何猜测？如何排除缩小问题范围？收起
某客户的OLTP系统，某天cancel一个online backup操作时，发现transaction throughput整体性能降幅明显。这个问题可以在测试系统上重现。
先不公布答案。
自己思考，然后对比答案思路可能效果更好。
大家有什么思路嘛？
比如，都需要收集哪些数据？有何猜测？如何排除缩小问题范围？收起
浏览455
多谢分享 我赞同
我的理解，您的观点提到一点很重要的东西：观察->猜测->验证->排除..这是一个迭代的过程。收起
我的理解，您的观点提到一点很重要的东西：观察->猜测->验证->排除..这是一个迭代的过程。收起
浏览421
我的观点是1.先理解清楚问题的是什么2.初步判断是什么原因3.结合日志来验证自己的判断4.采取解决方案 ...棉花糖ONE 发表于 2010-11-13 14:43
赞同。我的理解，您的观点提到一点很重要的东西：观察->猜测->验证->排除..这是一个迭代的过程。通过这个过程逐步排除、缩小怀疑...