设想\n我们正在将 SQL 资产升级到 SQL Server 2019,并已设置生产环境。
\n\n来自:\nSQL2008R2 Standard/Windows Server 2008R2 - 主服务器/辅助服务器(Windows 故障转移群集)和报表服务器(事务复制)。
\n\n至:\nSQL2019 Standard/Windows Server 2019 - 主服务器/辅助服务器(始终开启)和报表服务器(事务复制)
\n\n2008R2 的备份已于 2019 年恢复,兼容性级别设置为最新。始终在线设置相对顺利,针对当前应用程序的初步测试未显示兼容性问题。
\n\n问题纯粹在于设置事务复制。有 2 个数据库需要复制,每个数据库都有一个发布,主数据库作为发布者和分发者。
\n\n问题\n在报告服务器上每个数据库的订阅初始化期间,它运行良好,直到到达创建函数并产生以下错误为止。
\n\n第一个数据库:
\n\n\n\n\n消息:选项“INLINE=ON”对此功能无效。检查函数中 INLINE 选项支持的构造的文档。\n 命令文本:CREATE FUNCTION [dbo].[f_clienttels - 镜像复制 ce2d3663eb494f3589bd5000dad1bf1f](@ClientID [int])\n RETURNS varchar WITH INLINE = ON, EXECUTE AS CALLER\n AS \n BEGIN ......
\n
第二个数据库:
\n\n\n消息:为语句“CREATE/ALTER FUNCTION”指定了无效选项。\n 关键字“with”附近的语法不正确。如果此语句是公用表表达式、xmlnamespaces 子句或更改跟踪上下文子句,则前一个语句必须以分号终止。\n \')\' 附近的语法不正确。\n 命令文本: CREATE FUNCTION [dbo] .[GetGroupAndDescendantGroupsSelective - 镜像复制 46f329d5eed444428f45b052f07c7ea8](@GroupId …
由于磁盘限制,我最近进行了一项练习,以释放生产数据库 (SQL Server 2008 R2) 中的一些空间。特别是一张表就占据了 98% 的数据库。不需要的记录被识别出来,占数据的 1/3(大约 160GB 或 450GB)。
所以我在不同的磁盘上创建了一个数据库,创建了一个具有相同架构的表,唯一的区别是创建了一个 ID 列,而不是IDENTITY
. 我将其称为存档,将原始称为源。根据 SSMS,Original 有 PK 索引和另外两个小索引,总计 19MB。存档只有 PK 索引,因为它不会被查询。
我一次将数据分批传出 1000 行,以尽量减少对生产的影响。几个小时后,存档上的磁盘空间也用完了,所以当数据库达到 145GB 时我停止了传输,这代表了 800,000 行。
然后我开始删除源表,确保只删除存档的内容。这运行了一夜,并在交易开始前停止,最终从原始表中删除了 550,000 行。
根据存档,这应该是大约 (145GB / 800000) * 550000 ~= 100GB。但是源数据库中的可用空间只有45GB!
我已经做了明显的谷歌搜索和检查 DMV,但我找不到任何有用的东西,然后我承担了比较所有数据的数据长度以查看问题是否出在那里的任务。当我们使用 XML 列时,我的想法是删除的列由于其内容而代表较小比例的存档数据。这变得更加混乱,以下是结果:
所以这证明存档的数据大小与源(前两名)匹配,更重要的是我怀疑删除的 550000 行代表磁盘空间的一部分比剩余的 250000 更小。
但是删除的记录加起来比数据库中释放的 45GB 多出 16GB。而且存档被计算为具有 130GB,尽管大小为 145GB,因此再次出现 15GB 的赤字。
这是我正在努力弄清楚的。我目前的理论,虽然我不知道如何证明,但删除的数据(哪个日期分布在表格中)已从页面中删除,留下一些不符合标准的数据,所以如果这些页面已满 8kb,我们删除了一些代表其中 2kb 的数据,这就是数字不匹配的原因,仅释放了 45GB …
我正在为即将到来的基础设施变化起草一份提案。这将包括一个生产服务器和报告/数据仓库服务器,每个服务器都具有 Always On。为了降低硬件和许可成本,是否可以在运行 Prod-AG Primary 和 Rep-AG Secondary 的 Server-A 以及运行 Rep-AG Primary 和 Prod-AG Secondary 的 Server-B 的配置中运行?
我认为每个服务器都需要 2 个以下 WSFC 实例、sql 实例、AG、侦听器、DNS 名称/端口。
我希望这是有道理的,这是我认为它会是什么样子的图表。
在任一节点上发生故障转移的情况下,工作负载/业务需求并不是那么大,在同一台服务器上运行几个小时将是一个主要问题。
我只发现了几次类似的设置,但没有来自 Microsoft 或成功运行此设置的任何人的明确信息。
SQL 版将是 2017 年,很可能是标准版,我认为我们不会被批准用于企业版。操作系统将是 Windows Server 2016 Core。