标签: sql-server-2008-r2

认为这已通过以下链接解决 - 解决方法有效 - 但补丁没有。与 Microsoft 支持一起解决。

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

好的，所以我有一个问题，我想把它扔给 StackOverflow，看看是否有人有想法。

请注意，这是 SQL Server 2008 R2

问题：启用触发器时，从包含 15000 条记录的表中删除 3000 条记录需要 3-4 分钟，禁用触发器时只需 3-5 秒。

表设置

我们将称为 Main 和 Secondary 的两个表。Secondary 包含我要删除的项目记录，因此当我执行删除操作时，我会加入到 Secondary 表中。在删除语句之前运行一个进程，以使用要删除的记录填充辅助表。

删除声明：

DELETE FROM MAIN 
WHERE ID IN (
   SELECT Secondary.ValueInt1 
   FROM Secondary 
   WHERE SECONDARY.GUID = '9FFD2C8DD3864EA7B78DA22B2ED572D7'
);

这个表有很多列和大约 14 个不同的 NC 索引。在我确定触发器是问题之前，我尝试了很多不同的事情。

• 开启页面锁定（我们默认已关闭）
• 手动收集统计数据
• 禁用自动收集统计信息
• 已验证的索引运行状况和碎片
• 从表中删除聚集索引
• 检查执行计划（没有任何显示为缺少索引，实际删除的成本为 70%，记录的连接/合并成本为 28%

触发器

该表有 3 个触发器（插入、更新和删除操作各一个）。我修改了删除触发器的代码以使其返回，然后选择一个以查看它被触发了多少次。它在整个操作过程中只触发一次（如预期的那样）。

ALTER TRIGGER [dbo].[TR_MAIN_RD] ON [dbo].[MAIN]
            AFTER DELETE
            AS  
                SELECT 1
                RETURN

回顾

• 使用 …

我正在使用 BIDS 在 SSAS 2008 r2 中创建一个多维数据集。

我使用向导创建了一个时间维度。该配置的一部分是选择日期范围。

创建后，我意识到我需要比最初指定的日期范围更广的日期范围。

我确实发现我可以打开维度，转到属性，并在那里重新定义日期范围。我保存并重新处理了维度，但表中的实际日期范围并未增加以包括新添加的日期。

有没有另一种方法可以让这个时间维度增长，还是我需要从头开始重新创建它？

我们的空间快用完了。清除错误日志的安全方法是什么？

我想知道 SQL Server 2008 R2 是否有默认的SELECT语句日志记录方案（或任何其他与此相关的 T-SQL）。

如果是，我在哪里可以看到它？如果没有，我该如何设置？

我的 SQL Server 2008 R2 有 323 个数据库，在我的 C: 驱动器上消耗了大约 14 GB，这是一个快速的 SSD。

因为我想回收 C: 驱动器上的一些空间，所以我想将它们移动到我的 D: 驱动器。

我找到了这篇 MSDN 文章，但这似乎是只移动一个数据库的过程。

是否有自动方式或脚本一次移动我的所有数据库？

我正在运行 sql 2008 r2 并且数据库在过去 3 年中运行良好且快速，直到大约 3 个月前我们在非常活跃和使用过的表上添加了 ntext 字段。现在我们开始用尽服务器空间，因为这个表的大小越来越大。

我读到了缩小，我们不想放松 db 的索引，因为它多年来一直在快速工作，而且我们不想让碎片消耗殆尽。

我们决定删除该字段及其所有值： 有没有办法删除 ntext 字段及其所有值并释放空间而不删除索引，不缩小，不损失数据库性能？

我附上 db size 查询输出，以显示过去 5 个月的大小扩展。

检查 VARCHAR 字段是否具有非 Ascii 字符的最佳方法是什么？
CHAR(1)通过CHAR(31)和CHAR(127)通过CHAR(255)。

我尝试使用PATINDEX并遇到了以下问题。

检查下范围是否正常工作。

SELECT *      
FROM mbrnotes      
WHERE PATINDEX('%[' + CHAR(1)+ '-' +CHAR(31)+']%',LINE_TEXT) > 0  

我的数据有 0x1E 的三个记录，并且所有三个都返回了。

但是当我只检查上限时：

SELECT *      
FROM mbrnotes      
WHERE PATINDEX('%[' + CHAR(127)+ '-' +CHAR(255)+']%',LINE_TEXT) > 0 

它返回接近表中的所有记录（表计数 170737 并返回计数 170735），并且由于我的数据在此范围内没有任何值，我认为它不应该返回任何记录。

我有两个数据库服务器，通过链接服务器连接。两者都是 SQL Server 2008R2 数据库，链接服务器连接是通过常规“SQL Server”链接使用当前登录的安全上下文建立的。链接的服务器都在同一个数据中心，所以连接应该不是问题。

我使用以下查询来检查列的哪些值identifier可远程使用，但不能在本地使用。

SELECT 
    identifier 
FROM LinkedServer.RemoteDb.schema.[TableName]

EXCEPT

SELECT DISTINCT
    identifier 
FROM LocalDb.schema.[TableName] 

在两个表上的列上都有非聚集索引identifier。本地大约有 260 万行，远程只有 54 行。然而，在查看查询计划时，70% 的执行时间用于“执行远程查询”。此外，在研究完整的查询计划时，估计的本地行数是1而不是2695380（这是仅选择后面的查询时的估计行数EXCEPT）。 执行此查询时，确实需要很长时间。

不禁让人疑惑：这是为什么呢？估计是“刚刚”结束，还是链接服务器上的远程查询真的那么昂贵？

我想在我的数据库中通过脚本创建新函数。脚本代码如下：

IF Exists(Select * From sys.sysobjects A Where A.name =N'fn_myfunc' and xtype=N'FN') return;

CREATE FUNCTION fn_myfunc ()
returns varchar(10)
AS Begin
...
End

但是当我执行上面的脚本时，SQL Server 返回一个错误：

'CREATE FUNCTION' must be the first statement in a query batch.

我们的 SQL 服务器位于 SAN 上。它包含数十个 OLTP 数据库，其中一些数据库包含多个包含超过 100 万条记录的表。

我们每周都在运行Ola Hallengren 的索引维护脚本，每次运行几个小时。根据碎片阈值，脚本将重新组织或重新索引索引。我们观察到在重新索引期间，日志文件变得很大，这导致日志传送期间带宽消耗过多。

然后是Brent Ozar 的一篇文章，他说不要担心 SQL 索引：

您的硬盘驱动器与同时发出驱动器请求的其他服务器共享，因此驱动器总是会到处跳跃以获取数据。对索引进行碎片整理只是毫无意义的繁忙工作。

谷歌搜索这个问题会导致不同的意见，大多数支持似乎太简短或太弱的论点。我们的暂定计划是在我们的维护脚本中调整碎片阈值，以便它比重新索引更频繁地重新组织。

最终判决是什么？考虑到与运行每周维护作业相关的负担，是否值得对 SAN 上的 SQL 索引进行碎片整理？