SQL Server 2016 [新機能] 動的なデータマスキングでクエリの変更が必要な場面は?

  みなさん、こんにちは。 Microsoft SQL Server/Microsoft Azure SQL Database サポートチーム です。 SQL Server 2016 から動的なデータマスキングの機能が加わりました。 動的なデータマスキングの特徴として、クエリの結果に対してマスクが適用されるため、アプリケーション側でのクエリの変更が不要な場合が多い点にあります。   動的なデータ マスキング https://msdn.microsoft.com/ja-jp/library/mt130841.aspx 動的データマスクは、クエリの結果にマスク ルールが適用されるため、既存のアプリケーションで簡単に使用できます。 多くのアプリケーションは、既存のクエリを変更せずに、デリケートなデータをマスクすることができます。     一方で意図した結果にならないということでお問い合わせを頂くケースも出てきました。 ここではアプリケーション側でのクエリの変更が必要な場面の例をご紹介したいと思います。 いずれも仕様に沿った結果ではありますが、ご参考頂ければ幸いです。   変更が必要な場面 カーソルで取得した値がマスクされる前の値であることを前提としている実装 カーソルで取得した値は既にマスクされているため、マスクされた後の値であることを前提とした実装に変更する必要があります。 取得した値をクエリ内で置き換えた場合 置き換えた値もマスク対象となるため、マスクされた値であることを前提とした実装が必要です。   以下は、上記の具体例です。 前準備   ※公開情報で紹介しているテーブルとデータを使用しています。    動的なデータマスキング    https://msdn.microsoft.com/ja-jp/library/mt130841.aspx   テーブルを作成します。 CREATE TABLE Membership    (MemberID int IDENTITY PRIMARY KEY,     FirstName…

0

イベント ID : 455/489/490 及び 413/486 の対処方法について

  皆さん、こんにちは。 BI Data Platform サポートチーム です。 ※ BI Data Platformサポートチーム では、Microsoft SQL Server/Azure SQL Database/BI Azure などの製品をサポートしています。 今回は、イベント ID : 455/489/490 及び 413/486 の対処方法について、紹介したいと思います。   Windows Server 2012 以降、ソフトウェアの使用状況を収集する機能が追加されており、ソフトウェアの使用状況 を収集する機能の中で、“C:\Windows\system32\LogFiles\Sum” フォルダ配下への読み取り、書き込みが行われています。 そして、SQL Server サービス に指定された サービス起動アカウントに、“C:\Windows\system32\LogFiles\Sum” フォルダ配下に対する読み取り、書き込み、変更権限が付与されていない場合、権限不足に起因し、イベント ID : 455/489/490 がイベントログに記録されます。   ソース:ESENT イベントID:455 内容:   sqlservr (2032) ログファイル C:\Windows\system32\LogFiles\Sum\Api.log を開いているときに、エラー -1032 (0xfffffbf8) が発生しました。 ソース:ESENT…

0

SQL Server における分散トランザクション 2

  神谷 雅紀Escalation Engineer   SQL Server における分散トランザクション 1 の続きです。   前回の投稿では、SQL Server における MSDTC の接続を確立する際の振る舞いと、コミットまでの動作を説明しました。本投稿では、ロールバック時のシナリオや異常系シナリオについて説明します。   分散トランザクションの流れ (前回からの続き)   8) トランザクションのロールバック   ロールバック前までの流れは、前回紹介したコミットの場合と同様です。   8-1) アプリケーションは、アプリケーション側 MS DTC に対して、トランザクションのロールバック (中断) を要求します。 8-2) アプリケーション側 MS DTC は、SQL Server 側 MS DTC に対して、トランザクションの中断を要求し、その要求は SQL Server に対しても行われます。 この時、Transaction is aborting トレース/拡張イベントが生成されます。 8-3) SQL Server でのロールバックが完了すると、その完了が SQL Server…

0

SQL Server における分散トランザクション 1

  神谷 雅紀Escalation Engineer     分散トランザクション 分散トランザクションとは、複数のリソースマネージャーで実行されるトランザクションを、ひとつのトランザクションとして実行するトランザクションです。       リソースマネージャー リソースマネージャー (RM) とは、トランザクションによって更新されるデータを管理しているコンポーネントです。通常は、SQL Server や Oracle などのデータベース管理システムです。   トランザクションマネージャー トランザクションマネージャー (TM) とは、トランザクションを管理し、各リソースマネージャーに対してトランザクションに関する指示を出すソフトウェアコンポーネントです。SQL Server は、トランザクションマネージャーとして、Microsoft Distributed Transaction Coordinator (分散トランザクションコーディネーター / MS DTC) を使用します。   SQL Server における分散トランザクション実行時のソフトウェア構成 SQL Server やアプリケーションは、MS DTC Proxy を使用して MS DTC とのやり取りを行います。 最も一般的な形は次の図のように、それぞれの Windows で動作している MS DTC を使用して分散トランザクションを実行します。 尚、通常リソースマネージャは複数 (上図のように右側のサーバーが複数ある構成)…

