Escalation Engineer
神谷 雅紀

復元の条件

以下の条件を両方とも満たしている場合に限り、誤って削除してしまったデータベースを復元することができます。

• 削除したデータベースの配置されていた論理 SQL Server が存在している。(SQL Server は削除していない。)
• データベースバックアップの保有期間である。(2018/5/1 時点では既定の保有期間は Basic は 7 日、Standard および Premium は 35 日。https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-automated-backups)

復元の手順

1. Azure ポータル (https://portal.azure.com) でリソースとして [SQL Server] を選択し、続いて、削除したデータベースをホストしていた論理 SQL Server 名、[削除されたデータベース]、復元したいデータベース名の順番に選択します。

※ [削除されたデータベース] に復元したいデータベース名が表示されていない場合には、5 ～ 10 分程度待った後に改めて確認して下さい。

2. 次に、復元後のデータベース名を指定します。既定では、削除したデータベース名の後ろに日時が付加された名前になっています。データベース名を指定して OK を押下すると復元が開始されます。しばらく待つと復元が完了します。

3. 復元後にデータベース名を変更したい場合は、SQL Server Management Studio で Azure SQL Database に接続し、オブジェクトエクスプローラーでデータベース名を右クリックして [名前の変更] を行うか、または、クエリウィンドウで ALTER DATABASE を実行します。ALTER DATABASE により変更する場合は、現在のデータベースは master を選択します。

SQL Server management Studio オブジェクトエクスプローラーを用いた方法

SQL Server Management Studio クエリウィンドウを用いた方法

※ オブジェクトエクスプローラーで [データベース] を選択して F5 キーを押下することで表示を更新することができます。

この手順は、以下にも掲載されています。

データベースの自動バックアップを使用した Azure SQL Database の復旧
- 削除されたデータベースの復元
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-recovery-using-backups

山田 浩史
Technical Advisor

普段は 10分～15分で完了する SQL Database の価格レベルの変更処理がなかなか終わらない。

なにか Azure で障害が起きているのか？もう少し待てば終わるのか？ Microsoft に問合せを上げるべきかどうか判断が出来ない。

そんな時にまずは確認したいポイントをまとめました。

前提：

SQL Database の価格レベルを変更すると、新しい価格レベルで元のデータベースのコピーが作成され、接続先がそのコピー環境に切り替えられる事があります。価格レベル変更処理の大部分が、このデータベースのコピーを作成するのにかかる時間です。価格レベル変更が早く終わるケースは、このデータコピーが行われずにリソースの割り当てが行えた場合であり、時間がかかるケースはデータコピーが行われている場合となります。

つまり、データベースサイズが大きい場合や、IO が速い Premium 以外のサービスレベルをご利用の場合は、このコピー処理に長時間かかる事があります。具体的には、250 GB のデータベースを Standard サービス レベルとの間または Standard サービス レベル内で変更する場合は、6 時間程度かかる事があります。

とは言え、あとどれくらいで処理が完了するのか目安となる時間くらいは知りたいですよね。

進捗確認方法：

master データベースにて以下クエリを実行する事で、現在の価格レベル変更の進捗状況が確認出来ます。

     select major_resource_id, operation, state_desc, start_time, percent_complete from sys.dm_operation_status;

          major_resource_id：該当の DB 名
          operation：価格レベルの変更は ALTER DATABASE
          start_time：処理開始時刻(UTC)
          percent_complete：進捗(パーセント)

出力結果例：

上記クエリを定期的に実行し percent_complete の進み具合を見て、今どれくらい進んでいて、この後どれくらい変更完了までかかりそうなのかある程度推測が出来ます。

もし、数十分経過しても percent_complete が 1 % も進まないような状況であれば、私どもサポートまでお問合せ下さい。

※ 本Blogの内容は、2018年5月 現在の内容となっております。

高原 伸城

Support Escalation Engineer

皆さん、こんにちは。 BI Data Platform サポートチームの 高原 です。

今回は、Azure SQL Database でよくある質問事項の一つである ”Action recommended: Allow outbound traffic to all Azure SQL Database routers in <データセンター>” メールの対処方法について紹介します。

Azure SQL Database を使用している方は、以下のようなメールを受領しているかもしれません。

---

Configure outbound firewall rules to include new Azure SQL Database routers in <Data Center> to avoid disruption

You’re receiving this email because you’re an Azure SQL Database customer.
We’re adding Tabular Data Stream (TDS) connection router hardware to Azure SQL Database in the East Asia region to improve connection speed and stability. As we add the new hardware, the server connections associated with the subscriptions listed at the bottom of this email may be affected if your outbound traffic is restricted.

Upgrade details
The East Asia region previously had one TDS connection router: <IP Address>. We have added a new router with IP address: <Added IP Address>. DNS records for servers in the <Data Center> region will point to one of these two IP addresses. Learn more about the IP addresses of the new router.

How this affects you
The upgrade will not affect database content or availability; however, connectivity could be disrupted if the environments from which you are connecting use outbound firewall rules. This operation might affect you if you have outbound firewall rules configured to disallow connections or traffic to the IP address of the new router, <Added IP Address> , on TCP port 1433. It will manifest in this or a similar error message:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections.

Recommended action
We recommend that you configure outbound firewall rules to allow traffic to the IP addresses of all routers (<IP Address>, <Added IP Address> ) on TCP port 1433 to avoid connectivity disruptions.
If you don’t have outbound firewall rules that disallow connections or traffic to the new router, no action is needed.

---

送付されたメールでは、アプリケーション から Azure SQL Database へ接続を確立する際、ゲートウェイ (Gateway) を経由することになるのですが、この ゲートウェイの IP アドレスが追加されたことを通知しており、IP アドレスの追加に伴い、アウトバウンド (Outbound) 側のファイア ウォール (F/W) で TCP 1433 ポートの通信を制限している場合、追加された IP アドレスに対しても ファイアウォールの設定を追加する必要がある旨が記載されています。

そのため、オンプレミス環境からインターネット回線を経由する際の アウトバウンド側のファイア ウォールで TCP 1433 ポートの通信を特定の IP アドレス のみに制限されている場合は、追加された ゲートウェイの IP アドレスを追加ください。追加しなければ、今後、アプリケーション から Azure SQL Database への接続が失敗する可能性があります。

また、Azure 仮想マシンから Azure SQL Database へ接続している場合で、かつ、送信ポートの規則で TCP 1433 ポートの通信を特定の IP アドレス のみに制限されている場合は、同様に設定を追加ください。

なお、ゲートウェイの IP アドレスは、以下の公開情報で 各データセンター毎に公開されています。

Azure SQL Database 接続アーキテクチャ

[補足]

ゲートウェイの IP アドレスは、各 Azure SQL Database サーバーに紐づいています。 例えば、東日本に作成された Azure SQL Database サーバーには、191.237.240.43 もしくは、13.78.61.196 が紐づいています。

なお、データセンター毎に割り当てられている ゲートウェイの IP アドレスが異なるため、西日本に Azure SQL Database サーバーを作成されている場合、 191.238.68.11 もしくは、 104.214.148.156 が紐づくことになります。

現在使用している Azure SQL Database サーバーで、どの ゲートウェイの IP アドレスが紐づいているかを確認したい場合は、PING コマンドを Azure SQL Database サーバーに対して実行することで、確認することが出来ます。

しかしながら、Azure SQL Database サーバーに紐づく ゲートウェイの IP アドレスを固定化することは出来ません。そのため、Reconfiguration のタイミングなどにより、紐づく ゲートウェイの IP アドレスが変わる可能性がありますので、ご注意ください。

※ 本Blogの内容は、2018年5月 現在の内容となっております。

今回の投稿は、Azure Functions で SQL Data Warehouse の価格レベルを変更する方法です。

SQL Data Warehouse の価格レベルは、Azure Portal、PowerShell、T-SQL 、REST API などいくつかの変更方法があります。

今回は、Azure Functions から REST API を使用して、SQL Data Warehouse の価格レベルをスケジュール変更する方法をご紹介します。

※ Azure Functions はサーバーレスでアプリケーションを構築するための Azure の SaaS サービスです。

■ テンプレートから作成できます！

Function App を１から作るのは大変だなぁ・・・と思う方も大丈夫です！

価格レベルをスケジュール変更するための Function App 向けのテンプレートがあります。

タイトル : Azure SQL Data Warehouse で Azure Functions を使用してコンピューティング リソースを管理します。

アドレス : https://docs.microsoft.com/ja-jp/azure/sql-data-warehouse/manage-compute-with-azure-functions

前述の通り、Function App で作成したは、サーバーレスの API として実行することが可能です。

本 Post では、指定したスケジュールで自動的に価格レベルを変更するように設定をしていますが、

工夫次第ではほかにも色々な形でシステムに取り入れることが可能になります。

■ テンプレートを使用する前に

Function App をテンプレートから作成する前に、事前に準備を行います。

まず共同作成者のアクセス権を持ったサービス プリンシパル アカウントを作成する必要があります。

具体的な手順はこちらのページに記載がありますので、

必要なアクセス許可・Azure Active Directory アプリケーションを作成する・

アプリケーション ID と認証キーを取得する ・ テナント ID を取得する・アプリケーションをロールに割り当てる

の手順でサービス プリンシパル アカウントを作成し、必要な値を控えます。

※※※ ポイント ※※※

アプリケーション ID と認証キーを取得する の 認証キーは生成後しか確認できません。

そのため、生成後に必ずコピーを控えてください。⑨ Service Principal Secret Key で入力する必要があります。

アプリケーションをロールに割り当てる の [5. アプリケーションに割り当てるロールを選択します。] では、共同作成者を選択します。

■ テンプレートを使ってみましょう！

ページ内の       を押すと、Function App のカスタム デプロイ画面に遷移します。

以下のカスタム デプロイの画面で必要な項目を入力すれば、アプリケーションの作成は完了です。

入力項目は以下のとおりです。

▶ サブスクリプション :  プルダウンのメニューからご利用のサブスクリプションを選びます。

▶ リソースグループ :  Function App で使用するリソースグループを選択します。

▶ SQL DW Resource Group :  SQL Data Warehouseのリソースグループを入力します。

▶ SQL DW Logical Server Name :  SQL Data Warehouseのサーバー名グループを入力します。

▶ SQL DW Name : SQL Data Warehouse のデータベース名を入力します。

▶ Active Directory ID : テナント ID を取得するの手順で取得します。

（３．ディレクトリ ID をコピーします。 この値がテナント ID です。の箇所）

▶ Subscription ID : ご利用のサブスクリプション ID を入力します。

▶ Service Principal Application ID : アプリケーション ID と認証キーを取得する の手順で取得します。

（２．アプリケーション ID コピーし、・・・の箇所）

▶ Service Principal Secret Key : アプリケーション ID と認証キーを取得する の手順で取得します。

（５．キーの説明を入力し、・・・の箇所）

※キーを保存すると、キーの値が表示されます。 キーは後で取得できないため、必ずコピーを控えてください。

▶ WEBSITE_TIME_ZONE : スケジュールを設定するためのタイムゾーンです。

日本時間 (JST) の場合には、Tokyo Standard Time を指定します。

▶ Scale Up Time / Scale Down Time : 任意の時間を設定します。

入力後、使用条件に同意の上、[購入] ボタンを押下します。

作成後、Azure Portal の [Function App] から作成した Function App を確認できます。

■ 変更する価格プランの指定

価格プランの変更は javascript を使用して実行します。

index.js の ServiceLevelObjective にて変更後の価格プランを指定します。

Ex) "ServiceLevelObjective": "DW100"

