[转]SQL Server DBCC用法大全

www.hj8828.com,然而,你在第二天再检查索引碎片的时候会发生什么情况呢?它可能是大约8%至10%的碎片。因此,如果你每天运行一个索引碎片整理指令而不是每个星期运行一次索引碎片整理指令,每一天要做的工作就很少,这个工作就能够更快地完成,可能在每天的维护时间窗内完成。

控制日志过度措施

如果你的组织对任何潜在数据丢失不能容忍的,那么你没有选择,只能让所有的数据库运行在完整恢复模式里,并且妥当计划你的日志大小和增长。因此索引重建是作为一个单独线程发生的,日志至少会和你重建的索引一样的大小。如刚才所说,索引重组会需要更少的空间,且允许在操作期间通过日志备份来截断日志。这样的话,为了同时避免日志暴涨,可行的话,你可以用日志重组。

如果你的SLA和操作级别协议(Operational
Level
Agreements(OLAs))允许一些潜在的数据丢失,那么在索引重建前l切换到大容量日志恢复模式可以为重建索引最小化空间需求量。但是,要在最小化数据丢失的方式下进行,例如已经讨论确认过了。

不管使用的恢复模式,你可以通过重组索引而不是重建索引来在日志上最小化索引维护操作的影响。可以的话,可以看下微软的指导方针,为了最小化索引维护操作的影响,对于绝大数情况,并不是所有情况,决定什么时候进行索引重建,什么时候进行索引重组(查看索引重组和重建)。他们也声明:对于碎片级别大于5%且小于30%,你应该重组索引,对于碎片级别大于30%,你应该重建它。

但是,在索引维护期间,在保护日志过度增长里,最有效的武器是维护那些真正需要的索引。使用SSMS维护计划向导,索引维护是个孤注一掷的操作:要么重建(或重组)数据库里(维护计划里的所有数据库)的所有索引,要么全不维护。一个更好的方法是使用sys.dm_db_index_physical_stats的DMV来看下碎片程度根据需要来决定索引重建/重组策略。

Ola
Hallengren的免费维护脚本

Ola
Hallengren提供一个综合的免费维护工具,它展示了如何使用sys.dm_db_index_physical_stats进行索引分析来进行智能维护,它可以用来代替SSMS里向导创建的数据库维护计划()。

但是最好的方法,是计划只维护那些可以在查询上提供真正持久影响的索引。逻辑碎片(在乱序中的索引页)挫败了SQL
Server的预读机制(),且使在磁盘上读取连续页I/O-效率更低。但是,这只真正影响从磁盘的大范围扫描。即使对非常大碎片的索引,如果你不扫描表,重建或重组索引不会提高性能。降低页深度(通过页分裂或删除造成的很多缺口)会带来更多的页占用磁盘空间,且在内存里,会需要更多的I/O带宽来传输数据。再说一次,这个碎片格式不会真正影响不频繁修改的索引,因此重建它们不会有帮助。

计划索引维护前,问下自己什么性能标准从维护受益?它会大会减少I/O?它会提高你最昂贵查询的多少性能?它是持久正面影响么?如果这些答案是“否”或“不知道”,那么定期索引维护可能不是个长远的答案。最后,值得注意的是对小索引维护是不值得的。通常引用的阈值是近1000页。在微软,当Paul
Randal管理存储引擎开发团队时,建议这些值作为参考,在在线帮助里记录了。注意,尽管这只是个建议并不对所有环境合适,如Paul在他的博客文章里谈到的:“在线帮助的索引碎片阈值来自哪里?”

 

当你经过这个整个决策过程并且把这些数据库都放在同一台服务器上之后,你如何保持这些系统的健康和在高峰期仍能运行?与其它任何数据库解决方案一样,你仍需要处理自己的备份、索引碎片整理和重建、以及为操作系统和SQL服务器使用补丁。

