当执行 DELETE FROM TABLE后，会发现针对一个DELETE语句，该表中有多少行内容，数据库日志文件中，相对应的记录是就是多少条，每一条记录，对应的是行级别的删除。而且对应的LSN编号也是不同的。因为整个DELETE语句是一个事务，所以事务编号是相同的。
使用命令 TRUNCATE TABLE TEST来删除表，在日志文件中是找不到相应的记录的。这是因为Truncate这个命令所运行的操作，是不记录日志的。如果表有成千上万条纪录，建议使用TRUNCATE TABLE来删除整张表。这样，可以避免日志文件大量的增长，同样，因为TRUNCATE TABLE命令在日志文件没有记录，所以使用TRUNCATE TABLE命令删除表后，如果突然发现是误操作，想依靠日志备份，表是无法恢复到原来状态的。因为没有办法做Undo操作。
因此可以发现，SQL Server的日志记录有以下特点：
1. 日志记录的是数据的变化，而不是记录用户发过来的操作。
在这一点上，日志记录的定位很清楚。它只是为了保证数据库一致性。所以它记录的信息对SQL Server来讲很有意义。但是如果想要通过它来倒推出用户刚才发过来的语句，可以说是不太可能的。
2. 每条记录都有它唯一的编号（LSN），并且记录了它属于的事务号。
这种设计便于事务的重新提交和回滚。
3. 日志记录的行数和实际修改的数据量有关。
SQL Server会为每一条记录的修改保存日志记录。如果单个语句修改的行数非常多，那它所带来的日志行数也就会非常多。所以日志增长的速度不仅和事务的多少有关，还和事务所带来的数据的修改量有关。
4. 日志记录了事务发生的时间，但是不记录发起者的程序名称和客户端信息。
5. SQL Server能够从日志记录里面读到数据修改前的值和修改后的值。但是对管理者来讲，直接从日志记录里面是很难了解其修改过程的。
讨论这些的原因，是因为很多用户希望能从日志文件里倒推出数据库曾经发生的异常操作。比如，是哪个应用程序恶意或不小心删掉了一些重要数据，或者是哪个客户端在某个时间段发起了一个庞大的事务。由于SQL Server日志定位不是做用户行为监视和记录，而是在对性能影响最小的前提下保证事务一致性，所以它记录的内容是面向数据库服务，而不是面向用户的。换句话说，它记录的东西只要SQL Server自己能读懂就可以了，而没有考虑要给用户去访问和理解。一般情况下，使用者很难用事务日志来达到倒推的目的。所以如果要监视用户的行为，还是要开启SQL Server自己的监视工具，比如SQL Trace或XEvents等。