■ スケジュールの変更

コンピューティングレベルを変更する時間は、CRON 式 を使用して設定します。

※タイムゾーンは WEBSITE_TIME_ZONE で設定したタイムゾーンに準じます。

（今回の例は Tokyo Standard Time です。Tokyo Standard Time は UTC+9 時間の JST 時刻です。）

以下はスケールダウンをする時間を毎日 09:30 (Tokyo Standard Time) に設定する場合の入力例です。

Ex) 0 30 9 * * *

■ 実行ログの確認方法

作成した Function App のログは Storage アカウントに出力されます。

パス ： File Shares > [App Service Name] ＞ LogFile ＞ application > functions > function > DWOperationQueue

出力されたログからは以下のような内容を確認できます。

2018-06-**T00:30:00.315 [Info] Function started (Id=****************************)

2018-06-**T00:30:06.772 [Info] JavaScript queue trigger function processed work item { operationType: 'ScaleDw', ServiceLevelObjective: 'DW100' }

2018-06-**T00:30:06.772 [Info] Operation request for: ScaleDw with scale value: DW100

2018-06-**T00:30:06.772 [Info] Retrieving authorization token for REST command

2018-06-**T00:30:06.804 [Info] Function completed (Success, Id=****************************), Duration=6489ms)

いかがでしたでしょうか。

