标签: sql-server-2012

• 我尝试向 SQL Server（2012 标准）故障转移添加一个新节点，该节点已安装在 Windows2012 故障转移群集的另一个节点上
• 我在输入 SQL Server 代理帐户名称时遇到不可编辑字段的问题
• 可能有与 SQL Server 数据库引擎 (ei) 相同的 AD 名称
• 我的帐户访问权限没有 AD 管理员权限
• 父节点上 SQL Server Agent 的访问、帐户和设置是可访问和可设置的

公平警告，我知道这不是最好的方法，但我正在尝试扩展一些现有代码而无需重写。

无论如何，我已经安装了两个 SQL Server 2012，一个在我的办公室本地，另一个在远程站点。远程站点的服务器为我的本地系统设置了链接服务器。

远程站点的应用程序将记录插入链接服务器上具有INSTEAD OF触发器的表中。该触发器的末尾有一个 select 语句，它返回一个整数值。如果我在 SSMS 的本地框上插入，我会得到整数作为输出。如果我在远程盒子上插入，我得到的只是1 row(s) affected.

无论如何我可以将触发器的输出传递回链接服务器还是我需要重写为存储过程？

以下文本基于评论中要求的澄清

所有连接都是在远程端的单个用户的安全上下文中进行的。如果我EXECUTE AS USER在本地服务器上使用插入而不是通过链接进行插入，则输出会按预期显示，因此这不是帐户的权限问题。

服务器选项是：

Collation Compatible=False  
Data Access=True  
RPC=True  
RPC Out=True  
Use Remote Collation=True  
Collation Name=(blank)  
Connection Timeout=0  
Query Timeout=0  
Distributor=False  
Publisher=False  
Subscriber=False  
Lazy Schema Validation=False  
Enable Promotion of Distributed Transaction=True

我将数据库从 SQL Server 2005 移到 SQL Server 2012。有什么办法可以恢复新服务器上的所有登录信息？

我一直在尝试让以前工作的复制开始工作。

我尝试了很多设置，但我似乎无法让它工作。

这是场景。我从目标数据库中删除了所有 FK 约束（称之为 DestDB）。

然后我重新初始化我的复制，当我运行时，我收到这个（去标识化）错误：

ALTER TABLE 语句与 FOREIGN KEY 约束“FK_TableOnlyInDestDB_MyReplicatedTable”冲突。冲突发生在数据库“DestDB”、表“SomeSchema.MyReplicatedTable”、“MyReplicatedTableId”列中。（来源：MSSQLServer，错误号：547）

它让我发疯，因为该数据库中不存在指示的 FK。

现在，我确实从另一个数据库复制了这个数据库（备份和恢复）。所以我唯一能想到的是它以某种方式穿越了溪流。

但这似乎不太可能。

任何想法都会很棒！

注意：这是我运行的查询，以确保我没有 FK（它没有返回任何行）：

use DestDB

SELECT f.name AS ForeignKey,
   OBJECT_NAME(f.parent_object_id) AS TableName,
   COL_NAME(fc.parent_object_id, fc.parent_column_id) AS ColumnName,
   OBJECT_NAME (f.referenced_object_id) AS ReferenceTableName,
   COL_NAME(fc.referenced_object_id, fc.referenced_column_id) AS ReferenceColumnName
FROM sys.foreign_keys AS f
INNER JOIN sys.foreign_key_columns AS fc ON f.OBJECT_ID = fc.constraint_object_id

我还检查以确保有问题的 FK 不在源表上（在我从中复制的数据库中）。

我也试过： EXEC sp_msforeachtable 'ALTER TABLE ? NOCHECK CONSTRAINT all'

也试过 Dropping MyReplicatedTable。删除就好了，复制重新创建了它。（但仍然给了我错误。）

我尝试创建一个空数据库作为订阅者。效果很好，所以是 DestDB 中的某些东西导致了问题，但 ERROR 中的 FK 不存在。

我需要一些帮助和一些绷带来射击自己的脚。这是一个 DEV 环境，但我需要提出来。

我在 Windows 2008 R2 上使用 SQL Server 2012 Enterprise。不知何故，我们的 AG 听众群消失了。我尝试重新创建 AG 侦听器，但它给出了有关计算机帐户没有权限的错误。我内心的天才决定从 Windows Cluster Admin 中删除 AG 组，现在我无法重新创建 AG 组（我应该通过 SQL Server 而不是 Windows 来完成）。

我不断收到以下错误：

创建可用性组导致错误。(Microsoft.SqlServer.Management.HadrTasks)

附加信息：

为可用性组“SQLAG_D”创建失败。(Microsoft.SqlServer.Smo)

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

可用性组“SQLAG_D”已存在。此错误可能是由先前失败的 CREATE AVAILABILITY GROUP 或 DROP AVAILABILITY GROUP 操作引起的。如果您指定的可用性组名称正确，请尝试删除该可用性组，然后重试 CREATE AVAILABILITY GROUP 操作。

未能创建可用性组“SQLAG_D”。操作遇到 SQL Server 错误 41042 并已回滚。查看 SQL Server 错误日志以获取更多详细信息。解决错误原因后，重试 CREATE AVAILABILITY GROUP 命令。（Microsoft SQL Server，错误：41042）

有没有人有什么建议？

AG 组已在 Windows 群集中删除，并且未显示在 SQL 可用性组中。该sys.availability_groups系统目录视图具有“已删除” AG在里面。其中没有提及 SQLAG_D。

我是 SQL Server 的新手，如果有人能指出我正确的方向会很有帮助。

我们有一个名为main-db.bak.

这是我们克隆的数据库文件，因为它包含我们在为客户构建新网站的过程中需要的所有主要内容。是否可以执行以下操作：

