前阵子有个做数据库运维的朋友有个数据库总是有些问题，前阵子问题严重的时候还宕了一次机。现象是活跃会话数突然增大，然后突然数据库就宕了。因为宕机，以及系统上没装什么监控工具，因此分析比较困难。而我在远程，也没办法很好地帮他分析。
从宕机前一小时的AWR报告上看，当时的负载并不算高，等待事件主要是DB CPU的开销，排在第二、第三的是latch:shared pool和log file sync。数据库重启后现在的状态还算正常，负载也小了很多，因此也不是太好分析问题在哪。于是我建议他下载一下D-SMART社区版，跑上一两天的数据，然后发给我，我远程帮他分析分析。
昨晚他把数据发过来了，大概10M左右。我这几天因为疫情一直远程办公，早饭后就一边敲着这篇文字，一边上传数据。
在远程通过VPN还是比较慢的，每秒只有142K的上传速度，不过还好文件不大，74秒就上传到了我们实验室的服务器上。然后启动呼啦上传到D-SMART中。
数据上传完毕后，我就可以在实验室的D-SMART中观察这些数据了。
从健康分上看，系统中的存在一定的波动。找一个点看看雷达图，可以看到负载和并发维度出现了一些丢分。
点击查看详情发现每秒硬解析比较严重。点击调用历史查看工具。
可以看到硬解析波动很厉害，最高时接近400/秒。结合到前天我看到的一些AWR报告里的情况。这个系统似乎总是存在较多的共享池等待事件排在前面。很可能这个系统的波动与这个硬解析较高有关。
正好前几天有家银行也发来了类似的案例。最终定位也是硬解析导致了执行性能下降，于是我又分析了一下两者的特点，很多特性上都十分类似。因此我看到数据的时候，就建议客户今天试试调整cursor_sharing参数。
从这个案例我也总结出一个故障模型，那就是如果活跃会话数超过某个阈值，同时软解析比例异常下降，并且硬解析数量异常并不低于逻辑CPU的2倍，则系统存在性能风险。这个模型可以随着下一次D-SMART补丁包的发布，更新到D-SMART的数据库中去。
这样，我们只花了不到二十分钟，就帮一个朋友远程分析了问题，同时也总结了一个新的知识，这种现场与一线运维的互动因为有了共同的数据视角和标准化的工具而变得更加简单了，效率也提高了很多。正是因为如此，我们这个小团队才能为很多朋友免费地远程分析问题。
前阵子有个朋友希望我帮他远程分析一个PG的性能问题，说是可以VPN连上去做。我手头的事情也比较多，大致了解这样去分析一下需要花费的时间不少，因此我建议他下载一个D-SMART，采集一些数据，我远程帮他分析一下。他可能觉得我是在推托或者说是非要推广我们的工具，可能感到不太高兴了，就没再继续沟通。实际上在没有工具的帮助下，分析一个简单的问题可能都要花上很多时间，连接远程桌面，再跳转到生产环境，上去采集数据，同时通过沟通了解现场的情况，效率比直接面对数据要低太多了。有了holadata，这一切就简单得多了。
最近这5年时间，我参与其他事情越来越少，更多的时间都用在了如何利用数据来看数据库的运行状态，从中发现问题上了，我们研发的D-SMART也已经有了数百个装机用户。我每天也会看很多D-SMART采集上来的数据，因此已经习惯了用这些数据来思考问题。
数据库运维工具是十分丰富的，种类繁多，功能与侧重点也不同，可以满足不同用户的需求。两个运维工具可能满足了用户的不同的运维场景需求，因此并不存在某个工具好或者不好的问题，只是对于某个客户是否适用而已。对于用户来说，自己用得起来，并且能够给他的运维带来帮助的工具，就是好工具。就像有些DBA总说sqlplus是最好的运维工具，不接受辩驳一样。你觉得好用的，就是好工具。
经常我给客户介绍产品的时候，他们总会提出一些需求，某某功能你有没有。实际上他们可能需要的是另外一种数据库运维或者监控工具，D-SMART可能不是他们最需要的工具。通过这样的交流，我发现D-SMART并不是每个客户都需要的工具，对于需要在现场获得一些深度分析，精准报警能力，并且能够通过工具积累运维经验的用户，可能D-SMART刚好对他们的胃口。而对于仅仅想知道数据库是不是活着，并且希望这个工具能够帮他们解决一些繁重的日常操作的用户，D-SMART帮不了他们太大的忙。
于是在去年年底我就有了做一个社区版的想法。通过免费的社区版，让需要D-SMART功能的人，认可这种知识共享，远程交流的用户主动找到我们，一起来发展D-SMART这个工具生态。另外就是利用与客户之间的监控数据分享，加快我们的知识积累的速度。
目前来看，这两个目标都有可能达成。首先通过社区版的D-SMART，目前已经积累了近300个装机用户，他们中有运维服务商，有最终用户。有些人装了，试了，觉得工具并不适合他们，就不再用了。有些用户觉得工具对他们有帮助，于是就用得越来越深了。还有的用户购买了VIP工具包，有些用户和我们的客户联系，开始了商用版的测试。让需要这样工具的朋友了解我们的工具的目的初步达成。
构建生态的工作进展慢一些，不过也已经初步有了进展。下载D-SMART的朋友中，还有一些是做数据库服务的，他们利用这个工具可以降低运维服务的工作量，从而节约成本。对于这些客户是我们推出社区版的时候有点担心的，怕让人感觉我们是在和他们抢市场。实际上我们做D-SMART这个产品，并不是要参与数据库运维这个市场竞争，而是通过工具加入到这个生态中而已。我们团队的DBA不足10人，也很难和传统的数据库运维厂商去竞争。我们是希望通过D-SMART这个纽带把最终用户、服务厂商、工具厂商都联合起来，打破壁垒，共同构建一个数据共享、知识共享、能力共享的DBAIOPS生态。通过最近的一些尝试，我们也有了更大的信心。
随着信创工作的推进，运维知识积累变得越来越重要，而信创用户又极为分散，数据库厂商又没有类似MOS这样的知识库平台，遇到问题都不知道到哪去问，到哪去查。如果能利用D-SMART作为媒介，构建一个共同知识积累的社区，大家一起来分析数据，积累运维经验，并将知识存储到一个大家都可以使用的知识图谱中去，今后可以帮助我们的数据库信创用户解决很大的问题。