当然,如果增长没检查,日志文件会扩展直到吞没所有可用磁盘空间或日志文件的最大大小,在这个时候你会收到该死的9002错误(事务日志已满),数据库会变成只读。这篇文章会谈到处理日志不断增长和9002错误的正确方法,还会解释下通常建议截断或收缩事务日志为什么是危险的。

 

例如,你每个星期检查一次索引碎片,它显示碎片是70%。这样,你就可以运行一个索引重建指令清除这些索引。

这篇文章会列出导致事务日志过度增长的常见的问题和错误管理形式,包括:

  Result INT

当然,当把多个数据库集中在一个SQL服务器的时候需要考虑的最重要的问题是,是否有足够的CPU和内存资源处理这些客户程序添加到这个数据库服务器的工作量。如果单个服务器不能提供需要的CPU和内存资源,那么,把这些数据库都集中在那台服务器上就不是一个好的选择。

活动事务

如果log_reuse_wait_desc的返回值是ACTIVE_TRANSACTION,那么你受到来自SQL
Server里完整或大的事务日志的第二个常见原因:长时间运行或未提交的事务。重新执行下来自代码7.1的事务,但不提交,在重新执行下代码7.3,你
会看到这个值返回(不要忘记回去提交这个事务)。

如在第2篇日志截断和空间重用部分介绍的,事务日志里的VLF只有在不包含活动日志部分时才会被截断。如果数据库试用完整或大容量日志恢复模式,只
有日志备份操作才可以进行截断。数据库里长时间运行的事务延迟包含事务开始后生成的日志记录的VLF的截断,包括其它并发事务对数据库里的数据修改产生的
日志记录,甚至当这些改变还没提交时。另外,长时间运行的事务的空间需求量会通过对“补偿日志记录”保留的空间增加,如果在系统里事务回滚的话,这些日志
记录就会产生。这些保留是需要的,保证在回滚期间,这些事务可以成功恢复而不会用完日志空间。

另一个常见对log_reuse_wait_desc值的活动事务值是“孤立”的显式事务,它莫名其妙的从不提交。允许用户在事务里输入的应用程序就特别容易是这类问题。

六、DBCC跟踪标记

处理托管多个数据库的SQL服务器的维护的最大难题是时机。你需要保证你的维护任务能够在这个SQL服务器托管的全部数据库计划的维护时间窗内完成。在任何数据库的维护时间窗之外进行维护工作都将引起数据库运行缓慢,因为硬盘和CPU资源现在被维护活动占用了,而不是处理正常的数据库查询。


  EXEC (‘DBCC TRACESTATUS (-1) WITH NO_INFOMSGS’)

ACTIVE_BACKUP_OR_RESTORE

当log_reuse_wait_desc
column列显示为ACTIVE_BACKUP_OR_RESTORE作为当前等待描述,长时间运行的数据库完整或差异备份是最有可能导致日志重用问题。在数据库完整或差异备份期间,备份过程会延迟日志截断,这样的话事务日志的活动部分会被包含为完整备份的一部分。在备份操作没完成期间,允许修改到数据库的页,当备份用WITH
RECOVERY恢复时,可以让数据库恢复到一致的状态。如果这样的等待造成持续的问题,你会需要调查下优化备份过程的方式,例如提高备份性能(提供备份压缩)或者提高硬盘I/O系统的性能。

一、DBCC 帮助类命令

对托管多个数据库的SQL服务器进行维护的最大难题是时机。

最后,我们会谈下保证你日志文件是平稳和可预见增长的措施,还有日志碎片的最小化问题。在忙碌的数据库里,大型的事务日志会是一个简单的生活事实,如果管理妥当的话,这并不是件坏事,即使大部分时间日志文件空间不可用。

  FROM DBCCResult