ぜひサーバーレスの Azure Functions を使用して、価格プランの変更を試してみてください。

本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

今回の投稿では、SQL Server 2016 以降、かつ、Enterprise/Developer Edition 以外の Edition の Reporting Services に対するレポートサーバーデータベース移行時に発生する可能性がある現象とその対処策についてご案内します。

■ Reporting Services のレポートサーバーデータベースの移行方法について

Reporting Services が利用するレポートサーバーデータベース（既定では ReportServer, ReportServerTempDB) を移行し、別インスタンスの Reporting Services で利用する場合、移行元のレポートサーバーデータベースのバックアップを採取し、移行先の Reporting Services が参照する SQL Server インスタンスに復元します。その後、移行先の Reporting Services 構成マネージャにて、復元したレポートサーバーデータベースを使用するように指定することで、レポートサーバーデータベースの設定が完了します。

なお、上記手順によって、移行先のレポートサーバーデータベース内には、移行元のサーバー情報と移行先のサーバー情報が登録された状態となります。

この状態は、 Reporting Services のレポートサーバーデータベースの内部では、スケールアウト構成を実施した状態と同様の構成となります。

スケールアウト構成は、Enterprise/Developer Edition のみで利用可能な構成であるため、これら以外の Edition を利用している場合、 rskeymgmt を利用して、移行元のサーバー情報を削除する必要があります。

