Questions tagged «dbcc»

DBCC是SQL Server提供的T-SQL语句。该标签用于有关DBCC及其使用的问题。


6
缩小日志文件不会减小大小
我有一个数据库,该数据库具有350 MB数据文件(.mdf)和4.9 GB日志文件(.ldf)。恢复模型设置为FULL。 当我尝试收缩日志文件时,它没有收缩。 我知道收缩数据库是不好的,不应该这样做。但是我仍然在尝试缩小日志文件。 我跑的时候 DBCC SQLPerf(logspace) 我发现日志大小为4932 MB,使用的日志空间为98.76%! 然后我尝试了这个命令 USE <databasename>; DBCC loginfo; 现在几乎所有的VLF均为“状态2”,这意味着所有VLF都在使用中。 我尝试进行日志备份,然后缩小日志文件。缩小并没有减小尺寸。 我将恢复模型更改为SIMPLE并尝试再次缩小,但这也无济于事。 我检查了未结交易 DBCC opentran (database); 并发现现在没有任何交易打开。 是什么阻止了我缩小日志文件?我该如何解决?

1
DBCC CheckDB会丢失哪些类型的损坏?
这个问题是由较早的帖子提示的,我将一个数据库归档以备将来调查,该数据库已恢复,具体操作如下: BACKUP 'BrokenDatabase' detected an error on page (1:123456) in file ’BrokenDatabase.mdf'. Error: 3043, Severity: 16, State: 1. 在链接的问题和我准备进行DBCC PAGE调查的备份中,DBCC CHECKDB顺利通过,但显然存在损坏。 CHECKDB将通过但BACKUP WITH CHECKSUM失败将发生什么类型的损坏?

1
SHRINKFILE失败-为什么增加文件大小可以解决?
我正在运行一些SHRINKFILE操作来清理文件组中的一堆微小的不必要文件。对于其中一种收缩,以下命令将导致错误: DBCC SHRINKFILE (N'myfile' , EMPTYFILE)' 无法缩小数据库ID x的文件ID x,因为它正在被另一个进程缩小或为空 它不是空的也不是收缩的。它正在除我以外的任何人当前未使用的数据库上运行。自动收缩功能未启用,也从未启用过。但是,如果真的很重要,在我开始使用该数据库之前,会定期对其进行手动收缩。 在SQLServerCentral上,十年前的一个线程建议在文件中添加一些MB,因为“重新设置内部计数器或开关会告诉它现在不在收缩中”。 这很有效-很棒。但是,谁能更详细地说明SQL Server内部的工作原理/原因?

2
删除辅助数据文件。DBCC SHRINKFILE:无法移动页面,因为它是工作表页面
我为创建了太多辅助数据文件(.ndf)tempdb。要删除多余的文件,我需要清空文件(内容将移至其他文件): DBCC SHRINKFILE('tempdbfile8', EMPTYFILE); 然后删除文件: ALTER DATABASE tempdb REMOVE FILE tempdbfile8; 但是EMPTYFILE命令返回错误: DBCC SHRINKFILE: Page 8:41920 could not be moved because it is a work table page. Msg 2555, Level 16, State 1, Line 2 Cannot move all contents of file "tempdbfile8" to other places to complete the emptyfile operation. …

1
有关SQL Server基准测试的明确步骤列表?
在为使用SQL Server的应用程序运行性能测试/基准之前,我希望能够将实例设置为“干净”状态,而无需重新启动实例。我倾向于遵循一些步骤,但是我想建立一个确定的列表,该列表的顺序正确,没有多余的步骤。 此步骤列表是否完成将SQL Server设置为“干净”状态? 顺序逻辑/正确吗? 有多余的步骤吗? CHECKPOINT -- Write all dirty pages DBCC DROPCLEANBUFFERS -- All should be clean after checkpoint? DBCC FREEPROCCACHE -- Clear the plan cache DBCC FREESYSTEMCACHE -- Is this necessary after FREEPROCCACHE? DBCC FREESESSIONCACHE -- May not be necessary if distributed queries aren't used, but want …

