バッチで大量更新を行う際の設計パターン - 理系学生日記
次のようなよくある前提があるとして、じゃぁどのように設計すればいいのかという話です。 +24 時間サービスであり、エンドユーザがどの時間帯でもサービスを利用している +エンドユーザ用サービスが参照するテーブルに対し大量の(例えば数十万〜数億レコード)をバッチで更新する +不整合があるデータをエンドユーザから可視状態にしてはならない 一括コミットが楽なのだけれど、大量のデータの一括コミットは禁じ手です。だいたいの場合は UNDO 領域が枯渇して、おなじみの ORA-1555 なんてのがアラートに上がって夜中に起こされる羽目になり、世の中を恨みながら暮らすようになります。 一括コミットが禁じ手であれば、分割コミットしかありません。UNDO 領域が枯渇せず、かつ、commit の負荷が大きくならない程度に、更新対象レコード数を小分けにしてコミットしていくことになります。 ここで問題となるのが、前
Cf ～カリホルニウム～ 同じプロセスを２個同時に動かしたくない～Windows～
Windowsでバッチ処理を自動でやらせていると、 とある処理が同時に動いてしまうことって良くありますよね。 同時にいくつ動いても問題ないプロセスはいいのですが、 ２個以上動くと困るプロセスも沢山ありますよね。 たとえば、vcbmounterとか、vcbmounterとか。。。 vcbmounterについては次回以降説明するとして、 今回は指定のプロセスが動いていたら、 しばらくプロセスが動くのを待たせてしまう処理を説明します。 まずは、動作中のプロセスを調べるコマンド、 「tasklist」・・・/fiオプションを使うとプロセス名でフィルタリング出来ます。 「timeout」・・・Windows2003Server以降しか対応していないが、秒単位でバッチ処理を待たせることが出来る有能コマンド（XP以前は「ping」コマンドで代用） 「exit /b」・・・Windowsでバッチの戻り値を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
