1. 遇到问题
最近，公司的MSSQL数据库又崩溃了，无法启动，我们马上展开了一系列排查工作。我们检查了防病毒软件、数据文件及磁盘空间等因素，但没有发现任何异常。接下来，我们对系统日志和错误日志进行了仔细地分析，结果发现以下内容：
2019-01-10 17:02:42.04 spid5s Failed allocate pages: FAIL_PAGE_ALLOCATION 1
2019-01-10 17:02:42.04 spid5s A system assertion check has failed. Check the SQL Server error log for details
2019-01-10 17:02:42.04 spid5s Error: 16006, Severity: 16, State: 1.
2019-01-10 17:02:42.04 spid5s Internal error: An expression services limit has been reached. Please look for potentially complex expressions in your query, and try to simplify them.
2019-01-10 17:02:42.04 spid5s Error: 3624, Severity: 20, State: 1.
通过以上错误信息，我们初步确定这是一个内部错误，并且可能是源于复杂的查询语句。然而，这并没有让我们找到根本的解决方法。我们需要进一步进行排查工作。
2. 排查过程
2.1 进一步分析SQLServer日志
为了进一步了解问题，我们需要深入分析SQLServer日志。运行SQL Server Management Studio，并使用管理员账户登录，打开“SQL Server Logs”窗口。查找最后崩溃时间点的日志记录，并分析以下信息：
数据库最后一次成功的备份时间，以及备份方式
数据库的文件组是否存在问题
系统磁盘上是否存在I/O错误或操作系统错误
在仔细分析SQLServer日志后，我们得出了以下结论：
数据库的自动备份功能一直正常工作，最后一次备份的时间是前一天晚上。
数据库文件没有任何问题。
系统上不存在I/O错误或操作系统错误。
2.2 进一步分析应用程序日志
我们还需要对应用程序的日志进行分析。我们找到了错误最后发生时刻的Web服务器日志，并仔细分析了每个HTTP请求的性能和响应时间。结果表明，错误事件并没有发生在Web服务器上，我们需要进一步排查MSSQL服务器。
2.3 进行“故障注入”测试
在分析日志后，我们必须要确认问题真正出现的位置。我们从旧行程中找到最近一次的备份文件，将其恢复到SQL Server上并启动服务。如果服务能够正常工作，这意味着问题是由于特定的数据造成的，这些数据属于最新一次备份以后新增的。否则，问题应该是在备份的过程中出现的，这可能意味着备份文件本身存在问题，需要找到正确的备份文件进行还原。
3. 解决方案
3.1 创建一个临时表解决问题
经过对错误日志的深入分析，我们发现问题主要是出在一些复杂的查询语句上，可能是由于SQL Server特性而导致的。我们打算通过创建一个临时表来解决问题。
下面是我们采用的解决方案：
创建一个新的存储过程，该存储过程复制原始表中的所有数据，数据类型与原始表完全相同。
启动MSSQL服务器，执行存储过程，将表数据复制到临时表中。
在临时表上运行问题查询，检查查询结果是否符合预期。
如果查询结果正确，则修改原始查询，并删除临时表。如果查询结果不正确，则进行进一步排查。
这种解决方案的优点是安全、简单、快速，并且能够消除大多数用户对表结构和查询的不稳定性的担忧。
3.2 重建索引
我们还发现，问题可能与索引有关。因此，我们要重新构建表上的索引，以确保数据库的稳定性。
下面是我们采用的重建索引方案：
使用MSSQL补充工具（Maintenance Plan Wizard）来创建简单的重建索引方案，以同时处理多个表。该计划应该定期运行，以确保数据库保持优化状态。
对于需要特别维护的表，可以使用更详细和复杂的重建索引方案。该计划可以根据表的特定要求来定义，例如检查表中的非聚集索引，并调整其缓存大小。
4. 总结
本次MSSQL数据库崩溃的排查工作令我们受益匪浅，让我们发现了一些非常有用的解决问题的技术和方法。首先，我们需要深入分析SQL Server和应用程序日志，找出问题的根源。之后，我们有效地使用了“故障注入”测试，通过分布复制的临时表来检查问题查询。我们还重建了索引。
综上所述，我们通过对MSSQL数据库的全面排查工作，得出了许多有价值的结论和建议。希望这些技巧和方法能够帮助您解决自己的数据库问题。