名站网址导航为大家提供关于数据库教程相关的教程网站知识。
误区 #19:Truncate表的操作办法不会被记录到日志SQL Server误区30日谈 第18天 有关FileStream的存储，垃圾回收以
误区 #18:如下多个有关FileStream的误区,全部错误,18 a)FileStream数据可以在远程存储,不能，由于FileStream数据容器(指的是存放FileStream网站网站文件的NTFS网站网站文件夹，杜撰出来的术语)必须像数据网站网站文件或日志网站网站文件那样符合本地存储策略-也就是说，这个数据容器必须放在对于运行SQL ,18 b)FileStream的数据容器可以嵌套,不能，对于同一个网站数据库的两个不同的FileStream容器可能在同一个目录下，但是却不能嵌套。而对于不同网站数据库的FileStream容器无法在同一个目录下。我的一篇博文有一段具体相关代码能说明这一点:Misc,18 c)对于FileStream的更新可以部分更新,对于任何FileStream的更新都会导致创建一个全新的FileStream网站网站文件,这个操作办法会被日志原原本本的记录下来。这也就是为什么FileStream不能被用于网站数据库镜像。这么多数据假如如果用于镜像的话,18 d)FileStream会在不需要的时候立刻被垃圾回收,错误。FileStream数据会在不再需要并且到了下一个Checkpoint的时候进行垃圾回收。这点并不是那么直接以至于很多人对FileStream的回收机制存在误区。,18 f)FileStream存放的目录以及网站网站文件名是随机取得,其实不然，FileStream的网站网站文件名其实代表的是创建其操作办法对应LSN号。表和列的GUID目录名是可以在系统表中获取到。,我下面两篇博文对此有了更详细的解释:
错误
在用户表中的操作办法都会被记录到日志。在SQL Server中唯一不会被记录到日志的操作办法是TempDB中的行版本控制。
Truncate Table数据库语句会将整个表中的所有数据删除。但删除的相关方式并不是一行一行的删除，而是将组成表的数据页释放，将组成表的相关页释放的操作办法交给一个后台的线程进行队列处理的过程被称为deferred-drop。使用后台线程处理deferred-drop的好处是这个操作办法不会使得其所在的事务需要执行很长时间，因此也就不需要大量的锁。在SQL Server 2000SP3之前的版本（这个版本引入了deferred-drop）在Truncate Table的时候出现过多的锁耗尽内存的事是家常便饭。
下面是测试具体相关代码:
复制具体相关代码 具体相关代码如下:
CREATE DATABASE TruncateTest;
GO
USE TruncateTest;
GO
ALTER DATABASE TruncateTest SET RECOVERY SIMPLE;
GO
CREATE TABLE t1 (c1 INT IDENTITY, c2 ChAR (8000) DEFAULT 'a');
CREATE CLUSTERED INDEX t1c1 on t1 (c1);
GO
SET NOCOUNT ON;
GO
INSERT INTO t1 DEFAULT VALUES;
GO 1280
ChECKPOINT;
GO
上面的测试网站数据库恢复模式是简单，所以每个Checkpoint都会截断日志(仅仅是为了简单，哈哈)。
一分钟后让咱们来看看日志中有多少条记录。
复制具体相关代码 具体相关代码如下:
SELECT COUNT (*) FROM fn_dblog (NULL, NULL);
GO
可以看到，现在的日志条目数字为2。
假如如果您得到的数字不是2，那么再做一次Checkpoint直到数据是2为止。
现在已有的日志已经知道了，那么日志的增长就是由于后面的操作办法所导致。下面咱们执行如下具体相关代码:
复制具体相关代码 具体相关代码如下:
TRUNCATE TABLE t1;
GO
SELECT COUNT (*) FROM fn_dblog (NULL, NULL);
GO
可以看到现在已经有了541条日志记录。很明显Truncate操作办法是需要记录到日志中的。但也可以看出Truncate并不会逐行删除,因为这541条日志记录删除的是1280条数据。
执行下面数据库语句来查看日志:
复制具体相关代码 具体相关代码如下:
SELECT
[Current LSN], [Operation], [Context],
[Transaction ID], [AllocUnitName], [Transaction Name]
FROM fn_dblog (NULL, NULL);
下面是结果:
通过日志可以看出第一条显式开始Truncate Table事务，最后一条开始DeferredAlloc。正如您所见，Truncate操作办法仅仅是释放了构成表的页和区。
下面这个具体相关代码可以查看日志具体所做操作办法的描述:
复制具体相关代码 具体相关代码如下:
SELECT
[Current LSN], [Operation], [Lock Information], [Description]
FROM fn_dblog (NULL, NULL);
GO
结果如图2：
您可以看出为了快速恢复的目的而加的相关锁（您可以在我的博文:Lock logging and fast recovery中了解更多）。
由上面日志看出，这个操作办法会对8个页加相关的锁，然后整个区一次性释放。释放过后会对相关的区加IX锁,也就是不能再被使用,当事务提交后才会进行deferred-drop,因此也就保证了Truncate table操作办法可以回滚。
另外，假如如果表上存在非聚集索引.那么操作办法相关方式也是类似，都是交给一个后台线程然后释放表和索引的页。释放的最小单位就是每个分配单元。按照上面步骤您自己尝试一下就应该能明白我的意思了。
PS：还有一个关于Truncate Table操作办法不能回滚的误区,我在:Search Engine Q&A #10: When are pages from a truncated table reused?这篇文章中进行了详细的解释。
关于数据库教程相关的教程网站知识今天我们就说到这里了，希望可以帮到大家。
