ホーム   フォーラム   FAQ
 
メインメニュー
ログイン
ユーザー名:

パスワード:


パスワード紛失

レコード削除、バッチタスクかSQLコマンドか

  • このフォーラムに新しいトピックを立てることはできません
  • このフォーラムではゲスト投稿が禁止されています
depth:
0
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 .2 .3 .4 .5 .6 .7 .8 .9 | 投稿日時 2017-6-9 10:30
nkmt  長老   投稿数: 1668
SQLサーバーのデータを
Magicの普通の削除バッチタスクで消すのと
SQLコマンドで消すのと比較すると
SQLコマンドの方が短時間に済みますよね!?

LOGを見ますと普通のMagicの作りでは
DELETE文が繰り返し発行されているのがわかります。

これもいずれ普通のMagicの作りでも
シンプルに1回だけ適切なSQL文が発行されるよう
ゲートウェイ?が改善、改良されるのを期待したいです。
投票数:0 平均点:0.00
depth:
1
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-6-9 11:04
Tanda  長老   投稿数: 2151
テーブルの全件レコードを削除したい場合は、DBDEL()関数が便利
ですよ。

テーブル内のレコードで、条件に見合ったものだけ削除したい場合
は削除バッチが便利です。

状況に応じて使い分けるといいですよ。
投票数:0 平均点:0.00
depth:
1
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 .2 | 投稿日時 2017-6-9 11:09 | 最終変更
nkmt  長老   投稿数: 1668
おはようございます。
いつもありがとうございます。
そうですね、全件削除はDBDEL

今回、SQLコマンド DELETE文で範囲指定削除していたタスクを
試しにバッチ削除タスクに変えてみたら、遅かったので
またSQLコマンドへと戻しました。

バッチ、削除、メインソース指定、範囲絞り1項目
といった指定の時に
DELETE ○○テーブル WHERE 売上日=20170609
といった単純なSQL文を1回だけ発行するよう
ゲートウェイ?が改善されるといいなぁと思った次第です。

今のゲートウェイは
DELETE ○○テーブル WHERE 売上日=20170609 and キー項目1=? and キー項目2=?
みたいなのを何度も何度も発行していて
うーん、なんだかなーって思いました。
投票数:0 平均点:0.00
depth:
2
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-6-9 11:16
Tanda  長老   投稿数: 2151
ログにはいろいろ書き込まれると思いますが、実際の体感速度は
それほど遅いとは思えませんが、1日の売上データを削除するのに
何秒くらい差が出ますか?
投票数:0 平均点:0.00
depth:
2
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-6-9 15:19
ISHIJIMA  長老 居住地: 静岡県  投稿数: 1827
これって削除しながら何か別の処理を行う時に為ではないでしょうか

投票数:0 平均点:0.00
depth:
1
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2017-6-9 11:29 | 最終変更
nkmt  長老   投稿数: 1668
一つ訂正致します。

 Magicの普通の作りではDELETE SQL文が大量発行されるのは
 事実だが、速度の違いを感じた理由は、SQLコマンドログを
 取っていた、というのも原因だと思います。

※プログラムをその後いくつか いじった為
 ログを取らない状態での比較はまだ出来ておりません。
投票数:0 平均点:0.00
depth:
2
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-6-9 11:36
Tanda  長老   投稿数: 2151
そうですね、ログをONにするとテキストの掃き出しが伴いますので、
結構な負荷が掛かると思います。

ログをOFFにして試してみられるといいですよ。
投票数:0 平均点:0.00
depth:
1
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2017-6-9 11:45 | 最終変更
nkmt  長老   投稿数: 1668
その後、試してみました。^^;

ログを取らない状態で
・SQLコマンドのDELETE文
・削除バッチタスク
を比較してみました。

2本のテーブルから、それぞれ50件程度を削除するのですが
前者が サッ サッ っと体感0.5秒で終わるのに対し、
後者は たら〜〜 たら〜〜 っと 体感2.0秒かかる感じです。

総件数も500件程度にしかならないです。

ノートPC 4500rpmのハードDISK

SQL Server 2012 EXP

64bit OS

メモリ8GB

今回このいわば表示用ワークファイルをSQLサーバーにしている
のが実は誤りで、並行実行テストのデバッグ用にSQLサーバー
のデータにしていたのですが、メモリWFへと変更します。
(なので当然普通のバッチ削除タスクになりますけど。)

