同じ物理マシン上の別のDBを介して選択を実行すると、パフォーマンスが低下しますか？したがって、同じSQL 2008インスタンス内で実行される同じ物理マシン上に2つのデータベースがあります。私は同じ物理マシンと同じサーバーインスタンス上のSQl 2008のクロスデータベースパフォーマンス
SELECT someFields FROM the_other_db.dbo.someTable
を実行on_this_db SomStoreProcで例えば
は、これまでのところ、私はインターネット上で読んだものから、ほとんどの人がNOを示しているように見えます。
パフォーマンスヒットでない場合でも、FKはデータベース間で強制できないため、データの整合性に問題があります。
しかし、あなたのprocsが特に数千行の長さであれば調整する必要があります。まず、カーソル、相関サブクエリ、および不良インデックスの検索を行います。また、row-by-agonizing-rowで実行されている、スカラ関数ではない、疎らでない句を探します。
もちろん、別のデータベースが問題ではないことを証明する最良の方法は、1つの低速procを1つのデータベースに変換し、両方の方法でパフォーマンスをテストすることです。彼らが前進し、1つのデータベースにひどく複雑で時間のかかる変更を加え、それからそれらがまだパフォーマンスの問題を抱えていることを知るには、少なくともこの小さなテストを行うように彼らに説得してください。
実行計画は、あなたの友人がこれらのものを見ていることを忘れないでください。
ハッシュジョインなどの内部バッファを含むリモートケースがいくつかあるかもしれません。なぜなら、2つのデータベース（つまり、ファイルを共有しないでください（おそらく、tempDBの追加競合によって解決されるでしょう） – luckyluke
問題が発生していますか、これは仮説的な質問ですか？ –
2番目のDbと通信する数千行のコードの範囲にあるSpsを持つDb全体があり、パフォーマンス上の問題が発生しています。私はそれがたくさんあり得ることを知っていますが、それは思いついたもので、すべてを同じDBに移動したいと考えています。私はちょうどそこにそこに壊れないように助けようとしています。 – user432024