Microsoft SQL Server Japan Support Team Blog https://docs.microsoft.com/archive/blogs/jpsql/feed.xml Microsoft SQL Server Support チームのブログです。 Thu, 14 Mar 2019 00:22:20 GMT ja hourly 1 分散型可用性グループのフェールオーバーについて https://docs.microsoft.com/archive/blogs/jpsql/distributedavailabilitygroup Thu, 14 Mar 2019 09:20:00 GMT https://blogs.msdn.microsoft.com/jpsql/?p=13515 Replica Failover within the Secondary Availability Group in a Distributed Availability Group の翻訳です。 --------------- 分散型可用性グループ (distributed AG) は、特別な可用性グループであり、2つの可用性グループにまたがっています。このブログでは、分散型可用性グループのフェールオーバーについての問題を説明します。特に可用性グループ間の同期状態にかかわらず、分散型可用性グループのデータ損失への耐性をご紹介します。 検証のために、シンプルな分散型可用性グループ 'TIWENDAG' を作成します。 'TIWENDAG' の構成は次の図のとおりです。 'TIWENAG1' が分散型可用性グループ 'TIWENDAG' のプライマリ可用性グループで、'TIWENVM1' がプライマリ レプリカ、'TIWENVM2' がセカンダリレプリカです。'TIWENAG2' が分散型可用性グループ 'TIWENDAG' のセカンダリ可用性グループで、'TIWENVM3' がプライマリ レプリカ、'TIWENVM4' がセカンダリレプリカです。 分散型可用性グループで定義されている、2つの可用性グループの自動フェールオーバーはサポートされています。例えば、可用性グループ TIWENAG1 でフェールオーバーモードが "自動" で設定されていると、TIWENAG1 がダウンした際にはTIWENAG1 (プライマリ) と TIWENAG2 (同期セカンダリ) 間で自動フェールオーバーが発生します。同様に、可用性グループ TIWENAG2 でTIWENVM3 (プライマリ) がダウンした場合には、TIWENVM4 (同期セカンダリ) に自動的にフェールオーバーされます。   可用性グループのプライマリ レプリカがダウンした際、プライマリ レプリカ (可用性グループが分散型可用性グループの一部かどうかにかかわらず) は同期セカンダリ レプリカに自動的にフェールオーバーされます。   もしセカンダリ可用性グループ (フォワーダーとも呼ばれます) のプライマリ レプリカが失われて自動フェールオーバーが発生した場合や、分散型可用性グループのセカンダリ可用性グループで手動フェールオーバーが行われた場合、次の条件を満たしていれば、データ損失は発生しません。  
  • プライマリ可用性グループ のプライマリ レプリカ (グローバル プライマリとも呼ばれます)が、データベース ミラーリング エンドポイントを通して、セカンダリ可用性グループのフォワーダー レプリカと正常に同期している。
  • セカンダリ可用性グループのフォワーダー レプリカが、データベース ミラーリング エンドポイントを通して、セカンダリ可用性グループのセカンダリ レプリカと正常に同期している。
  グローバルプライマリ“TIWENVM1" に最後に書き込まれた LSN (last_hardend_lsn) が 10:15:1 と仮定します。プライマリAG のセカンダリレプリカ “TIWENVM2” は同期されており、最後に書き込まれた LSN  (last_hardend_lsn) は 10:15:1 です。セカンダリAG に関しては、プライマリAG とフォワーダーの間の同期モードは非同期コミットモードで、フォワーダー “TIWENVM3” の最後に書き込まれた LSN (last_hardend_lsn) は 10:12:1 です。セカンダリAG のセカンダリレプリカ “TIWENVM4” は、まだ同期されていないため最後に書き込まれた LSN (last_hardend_lsn) は 10:10:1 です。この分散型可用性グループ内では、 “TIWENVM4”  が最後に書き込まれたLSN として最も低い値を持っています。また、この時グローバルプライマリのトランケート LSN (truncation_lsn) は 10:10:1 を下回りません。これは、“TIWENVM3” が失われたとき、“TIWENVM4” が新しいフォワーダーとなりプライマリAG と同期出来るようにするためです。 この理由は、トランザクションログのバックアップが取られたとき、分散型可用性グループ内のすべてのレプリカ(プライマリAG,セカンダリAG 両方のレプリカ)に適用済みのトランザクションログのみが切り捨てられるからです。以下のテスト結果が、本記事の冒頭にて説明したテスト環境の分散型可用性グループにて、トランザクションログがどのように切り捨てられるかの例になります。 このシナリオは、以下手順にて簡単に証明出来ます。  
  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 を繰り返します。
   以下スクリーンショットがこの再現テストシナリオのすべての結果です。 Step1 - この Step で使用した DMV: USE test SELECT COUNT(*) AS '# of transaction logs' FROM fn_dblog(null, null) SELECT database_id, group_id, replica_id, is_local, is_primary_replica, truncation_lsn, last_hardened_lsn FROM sys.dm_hadr_database_replica_states WHERE database_id=6 AND is_local=1 SELECT replica_id, replica_server_name FROM sys.availability_replicas WHERE replica_id= (SELECT replica_id FROM sys.dm_hadr_database_replica_states WHERE database_id=6 AND is_local=1) SELECT COUNT(*) AS '# of entries in testt1 table' FROM testt1 4つのレプリカでの結果 : プライマリAG のプライマリレプリカ (グローバルプライマリ): プライマリAG のセカンダリレプリカ: セカンダリAG のプライマリレプリカ (フォワーダー): セカンダリAG のセカンダリレプリカ: このテスト環境のように、すべてのレプリカが同期されている場合、上記スクリーンショットのように、すべてのレプリカは同じ数のトランザクションログと truncation_lsn を返します。 Step 2 - INSERT 文を10回実行します。 INSERT INTO testt1 (NAME, ID) VALUES ('John Smith', 1) GO Step 3 - プライマリAG のプライマリレプリカ (グローバルプライマリ): プライマリAG のセカンダリレプリカ: セカンダリAG のプライマリレプリカ (フォワーダー): セカンダリAG のセカンダリレプリカ: トランザクションログのサイズがINSET 文の実行により大きくなります。test データベースで内のエントリーの数も 10行分増加しています。 Step 4 - グローバルプライマリにてトランザクションログのバックアップを取得します。 Step 5 - プライマリAG のプライマリレプリカ (グローバルプライマリ): プライマリAG のセカンダリレプリカ: セカンダリAG のプライマリレプリカ (フォワーダー): セカンダリAG のセカンダリレプリカ: 各レプリカの truncation_lsn が現在の LSN まで増加し、トランザクションログも切り捨てられるため、トランザクションログは圧縮されます。  Step 6 - セカンダリ AG のセカンダリレプリカにある test データベースへのデータ移動を中断します。 Step 7 - Step 2 と Step3 を繰り返したのちに、セカンダリ AG のセカンダリレプリカ (TIWENVM4) 以外のすべてのレプリカの test データベースのデータは もう10行 insert されたデータの分だけ更新されています。セカンダリAG のセカンダリレプリカに存在するデータベースのデータは、データ移動が中断されているため、同期されていません。 プライマリAG のプライマリレプリカ (グローバルプライマリ): プライマリAG のセカンダリレプリカ: セカンダリAG のプライマリレプリカ (フォワーダー): セカンダリAG のセカンダリレプリカ: Step4と Step5 を繰り返したあとの結果は以下です。 プライマリAG のプライマリレプリカ (グローバルプライマリ): プライマリAG のセカンダリレプリカ: セカンダリAG のプライマリレプリカ (フォワーダー): セカンダリAG のセカンダリレプリカ: 新しく生成されたトランザクションログは、プライマリAG のセカンダリレプリカでは切り捨てられています。しかしながら、プライマリAGのプライマリレプリカでは truncation_lsn は、10行のInsert とトランザクションログのバックアップによって変化していません。前述した通り、これはセカンダリAG のセカンダリレプリカ"TIWENVM4" が同期されておらず、Insert クエリによって生成されたトランザクションログが適用されていないからです。 分散型可用性グループのグローバルプライマリでは、分散型可用性グループに参加するすべてのレプリカ内で一番古い LSN までしかトランザクションログを切り捨てません、このロジックにより、フォワーダーとセカンダリAGのセカンダリレプリカが完全に同期されていない状況下において、フォーワーダーが消失した場合でも、グローバルプライマリが健全な状態であり、またセカンダリAGのセカンダリレプリカと通信が出来ていれば、データロスがない事を保証しています。 上記シナリオをシミュレーションするために、セカンダリAG のプライマリレプリカ(TIWENVM3) のネットワークを遮断します。これにより、セカンダリAG のセカンダリレプリカ (TIWENVM4)のデータ移動を再開する前に TIWENVM3 が使用不可になります。 TIWENVM4 上の test データベースのデータ移動を再開させると、セカンダリAG TIWENAG2は、解決中のステータスになります。これは、セカンダリAG TIWENAG2 上のプライマリレプリカ TIWENVM3 と通信が出来ないためです。これを解消するには、フェールオーバーをする必要があります。分散型可用性グループのセカンダリAGのフォワーダーが使用可能でない場合、セカンダリAGのセカンダリレプリカにて実行可能なフェールオーバーオプションは FORCE_FAILOVER_ALLOW_DATA_LOSS のみです。   ALTER AVAILABILITY GROUP TIWENAG2 FORCE_FAILOVER_ALLOW_DATA_LOSS   セカンダリAG のセカンダリレプリカ TIWENVM4 にて FORCE_FAILOVER_ALLOW_DATA_LOSS オプションにてフェールオーバーを実行した後、以前のフォワーダーが使用不可な状況においてもデータベースの同期は行われます。これは、グローバルプライマリがセカンダリAG上のセカンダリレプリカのトランザクションログの同期されていない分を管理しているからです。 このシナリオでは、 FORCE_FAILOVER_ALLOW_DATA_LOSS オプションをつけてフェールオーバーではあるものの、データ損失は発生しません。 一つ注意したいのは、FORCE_FAILOVER_ALLOW_DATA_LOSS 後に以前のプライマリレプリカ(TIWENVM3) が復旧した場合、データ移動は自動的に再開されないため、手動でデータ移動を再開させる必要があります。この動作は、分散型可用性グループに限らず、一般的な可用性グループにて FORCE_FAILOVER_ALLOW_DATA_LOSS  が行われた場合の仕様となります。これは、以前のプライマリレプリカと現在のプライマリレプリカにてデータの差異や競合が発生する可能性があり、ユーザーが自身でどのデータが適切か判断する必要があるからです。 TIWENVM3 のデータ移動を再開させたあと、分散型可用性グループ内のすべてのレプリカは同期がされ、トランザクションログの切り捨ても同じ時点まで行われます。 プライマリAG のプライマリレプリカ (グローバルプライマリ): プライマリAG のセカンダリレプリカ: (New) セカンダリAG のセカンダリレプリカ: (元フォワーダー): (New) セカンダリAG のプライマリレプリカ (新フォワーダー): 今回のシナリオでは FORCE_FAILOVER_ALLOW_DATA_LOSS  にてフェールオーバーをしデータ損失はありませんでしたが、これは必ずしも分散型可用性グループにてこのオプションを使用した場合にデータ損失がないわけではありません。例えば、プライマリAG が損失した場合、セカンダリAG にて強制フェールオーバーを行う場合は、データ損失が発生する可能性があります。またこの例に限らずデータ損失が発生する可能性がある点についても注意が必要です。]]> BCP Queryout で処理が二重実行される https://docs.microsoft.com/archive/blogs/jpsql/bcp-queryout-twice Mon, 03 Dec 2018 13:26:46 GMT https://blogs.msdn.microsoft.com/jpsql/?p=13455 ユーティリティの queryout オプションを使用した場合の不具合に関する報告です。   事象概要 bcp ユーティリティの queryout オプションを使用した場合、予期せずクエリが 2 回実行される場合があります。   bcp ユーティリティの queryout オプションを使用してコマンドを実行する際、フォーマットファイルを使用することで、 インポート先のテーブルのスキーマとテーブル列のデータ型に準拠して、一括インポートすることができます。   しかしながら、フォーマットファイルでテーブルの各列の照合順序を指定した場合、 フォーマットファイルで指定した照合順序の確認を行う内部動作に起因して、予期せずクエリが 2 回実行される場合があります。 なお 1 回目のクエリ実行後、Attention が記録される場合もありますが、 Attention が記録されず、クエリが 2 回実行される場合もあります。   回避方法 本動作はフォーマットファイルで照合順序を指定して、bcp ユーティリティの queryout オプションを実行した場合に発生することを確認しています。またフォーマットファイルで照合順序を指定しない場合、事象が回避できます。   以下の参考情報の通り、一般的にはフォーマットファイルを使用して、照合順序を明示的に指定することを推奨しておりますが、 本不具合が発生した場合には。フォーマットファイルで照合順序を指定せずに、queryout オプションを実行してください。 なお、フォーマットファイルで照合順序を指定しない場合、インポート先の既定の照合順序に従ってインポートが行われます。   参考情報 bcp ユーティリティ https://docs.microsoft.com/ja-jp/sql/tools/bcp-utility?view=sql-server-2017  