八、官方使用DBCC的建议
1、在系统使用率较低时运行 CHECKDB。
2、请确保未同时执行其它磁盘 I/O 操作,例如磁盘备份。
3、将 tempdb 放到单独的磁盘系统或快速磁盘子系统中。
4、允许 tempdb 在驱动器上有足够的扩展空间。 使用带有 ESTIMATE ONLY 的
DBCC
估计 tempdb 将需要多少空间。
5、避免运行占用大量 CPU 的查询或批处理作业。
6、在 DBCC 命令运行时,减少活动事务。
7、使用 NO_INFOMSGS 选项显著减少处理和 tempdb 的使用。
8、考虑使用带有 PHYSICAL_ONLY 选项的 DBCC CHECKDB 来检查页和记录首部
的物理结构。当硬件导致的错误被置疑时,这个操作将执行快速检查。

备份是在一台服务器上托管多个数据库的时候需要解决的另一个关键问题。

当一切正常时,没有必要特别留意什么是事务日志,它是如何工作的。你只要确保每个数据库都有正确的备份。当出现问题时,事务日志的理解对于采取修正操作是重要的,尤其在需要紧急恢复数据库到指定点时。这系列文章会告诉你每个DBA应该知道的具体细节。

在发布,订阅复制时要用服务器实名时可以这样:

即使你在时间窗内不能让这个系统离线,由于碎片整理操作是一种在线操作,这个系统在整理碎片操作的时间将继续发挥作用,只是反应速度比正常情况下稍微慢一点。

妥当的日志管理

没有任何意想不到的操作或问题而导致不正常的日志增长(复制问题,未提交的事务等等),如果事务日志关联的数据库运行在完整恢复模式,还一直增长,其实只有2个原因:

  • 日志文件大小太小,支持不了当前数据库所发生的数据修改。
  • 日志备份的频率不够,满足不了日志文件里快速空间重用。

最好的做法,如果你不能通过减少它们之间的时间来增加日志备份的频率,当在加载的时,可以人为增加日志文件大小而不是让它自动增长,然后恢复原来大小。有大的我们人为增长的事务日志文件,但有最小化数量的VLF并不是个坏事,即使大部分时间日志文件有空余空间。我们会在第8篇详细讨论这个。

DBCC CHECKDB(“databasename”,REPAIR_REBUILD) WITH TABLOCK   
(修复数据库)

数据库备份

索引重建

当重建索引时,不管在线还是离线,使用ALTER
INDEX REBUILD,或是已经废弃的SQL Server 2000里的DBCC DBREINDEX,SQL
Server新创建一个索引的副本,然后一旦重建完整,删除老的副本(这是为什么你至少需要数据文件里索引大小一样的可用空间)

日志记录和在线索引重建

在SQL Server
2008和后续版本,在线索引重建是完整日志操作,在SQL Server
2005里是最小化日志。因此,在后续SQL
Server版本上进行这样的操作本质上需要更多的事务日志空间,可以看下:还有Kalen
Delaney的日志,对于完整和大容量日志2个恢复模式,验证下在在线和离线索引重建期间的日志记录。

在完整恢复模式里,索引重建可以是非常占资源的操作,需要事务日志里的很多空间。在简单或大容量日志恢复模式里,重建索引是最小化日志操作,这意味着只有分配被记录,实际的页并没改变,因此通过这个操作减少了日志空间量。

如果你切换到简单模式进行索引重建,LSN链会立即中断。你只能恢复你的数据库到刚才事务日志备份里的包含的时间点。为了重新开始日志链,你需要切换回完整恢复模式并立即进行一次完整或差异数据库备份。

如果你切换到大容量日志模式(看下第6篇),LSN链还是连续的,但还会影响到进行时间点的恢复,因为包含最小化日志操作的日志备份不能用来恢复到时间点。如果能恢复到时间点的要求是至高无上的,那么索引重建或任何最小化日志操作不要使用大容量日志恢复模式。除非在数据库里没有同时发生的用户活动,你可以使用。不然的话,在可能的情况下考虑在完整恢复模式里进行索引重建。

如果使用的是大容量日志模式,尽可能使时间点恢复的时间最小,这样可以最小化暴露数据丢失风险。为了做到这一点,在完整模式里进行日志备份,切换到大容量日志,进行索引重建,然后切换回完整进行另一个日志备份。

