jdbcタスクに対する要望

[dkr]

数年前から現場でDBFluteをしたことにより、効率よく開発が進められ大変助かっております。

その中で１点だけ対応して頂きたいことがあります。

現在の現場では１スキーマに大量のTABLEとVIEWがある残念な構成になっており

manage.batのjdbcタスクの実行に１時間ほど掛かっております。

一番時間がかかるのが下記のSQLを実行している部分です。

select * from ALL_COL_COMMENTS where OWNER = 'HOGE' order by TABLE_NAME asc, COLUMN_NAME asc

自動生成の対象はdatabaseInfoMap.dfpropのtableTargetListを用いて制限していますが、

jdbcタスクでTABLE情報を取得する際はすべてのTABLEが検索対象となっているのが原因かと思います。

この検索条件にtableTargetListを追加してもらうことはできないでしょうか。

select * from ALL_COL_COMMENTS

where OWNER = 'HOGE' and TABLE_NAME in ('TABLE1', 'TABLE2')

order by TABLE_NAME asc, COLUMN_NAME asc

以下、使用環境です。よろしくお願いします。

-----

DBFluteバージョン：0.9.6 から 1.1.0 

（複数のサブシステムで異なるものを使用しています）

Database：Oracle Database 11g

[kubo]

jfluteです

dkrさん、こんにちは

> 数年前から現場でDBFluteをしたことにより、効率よく開発が進められ大変助かっております。
ありがとうございます！

> manage.batのjdbcタスクの実行に１時間ほど掛かっております。
おおおぉぉぉ、Oracleだとなおさらですね…
マルチスレッドでメタデータを取得するようにしていますが、
焼け石に水っぽい感じなんですよね

> 自動生成の対象はdatabaseInfoMap.dfpropのtableTargetListを用いて制限していますが、
> jdbcタスクでTABLE情報を取得する際はすべてのTABLEが検索対象となっているのが原因かと思います。

なるほど、りょうかいしました。
ちょっと、チャレンジしてみます。

ちなみに、ちょっと確認ですが、
ALL_COL_COMMENTSへの検索って、
jdbcタスクにつき、一回 or 二回くらいになっていますでしょうか？
(変にループさせてたりしないとちょっと心配になって)

また、参考までに、ALL_COL_COMMENTSへの検索一回で
どのくらいの時間かかってます？

> DBFluteバージョン：0.9.6 から 1.1.0
> （複数のサブシステムで異なるものを使用しています）

いったん、対応しやすい 1.1.x で入れてみます。
それでうまくいったら、1.0.x にもバックポートするような感じで。

> --
> このメールは Google グループのグループ「DBFluteユーザの集い」に登録しているユーザーに送られています。
> このグループから退会し、グループからのメールの配信を停止するには dbflute+u...@googlegroups.com
> にメールを送信してください。
> このグループに投稿するには dbf...@googlegroups.com にメールを送信してください。
> http://groups.google.com/group/dbflute からこのグループにアクセスしてください。
> その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。

[awaawa]

awaawaです。

jfluteさん

もしかしたら、自分がだいぶ前にお願いしたsynonymやDBLinkの対応のために、

豪快に全てテーブル取得しているのかもしれません。

対応の際に、すいませんがsynonymやDBLinkの考慮もよろしくお願いしますm(__)m

2015年9月11日金曜日 16時59分30秒 UTC+9 jflute:

> このグループから退会し、グループからのメールの配信を停止するには dbflute+unsubscribe@googlegroups.com

[dkr]

jfluteさん

dkrです。

> ALL_COL_COMMENTSへの検索って、 

> jdbcタスクにつき、一回 or 二回くらいになっていますでしょうか？ 

１スキーマに対しては１回だけになっています。

（additionalSchemaMapを使っているのでスキーマの数だけ実行されています）

> また、参考までに、ALL_COL_COMMENTSへの検索一回で 

> どのくらいの時間かかってます？ 

今も実行していたのですが、１時間半ぐらい掛かるときもあります。

