标签: dbcc

我有一个数据库,[我的数据库],它有以下信息:
SQL Server 2008
MDF大小:30 GB
LDF大小:67 GB

我想尽可能地缩小日志文件,所以我开始寻找如何做到这一点.警告:我不是一名DBA(甚至是接近DBA)并且一直在通过这个任务感受到进步.

首先,我刚进入SSMS,数据库属性,文件,并将初始大小(MB)值编辑为10.这将日志文件减少到62 GB(不完全是我输入的10 MB).所以,我附加了SQL Profiler,看到正在调用DBCC SHRINKFILE.然后我将该命令输入查询编辑器,这是结果.

DBCC SHRINKFILE (N'My DB_Log' , 10)

输出是:

Cannot shrink log file 2 (My DB_Log) because the logical log file located at the end of the file is in use.
DbId   FileId      CurrentSize MinimumSize UsedPages   EstimatedPages
------ ----------- ----------- ----------- ----------- --------------
8      2           8044104     12800       8044104     12800

(1 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

然后我做了一些研究,发现了这个:

http://support.microsoft.com/kb/907511

这说我需要在收缩文件之前备份日志文件,以便释放虚拟日志文件并且收缩文件可以完成它的工作 - …

这个wiki帖子概述了问题和解决方案.我想发布这个可能有类似问题的其他人,因为我找不到任何具体的解决方案来解决其他问题.

我们最近将SQL Server 2000数据库升级到SQL Server 2005.服务器上的一个数据库是MS Access数据库的后端.MS Access数据库使用传递查询,通过无DSN的ODBC连接到SQL Server.

无DSN连接字符串的示例如下所示:

ODBC; DRIVER=SQL Server;SERVER=servername;APP=Microsoft® Access (Pass Through
    Query);DATABASE=databasename;Network=DBMSSOCN;ConnectionTimeout=20;
    Trusted_Connection=Yes

升级后,我们发现用户无法运行传递查询,并显示以下错误:

ODBC - 与"SQL Server"的连接失败

这最初似乎是一个权限问题,因为将SQL服务器登录的priveledges提升到sysadmin服务器角色缓解了这个问题(但显然这不是一个很好的解决方案).

从登录sysadmin角色后,我们发现当通过Management Studio连接到SQL Server时,登录可以执行存储过程.MS Access中无法进行相同的登录.这指向了MS Access在尝试执行存储过程时所做的事情 - 而不是权限问题.

我们使用Profiler在服务器上运行了一个跟踪,这显示MS Access试图在存储的proc执行之前执行以下命令:

DBCC TRACEON(208)

在存储过程执行之前,它似乎在此命令失败.对Web的研究表明,DBCC TRACEON(208)相当于使用'SET QUOTED IDENTIFIERS ON'命令,并且在SQL 2005中,运行此DBCC命令的priveledges已被撤销.

经过进一步研究,我们发现对MS Query的引用存在类似的问题,并且连接字符串的APP组件应该从"MS Query"更改为其他内容.

在预感中,我们更改了ODBC连接字符串的APP组件,并且MS Access在存储过程执行之前不再尝试执行DBCC TRACEON(208).

经过进一步测试,我们将问题跟踪到APP组件中包含的"版权"符号:

APP=Microsoft® Access (Pass Through Query)

通过删除版权符号,一切都很好的连接和应用程序工作,就像以前在SQL 2000上所做的那样.

希望这可以帮助其他有类似问题的人.

我有一个大型数据库(90GB数据,70GB索引)在过去一年中一直在缓慢增长,并且增长/变化不仅引起了索引的大量内部碎片,而且导致了表本身的大量内部碎片.

很容易解决(大量)非常分散的索引 - REORGANIZE或REBUILD将根据它们的碎片程度来处理它 - 但我在清理实际表碎片时可以找到的唯一建议是添加聚簇索引到桌子.之后我会立即删除它,因为我不希望桌面上有聚簇索引,但是有没有另一种方法可以在没有聚簇索引的情况下执行此操作？一个"DBCC"命令会这样做吗？

谢谢你的帮助.

我有一个当前正在运行的存储过程,似乎挂起/锁定特定查询.我怎么才能看到哪个查询？优选地,不修改过程.

运用

DBCC Inputbuffer (65)

给我

语言事件0 EXEC mySP;

据我所知,如果我执行'DBCC FREEPROCCACHE'和'DBCC DROPCLEANBUFFERS',整个服务器的缓冲区将被清除.我想知道是否只有清理指定数据库的缓冲区.因此,对其他数据库的查询不会受到影响.

我有一个带有标识集的SQL表:

CREATE TABLE MyTable(
    MyTableID int IDENTITY(1,1) NOT NULL,
    RecordName nvarchar(100) NULL)

这张桌子发生了什么事,导致奇怪的行为.我需要找出什么.

发生插入时:

INSERT MyTable(RecordName) 
VALUES('Test Bug')

SELECT SCOPE_IDENTITY() -- returns 0
SELECT * FROM MyTable   -- displays: 0, 'Test Bug'

这是一个问题,因为这个插入上面的代码需要第一个ID 1- 我无法弄清楚如何IDENTITY(1,1)以此结束0.

如果(在执行之前INSERT)我检查身份,它返回null:

DBCC CHECKIDENT (MyTable, NORESEED)

检查身份信息:当前标识值'NULL',当前列值'NULL'.

我知道几种解决方法; 我需要知道桌子是如何进入这种状态的？

我知道CHECKIDENT返回null 的唯一方法是,如果刚刚创建了表,但是后来IDENTITY(1,1)被尊重并且INSERT原因SCOPE_IDENTITY()是1.

或者,0如果我强制-1作为当前种子(DBCC CHECKIDENT (MyTable, RESEED, -1)或者SET IDENTITY_INSERT MyTable ON),我可以获得下一个ID 但是然后检查报告当前-1 …

MSDN 关于命令"DBCC CHECKDB" 的文章解释了在语法部分中执行数据库修复的三种方法:

- REPAIR_ALLOW_DATA_LOSS
- REPAIR_FAST
- REPAIR_REBUILD

但是当我在寻找如何修复可疑数据库时,我发现了以下声明,我无法理解这三种模式中的哪一种:

DBCC CHECKDB(databaseName,修复)

我执行了该声明,它工作正常.我很困惑,因为没有任何对"修复"参数的引用而没有用"_allow_data_loss","_ fast"或"_rebuild"完成单词.

提前致谢,

使用 DBCC SHOWCONTIG 命令，我们可以得到一行的最小、最大和平均大小。只是为了确保，度量单位是字节，对吗？

我有大约 300 个表，每个表有 5.5kk 行。其中一行使用 nvarchar(128) 作为数据类型 (SQL Server 2012)。
我们决定将其更改为 int 并将 FK 添加到包含所有 nvarchar 的字典表中。

完成所有操作后，我删除了 nvarchar 列，但表的大小保持不变。我使用 DBCC CLEANTABLE 并重建索引以回收可用空间，但表的大小仍然没有改变。

到目前为止，我发现的唯一方法是将所有数据复制到新表中。

问题：我在这里缺少什么？为什么空间仍然被标记为已用而我不能通过收缩或 CREANTABLE 命令释放？

谢谢！

答：看起来答案很简单，由于我缺乏知识，我无法找到它。这里的主要问题是堆碎片。这个查询对我有用：

ALTER TABLE [TABLE_NAME] REBUILD

CREATE TABLE [dbo].[Data_](
    [ID] [bigint] PRIMARY KEY IDENTITY(1,1) NOT NULL,
    [Text] [nvarchar](128) NOT NULL,
    [Category] [tinyint] NOT NULL,
    [Country] [nvarchar](2) NOT NULL,
    [ImportTimestamp] [date] NOT NULL
)

CREATE TABLE [dbo].[Data_New](
    [ID] …