Q&A

回答の並べ替え：
投稿新規に質問を投稿する

「テーブルのデータをCSVファイルとして保存する」のレスポンス

＠いさお ＠いさお

2025-12-10 11:18

データ操作の「テーブルのデータをCSVファイルとして保存する」を実行した際
初回の処理が遅く（３０分～１時間）、２回目以降は当日であれば早く（１分以内）
翌日になると同現象に戻ってしまいます。
データ件数は６万件程です。
不要なメモリ領域の解放やCurlのキャッシュを空にしても改善しません。
解決法をご存じの方は、ご教授ください。

＠いさお ＠いさお
ご回答ありがとうございます。
確かにViewは複雑な構造をしており
CELF以外の影響であることを認識しました。
(SQL文でViewをcount(*)するのも20~30分処理時間がかかる)
View側の改善を試みてみます。
蓼科情報株式会社 蓼科情報株式会社 パートナー
詳細の情報ありがとうございます。

ODBC接続でOracleのVIEWを利用してデータを取得しているとのことなので、VIEWの初回の時間がかなり遅いのではないかと考えられます。
CELFを介さずにSQL文で該当データを取得した時間を計測し、遅いようであればVIEWのSELECT文を見直す必要がありそうです。
また、ODBC接続の場合は「テーブルのデータをCSVファイルとして保存する」アクションの前後でデータベースへの接続・切断も行われるので最初の接続に少し時間がかかる場合があります。こちらもODBCもしくはOracleのパラメータ設定などで解消する場合があります。
いずれにしろCELFの外側の影響が大きいと思いますので、そちらの調査・改善を試みてください。
メールコンタクトをとる
＠いさお ＠いさお
ご回答ありがとうございます。
①６万件　エクスポート後のCSV容量　12MB
②ロカールPC　＆　ファイルサーバ（AWS）ともに遅いです。
③Wifi＆有線LANとも遅いです。

テーブルがOracleDBのViewの参照します
出力Csvも見るとCELF側で主Keyでソートされているので
それが原因かと想像しています。
蓼科情報株式会社 蓼科情報株式会社 パートナー
1レコードのデータ量や環境が書かれていませんので、私が経験した範囲でお答えします。

初回と2回目以降の時間差は先の方が書かれているようにキャッシュが働いている可能性が高いです。時間差の大きさからCELF以外のネットワークや保存先側のキャッシュ機能による働きが大きいのではないでしょうか。

初回の時間ですがデータ件数だけで考えると遅すぎる印象です。
遅い要因としては、
　①1レコードのデータが非常に大きい
　②保存先がPCのローカルドライブ以外になっている
　③ネットワークの接続が不安定になっている
などが考えられます。
①は既に存在しているデータなので改善は難しいです。
②は保存先をPCのローカルディスクに変えます。
　手動でネットワークドライブなどにコピーするとトータルの時間は短くすみます。
③は接続が安定する有線LANを使用することを推奨します。

多くの推測を含んでおりますが、参考になれば幸いです。
メールコンタクトをとる
ytradish ytradish
これは初回の処理にはキャッシュが効いていないため本来のパフォーマンスを発揮しており、２回目以降はキャッシュが効いているのではないでしょうか？

Q&A一覧 Q&A一覧へ