标签: compatibility-level

如何知道哪个版本的mysql客户端与哪个版本的服务器兼容？

从客户端和/或服务器的角度来看，是否存在向后或向前兼容性表？

对于给定版本的服务器，如何知道哪些客户端兼容，反之亦然？

创建表脚本

create table temp 
(
    id int identity(1,1),
    a decimal(6,2),
    b decimal(6,2),
    c decimal(6,2),
    d decimal(6,2),
    e decimal(6,2),
    f decimal(6,2),
    g decimal(6,2),
    h decimal(6,2),
    i decimal(6,2),
    j decimal(6,2),
    k decimal(6,2),
    l decimal(6,2),
    m decimal(6,2),
    n decimal(6,2),
    o decimal(6,2),
    p decimal(6,2),
    q decimal(6,2),
    r decimal(6,2),
    s decimal(6,2),
    t decimal(6,2),
    u decimal(6,2)
)

插入脚本

insert into temp
    (a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u)
values
    (1,5,6,7,8,2,6,3,4,5,2,1,6,5,7,8,2,7,6,2,8)

insert into temp
    (a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u)
values
    (1,5,6,7,8,2,2,3,2,4,2,1,4,5,9,8,2,7,6,2,8)

预期结果

Median
======
first row  - 5.00
second row - 4.00 

非工作解决方案

我尝试了以下查询，该查询在 SQL Server 2014 …

我们最近将生产数据库的兼容性级别 (CL) 从 100 升级到 120。

几天之内，用户开始抱怨等待时间增加和普遍缓慢。决定将 CL 恢复到 100。虽然情况确实有所好转，但查询时间并没有回到历史平均水平。

然后我们清除了计划缓存以删除任何仍然存在的 120 个查询计划，并在配置工具中重新启动 SQL Server 服务。毕竟，我们的平均时间仍然明显更高，尽管比我们最初切换到 CL 120 时要好得多。

还有什么我可以做的，或者我错过了什么步骤，以恢复到旧的基数估算器？

我认为这没有任何影响，但我们所做的相同更改的一部分是在 CL 升级时启用 CLR，并在尝试恢复时再次禁用它。

我们使用的是 SQL Server 2014 Service Pack 1，还没有 CU。我们的更新时间表有限。CU 6 定于下个月进行。我们每晚更新统计数据并检查要重建的索引。

任何人都可以帮助解决我认为是一个简单的问题。

一位 DBA 朋友和我讨论了一般的兼容性级别，特别是它们与安全性的关系。他认为，使它们尽可能最新的一个很好的理由是减少由它们引起的安全漏洞。我反驳说，以前的 SP 和当前的 CU 和修补程序肯定会修补这些漏洞，即在 2014 SQL Server 实例中以 2005 兼容模式运行数据库肯定不会将该数据库恢复到 2005 SP4 安全级别/漏洞。

我一直在寻找支持此声明的文档，但一直找不到。有没有人知道任何权威文档可以告诉我正确或错误？

链接：https://learn.microsoft.com/en-us/sql/database-engine/install-windows/change-the-database-compatibility-mode-and-use-the-query-store ?view=sql-服务器版本15

我正在将 sql server 从 2016 年迁移到 2019 年。我了解，默认情况下，迁移后数据库将保留现有的兼容性级别。升级兼容性级别可启用新功能。

Microsoft 建议采用以下方法来升级兼容性级别以避免回归：

兼容性级别升级是否会导致任何破坏结果？或者查询回归（我认为这意味着由于错误的执行计划选择而导致查询比平时花费更多的时间）是兼容性升级的唯一负面影响吗？

我们有一些数据库脚本需要从 SQL Server 2008 R2 迁移回 2005，通常在 SQL Server 2008 / 2008 R2 中创建的脚本不会在 SQL Server 2005 安装（一些客户仍在使用）上运行。

所以我的问题：根据您的经验/知识，这真的有必要吗，或者在 SQL Server 2008 (2008 R2) 上将兼容性级别设置回 90 是否可以解决 SQL Server 2005 中未被注意的破坏脚本的问题？MSDN 说“兼容性级别仅提供与早期版本的 SQL Server 的部分向后兼容性”，所以我在这里不确定。

