标签: sql-server

Adam Machanic 的 sp_WhoIsActive 在运行时是否返回实际查询计划或估计计划@get_plans=1？

我试图从存储和性能角度了解决定 varchar 列应该有多大的最佳方法。

性能
从我的研究来看，似乎varchar(max) 只应在您确实需要时使用；也就是说，如果该列必须容纳超过 8000 个字符，一个原因是缺乏索引（尽管我对一般的 varchar 字段的索引有点怀疑。不过，我对 DB 原则还很陌生，所以也许这是没有根据的) 和压缩（更多的是存储问题）。事实上，一般来说，人们似乎只推荐使用你需要的东西，当做 varchar(n)....oversizing 是不好的，因为查询必须考虑到最大可能的大小。但也有人表示，引擎将使用指示大小的一半作为数据平均实际大小的估计值。这意味着人们应该根据数据确定平均大小是多少，将其翻倍，并将其用作 n。对于具有非常低但非零可变性的数据，这意味着比最大尺寸大 2 倍，这看起来很多，但也许不是？见解将不胜感激。

存储
在阅读了行内与行外存储的工作原理后，并记住实际存储仅限于实际数据，在我看来，n 的选择实际上对存储几乎没有影响（除了确保它足够大以容纳所有东西）。即使使用 varchar(max) 也不会对存储产生任何影响。相反，如果可能，目标可能是将每个数据行的实际大小限制为 ~8000 字节。这是对事物的准确阅读吗？

上下文
我们的一些客户数据会稍微波动，因此我们通常将这些列的列设置得比它们需要的宽度稍宽一些，比如大 15-20%。我想知道是否还有其他特殊考虑；例如，和我一起工作的人告诉我使用 2^n - 1 个尺寸（不过我没有发现任何证据......）

我说的是初始表的创建。客户会告诉我们他们将开始向我们发送一个新表，并发送示例数据（或只是第一个生产数据集），我们会查看这些数据并在我们的一端制作一个表来保存数据。我们希望在我们的一端制作表格以处理未来的导入以及样本中的内容。但是，某些行肯定会变长，所以我们填充它们。

问题是多少，是否有技术指南？

我如何在生产框中检查我的 SQL 服务器的内存使用情况。我正在使用 SQL Server 2016。当我检查任务管理器时，它显示在 90% 以上。我不认为这是 sql server 的真实内存使用情况。

我有一个 SQL 性能工具 grafana，它显示的 CPU 使用率比我在任务管理器中看到的少得多。我检查了资源监视器，可以看到平均 CPU 值。我对 SQL 服务器内存使用情况感到困惑。我正在尝试确定内存压力是否是我的某些问题的一个问题。

有人可以直接给出一个好的/正确的解释。

我有一个 SQL Server 数据库，其中的查询速度很慢，而且有很多锁定和阻塞。

当我查看缺失的索引 DMV 和查询计划时，没有任何建议。

这是为什么？

我有一个存储过程：

• 检查表是否存在，如果存在，则删除它。
• 再次创建该表
• 然后用大约 30 个查询填充该表。

当我（数据库所有者）运行这个过程时，一切都按预期工作。当我的同事通过 Active Directory 中的角色对该数据库具有 DROP/CREATE 权限时，会出现一些问题。令我困惑的是：

表的创建没有dbo在名称前显式指定架构。这导致domain\cowork_id.table_name_here创建一个名为table 的表。除了在他的个人模式中创建的表之外，他现在还在数据库中拥有该模式（在运行 proc 之前它不存在）。

发生了什么？为什么 SQL Server 在用户架构中创建表而不是在dbo未指定时创建表？

我们发现 SQL "sa" 帐户的使用方式不该使用，因此我们正在更改所有 SQL 实例的 sa 密码。

（我们有 SQL 2005 到 2017 服务器以混合身份验证模式运行。所有用户和应用程序都应该使用域帐户或非 sa SQL 帐户进行连接。我一直在监视，但没有发现任何其他应用程序、用户或非- 使用 sa 帐户的内部 spid。）

几个问题：

Q1：更改 sa 密码是否需要重新启动 SQL？

我发现一些参考资料说更改 sa 帐户密码后需要重新启动 SQL 服务：

• DBA SE：更改 sa 密码
• SQLAuthority：使用 Management Studio 更改 SA 登录密码

真的吗？还是仅当我更改身份验证模式时？还是仅当我经常以 sa 身份登录时？

这个 SQL Server Central 线程甚至建议更改它可能会影响现有的 SQL 代理作业和其他东西；这是一个问题吗？或者仅当有人将 SA 帐户硬编码到 SSIS 包中时？

（以防万一，我们为 SQL 服务和 SQL 代理服务使用域帐户，为调用 SSIS 包或 PowerShell 脚本的作业使用域代理帐户。）

问题 2：我可以以“正常”方式更改 sa 密码吗？

我可以像重置任何其他帐户一样重置它吗？使用 SSMS，或更可能通过：

ALTER LOGIN sa WITH PASSWORD = 'newpass'; …

