問題タブ [azure-sqldw]

数百万行を切り捨てて挿入するいくつかの大きな sproc で、DMS 内で少なくとも 30% 以上の確率でデッドロックが発生しています。ただし、実行中のクエリは 1 つしかないため、デッドロックがどのように私のせいになるのかわかりません。

と：

これは、確認または修正すべき明らかなことを示していますか? それとも、Azure サポート ケースは解決への最善の道ですか?

更新: この問題のサポート ケース 115111713384329 が開かれています

更新: SQL DW は 2016 年 3 月 4 日に新しい更新を取得し、この問題を修正したと思われます。(オンデマンドで再現できないため、確実なことは言えません。) 「select @@version」を実行すると、10.0.8224.5 以降に修正が適用されます。まだ修正を入手していない場合は、サポート ケースを開いてリクエストするか、数週間待って修正を入手することを想像します。

企業のファイアウォール内から Azure SQL Data Warehouse インスタンスに接続する際に問題が発生しています。

サーバー自体 (つまり、マスター データベース) に接続でき、1433 でサーバー名と IP の両方に telnet できますが、SQL DW データベースに接続しようとすると、「ターゲット マシンが原因で接続できませんでした」というメッセージが表示されます。積極的に拒否しました」(SQL Server エラー 10061)。

これは権限の問題ではありません。ユーザーはデータベースにアクセスでき、他のネットワークから同じ資格情報を使用してデータベースに接続できます。マスター データベースに接続できるため、ファイアウォールの問題でもないようです。

もう 1 つの特異な症状は、サーバーのバージョン番号がクライアントごとに異なる (12.0.2000.8 や 13.0.702 など) と報告されることですが、これは接続には何の違いもないようです。

これは、VS 2013、VS 2015、SSMS 2012、および SSMS 2014 で発生します。

誰がこれを引き起こしているのか考えていますか?

よろしく、

マット

「Azure SQL データ ウェアハウス」で非常に単純なクエリ (以下を参照) を実行すると、5 秒かかります。「Azure SQL Server」で同じクエリを実行すると、0 秒かかり、より正常に見えます。(このクエリは、実行すると実行計画からわかるように、基本的には条件のない LEFT JOINS の集まりです。)

これに5秒かかる可能性はありますか?

CREATE EXTERNAL TABLE cetasTable AS SELECT コマンドを実行すると、次のように実行します。

分散クエリ プランに次のように表示されます。

正しい行数を知っているようですが、このクエリがゼロ行を返すため、そのテーブルに統計が作成されていないことがわかります。

ブロブ ストレージに既にファイルがあり、CREATE EXTERNAL TABLE cetTable コマンドを実行した場合は、次のコマンドを実行します。

分散クエリ プランは、SQL DW が外部テーブルに 1000 行しかないと考えていることを示しています。

もちろん、統計を作成して、SQL DW が分散クエリ プランを作成するときに正しい行数を認識できるようにすることもできます。しかし、誰かが正しい行数を時々知っている方法と、その正しい行数がどこに保存されているかを説明できますか?

Azure SQL DW には現在、レプリケートされたテーブルがないため (更新: 現在あります)、BroadcastMove 中に正確に何が起こるのでしょうか? 計算ノードごとに 1 つの一時テーブルが作成され、ブロードキャストの結果が取り込まれますか? 次に、60 個のクエリ (ディストリビューションごとに 1 つのクエリ) を実行して、ブロードキャストされた一時テーブルに参加しますか?

私は主に、ブロードキャストが60個の一時テーブルが作成されることを意味しないことを確認しています。

私は次のデータを持っています。

過去 4 週間のデータを取得するための SQL クエリを作成する必要があり、次の各列について過去 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: 返される必要がある 4 つの行には、それ自体からの列の合計があり、それは 3 週間前です。

たとえば、201548 の数値が必要な場合は、次のように返されます。

201548、201547、201546、およびの 4 つの (非同一性) 列の合計です201545。

列ストアの仕組みは、列ストアの 1 つのディストリビューションに 102,400 を超える行を一括で読み込むと、自動的に圧縮されると考えていました。私は Azure SQL DW でそれを観察していません。

次の CTAS ステートメントを実行しています。

次に、列ストアの行グループの状態を確認します。

最終的に、102401 行の 1 つの OPEN 行グループになります。列ストアのこの動作を誤解していませんか? Azure SQL DW は異なりますか?

SSIS から同じ数の行をすべて 1 つのバッファーとして一括挿入すると、同じ動作が見られます。

650 万行以上を挿入するという Drew の提案を試してみましたが、それでもすべての OPEN 行ストアに行き着きます。