标签: sql-server

我需要恢复我的 SQL Server 2008 用户/密码。

情况是：我不知道SA密码并且经过 Windows 身份验证的用户不再是活动用户（禁用用户，因为用户已离职）所以我无法使用 Windows 身份验证登录。

有没有办法重置sa密码、Windows 身份验证和登录数据库？

最后一个选项可能是卸载并重新安装。在这种情况下，数据将丢失。

谢谢，

SQL Server的数据库镜像功能即将消失：

此功能将在 Microsoft SQL Server 的未来版本中删除。避免在新的开发工作中使用此功能，并计划修改当前使用此功能的应用程序。请改用AlwaysOn 可用性组。

有谁知道什么时候？高可用性（和快速恢复）数据库有哪些选择？

我一直在研究使用索引视图来提高一些最常用的视图的性能。

然而，索引视图不支持非唯一聚集索引，这与数据库结构的其余部分设置的优先级略有不同。

例如，这是我们几个表的简化版本。

-Groups-
Group ID    GroupName

-Users-
UserKey    UserName    FullName     GroupID

索引位于 Groups.GroupID（非集群）和 Users.GroupID（集群）上。聚集键位于用户表中的 GroupID 上，因为最常见的是将检索来自特定组的用户范围。显然每个组会有多个用户，所以这个聚集索引是非唯一的。

这让我有点不确定在索引我的视图（例如这个例子）时如何遵循这个优先级，因为我不能有一个非唯一的聚集索引。

ConsumableID    ConsumableVariantID AllowThresholdOverwrite FullPath    GroupID ManufacturerID  Type    ModelID
101              29                 1                       0.1.2.4.    4       3               3       2

实际上，此视图上唯一始终唯一的值是 ConsumableID 列，因此在放置索引的位置方面我几乎没有选择。

当常规表允许时，为什么视图不允许非唯一聚集索引？

我正在查看我继承的应用程序的 SQL Server 数据库。我已经有大约 10 年没有研究过 SQL Server，所以请耐心等待。

我正在查看的数据库表有一个bigint NOT NULL名为的列id，但是，当我检查约束时，我没有看到任何约束，所有数据库表也是如此。

我是否正确假设这些表上没有主键和索引（集群或非集群）？

我运行了以下查询，结果似乎证实了我的怀疑：

//**returns 0**
select count(*) from INFORMATION_SCHEMA.TABLE_CONSTRAINTS;

//**returns no rows**
select * from sys.indexes
where object_id = (select object_id from sys.objects where name = 'NAME-OF-TABLE');

//**returns all tables in database**
SELECT name
FROM sys.tables 
WHERE OBJECTPROPERTY(object_id,'IsIndexed') = 0;

我已经尝试Tasks>Generate Scripts...并在高级脚本选项中设置了“脚本登录”，但我在输出中得到了这个：

/* For security reasons the login is created disabled and with a random password. */

是否有一种简单的方法可以使用密码对这些登录进行脚本编写，或者使用其他方法将登录从 2008R2 实例转移到 2014 实例？

我注意到 2 台服务器 HA 集群上的奇怪行为，我希望有人能证实我的怀疑，或者提供一些其他解释......这是我的设置：

• 2 台服务器 SQL 2012 SP1 安装
• 已为一些数据库启用 SQL AlwaysOn HA
• CPU 为 2.4GHz，4 核
• RAM 为 34 GB（它是一个 AWS 实例，因此是奇数）
• 资源利用率比较低——每台服务器有14+GB的空闲内存，SQL没有限制使用多少内存
• 磁盘访问时间很好 - 很少超过 15 毫秒/读或写
• 数据库不大 - 1 GB、1.5 GB、7.5 GB
• SQL 服务器进程使用 16 GB 专用字节，15 GB 工作集

总体而言，没有注意到资源问题。现在是奇怪的部分。SQL 没有重新启动（进程已经运行了将近 6 个月），但似乎每大约 50 天，页面预期寿命计数器就会下降到（几乎）0。直到那时它稳步攀升，没有下降。这是一个性能图：

当我查看计数器数据时（我没有确切的数字，只是每小时汇总），似乎 PLE 计数器值每次都达到了大约 4,295,000 秒（大约 50 天）（至少每次我有数据时）。

