小编Dan*_*man的帖子

incurs_seek_penaltySQL Server 2019 sys.dm_os_volume_statsDMF 中引入了一个新列。这个tinyint 列目前没有记录。

有没有人有关于此列中返回的枚举值的信息？我见过 0（裸机服务器）和 2（VM）的值。我很好奇这些值的含义以及可能返回的其他值。我的互联网搜索没有出现任何结果。

我们有一对 SQL 2019 Enterprise 实例，托管在 Azure 中规格和配置相同的虚拟机中。

它们用于简单的主/辅助可用性组阵列，包含跨少量 AG 的少量数据库。

单个主生产数据库利用由生产代码填充的大型（数十亿行）列存储表，并用于只读分析报告查询 - 这些查询还连接到行存储表以获取附加信息。

我们希望将只读查询卸载到只读 AG 辅助数据库上，以将负载分散到数据库上，因此我们向侦听器提供参数ApplicationIntent=ReadOnly- 这效果很好，并且针对辅助数据库发出查询。

然而，只读查询的持续时间通常比主数据库慢 10 倍。

比较相同的执行计划，我可以看到所有额外的时间都花在读取列存储表上。反复重新运行查询以确保缓存不会对辅助数据库产生任何影响。但在主要方面，我看到了与缓存相关的性能改进，重新运行时立即返回结果。另外，暂时停止AG数据同步也没有任何效果。

比较 IO 统计数据，两者相似。比较列存储对象池和行存储缓冲池中使用的内存，两者也很相似。

这里真的很茫然——我本以为辅助设备的负载要少得多，但资源相同，如果有更好的表现，而不是持续和明显更差的话。

有没有人遇到过这种情况并对我如何改善或至少证明这种情况有任何建议？

我正在使用 sqlserver 2014 并尝试创建一个StoredProcedure像这样的内部 try-catch 块：

BEGIN TRY   
  CREATE PROCEDURE [ammeghezi1] (@w INT) AS SELECT '' 
END TRY
BEGIN CATCH
  ...
END CATCH

它无法运行并出现以下错误：Incorrect syntax near 'SELECT' Expecting EXTERNAL.
然后我更改了 sp 如下：（CREATE PROCEDURE [ammeghezi1] (@w INT) AS BEGIN SELECT '' END用 BEGIN-END 块覆盖 sp），但错误没有改变。我还添加了GOafterBEGIN TRY声明，结果变得最糟。
我得出的结论是，sp在TRY_CATCH块内创建是不切实际的。

这甚至可以sp在TRY_CATCH块内创建吗？如何？

所有更新均安装在 VS 2017 (15.9.47) 和 2019 (16.11.2013) 上

我正在尝试通过 Microsoft\xe2\x80\x99s 工具、On Prem 和 Azure SQL 托管实例在两个数据库之间执行数据比较\n过去几个月一切正常

我上周更改了密码，这是我唯一能看到导致问题的原因？\n当我之前更改密码时，没有出现任何问题，也许是巧合

\xe2\x80\xa2 我可以使用新密码连接到 SSMS 中的 Azure SQL 托管实例\n\xe2\x80\xa2 我可以使用新密码连接到 SSDT 中的 Azure SQL 托管实例

问题

在 SSDT 2017/2019 --> 工具 --> SQL Server --> 新数据比较 --> 选择连接

选择 Azure SQL 托管实例，单击连接 --> 连接 --> 提示输入我的密码\n无错误 --> 在源数据库中仍然说明“选择数据库”（应说明 Azure SQL 托管实例）

\xe2\x80\xa2 使用本地服务器连接正常

我试过

\n
1. 再次重置密码
\n
2. 使用新密码在 SSDT 中创建了到 Azure SQL\n托管实例的新连接，我可以在下拉列表中看到所有数据库，没有错误，似乎已连接
\n
3. SSDTSchema …

我有一个包含超过 200 亿行的 SQL Server 表，最后一个分区中有 130 亿行。

该表目前按“时间”字段分为 6 种方式：

2011
2012
2013
2014
2015
2016/2017/2018

2016/2017/2018分区需要拆分成自己的分区所以有2016、2017、2018分区。

如何做到这一点并在此过程中避免大量日志文件增长？数据库处于简单恢复中，当前每个分区都位于其自己的一组磁盘上的单独文件组中。

CREATE TABLE [dbo].[Log](

      [RefNo] [nchar](7) NOT NULL,

      [DevID] [nvarchar](7) NOT NULL,

      [Time] [datetime] NOT NULL,

      [summary] [float] NULL,

      [staging] [float] NULL,

      [position] [float] NULL,

CONSTRAINT [PK_Log] PRIMARY KEY CLUSTERED

(

      [RefNo] ASC,

      [DevID] ASC,

      [Time] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = ON, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 96)

)

我们有一个包含人力资源数据的 HR 架构的 SQL Server 数据库。它包括工资和其他私人信息。数据库所有者、系统管理员和 [Executives] 角色的成员可以查看 HR 架构。

其他一些用户是 db_datareader 角色的成员，该角色能够从数据库的任何表中读取数据。他们在人力资源安全要求存在之前就被添加到该角色中。

拒绝所有其他用户访问的策略是什么？

我不小心恢复了数据库的一个非常旧的版本，并拥有 3 天前的 .bak 标准文件。

但我在 MSSQL 中发现了这个“备份时间线”，它实际上指出了几个我什至不知道发生过的备份。然而，当我选择其中一个进行恢复时，他们只是声称该文件不存在（并且它根本不存在于标准备份文件夹中）。

我应该怎么办？？我丢失了一堆重要数据！