2015-09-11 16:30:01,686 [main] INFO  (DfDbCommentExtractorBase#doSelectUserTabComments():121) - select * from ALL_TAB_COMMENTS where OWNER = 'HOGE' order by TABLE_NAME asc

2015-09-11 16:34:15,948 [main] INFO  (DfDbCommentExtractorBase#doSelectUserTabComments():121) - select MVIEW_NAME as TABLE_NAME, COMMENTS from ALL_MVIEW_COMMENTS where OWNER = 'HOGE' order by TABLE_NAME asc

2015-09-11 16:34:23,921 [main] INFO  (DfDbCommentExtractorBase#doSelectUserColComments():168) - select * from ALL_COL_COMMENTS where OWNER = 'HOGE' order by TABLE_NAME asc, COLUMN_NAME asc

2015-09-11 18:07:13,986 [main] INFO  (DfSchemaXmlSerializer#loadSupplementarySynonymInfoIfNeeds():1325) - ...Loading supplementary synonym informations

よろしくお願いします。

[kubo]

jfluteです

ありがとうございます！

> １スキーマに対しては１回だけになっています。
> （additionalSchemaMapを使っているのでスキーマの数だけ実行されています）

おお、想定通りでした、よかったです。


> 今も実行していたのですが、１時間半ぐらい掛かるときもあります。

ひーーー

どういうメカニズムなんでしょうね...

テーブル名で絞るのもそうですが、
本来は、tableNameListを指定してないときでも速くならないとなので、
テーブルごとSQLを何発も発行した方が速いとか、
なにか策を見出したいですねぇ..


五月雨で申し訳ないですが、
テーブル数ってだいたいいくつくらいですか？

[dkr]

jfluteさん 

dkrです。 

TABLE数は500程度ですがVIEWが3万弱あります。

流石にこれだけあると遅くなるのも致し方ないと思い、色々と試したところ

下記の対応により5分程度でjdbcタスクが完了しました。

1.ダミースキーマを作成

2.必要なテーブルに対する権限をダミースキーマに付与

3.ダミースキーマをdatabaseInfoMapのメインスキーマに変更

4.自動生成したいスキーマをadditionalSchemaMapに設定

# databaseInfoMap:

map:{

    ; schema = FUGA  # ダミースキーマ

    ; variousMap = map:{

        ; additionalSchemaMap = map:{

            ; HOGE = map:{  # 自動生成したいスキーマ

                ; tableTargetList=list:{

                    ; TABLE1

                    ; TABLE2

                 }

            }

        }

    }

}

これだとALL_COL_COMMENTSへの検索時でも権限を持っているテーブルのみが検索されるため早くなるようです。

ひとまずはこの方法で何とかなりそうですが、ダミースキーマを作らないで済むようになればありがたいので

お手隙の際にでも対応お願いします。

[kubo]

jfluteです

> TABLE数は500程度ですがVIEWが3万弱あります。

恐れ入りました…
それで、COL_COMMENTS だと、カラム数が平均20としても、
30000*20くらいのレコードを検索してしまっているって感じですね。


ひとまず、1.1.x で修正入れてみました。
1.1.0-sp8 のパッチとして入れましたので、
すでに 1.1.0-sp8 であればエンジンだけ上書き、
それより前であれば単純に丸ごとアップグレードで試してみてください。

エンジンは、sh manage.sh 94 でダウンロードされます。

targetTableList で絞り込んだというよりかは、
jdbcタスクで取得したテーブル自体で絞り込んでいます。
(targetTableListは、exceptとかprefixとか考えるとなかなか難しかった)


ただし、制限があります。
自動生成対象テーブルが1000以上だと絞り込みが効きません。
つまり、今までと同じ挙動になります。
Oracle の inScope の個数制限1000があるので、
ちゃんと対応するとなると、or でつなげてあげないといけなくて、
いったんはそこまでは対応していません。

[dkr]

jfluteさん

dkrです。

早速の対応ありがとうございます！

対象テーブルも1000件を超えることはないので、ALL_COL_COMMENTSのレスポンス問題は

改善されました。

ALL_COL_COMMENTSが早くなったので、今まで他のスキーマを経由していたのをやめて

直接アクセスしたところ、パッケージが大量に存在するスキーマで同様の事象と

なることがわかりました。（小出しになってしまって申し訳ありません。。）

  select * from ALL_ARGUMENTS where OWNER = 'FUGA' and ARGUMENT_NAME is not null order by PACKAGE_NAME, OBJECT_NAME, OVERLOAD, SEQUENCE

  select * from ALL_SOURCE where OWNER = 'FUGA' order by NAME, TYPE, LINE

ALL_ARGUMENTSは約600万件、ALL_SOURCEは約5000万件あります。

isSuppressProcedure=trueなどでプロシージャを使わないようにしても同様でした。

お手隙の際にこちらも対応頂けると助かります。

また、ALL_COL_COMMENTSのレスポンス改善の影響で対象となるテーブルが存在しない

スキーマで例外が発生しておりました。

INFOで出力されているので認識済みかもしれませんが、念のためログを報告しておきます。

  2015-09-28 10:40:22,626 [main] INFO  (DfSchemaXmlSerializer#helpTableComments():1052) - Failed to extract table comments: extractor=org.dbflute.logic.jdbc.metadata.comment.DfDbCommentExtractorOracle@70e889e9

  org.dbflute.exception.DfCommentExtractingFailureException: Failed to extract table comment: sql=select * from ALL_TAB_COMMENTS where OWNER = 'HOGE' and TABLE_NAME in () order by TABLE_NAME asc

  2015-09-28 10:40:22,761 [main] INFO  (DfSchemaXmlSerializer#helpTableComments():1061) - Failed to extract column comments: extractor=org.dbflute.logic.jdbc.metadata.comment.DfDbCommentExtractorOracle@70e889e9

  org.dbflute.exception.DfCommentExtractingFailureException: Failed to extract column comment: sql=select * from ALL_COL_COMMENTS where OWNER = 'HOGE' and TABLE_NAME in () order by TABLE_NAME asc, COLUMN_NAME asc

[kubo]

jfluteです

dkrさん、確認ありがとうございます！

> ALL_ARGUMENTSは約600万件、ALL_SOURCEは約5000万件あります。
参りました。。。
isGenerateProcedureParameterBeanもfalseでもってことですよね。
恐らく、DBLinkとかのメタデータから関連して
引きにいっちゃってるのかもです

対象となるテーブルが存在しないケースと合わせて、
ちょっと調整してみます。

[kubo]

jfluteです

> select * from ALL_ARGUMENTS where OWNER = 'FUGA' and ARGUMENT_NAME is not null order by
> PACKAGE_NAME, OBJECT_NAME, OVERLOAD, SEQUENCE
> select * from ALL_SOURCE where OWNER = 'FUGA' order by NAME, TYPE, LINE

パッと見てみたのですが、
isGenerateProcedureParameterBean が false の状態で、
こちらが実行されるパスを見つけるのに、
さすがにじっくり時間取らないとわからなさそうなので、
またしばらくお待ちくださいませ。。。

※DfProcedureExtractorで弾いてるはずなのですが...

[kubo]

jfluteです

dkrさん、
再度、1.1.0-sp8 に上げ直して、

outsideSqlMap.dfprop (outsideSqlDefinitionMap.dfprop) にて、

isForcedlySuppressProcedureMetaData = true

をやってみてください。

ParameterBeanの生成に関わらず、
ドキュメント情報としてメタデータを取得するようにしていましたが、
これで問答無用でメタデータを取らなくなるはずです。

ただこれ、AdditionalSchemaごとの方がよかったりしますかね？？？
(Procedure情報が取得されてほしいスキーマが混在してるとか)

[kubo]

jfluteです

> 再度、1.1.0-sp8 に上げ直して、
と思ったら、seasar.org がまた落ちてますね…
モジュールの反映ができたらまた連絡します。

[kubo]

jfluteです

> と思ったら、seasar.org がまた落ちてますね…
> モジュールの反映ができたらまた連絡します。
反映されましたー！

[dkr]

jfluteさん

dkrです。

お忙しい中ありがとうございます。

isForcedlySuppressProcedureMetaData = true により改善されることが確認できました。

> ただこれ、AdditionalSchemaごとの方がよかったりしますかね？？？ 
> (Procedure情報が取得されてほしいスキーマが混在してるとか) 

今のところは必要ないので大丈夫です。

が、今後も不要かと言われると怪しいので何かのリリースタイミングで組み込んで頂けるとありがたいです。