问题标签 [azure-managed-database]

我在一个订阅中有我的生产数据库，在另一个订阅中有开发/测试数据库。如何将数据库从生产恢复到测试？

我们目前正在执行将本地 SQL 数据库迁移到 Azure SQL 数据库的 POC。在迁移时，我们遇到了应用模式的问题——很少有存储过程调用其他数据库。

场景就像我们有中央数据库-A，还有另一个应用程序数据库-B。应用程序数据库有一些引用中央数据库-A（基本上是选择和连接）的存储过程。

当我们搜索 MS 站点时，发现了一篇关于创建外部表链接的文章作为该问题的修复。如果您有多个具有多个引用的数据库，事情就会变得复杂。

所以我正在考虑使用 Azure SQL Managed Instance ，所以在启动一个并想要获得建议之前，托管实例中是否也会存在相同的情况？

我通过 JDBC 连接使用 PUBLIC ENDPOINT 连接到 Azure SQL 托管实例。它连接正确。我可以使用 JDBC 读取数据。

但是，如果我尝试使用 SSH 隧道连接 azure sql 的公共端点，我会得到以下相同的数据库、用户名和密码。

即使在网络安全组中，我也启用了所有端口。任何人都可以帮我解决这个问题吗？

我有一个 SQLCLR 程序集，它使用 SQL Azure 托管实例上的 LitJson 包进行简单的 JSON 反序列化。此 CLR 从一个表值函数调用，该函数仅将 JSON 属性作为表返回（理论上比 T-SQL 中的内置 JSON 处理更快）。

奇怪的是，程序集在卸载时（即它没有出现在 中sys.dm_clr_loaded_assemblies）比加载时运行得快得多。对于某些颜色，卸载时我可以在约 200 毫秒内反序列化 1,000 条记录，而加载程序集时，相同的 1,000 条记录需要约 7 秒。

我有一个解决方法，即在我的查询开始时，我PERMISSION_SET来回UNSAFE切换EXTERNAL_ACCESS强制卸载程序集，但这感觉就像一个黑客。程序集的加载速度应该比卸载速度快。

这里的任何想法将不胜感激。代码如下所示——根本没有什么花哨的地方。

SQL 组件如下所示：

更新

看来问题与 LitJson 包本身有关。我们最终尝试将 JsonFx 作为另一个不需要任何不受支持的 SQL Server .NET 库的包（向@SolomonRudzky 提出建议），但无论出于何种原因，该包在反序列化中的性能，这就是我们的练习，是不如原生 T-SQL JSON 处理（至少对于我们的数据集）。所以我们最终放弃了 SQLCLR 并返回到 T-SQL 来完成这个过程。T-SQL 中的性能仍然不如卸载的 LitJson 包，但它足以满足我们的需求，并且避免了在每次调用 CLR 时卸载程序集的太多不稳定的解决方法。

我正在尝试从链接服务器中读取数据，并且连接只带回第一个匹配项。如果我直接在远程服务器上运行查询，我会得到多行。本地和远程服务器都是 Azure 托管实例。@@Version 显示：

查询如下：

链接服务器的创建方式如下：

查询计划大到共享。此链接应允许您查看托管在 Google 上的文件：Linked Server Query Plan

我需要将 azure 托管 sql 服务数据库复制到本地实例中。但是当我搜索该主题时，我能够找到将本地迁移到 Azure 托管服务实例的选项。但不是反过来。请分享您的想法。

在以下要求方面需要帮助...

我必须从 90（源和目标 Azure MI 数据库）执行 ADF 迁移，例如源本地服务器（数据服务器 1、数据服务器 2、数据服务器 3、...数据服务器 90）到目标 Azure MI 服务器（Azure MI 数据库 1、Azure MI 数据库 2、Azure MI 数据库 3、....Azure MI 数据库 90)

On-Prem dataserver1 db1 (Self Hosted Integration Runtime1)---> Azure MI Database1

我的问题是，我是否需要为这个类似的活动创建 90 个（自托管集成运行时为每个本地源数据服务器）和 90 个管道，或者有没有办法对其进行优化，以便一个自托管集成运行时服务和同一管道可用于所有 90 迁移？