1
行为异常DBCC Shrinkfile
我正在尝试对其中95%的数据已被存档和删除的数据库运行1GB的dbcc收缩文件。我用的是235GB的文件,其中9GB是数据/索引。我想缩小到50GB。我知道收缩数据库文件是不好的,它会导致碎片等。作为数据清除/收缩的一部分,我们还有一个重建idnex脚本。 当我在自己的工作站(四核,12GB RAM,2个SATA驱动器)上对数据库运行dbcc收缩文件脚本时,收缩过程大约需要8-10分钟。 当在数据库发布后数据清除的相同副本上运行相同的代码时,在我们的测试环境(80多个核,128GB RAM,SSD SAN)中,需要70分钟。请注意,运行收缩文件时,此服务器上几乎没有活动。它已运行4次,结果相同。 然后,我采取了另一种方法,将剩余的9GB移动到另一个文件组和物理文件。在空的230GB文件上运行dbcc收缩文件以将其缩减到50GB,在我自己的工作站上花费的时间不到1分钟。 使用相同的方法,在测试环境上,又需要70分钟以上的时间。 在测试环境运行70分钟的过程中,按照布伦特·奥扎尔(Brent Ozar)的脚本操作前后,我已经对waitstats进行了快照,并且返回的waittypes值得关注。下面的前3行: 秒采样时间采样持续时间(以秒为单位)wait_type等待时间(秒)等待次数平均每次等待的毫秒数 2013-05-28 11:24:22.893 3600 WRITELOG 160.8 143066 1.1 2013-05-28 11:24:22.893 3600 CXPACKET 20.9 13915 1.5 2013-05-28 11:24:22.893 3600 PAGELATCH_EX 11.1 443038 0.0 Windows事件日志显示没有异常。在这一点上,我要抓挠,为什么与独立工作站相比,忍者硬件要花这么长时间。

2
可以同时在不同的表上运行两个DBCC INDEXDEFRAG命令吗?
我当前正在运行一个脚本,该脚本在SQL Server 2005数据库中的每个表上一次执行一个DBCC INDEXDEFRAG。由于空间限制和正常运行时间的要求,不能选择使用DBCC DBREINDEX而不是INDEXDEFRAG。 我注意到,某些表需要很长时间才能进行碎片整理。例如,如果我检查“ sys.dm_exec_requests”动态管理视图,则可以看到以下INDEXDEFRAG当前正在删除table_id为829610394的表的聚集索引: DBCC索引(0,829610394,1) 我知道碎片整理过程需要很长时间才能完成。撇开当前正在运行的脚本最终会对所有表进行碎片整理这一事实,在执行当前命令时在另一个表的聚集索引上手动运行另一个DBCC INDEXDEFRAG是否对我有什么危害?如果执行此操作,实际上是否会同时对两个表进行碎片整理?

1
跟踪标志1222不起作用?
我有一个客户站点,其中有两个配置类似的2008r2 SQL Server“ A”和“ C”。在两台服务器上,启用了跟踪标志1204和1222,并DBCC tracestatus在两台服务器上显示以下内容: TraceFlag Status Global Session 1204 1 1 0 1222 1 1 0 3605 1 1 0 在A上,跟踪标志按预期工作,当发生死锁时,我们在错误日志中同时获取1204和1222死锁报告。但是,在C上,仅显示1204报告,而我们从未获得1222报告。 对于我的一生,我看不出有什么区别。我已经在Google上进行了广泛的搜索,并阅读(并重新阅读了)这些跟踪标志上的MS文档,但找不到任何此类行为的报告,也没有任何提示可能导致这种情况的提示。唯一接近的是偶尔声称没有跟踪标记起作用的情况,但是事实证明,如果它们在启用命令中有错别字。我知道这里不是这种情况,因为我已经使用DBCC TRACESTATUS进行了确认。 因此,对于可能导致仅跟踪标记1222不工作和/或如何修复跟踪标记的任何见解,将不胜感激。 好吧,这是一个有趣的发展。每当我自己生成一个死锁(使用此代码:https : //stackoverflow.com/questions/7813321/how-to-deliberately-cause-a-deadlock)时,我都会在错误日志中获得两个跟踪报告。从应用程序开始每两天就会发生“自然”死锁,似乎只触发其中一个死锁报告。不确定是否有帮助,是否有任何理由相信跟踪1222不会报告与1204相同的所有死锁条件?

2
PostgreSQL中的数据库一致性检查器
PostgreSQL中是否有任何DBCC(数据库一致性检查器)命令?我可以找到SQL Server DBCC命令,但找不到Postgres吗?我读到postgresql具有性能调整的内置功能,并且没有DBCC命令可用于postgres。是真的吗

1
具有全局标志的DBCC TRACEON
在“ 需要帮助对Sql Server 2005死锁方案进行故障排除 ”问题中,建议使用DBCC TRACEON (1204, -1)全局跟踪死锁。 在BOL中阅读此命令时,它指出仅当用户或应用程序未在系统上同时运行语句时才应使用该命令。这是否意味着在启用此跟踪标记时我们必须处于单用户模式?另外,为什么要这样做,遵循建议很重要?(在始终运行的生产系统中,似乎很难遵循。)
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.