谢谢...

我想要一个“功能将通过兼容性级别 90 但在 SQL Server 2005 上会中断”或链接的具体列表。如果列表是短列表，我们可以将其转换为内部“不要这样做！”列表并保存一个大量的工作。

我需要一个将以下结果放在一起的查询：

• 跨所有数据库的每个数据库文件一行
• 包含有关文件所在的本地驱动器的信息的附加列
• 有关文件大小和用途的信息

到目前为止，我已经整理了以下查询：

    SELECT 
     GETDATE() as dt
     ,@@SERVERNAME as srv
     ,F.name 
     ,F.physical_name    
     ,Round(F.size * 8 / 1024, 2) as FileSizeMb
    , CAST(FILEPROPERTY(F.name, 'SpaceUsed') AS INT)/128 as FileUsedMB
    ,(F.size/128 - CAST(FILEPROPERTY(F.name, 'SpaceUsed') AS INT)/128) AS FileFreeMB
    ,Convert(decimal(18,2), (F.size/128 - CAST(FILEPROPERTY(F.name, 'SpaceUsed') AS INT)/128) / (F.size * 8 / 1024.1) * 100) as SpaceFreePerc 
     ,stat.size_on_disk_bytes / 1024 / 1024 SizeOnDiskMb
     ,drv.volume_mount_point, drv.logical_volume_name, drv.available_bytes, drv.total_bytes 
 FROM sys.master_files F 
 inner join sys.dm_io_virtual_file_stats(NULL, NULL) stat on F.database_id = stat.database_id AND F.file_id = stat.file_id …

我们正在将现有数据库移动到新的 SQL Server 2019 实例。

如果我们将兼容级别更改为 150，则没有任何效果。任务管理器显示 sql server 服务正在消耗所有可用内存并且所有查询超时并显示错误

内部资源池中的系统内存不足，无法运行此查询

RAM 被完全消耗，直到无法运行查询（所有这些都以我提到的上一个错误结束）。我们尝试过 16、32 和 64GB 的 RAM。

任何人都可以提供有关如何调试的任何提示吗？

请注意，这不是查询问题……仅更改兼容级别就足以使 SQL 开始耗尽内存。

即使运行一个简单的标量函数（内部使用多个 Substring 和 cast 调用 - 没有表或视图选择）也足以使其消耗所有可用内存。

我相信在数据库镜像中改变主数据库的兼容模式会改变镜像数据库。

但事实证明这是错误的。我sys.databases在 Primary 上查询使用，我将兼容模式更改为 120 ，但是在其镜像数据库兼容级别仍然是 100。为什么？

我在 sys.databases 中使用了不正确的 fn 吗？

此外，如果它没有改变它的含义，我是否需要进行故障转移/故障回复来反映？

如果我有只读日志传送辅助数据库以及此更改需要反映的地方怎么办？那我需要重建日志传送吗？

谢谢

我发现数据库兼容性级别之间的一段代码的行为存在差异，并想知道其原因是什么。下面是一个简单的示例，它迭代计数表并ROWCOUNT在第 50 次迭代时更改选项：

设置：

/* Create tally table */

SELECT  TOP 100
        ROW_NUMBER() OVER (ORDER BY a.object_id) AS Number
INTO    #Tally
FROM    sys.objects a
        CROSS JOIN sys.objects b;

/* Create Some databases with different compatibility levels */

CREATE DATABASE [100Compat] WITH COMPATIBILITY_LEVEL = 100
CREATE DATABASE [110Compat] WITH COMPATIBILITY_LEVEL = 110
CREATE DATABASE [120Compat] WITH COMPATIBILITY_LEVEL = 120
CREATE DATABASE [130Compat] WITH COMPATIBILITY_LEVEL = 130

受影响的代码：

/* cursor through the tally table */
DECLARE MyCursor CURSOR
FOR
SELECT …