0

照合順序 – 文字の比較と並び順 (その 2)

神谷 雅紀Escalation Engineer   照合順序 – 文字の比較と並び順 (その 1) では照合順序とは何かを書きました。今回は、照合順序に関わるいくつかの注意点について書きます。     照合順序の衝突   異なる照合順序が指定されている列同士は、比較することができません。 以下は、その簡単なサンプルです。   use mastergodrop database ja_90_bin2go— 照合順序 japanese_90_bin2 のデータベースを作成create database ja_90_bin2 collate japanese_90_bin2gouse ja_90_bin2go— 照合順序 japanese_90_bin2 のデータベースに japanese_90_ci_as と japanese_90_cs_as の列を持つテーブルを作成create table dbo.ja_90_cias (c1 int, c2 nvarchar(10) collate japanese_90_ci_as)create table dbo.ja_90_csas (c1 int, c2 nvarchar(10) collate japanese_90_cs_as)go— japanese_90_ci_as と japanese_90_cs_as…

0

照合順序 – 文字の比較と並び順 (その 1)

神谷 雅紀Escalation Engineer 照合順序が分かりにくいという意見がありましたので、今回は照合順序を取り上げます。        照合順序とは何か SQL Server では、文字の大小関係を比較する場合の基準を照合順序 (collation) と呼んでいます。例えば、「朝」と「海」ではどちらが大きいのか、「あ」「ア」「ア」を大きい順に並べた場合どのように並ぶのかといった、文字の大小関係を決めているのが照合順序です。 言語としての日本語の観点では、「朝」と「海」のどちらが大きくても、さほど問題にはならないように思えるかもしれません。しかし、もしこれらの文字に大小関係がなかったら、データを大きい順に並べても毎回違った並び順になる可能性があります。さらに、もしこれらの文字に大小関係がなかったら、大きくも小さくもないということになります。大きくも小さくもないということは、   if (a < b) …else if (a > b) …else …   の式で最後の else に入るということであり、そこに入るのは a = b の場合だけです。つまり、等しいということです。「朝」と「海」が等しいとなると、それは言語としての日本語でも問題となってきます。 このように、照合順序 (文字の大小関係) は、データを扱う処理にとっては、重要な要素です。 照合順序はどのような場面で使われるのか 文字の比較を行うすべての場面で使われます。 例えば、インデックスを作成する際には、キー列の値順にインデックス行を並び替えるために使われます。select … from … order by Col1 のようなクエリでデータを並び替える際にも使われます。select … from … group by Col1 のようなクエリでグルーピングを行う際にも使われます。また、if (@a = @b)…

1

SQL Server エージェントのジョブの結果をメール通知する方法

Microsoft SQL Server サポートチー 佐藤美菜 SQL Server の標準機能で、メンテナンス プランや SQL Server エージェント ジョブを利用して、定期的にバックアップを取得したり、ジョブを実行できます。「ついでに、SQL Server の標準機能でその結果をメール通知したいけれど、標準機能でできる?」というご質問をいただきます。 ジョブ管理ツールがなくても、SQL Server の標準機能で行えるメール通知方法がありますので、今回は具体的な設定方法をご案内します。 ※ SQL Server エージェントが提供されていない Express Edition では利用できません。その他のエディションでは利用可能です。   概要 メンテナンス プランや SQL Server エージェント ジョブの結果をメール通知するには以下の設定を行います。 データベース メールの構成 SQL Server エージェント のメール プロファイルの設定 オペレータの作成 ジョブ通知の設定 順番に設定する手順をご紹介します。 なお、通知されるメールの内容は決まっており、残念ながらカスタマイズできません。メールの文言を変更したいなどカスタマイズの要望がある場合は、サードパーティー製のツール等をお探しください。   1. データベース メールの構成 ( 1 ) SQL Server Management Studio(SSMS)…

0

FlushCache メッセージ

  神谷 雅紀Escalation Engineer     SQL Server 2012 以降では、以下のメッセージが Errorlog ファイルに記録されることがあります。今回はこのメッセージを解説します。   メッセージ   FlushCache: cleaned up 39907 bufs with 1628 writes in 74882 ms (avoided 30218 new dirty bufs) for db 5:0            average writes per second: 21.74 writes/sec average throughput: 4.15 MB/sec, I/O saturation: 3296, context switches 9000            last target outstanding: 153600, avgWriteLatency…

0

トラブルシューティング手法とサポートサービス

