标签: sql-server-2005

我目前正在运行一个脚本，该脚本对 SQL Server 2005 数据库中的每个表执行 DBCC INDEXDEFRAG，一次一个表。由于空间限制和正常运行时间要求，不能使用 DBCC DBREINDEX 代替 INDEXDEFRAG。

我注意到对某些表进行碎片整理需要很长时间。例如，如果我检查“sys.dm_exec_requests”动态管理视图，我可以看到以下 INDEXDEFRAG 当前正在处理 table_id 为 829610394 的表的聚集索引：

DBCC INDEXDEFRAG (0, 829610394, 1)

我知道在碎片整理过程完成之前需要很长时间。撇开当前运行的脚本最终会对所有表进行碎片整理的事实不谈，在当前命令执行时，我在另一个表的聚集索引上手动运行另一个 DBCC INDEXDEFRAG 有什么危害吗？如果我这样做，实际上会同时对两个表进行碎片整理吗？

抱歉，标题令人困惑，我不知道在那里写什么。

我有一张包含几百条记录的表格。我需要将这个表的每条记录分配给一个更小的动态用户表，并且用户应该交替分配他们被分配的记录。

例如，如果表A是

Row_Number() 标识
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10

表B是

Row_Number() 标识
1 1
2 2
3 3

我需要一个最终结果集

用户 ID 记录 ID
1 1
2 2
3 3
1 4
2 5
3 6
1 7
2 8
3 9
1 10

我已经设法使用 mod 运算符做了一些有点混乱的事情，但是我很好奇是否可以在没有临时表和变量的情况下运行相同的查询。

使用临时表是因为 TableA 实际上是一个用户定义的函数，它将逗号分隔的字符串转换为表，我需要来自 UDF 的对象的计数。

-- Converts a comma-delimited string into a table
SELECT Num as [UserId], Row_Number() …

我想我可以使用 sp_MSforeachdb 来解决这个问题，但我收到一条错误消息。

sp_MSforeachdb '
BEGIN
USE [?]
DECLARE @dbid INT
SET @dbid = DB_ID()
IF(@dbid > 4)
BEGIN
    --PRINT ''[?]'' + CONVERT(VARCHAR, @dbid)
    --ALTER DATABASE [?] SET AUTO_SHRINK OFF
END
END;
'

如果我在未注释 PRINT 行的情况下运行上述查询，我​​将获得除系统数据库之外的所有数据库的列表。但是，当我取消注释 ALTER DATABASE 行时，我收到以下两条错误消息：

消息 5058，级别 16，状态 2，第 9 行
无法在数据库“master”中设置选项“AUTO_SHRINK”。
消息 5058，级别 16，状态 1，第 9 行
无法在数据库“tempdb”中设置选项“AUTO_SHRINK”。

这似乎在某些时候中断了操作，因此只有一些数据库被禁用自动收缩。

知道如何在所有数据库上禁用自动收缩吗？额外问题：为什么我的方法不起作用？

我刚刚收到有关 SQL Server 2005 实例的以下通知。该实例的核心与 tempdb 文件的比率为 2:1，tempdb 文件总数为 24 个文件。不应该发生争用 - 我将如何检测这种争用的来源？TempDB 和所有其他数据库都通过 10 GB 以太网存储在 SAN 存储上。SAN 在一个 RAID-60 阵列中配置了 46 个 10k SAS 驱动器。该阵列与多个 VMWare 服务器和一个或两个 Exchange 服务器共享。

来自 Idera SQL 诊断管理器的通知：

2012 年 11 月 8 日下午 10:49:00，MGSQL01 上的 Tempdb 争用 (ms) 至关重要。

在 MGSQL01 上检测到 Tempdb 闩锁争用。检测到的总等待时间为 1782 毫秒。这表明性能受到 tempdb 中分配映射争用的影响。如果这是一个常规问题，可以通过遵循有关 tempdb 文件计数、大小和 IO 子系统的最佳实践来缓解。

PFS 等待时间：1782 ms GAM 等待时间：0 ms SGAM 等待时间：0 ms

Tempdb 争用 (ms)：tempdb 分配映射（GAM、SGAM 和 PFS）的当前等待时间，以毫秒为单位。此警报只能在运行 SQL 2005 或更高版本的实例上引发。

我们在一个 SQL Server 2005 实例上有两个数据库，它们之间有事务复制（3 个表作为文章）。该服务器同时充当发布者和分发者。

然后服务器上的 RAID 失败。然而，我们设法.mdf在崩溃之前分离并复制了几乎所有文件。

系统恢复后，我们重新安装了SQL Server，恢复了系统数据库（master、model、msdb）并将.mdf文件放在相同的路径下。于是开始了。

问题出现在复制中。在本地发布文件夹是空的，虽然本地订阅文件夹包含有问题的订阅。当我尝试添加新出版物时，我得到了：

新发布向导在检索发布名称时遇到一个或多个错误。

执行 Transact-SQL 语句或批处理时发生异常。(Microsoft.SqlServer.ConnectionInfo)

无效的对象名称“dbo.syspublications”。（Microsoft SQL Server，错误：208）

我决定尝试删除左订阅（最终我设法）并禁用服务器上的发布和分发，这给了我：

SQL Server 无法禁用“someserver”上的发布和分发。