私の言いたかった事は、ゲートウェイの改良を希望したい
という事です。

SQLサーバーの実データを削除する場合は、バッチ削除よりも
SQLコマンドの方が高速だという事は、正解でしょうかね?
投票数:0 平均点:0.00
depth:
2
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-6-9 11:59
Tanda  長老   投稿数: 2151
削除バッチが遅いというのはあまりあり得ないと思うのですが、
範囲指定のキーは正しく設定されていますか?

SQLコマンドの直書きは、他の何よりも早いと思いますよ。ただし、
デメリットとしては保守の手間が掛かりますね。
投票数:0 平均点:0.00
depth:
1
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2017-6-9 13:14
nkmt  長老   投稿数: 1668
はい、範囲指定はおかしくないです。

インデックスは1つだけ。日付項目。

それに From〜To 普通に範囲指定しておりました。

テーブル項目は、一つが10項目
もう1本が13項目でした。

SQLコマンドは
1.保守性で落ちる場合が有る
2.クロスリファレンスでひっかからない。
といったデメリットも有りますね。

最近はグルーピング合計や件数把握などに重宝しております。
また商品マスタを主体とした、ある期間の総在庫金額把握など。

従来の作りなら処理時間かかるような分が
SQLコマンドだと数秒で終わるといった事も有り
有り難いです。

と書いた所で一つ気が付きました。

作業ファイル代わりとしていたそのSQLサーバーのデータ

削除するバッチタスクで、物理トラン、トランザクション無し、
ロック無しで削除しておりました。

タスク前トランで再実験してみます。m(__)m

※普段の残すようなデータは、物理トラン、タスク前開始トランにしています。
投票数:0 平均点:0.00
depth:
2
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-6-9 13:19
Tanda  長老   投稿数: 2151
総レコード500件から90レコードの削除バッチなら、キーさえ
正しく効いていれば、おそらく一瞬で終わると思いますよ。

長くても1秒〜2秒でしょうか。
投票数:0 平均点:0.00
depth:
1
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-6-9 13:19 | 最終変更
nkmt  長老   投稿数: 1668
物理トラン、タスク前、即時ロックで再実験しました。

バッチ削除がSQLコマンドと近い速度になりました。

お騒がせしました。失礼しました。

ワーク的な扱いのSQLデータも今後はトランザクションかけたいと思います。

※もっともその処理が済んだら必要のないデータを
SQLサーバーで作る事は今後も少ないと思いますけども。

投票数:0 平均点:0.00
depth:
1
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-6-9 15:33
nkmt  長老   投稿数: 1668
そうですね。

WFの中身を一部クリアー

別端末で受注エントリーされると、
それを把握した当PGがWFを作り直して
縦、横の表にして表示。

当PGで様々な指示を行う!といった感じです。
投票数:0 平均点:0.00
depth:
1
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-6-9 21:51
pu_mahalo  長老 居住地: 大阪  投稿数: 775
こんにちは Puです

単純に速度だけを考えれば SQL文を直接発行した方が
早く削除できます。
Magicの場合はその条件にあったレコードを一度読んで
そのKEYを取得しDELETE文を発行するので
だからレコード後処理を削除する件数分通ります
ですので 削除件数をcounter(0)で表示できるんですね。

SQL文を発行したら全てサーバー側での処理になるので
トラフィックは発生しません

C/Sだったら大した差は出ませんが WAN越しで実行したら
差は体感できると思いますよ

でもそうするんだったらMagicで作る意味ないですからね
生産性の高さは実行スピード以上のメリットを享受できますので
でわ〜でわ〜
投票数:0 平均点:0.00
depth:
1
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2017-6-10 6:38 | 最終変更
nkmt  長老   投稿数: 1668
そうですね。
SELECT DELETE FETCH といったSQL文が
削除する件数分発行されていたような気もします。

Magicの従来の作り、SQL文を使った作り
それぞれメリット有りますので今後も場面に応じて
使い分けていきたいと思います。

Puさん、Ishijimaさん、Tandaさん レスありがとうございました。
投票数:0 平均点:0.00

  条件検索へ


Copyright (C) Magic Software Japan K.K. All Rights Reserved.
個人情報保護方針 会員規約