0

Oracle から SQL Server 2008 への移行プロジェクトに取り組んでいます。そのため、他のストアドプロシージャを呼び出すために使用される多くのオラクルパッケージ関数があります。これらの関数は、SSMA によって関数から拡張プロシージャを介して実行される IMPL プロシージャに変換されています。そのような関数のほとんどを可能な限り単純な UDF に変換しました。現在、私たちは独特のパフォーマンスの問題に直面しています。このような関数を IMPL プロシージャ コールで呼び出すクエリは、実行に時間がかかります。興味深いのは、Sql Server 2008 の古いサーバーで 2 分で同じクエリを実行していたことです。現在、SQL Server 2008 R2 を搭載した新しいサーバーでは、非常に長い時間がかかります (約 25 ～ 30 分)。

インデックスと統計も最新であることを確認しました。また、IMPL 呼び出しが master および sysdb データベースを通過し、内部テーブルを使用して IMPL プロシージャー呼び出しからの結果を保存し、関数に返すことにも気付きました。それらのスペース割り当ては、古いサーバーとは異なります。しかし、スペースが不足しているわけではありません。それらが問題を引き起こしている可能性はありますか? master/sysdb データベースの領域割り当てに関するガイドラインはありますか?

データベースは約 300 GB で、tempdb は約 50 GB です。

古いサーバー

  • SQL Server 2008/Windows
  • Xenon クアッドコア x4 - 3GHz、64GB RAM

新しいサーバー

  • SQL Server 2008 R2 RTM
  • Opteron 6 コア x6 - 2.2GHz、64GB RAM

さらに詳細が必要な場合はお知らせください。

ありがとう

4

1 に答える 1

0

SQL Server のユーザー定義関数は、値を返すことができる単なる SP ではありません (たとえば、データベース テーブルを変更することはできません)。Oracle 関数は、基本的にプロシージャと同じことを実行できます。したがって、多くの Oracle 関数は func_name$IMPL ストアド プロシージャ + いくつかのラッパー関数 (私が覚えている限り、SSMA 固有の拡張 SP を介して対応する $IMPL プロシージャを呼び出す) に変換されます。可能な場合、SSMA は関数を直接呼び出すことを回避しようとします (代わりに、適切な ...$IMPL SP への呼び出しを生成します) が、一部のケースはカバーされていません。これらの難しいケースでは、生成されたラッパー関数が直接呼び出されます。確かにかなり遅い傾向があると思います:( SSMAによってあなたのケースでより良い自動変換が見つかりませんでした...したがって生成された SQL Server コードを変更して、func_name$IMPL ストアド プロシージャを直接使用するようにしてください(通常の EXEC を使用するだけで、パフォーマンスが十分になるまでラッパー関数をできるだけ呼び出さないでください)。

于 2011-02-01T17:57:54.360 に答える