1

リンクサーバーとしてJDEDB2がセットアップされたSQLServer2005マシンがあります。

何らかの理由で、このボックスからdb2ボックスへのクエリのパフォーマンスはひどいものです。

例えば。以下は、ManagementStudioから実行するのに7分かかります

SELECT     *
FROM       F42119 
WHERE     SDUPMJ >= 107256

一方、iSeriesナビゲーターでの実行には数秒かかります

何かご意見は？設定の問題を想定しています。

4

5 に答える 5

5

特定の検索では、SQL Server は、クエリをリモート サーバーに送信する代わりに、テーブル全体をプル ダウンし、SQL Server 内でデータを並べ替えて検索することを決定します。これは通常、照合設定の問題です。

プロバイダに次のオプションが設定されていることを確認してください: データ アクセス、照合互換性、リモート照合の使用

次に、プロバイダーを使用して新しいリンク サーバーを作成し、次のプロバイダー オプションの [動的パラメーター]、[ネストされたクエリ]、[処理中の許可] を選択します。

オプションを設定した後、クエリを少し変更して、新しいクエリ プランを取得します。

于 2008-10-28T23:03:06.727 に答える
1

SQL Server マシンのメモリの問題である可能性があります。最近、リンク サーバー クエリが OS によるメモリ割り当てを使用することを知りました。一方、ネイティブ SQL Server クエリは、SQL Server によって事前に割り当てられたメモリを使用します。SQL Server マシンがサーバーのメモリの 90% 以上を使用するように構成されている場合は、それを少し縮小します。たぶん60％が適切な場所です。

もう 1 つの確認事項は、SQL Server プロセッサの優先順位です。「SQL Server の優先度を上げる」が有効になっていないことを確認します。

アクセスのためにODBCを使用していると思います。ここでは、ネイティブの db2 クエリを作成するのではなく、ODBC sql クエリを作成することに注意してください。読み取り専用データのみが必要な場合は、ODBC データソースを読み取り専用モードに構成してみてください (オプションである場合)。

于 2008-09-18T20:36:21.047 に答える
1

DB2 を統合したプロジェクトでは、直接選択またはビューを介したすべてのクエリを、OPENQUERY 関数を呼び出すストアド プロシージャに置き換えました。

私の解釈では、SqlServer は WHERE 条件を適用する前にテーブル全体をフェッチしますが、OPENQUERY は SQL ステートメントを直接 db ドライバーに渡します。

とにかく、変更後のパフォーマンスは許容範囲内でした。

于 2008-10-28T23:13:58.623 に答える
0

私の最初の考えはドライバーに行きます。何年も前に、DB2 を SQL Server 2000 にリンクする必要がありましたが、動作するドライバとセットアップ パラメータの正しい組み合わせを見つけるのは非常に困難でした...

そのため、私は偏見を持っているかもしれませんが、ドライバーをアップグレードまたはダウングレードするか、DB2 ドライバーが INPROC を実行できるようにセットアップを変更してみます (まだ実行していない場合)。

于 2008-09-17T21:51:21.750 に答える
0

リンクされたサーバーとしての DB2 には、いくつかの問題がありました。それがあなたの問題に対処するかどうかはわかりませんが、私の修正は次のとおりです。

1) ODBC 設定で、EXECUTE 中のレイジー クローズ サポートとプリフェッチを有効にしました 2) すべての選択に「FOR FETCH ONLY」を追加しました 3) SELECT * FROM OPENROWSET(LinkedServerName, 'SQL Command') メソッドを使用してクエリを実行しました

于 2008-09-18T20:46:20.477 に答える