我有一个应用程序，它在 SQL Server 2008 数据库（非集群）中创建了数百万个表。我想升级到 SQL Server 2014（集群），但在负载下时遇到错误消息：

“数据库中已经有一个名为'PK__tablenameprefix__179E2ED8F259C33B'的对象”

这是系统生成的约束名称。它看起来像一个随机生成的 64 位数字。由于大量表，我是否可能看到冲突？假设我有 1 亿张表，我计算出在添加下一张表时发生碰撞的可能性不到 1 万亿分之一，但这是假设均匀分布的。SQL Server 是否有可能在 2008 和 2014 版本之间更改其名称生成算法以增加冲突的几率？

另一个显着差异是我 2014 年的实例是一个集群对，但我正在努力形成一个假设，为什么会产生上述错误。

PS 是的，我知道创建数百万个表是疯狂的。这是我无法控制的黑盒 3rd 方代码。尽管疯狂，但它在 2008 版中有效，现在在 2014 版中无效。

编辑：仔细检查，生成的后缀似乎总是以 179E2ED8 开头 - 这意味着随机部分实际上只是一个 32 位数字，每次添加新表时，冲突的几率仅为 50 分之一，这与我看到的错误率更接近！

在过去的几天里，我们已经 3 次遇到这个奇怪的错误，在 8 周没有错误之后，我被难住了。

这是错误消息：

Executing the query "EXEC dbo.MergeTransactions" failed with the following error:
"Cannot insert duplicate key row in object 'sales.Transactions' with unique index
'NCI_Transactions_ClientID_TransactionDate'.
The duplicate key value is (1001, 2018-12-14 19:16:29.00, 304050920).".

Run Code Online (Sandbox Code Playgroud)

我们拥有的索引不是唯一的。如果您注意到，错误消息中的重复键值甚至与索引不一致。奇怪的是，如果我重新运行 proc，它会成功。

这是我能找到的最新链接，但我没有看到解决方案。

https://www.sqlservercentral.com/forums/topic/error-cannot-insert-duplicate-key-row-in-a-non-unique-index

关于我的场景的一些事情：

• proc 正在更新 TransactionID（主键的一部分）-我认为这是导致错误的原因，但不知道为什么？我们将删除该逻辑。
• 在表上启用更改跟踪
• 做事务读未提交

每个表有45个字段，我主要列出了索引中用到的字段。我正在更新更新语句中的 TransactionID（集群键）（不必要）。奇怪的是，直到上周我们几个月都没有遇到任何问题。它只是通过 SSIS 偶尔发生。

桌子

USE [DB]
GO

/****** Object:  Table [sales].[Transactions]    Script Date: 5/29/2019 1:37:49 PM ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

IF NOT EXISTS (SELECT * …

我在 MS SQL Server 中有一个表。

• 表大小：806 GB
• 行数：12亿
• 索引空间：1.2 GB

表使用方法：记录从Web Service调用99.9％的使用率从伐木，开发商很少看这个表在正式版（仅当报告或研究的问题）。

主键：基于“INT”数据类型的“ID”。有一个基于“ID”列的聚集索引。

我对此更改的意图：想要管理此表（因为它有 10 年的数据）并继续前进（由于新要求），开发人员/分析师有可能进一步深入研究此表（仅几个月）我不想为同样的目的创建一个新表。

我的问题：

1. [主要问题]我可以根据“DateCreated”（DATETIME，NOT NULL 列）对这个表进行分区，而不会引起问题（逻辑上/性能方面）。

2. [很高兴知道] 需要多少时间（我知道这取决于数据库空间/服务器内存和其他细节，但大概# 会很好）对这个巨大的表进行分区（如果可以根据日期进行分区） . 问这个问题，因为这是一个生产表，行被频繁插入（现在大约 350 条记录/分钟）。

3. 【不完全是问题，求推荐】有没有更好的方案来管理这个表（不想在Production中保留3年以上的数据，方案在下面提到）？

当前计划（我是 MS SQL 的新手，所以这就是我想出的）：

• 在每个分区中保留 3 个月的数据。
• 系统在每个季度前自动创建分区。
• 在活动表中仅保留 3 年的分区。
• 将其他分区移动到 OLD/ARCHIEVE 表（需要创建这个）。真正要清除的旧数据。

越南语校对中的“tR”似乎有一些特别之处。知道的人能不能用简单的语言解释一下，不胜感激。此问题是在“越南语”整理的 SQL Server 上安装我们的产品期间发现的。模式中的一个表的名称中包含“tR”，但存储过程正在以所有小写的“tr”引用该表。而这个参考失败了。

我想这种情况类似于“？” 匹配其他排序规则中的“ss”。

这是一个复制品：

select  case when 'tr' = 'tR' COLLATE SQL_Latin1_General_CP1_CI_AS   then 'match' else 'no match' end 
select  case when 'tr' = 'tR' COLLATE Vietnamese_CI_AI   then 'match' else 'no match' end 
select  case when 'tr' = 'TR' COLLATE Vietnamese_CI_AI   then 'match' else 'no match' end 

结果：

-----
match


--------
no match


-----
match

第二个 T-SQL 产生不匹配。't' 和 'R' 的其他组合则不然。