## 突然变慢的 SQL 与无法掌握的运行状况实态 支撑业务系统或内核系统的数据库，平时看起来运作正常，但某天可能会突然发生 SQL 回应变慢的情况，导致现场应对压力骤增。特别是对于拥有制造、金融、电信等「不可停机系统」的企业而言，故障或性能问题一旦发生，业务影响极易扩大，因此需要迅速掌握原因。日本エクセム（Nihon Exem）希望以 MaxGauge 为内核，针对实际面临困扰的用户企业，提供包含诊断与顾问服务在内的提案，将故障处理视为商机转化的起点。 另一方面，能够设置专门负责数据库人才的企业并不多，实际上由信息部门、基础设施负责人或开发负责人兼任故障处理的情况屡见不鲜。因此，发生故障时，虽然能看到「现在发生了什么」，却无法整理出「为什么变慢」或「应该从哪里开始追查」，导致应对高度依赖于特定负责人。根据客户的回馈，能将数据库问题视为己任深入追查的人非常有限，多数人实质上都抱着「想交给别人处理」的想法。 ## 片段式日志无法追查，故障与性能应对过度依赖个人 在故障与性能问题长期化的现场，瓶颈往往不只是调查困难，更在于追查原因所需的信息仅以片段形式存在。虽然有日志或监控数据，但事后无法按时间顺序重现故障发生时的状况，也无法区分是数据库引起还是应用程序引起，更无法锁定到 SQL 或工作阶段（Session）单位。其结果是，只能依赖日志分析或供应商的应对，陷入一种「优先恢复系统但原因追查仅限于少数人」的结构性困境。客户也指出，故障发生时几乎没有用于整理事象与取得证据的数据，且现场缺乏具备故障处理能力的人才，这是极大的挑战。 结果导致了恶性循环：「虽然恢复了系统，但终究无法解释为何发生」、「在根本原因未整理的情况下，类似问题重复发生」、「因为只有特定负责人能追查，无法摆脱个人化应对」。本次研讨会的特点在于，并非单纯介绍原因锁定的技术，而是将其整理为「如何改变这种个人化故障与性能应对」的维运课题。客户方也表示，不希望内容过于偏重产品，而是希望从提出问题开始，最后引导至「解决问题的工具正是 MaxGauge」这一流程。 ## 追踪 SQL 单位，并将原因锁定与防止再发链接的维运模式 本研讨会将针对突然变慢的 SQL 或故障性能问题，整理为何原因追查会变得个人化，并解释如何将片段日志或监控无法完全掌握的状况进行时间串行的可视化，以及如何按 SQL 与工作阶段单位进行追踪。MaxGauge 的优势在于不仅能进行即时监控，还能回溯历史重现并分析故障时的状况。其特点是能够支持事象整理与证据取得，并结合专家的支持进一步进行原因锁定与改善方案的探讨。 此外，内容将不局限于「找到原因」，还会探讨如何打造一个能够「解释原因」的状态，并链接到如何防止问题再发。在与客户的交流中也确认，「回顾、说明、防止再发」是共同的目标，且希望不仅限于 MaxGauge 单体产品，而是能链接到包含诊断与顾问服务在内的综合提案。本研讨会是一个契机，让企业思考如何摆脱对故障性能问题的「随机应变」，创建一个任何人都能追查、解释并落实改善的数据库维运模式。 ## 推荐对象 - 对于突然变慢的 SQL，谁该追查原因变得模糊不清的人。 - 每次发生故障或性能问题，应对工作都集中在特定负责人身上的人。 - 因为片段日志或监控信息无法掌握全貌，导致调查时间拖长的人。 - 难以区分是数据库引起还是应用程序引起问题的人。 - 不想止步于原因锁定，希望链接到说明责任与防止再发的人。 ## 主办 / 协办 日本エクセム株式会社（Nihon Exem） ## 合作 株式会社开源软件活用研究所（Majisemi 相关） Majisemi 株式会社（マジセミ）