Microsoft SQL Server では、SQL Server におけるイベントの監視および物理データベース設計のチューニングを行うための包括的なツールセットが提供されています。実行する監視またはチューニングのタイプ、および監視する特定のイベントに基づいて、ツールを選択します。

詳細については、 https://docs.microsoft.com/en-us/sql/relational-databases/performance/performance-monitoring-and-tuning-tools?view=sql-server-2017 > を参照してください。

SQL Server データのコピーを使用して、障害発生後のデータの復元および復旧を行えます。SQL Server データのバックアップは、データベースレベル、またはその 1 つ以上のファイルまたはファイルグループのレベルで作成されます。テーブルレベルのバックアップは作成できません。完全復旧モデルでは、データのバックアップに加え、トランザクションログのバックアップを作成する必要があります。

データベース上のトランザクションログのメンテナンスを制御するデータベースプロパティ。単純、完全、一括ログの 3 つの復旧モデルが存在します。データベースの復旧モデルによって、そのバックアップと復元の要件が決まります。

指定された SQL Server バックアップから指定されたデータベースにすべてのデータとログページをコピーしてから、ログに記録されている変更を適用することでバックアップに記録されているすべてのトランザクションをロールフォワードして、データを直近の状態まで戻すマルチフェーズプロセス。

参照先

スケーラビリティとは、アプリケーションがさらに有益な作業を行うために、より多くのリソースを効率的に利用する能力のことです。

SQL Server で最も簡単に実装可能なスケールアウトソリューションが、スケーラブルな共有データベースです。このシナリオでは、SAN 上にデータベースを作成し、異なるサーバー上で動作している最大 8 つの SQL Server インスタンスがそのデータベースに接続し、クエリーの処理を開始します。これは従来の "共有ディスク" スタイルのスケールアウトソリューションであり、処理能力はスケールアウトしますが、使用されるデータのディスクイメージは 1 つだけです。ここで、SQL Server の知識がある人は、「でもロックはどうなるのでしょう? SQL Server の各インスタンスがそれぞれのメモリで独自のロックを保持していると思いますが。」という疑問を抱くかもしれません。そのとおりです。各インスタンスは独自のデータベースロックを管理し、いずれのインスタンスもほかのインスタンスのロックについて知りません。これが機能するのはロックが存在しない場合だけであり、したがって、読み取り専用データベースとして接続している場合にのみスケーラブルな共有データベースは機能します。つまり、スケーラブルな共有データベースはデータウェアハウスまたはレポーティングデータベースとしては優れていますが、データを更新するアプリケーションには適していません。私達のデータの特性に話を戻せば、スケーラブルな共有データベースは更新頻度がゼロの場合にのみ機能します。このデータは、定義上、履歴データなので、すべてが参照データです。

MSSQL Server では、インデックスキーの最大バイト数が 900 バイトを超えることはできません。キーは最大サイズが 900 を超える可変長列を使用して定義できますが、その場合、それらの列に 900 バイトを超えるデータ行を挿入してはなりません ( https://docs.microsoft.com/ja-jp/sql/sql-server/maximum-capacity-specifications-for-sql-server?view=sql-server-2014&redirectedfrom=MSDN)。