本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。
]]> [SSRS] Windows 10 におけるレポート表示時に文字化けが発生する。 https://docs.microsoft.com/archive/blogs/jpsql/ssrs-windows-10-garbled-characters Wed, 21 Nov 2018 11:00:43 GMT https://blogs.msdn.microsoft.com/jpsql/?p=13425 Windows 10 の環境において、レポートで利用するフォントに依存した文字化けの現象についてご案内します。   ■現象 Windows 10 上にて、Report Builder などを利用し、レポートを作成する際に特定のフォントを利用すると、日本語（漢字）の表示が文字化けします。 Windows 10 以外の OS にて、同様のレポートを作成した場合、本現象は発生しません。 この現象は、 Windows 10 において、フォールバックフォント (この度のように英字用のフォントで漢字表示をする際にも判読可能なように常に表示されるように設計されたフォント) が既定ではインストールされていないことに起因して発生しています。 また、この現象は、過去に作成したレポートをアップグレードする際に、新しく Windows 10 を含めた複数の OS でレポートを参照する要件が発生した場合などに生じやすい現象となります。 ■回避策 次のいずれかの回避策が有効です。 Windows 10 に「繁体字中国語補助フォント」のフォールバックフォントをインストールする。 個々のレポート毎の対応でなく、一括で対応が可能な対処策となります。 次の手順でフォントをインストールできます。 フォントインストール手順 ----------------------------------------------------- 1.　[スタート] メニューの [設定] を開きます。 2.　設定の検索で、「アプリと機能」を検索します。 3.　[アプリと機能] を選択します。 4.　[オプション機能の管理] を選択します。 5.　[機能の追加] を選択します。一覧から 繁体字中国語補助フォントをインストールします。 レポートの構造を変更する。 Windows 10 においても文字化けしないフォントを利用しレポートを構成します。 大変残念ながら、文字化けが発生しているレポートの改修は、個々のレポート毎にフォントの変更が必要となります。一括での修正はできませんのでご注意ください。 例えば、MSP ゴシックや MSP 明朝などのフォントを検討します。   ※2018/11/30 追記 Windows Update サイトに直接接続できない環境(WSUS や SCCM 管理環境)では "インストールする機能がありません" と表示されフォントをインストールできない場合があります。その場合は、「レポートの構造を変更する。」の対処を実施してください。]]> [Stream Analytics] 不正な JSON 形式を送った場合に発生するエラーについて https://docs.microsoft.com/archive/blogs/jpsql/stream-analytics-%E4%B8%8D%E6%AD%A3%E3%81%AA-json-%E5%BD%A2%E5%BC%8F%E3%82%92%E9%80%81%E3%81%A3%E3%81%9F%E5%A0%B4%E5%90%88%E3%81%AB%E7%99%BA%E7%94%9F%E3%81%99%E3%82%8B%E3%82%A8%E3%83%A9%E3%83%BC Fri, 14 Sep 2018 19:20:02 GMT https://blogs.msdn.microsoft.com/jpsql/?p=13395 松本 奈紗 Support Engineer

  皆さん、こんにちは。 BI Data Platform サポートチームの松本奈紗です。 今回の投稿では、Stream Analyticsの環境において、上手くストリーミングデータが出力に受け渡されない場合、参考となる情報をご紹介いたします。 日々、弊社には多くのお問い合わせを頂くわけですが、その中でも Stream Analytics で以下のようなエラーが発生した、といったご相談をしばしばいただきます。   エラーメッセージ Could not deserialize the input event(s) from resource 'xxxxx' as Json. Some possible reasons: 1) Malformed events 2) Input source configured with incorrect serialization format   このメッセージだけですとやはり、何が問題か判断がつきにくいもあると思いますので、今回の投稿ではこの点についてフォーカスしてみたいと思います。 結論から申し上げますと、このエラーはStream Analyticsの環境において、上手くストリーミングデータが出力に受け渡されない事を意味しています。 考えられる原因として、不正な JSON 形式が送付されている可能性が高いため、インプットとなるデータの精査が必要になります。 下記情報と共に、事象の切り分けにあたって少しでも参考となりましたら幸いです。   参考情報『間違った形式の入力イベントをトラブルシューティングする』 https://docs.microsoft.com/ja-jp/azure/stream-analytics/stream-analytics-common-troubleshooting-issues#troubleshoot-malformed-input-events   ■現象 以下のようにStream Analyticsのジョブトポロジの「入力」の「ストリーム入力の追加」においてイベントシリアル化形式としてJSONを選択した場合を想定します。 例えば以下のようなJSONとして正しくないもの(項目"is_event_logged"に値が存在しない)が来たと想定します。 例) 　{ "message_id": 18456, "language_id": 1033, "severity": 14, "is_event_logged": , "text": "Login failed for user '%.*ls'.%.*ls%.*ls" }   JSONの正しいとはなんであるか、は規格の説明になるので今回は割愛しますが、上記については少なくとも値が入っているところに値がない事で不正なJSONといえます。 では、上記の意図的に不正にした JSON ファイルを元にStream Analyticsを利用して、不正な JSON 形式を送ってみましょう。 Stream Analytics ジョブを開始後、しばらくすると、入力の右側のオレンジ色のアラートマークが表示され、それをクリックすると以下のエラーが表示されます。   エラーメッセージ Could not deserialize the input event(s) from resource 'xxxxx' as Json. Some possible reasons: 1) Malformed events 2) Input source configured with incorrect serialization format   ■原因 このエラーは Stream Analytics 側で入力データ形式が不正な形式であるときにエラーが発生します。 JSON形式で来たものの、JSONとして正しくない形式で来ている場合や、JSONをInputと指定しながらも、実際にはファイルがCSVで配置された場合などもこのエラーになりえます。   ■対処策 いずれにしても Stream Analytics としてはインプットデータを正しく評価できない事で問題が発生しています。 以下のような点がないかを確認頂く事になります。
  • JSON ファイル自体のフォーマットが正しいかどうか
  • 入力データ形式とイベントシリアル化形式の設定(JSON/Avro/CSV)の設定が正しい(両者が一致しているか)かどうか
