IF (OBJECT_ID('#tmpDBCC04') IS NOT NULL)
DROP TABLE #tmpDBCC04
GO
CREATE TABLE #tmpDBCC04
(
CurrentLSN Varchar(200),
Operation Varchar (200),
Context Varchar (200),
TransactionID Varchar (200),
LogBlockGeneration Varchar (200),
TagBits Varchar (200),
LogRecordFixedLength Varchar (200),
LogRecordLength Varchar (200),
PreviousLSN Varchar (200),
FlagBits Varchar (200),
LogReserve Varchar (200),
Description Varchar (500),
RecordData Varchar (8000)
)
GO
INSERT INTO #tmpDBCC04 EXEC ('DBCC LOG(database, 4)')
SQL Server：DBCC 命令列表。
DBCC 命令全称: Database Console Commands
1. 查看有文档记录（Documented）的 DBCC 命令列表。
dbcc help('?')
dbcc checkalloc
dbcc checkcatalog
dbcc checkconstraints
dbcc checkdb
dbcc checkfilegroup
dbcc checkident
dbcc checktable
dbcc cleantable
dbcc concurrencyviolation
dbcc dbreindex
dbcc dropcleanbuffers
dbcc free
dbcc freeproccache
dbcc freesessioncache
dbcc freesystemcache
dbcc help
dbcc indexdefrag
dbcc inputbuffer
dbcc opentran
dbcc outputbuffer
dbcc pintable
dbcc proccache
dbcc show_statistics
dbcc showcontig
dbcc shrinkdatabase
dbcc shrinkfile
dbcc sqlperf
dbcc traceoff
dbcc traceon
dbcc tracestatus
dbcc unpintable
dbcc updateusage
dbcc useroptions
2. 查看有文档记录（Documented）的 DBCC 命令用法。
dbcc help('free') with no_infomsgs
dbcc dll_name( FREE ) [ WITH NO_INFOMSGS ]
e.g. dbcc xp_sample( FREE )
3. 查看包含无文档记录（Undocumented）的所有 DBCC 命令列表。
dbcc traceon(2520)
dbcc help ('?')
dbcc activecursors
dbcc addextendedproc
dbcc addinstance
dbcc adduserobject
dbcc auditevent
dbcc autopilot
dbcc balancefactor
dbcc bufcount
dbcc buffer
dbcc bytes
dbcc cachestats
dbcc callfulltext
dbcc checkalloc
dbcc checkcatalog
dbcc checkconstraints
dbcc checkdb
dbcc checkdbts
dbcc checkfilegroup
dbcc checkident
dbcc checkprimaryfile
dbcc checktable
dbcc cleantable
dbcc cacheprofile
dbcc clearspacecaches
dbcc collectstats
dbcc concurrencyviolation
dbcc config
dbcc cursorstats
dbcc dbinfo
dbcc dbrecover
dbcc dbreindex
dbcc dbreindexall
dbcc dbrepair
dbcc dbtable
dbcc debugbreak
dbcc deleteinstance
dbcc des
dbcc detachdb
dbcc dropcleanbuffers
dbcc dropextendedproc
dbcc dropuserobject
dbcc dumptrigger
dbcc errorlog
dbcc extentinfo
dbcc fileheader
dbcc fixallocation
dbcc flush
dbcc flushprocindb
dbcc free
dbcc freeproccache
dbcc freeze_io
dbcc getvalue
dbcc help
dbcc icecapquery
dbcc incrementinstance
dbcc ind
dbcc indexdefrag
dbcc inputbuffer
dbcc invalidate_textptr
dbcc invalidate_textptr_objid
dbcc iotrace
dbcc latch
dbcc lock
dbcc lockobjectschema
dbcc log
dbcc loginfo
dbcc memobjlist
dbcc memorymap
dbcc memorystatus
dbcc memospy
dbcc memusage
dbcc monitorevents
dbcc newalloc
dbcc no_textptr
dbcc opentran
dbcc outputbuffer
dbcc page
dbcc perflog
dbcc perfmon
dbcc pglinkage
dbcc pintable
dbcc procbuf
dbcc proccache
dbcc prtipage
dbcc pss
dbcc readpage
dbcc rebuild_log
dbcc renamecolumn
dbcc resource
dbcc row_lock
dbcc ruleoff
dbcc ruleon
dbcc setcpuweight
dbcc setinstance
dbcc setioweight
dbcc show_statistics
dbcc showcontig
dbcc showdbaffinity
dbcc showfilestats
dbcc showoffrules
dbcc showonrules
dbcc showtableaffinity
dbcc showtext
dbcc showweights
dbcc shrinkdatabase
dbcc shrinkdb
dbcc shrinkfile
dbcc sqlmgrstats
dbcc sqlperf
dbcc stackdump
dbcc tab
dbcc tape_control
dbcc tec
dbcc textall
dbcc textalloc
dbcc thaw_io
dbcc traceoff
dbcc traceon
dbcc tracestatus
dbcc unpintable
dbcc updateusage
dbcc upgradedb
dbcc usagegovernor
dbcc useplan
dbcc useroptions
dbcc wakeup
dbcc writepage
4. 运行无文档记录（Undocumented）的 DBCC 命令。
运行未公开的 DBCC 命令，需要先打开 3604 跟踪标记。
dbcc traceon (3604)
dbcc perfmon
dbcc log
0 - 最少信息(operation, context, transaction id)
1 - 更多信息(plus flags, tags, row length)
2 - 非常详细的信息(plus object name, index name,page id, slot id)
3 - 每种操作的全部信息
4 - 每种操作的全部信息加上该事务的16进制信息
这是一个大侠告诉我的，因为我的SQL没有保存LOG，试不出来，你看看。记得告诉大家啊。sqlserver的事务日志记录的是对数据有改动的事务操作，sqlserver就是借助这个日志来完成事务，或者恢复数据库，但是日志中记录的不是sql语句，而是对索引页或数据页的具体操作，所以不是很好反向翻译出sql语句来。
How to determine SQL Server database transaction log usage
By: Greg Robidoux | Comments (0) | Print | Share4
Expand your SQL Server horizons with a Kindle loaded with 5 eBooks
Read these related tips:
* Click here for related tips
* Still need your problem solved?
* Let us know what you think about the site
Problem
One crucial aspect of all databases is the transaction log. The transaction log is used to write all transactions prior to committing the data to the data file. In some circumstances the transaction logs can get quite large and not knowing what is in the transaction log or how much space is being used can become a problem. So how to you determine how much of the transaction log is being used and what portions are being used?
Solution
In most databases the transaction log is generally just one (ldf) file, but inside the overall transaction log is a series of virtual log files as depicted below.
source (SQL Server 2005 Books Online)
The way the transaction log is used is that each virtual log file is written to and when the data is committed and a checkpoint occurs the space becomes useable again. Although this does depend on your database recovery model, whether you are using replication and your backup processing. If there are no additional virtual logs available, SQL Server will grow the transaction log, based on your database settings, to accommodate the additional space that is required.
source (SQL Server 2005 Books Online)
The use of the file and the virtual logs all depends on how the database is used and other settings you have enabled in your database. If you are publishing data from this database or if the database is set to the the Full or Bulk-Logged recovery mode, this will also affect whether the process loops back to the beginning of the file, if it uses the next available virtual log or it if needs to grow the transaction log and create additional virtual logs.
DBCC SQLPERF(logspace)
One command that is extremely helpful in understanding how much of the transaction log is being used is DBCC SQLPERF(logspace). This one command will give you details about the current size of all of your database transaction logs as well as the percent currently in use. Running this command on a periodic basis will give you a good idea of how the transaction logs are being used and also give you an idea on how large they should really be. This is a question that is often asked by a lot of people that use SQL Server and as you run this you will find out there is no perfect answer it all depends on a lot of criteria such as:
*
recovery model
*
size of the transactions
*
how large your tables are and therefore how much space is needed for index maintenance
*
how frequently you run transaction log backups
*
whether the database is published or not
*
etc...
To run this command issue the following in a query window:
DBCC SQLPERF(logspace)
This is sample output:
From here we can see the size of the transaction logs as well as how much space is being used. The current log space used will tell you how much of the transaction log is being used. If this percentage is high and the size of the log is quite big it is probably due to one of the items listed above.
DBCC LOGINFO
The next command to look at is DBCC LOGINFO. This will give you information about your virtual logs inside your transaction log. The primary thing to look at here is the Status column. Since this file is written sequentially and then looped back to the beginning, you want to take a look at where the value of "2" is in the output. This will tell you what portions of the log are in use and which are not in use Status = 0. Another thing to keep an eye on is the FSeqNo column. This is the virtual log sequence number and the latest is the last log. If you keep running this command as you are issuing transactions you will see these numbers keep changing.
To run this command issue the following in a query window:
DBCC LOGINFO
This is sample output:
If we now run a transaction log backup such as the following:
BACKUP LOG DBUtil WITH NO_LOG
or
BACKUP LOG DBUtil TO DISK = 'C:\Backup\DBUtil.trn'
and then rerun the command you will see how the Status=2 has changed in the file. The last entry is still marked as in use, but the previous entries have been reset to 0.
One thing to note, if you do run BACKUP LOG...WITH NO_LOG you will need to run another full backup, otherwise SQL Server will just reuse the space in the transaction log because there is no way to restore the next transaction log backup since you did not do a real transaction log backup and therefore the settings in the log file were reset. Also, if you don't have a full backup of your database the space in the transaction log also gets reused. This is because there is no full backup to restore first and therefore you can not issue a transaction log restore.
DBCC OPENTRAN
Another command to look at is DBCC OPENTRAN. This will show you if you have any open transactions in your transaction log that have not completed or have not been committed. These may be active transactions or transactions that for some reason never completed. This can provide additional information as to why your transaction log is so big or why you may not be able to shrink the transaction log file. This will show you both open transactions as well any un-replicated transactions if the database is published.
To run this command issue the following in a query window:
DBCC OPENTRAN
This is sample output:
Now that you have an idea how much of your transaction log is being used and what is being used you can start to make some decisions on how large the transaction log should be. One thing you should try to do is find that optimum size in order to eliminate having to shrink and grow the transaction log on a constant basis. As with all database and server activity it is best to minimize the overhead as much as you can and this is one of those areas that you can somewhat manage by creating and maintaining the optimum transaction log size.
Next Steps
* Make sure you are using the correct backup strategy based on your recovery model
* If you are going to use BACKUP LOG...WITH NO_LOG you should just look at changing your database to the Simple recovery model
* If you do need to shrink your transaction log file take a look at DBCC SHRINKFILE.
* Here are some other tips regarding transaction log space.
o Monitoring transaction log space
o Managing SQL Server 2000 Transaction Log Growth
DBCC详解
2009-05-02 17:27:44
标签：sql server
一、 数据库一致性检查工具（Database Consistenecy Checker，简称DBCC）。DBCC是一个实用命令集，用来检查一个数据库的逻辑一致性及物理一致性。在开发和应用中，DBCC是我们经常要使用的命令。
数据库控制台命令语句被分为以下类别。
维护
对数据库、索引或文件组进行维护的任务。
杂项
杂项任务，如启用跟踪标志或从内存中删除 DLL。
信息
收集并显示各种类型信息的任务。
验证
对数据库、表、索引、目录、文件组或数据库页的分配进行的验证操作。
DBCC命令的格式如下
dbcc (checktable ((表名|表标识( [, skip_ncindex] ) |
checkdb [(数据库名[, skip_ncindex] )] |
checkalloc [ (数据库名[, fix | nofix] )] |
tablealloc( {表名|表标识}
[，{full |optimized |fast |null}
[, fix |nofix] ]]) |
indexalloc ( {表名|表标识}，索引标识
[，{full |optimezed | fast | null}
[, fix |nofix ]] ) |
checkcatalog [ (数据库名)] |
dbrepair(数据库名,dropdb ) |
reindex({表名|表标识} ) |
fix_text({表名|表标识) }
dbcc的权限，对于checktable,fix_text和reindex是缺省赋给表的属主，对于 checkdb,checkalloc，checkcatalog,dbrepair，indexalloc和tablealloc，是缺省赋给数据库属主的。DBO自动获得DBCC命令和全部选项的权限。该权限不可转授。此外，dbcc在数据库是活动时运行，除了dbrepair选项和带有fix选项的 dbcc checkalloc以外。
checktable选项
checktable是用来对一个指定的表做检查，确保索引和数据页正确地连接，索引按正确的顺序存储，所有指针的一致性，每页上数据信息的合理性，页偏移的合理性。如果日志段在它自己的（日志）设备上，对syslogs表使用dbcc checktable命令可以报告已使用的和剩余的日志空间，使用skip_ncindex选项使得dbcc checktable跳过对用户表上非聚簇索引（nonclustered index）的检查。缺省是检查所有的索引。
DBCC 语句使用输入参数和返回值。所有 DBCC 语句参数都可以接受 Unicode
和 DBCS 字面值。
使用 DBCC 结果集输出
许多 DBCC 命令可以产生表格格式的输出（使用 WITH TABLERESULTS 选项）。该信息可装载到表中以便将来使用。
例１.检查日志使用的空间量和未用的空间量：
dbcc checktable (syslogs)
若日志段在日志设备上，则会返回如下信息：
SysLogs的 DBCC 结果。
对象 'SysLogs' 的 37 页中有 4361 行。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
若日志不在它自己的设备上，则会显示下列信息：
消息 2501，级别 16，状态 45，第 1 行
找不到名为 "syslogs" 的表或对象。请检查系统目录。
checkdb选项
运行checkdb选项同checktable检查的内容一样，但它是对一指定数据库中的每张表都做这样的检查。若未指定数据库名，checkdb检查当前的数据库。checkdb返回的信息，也同于checktable。
checkalloc选项
checkalloc是检查指定数据库，看其所有正确分配的页和尚未分配的页的情况。若未指定数据库名，则checkalloc检查当前数据库。checkalloc会返回已分配的和使用的空间数量。checkalloc的缺省模式为nofix，要使用fix选项，必须把数据库置于单用户模式。
例：
dbcc checkalloc (iccard13)
……
在此数据库中，总区数 = 325，已用页数 = 2534，保留页数 = 2589。
此数据库中(混合区数 = 45，混合页数 = 349)。
CHECKALLOC 在数据库 'IcCard13' 中发现 0 个分配错误和 0 个一致性错误。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
tablealloc选项
tablealloc检查指定的表以确保所有页都被正确地分配。它是checkalloc的缩小版本。对单张表进行相同的完整性检查。使用 tablealloc可以生成三种类型的报表：full,optimized和fast。full选项相当于表一级的checkalloc；它报告各种类型的分配错误。optimized选项基于表的对象分配映像（OAM）页里列出的分配页生成报告。它并不报告，也不能整理OAM页里没有列出的在分配页上没有引用的扩展（extent）。如果没有指明类型，或使用了null，则optimized选项是缺省的设置。fast选项，并不生成分配报告，但生成一个被引用但并没有在扩展里分配的页的额外的报告。fix|nofix选项决定tablealloc 是否整理表中发现的分配错误。对于所有的表，缺省为fix，但系统表除外，它们的缺省为nofix。要对系统表使用fix选项，必须首先将数据库置成单用户模式。
indexalloc 选项
indexalloc检查指定的索引，确保所有的页都被正确地分配，它是checkalloc的缩小版本，对单独一条索引指定同样的完整性检查。其中各选项与tablealloc相同。
checkcatalog选项
checkcatalog选项用于检查系统表内，系统表之间的一致性。例如：它确保在syscolumns表中的每一（数据）类型在 systypes表中都有一个相匹配的记录；对于sysobjects中的每个表和视图在syscolumns表中应有关于它们每一列的描述记录；确保在 syslogs中的最后一个检查点是有效的。checkcatalog也报告任何已定义的段。若不指定数据库名，则检查当前数据库。
dbrepair选项
dbrepair（数据库名，dropdb）选项是删除一个受破坏的数据库。受破坏的数据库是不能用drop database命令删除的，drop database只能删除正常的数据库，当执行dbrepair命令时，任何用户（包括执行此命令的用户）都不得使用正被删除的数据库。该选项要在 master库中运行。
reindex选项
reindex选项通过运行dbcc checktable的“fast”执行方式检查用户表上索引的完整性。如果它检测出索引有问题则会删除并重建索引。在SQL Server的排列顺序改变之后，SA或表属主应该执行这一选项。此选项不能在用户定义的事务中运行。
fix_text选项
SQL Server的字符集由单字节转变为多字节后，fix_text选项用于升级文本值。SQL Server的字符集由单字节转变为多字节字符集会使文本数据的管理更加复杂。由于文本值可能较大足以覆盖若干页，SQL Server必须能处理（通过页约束）可能横跨页的字符。为做到这点，服务器需要在每一文本页上添加一些信息。SA或表属主必须在文本数据的每一个表上运行dbcc fix_text，以计算所需要的新页数。
总之，DBCC命令所返回的信息能准确地反映数据库及它的各个对象的状态。
二、DBBCC维护语句：对数据库、索引或文件组进行维护的任务
1、DBCC SHRINKDATABASE --压缩整个数据库的数据文件与日志文件。
例：DBCC SHRINKDATABASE(adventureworks,40) --将此数据库压缩到仅剩下40%的剩余空间。
……DBCC SHRINKDATABASE: 已跳过数据库 ID 6 的文件 ID 1，因为该文件没有足够的可用空间可以回收。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
2、DBCC SHRINKFILE --压缩指定的数据库文件或记录文件的大小。文件存于sys.database_file的命令行
DBCC SHRINKFILE('AdventureWorks_log',50) --将指定的文件压缩到仅剩下50M
3、DBCC UPDATEUSAGE --更正任何无效的命令行或页面计数，对象可从整个数据库到单一的数据表或是索引，多用在数据库升级后的处理操作。
如：DBCC UPDATEUSAGE(0)
4、DBCC CLEANTABLE。回收删除的可变长度列和文本列的空间。
如：
use iccard13
go
DBCC CLEANTABLE(0,log,0)WITH NO_INFOMSGS
5、DBCC INDEXDEFRAG。指定表或视图的索引碎片整理。
6、DBCC DBREINDEX。 对指定数据库中的表重新生成一个或多个索引。
7、DBCC DROPCLEANBUFFERS。 从缓冲池中删除所有清除缓冲区。
8、DBCC FREEPROCCACHE。 从过程缓存中删除所有元素。
三、DBBCC验证语句：对数据库、表、索引、目录、文件组或数据库页的分配进行的验证操作
DBCC CHECKALLOC。检查指定数据库的磁盘空间分配结构的一致性。
DBCC CHECKFILEGROUP。检查当前数据库中指定文件组中的所有表的分配和结构完整性。
DBCC CHECKCATALOG。检查指定数据库内的目录一致性。数据库必须联机。
DBCC CHECKIDENT。 检查指定表的当前标识值，如有必要，则更改标识值。
DBCC CHECKCONSTRAINTS。 检查当前数据库中指定表上的指定约束或所有约束的完整性。
DBCC CHECKTABLE。检查组成表或索引视图的所有页和结构的完整性。
DBCC CHECKDB。检查指定数据库中所有对象的分配、结构和逻辑完整性。
四、DBBCC的信息语句
DBCC SHOW_STATISTICS。显示指定表上的指定目标的当前分发统计信息。
DBCC INPUTBUFFER.显示从客户端发送到 Microsoft SQL Server 2005 实例的最后一个语句。
DBCC INPUTBUFFER ( session_id [ , request_id ] ) [WITH NO_INFOMSGS ]
DBCC SHOWCONTIG.显示指定的表的数据和索引的碎片信息。
DBCC OPENTDBCC INPUTBUFFERRAN 如果在指定数据库内存在最早的活动事务和最早的分布式和非分布式复制事务，则显示与之有关的信息
DBCC SQLPERF.提供有关如何在所有数据库中使用事务日志空间的统计信息。
DBCC SQLPERF ( LOGSPACE | 'sys.dm_os_latch_stats' , CLEAR | 'sys.dm_os_wait_stats' , CLEAR )
[WITH NO_INFOMSGS ]
DBCC OUTPUTBUFFER.以十六进制和 ASCII 格式返回指定 session_id 的当前输出缓冲区。DBCC OUTPUTBUFFER ( session_id [ , request_id ] )
DBCC TRACESTATUS.显示跟踪标志的状态.DBCC TRACESTATUS ( [ [ trace# [ ,...n ] ] [ , ] [ -1 ] ] )
DBCC PROCCACHE.以表格格式显示有关过程缓存的信息。DBCC PROCCACHE [ WITH NO_INFOMSGS ]
DBCC USEROPTIONS 返回当前连接的活动（设置）的 SET 选项。DBCC USEROPTIONS
五、DBBCC的杂项语句：杂项任务，如启用跟踪标志或从内存中删除 DLL
DBCC HELP。返回指定的 DBCC 命令的语法信息。DBCC HELP ( 'dbcc_statement' | @dbcc_statement_var | '?' )[ WITH NO_INFOMSGS ]
DBCC dllname (FREE)。从内存中上载指定的扩展存储过程 DLL。DBCC dllname ( FREE ) [ WITH NO_INFOMSGS ]
DBCC DBREPAIR 。禁用指定的跟踪标记。DBCC TRACEOFF ( trace# [ ,...n ] [ , -1 ] ) [ WITH NO_INFOMSGS ]
DBCC TRACEON。启用指定的跟踪标记。DBCC TRACEON ( trace# [ ,...n ][ , -1 ] ) [ WITH NO_INFOMSGS ]
六、未公开的DBCC
DBCC ERRLOG 初始化SQL错误日志
DBCC BUFFER 显示缓冲区头部和页面信息
DBCC FLUSHPROCINDB 清楚数据库服务器内存中的某个数据库存储过程的缓存内容。
DBCC DBINFO 显示数据库结果信息
DBCC DATABLE 显示管理数据库的表信息
DBC IND 查看某个索引使用的页面信息。
DBCC REBULDLOG
重建修复SQL数据库事物日志文件。
DBCC LOG 查看某个数据库的事务日志信息
DBCC PAGE 查看某个数据库数据也面信息
DBCC PROCBUF 显示过程缓冲池的缓冲区头和存储过程。
DBCC PRTIPAGE 查看某个索引页面的每行指向的页面号。
DBCC PSS 显示当前连接到SQLSERVER服务器的进程信息。
DBCC RESOURCE 显示服务器当前使用的资源情况。
DBCC TAB 查看数据页面的结构
我们知道，在数据库系统的开发和应用中，必须保证数据库的完整性和一致性。
当数据库出现了严重错误；当我们怀疑数据库受到破坏（如无法用drop命令删除数据库或对象，使用某个表时出现“不可靠数据”的信息等）；当用户改变了 Server的缺省排序的顺序或改变了字符集而需要检查；当SA对系统做定期检查；这些时候，我们都需要使用数据库一致性检查工具（Database Consistenecy Checker，简称DBCC）。DBCC是一个实用命令集，用来检查一个数据库的逻辑一致性及物理一致性。在开发和应用中，DBCC是我们经常要使用的命令。
DBCC命令的格式如下
dbcc
(checktable ((表名|表标识( [, skip_ncindex] ) |
checkdb [(数据库名[, skip_ncindex] )] |
checkalloc [ (数据库名[, fix | nofix] )] |
tablealloc( {表名|表标识}
[，{full |optimized |fast |null}
[, fix |nofix] ]]) |
indexalloc ( {表名|表标识}，索引标识
[，{full |optimezed | fast | null}
[, fix |nofix ]] ) |
checkcatalog [ (数据库名)] |
dbrepair(数据库名,dropdb ) |
reindex({表名|表标识} ) |
fix_text({表名|表标识) } dbcc的权限，对于checktable,fix_text和reindex是缺省赋给表的属主，对于 checkdb,checkalloc，checkcatalog,dbrepair，indexalloc和tablealloc，是缺省赋给数据库属主的。DBO自动获得DBCC命令和全部选项的权限。该权限不可转授。此外，dbcc在数据库是活动时运行，除了dbrepair选项和带有fix选项的 dbcc checkalloc以外。
checktable选项
checktable是用来对一个指定的表做检查，确保索引和数据页正确地连接，索引按正确的顺序存储，所有指针的一致性，每页上数据信息的合理性，页偏移的合理性。如果日志段在它自己的（日志）设备上，对syslogs表使用dbcc checktable命令可以报告已使用的和剩余的日志空间，使用skip_ncindex选项使得dbcc checktable跳过对用户表上非聚簇索引（nonclustered index）的检查。缺省是检查所有的索引。
例１.检查日志使用的空间量和未用的空间量：
dbcc checktable (syslogs)
若日志段在日志设备上，则会返回如下信息：
若日志不在它自己的设备上，则会显示下列信息：
checking syslogs
The total number of data page in the table is 1.
NOTICE:Space used on the log segment is 0.20 Mbytes, 0.13%.
NOTICE:Space free on the log segment is 153.4Mbytes,99.87%.
DBCC execution Completed.If dbcc printed error messages,
Contact a user with SA role.
checkdb选项
NOTICE:Notification of log space used/free.
Can not be reported because the log segment is not on its own device.
例2. dbcc checktable (titles)
The total number of data page in this table is 3.
Table has 18 data rows.
DBCC execution Completed. If DBCC printed error messages. contact a user with SA role. 运行checkdb选项同checktable检查的内容一样，但它是对一指定数据库中的每张表都做这样的检查。若未指定数据库名，checkdb检查当前的数据库。checkdb返回的信息，也同于checktable。
checkalloc选项
checkalloc是检查指定数据库，看其所有正确分配的页和尚未分配的页的情况。若未指定数据库名，则 checkalloc检查当前数据库。checkalloc会返回已分配的和使用的空间数量。checkalloc的缺省模式为nofix，要使用fix 选项，必须把数据库置于单用户模式。
例：
dbcc checkalloc (pubs2)
.
.
.
alloc page 0 (#of extent=32 used pages=68 ref pages=6
alloc page 256 (# of extent=32 used pages=154 ref pages=154)
alloc page 512 (# of extent=28 used pages=184 ref pages=184)
alloc page 768 (# of extent=1 used pages=1 ref pages=1)
total (# of extent=93 used pages=407 ref pages=407) in this database.
DBCC execution completed.If dbcc printed error message,
Contact a user with System Adminstrator (SA) role.tablealloc选项
tablealloc检查指定的表以确保所有页都被正确地分配。它是checkalloc的缩小版本。对单张表进行相同的完整性检查。使用tablealloc可以生成三种类型的报表：full,optimized和fast。full选项相当于表一级的 checkalloc；它报告各种类型的分配错误。optimized选项基于表的对象分配映像（OAM）页里列出的分配页生成报告。它并不报告，也不能整理OAM页里没有列出的在分配页上没有引用的扩展（extent）。如果没有指明类型，或使用了null，则optimized选项是缺省的设置。 fast选项，并不生成分配报告，但生成一个被引用但并没有在扩展里分配的页的额外的报告。fix|nofix选项决定tablealloc 是否整理表中发现的分配错误。对于所有的表，缺省为fix，但系统表除外，它们的缺省为nofix。要对系统表使用fix选项，必须首先将数据库置成单用户模式。
例：
dbcc tablealloc(titles)
显示信息如下：
The default report option of OPTIMIZED is used for this run. The default fix option of FIX.is used for this run.
.
.
.
Total #of extent=3
Alloc page 256 (# of extent=1 used pages=2 ref pages=2).
Alloc page 256(# of extent=1 used pages=2 ref pages=2)
Alloc page 256 (# of extent=1 used pages=2 ref pages=2)
Total (# of extent=3 used pages=8 ref pages=
in this database. indexalloc 选项
indexalloc检查指定的索引，确保所有的页都被正确地分配，它是checkalloc的缩小版本，对单独一条索引指定同样的完整性检查。其中各选项与tablealloc相同。
checkcatalog选项
checkcatalog选项用于检查系统表内，系统表之间的一致性。例如：它确保在syscolumns表中的每一（数据）类型在systypes表中都有一个相匹配的记录；对于sysobjects中的每个表和视图在syscolumns表中应有关于它们每一列的描述记录；确保在syslogs中的最后一个检查点是有效的。checkcatalog也报告任何已定义的段。若不指定数据库名，则检查当前数据库。
dbrepair选项
dbrepair（数据库名，dropdb）选项是删除一个受破坏的数据库。受破坏的数据库是不能用drop database命令删除的，drop database只能删除正常的数据库，当执行dbrepair命令时，任何用户（包括执行此命令的用户）都不得使用正被删除的数据库。该选项要在 master库中运行。
reindex选项
reindex选项通过运行dbcc checktable的“fast”执行方式检查用户表上索引的完整性。如果它检测出索引有问题则会删除并重建索引。在SQL Server的排列顺序改变之后，SA或表属主应该执行这一选项。此选项不能在用户定义的事务中运行。
例：
dbcc reindex (titles)
返回信息：One or more indexes corrupt.They will be rebuilt.
fix_text选项
SQL Server的字符集由单字节转变为多字节后，fix_text选项用于升级文本值。SQL Server的字符集由单字节转变为多字节字符集会使文本数据的管理更加复杂。由于文本值可能较大足以覆盖若干页，SQL Server必须能处理（通过页约束）可能横跨页的字符。为做到这点，服务器需要在每一文本页上添加一些信息。SA或表属主必须在文本数据的每一个表上运行dbcc fix_text，以计算所需要的新页数。
总之，DBCC命令所返回的信息能准确地反映数据库及它的各个对象的状态，是我们检测数据库的好帮手。
sqlserver 事务日志文件格式 收藏
以前有个log explorer能读日志,但不支持2008
所以找了篇事务日志文件格式文章,留待研究
http://book.51cto.com/art/201001/181081.htm
当日志文件大小超过预期的时候，数据库管理员自然会想去看看日志文件中到底存放了些什么信息。SQL Server有一条"DBCC LOG"命令可以帮助我们解释日志文件中的信息。它的语法是：
DBCC LOG(, )
：目标数据库编号。可以用sp_helpdb得到。
：DBCC LOG命令翻译和解释日志记录的方式。
一般来讲，使用"3"这个格式参数输出比较详细。
下面我们通过一个很简单的表格操作来看看SQL Server是怎么组织事务日志记录的。
首先，我们在范例数据库AdventureWorks里面创建一个只有一个int类型字段的表格。然后将数据库日志文件清空。接着运行DBCC LOG命令。找到这时日志文件的最后一条记录。
use adventureworks
go
create table a (a int)
go
checkpoint
go
backup log adventureworks WITH NO_LOG
--2008中需改为 DBCC SHRINKFILE (N'adventureworks_Log' , 1)
go
dbcc log(adventureworks,3)
go
--接着，我们在表格里插入一条记录。
insert into a values (1)
go
dbcc log(adventureworks,3)
go 结果中（见图1-26）可以看到三条关于这个Insert的记录。
--sql2008中增加了20几条记录
图1-26 DBCC LOG结果中3条和INSERT动作相关的记录
我们再插一条记录。
1. insert into a values (100)
2. go
3. dbcc log(5,3)
4. go 可以看到新的3条记录（见图1-27）。新的记录有不同的LSN编号。
图1-27 新的3条和INSERT动作相关的记录
从这些记录里，我们可以看到刚才做的INSERT的事务，它的起始时间，刚才连接的SPID，以及其他一些信息。SQL Server完全可以通过这些记录把INSERT重做，或者撤销。
我们把这两条记录都改成2。这次出现了6条记录（见图1-28）。
1. update a set a = 2
2. go
图1-28 和UPDATE动作相关的6条记录
从这些记录可以看出，虽然只是一条UPDATE语句，但是实际上SQL Server并没有记录语句本身。它记录的是两条被修改的数据原来的值和现在的值。
因此我们可以发现，SQL Server的日志记录有以下特点：
1. 日志记录的是数据的变化，而不是记录用户发过来的操作。
在这一点上，日志记录的定位很清楚。它只是为了保证数据库一致性。所以它记录的信息对SQL Server来讲很有意义。但是如果想要通过它来倒推出用户刚才发过来的语句，可以说是不可能的。
2. 每条记录都有它唯一的编号（LSN），并且记录了它属于的事务号。
这种设计便于事务的重新提交和回滚。
3. 日志记录的行数和实际修改的数据量有关。
SQL Server会为每一条记录的修改保存日志记录。如果单个语句修改的行数非常多，那它所带来的日志行数也就会非常多。所以日志增长的速度不仅和事务的多少有关，还和事务所带来的数据的修改量有关。
4. 日志记录了事务发生的时间，但是不保证记录下了发起这个事务的用户名，更不记录发起者的程序名称。
5. SQL Server能够从日志记录里面读到数据修改前的值和修改后的值。但是对管理者来讲，直接从日志记录里面是很难了解其修改过程的。
讨论这些的原因，是因为很多用户希望能从日志文件里倒推出数据库曾经发生的异常操作。比如，是谁恶意或不小心删掉了一些重要数据，或者是谁在某个时间段发起了一个庞大的事务。由于SQL Server日志定位不是做用户行为监视和记录，而是在对性能影响最小的前提下保证事务一致性，所以它记录的内容是面向数据库服务，而不是面向用户的。换句话说，它记录的东西只要SQL Server自己能读懂就可以了，而没有考虑要给用户去访问和理解。所以使用者很难用事务日志来达到倒推的目的。
市场上有一些第三方的工具宣称能从SQL Server的日志文件中完成一些推断工作。他们能够更进一步地解释日志记录，并且做一些自动化的工作（例如，帮助用户回滚一个误操作）。但是如果有什么内容DBCC LOG看不到，这些工具应该也很难看到。所以如果要监视用户的行为，还是要开启SQL Server自己的监视工具，比如SQL Trace或XEvents等。
在 SQL Server 实例中的每一个数据库，都有一个日志，它记录着数据库的所有更改。由于这个日志是独立的，在更改发生之前，事务日志允许在硬件故障或应用程序错误时，对数据库回滚或保存事务。由于它的角色的重要性，事务日志被保存在一个或多个与数据库文件独立的日志文件中；日志记录是在内容的变更从缓存写到数据库文件中以前发生的。
对每个数据库，事务日志支持以下操作：
当发出一个回滚操作或数据库引擎检测到一个错时，进行事务回滚；
当服务器失改时，进行一个完整的事务回滚。这个事务在SQL Server 重启时进行回滚。
当服务器失败时，将未完成的事务写入到日志文件，而不是数据文件中。当 SQL Server 重启时，这些未完成的事务将会写入数据文件。
当发生硬件错误时，对恢复的数据库、文件组、文件或页向前滚动到失败点。事务将滚动到最后一个完整备份或差异备点。
对事务复制、数据库镜像、日志传输提供支持。
这些记录事务日志的文件，会由数据库引擎根据物理文件的实际情况，自动地分解为多个虚拟文件。数据库引擎也会判断在何时对哪些虚拟文件进行截断。你可以指定物理日志文件的最小值和最大值，并可以配置扩展文件时的增长率。另外，你可以向日志增加物理文件、删除文件、增加日志的大小或收缩日志。
在这篇文章中，我将解释如何执行这些任务，以开始管理你的事务日志，同时，我提供了一些例子以演示每一个任务如何工作。在这些例子中，我使用位于本地 SQL Server 2008 实例上的 EmplyeeDb 数据库：
USE master;
IF EXISTS
(
SELECT name FROM sys.databases
WHERE name = 'EmployeeDB'
)
DROP DATABASE EmployeeDB;
CREATE DATABASE EmployeeDB
ON
(
NAME = EmployeeDB_dat,
FILENAME = 'C:\SqlData\EmployeeDb.mdf'
)
LOG ON
(
NAME = EmployeeDB_log,
FILENAME = 'C:\SqlData\EmployeeDb.ldf'
);
注意：我是在一个指定的位置上创建了一个数据库文件，而不是 SQL Server 默认的位置。如果运行这段代码，可以将数据库定位到你想指定的位置。创建数据库以后，我可以使用 SELECT...INTO 语句从AdventureWorks2008 数据库创建表，并传输数据。
USE EmployeeDB;
IF OBJECT_ID('Employees', 'U') IS NOT NULL
DROP TABLE dbo.Employees;
SELECT BusinessEntityID,
FirstName,
LastName,
JobTitle,
PhoneNumber,
EmailAddress,
AddressLine1,
AddressLine2,
City,
StateProvinceName,
PostalCode,
CountryRegionName
INTO dbo.Employees
FROM AdventureWorks2008.HumanResources.vEmployee;
你不一定非要在这个数据库中执行这段代码，但是它作为一个小小的测验，有助于你学习事务日志的有关内容。如果你计划使用另外的数据库，只需要替换一下例子代码中的数据库名称即可。
配置恢复模式
每个 SQL Server 数据库都有一个恢复模式属性，(the Recovery Model), 它指示事务日志如何记录，如：事务日志是否可以被备份，以及恢复操作的许可类型。默认情况下，一个新的数据库从 Model 数据库继承了一个恢复模式。当然，你也可以修改默认设置为其它模式。
你可以配置一个 SQL Server 数据库的恢复模式为以下几种之一：
简单模式(Simple): 在这种模式下，事务日志的备份是不安全的，这意味着你不能对备份之后的事务日志进行管理。这种模式也会自动的扩展日志空间，所以几乎不需要去管理事务日志的空间。然而，这种模式也是风险最大的一种模式，数据库只能被恢复到最后一次备份的时间点，而在最后一次备份之后执行的事务将会丢失。这种模式通常用于系统数据库、或者用于测试和开发阶段。或者是几乎仅有只读情况的数据仓库数据库。这种情况下，一些操作只是尽可能少的被记录。
完整模式(Full): 由于这种模式可以提示指定时间点的恢复，因此它可以备份并且也应当进行备份。这种模式比简单模式的风险要小。但是，在完整模式下，所有的操作都被完整的记录，包括大数据量操作。这种模式适用于生产环境。
大数据量记录模式(Bulk Logged): 这种模式可以看作是完整模式的补充，因为在这种模式下，大数量操作只是被最小化的记录。例如，你可能要大量的加载数据但你不希望这些事务日志被记录，因为你只是希望加载数据而已。在这种情况下，你可以在导入数据时，将模式由完整模式切换到大数据量模式，执行完后，再恢复到完整模式。（需要注意的是：在切换回完整模式后，你应当做一次完整备份）
你可以在数据库上通过执行 ALTER DATABASE 语句，和指定 Set Recovery 来切换这些模式，例子如下：
USE master;
ALTER DATABASE EmployeeDB
SET RECOVERY FULL;
在上面的代码中，我修改了 EmployeeDB 数据库，并将恢复模式设置为完整模式 FULL。注意：由于默认的 model 数据库是被配置为完整模式 Full ，这也意味着 EmployeeDB 数据库被自动配置为完整模式，因为它是继承自 model 数据库的。所以，如果在你的服务器上， model 数据库的默认设置没有被更改的话，上面的的例子中 ALTER DATABASE 并不会改变什么，但是你要注意，当你将数据从 简单模式 切换到完整模式时，有时候必须执行一些其它步骤，例如进行一个完整备份。在SQL Server 在线教程中主题 "Considerations for Switching from the Simple Recovery Model" 描述了将数据库的恢复模式从简单模式转换为完整模式或大容量模式时，有哪些步骤要执行。
你也可以在 SQL Server Management Studio中设置恢复模式。在对象浏览器中右键单击数据库名称，并选择“属性”，在数据库属性对话框中，单击选项页，并设置恢复模式属性。
监控日志文件
在维护数据库的事务日志过程中，你可能需要经常获取日志的一些信息以便检查其设置或者已经使用了多少日志空间。一种方法是使用 sys.database_files 分类视图，这个视图返回关于数据库文件的详细信息，包括：文件类型、当前文件大小、以及文件增长设置。
在下面的例子中，我使用 sys.database_files 来获取 EmployeeDB 数据库的日志文件的数据：
USE EmployeeDB;
SELECT name,
size, -- in 8-KB pages
max_size, -- in 8-KB pages
growth,
is_percent_growth
FROM sys.database_files
WHERE type_desc = 'LOG'
这条语句返回了当前的文件大小（按8-KB的页面大小），文件可增长到的最大大小 (同样按 8_KB 的页面大小)，增长率和是否按百分比增长标记。该标记指示数据库文件的大小按何种方式增长。如果标记被设置为0，那么增长率就是 8-KB ，如果设置为 1，则按百分比增长。
上述代码返回的结果大致如下：
Name size max_size growth is_percent_growth
EmployeeDB_log 128 268435456 10 1
如结果中所示，这条语句只返回一行记录。这是因为 EmployeeDB 只配置了一个日志文件。上面的结果还反映了 EmployeeDB_log 的当前文件大小是 128 个8-KB 的页面大小，它可以增长到 268,435,456 个8-KB 的页面大小，增长率是按 10%的速率。
你还可以使用 DBCC SQLPERF 语句返回一个 SQL Server 实例的每个数据库的事务日志信息，要获取日志数据，你必须在参数中使用 LOGSPACE 关键字，如下所示：
DBCC SQLPERF(LOGSPACE);
这条语句返回以 MB 计算的日志大小，日志空间使用的百分比，以及你的 SQL Server 实例中每个数据库的日志状态。 EmployeeDB 数据库的信息如下：
Database Name Log Size (MB) Log Space Used (%) Status
EmployeeDB 0.9921875 40.05906 0
这个例子中 EmployeeDB 日志大约是 1 MB 大小，并且使用了 40% 的日志空间。
你也可以在 SQL Server Management Studio 中生成一个图形化的报表，结果类似于执行 DBCC SQLPERF 语句。方法是：在对象浏览器中，右键单击数据库名称，选择报表，再选择标准报表，最后点击磁盘利用率。
备份日志文件
如果你将数据库的恢复模式配置为完全模式或大容量模式，你就应当有规律的备份事务日志，这样你就可以截断日志并释放不活动的日志空间。备份也可以用于恢复数据库（通常与数据库备份一起使用）。
在事务日志备份之前，必须先执行过一个数据库的完整备份。通常，在我使用本文中的日志备份前，一般都先执行下面的数据库备份语句：
BACKUP DATABASE EmployeeDB
TO DISK = 'E:\DbBackup\EmployeeDB_dat.bak';
注意：执行这段代码时，确认指定路径存在或指定一个另外的路径。
执行完数据库备份后，我一般运行下面的数据修改语句，以使当前日志不包含已备份的内容：
USE EmployeeDB;
UPDATE Employees
SET JobTitle = 'To be determined';
UPDATE Employees
SET CountryRegionName = 'US'
WHERE CountryRegionName = 'United States';
DELETE Employees
WHERE BusinessEntityID > 5;
然后我再运行 DBCC SQLPERF 查看日志空间的统计信息，该语句返回下面的结果：
Database Name Log Size (MB) Log Space Used (%) Status
EmployeeDB 0.9921875 64.41929 0
你可以看到，日志空间的使用率已从40%提升到接近65%。
备份完数据库，你就可以备份事务日志了。执行事务日志的备份，使用 BACKUP LOG 语句，并指定备份位置，如下：
-- back up transaction log
BACKUP LOG EmployeeDB
TO DISK = 'E:\LogBackup\EmployeeDB_log.bak';
同样要注意路径的问题。
这里我指定了备份路径，然而， BACKUP 还支持其它选项，可以在SQL Server Books Online查看 “BACKUP (Transact-SQL)” 主题以获得更多信息。
执行完事务日志的备份以后， SQL Server 数据库引擎会自动截断不活动的日志空间。（注意：截断事务日志只是移除了不活动的虚拟日志空间，并不减小文件大小）要减小日志文件，你应当对文件进行收缩。要检查是否截断了日志，请再次运行 DBCC SQLPERF 语句。现在的结果应当如下面所示：
Database Name Log Size (MB) Log Space Used (%) Status
EmployeeDB 0.9921875 44.88189 0
现在日志空间已下降到45%。
修改日志文件
你可以使用 ALTER DATABASE 语句来修改日志文件。在执行语句时，必须使用适当的选项指定修改文件的原因（ MODIFY FILE clause）。 除了给日志文件指定适当的逻辑名外，还有以下三个参数可用：
SIZE: 为日志文件指定大小。你可以指定以 KB, MB, GB, 或 TB为单位的文件大小，例如： 10 MB 或 1 GB。如果在添加文件时没有指定文件大小，数据库引擎使用默认的大小：1MB。新的文件大小必须比现在的大，否则在运行语句时会报错。
MAXSIZE: 这个参数指定该文件最大可以是多大。同样，你可以以 KB, MB, GB, 或 TB 为单位指定。如果你没有指定最大的文件大小，文件会一直变大，直到占满整个磁盘空间。
FILEGROWTH: 增量用于文件扩展时。可以KB, MB, GB, 或 TB 指定，或者用百分比。如 10%。如果没有指定增量的单位，则默认为MB，如果没有指定增量，则默认为10%。如果指定增量为0，则不允许自动增加。
下面用 ALTER DATABASE 语句来修改 EmployeeDB 数据库的日志文件 EmployeeDB_log：
-- modify log file
ALTER DATABASE EmployeeDB
MODIFY FILE
(
NAME = EmployeeDB_log,
SIZE = 2MB,
MAXSIZE = 200MB,
FILEGROWTH = 10MB
);
如上所示，我在指定了日志文件的逻辑名称以后，设置了文件的大小 (2 MB)，最大值 (200 MB)，和增量 (10 MB)。
执行 ALTER DATABASE 语句后，可以查询 sys.database_files 的分类视图，以查看更改，结果如下：
Name size max_size growth is_percent_growth
EmployeeDB_log 256 25600 1280 0
现在文件的大小是 256 个 8-KB 页面，最大值 25,600 个 8-KB 增量是 1,280 个 8-KB 页面。
收缩日志文件
前面已经说过，要截断事务日志，你必须先备份日志，这样数据库引擎就可以自动的截断不活动的记录。然而截断日志并不会减小它的文件大小。要减小日志文件的大小，必须收缩日志文件，它会移除一个或多个不活动的虚拟日志文件。
要收缩日志文件，你可以使用指定了日志文件名称、目标大小（MB）的 DBCC SHRINKFILE 语句，下面的例子，使用DBCC SHRINKFILE 语句收综 EmployeeDB_log 文件：
-- shrink log file
DBCC SHRINKFILE(EmployeeDB_log, 1);
上面例子中文件的目标大小是 1 MB (128 8-KB pages)，执行该语句时，数据库引擎会将文件收缩到指定大小，但必须是在有足够的虚文件时。执行完后，可以通过查询 sys.database_files 分类视图，以检查是否文件已缩小，结果应当如下：
Name size max_size growth is_percent_growth
EmployeeDB_log 128 25600 1280 0
你可以看到，文件的大小已从 256 个 8-KB 减小到 128。如果数据库引擎无法释放空间，它会提示你一些建议的步骤，你可以按提示重新运行 DBCC SHRINKFILE 语句。
添加或删除日志文件
如果你在增加日志文件的大小，一种方法是为日志增加文件。
你可以在执行ALTER DATABASE语句时，使用 ADD LOG FILE 子句，在子句中，除了新的日志文件的逻辑名和物理名，你还可以指定以下参数：
SIZE: 日志文件的初始大小。你可以使用 KB, MB, GB, or TB为单位，如 10 MB 或 1 GB。如果不指定，则数据库引擎指定为默认值 1MB。
MAXSIZE: 日志文件的最大值，单位同上。如果不指定此参数，日志文件会一直增长，直到占满所在的磁盘空间。
FILEGROWTH: 增量，单位同上，也可以是百分比。如果指定了数字，但没有单位，则按 MB 。如果未指定此参数，则使用 10% 。如果指定为0，则不允许自动增长。
下面的例子添加 EmployeeDB_log2 到 EmployeeDB 的事务日志中。
ALTER DATABASE EmployeeDB
ADD LOG FILE
(
NAME = EmployeeDB_log2,
FILENAME = 'C:\SqlData\EmployeeDB2.ldf',
SIZE = 2MB,
MAXSIZE = 50MB,
FILEGROWTH = 10%
);
注意：我先是指定了逻辑名和物理名，随后定义了初始大小，最大值和增量。运行此语句以后，我可以通过查询 sys.database_files 分类视图来确认是否文件已被加入：
Name size max_size growth is_percent_growth
EmployeeDB_log 128 268435456 10 1
EmployeeDB_log2 256 6400 10 1
结果显示， EmployeeDB_log2 已被添加到数据库，其初始大小是：256个 8-KB 页面，最大值 6,400 个 8-KB 增量 10%.
你也可以使用 ALTER DATABASE 和子名 REMOVE FILE 来移除日志文件：
ALTER DATABASE EmployeeDB
REMOVE FILE EmployeeDB_log2;
查询 sys.database_files 分类视图，返回的结果如下：
Name size max_size growth is_percent_growth
EmployeeDB_log 128 268435456 10 1
EmployeeDB_log2 1 6400 10 1
你可能注意到： EmployeeDB_log2 还在，但大小是 1 个 8-KB 页，这个物理文件已经被删除，但逻辑文件还在，你必须通过备份事务日志来移除它。备份以后，再查询 sys.database_files 分类视图，结果如下：
Name size max_size growth is_percent_growth
EmployeeDB_log 128 268435456 10 1
显示逻辑文件已移除。
总结
很明显，事务日志在 SQL Server 数据库中扮演着非常重要的角色，上面的内容指导您如何用它们来工作。上面关于事务日志，我没讲到的东西有：如何支持事务日志的复制、数据库的镜像和事务日志的发布，也没有讲到如何使用事务日志进行数据库的恢复。这些内容每个都是一个专题，但至少你现在对事务日志有了一个基本的认识，这是基础。不过，我还是强烈建议您认真阅读 SQL Server 在线帮助上关于事务日志的不同主题和其它资源，这样你就会对如何使用日志来工作，并最好的把握它。