rskeymgmt による削除方法は下記の通りです。

1. 管理者として実行でコマンドプロンプトを開きます。

2. 下記のコマンドを実行し、移行元のサーバーが利用している installation-id を確認します。

 rskeymgmt -l

実行例)

C:\windows\system32>rskeymgmt -l

Server01\MSSQLSERVER - 1f8d21c3-f828-4f18-ab4e-f2e355491b9e

The command completed successfully

3. 下記のコマンドを実行し、移行元のサーバー情報を削除します。

 rskeymgmt -r <installation-id>

実行例)

C:\windows\system32>rskeymgmt -r 1f8d21c3-f828-4f18-ab4e-f2e355491b9e

Are you sure you want to delete this key? Yes (Y)/ No (N): Y

The command completed successfully

■ SQL Server 2016 以降における rskeymgmt の実行について

SQL Server 2016 以降、かつ、Enterprise/Developer Edition 以外の Edition の Reporting Services に対して、上記 rskeymgmt によるコマンドを実行すると下記のエラーが発生します。

The feature: “Scale-out deployment” is not supported in this edition of Reporting Services (rsOperationNotSupported)

（日本語版: このエディションの Reporting Services では、機能 "スケールアウト配置" はサポートされていません。）

■ 対処策について

本動作は SQL Server の問題であるため、現在、本問題の修正について検討が為されておりますが、現時点における修正予定は未定となります。

このため、下記の手順により問題に対処ください。本対処策の実行により Reporting Services の動作に影響を与えることはございませんので、ご安心ください。