最后一个重点要记住的是ALTER
INDEX
REBUILD操作是在一个单独事务里。如果索引很大,事务的执行时间会很长,在期间,这会阻止日志里的空间重用。这就是说,即使你在简单模式里重建索引,你也要想到自检查点(CHECKPOINT)操作后日志应该保持很小,重建是最小化日志,在剧烈的重建期间,日志文件还会快速扩展。

* DBCC ERRLOG
初始化SQL Server 2000的错误日志文件
* DBCC FLUSHPROCINDB (db_id)
清除SQL Server 2000服务器内存中的某个数据库的存储过程缓存内容
* DBCC BUFFER (db_name,object_name,int(缓冲区个数))
显示缓冲区的头部信息和页面信息
* DBCC DBINFO (db_name)
显示数据库的结构信息
* DBCC DBTABLE
显示管理数据的表(数据字典)信息
* DBCC IND (db_name,table_name,index_id)
查看某个索引使用的页面信息
* DBCC REBUILDLOG
重建SQL Server 2000事务日志文件
* DBCC LOG (db_name,3) (-1–4)
查看某个数据库使用的事物日志信息
* DBCC PAGE
查看某个数据库数据页面信息
* DBCC PROCBUF
显示过程缓冲池中的缓冲区头和存储过程头
* DBCC PRTIPAGE
查看某个索引页面的每行指向的页面号
* DBCC PSS (user,spid,1)
显示当前连接到SQL Server 2000服务器的进程信息
* DBCC RESOURCE
显示服务器当前使用的资源情况
* DBCC TAB (db_id,object_id)
显示数据页面的结构

你需要考察的下一个决定因素是这些系统的服务级协议。需要99%的开机时间的系统能够安排在一起,因为你可能会为这些系统(也许是集群解决方案)建立一个比非重要任务系统更强大的环境。这可以为你节省额外的成本,因为你现在不需要采购任何高端系统。具有更高的服务级协议的系统也可能会有同样的维护时间窗。因此,这些系统在一开始就是互补的。

计划事务日志收缩

如在处理事务日志满错误部分讨论的,事务日志在很少情况下是因为管理不当造成的,日志增长正被活动管理,使用DBCC
SHRINKFILE来回收事务日志占用的空间是个可以接受的操作。

但我们绝不能把日志收缩作为日常,计划维护操作的一部分。原因是我们每次收缩日志,它会为接下来的事务立即再次增长来存储日志记录。如在日志大小和增长部分讨论的,事务日志不能利用即时文件初始化,因此所有日志增长引发SQL
Server需要分配的存储空间填零操作。另外,如果我们依赖事务日志自动增长(下部分会谈到),在日志文件了会聚集更多的VLF,这个日志碎片会影响任何需要读取这个日志文件的进程性能,如果碎片实在太多,也会影响到数据修改性能。

对于事务日志文件的最佳做法是预先设置好它的合适大小,这样的话正常情况下就不会增长。然后,监视它的使用率来决定是否需要人为增长,允许你决定合适的增长大小且决定要添加到日志文件里的VLF的大小和个数。在第8篇我们会具体讨论。

 

只有很少的几种技术能够在一台服务器上运行多个数据库的时候帮助进行数据库服务器的维护。当你考虑数据库整合项目时,希望你能发现这些工具是很有用的。

REPLICATION

在事务复制期间,日志读取代理的任务是读取事务日志,
查找关联修改的日志记录,复制到订阅者(例如,“待定的复制”)。一旦修改被复制,会标记日志为“已复制”。缓慢或延迟的日志读取活动会导致记录剩为“待
定的复制”很长时间,在此期间它们还是活动日志的一部分,因此母VLF不能被截断。对于通过变更数据捕获( Change
Data Capture (CDC))功能需要的日志记录也有类似的问题存在。

