问题标签 [azure-sqldw]

在截断和插入几百万行的几个较大的存储过程中，我们在 DMS 中至少有 30% 或更多的时间出现死锁。但是，只有一个查询正在运行，所以我看不出死锁是我的错：

和：

这点是否明显需要检查或修复？还是 Azure 支持案例是解决问题的最佳途径？

更新：支持案例 115111713384329 已针对此问题开放

更新：我们的 SQL DW 在 2016 年 3 月 4 日获得了一个新的更新，据说它修复了这个问题。（我不能按需复制它，所以我不能肯定地说。）如果你运行“select @@version”，那么 10.0.8224.5 或更高版本应该有修复。如果您还没有修复程序，我想打开一个支持案例并请求它或等待几周会让您得到修复程序。

我在从公司防火墙内连接到 Azure SQL 数据仓库实例时遇到问题。

我可以连接到服务器本身（即主数据库），并且可以远程登录到 1433 上的服务器名称和 IP，但是当我尝试连接到 SQL DW 数据库时，我得到“无法建立连接，因为目标机器主动拒绝它”（SQL Server 错误 10061）。

这不是权限问题 - 用户可以访问数据库，我可以使用相同的凭据从其他网络连接到它。这似乎也不是防火墙问题，因为我可以连接到主数据库。

另一个特殊的症状是服务器的版本号从不同的客户端得到不同的报告——不同的是 12.0.2000.8 和 13.0.702——尽管这似乎对连接没有任何影响。

这发生在 VS 2013、VS 2015、SSMS 2012 和 SSMS 2014 中。

有谁知道可能是什么原因造成的？

问候，

马特

我正在尝试使用 bcp 实用程序加载我的 Azure SQL 数据仓库，但在一个又一个问题中遇到问题......我终于得到了一个 .txt 文件，其中包含一条记录可以成功导入，但是现在当我将两条或更多记录放入该文件，它会出现错误（通过错误输出文件）：

第 1 行第 5 列：数值超出范围

数据如下所示：

我要导入的表如下所示：

我认为这与换行符有关，但我无法解决它。我尝试将 Notepad++ 中的编码更改为 ANSI、ISO-8859-1、UTF-8 w/o BOM，以及使用 Visual Studio CODE 的 UTF-16 LE & BE。当指定'ANSI'时，单行文件导入成功。行尾顺序设置为LF，我的bcp命令如下：

我在“Azure SQL 数据仓库”中运行了一个非常简单的查询（见下文），它需要 5 秒。如果我在“Azure SQL Server”中运行相同的查询，则需要 0 秒，这似乎更正常。（这个查询基本上是一堆没有条件的 LEFT JOINS，如果你运行它，你将从执行计划中看到。）

这怎么可能需要 5 秒？

我在 Azure Blobs 中有一堆数据作为 JSON 文件存储。我想将它们加载到 Azure SQL 数据仓库，但 Azure SQL 数据仓库似乎不接受 JSON 输入文件。

最好的方法是什么？

我研究的解决方案：

1）使用带有自定义活动的 Azure 数据工厂（例如https://github.com/Azure/azure-content/blob/master/articles/data-factory/data-factory-use-custom-activities.md）但似乎为此旋转 HDInsight 群集有点“开销”（而且我更喜欢使用 JavaScript 而不是 C# 解决方案）。

2) 编写 Azure api-app（或自定义代码）将文件转换为 CSV，然后编写外部表脚本将其上传到 Azure SQL 数据仓库，然后删除 CSV 文件。我不确定是否需要保留此 CSV 文件以供以后使用。

有更好的建议吗？

如果我运行 CREATE EXTERNAL TABLE cetasTable AS SELECT 命令，则运行：

我在分布式查询计划中看到：

它似乎知道正确的行数，但是，如果我查看该表上没有创建统计信息，因为此查询返回零行：

如果我已经在 blob 存储中有文件并且我运行 CREATE EXTERNAL TABLE cetTable 命令，则运行：

分布式查询计划显示 SQL DW 认为外部表中只有 1000 行：

当然，我可以创建统计信息以确保 SQL DW 在创建分布式查询计划时知道正确的行数。但是有人能解释一下它是如何在某些时候知道正确的行数以及正确的行数存储在哪里的吗？

Because Azure SQL DW doesn't currently have replicated tables (update: it does now), what exactly happens during a BroadcastMove? Does one temp table per compute node get created and populated with the results of broadcast? Then do 60 queries (one query per distribution) get run to join to the broadcasted temp table?

I'm mainly just checking that a broadcast doesn't mean 60 temp tables get created.

In PDW, you can have 10 loads running concurrently and up to 40 queued, then the 51st will fail. What about for Azure SQL DW?

This page mentions the DWU/concurrency numbers. Does data loading (through bulk load and Polybase) also follow the 32 concurrent query limit? What happens if you try to run 33 concurrent loads? Is there a max queue depth?

我有以下数据。

我需要编写一个 SQL 查询来获取最后 4 周的数据，并将它们的最后 4 周汇总为以下列中的每一列：POS_Store_Count、POS_Qty、POS_Sales和POS_Cost。

例如，如果我想要 201548 的数据，它将包含 201548、201547、201546 和 201545 的数据。

201547 的总和将包含 201547、201546、201545 和 201544。

成功运行时，查询应返回 4 行。

我将如何制定一个递归查询来做到这一点？有什么比递归更容易做到这一点的吗？

编辑：版本是 Azure Sql DW，版本号为 12.0.2000。Edit2：应该返回的四行将具有来自其自身的列的总和，并且是前三周。

例如，如果我想要 201548 的数字，它将返回以下内容：

201548这是来自、201547、201546和的四个（非身份）列的总和201545。

我认为列存储的工作方式是，如果您将超过 102,400 行批量加载到列存储的一个分布中，它会自动压缩它。我没有在 Azure SQL DW 中观察到这一点。

我正在执行以下 CTAS 声明：

现在我检查列存储行组的状态：

我最终得到一个具有 102401 行的 OPEN 行组。我是否误解了列存储的这种行为？Azure SQL DW 有什么不同吗？

如果我从 SSIS 执行相同数量的行的批量插入，我会看到相同的行为，所有这些都作为一个缓冲区。

我尝试了 Drew 的插入超过 650 万行的建议，但我仍然得到了所有 OPEN 行存储：