ログイン Up dated!
ユーザー名:

パスワード:


パスワード紛失

新規登録

SAP勉強会開催中!

運 営

メインメニュー

運営者及び問合先

当サイトに対する問い合わせは erp.expert.jp@gmail.comまでお願いします。または
SUNTEC WEST お問合せまで。
なおこのサイトからのメールが迷惑メールに振り分けられてしまう場合があります。


フォーラムの説明
フォーラムは階層構造になっており「カテゴリ」の下に「フォーラム」があります。その下にQ&Aのやりとりの題名があり、それを「トピック」と呼びます。例にあげると「SAP ERP」というカテゴリがあって「Financials」というフォーラムがあります。その下でメンバーが自由に「原価センタグループの移送方法ありますか」とかいうQ&Aの「トピック」を立ててやりとりします。 このフォーラム機能は通知機能があります。興味のある「カテゴリ」「フォーラム」「トピック」と各レベルごとに誰かが投稿したら「メール」で知らせること機能でフォーラム内各ページの下にある「イベントの選択」で自由に通知方法を選択してください。なおその前に「ホーム」→「アカウント編集」でイベント更新通知メッセージの受取方法は「メール」、イベント通知のタイミングは「・・・通知する」となっていることを確認してください。「フォーラム」とその親となる「カテゴリ」に また「トピック」とその親となる「フォーラム」に通知チェックを入れたりするとどちらかがキャンセルされるか二度通知いくようなことが発生しますので親側にチェックいれたらその子には通知チェックはずしておいてください。複雑になってしまったら「ホーム」→「イベント通知機能」で整理するといいでしょう。

投稿数ランキング
1 chira3903 51
2 ttabuchi 43
3 emy 25
4 jun 20
5 chong 20
6 hiro888 15
7 mkouso 11
8 sarjan 11
9 saku_saperp 11
10 ishikawa 10

COEPの抽出

  • このトピックは管理者もしくはモデレータによりロックされています

なし COEPの抽出

msg# 1
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 .2 .3 .4 | 投稿日時 2013-7-18 9:14
ゲスト 
テーブル:COEPからのSELECTのパフォーマンスが悪く困っています。SELECT文は以下の通りです。COEPの全エントリは3600万程です。索引は当っているのですが、時間がかかってしまいます。良い案があれば教えて下さい。

SELECT BELNR
BUZEI
PERIO
WKGBTR
OBJNR
GJAHR
KSTAR
GKONT
WERKS
MATNR
GKOAR
EBELN
EBELP
SGTXT
MEINB
MEINB
FROM COEP
INTO TABLE ITAB_COEP
FOR ALL ENTRIES IN ITAB_WBS
WHERE KOKRS = '1000'
AND LEDNR = '00'
AND OBJNR = ITAB_WBS-OBJNR
AND GJAHR >= P_GJAHRS "パラメータ:開始年度
AND GJAHR <= P_GJAHRE "パラメータ:終了年度
AND WRTTP = '04'
AND VERSN = '000'
AND KSTAR IN S_KSTAR "パラメータ:原価要素
AND HRKFT = SPACE
%_HINTS ORACLE 'INDEX("COEP" "COEP~1")'.
投票数:180 平均点:3.06
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2013-7-18 17:47
ishikawa  新米   投稿数: 10
%_HINTS ORACLE 'INDEX("COEP" "COEP~1")'.

こんな構文が可能なんですね。
このヒント文は(テーブルCOEPのインデックス"COEP~1"を使うと効率が良い)
という事になると思います。
COEP~1は一次インデックスというか、主キーのインデックスですが
このキーとWHERE条件が一致していないので、このインデックスをつかえておらず
FULL SCANされていると推測しています。

手っ取り早い解消方法といえば、現在の抽出条件に利用している項目の単位で二次インデックスを
作成し、ヒント文でその追加したインデックス(COEP~2)を指定すれば解消すると思います。
(もちろんその後DBの統計情報更新も。)

効果はデータの分布状態(インデックスの効率)にもよりますが十倍から数十倍の効果がでる場合もあります。
また、効果があるか定かではないですがインデックスが貼られた項目順に
WHERE条件も並べておいた方がお作法的には良いような気はします。

※ただし、インデックスが増える分COEPの更新する他の処理に影響が出ますので
 コアなテーブルへの二次インデックス作成はBASIS担当の方と相談の上行った方が良いと思います。

それと初歩的ですが実装していると意外と忘れがちな件です。
"FOR ALL ENTRIES"は指定した内部テーブル(ITAB_WBS)が0件の場合
WHERE条件そのものが無効となる罠がありますが、これに該当していないでしょうか?
パラメータで指定されている会計年度・原価要素等の抽出条件も無効となりますので
この場合ですと全件(3,600万件)を抽出しに行きます。

<ご参考>
http://abap.sblo.jp/article/13768651.html

テーブルのキー情報だけで一度内部テーブルへ抽出して
対象外データを内部テーブルからDeleteする方法の検討もありかと思います。
DB負荷をアプリ側に持ってきただけなので
アルゴリズムとしてはイマイチですが、結果としてパフォーマンスが向上する場合もあります。

いずれにしてもSAP全般的に"年度"を跨る抽出は遅くなると思います。
パフォーマンスについては、ある程度はやむなしな気はします。
投票数:167 平均点:4.37
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2013-7-18 21:09
ゲスト 
質問者です。
ご回答ありがとうございましたm( _ _ )m
投票数:140 平均点:5.29
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2013-7-24 18:39
abapやってます 
横からすいません。
遅いかもしれませんが、気になったので訂正を。

そのHINT文は標準の二次インデックスを指定していますので、
検索条件としては正しと思われます。
ちなみに、テーブルインデックスの場合は番号が0ですね。

年度が範囲指定になってますので、in文にして等号検索になるようにしてください。
rangeテーブルのoption eq レコードを範囲文設定するロジック組んで使用してください。
ベストは範囲指定させないかと思いますが…。

メモリに余裕があるのならfor all は件数が多いとパフォーマンスが悪いので、
検索条件を緩くしてみるのも手です。
投票数:165 平均点:4.79
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2013-7-25 8:59
ゲスト 
質問者です。
ご回答ありがとうございます。
ちなみにfor allをやめてビューにしてみたらどうかと思っているのですが、ビューの方がパフォーマンスはいいでしょうか?
投票数:105 平均点:5.43

  条件検索へ


 

Powered by XOOPS Cube 2.1.8© 2010 ERP EXPERT Project  |  COPYLIGHT (C) 2007 Suntec-BS rights reserved.