前段时间，一位做数据库运维的朋友，数据库出现了一些问题。现象是活动会话数突然增加，然后数据库突然宕机。由于停机时间和系统上没有安装监控工具，分析起来很困难。而我身处异地，也帮不了他分析好。从宕机前一小时的AWR报告来看，当时的负载并不高，等待事件主要是DBCPU的开销，第二和第三是latch:sharedpool和logfilesync。重启数据库后，当前状态还是正常的，负载小了很多，所以不太好分析问题。于是我建议他下载D-SMART社区版，跑一两天数据，然后发给我，我远程帮他分析。他昨晚发的数据，10M左右。这几天因为疫情一直在远程办公。早餐后，我正在输入这段文字并上传数据。通过VPN远程还是比较慢的，上传速度只有142K/秒，好在文件不大，74秒就上传到了我们实验室的服务器。然后启动Hula并将其上传到D-SMART。数据上传后，我可以在实验室观察D-SMART中的数据。从健康的角度来看，系统存在一定的波动。找一个点看雷达图，可以看到在负载和并发维度上丢失了一些点。点击查看详情，发现hardparsingpersecond比较严重。单击调用历史查看工具。可以看出硬解析波动剧烈，最高值接近400/秒。结合前天看到的一些AWR报告中的情况。这个系统似乎总是有更多的共享池等待事件在前面。很可能这个系统的波动与高硬分辨率有关。就在几天前，一家银行发来了一个类似的案例。最后定位也是hardparsing导致执行性能下降，所以我分析了两者的特点，很多特点很相似。所以看到数据的时候，建议客户今天尝试调整一下cursor_sharing参数。从这个案例中，我也总结出一个故障模型，即如果活跃会话数超过一定的阈值，软解析的比例异常下降，而硬解析的数量异常不低于逻辑CPU的两倍，然后系统中存在性能风险。随着下一个D-SMART补丁包的发布，该模型可以更新到D-SMART数据库中。就这样，我们用了不到20分钟的时间帮助一个朋友远程分析了问题，同时总结了一个新的知识点。这种站点和一线运维的交互，有共同的数据视角和标准化的工具。而且它变得更简单、更高效。也正是因为如此，我们的小团队才可以免费为很多朋友远程分析问题。前段时间有个朋友让我帮他远程分析一个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为媒介，建立一个共同知识积累的社区，大家一起分析数据，积累运维经验，把知识存储在一个人人都可以使用的知识图谱中，可以帮助我们的数据库在未来信创用户解决大问题。
