3

SQL Server 2012 では、Contained Database が導入されました。この機能の本当の目的は何ですか? 以前のバージョンのどのような欠点が修正されましたか?

4

1 に答える 1

8

これらは、システム間のデータベースの移行を容易にするために開発されています (データベースと、リソースのバランスをとるために移動する必要がある SQL Azure 上のデータベースの両方)。データベースの外部に依存するものはすべてリスクと見なされます。なぜなら、それはデータベースと一緒に行かなければならない余分な足場だからです - 忘れやすく、間違いやすく、同期から外れやすいのです。

たとえば、デナリでは、次の問題が解決されています。

  • 現在、データベースを別のサーバーに移動する場合、サーバー レベルですべての SQL ログインも移行する必要があります。これは、特に SID が同期されていない場合に面倒です。包含データベースでは、SQL Server ログインに関係のないデータベース レベルのユーザーは、データベースのバックアップ、デタッチ、ミラーリング、レプリケートなどの際に、乗り物に乗るだけです。素晴らしく簡単です。

  • サーバーの照合順序とは異なる照合順序を持つデータベースがある場合、作成された #temp テーブルはサーバーの照合順序ではなくサーバーの照合順序を継承するため、#temp テーブルを結合またはその他の操作を実行すると、照合順序の競合が発生することがあります。データベースを呼び出します。単一の列参照ごとに COLLATE 句を指定することでこれを回避できますが、データベースが含まれている場合、#tempdb は呼び出し元のデータベースの照合を継承し、サーバーの照合をオーバーライドします。

  • THROW() もほぼこのカテゴリに分類されます。これは、sys.messages を使用してカスタム メッセージを格納する必要がなくなったためです。これは上記の 2 つの問題ほど一般的ではありませんが、sys.messages の同期を維持する必要がない場合、新しいサーバーへの移行が確実にうまくいきます。これは包含データベースに限定されませんが、同じ役割を果たします。

  • 「封じ込め」基準を満たさないものについては、別のサーバーに移動すると破損する可能性のあるもののリストを表示できる DMV があります。たとえば、3 部構成または 4 部構成の名前の呼び出し。

将来のバージョンでは、対処される他の問題があります。例えば：

  • SQL Server エージェントは外部依存関係です。データベースを別のサーバーに移動する場合、そのデータベースを参照する SQL エージェント ジョブはデータベースと共に自動的に移動しません。どのジョブが影響を受けるかを判断し、それらを自分でスクリプト化する必要があります (msdb を持ち込むだけでは簡単ではありません)。それも）。SQL Server の将来のバージョンでは、(a) 各データベースが独自のエージェントを持つことができるようになるか、または (b) エージェントが OS レベルのアーキテクチャに移行され、変換レイヤーによってデータベースの場所が示されるようになると思います。つまり、エージェントを同じマシンに配置する必要はありません。後者のオプションは、Azure や地理的に分散したネットワークなどについて話していると複雑になる可能性があります。

  • リンク サーバーも外部依存関係です。これは、データベース レベルのリンク サーバーで簡単に解決できます。特に、これらはシノニム コンテナー/ポインターにすぎないためです。

他にもありますが、それらはヘビーヒッターです。

于 2011-07-14T02:59:36.027 に答える