SQL Server在Ubuntu上的故障排查技巧

Ubuntu上SQL Server故障排查技巧

一 快速定位流程

• 检查服务状态：运行 sudo systemctl status mssql-server --no-pager，确认是否为 active (running)；若失败，先看状态输出的关键错误片段。
• 查看系统日志：使用 journalctl -xeu mssql-server 聚焦与 mssql-server 相关的内核与系统级日志，便于发现启动阶段的依赖、权限或资源问题。
• 查看引擎错误日志：SQL Server 引擎日志位于 /var/opt/mssql/log/errorlog，使用 sudo tail -f /var/opt/mssql/log/errorlog 实时跟踪；必要时用 grep 过滤关键字（如 “error”、“failed”、“login”）。
• 验证端口与连通：确认 1433 端口监听（sudo ss -lntp | grep 1433），并在本机用 sqlcmd -S 127.0.0.1 -U SA 测试本地连接；远程连接时排查云安全组/本机防火墙（如 sudo ufw allow 1433/tcp）。
• 复核资源与权限：检查磁盘空间（df -h）、内存（free -h），确保至少留出 2GB 可用空间与内存；确认 /var/opt/mssql 目录权限正确且服务账户具备所需权限。

二 常见故障与修复

• 服务无法启动
  • 典型根因：依赖库缺失（如 libldap、libssl）、配置文件参数不当、磁盘/内存不足。
  • 处理步骤：
    • 查看 /var/opt/mssql/log/errorlog 与 journalctl 的错误细节。
    • 修复依赖：在 Ubuntu 22.04 常见为安装 libldap-2.4-2 与 libssl1.1；在 Ubuntu 24.04 可能需要 libldap-2.5-0。示例：sudo apt-get install -y libldap-2.4-2 libssl1.1 或 sudo dpkg -i libldap-2.5-0_*.deb。
    • 资源不足时释放空间或扩容，再重启服务。
• 共享库缺失
  • 现象：启动报 “error while loading shared libraries: …”。
  • 处理：按发行版安装对应版本的 OpenLDAP 与 OpenSSL 运行时库（见上），随后重启 mssql-server。
• 连接被拒绝或超时
  • 排查顺序：本机用 127.0.0.1 验证 → 检查 1433 端口监听与占用 → 核对防火墙/安全组 → 验证 SA 密码与大小写/空格 → 远程用 sqlcmd -S ,1433 -U SA 测试。
• 配置错误导致无法启动
  • 处理：以单用户/最低配置方式启动（mssql-conf set-sa-password 等维护动作前先确保能启动），修正参数后重启；必要时再恢复为正常模式。

三 日志与转储分析

• 引擎错误日志：优先查看 /var/opt/mssql/log/errorlog，关注首次报错行及随后的堆栈信息；使用 tail -f 实时跟踪，grep 过滤 “error|failed|login|exception”。
• 系统日志：journalctl -u mssql-server -b 查看本次启动日志，-xe 获取详细上下文，有助于发现权限、依赖、OOM、磁盘满等问题。
• 故障转储：检查 /var/opt/mssql/log/ 下的核心转储或小型转储文件（如 core.、.mdmp），结合错误日志时间戳定位触发点，用于向微软支持提交工单时提供证据。

四 性能与连接诊断

• 系统层监控：使用 top/htop、vmstat、iostat、netstat/dstat 观察 CPU、内存、磁盘 I/O、网络 瓶颈；结合 df -h 与 free -h 判断资源压力。
• SQL Server 层诊断：
  • 用 SSMS 或 sqlcmd 查询 DMVs（如 sys.dm_exec_requests、sys.dm_os_wait_stats）定位阻塞与等待类型；
  • 使用 扩展事件（Extended Events） 捕获高成本查询、登录失败、异常等轻量事件；
  • 借助 SSMS 的“活动监视器”“性能仪表板”“查询执行计划”分析慢查询与资源占用。

五 配置变更与维护要点

• 修改配置：使用 mssql-conf 完成版本/语言/SA 密码/端口等设置，变更后执行 sudo systemctl restart mssql-server 使配置生效。
• 端口与防火墙：如需修改默认端口，先确保新端口未被占用并同步更新防火墙/云安全组规则；测试连通后再对外发布。
• 备份与回滚：重大配置调整前先备份数据库与关键配置；若系统数据库损坏且万不得已，才考虑重建 master/model（高风险，可能导致数据与对象丢失）。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！