门号 1、2 或 3?...安全更改、错误或从 SQL Server 2016 就地升级到 SQL Server 2019 的升级失败?

J.D*_*.D. 5 sql-server upgrade linked-server sql-server-2016 sql-server-2019

我做了什么:

ServerA最近,我测试了在运行 SQL Server 2016 (SP 2 CU17) 标准版到 SQL Server 2019 标准版的开发服务器上进行就地升级。(我知道这不是进行升级的首选方法,但同样只是在开发服务器上进行测试,所以没有坏处。)

在安装向导过程中,其中一个步骤挂起很长时间,因此我的同事单击“下一步”按钮跳过该步骤。我不太记得那是哪一步,但我相信它是产品更新或安装设置文件步骤。我记得接下来它说它跳过了几种不同类型的下载。剩下的安装一切顺利,顺利完成。

我能够启动实例、登录并访问我们的数据库。然后,我将数据库兼容级别提高到 150(SQL Server 2019 的兼容级别)。我运行了一些性能测试查询,然后最终决定打开旧基数估计器。到目前为止一切似乎都正常。

发生的事情是:

然后我注意到 上有一些有趣的事情ServerB,这是另一台已经运行 SQL Server 2019 的开发服务器,并且有一个指向 的链接服务器设置ServerA。一切都运行良好ServerB,除了任何跨链接服务器引用视图的查询,ServerA该视图在其中使用架构绑定标量函数。我收到错误The EXECUTE permission was denied on the object 'MyFunction', database 'Database1OnServerA', schema 'dbo'。如果我返回ServerA并更改该函数并WITH SCHEMABINDING注释掉该行,则ServerB可以从再次引用该函数的视图中进行选择。

附加信息:

链接服务器对象中使用的帐户是一个 SQL Server 登录帐户ServerA,只有映射db_datareader到它的角色(当然除了数据库角色之外)。没有对其设置额外的细粒度权限,并且也仅分配有服务器角色。Database1ServerAPublicPublic

有趣的是,我的问题的另一种解决方案是向链接服务器帐户或专门授予链接服务器帐户的EXECUTE权限。但在升级到 SQL Server 2019 之前我不必授予权限,并且我的生产服务器(在这次测试升级之前非常类似地镜像我的开发服务器)目前也没有向链接服务器帐户提供权限。Database1ServerAMyFunctionEXECUTEServerAEXECUTE

门号 1、2 或 3:

  1. 从 SQL Server 2016 到 SQL Server 2019 是否发生了一些与安全相关的变化,我没有意识到或者......
  2. 这听起来像是我遇到过的错误还是......
  3. 您认为我的就地升级失败了吗ServerA

简而言之,从 SQL Server 2016升级到 SQL Server 2019 后,为什么在通过链接服务器访问的仅架构绑定函数的权限ServerB上会出现权限错误,还有其他想法吗?EXECUTEServerAServerA

Dav*_*oft 9

门号 1、2 或 3:

2,带破折号 3。

所有权链应防止对视图引用的标量 UDF 进行权限检查,因此对视图具有 SELECT 权限的用户不应还需要视图所有者拥有的 UDF 的 EXECUTE 权限。

看起来这是 RTM 中存在并在某些 CU 中修复的众多 TSQL 标量 UDF 内联错误之一。它在 RTM 上为我重现,并在升级到 CU14 后停止。

SQL Server 通常不会整合累积更新(或 Service Pack*),因此安装程序会安装 RTM,然后在升级后进行修补。通常会为 GDR 更新构建更新的安装程序,但在主要版本升级后没有理由保留在 RTM+GDR 上。

当我设置时,它也停止在 RTM 上执行此操作

ALTER DATABASE SCOPED CONFIGURATION SET TSQL_SCALAR_UDF_INLINING = OFF;
Run Code Online (Sandbox Code Playgroud)

*SQL Server 2017 及更高版本没有服务包,只有 CU。