小编Mat*_*DBA的帖子

我在我的投资组合中发现了许多使用默认自动增长设置（1 MB 或 10% 增量）创建的数据库，这些数据库已经扩展了很长一段时间。如果我想了解每个 DB 文件的外部碎片量，是否可以从元数据中获取 DB 文件的大小修改次数（通过自动增长或手动）？澄清一下，我是否可以从元数据中获取 DB 生命周期内 DB 文件修改的历史记录，而不仅仅是因为实例重启？

在从集群中删除一个使用过的磁盘资源的过程中，我将遵循以下步骤：1）删除 SQL Server 资源对磁盘的依赖，2）使磁盘资源脱机，3）从 SQL 资源组中删除磁盘资源, 4) 从可用存储池中删除磁盘资源。

我正在一个带有两个 SQL 2008 R2 命名实例（运行 Win2K8R2 SP1 build 6701，64 位）的双节点集群上执行此操作。在上述步骤 3 中删除资源时，SQL 将脱机，所有磁盘资源将返回可用池，并且 SQL 资源（网络名称、SQL Server、SQL Server 代理）将消失。通过服务控制台后，SQL 服务确实重新启动，因为所有磁盘仍然在同一个节点上。

我cluster res从命令提示符运行，我看到 SQL 服务资源仍然存在，在可用存储中，并且处于脱机状态。

要将资源带回适当的组，我可以通过cluster命令移动它们吗？

我正在一个新的 SSD 阵列上进行计时试验，该阵列同时运行 SQLIO 测试和 DB 还原和 DBCC CHECKDB 调用的实际工作负载。我发现我的 SQLIO 批处理生成的 IOPS 和吞吐量与我观察到的工作负载之间存在重大差异，工作负载仅请求我使用 SQLIO 能够观察到的一小部分，通常在 5,000 IOPS 范围内并产生不超过 400 MB/s 的吞吐量。

如果硬件有足够的容量来处理负载，那么 DBCC CHECKDB 将消耗多少资源事件是否存在固有限制？我可以尝试哪些设置来扩展 DBCC CHECKDB 对 CPU 和磁盘资源的使用？

以下是具体...

从 systeminfo

OS Name: Microsoft Windows Server 2012 R2 Standard OS Version: 6.3.9600 N/A Build 9600 System Manufacturer: HP System Model: ProLiant DL580 G7 System Type: x64-based PC Processor(s): 4 Processor(s) Installed. [01]: Intel64 Family 6 Model 46 Stepping 6 GenuineIntel ~1042 Mhz Total Physical Memory: 131,062 MB …

我试图找出我为验证备份和执行 DBCC 检查而采购的新硬件上可以承受的峰值负载。我一直在使用 Crystal Diskmark 来获取吞吐量统计信息，这有助于我对复制/恢复任务的顺序 I/O 进行基准测试。我无法衡量 DBCC 检查可以维持多少随机 I/OI。我正在考虑使用 iometer 和 sqliosim，但想知道配置最适合模拟 DBCC 检查。

我正在测试的硬件包括一台 R720，配备双 E5-2609 8 核、32 GB RAM、Windows 2008 R2 Standard、SQL Server 2008 R2 Standard with SP2，以及配备 24 个 15k SAS 轴的 PowerVault 3620f 连接到两个双核R720 上的端口 HBA。我一直在试验 4、8 和 12 轴 RAID 0 组（我可以承受失去容错能力，因为作为测试过程的一部分，DB 的预期寿命为几分钟）。

我想我可以使用上述硬件同时运行多个 DBCC 检查而不会出现磁盘争用。我可以选择将 RAM 升级到 64 GB，将 O/S 升级到 Enterprise，但由于许可成本，可能无法将 SQL 升级到 Enterprise。

关于如何使用 iometer、sqliosim 或其他实用程序确定 DBCC 的最大随机 I/O 的任何建议将不胜感激。

我调查了一个经历意外重启的实例，并遇到了通常的服务控制事件，但没有与之关联的用户登录。是否仍然有可能是授权用户启动了重新启动，还是由于 Windows 发出了命令？如果是授权用户，在 SQL 错误日志和事件日志之外，我可以在哪里尝试识别用户？

Log Name: System Source: Service Control Manager Date: 12/24/2014 9:02:24 AM Event ID: 7036 Task Category: None Level: Information Keywords: Classic User: N/A Computer: XXX Description: The SQL Server Agent (MSSQLSERVER) service entered the stopped state.