任何帮助或建议都会很有帮助，因为我是 ADF 的新手......

以下是我的管道活动... 在此处输入图片描述

在此处输入图像描述

我正在尝试从 Azure VM 机器中的 python 脚本访问 Azure 托管实例中的 SQL 数据库中的表（IP：xxxx.database.windows.net），但出现以下操作错误。我尝试了以下两种不同的方法。

错误：

OperationalError: ('08001', '[08001] [Microsoft][SQL Server Native Client 11.0]TCP Provider: 连接尝试失败，因为连接方在一段时间后没有正确响应，或者建立连接失败，因为连接的主机有未能响应。\r\n (10060) (SQLDriverConnect)；[08001] [Microsoft][SQL Server Native Client 11.0]登录超时已过期 (0)；[08001] [Microsoft][SQL Server Native Client 11.0]网络- 与 SQL Server 建立连接时发生了相关或特定于实例的错误。找不到或无法访问服务器。请检查实例名称是否正确以及 SQL Server 是否配置为允许远程连接。有关详细信息，请参阅 SQL Server 联机丛书. (10060)')

连接字符串的第一种方式：

连接字符串的第二种方式：

此外，我也尝试将驱动程序更改为下面的驱动程序，但仍然没有运气。

有趣的部分是，如果我尝试使用非 Azure VM 的本地机器（例如：我的本地机器或我可以 RDP 连接到的其他服务器）使用相同的连接字符串进行连接，我可以访问数据库。但是当我在 Azure VM 机器上尝试时，它会超时。您对如何解决此问题有任何想法吗？

感谢您的投入。

我在使用 gem 文件 tiny_tds（版本 2.1.1）的 linux 容器中尝试连接到 Azure 托管实例上的 sql server。

我用来连接的代码是这样的：

我已经尝试从 ruby​​ 控制台以及从容器内运行它。

这是我正在使用的 freetds 的信息：

我一直收到错误消息： Login failed for user 'username@full.server.name

奇怪的是，我可以通过 freetds 进行连接：

我想知道它是否与具有多个“。”的服务器/主机有关。主机名中的字符。

此外，根据我所读到的有关 tiny_tds 的内容，连接到 Azure 时，用户名需要附加 @servername。

我已经尝试了几个版本的 tiny_tds（全部无效）。

我还尝试了连接字符串的许多不同排列。纳达。

如果您有任何建议，请告诉我！！

AFAIK 没有直接提供此功能的REST API 。所以，我通过Create request使用 restore （还有其他方法，但不能保证事务一致性并且更复杂） 。

由于无法关闭短时间备份（保留时间必须至少为 1 天），因此它应该是可靠的。我在请求中使用“properties.restorePointInTime”属性的当前时间。这适用于大多数数据库。但是一个数据库向我返回了这个错误（来自异步操作请求）：

我知道我没有超出范围，因为如果恢复时间在“earliestRestorePoint”之前（这可以在托管数据库的 GET 请求中找到），或者将来我会收到“PitrPointInTimeInvalid”错误。尽管如此，我还是发现了一些信息，我不应该使用当前时间，而是使用当前时间 - 最多 6 分钟。如果通过不允许输​​入比当前时间更新的时间 - 6 分钟通过 Azure 门户（它失败并出现相同的错误顺便说一句）完成，这也是正确的。经过几次尝试，我发现当前时间 - 大约 40 分钟开始正常工作。但是 40 分钟太多了，在我尝试等待异步操作的结果之前，我没有找到任何方法来找出什么时间有效。

我的问题是：有没有办法找到最晚的恢复时间？

还是有更好的方法来“复制”托管数据库，以保证事务一致性并且相当快？

编辑：
我所描述的问题已报告给 MS。它发生在：

1. 有一个自定义时区格式，例如 UTC + 1 小时。
2. 由于数据库处于非活动状态（无活动事务），因此在所需时间点跳过源数据库的备份。

这应该从现在（2021 年 8 月 25 日）开始修复，并且我无法在当前时间 - 10 分钟内重现它。我还被告知应该有新的 API 允许在不使用 PITR 的情况下进行复制（不早于 1Q/22）。