MS SQL Server 2005 日志文件过大
SQL Server 2005的默认设置很WoCuo- -!， 不小心就没注意，
等到出现Log文件过大，大到10G的时候，才想起来要Shrink一下。
防止遗忘：
1 use DBNAME; #选择要操作的数据库/Database Name
2 go
3 backup log DBNAME with truncate_only; #先切掉LOG文件/Backup truncatelog only first
4 dbcc shrinkfile (DBNAME_log, 1); #再压缩LOG文件/shrink the DB log file
5
2 go
3 backup log DBNAME with truncate_only; #先切掉LOG文件/Backup truncatelog only first
4 dbcc shrinkfile (DBNAME_log, 1); #再压缩LOG文件/shrink the DB log file
5
isn‘t it so easy
ps：察看当前数据库使用情况用： /get the current space usage.
exec sp_spaceused
顺便给个MS的连接，说是关于
SQL Server 中的自动增长和自动收缩配置注意事项
http://support.microsoft.com/?scid=kb%3Bzh-cn%3B315512&x=5&y=12
其中主要看：
最佳做法
- 对于受管理的生产系统，您必须将自动增长仅视为偶然的意外增长。请勿使用自动增长管理每天的数据和日志增长。
- 您可以使用警报或监控程序来主动地监控文件大小和增长文件。这有助于您减少碎片，并允许您将这些维护活动移到非高峰时段进行。
- 自动收缩和自动增长必须由训练有素的数据库管理员 (DBA) 仔细评估，而不能不对其进行管理。
- 您的自动增长增量必须足够大，以避免上一节中列出的性能影响。要在您的配置设置中使用的精确值以及增量是以百分比还是以特定的 MB 值表示取决于环境中的许多因素。一种可供尝试的通用经验规则是：将您的自动增长设置设定为文件大小的八分之一左右。
- 打开每个文件的 <MAXSIZE> 设置，以防某个文件增长到会用尽全部可用磁盘空间的大小。
- 保持事务大小尽可能小，以防出现计划外的文件增长。
CPU可能造成的SQL Server的BUG：
SQL Server timing values may be incorrect when you use utilities or technologies that change CPU frequencies
参考: http://blog.sqlauthority.com/ 很牛的SQL Server BLOG
