我知道这个问题可能已经得到了部分回答。我的问题如下。
SQL Server 安全更新是累积性的吗？
在https://sqlserverupdates.com/sql-server-2014-updates/网站上，它说在 CU4 之后发布了 3 个“安全更新”，然后在 2023/02/14 发布了一个 GDR。有人可以解释 GDR 和 3 安全更新之间的区别吗？
2023 年 2 月 14 日发布的 GDR 更新是否包含之前发布的 3 个安全更新中的所有更新？
我在同一物理服务器（2 个 NUMA 节点）上运行 SSRS 和 SQL Server。
如何配置 SQL Server 和 SSRS 以使用单独的 NUMA 节点？
我只是不希望 SQL 数据引擎潜在地消耗 100% 的 CPU 资源而没有为 SSRS 留下任何东西。
我们正在尝试解决其中一个应用程序的连接问题，该应用程序试图从防火墙后面的非常安全的 sql 服务器中提取数据。我不是安全方面的专家，但需要有关如何继续为该应用程序打开端口以从安全域后面的 sql server 中提取数据的帮助。
我们已经打开了 sql server 正在侦听的端口，比如说 12345，但仍然没有运气。
我怎么知道可能需要打开哪些额外的端口，如 udp 1434 默认 1433 或镜像 5022？有没有办法找到这些信息？
我可以通过查询视图来获取可用内存[master].[sys].[dm_os_sys_memory]，但是我没有找到任何类似的东西来获取有关 CPU 负载的信息。
我只找到有关通过 SQL 服务器本身查询 CPU 负载的信息，这不是我主要关心的，我需要系统上的全部负载。我查看了系统视图，但我找不到任何东西，或者至少不明白我是否找到了它......
我想通过 T-SQL 得到这个的原因是我们已经有一个监控应用程序，它正在查询我们所有的系统以获取其他信息，并且能够扩展它而不是设置一些全新的东西会很好。
目前感兴趣的系统正在运行 2014 和 2017 express，但它可能很快就会包括 2019/2022 express。
到目前为止，我有以下查询，不幸的是，我不能使用正则表达式或大于运算符，我只能使用LIKE关键字。
整个列都在一个 json 字符串中，我不能使用json_value或正则表达式，因为我在 SQL Server 上，所以我坚持使用LIKE. 它是 SQL Server 2014，json_value直到 2016 年才受支持。
SELECT * FROM DataTableOne
WHERE update_date LIKE '%1645290000%'
我想仅使用 SQLLIKE关键字（甚至使用 SQLLIKE运算符在 1645290000 和 9999999999 之间）检索纪元 unix 时间戳大于 1645290000 的所有记录。
任何帮助将不胜感激，因为这是一个非常艰难的独特案例，我仅限于使用LIKE关键字。
示例表/数据如下：
CREATE TABLE DataTableOne (
ID int,
DATA varchar(MAX)
);
INSERT INTO DataTableOne (ID, DATA)
VALUES (1, '{"name":"Cole", "update_date":"2855290000"}'),
(2, '{"name":"Peter", "update_date":"1222290000"}') ;
这种数据可能有一千行，我唯一想要的是 update_date 大于 1645290000 的行。
在我给出的上表上运行查询应该只返回第一行，因为 2855290000 的update_date在数值上确实大于 1645290000。
我目前有一个带有非常基本的 AAG 设置的 SQL Server 2014 实例。AG中有2个节点。主节点上的日志驱动器有 90% 的可用空间，辅助节点上的日志驱动器有 5% 的可用空间。我想我有两个问题是：
- 由于它们是同步的，它们不应该总是或多或少相同的大小吗？
- 如何在不首先将其设为主节点的情况下缩小辅助节点上的日志大小？
有没有办法在不进行手动故障转移的情况下完成第二个，使其成为主要然后完成所有工作？我如何才能防止将来出现这种巨大的尺寸差异，或者这只是意料之中的？提前感谢您的帮助。
我删除了我的旧问题，以便更准确地了解我需要什么。
我们有一个包含许多较小查询的大查询。这个查询运行得非常好，直到它到达“having max”子句：
having
max
(
DateField
) < getdate() - @2_years_ago
有没有比拥有 max 更快的条款？因为这会导致索引扫描以及表中存在的数百万行不停地循环和循环。
我试图按 row_number 做，但没有运气。
我只是注意到这个相同的查询在具有相同结构的其他数据库上运行得很好。
只是这个（有趣的是行更少）它不起作用。
数据库在同一台服务器上。
我遇到了与自动故障转移相关的异常行为，因此在关闭 SQL Server 服务的情况下自动故障转移不起作用。集群磁盘似乎仍连接到故障节点，但我无法找出导致此行为的最终问题。如果您能帮助我理解这个问题，我将非常感谢您。
出于测试目的，我在域控制器上创建了 iSCSI 目标，并连接了 2 个启动器：
以下是有关我的集群的详细信息：
以下是有关我的 SQL Server 服务的详细信息：
以下是有关集群磁盘的详细信息（我只添加了其中一个磁盘的详细信息，因为两个磁盘相同）：
现在，当我关闭 SQL Server 服务时，服务的自动故障转移不会发生：
I tested other scenarios where automatic failover successfully works:
- Manual failover
- Shutting down active node
- Disabling adapter on active node
- killing sql server process in task manager
- killing sql agent service process in task manager
In all above scenarios, resources successfully failed over to another node.
Could you please help me to figure out what is going wrong with automatic failover when I shutdown SQL Server service on active node?
我在 sql server 2017 上工作，我遇到了我无法解决的问题partnumber
至少具有源类型website并且至少具有stockid equal 1每个partnumber
所以还有另一个含义，我需要获得具有stockid 1和source type website
所以我需要进行选择查询获取必须具有源类型website和库存=1的零件编号Part number
样本数据
create table #stockyes
(
PartNumber varchar(100),
sourcetype varchar(100),
stockid tinyint
)
insert into #stockyes(PartNumber,sourcetype,stockid)
values
(1233,'Website',1),
(1233,'Website',0),
(1233,'Datasheet',1),
(8901,'Website',1),
(8901,'Website',0),
(9015,'Website',1),
(7801,'Website',1),
(7801,'Website',1),
(9401,'Datasheet',0),
(5688,'Datasheet',0),
(5688,'Datasheet',0),
(5688,'Lifecycle',2),
(5688,'Lifecycle',2),
(8409,'Lifecycle',1),
(6703,'Website',0),
(6703,'Website',0),
(6703,'Website',0),
(3099,'Website',0),
(3099,'Website',0),
(8541,'Website',0)
预期结果
我已经将几个大表（每个具有 >10^9 行和几十列）从聚集行存储移动到 SQL Server 2014 实例上的聚集列存储索引，并注意到这些的统计信息更新（默认采样，在我们的 ETL 中触发或来自 Hallengren 脚本）现在需要更长的时间。
一个更理论的问题是为什么会这样？我的疯狂猜测是统计信息更新会产生大量随机读取，这与列存储索引不兼容，因为它们更适合大量数据的顺序读取。我很高兴知道更“深入”的解释。
更重要的问题是我是否可以针对它做点什么。我已经在 SQL Server 2017 实例上尝试了针对具有单个 bigint 列（见下文）的表的测试用例，结果相同。增量统计似乎是一个很好的解决方案。我需要重新创建所有统计对象（目前不是增量的，可能是由于历史原因），扩展 ETL 逻辑并更新我们的 Hallengren 脚本版本（我们目前使用旧版本）。如果有人在我进入这个兔子洞之前分享他/她的经验，我将不胜感激。
重现步骤：
/*Create a rowstore and a columnstore table with a single bigint column*/
CREATE TABLE dbo.rowstore (col1 BIGINT);
GO
CREATE TABLE dbo.columnstore (col1 BIGINT);
GO
CREATE CLUSTERED COLUMNSTORE INDEX CCI_columnstore ON dbo.columnstore;
GO
/*Fill both tables with 400 * 10^6 rows. This results in a 15GB large rowstore and a 3,1GB large columnstore tables*/
;WITH e1(n) AS
(
SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL
SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL
SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1 UNION ALL SELECT 1
), -- 10
e2(n) AS (SELECT 1 FROM e1 CROSS JOIN e1 AS b), -- 10*10
e3(n) AS (SELECT 1 FROM e2 CROSS JOIN e2 AS b), -- 100*100
e4(n) AS (SELECT 1 FROM e3 CROSS JOIN e3 AS b) -- 10000*10000
INSERT dbo.rowstore WITH (TABLOCK)
SELECT CAST(CAST(NEWID() AS VARBINARY(8)) AS BIGINT) FROM e4;
GO 4
INSERT dbo.columnstore WITH (TABLOCK)
SELECT * FROM dbo.rowstore
GO
/*Trigger stats creation*/
SELECT TOP 1 * FROM dbo.rowstore WHERE col1>0
SELECT TOP 1 * FROM dbo.columnstore WHERE col1>0
GO
SET STATISTICS TIME, IO ON
/*This runs 1,5 seconds*/
UPDATE STATISTICS dbo.rowstore
/*This runs 8 seconds and becomes much slower than rowstore on really large tables*/
UPDATE STATISTICS dbo.columnstore