不管任何情况,sys.databases的
log_reuse_wait_desc列会显示REPLICATION作为问题根源。在事务磁盘阵列的输出性能里,这个问题本身也暴露了瓶颈。尤其是,
在并发写加载下的延迟读取操作。写入日志文件会持续发生,但用日志读取代理相关的和日志备份文件读取的读操作也要持续的。同一时间有持续的读和写发生,取
决于系统中的日志活跃级别和活动日志部分的大小,会导致磁头随机的I/O活动,因为磁头需要改变位置来读取活动日志的头,然后活动日志的尾。我们可以使用性能监视器(PerfMon)里磁盘计数器 Physical
Disk\Disk Reads/sec 和 Physical Disk\Disk
Writes/sec来故障排除这类问题,看下SQL
Server的故障排除的免费电子书的第2章来进一步了解这个问题的细节:

这些复制等待问题的故障排除的第一步是识别日志读取器,SQL
代理作业是否正常运行。如果不是的话,尝试启动它们。如果启动失败,你要找出为什么。

如果作业是运行的,但是复制一直等待,事务日志快速增长,你需要找到一些方法让相关的日志标记为“已复制”,这样的话它们的母VLF可以被重用。遗憾的是,没有完美的解决方案来避免复制或在CDC环境里的副作用,但你可以尝试下面方法中的一种。

  • 在事务日志复制的情况下,使用sp_repldone命令来标记在日志读取器上当前正等待的所有日志记录为已复制,但还是需要重新初始化订阅者,CDC的话,这个命令不会解决事务日志增长的问题。
  • 停用CDC或复制,进行数据的人为同步。停用CDC或复制后,事务日志中的待定复制的日志记录不会是待定,在完整或大容量日志恢复模式里的下次日志备份,或简单恢复模式里的检查点操作,会清除掉。但是,换来的代价是对于CDC环境需要数据的人为的同步,对于复制需要人为初始化订阅者,如果这个功能加回到数据库的话。

记住直接切换到简单恢复模式,希望能截断日志,是不行的,因为复制和CDC2个均不支持简单恢复模式,还是继续需要日志读取器直到日志读取器的SQL代理处理完成处理。

快照复制架构改变问题

在SQL Server
2005里使用快照复制有一个已知的问题,当架构修改时,它会导致应该标记为复制的架构修改没被标记。这个问题可以看下这个文章的解决方法:

 

重新索引工作

感谢

非常感谢SQL Server故障排除的作者Jonathan
Kehayias,电子书也是可以下载的,为本文提供了大量参考。

也感谢您这么耐心围观完这篇文章,我真是挤牙膏一样,熬了一个星期才能出一篇文章,感谢您的关注!!!

* DBCC CLEANTABLE (‘db_name’,’table_name’)
回收Alter table drop column语句删除可变长度列或text
* DBCC DBREINDEX
重建指定数据库的一个或多个索引
* DBCC INDEXDEFRAG
对表或视图上的索引和非聚集索引进行碎片整理
* DBCC PINTABLE (db_id,object_id)
将表数据驻留在内存中
查看哪些表驻留在内存的方法是:
select objectproperty(object_id(‘tablename’),‘tableispinned’)
* DBCC UNPINTABLE (db_id,object_id)
撤消驻留在内存中的表
* DBCC SHRINKDATABASE(db_id,int)
收缩指定数据库的数据文件和日志文件大小
* DBCC SHRINKFILE(file_name,int)
收缩相关数据库的指定数据文件和日志文件大小

为了应对这种价格昂贵的设置,人们一般在一个服务器或者实例上托管多个数据库(也就是多个应用程序)。虽然这将减少托管所有这些数据库的成本,但是,这增加了管理这些系统的复杂性,因为你现在要处理多个服务级协议和维护窗口。

未提交事务

默认情况下,SQL
Server会在隐性事务里包裹任何数据修改语句来保证,在灾难事件里,SQL
Server可以回滚在故障点已经做出的修改,返回数据到一致的状态。如果修改成功,隐性事务会提交到数据库。和自动发生的隐性事务相比,我们创建显性事务,在代码包裹多个修改在一个事务里,来保证所有的修改通过ROLLBACK命令可以撤销,或者通过COMMIT命令提交让它持久。