なお、EventHub などが Input データになる場合、BLOB Input のように単純に中身を開いてみるといった事はできません。 その場合には下記ドキュメントに存在している CheckMalformedEvents.cs などを利用し、Input 側のデータを確認していただく必要があります。 参考情報『間違った形式の入力イベントをトラブルシューティングする』 https://docs.microsoft.com/ja-jp/azure/stream-analytics/stream-analytics-common-troubleshooting-issues#troubleshoot-malformed-input-events  ]]> [ADF] Azure SQL DataWarehouseにデータをコピーする際に発生するエラーについて https://docs.microsoft.com/archive/blogs/jpsql/adf-azure-sql-datawarehouse%E3%81%AB%E3%83%87%E3%83%BC%E3%82%BF%E3%82%92%E3%82%B3%E3%83%94%E3%83%BC%E3%81%99%E3%82%8B%E9%9A%9B%E3%81%AB%E7%99%BA%E7%94%9F%E3%81%99%E3%82%8B%E3%82%A8%E3%83%A9%E3%83%BC Fri, 14 Sep 2018 16:32:13 GMT https://blogs.msdn.microsoft.com/jpsql/?p=13335 松本 奈紗

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が表示され、エラーが解消されたことが確認できます。
     ]]> [SSRS] Web ポータルからファイルダウンロード時のファイル名文字化けについて https://docs.microsoft.com/archive/blogs/jpsql/ssrs-filedownload-of-webportal Wed, 05 Sep 2018 19:33:49 GMT https://blogs.msdn.microsoft.com/jpsql/?p=13305

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

 ]]> [SSRS] SQL Server 2016 SP2 Cumulative Update 適用による不具合について https://docs.microsoft.com/archive/blogs/jpsql/ssrs2016-problem-of-sp2cu1cu2 Mon, 03 Sep 2018 19:28:40 GMT https://blogs.msdn.microsoft.com/jpsql/?p=13285 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]]> [SSRS] サブスクリプション設定画面参照時に記録されるエラーについて https://docs.microsoft.com/archive/blogs/jpsql/ssrs-configuration-of-subscription Mon, 03 Sep 2018 16:43:49 GMT https://blogs.msdn.microsoft.com/jpsql/?p=13255

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 への影響は特にありませんので、無視頂きますようお願いします。 ■修正状況 現在このエラーに対する修正は予定されておりません。修正が為された際には本ブログをアップデートさせて頂きます。]]> [SSRS] レポートサーバーデータベース移行時のキー情報の削除方法について https://docs.microsoft.com/archive/blogs/jpsql/move-reportserver_database_rskeymgmt-error Tue, 24 Jul 2018 12:09:17 GMT https://blogs.msdn.microsoft.com/jpsql/?p=13165 今回の投稿では、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  
]]> Azure Functions で SQL Data Warehouse の価格レベルを変更する https://docs.microsoft.com/archive/blogs/jpsql/azure-functions-sql-data-warehouse-slo-change Wed, 13 Jun 2018 12:54:05 GMT https://blogs.msdn.microsoft.com/jpsql/?p=13055
今回の投稿は、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のサーバー名を入力します。
（Server.database.windows.net であれば、Server 部分のみでよい）
▶ 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 を使用して、価格プランの変更を試してみてください。  

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

 ]]>