1. SQL Server Management Studio から、移行先のレポートサーバーデータベースを復元した SQL Server データベースエンジン インスタンスに接続します。

2. ReportServer データベースをカレントとし、下記のクエリを実行します。

#<移行元のサーバー名> は移行元のサーバー名を入力してください。

USE ReportServer

GO

-- まずは下記コマンドを実行します。

BEGIN TRANSACTION

DELETE FROM Keys WHERE MachineName='<移行元のサーバー名>'

-- (1 行処理されました) と結果表示され、1行のみ削除されたことを確認します。

-- 問題なければ、下記のようにコミットします。

COMMIT TRANSACTION

-- 0件、もしくは2件以上削除された場合には、下記のようにロールバックします。

ROLLBACK TRANSACTION

今回の投稿では、SQL Server 2016 Reporting Services の環境において、サブスクリプション設定画面を参照した際に記録されるエラーについてご案内します。

■現象
Web ポータルサイトより、任意のレポートの管理画面からサブスクリプションページを開くと、Reporting Services のログへエラーが記録されます。

1) Web ポータルサイトから管理画面 - サブスクリプション設定画面を開きます。

2) reportserverservice_ymd.log から次のエラーの出力を確認できます。

【ファイルパス(既定の場合)】
C:\Program Files\Microsoft SQL Server\MSRS13.MSSQLSERVER\Reporting Services\LogFiles\reportserverservice_ymd.log

【出力内容】
library!ReportServer_0-1!c08!08/09/2018-20:55:55:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.NotEnabledException: , Microsoft.ReportingServices.Diagnostics.Utilities.NotEnabledException: The requested functionality is not currently enabled.;
extensionfactory!ReportServer_0-1!c08!08/09/2018-20:55:55:: i INFO: Skipped instantiating Report Server PowerBI report server extension. Extension was not enabled.
library!ReportServer_0-1!c08!08/09/2018-20:55:55:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.OperationNotSupportedNativeModeException: , Microsoft.ReportingServices.Diagnostics.Utilities.OperationNotSupportedNativeModeException: This operation is not supported on a report server that runs in native mode.;
library!ReportServer_0-1!c08!08/09/2018-20:55:55:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: Email Provider has no server or pickup directory specified, Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: The report server has encountered a configuration error. ;
extensionfactory!ReportServer_0-1!c08!08/09/2018-20:55:55:: e ERROR: Exception caught instantiating Report Server Email report server extension: Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: The report server has encountered a configuration error. .

■原因　
大変申し訳ございませんが、原因については判明しておりません。

■対処
このエラーによるReporting Services への影響は特にありませんので、無視頂きますようお願いします。

■修正状況
現在このエラーに対する修正は予定されておりません。修正が為された際には本ブログをアップデートさせて頂きます。

今回の投稿では、SQL Server 2016 SP2に Reporting Services をインストールしている環境において、累積的な更新プログラムのCU1、並びに、CU2 を適用した際に発生する問題と、この修正状況についてご案内します。

■現象
SQL Server 2016 SP2 環境にて、CU1(*1)、または、CU2(*2) を適用することで以下問題が発生する報告を確認しています。