无效的对象名称“dbo.syssubscriptions”。EXECUTE 之后的事务计数表示缺少 COMMIT 或 ROLLBACK TRANSACTION 语句。先前计数 = 0，当前计数 = 1。 EXECUTE 之后的事务计数表示缺少 COMMIT 或 ROLLBACK TRANSACTION 语句。先前计数 = 0，当前计数 = 1。 EXECUTE 之后的事务计数表示缺少 COMMIT 或 ROLLBACK TRANSACTION 语句。先前计数 = 0，当前计数 = 1。 EXECUTE 之后的事务计数表示缺少 COMMIT 或 ROLLBACK TRANSACTION 语句。先前计数 = 0，当前计数 = 1。 EXECUTE 之后的事务计数表示缺少 COMMIT 或 ROLLBACK …

我正在尝试获取当前活动的全局临时表的列表。它们相互碰撞（同名）似乎存在问题。作为“代理”dba，试图解决这里的混乱。

我们有一个基表，用于定义部件并保存部件号、描述、价格、重量等信息。我们还有大约 400 个表引用基表，并根据部件的类型/类别提供有关部件的附加信息。

我们首先使用外键约束，这样如果某个部分在 400 个特定于部分的表中的一个中被引用，则无法从基表中删除该部分，但我们很快达到了 SQL Server 2005 的最大 253 个推荐外键。

在这种情况下，是否有任何外键替代方案可以确保数据完整性？我们在访问数据时没有看到性能问题，但由于查询计划太复杂，更新基表中的现有部分将失败。

我们在周末设置了数据库镜像，但忘记重新启用备份事务日志的作业。当我今天早上进来时，事务日志已经膨胀到 58GB，并且占用了大部分驱动器空间。

我将事务日志手动备份到磁盘以使数据库再次运行，但是运行 DBCC SHRINKFILE 似乎并没有减少事务日志文件的物理大小。

DBCC SHRINKFILE (N'MyDatabaseName_Log', 1000)

如果我使用

DBCC SQLPERF(LOGSPACE)

我可以看到只有 22% 的当前日志正在被使用

数据库名称 日志大小(MB) 已用日志空间 (%) 状态
我的数据库名称 55440.87 22.38189 0

如果我log_reuse_wait_desc在 sys.databses 中签出，我看到的唯一记录是DATABASE_MIRRORING，所以我猜测镜像在为什么日志文件的物理大小不会缩小方面发挥作用？

SELECT log_reuse_wait_desc
FROM sys.databases
WHERE name = N'MyDatabaseName';

我还注意到我的主要数据库镜像状态是暂停，并且尝试恢复它立即失败并出现以下错误：

数据库“MyDatabaseName”的远程镜像伙伴遇到错误 5149，状态 1，严重性 25。数据库镜像已暂停。解决远程服务器上的错误并恢复镜像，或删除镜像并重新建立镜像服务器实例。

镜像服务器上的错误日志也包含此错误，但也包含有关日志文件驱动器已满的错误

MODIFY FILE 在尝试扩展物理文件时遇到操作系统错误 112（磁盘空间不足。）。

和

F:\Databaselogs\MyDatabaseName_1.ldf: 遇到操作系统错误 112（磁盘空间不足。）。

主体服务器在日志文件驱动器上有 60GB（这里还有其他数据库托管），而镜像服务器只有 45GB。

备份日志文件使数据库再次可用，但是我还想减小磁盘上物理日志文件的大小，并恢复镜像。

如何在不影响镜像或备份链的情况下缩小物理事务日志文件的大小？

我正在运行 SQL Server 2005

我们有相当多的 SQL Server 需要从 2005 版升级到 2008 R2。工作计划在今年年中之前完成，因为 Microsoft 将结束对它的支持。

2005 SQL Server 都是 SP3 和 SP4，运行在 Windows Server 2003（其支持已经结束，但我们有延长一年的例外），但在需要时我们也可能会升级服务器操作系统。

这些服务器包括复制（事务）、日志传送、报告服务和运行 SSIS 包的集成服务器。

我的问题不是如何，而是我想知道所涉及的风险或在计划此升级之前可以进行的任何预检查？

此外，对于此迁移/升级，就地升级是否是比并行升级更好的计划？

我正在使用 sql server 2005，我遇到了可以在参数中传递许多值的情况。

基于此：为一个 SQL 参数传递多个值此过程使用 XML 作为参数。

这是存储过程的代码：

CREATE PROCEDURE [DENORMV2].[udpProductBulletPointSelectByTier1NoteTypeCode] (  
    @Tier1 VARCHAR(10),  
    @LanguageID INT,  
    @SeasonItemID VARCHAR(5) = NULL,
    @ListNoteTypeCode XML,  
    @CacheDuration INT OUTPUT )  
    WITH EXECUTE AS 'webUserWithRW'  
AS

        SELECT  pbp.Tier1, pbp.LanguageId, pbp.NoteText, pbp.NoteTypeCode,  
                pbp.NoteGroup, pbp.SortOrder  
        FROM    dbo.ProductBulletPoint pbp  

        WHERE   Tier1 = @Tier1 
          AND   LanguageId = @LanguageID 
          AND   (      SeasonItemId = @SeasonItemID  
                  OR
                       @SeasonItemID is null
                )

          AND pbp.NoteTypeCode IN (

                 SELECT  NoteTypeCode=BulletPoint.NoteTypeCode.value('./text()[1]', 'varchar(50)')
                   FROM  @ListNoteTypeCode.nodes('/BulletPoint/NoteTypeCode') AS BulletPoint ( NoteTypeCode )

          )

SELECT  @CacheDuration …