SQL Server如何截断(Truncate)和收缩(Shrink)事务日志
当SQL Server截断事务日志时，它仅仅是在虚拟日志文件中做个标记，以便不再使用它，然后准备以重用形式来做备份(假如运载在完整或是批量日志恢复模型)。也就是说，在使用简单恢复模型时，事务日志包括如下的日志记录：
当checkpoint发生时，虚拟日志文件1、2不再被使用，因为事务1、2已经被提交了，而且日志记录也不再需要回滚了。然后SQL Server重用虚拟日志文件1、2，如下图：
这就是我们所熟知的事务日志截断。基本上，事务日志的活动区间已经被截断了，但是事务日志的物理大小不会改变，除非数据库使用自动收缩的属性设置。在这种情况下，事务日志就会尽可能的在物理上进行周期性的收缩。
为了物理上减小事务日志的大小，收缩事务日志作为已知的方法，你在使用时可以选择下面选项中的一种：
执行 DBCC SHRINKDATABASE命令
执行 DBCC SHRINKFILE命令
设置数据库的事务日志自动收缩选项
需要注意的是，事务日志仅仅能收缩到虚拟日志文件的边界。下面是个例子。
我新建了一个数据库，它有1MB的事务日志空间，5MB的自动增长空间。运行DBCC LOGINFO显示如下：
这里有四个可变大小的虚拟日志文件。然后我输入一些数据，这会使事务日志 增长到5MB：
在新的5MB事务日志区间里面新建了4个新的虚拟日志文件。每一个新建的虚拟日志文件都是1310720bytes，每7个虚拟日志文件正在使用时(状态是2)。我现在备份事务日志，因此将会截断事务日志：
目前仅仅有一个虚拟日志文件在使用(第7行，状态为2). 假如我现在用下面的命令，试着把日志收缩到2M：
DBCC SHRINKFILE ('AdventureWorks_log', 2)
因为活动日志记录是虚拟日志文件7，所以SQL Server仅仅删除虚拟日志文件8。这次事务日志从7MB收缩到4.7MB. SQL Server也在事务日志中新建了假的入口，为了移除2MB点之前的最近活动日志记录，以便于它包裹到虚拟日志文件2（注意状态为2的行）。
假如现在再次备份事务日志的话，事务日志会再次被截断，现在活动区间就是虚拟日志文件2了。
如果我现在再尝试一次收缩文件的话，SQL Server则会成功的收缩到2MB左右，因为日志的活动区间已经接近2MB了。文件被收缩到最接近于日志登记时的大小。这时DBCC LOGINFO的输出如下：
事务日志文件大小为2359296bytes(虚拟日志文件大小总量要加上8192字节的头信息)
所以如果你发现你不能收缩事务日志到一个指定的范围，运行DBCC LOGINFO，然后检查虚拟日志文件的范围，弄清楚每一�
相关文档：
系统环境：Windows 7
软件环境：Visual C++ 2008 SP1 +SQL Server 2005
本次目的：编写一个航空管理系统
这是数据库课程设计的成果，虽然成绩不佳，但是作为我用VC++ 以来编写的最大程序还是传到网上，以供参考。用VC++ 做数据库设计并不容易，但也不是不可能。以下是我的程序界面，后面 ......
（1）整合简单,无关联的数据库访问：
如果你有几个简单的数据库查询语句,你可以把它们整合到一个查询中(即使它们之间没有关系)
（2）删除重复记录：
最高效的删除重复记录方法 ( 因为使用了ROWID)例子：
DELETE from EMP E WHERE E.ROWID > (SELECT MIN(X.ROWID)
from EMP X WHERE X.EMP_NO = E.EM ......
如果想查找“_cs”结尾的的账户
select * from [user] where loginname like '%_cs'是不行的，_ 被认为是任意的字符，
所以需要转义字符，有两种写法：
select * from [user] where loginname like '%[_]cs'
select * from [user] where loginname like '%/_cs' escape'/'
通配符含义
%
包含零个或更多字� ......
最近需要测试一个项目, 需要SQL SERVER 2008, 在微软下载评估版后进行安装
中间发现了种种安装失败的问题，对该过程进行了记录，希望给遇到此类问题的朋友们共同探讨，有所帮助：
1. WINDOWS 2003, WINDOWS 7 新装的时候可行，但是如果有删除后重新安装则无法再次安装
2. 根据网上无数先驱的失败提示， 进行了无数重试， ......
