我一直在研究一个问题，诊断为有人将SQL Server数据库的兼容性模式从SQL Server 2005中的80到90更改为数据库的兼容性模式设置为80，因为旧版存储过程代码没有升级。
我发现在更改兼容模式时，这不会logging在SQL Server日志中。
有没有人看到这个问题，这是一个错误，或者有一个替代方法来跟踪这些变化？
当然logging。 简单的breazyvalidationtesting：
create database foo alter database foo set recovery full backup database foo to disk='nul:' go exec sp_dbcmptlevel 'foo', '80' go use foo select * from fn_dblog(null, null) go 变化将在那里看到：
LOP_MODIFY_ROW LCX_BOOT_PAGE ... 0x50
数据库的启动页面已将兼容级别更新为0x50（或“80”）。
此外，更改logging到ERRORLOG：
2010-04-08 16:15:39.37 spid52 Setting database option COMPATIBILITY_LEVEL to 80 for database 'foo'.
它还创build一个系统NT事件日志事件：
Log Name: Application Source: ... Date: 4/8/2010 4:15:39 PM Event ID: 5084 Task Category: Server Level: Information Keywords: Classic User: ... Computer: ... Description: Setting database option COMPATIBILITY_LEVEL to 80 for database 'foo'. Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="..." /> <EventID Qualifiers="16384">5084</EventID> <Level>4</Level> <Task>2</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2010-04-08T23:15:39.000000000Z" /> <EventRecordID>4965</EventRecordID> <Channel>Application</Channel> <Computer>...</Computer> <Security UserID="S-1-5-..." /> </System> <EventData> <Data>COMPATIBILITY_LEVEL</Data> <Data>80</Data> <Data>foo</Data> <Binary>...</Binary> </EventData> </Event>
我不相信这是logging在任何地方。 这可能是在默认跟踪中，但我不这么认为。 sp_dbcmptlevel的权限仅默认为sysadmin固定服务器angular色的成员。 这缩小了谁可以执行存储过程。
通过运行服务器端跟踪，您可以检测正在执行的命令，但这可能难以pipe理。 不过这可能是唯一可行的方法。 另一种select是定期对sys.databases运行查询来检查兼容性级别和其他更改。