当恰当使用时,显性事务可以保证多个表之间的数据修改作为一个单位成功完成,或者全部都不修改。当使用不当时,不管怎样,在数据库里孤立的事务还是活跃的,阻止事务日志的截断,这会导致事务日志增长或填满。在SQL
Server里有很多孤立事务的原因,这超出了这篇文章详细介绍的范围。但是,一些常见的原因有:

  • 长时间运行的事务造成应用程序超时
  • 在T-SQL或应用程序代码里错误的错误处理
  • 触发器执行期间失败
  • 链接服务器失效导致孤立的分布式事务
  • 和BEGIN TRANSACTION
    COMMAND没有对应的COMMIT/ROLLBACK语句

 一旦一个事务开始,它会保持活动直到创建的连接,事务触发COMMIT或ROLLBACK语句,或者连接从SQL
Server中断(当使用绑定的链接,会允许会话共享锁,这是个异常)。

现在的应用程序通常会使用连接池,在池里保持与SQL
Server的连接让程序重用,即使当程序代码在连接上调用Close()方法。当对孤立事务进行故障排除是理解最后一点非常重要,因为即使连接在加入或返回到应用程序连接池前被重置,数据库里打开的事务还是继续存在的,如果它们没有正常结束的话。

* DBCC CHECKALLOG (‘数据库名称’)
检查指定数据库的磁盘空间分配结构的一致性
* DBCC CHECKCATALOG (‘数据库名称’)
检查指定数据库的系统表内和系统表间的一致性
* DBCC CHECKCONSTAINTS (‘tablename’)
检查指定表上的指定约束或所有约束的完整性
* DBCC CHECKDB
检查数据库中的所有对象的分配和结构完整性
* DBCC CHECKFILEGROUP
检查指定文件组中所有表在当前数据库中的分配和结构完整性
* DBCC CHECKTABLE
检查指定表或索引视图的数据、索引及test、ntest和image页的完整性
* DBCC CHECKIDENT
检查指定的当前标识值
* DBCC SQLPERF(UMSSTATS) undocumented in BOL
可以用来检查是否CPU使用达到瓶颈
最关键的一个参考数据num runnable,表明当前有多少个线程再等待运行
如果大于等于2,考虑CPU达到瓶颈

每一个实例或者每一个服务器设置一个单一的数据库能够使数据库管理更方便。然而,这样做很快将增加你的数据库解决方案的成本,因为你要对你希望托管的每一个数据库购买一台新的服务器或者新的SQL服务器许可证。

处理事务日志满错误

最坏的情况,事务日志管理不当或突发、快速的日志增长会造成事务日志增长,最后吞食完硬盘上所有可用空间。到这个时候就不能增长了,你会遇到9002错误,事务日志满错误,数据库会变成只读。

尽管这个问题很紧迫,冷静面对很重要,避免这类接下来会提到的”无意识“的解决方法,处理不当或做不该做。显然当前的问题是让SQL
Server可以继续写日志,通过生成更多可用空间。如果起因是缺少日志备份,第一个要做的是重新运行代码7.1;如果log_reuse_wait_desc列返回值是 Log
Backup,那么和可能这是问题原因。一个在MSDB数据库里对backupset表的查询,如代码7.10所示,会确认是否要在数据库上进行一次日志备份,还有上一次日志备份的时间。

1 USE msdb ;
2 SELECT   backup_set_id ,
3          backup_start_date ,
4          backup_finish_date ,
5          backup_size ,
6          recovery_model ,
7          [type]
8 FROM     dbo.backupset
9 WHERE    database_name = 'DatabaseName'

(代码7.10:哪个备份已做,什么时候做的)

在type列,D代表数据库备份,L代表日志备份,I代表差异备份。如果没有日志备份,或者它们并不频繁,那么你最好的做法是进行一次日志备份(这里假定数据库运行在完整或大容量日志恢复模式)。希望,这个能释放日志里的实在空间,然后你可以进行合适的日志备份计划和日志增长管理策略。