システムで何らかのエラーが発生したという場合や、やりたいことができないといった場合に、トラブルシューティングを行うことになりますが、その際の一般的なトラブルシューティングの流れについてご紹介します。私たちサポートチームもだいたいこのようなフローの考え方をもとに調査を行っています。また、テクニカルサポートでは、インシデント単位で承っているプロフェッショナルサービスと、時間単位で承っているプレミアサービスがあります。トラブルシューティング内容に応じた、それらのサポートサービスの違いについても、参考としてご案内します。 大きく、運用でのエラー発生、開発時の How-to では考え方も異なりますので、それぞれ分けて見ていきます。 エラー発生 A) いま事象が発生しているか これは一番重要なポイントになります。いま事象が発生している場合には、すぐに対処が必要なため緊急度は高くなり、できることも多くなります。復旧優先で対処となりそうな対応をすぐに行ったり、原因調査のためにいったん情報も採取してから対処を行うといった対応があります。 一方、いま発生していないけれども、過去発生していたエラーをさかのぼって調査することもあります。この場合には、どれだけ手掛かりとなる情報が残っているかが重要です。 B)エラーメッセージやログから調査 いま事象が発生している場合には、エラーメッセージやログを確認します。 SQL Server を例にとると、既定で出力されている情報として参考になるのは、下記があります。 既定の情報 SQL Server エラーログ (ERRORLOGファイルや、同じフォルダにあるデフォルトトレースやダンプファイル等) Reporting Services ログ (ログファイルや同じフォルダにあるダンプファイル、ExcecutionLog ビュー) Analysis Services ログ (msmdsrv.logやフライトレコーダー) イベントログ その他、事象に応じて、次のような情報を採取することもあります。 追加情報 ブロッキング情報 動的管理ビュー サーバートレース 拡張イベント パフォーマンス カウンター 問題ステップ記録ツール BID トレース ネットワークトレース ダンプファイル プロフェッショナルサービス、プレミアサービスのいずれでも、これらの情報からの調査は承っています。違いとしては、下記があります。 プロフェッショナルサービス これらの情報から、対処方法を調査してご案内します。 プレミアサービス これらの情報から、対処方法を調査してご案内します。また、必要に応じて原因追及の調査も行うことが可能です。 追加情報の中でも、BIDトレース、ネットワークトレース、ダンプファイルを採取する必要がある事象については、環境依存の問題の可能性が一般的には高いと言えます。その場合にはプレミアサービスでのみ調査可能です。   C) 発生状況の切り分け 事象によっては、情報採取よりも、事象が発生するパターン、発生しないパターンを切り分けることによって、問題点が特定できる場合があります。また、発生しないパターンが確認できると、それが対処方法に直結する場合もあります。例えば、次のような切り分けがあります。 特定の環境で発生する、もしくは複数の環境で発生する 特定のクライアントで発生する、複数のクライアントで発生する 特定のユーザーで発生する、複数のユーザーで発生する…

0

用語解説: 復旧、復元、修復

神谷 雅紀 Escalation Engineer 今回は、混同しやすい用語である「復旧」「復元」「修復」について解説します。 復旧 復旧 (英語では recover, recovery) は、データベース開始時に実行されるトランザクションのロールフォワード、ロールバックなどの処理を表します。 SQL Server は、多くのデータベースシステムと同様に、ログ先行書き込み (Write-Ahead-Logging, WAL) を行います。データベースファイルへの書き込みは、必ずトランザクションログファイルへの書き込みが先行されます。トランザクション完了時、トランザクションログへの書き込みは必ず同期されます。言い換えれば、クライアントが COMMIT を発行しても、トランザクションログへの書き込みが終わらないと、クライアントへは制御が返されません。一方、データファイルへの書き込みは非同期です。そのため、データベースクローズ時にデータファイルの内容が最新の状態であるとは限りません。データベース開始時には、トランザクションログを使用して、データファイルをトランザクションとして整合性のとれた最新の状態にするために、未完了トランザクションをロールバックしたり、データファイルへ未反映のトランザクションをロールフォワードしたりします。つまり復旧が必要になります。 データベースの開始は、SQL Server の起動時やデータベースのアタッチ時に実行されたり、WITH RECOVERY の指定された RESTORE DATABASE または RESTORE LOG ステートメントの実行時に実行されます。データベースが開始されると、Errorlog ファイルには “Starting up <database name>” と記録されます。 復元 復元 (restore, restoration) は、RESTORE ステートメントによってバックアップデータからデータベースを作成したり、復元中 (restoring) の状態にあるデータベースにトランザクションログを適用することを指します。 修復 修復 (repair) は、SQL Server のデータベースとして論理的に正常ではない状態になってしまったデータベースを、データベースとして使用可能な状態に戻すことを指します。 通常は、復旧に失敗し、データベースが未確認 (suspect) の状態となってしまったものの、そのデータベースのバックアップがなく、バックアップからデータベースを復元できない状況の場合に、最後の手段として、DBCC CHECKDB に修復オプションを指定することで修復します。…

0