・CPU 使用率が大幅に増加する
・Web ポータル (http://<サーバー名>/reports) サイトが閲覧できなくなる

(*1) Cumulative Update 1 for SQL Server 2016 SP2
https://support.microsoft.com/en-us/help/4135048/cumulative-update-1-for-sql-server-2016-sp2
(*2) Cumulative Update 2 for SQL Server 2016 SP2
https://support.microsoft.com/en-us/help/4340355/cumulative-update-2-for-sql-server-2016-sp2

■原因　
内部コードの問題により発生しておりました。このコードの内容については非公開とさせていただいております。

■回避策
既にインストールされているCU1、またはCU2 をアンインストールします。
コントロールパネル - プログラムと機能 - 更新プログラムのアンインストール からアンインストールが可能です。

■修正状況
現在、SQL Server SP2 CU に対する更新プログラムの改修が進められています。
既にCU1、並びに、CU2 がインストールされている場合には、本更新プログラムを適用することで事象が改善される見込みです。
詳細な修正状況につきましては、以下ブログより追跡できます。

Issue with security update for the Remote Code Execution vulnerability in SQL Server 2016 SP2 (CU): August 14, 2018
https://blogs.msdn.microsoft.com/sqlreleaseservices/issue-with-security-update-for-the-remote-code-execution-vulnerability-in-sql-server-2016-sp2-cu-august-14-2018/

なお、本更新プログラムの内容は、次期CU (CU3) にも含まれる予定です。

※Update
SQL Server SP2 CU に対する更新プログラム(KB4458621)が公開されました。

SQL Server 2016 SP2 のリモートでコードが実行される脆弱性のセキュリティ更新プログラム (CU) について: 2018 年 8 月 20 日
https://support.microsoft.com/ja-jp/help/4458621/description-of-the-security-update-for-the-remote-code-execution

今回の投稿では、SQL Server 2016 Reporting Services、並びに、SQL Server 2017 Reporting Services の環境において、Web ポータルからファイルダウンロード時、ファイル名の日本語文字が文字化けする事象についてご案内します。

■現象
Internet Explorer ブラウザにて、Web ポータルからファイルダウンロード時、ファイル名に日本語文字が含まれる場合、ファイル名が文字化けする事象を確認しております。

1) Web ポータルから、ファイル名に日本語文字(2byte文字) が含まれるファイルをダウンロードします。
2) ファイル名が文字化けされた状態でダウンロードされます。
元のファイル名：レポートテスト.xlsx
ダウンロード後のファイル名：=_utf-8_B_44Os44Od44O844OI44OG44K544OILnhsc3g=_=

■回避策
残念ながら、現時点で本現象の修正は予定されておりません。このため、下記いずれかの回避策の適用をご検討ください。

A. シングルバイトの文字で命名したファイルをアップロードする
B. ダウンロード後にファイル名を手動で変更する
C. ファイルダウンロード操作は、Chrome など事象が発生しない別のブラウザを使用する（※Chrome の場合には事象が発生しないことを確認しております）
D. Web サービスからダウンロードする
Web サービスよりダウンロードする場合には、文字化けが発生しないことを確認しています。
Excel ファイルやテキストファイルなど、Web サービスからダウンロード可能なファイルにつきましては本回避策は有効となります。
例えば、レポート定義ファイル(*.rdl) はWeb サービスよりダウンロードできないため、この場合は上記A. ～ C. の回避策にて対処する必要があります。

松本 奈紗

Support Engineer

皆さん、こんにちは。 BI Data Platform サポートチームの松本奈紗です。
今回の投稿では、Azure Data Factoryを利用してAzure SQL DataWarehouse にデータをコピーする際に発生するエラーのうち、メッセージから判断がつきにくいものがありますので、エラーの原因を見つけるために確認すべき点をご紹介いたします。
また、今回はイメージがつきやすいように、以下のようなサンプルを用いて、エラーの対処策をご紹介いたします。

[サンプルの前提]

Azure Data Factoryを利用して、CSVファイルをSQL Server Management Studio(SSMS) に接続されたAzure DataWarehouse へコピーします。

Test.csv

Number, Word, Letter
1, test1, A
2, test2, B

Azure SQL Data Warehouse

SSMSでのテーブル定義

CREATE TABLE dbo.TestTable(
Number int NULL
,Word char(1) NULL
,Letter char(1) NULL
);

[テスト]
上記のような前提でAzure Data Factory (V2)からデータをSQL Data Warehouseにロードしてみると、同じエラーが確認できるかと思います。

■エラーの確認方法
Azure Data Factory (V2)を利用して発生したエラーを確認する場合、パイプラインのモニター画面を確認ください。

• ADFのモニター画面からエラーの詳細画面を開きます。

• 以下のエラーの出力を確認できます。

Error Message