如果因为某些原因不能进行日志备份,例如磁盘空间不足,或者进行日志备份的时间超过可接受的问题解决时间,那么,取决于对问题数据库的灾难恢复策略,或许可以通过临时切换到简单恢复模式来强制日志截断,这样在检查点的时候日志中不活动的VLF会被截断。然后你可以切换回完整数据库恢复模式,进行新的完整数据库备份(或差异备份,这里假定先前已经有一次完整备份)来重新开始用于时间点恢复的日志链。当然,你还是充分调查问题,来保证空间不会再次直接吞食完。还有记住这点,刚才讨论过的,如果阻止空间重用的问题不是日志备份,那么这个技术就无效了,因为这些记录会保留在活动日志里,阻止截断。

如果缺少日志备份不是问题,或者进行完日志备份不能解决问题,那么调查原因可能会花更多的时间。最快和最简单的方法是在日志硬盘上增加更多的空间。这表示要清理掉其他文件,或者增加当前日志硬盘的容量,或者在不同的硬盘列里增加额外日志文件,但这会占用你一点喘息的空间,你需要让数据库摆脱只读模式,然后进行一次日志备份。

如果日志备份释放空间失败,你要找出什么阻止了日志里的空间重用。调查下sys.databases(代码7.1)来找出什么阻止了日志空间重用,采取合适的行动,如刚才缺少日志空间重用部分介绍的。

如果这个啥都没透露,你需要进一步调查找出什么操作造成过度日志导致日志增长,如事务日志过度增长部分介绍的。

最后,解决了任何空间重用问题,很可能我们的日志文件会在磁盘上占用很大的空间。作为一次性的测量,例如假定我们采取措施保证日后日志增长有妥善的管理(下一部分就会谈到),是可以使用DBCC
SHRINKFILE来回收臃肿事务日志文件使用的空间。在第8篇我们会提供如何做的例子。

我们要么指定收缩日志的文件target_size,要么指定0位目标大小,让日志收缩的尽可能小,然后立即使用ALTER
DATABASE来调整到合适的大小。后者是推荐的方法,它会最小化日志文件的碎片。碎片问题是你应该从不定期进行的DBCC
SHRINKFILE任务的主要原因,因为它只用来控制日志大小;我们会在下个部分详细讨论这个。

 

当你决定在同一台服务器上托管多个数据库的时候,你要考虑的第一件事是这些系统是否有互补的维护窗口。如果一个系统不能在夜间放慢速度或者离线,另一个系统不能在白天放慢速度或者离线,这些系统就不适合共享一个服务器,因为你在需要为系统使用补丁或者处于其它原因要让系统离线的时候,你没有有效的维护时间窗。

日志过度增长:索引维护操作

索引维护操作是个很常见的导致事务日志使用率过度和增长的原因,尤其数据库运行在完整恢复模式里。进行索引维护需要日志空间量取决于下列因素:

  • 重建还是重组——通常索引重建在日志里会使用更多的空间
  • 恢复模式——如果时间点恢复的风险已理解且可接受的,那么索引重建可以临时通过切换到大容量恢复模式里的最小化日志。但索引重组始终是完整记录的。

DBCC DBREINDEX (‘t_icitem’ , ‘   ‘)     修复此表所有的索引。

每一个数据库都有自己的备份要求。备份数据库也许是能够在SQL服务器运行时执行的最繁重的任务。并不是因为这种备份需要占用大量的CPU和内存资源(这个任务占用的资源一般是很低的,除非你在备份的时候对数据库进行压缩),而是因为备份一个大型数据库需要占用大量的硬盘资源。

处理不当和不该做的事

遗憾的是,在网络上搜索”事务日志满“会返回大量论坛的帖子,博客文章,甚至很多复制于SQL
Server网站的文章,那些建议矫正的方法,坦白说,很危险。我们在这里会谈其中一些流行的建议。

二、DBCC 检查验证类命令