# 网络基本功（二十九）：Wireshark抓包实例诊断数据库常见问题 **转载请在文首保留原文出处：EMC中文支持论坛**[https://community.emc.com/go/chinese](https://community.emc.com/go/chinese) [](https://community.emc.com/servlet/JiveServlet/showImage/2-872167-108601/image001.gif) ## 介绍 通常来说，数据库，应用和网络在IT架构中处于不同的分支。数据库的故障排查由DBA来完成，但是网络工程师仍可以从抓包中定位出问题并不出自网络。当IT抱怨“网速慢”，实际并不一定是这样。下文帮助我们验证所谓“网速慢”的问题。 ## 更多信息 **工作过程:** 对于数据库问题，按照以下步骤： 1. 当怀疑是“慢速网络响应”时，问以下问题： * 问题发生于本地还是全局？是只发生在远端办公室，还是center也有发生？如果整个网络都出现问题，就不会是WAN带宽问题。 * 对于所有客户端是否都发生了这样的问题？如果只是某些特定用户碰到问题，则可能是这些用户运行了某些应用导致。 * 客户端和服务器之间通讯链路是否过载？导致过载的应用是什么？ * 是所有应用都运行缓慢，还是使用特定数据库的应用运行缓慢？是PC比较老旧，还是服务器资源耗尽? 2. 搞清楚上述问题之后，开始故障排查： 1\. 打开Wireshark开始抓包。可以将对端端口连到PC，服务器，VLAN，或连接远端客户端的路由器。 2\. 在expert info中查看TCP事件。这些事件发生在整个通信链路，或是特定的IP地址，还是特定的TCP端口？此操作能够帮助定位问题并验证是否发生于特定链路，服务器，或是应用。测试连接到Internet的数据流时，可能会得到发往站点或mail server（诸如此类）的很多重传以及重复ACK。在组织内部，重传范围应当在百分之0.1至0.5。连接到Internet时，可能会高得多。 3. 当你看到网络上有问题时，按照前几张的故障排查步骤给予解决。但是，也有些网络问题会影响数据库操作。下例中，可看到客户端与服务器通信链路往返延时达到35至40ms。 1\. 我们查看TCP stream 8（1），连接开始于TCP SYN/SYN-ACK/ACK。如下图（2）所示。可以看到整个连接花费了371个报文（3）。 [](https://community.emc.com/servlet/JiveServlet/showImage/2-872167-108602/image002.jpg) 2\. 连接继续，可见到DB请求与响应之间时间间隔大约35ms。 [](https://community.emc.com/servlet/JiveServlet/showImage/2-872167-108603/image003.jpg) 3\. 由于往返已经有371个报文，371X35 ms大约是13秒。加上可能发生一些重传导致延时，用户查询一次数据库可能要等待10至15秒。 4\. 这种情况下，应当与DBA讨论怎样大幅减少网络上传输的报文数量，或是改变终端服务器或网络接入的方式。 4. 另一个可能发生的问题是抓包文件反映出有软件问题。以下截图中可看到5个重传（1），并且客户端打开了一个新的连接（3）。看起来像一个TCP问题但只发生在软件中一个特定窗口。这只是由于一个软件进程停止运行，因此TCP无法对客户端作出响应（2）。 [](https://community.emc.com/servlet/JiveServlet/showImage/2-872167-108604/image004.jpg) **更多建议：** 右键数据库客户端与服务器会话报文，会打开一个窗口，有助于DBA查看网络问题。当碰到延时问题时，例如，通过移动电话接入Internet，数据库客户端到服务器的通讯可能效率低下。可能需要切换接入方式。 很重要的一点是搞清楚数据库的工作模式。如果客户端正在接入数据库服务器，数据库服务器正在使用从另一台服务器共享的文件，可能客户端——服务器工作良好，但问题可能出在数据库服务器与文件服务器之间共享文件上。确保在开始测试之前确知所有依赖条件。 最重要的是，与DBA保持良好关系。 ## 参考 Network Analysis Using Wireshark Cookbook