数据库向外的可观测性
胖头鱼的鱼缸约 3 分钟数据库管理-第307期 数据库向外的可观测性（20250328）
作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE Partner10年数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著名社恐（社交恐怖分子）公众号：胖头鱼的鱼缸
CSDN：胖头鱼的鱼缸（尹海文）
墨天轮：胖头鱼的鱼缸
ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭
首先，补充一下前一篇文章的一些后续的总结：
使用PLSQL Developer的命令窗口，执行大规模操作，包括DML和DDL时，如果程序挂死或直接中断退出（易出现），大概率会造成数据库出现D状态进程，因此还是建议用命令行界面来执行相关操作 即便是找到了对端进程，KILL对应进程甚至是重启服务器，数据库侧的D状态进程及其关联会话仍可能造成阻塞，需要较长时间释放，还是得重启数据库服务器
本期后面内容不分段。
在写前一篇文章的时候，我就在思考一件事，通过Oracle的v$session视图，是可以比较方便的对本机对应进程和客户端服务器相关信息（主机名、程序名、进程号等）进行检索的（当然主机名有时候不如IP好使），从而可以一定程度上解决非正常D状态进程带来的问题。一直以来，对于数据库的监控我们一直在强调可观测性，这在一定程度上强调的是数据库对内的可观测性，比如数据库有多少会话连接，其中有多少在运行，运行了哪些语句，运行状态如何，等待事件有哪些，有没有锁等等；另一方面则是自身运行状态，组件是不是都存活，有没有挂死的进程，是否还能正常访问等等。
写完上一篇文章，我就把草稿发给了一家做国产数据库的兄弟，问他如果遇到相同的问题，通过数据库内部的各种查询能用类似的方法解决么？那兄弟思索了片刻，回答了两个字：不行，因为很多信息没有实现实时在数据库中展示。转过头回去看Oracle，vsession和vprocess的功能是非常强大的，它们能帮助解决绝大多数本机和客户机的相关问题（对于历史问题还有v$active_session_history），这就是数据库向外的可观测性，对于主机和客户端。但这样就足够了么？
我认为是不够的，其实在数据库运维的过程中，很多时候我们发现的问题都不是数据库本身，数据库要运行在操作系统、虚拟化或容器化平台之上，再往下是硬件，而往外是通过网络与客户端应用程序连通，数据库向外的可观测性应该包含前面的所有内容。特别是网络层面，网络的不稳定性造成了其延迟和带宽都会存在波动，甚至会丢包，往往应用侧到数据库的问题大多也因此产生，如果数据库向外的可观测性可以做到对每个外来连接的双向监控，这对全流程的应用性能与故障分析会有非常大的助益，这一部分也更像是APM需要监控的一部分。
其实数据库向外的可观测性，对硬件、操作系统、虚拟化或容器平台、以及网络都是有非常成熟的方案，与其说是数据库向外的可观测性，还不如说是数据库周边环境监控的整合。最重要的是，数据库向内与向外的可观测性必须结合起来，内外监控的联动，可以提供全链路的可观测性方案。当然不得不说有些数据库本身在“内外兼修”这块做的确实不大好，是不是引入进程/线程模型分析甚至是引入AI来内外兼顾，可以考虑考虑。
最后，当基于数据库的向内向外的可观测性都做的差不多了，肯定有海量的可展示指标内容，怎么展示效果最好，那就得看不同的人的不一样的需求，根据其痛点展示不同侧重点的内容。
连续加班两天了，昨天凌晨3点睡的，今天凌晨6点睡的，两个白天还都在解决其他问题。想到，写出来，也就不管流量如何发了。
老规矩，其实也没啥规矩。