トランザクションの開始
- このフォーラムに新しいトピックを立てることはできません
- このフォーラムではゲスト投稿が禁止されています
mizuno
投稿数: 58
![常連 常連](../../uploads/rank3dbf8e9e7d88d.gif)
お世話になっております。
PervasiveからMSSQLへのデータ移行のPGを作成しております。
データ件数が290万件あるファイルの移行なので、移行処理に時間がかかります。
処理時間短縮のため「トランザクションの開始」を「なし」にしたところ、
「タスク前の前」と比較すると圧倒的に、「なし」の方が処理時間がかかります。
トランザクションをオープンしなければ処理速度は向上すると思っていたのですが、
違うのでしょうか?
PervasiveからMSSQLへのデータ移行のPGを作成しております。
データ件数が290万件あるファイルの移行なので、移行処理に時間がかかります。
処理時間短縮のため「トランザクションの開始」を「なし」にしたところ、
「タスク前の前」と比較すると圧倒的に、「なし」の方が処理時間がかかります。
トランザクションをオープンしなければ処理速度は向上すると思っていたのですが、
違うのでしょうか?
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
![長老 長老](../../uploads/rank3dbf8eb1a72e7.gif)
トランザクション開始をなしにできますか
F7のチェックでエラーになりませんか
そのプログラムは単体でしょうか
F7のチェックでエラーになりませんか
そのプログラムは単体でしょうか
投票数:0
平均点:0.00
mizuno
投稿数: 58
![常連 常連](../../uploads/rank3dbf8e9e7d88d.gif)
ISHIJIMA様
「トランザクションモード:物理」
「トランザクションの開始:なし」にしています。
チェックでエラーはでません。
移行のプログラムは、メインソースにPervasiveのテーブルを指定し、同一タスクでSQLServerの
テーブルを登録リンクにて作成しています。
検証していないのですが、「トランザクションの開始:なし」の設定とは、DBへレコード書込み時に
トランザクションを開始し、書込み終了時にコミットを発行する設定なのでしょうか?
よくよく考えれば当たり前の事なのですが、そう考えると処理に時間がかかるのも納得がいきます。
「トランザクションモード:物理」
「トランザクションの開始:なし」にしています。
チェックでエラーはでません。
移行のプログラムは、メインソースにPervasiveのテーブルを指定し、同一タスクでSQLServerの
テーブルを登録リンクにて作成しています。
検証していないのですが、「トランザクションの開始:なし」の設定とは、DBへレコード書込み時に
トランザクションを開始し、書込み終了時にコミットを発行する設定なのでしょうか?
よくよく考えれば当たり前の事なのですが、そう考えると処理に時間がかかるのも納得がいきます。
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
![長老 長老](../../uploads/rank3dbf8eb1a72e7.gif)
Pervasiveはトランザクションは意味を持たなかったような気がします。
ただSQLはトランザクションは必ず必要だとおもったのでそのあたりでなしにすると何かおかしくなっているのでしょうかね?
違っていたらすみません
私は通常物理でバッチの場合はタスク前処理の前かレコードロック時にしています。
なしにした場合ロック方式もなしにしないとエラーになりませんか
ただSQLはトランザクションは必ず必要だとおもったのでそのあたりでなしにすると何かおかしくなっているのでしょうかね?
違っていたらすみません
私は通常物理でバッチの場合はタスク前処理の前かレコードロック時にしています。
なしにした場合ロック方式もなしにしないとエラーになりませんか
投票数:0
平均点:0.00
pu_mahalo
居住地: 大阪
投稿数: 775
![長老 長老](../../uploads/rank3dbf8eb1a72e7.gif)
こんにちは Puです
SQLserverへinsertするのにトランザクション無し
というのは ありえません
バッチでinsertするのでしたら
タスク前でbegin tranが早いような気がします
あまりにも データ量が多かったらtranzaction logが多くなるので
break いれてcommitする方が安全だと思います。
SQLserverへinsertするのにトランザクション無し
というのは ありえません
バッチでinsertするのでしたら
タスク前でbegin tranが早いような気がします
あまりにも データ量が多かったらtranzaction logが多くなるので
break いれてcommitする方が安全だと思います。
投票数:0
平均点:0.00
mizuno
投稿数: 58
![常連 常連](../../uploads/rank3dbf8e9e7d88d.gif)
ISHIJIMA様
私も通常のバッチタスクでは「タスク前の前」を使用しています。
今回の場合は、本番データをPervasive→SQLServerへ移行するために
一度きりしかながさない事と、処理速度向上を期待しての「なし」でした。
見当はずれの事をしていましたが・・・
ロック方式は「なし」にしていたのでエラーはでませんでした。
Pu様
>SQLserverへinsertするのにトランザクション無し
>というのは ありえません
これですね。
「なし」=レコード毎コミットのようなイメージでしょうか。
結果、「グループ」に設定しました。
ただ、「グループ」よりも、「タスク前の前」の方が少しだけ速いです。
290万件の登録で処理に約2時間かかる中での5分の差なので誤差の範囲内
なのかもしれないのですが・・・それだけコミットに時間がかかりということでしょうか
私も通常のバッチタスクでは「タスク前の前」を使用しています。
今回の場合は、本番データをPervasive→SQLServerへ移行するために
一度きりしかながさない事と、処理速度向上を期待しての「なし」でした。
見当はずれの事をしていましたが・・・
ロック方式は「なし」にしていたのでエラーはでませんでした。
Pu様
>SQLserverへinsertするのにトランザクション無し
>というのは ありえません
これですね。
「なし」=レコード毎コミットのようなイメージでしょうか。
結果、「グループ」に設定しました。
ただ、「グループ」よりも、「タスク前の前」の方が少しだけ速いです。
290万件の登録で処理に約2時間かかる中での5分の差なので誤差の範囲内
なのかもしれないのですが・・・それだけコミットに時間がかかりということでしょうか
投票数:0
平均点:0.00
nobukoshi802
投稿数: 118
![一人前 一人前](../../uploads/rank3dbf8ea81e642.gif)
テーブルにインデックスは作成されていると思いますが
データ移行なので実行中にインデックスを削除
データ移行終了後、インデックスを再作成出来ますか?
データ移行なので実行中にインデックスを削除
データ移行終了後、インデックスを再作成出来ますか?
投票数:0
平均点:0.00
mizuno
投稿数: 58
![常連 常連](../../uploads/rank3dbf8e9e7d88d.gif)
nobukoshi802様
SQLServer側のインデックスを削除してみましたが処理速度は同じでした。
Magic側のインデックスも削除しなければいけないのでしょうか?
SQLServer側のインデックスを削除してみましたが処理速度は同じでした。
Magic側のインデックスも削除しなければいけないのでしょうか?
投票数:0
平均点:0.00
pu_mahalo
居住地: 大阪
投稿数: 775
![長老 長老](../../uploads/rank3dbf8eb1a72e7.gif)
こんにちは Puです
260万件と言う大量データのinsertの場合
グループレベルでcommitが一般的だと思います
サーバーで走らす事ができるのなら
サーバーで実行する事をお勧めします
260万件と言う大量データのinsertの場合
グループレベルでcommitが一般的だと思います
サーバーで走らす事ができるのなら
サーバーで実行する事をお勧めします
投票数:0
平均点:0.00
nobukoshi802
投稿数: 118
![一人前 一人前](../../uploads/rank3dbf8ea81e642.gif)
Magic側のインデックスも削除しても処理速度が変わらないなら
サーバ側で実行してみるとか
サーバ側で実行してみるとか
投票数:0
平均点:0.00
mizuno
投稿数: 58
![常連 常連](../../uploads/rank3dbf8e9e7d88d.gif)
お世話になります。
インデックスの削除はさけたく、サーバでの実行もできないので、現状のクライアントから実行する
方法をとりました。
処理速度向上の対策として、移行対象のファイルが、280万件のテーブル、140万件のテーブル、
その他のテーブル(約60本)とあったので、3つのショートカットを用意し、起動するTerm毎に移行処理を
別々に走らせるようにしました。
(280万件のテーブル、140万件のテーブルはグループコミットで、その他のテーブルはタスクコミット)
トータルで4時間半ほどかかっていたのが、2時間半を切るぐらいの処理時間になりましたので、
この方法で処理することにいたしました。
インデックスの削除はさけたく、サーバでの実行もできないので、現状のクライアントから実行する
方法をとりました。
処理速度向上の対策として、移行対象のファイルが、280万件のテーブル、140万件のテーブル、
その他のテーブル(約60本)とあったので、3つのショートカットを用意し、起動するTerm毎に移行処理を
別々に走らせるようにしました。
(280万件のテーブル、140万件のテーブルはグループコミットで、その他のテーブルはタスクコミット)
トータルで4時間半ほどかかっていたのが、2時間半を切るぐらいの処理時間になりましたので、
この方法で処理することにいたしました。
投票数:0
平均点:0.00
nkmt
投稿数: 1668
![長老 長老](../../uploads/rank3dbf8eb1a72e7.gif)
タスクコミットというのは、
トランザクション開始をタスク前の前にする事でしょうか?
グループコミットというのは、どんなタスク構造なんでしょうか?
トランザクション開始をタスク前の前にする事でしょうか?
グループコミットというのは、どんなタスク構造なんでしょうか?
投票数:0
平均点:0.00
mizuno
投稿数: 58
![常連 常連](../../uploads/rank3dbf8e9e7d88d.gif)
タスクコミット、グループコミットという表現が一般的かどうかわかりかねますが、
ここでの表現としては、
タスクコミット:トランザクションの開始 = タスク前の前
グループコミット:トランザクションの開始 = グループ
として話をしていました。
グループコミットは文字通りグループ毎にトランザクションをかける
設定になります。
グループ処理を設定し、トランザクションの開始をグループにすると、
右側の項目が有効になり設定したグループでbegin-commitします。
投稿した件の移行では、伝票日付の年度をグループとしました。
ここでの表現としては、
タスクコミット:トランザクションの開始 = タスク前の前
グループコミット:トランザクションの開始 = グループ
として話をしていました。
グループコミットは文字通りグループ毎にトランザクションをかける
設定になります。
グループ処理を設定し、トランザクションの開始をグループにすると、
右側の項目が有効になり設定したグループでbegin-commitします。
投稿した件の移行では、伝票日付の年度をグループとしました。
投票数:0
平均点:0.00
nkmt
投稿数: 1668
![長老 長老](../../uploads/rank3dbf8eb1a72e7.gif)
mizunoさん
バッチタスクに
グループ処理を付けると、トランザクション開始に
G=グループ を選べるんですね。
有難う御座いました。
(SQL始めて間もないし知らなかったです。)
バッチタスクに
グループ処理を付けると、トランザクション開始に
G=グループ を選べるんですね。
有難う御座いました。
(SQL始めて間もないし知らなかったです。)
投票数:0
平均点:0.00