1. 在同一个 SQL Server 实例上拥有数据库的副本
2. 创建一个新的空数据库
3. 从main-db.bak文件中恢复数据库而不覆盖可能使用相同数据 MDF 和 LDF 文件的其他任何内容？

或者从实时运行的数据库副本中复制此数据库是否更容易，以便在从备份中恢复时不需要？

恢复数据库时是否必须重命名 LDF 和 MDF 文件，我可以编写脚本来自动执行大部分工作吗？

我们有用户查询我们的产品数据库（主要是通过 MS-Access 的 ODBC）来创建一些海关报告。我们想将我们的数据复制到第二台服务器（复制/日志传送/???），因此生产数据库上的负载较少。Prod DB 中的许多表没有主键并且是 SQL Server 2005。我们的目标 DB 是 SQL Server 2012 Standard（尽管我们可以在必要时降级目标服务器）。

我们怎么能做到这一点？我们尝试过复制，但由于缺少主键而失败。我们也尝试过日志传送，但由于 SQL 版本不同，第二个 DB 无法上线。

谢谢，吉姆

我想恢复我的数据库，我使用 sql server 2012 express edition 但是当我在 sql server management studio 中恢复我的备份文件时，我出现了这个错误：

System.Data.SqlClient.SqlError: 磁盘卷“c:\”上的可用空间不足，无法创建数据库。数据库需要 84260749312 个额外的空闲字节，而只有 47428677632 个字节可用。(Microsoft.SqlServer.SmoExtended)

我的 .bak 文件是 8.27 GB，我的 C 盘有 44.1 GB 可用空间。为什么我会出现这个错误？我该如何解决这个错误？提前致谢。

我有两个带有 MSSQL2012 的节点，它们与 AlwaysOn 高可用性一起工作

在一些崩溃之后，我不得不从节点之一上的可用性组中删除 db。为了恢复，我已经在第二个节点上备份了数据库（完整+日志），并根据标准程序在崩溃的节点上恢复了它。看起来完全没问题，但我遇到过，当我将主要角色赋予恢复的节点时，应用程序服务（使用 Service Broker）不做任何事情。

sys.databases 说对于我的数据库 is_broker_enabled=1，但我发现了几篇关于必须显式启用还原数据库上的代理的文章。

由于 AlwaysOn，SET ENABLE_BROKER 失败。

Internet 说激活服务代理的唯一方法是使用 ENABLE_BROKER 选项再次恢复数据库。但是为了将 db 添加到 AlwaysOn，我必须使用 NORECOVERY 恢复它。

试图运行

RESTORE DATABASE [dbname]
FROM  DISK = N'D:\111.bak'
WITH  NORECOVERY, ENABLE_BROKER

我已经看到有关这两个 WITH 选项之间冲突的通知

有人知道进行这种恢复的正确方法吗？db 超过 150GB，检查每个版本总是需要两个多小时:)

提前致谢

这个问题一直困扰着我一段时间，但我实际上修复了导致问题的查询（在我最终找到它们之后）但我很好奇它是否是一个 SQL 进程，这是我们的raidcontrollers是狗屎的潜在问题还是什么问题真的是。所以这就是一直困扰我们的场景。

@ 11:10~ 和 01:10~ 服务器会给出这些 IO 错误，即使通过远程桌面服务器也会失败，管理工作室会超时，一切都将指向集群即将失败。

（服务器是相同的，我们运行 Windows Server 2012 标准，群集在运行 SQL Server 2012 企业版的 AlwaysOn 中）。

大约 5-15 分钟后，服务器将恢复运行（除了事件 ID 833 是“众所周知的”：SQL Server 已遇到 16870 次 I/O 请求花费的时间更长，事件日志中没有任何内容15 秒内完成数据库 [XXXXX] 中的文件 [E:\XXXXXXXX.mdf] (10). OS 文件句柄为 0x0000000000001284。最新的 long I/O 的偏移量为：0x0000041fb3c000。

现在我正在运行分析器以找出正在运行的查询，并尽我所能找出导致服务器冻结并拒绝正常服务的原因。事件日志针对特定的数据库，我朝那个方向搜索，昨天我发现了一张对我来说看起来很奇怪的表。

特定的表有 11 演出大，有价值 23 演出的索引（还没有研究这些，但对我来说这似乎是错误的）并且有 8000 万条记录。考虑到该表应该容纳大约 200 万个并且增长相对缓慢，这激发了我的兴趣，我发现了三个填充该表的存储过程。

所有三个存储过程都有缺陷，这使得它们每次运行时插入的记录不是几百条而是超过 500.000。（这些现在已修复，因此问题不会出现，但我觉得这里存在潜在问题）。

这些存储过程将在 09:00 和 23:00 运行（恰好在问题发生前 2 小时）。程序本身大约需要 5 分钟才能完成。

现在我想知道为什么在有问题的实际存储过程已经完成后，服务器需要两个小时才能开始死在我身上。那时我没有运行任何索引维护，或者其他任何事情（这是我检查的第一件事）。据我所知，在特定时间没有运行@。可能是 SQL Server 做了一些“自我维护”，并注意到一些索引需要进行碎片整理或其他什么，即使我没有要求任何这样的事情？

是不是我们的raidcontrollers（或者甚至是连接到它们的SSD）有缺陷并且在很多活动决定在2小时后显示降级迹象？

我根本无法解释这种行为，我担心我们的生产服务器可能不可靠（这会很糟糕，因为它们大约有 4 个月大）。现在我昨晚已经解决了这个问题，24 小时以来我们都没有遇到过这个问题（除非它稳定了多天，否则我不会称它为“已解决”）但我仍然很好奇我的到底是什么服务器正在做。