在用于部署的大型 DDL 脚本中，将 SET NOEXEC ON 作为错误处理的一部分使用是很常见的，以防止下游代码的执行。如果与 SET NOCOUNT ON 结合使用，则除非进行适当的部署后检查，否则可能会无意中抑制代码执行。我检查了 sys.dm_exec_sessions 并且没有任何 SET 语句的属性。从 DBA 的角度来看，是否有其他方法可以检查当前会话或任何用户会话的任一语句的状态？

这是一个快速示例...

CREATE TABLE dbo.MJZTest
    (Col1 int)
ON [PRIMARY2]
GO
IF @@ERROR<>0
    SET NOEXEC ON

INSERT INTO dbo.MJZTest (Col1)
VALUES (1)
GO

在上面的例子中，如果[PRIMARY2]文件组不存在，阻止了表的创建，@@ERROR检查将调用SET NOEXEC ON阻止后续INSERT语句实际执行的语句。我见过使用 RedGate SQL Compare 等工具生成这种类型的代码。

问题是，如果执行代码的人SET NOEXEC OFF在调试期间忽略运行以重置会话，他们可能会收到一条Command(s) completed successfully.消息，而不管实际结果如何。

服务器 A 和服务器 B 具有相同的硬件和实例配置（A 是生产，B 是 QA）。B 的数据库是从一周前 A 的备份中恢复的。开发团队向我提供了这个查询。

SELECT 
        c.Start
        ,c.[End]
        ,c.Word
        ,doc.UniqueDocumentNumber
        ,doc.EID
        ,c.CUI
        ,c.Concept
        ,a.OID
        ,doc.DocumentTypeName
        ,doc.ActivityDtTm
        ,CAST(doc.DocumentTypeId AS INT) AS MedCode
        ,CASE WHEN c.[Count] = 0 THEN  CAST(0.00 AS REAL)
           ELSE CAST(LOG(c.TotalCount / c.[Count]) AS REAL) END AS 'idf'
        ,c.[Count]
        ,c.TotalCount
FROM ECHO..AEID201 a
INNER JOIN ALPHA..XADocuments doc (NOLOCK) ON a.EID = doc.EID
CROSS APPLY (SELECT t.start,t.[end],t.word,t.cui,t.eid,
   t.UniqueDocumentNumber,cu.[Count],cc.TotalCount,core.Concept 
FROM HOTEL.dbo.Htf_Index AS t
INNER JOIN HOTEL..Doc_CUI_Counter AS cu ON cu.CUI=t.CUI AND cu.DocumentTypeID=t.DocumentTypeID
INNER JOIN HOTEL..Doc_Counter …

我正在使用 COTS 包在我的 SQL Server 产品组合中执行索引重建。不幸的是，该包没有为单个实例或数据库全局设置索引填充因子的选项（我可以在逐个索引的基础上安排重建时设置它们，但是有 1,600 多个索引，我想设置他们提前批量）。在 ALTER INDEX 命令之外，有没有办法重新定义现有的索引填充因子？

我有一个date使用 RANGE LEFT的简单的基于分区函数...

CREATE PARTITION FUNCTION [PF_YEAR_LEFT](date) AS RANGE LEFT 
    FOR VALUES (N'1992-12-31', N'1993-12-31', N'1994-12-31')
GO

CREATE PARTITION SCHEME [PS_YEAR_LEFT] AS PARTITION [PF_YEAR_LEFT] 
    TO ([DATA_1992], [DATA_1993], [DATA_1994], [DATA_1995])
GO

在上面的代码中，文件组 [DATA_1995] 将保留超出最后一个分区边界的值。因此，如果我选择添加新文件组并以这种方式拆分附加边界的功能......

ALTER PARTITION SCHEME [PS_YEAR_LEFT] NEXT USED [DATA_1995]
GO

ALTER PARTITION FUNCTION [PF_YEAR_LEFT]() SPLIT RANGE (N'1995-12-31')
GO

ALTER PARTITION SCHEME [PS_YEAR_LEFT] NEXT USED [DATA_1996]
GO

ALTER PARTITION FUNCTION [PF_YEAR_LEFT]() SPLIT RANGE (N'1996-12-31')
GO

对于超出最高边界的值，文件组 [DATA_1995] 保留在最后一个分区位置。

在最初创建分区方案后是否可以更改最后一个文件组，或者是创建新分区方案并将使用旧方案的所有索引重建为新方案的唯一方法？