Activity Copy_5ua failed: ErrorCode=FailedDbOperation、'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=次のエラーにより、データベースの操作が失敗しました: 'PdwManagedToNativeInteropException ErrorNumber: 46724, MajorCode: 467, MinorCode: 24, Severity: 20, State: 2, Exception of type 'Microsoft.SqlServer.DataWarehouse.Tds.PdwManagedToNativeInteropException' was thrown.',Source=,''Type=System.Data.SqlClient.SqlException,Message=PdwManagedToNativeInteropException ErrorNumber: 46724, MajorCode: 467, MinorCode: 24, Severity: 20, State: 2, Exception of type 'Microsoft.SqlServer.DataWarehouse.Tds.PdwManagedToNativeInteropException' was thrown.,Source=.Net SqlClient Data Provider,SqlErrorNumber=100000,Class=16,ErrorCode=-2146232060,State=1,Errors=[{Class=16,Number=100000,State=1,Message=PdwManagedToNativeInteropException ErrorNumber: 46724, MajorCode: 467, MinorCode: 24, Severity: 20, State: 2, Exception of type 'Microsoft.SqlServer.DataWarehouse.Tds.PdwManagedToNativeInteropException' was thrown.,},],'

■上記エラーメッセージが発生する可能性と対処策

上記のようなエラーが発生した場合、出力先であるSQL Data Warehouseのテーブルのデータ長が、Azure Data Factory(V2) から受け渡されるデータと合わない(受け側のサイズが不足している)可能性がないかを確認してみてください。

この場合、SQL Data Warehouseのテーブルのデータ長とAzure Data Factory(V2) から受け渡されるデータ長を確認し、これらのデータ長を合わせることで、エラーに対処できます。

今回のサンプルの場合、ADF側では、以下のようにSSMSを使用してSQL Data Warehouseのテーブルのデータ長を確認し、データ長を修正することでエラーに対処できます。

• SSMSにおいて、SQL Data WarehouseのTestTableのWordカラムがchar(1)となっていることを確認できます。

char(1)は1バイトの文字を格納することを想定した型であり、Azure Data Factory(V2) から受け渡されるCSVファイルのWordカラムのデータは”test1”,”test2”のように1バイトではないため、データサイズが不足していることが確認できます。

• ここで、次のクエリを実行し、SSMSに再接続すると、以下のようにTestTableのWordカラムがchar(255)となっていることが確認できます。

“ALTER TABLE dbo.TestTable ALTER COLUMN Word char(255) NULL ;”

char(255)型は255バイト分の文字コードを格納できますので、CSVファイルのWordカラムのデータは”test1”,”test2”と255バイト以内であるため、データ長は足りていることが確認できます。

• Data Factoryのパイプラインをもう一度実行すると、モニター画面のStatus欄にSucceedが表示され、エラーが解消されたことが確認できます。

松本 奈紗 Support Engineer

• JSON ファイル自体のフォーマットが正しいかどうか
• 入力データ形式とイベントシリアル化形式の設定(JSON/Avro/CSV)の設定が正しい(両者が一致しているか)かどうか

本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

• プライマリ可用性グループ のプライマリ レプリカ (グローバル プライマリとも呼ばれます)が、データベース ミラーリング エンドポイントを通して、セカンダリ可用性グループのフォワーダー レプリカと正常に同期している。
• セカンダリ可用性グループのフォワーダー レプリカが、データベース ミラーリング エンドポイントを通して、セカンダリ可用性グループのセカンダリ レプリカと正常に同期している。

1. 現在の truncation_lsn と last_hardend_lsn を各レプリカで記録します。
2. データベースに変更を加えます。ここでは test データベースに INSERT 文を10回発行します。
3. 各レプリカにて LSN が同じ分だけ進む事を確認します。
4. トランザクションログのバックアップを、グローバルプライマリの test データベースにて取得します。
5. 現在の truncation_lsn と last_hardend_lsn の確認をします。
6. セカンダリAG のセカンダリレプリカへのデータ移動を中断します。
7. 2-5 を繰り返します。