我疯狂的理论是，PLE 数以毫秒为单位作为无符号长整型（其限制为 4,294,967,295）并在 49.71 天时重置，无论是设计还是错误。这将解释两台服务器的行为以及它们具有的相同模式。或者它可能是完全不同的东西，我只是没有任何意义。:)

有没有人见过这样的事情，或者可以解释这种行为？

PS我看到了这篇文章，但我的情况似乎略有不同。

PPS 这是一个转贴 - 我最初把它贴在这里，但被告知这里的观众更合适。

谢谢！

目前我们对环境中的 SQL Server 2005/2008/2008R2/2012 服务器上的备份使用标准维护计划，并且始终选中“验证备份完整性”框。

有些备份运行时间很长，因此我建议关闭该选项，但管理层需要我记录此更改的影响和风险。

我了解此选项的使用和历史，对我来说似乎没有必要将备份作业的时间加倍（在我看来），任何可能发生的错误都可能发生在备份步骤期间，而不是在验证期间。

我错了吗？如果我备份到磁盘而不是流式传输磁带或其他东西，关闭它的风险是否最小？（如果相关，我们通过网络备份到 EMC DD-800 备份设备。）

是否有任何关于何时可以安全关闭此功能的官方 MS 建议？

您是否对环境中的每个备份运行“验证”？你抽查他们吗？

编辑：澄清一下，当您在维护计划中检查“验证备份完整性”时，SQL 将在每次备份后立即对每个数据库执行完整的RESTORE VERIFYONLY。这与原始备份一样是数据/IO 密集型，并且（基本上）使备份作业的总时间加倍。这是不一样的使备份的“校验”选项（不能在向导中进行，因为据我所知）。

我在 SQL Server 2008R2 中有一个非常大的生产数据库和一个非常大的测试环境数据库。两个数据库具有相似的表结构，但不同的用户/登录名/权限/角色。

我只需要定期从生产中刷新测试数据库中的几个表，大约每月一次。

我目前计划这样做的方式是

1. 使用 BCP 实用程序从生产中导出我需要的表。
2. 将 bcp 导出文件复制到测试服务器上
3. 禁用我在测试中刷新的所有表的索引和约束
4. 截断测试数据库表
5. 使用 BCP 将数据加载回测试数据库表。
6. 在测试中重建索引并重新启用约束

对于这么小的任务来说，这一切似乎有点太复杂了。它似乎也会产生很多重做（在 t-log 中）有没有更好的方法来做到这一点？

我想到的另一种方法是将备份从生产恢复到测试环境 - 但我遇到的问题是完整备份会非常大，我不需要刷新所有表，只需要刷新几个 - - 而且生产数据库中的用户和安全性与测试不同。如果我恢复整个数据库，这将被生产数据库中的安全设置覆盖。

在 SQL Server 中，我可以在协议设置中“强制加密”。如果我将该设置保留为“否”，则任何客户端仍可能需要加密。

我能以某种方式查看到数据库的哪些连接正在使用加密吗？

我是一名“偶然”的 DBA，相对缺乏经验并且对这个问题感到困惑。

运行 MS SQL Server 2012。问题在于这个 UPDATE 语句：

UPDATE dbo.tAccts SET
       Ticket               = 'ARP.ExGE'
       , Method             = 'smtp'
       , AcctOwner          = 'r00417819'
       , DisplayName = '~AppLight HBSFax-Inactive'
       , Destination = 'r00417819@mail.ad.ge.com'
       , UpdatedBy          = SYSTEM_USER
       , UpdatedOn          = CAST(GetDate() AS DATE)
FROM dbo.vReclaimable
WHERE OHR_EmpStatus <> 'A'

这应该只更新tAccts 表中由 vReclaimable 视图返回的行。

vReclaimable 视图基于 tAccts 表并返回 tAccts 中行的子集。

当我运行它时，它失败并显示唯一键错误：

(0 row(s) affected)
Msg 2627, Level 14, State 1, Line 67
Violation of UNIQUE KEY constraint 'UQ__tAccounts_DNIS.Method.Destination.Phones'. Cannot …