web-dev-qa-db-ja.com

as400コンソールでのSQLステートメントはリモートODBCからのものよりも遅い

7.1を実行しているiシステムの1つで奇妙な問題が発生しています

私はerpとしてjdedwards8.0を使用していますが、この問題は私が見つけたばかりのように関連していません。

いくつかの調査の後、それはこれに行き着きました。特定のテーブルで同じ単純な選択を実行します。 1回目はodbcを介して接続する1つのファットクライアントから実行し、2回目はSTRSQLを介して実行します。

1回目は最大1秒、2回目は4〜5秒かかります。

デバッグ（STRDBG）は、サーバーで実行すると、既に存在するインデックスの提案があることを示しています。 odbcマシンはそれを使用します。

Erpとナビゲーターの両方からインデックスを削除して追加しようとしましたが、結果は同じです。

同じテーブルに対してSTRSQLから同じSQLを実行すると、本番ライブラリではodbcの場合と同じように高速に実行されます。

私の無知をお詫びしますが、iamはas400を知っている人にさえ近くありません...

P.S.いくつかの詳細：

私が実行しているその単純なSQL：

SELECT  *  FROM testDTA/F74G0904  WHERE  ( WFDCT = 'JE' AND WFDOC = 
166823.000000 AND WFKCO = '00003' AND WFDGJ = 114090 AND WFJELN =   
1.000000 AND WFLT = 'AA' AND WFEXTL = ' ')  
The table has around 10.000.000 in both libraries.

グリーンスクリーン-LIB1-4秒

グリーンスクリーン-LIB2-1秒

ODBCクライアント-LIB1-1秒

ODBC CLIENTLIB2-1秒

ライブラリ固有であると同時に接続固有であるようです。

「GREENSCREEN--LIB1-4SECS」の場合のDSPJOBLOGは、すでに存在するインデックスを示しています。また、私が言ったように、インデックスを削除して作成しようとしました。

さまざまなライブラリ、オプティマイザ、および実行プランのsameSQLを見てください。

比較画像

ありがとう

performanceiseries
1
e4rthdog

問題は単純であるが見つけるのが難しいものでした。

インデックスのソート順序が間違っていました。

ソート順序に言語設定を使用するようにクライアントが誤って構成されていました。

したがって、インデックスが作成されたとき、それらにはソート用の言語仕様がありました。

ジョブがサブミットされたときのサーバーは、* HEX仕様のインデックスを探していたため、既存のインデックスを無視していました。

1
e4rthdog