检查数据库日志，有如下报错信息：
Error: 9002, Severity: 17, State: 4.The database ‘SharedServices1_Search_DB’ cannot be reused, see the log_reuse_wait_desc column in sys.databases
查看当前日志的使用情况：
这里日志并没有完全满，但已经占用70GB日志文件的79%，也有50多GB了，个人感觉这是不正常的。个人曾经读过《SQL Server 2012实施与管理实战指南》，在日志这一块有这么一段描述：
由于应用程序设计问题，有些连接可能会遗留一个事务在SQL Server里面，而不是及时提交它，SQL Server是不会干预用户的这种行为的。只要这个连接不退出，这个事务会永远存在，直到客户端主动提交或者回滚。从这个事务开启的那个时间点开始的所有日志记录，SQL Server都会保留（做过日志备份也没有用）。
所以长事务的存在是最可疑的线索。 在系统视图sys.databases中查看数据库‘SharedServices1_Search_DB’的log_reuse_wait及log_reuse_wait_desc 值：
这里可以看到log_reuse_wait_desc值为‘ACTIVE_TRANSACTION’ 也就是说日志正在等待transaction的检查点。这里进一步证明了是长事务导致了超大的事务日志是由超长事务所导致的。 关于sys.databases视图的描述参见(https://msdn.microsoft.com/zh-cn/library/ms178534.aspx+%20+%22%E5%AE%98%E6%96%B9%E8%AF%B4%E6%98%8E%22)
查看长事务：
currentdate2015
可以看到果然有长事务在运行，而且已经运行近90分钟了。 查看transaction相关信息:
select session_id,transaction_id,is_user_transaction,is_local from sys.dm_tran_session_transactions where is_user_transaction=1session_id transaction_id is_user_transaction is_local
根据session_id查看transaction具体内容：
select s.text from sys.dm_exec_connections c cross apply sys.dm_exec_sql_text(c.most_recent_sql_Handle) s where session_id=1566text.proc_MSS_Crawl …………………………
也可以通过transaction_id看一下这个事务目前的状态：
select transaction_begin_time, case transaction_type tran_Type, case transaction_state transaction_state from sys.dm_tran_active_transactions where transaction_ID=3452140915 transaction_begin_time tran_Type transaction_state/Write transaction active
确定出来语句了，就可以找开发人员一起看看是为什么了。
，坚韧是成功的一大要素，只要在门上敲得够久够大声，终会把人唤醒的。
