「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
バッチEXEの実装方式
注意点 †
バッチ処理の方式を検討する上で以下の点に注意する。
- 例えば１万件の処理を行うにあたり、１万件分のデータをメモリに保持するよう処理を実装する。
すると、ページングによる性能劣化や、メモリ リーク、アウト オブ メモリ例外が発生する。
- シーケンシャル アクセスの中間ファイルを使う概念が無く、全てデータベースへの入出力で処理を行う。
すると、無駄なDBMSとのプロセス間通信のラウンドトリップや、ランダム アクセスで性能が劣化する。
- トランザクション分割の概念がなく、１つの巨大なトランザクション処理を行う（ロング トランザクション）。
すると、（ロング トランザクションでは）ロックを長時間ホールドしたり、ロールバックに長い時間がかかる。
- リランを行う概念がなく、１レコードでも失敗すると全ての処理が失敗する。
すると、リラン時に、常に最初からの開始となってしまうため、
処理時間が長いバッチは時間内に処理を完了することができない可能性がある。
- 並列処理前提のプログラムと単一処理前提のプログラムの違いが分からずに実装する。
すると、後々、処理の多重化（システム リソースを使い切って処理時間を短縮すること）などのチューニングができなくなる。
- 実行ファイルを分割する概念がなく、全て１つの実行ファイルで処理する。
すると、タスクを組み合わせて１つのジョブにすることができなくなる。また、リランに時間がかかることもある。
バッチ処理フレームワーク †
Spring Batch を参考に方式を参考にして、上記の問題を起こさない、多重化＆リラン可能なバッチ処理方式を説明する。
Spring Batchの多重化＆リランは、オンライン側を排他で止めておくことが前提で、反復不可、ファントムは発生しない前提とする。
トランザクション範囲 †
反復不可、ファントムの問題は無い前提のため、トランザクション範囲は、下図の（処理 → Write）の範囲とする。
（コミット インターバル分、データを渡す）
↓
Read ────>（処理 ──> Write）
↑ │
└───────────┘loop
多重化方法 †
- バッチEXEを多重起動する（Javaと異なりマルチスレッド化する必要はない）。
- それぞれのバッチEXEが処理する結果セットを分割する。
- これには、バッチEXE起動時に結果セット取得に使用する
検索条件（分割キー、主キー範囲）のコマンドライン引数を変更する。
リラン †
- 異常終了時は、所定のディレクトリに次回、再開の行番号を出力する。
- 多重起動することを考慮すると下記を１つのファイルで管理すると良い。
- 「結果セット取得に使用する検索条件」
- 「再開の行番号（処理済みの行番号）」
分散多重処理対応 †
複数のバッチ処理サーバ。
分散多重処理の状態の一元管理には、
別途管理データベースなどの利用が必要になることがあり大掛かりになる。
バッチ処理のフロー †
集計処理の場合、DBMSを使用しない場合は、コミットインターバルは不要。
参考 †
オンラインバッチ処理方式 †
Windows NT系カーネルでは、
- コマンドライン起動で
- startコマンドを用いなければ同期実行
- startコマンドを用いれば非同期実行
が可能である。
- Processクラスを使用する場合は、
- Startメソッドを用いれば非同期実行
- WaitForExit?メソッドを用いれば同期実行
となる。
なお、非同期実行を行う場合、連打できてしまうので、
Semaphoreなどを使用して多重実行を防ぐ必要がある。
同期実行 †
ASP.NETからの同期実行 ＆ セマフォ を使用してバッチの多重度を制御することも可能であるが、
これではオンライン処理が待機によりスレッドを占有してしまい同時実行性が低下する場合がある。
非同期実行 †
非同期実行では上記問題は発生しないが、場合によっては、
多重度・リトライ、結果通知などの制御・実装が必要となってくる。
- 非同期実行で多重度・リトライなどの制御が必要になる場合は、
キュー（ディスク、RDB、MQなど）を用意して多重度・リトライを制御することも可能である。
- 実行結果の通知方法（プッシュ型通知、プル型通知）を検討しておく必要がある。
多重度・リトライ、結果通知などの制御・実装が必要となる場合、”Open棟梁”の非同期処理サービスを利用できる。
データアクセス †
大量データ †
大凡、下記の選択肢がある。
配列バインドの実行方法 †
配列バインドは、ODP.NETやHiRDBなど、ごく少数のデータ・プロバイダでサポートされている。
- サンプル・コード（ODP.NET）
- SQL定義
INSERT INTO XXX(AAA, BBB, CCC) VALUES(:P1, :P2, :P3);
- コード
// 配列データを作成
object[] temp1 = new string[] { "aaa", "bbb", "ccc" };
object[] temp2 = new string[] { "aaa", "bbb", "ccc" };
object[] temp3 = new string[] { "aaa", "bbb", "ccc" };
// ODP.NETの配列バインドの場合は、ArrayBindCountを指定
((DamOraOdp)this._dam).DamOracleCommand.ArrayBindCount = temp.Length;
// ODP.NET配列バインドの場合は、OracleDbTypeの型情報が必要
((BaseDam)this._dam).SetParameter("P1", temp1, OracleDbType.Varchar2);
((BaseDam)this._dam).SetParameter("P2", temp2, OracleDbType.Varchar2);
((BaseDam)this._dam).SetParameter("P3", temp3, OracleDbType.Varchar2);
また、動的パラメタライズド・クエリ分析ツールも、この「配列バインド」をサポートしている。
- 動的パラメタライズド・クエリは、XML編集を伴うので、
XMLタグの数が多くなる場合（100タグ以上が目安）、性能が劣化することがある。
- このため列数が非常に多いテーブルでは更に問題となり易い。
- このようなテーブルに大して動的パラメタライズド・クエリを
連続実行する場合、APサーバ側に負荷がかかり、ボトルネックになり易い。
- 大量データ更新を行うバッチ処理で問題となり易い。
- 自動生成されたUpdate文は、全カラム分のXMLタグを持つ。
- しかし、一度パラメタライズド・クエリを実行するとCommandオブジェクトにパラメタが設定されたままになるので、
各DamのCommandオブジェクト プロパティから各データプロバイダのCommandオブジェクトを取得して、
Command.Parameters.Clear()メソッドを呼び出し、この後、パラメタを再設定すれば良い。
- サンプル・コード
なお、この処理は、Commandオブジェクトのクリアが可能な自作Daoで実装する必要がある。
object obj;
// 動的SQLを読み込む場合。
this.SetSqlByFile2("DaoShippers_D1_Insert.xml");
// この状態では動的SQL（IsDPQプロパティを確認）。
System.Diagnostics.Debug.WriteLine(this.GetDam().IsDPQ.ToString());
// 実行１回目
this.SetParameter("CompanyName", "１回目");
this.SetParameter("Phone", "１回目");
obj = this.ExecInsUpDel_NonQuery();
// 以降は静的SQLとなる（IsDPQプロパティを確認）。
System.Diagnostics.Debug.WriteLine(this.GetDam().IsDPQ.ToString());
// 前回の実行で設定したパラメタ（Command.Parameters）をクリア。
((DamSqlSvr)this.GetDam()).DamSqlCommand.Parameters.Clear();
// 実行２回目
this.SetParameter("CompanyName", "２回目");
this.SetParameter("Phone", "２回目");
obj = this.ExecInsUpDel_NonQuery();
// 前回の実行で設定したパラメタ（Command.Parameters）をクリア。
((DamSqlSvr)this.GetDam()).DamSqlCommand.Parameters.Clear();
// 実行３回目
// ・・・
DataSet?、DataTable?を使用したバッチ更新方式 †
概要 †
- 一般的に、DataSet?、DataTable?を使用したバッチ更新処理は以下のように実装される。
- 本フレームワークでも、この方式のバッチ更新処理をサポートする。
- 自動生成Daoを利用して処理を実装すれば、実装は更に容易になる。
- DataSet?、DataTable?の「AcceptChanges?」メソッドを実行し、DataSet?、DataTable?を編集する。
（「Fill」メソッドで充填したDataSet?、DataTable?は「AcceptChanges?」メソッド実行済みの状態になっている。）
- 編集結果は、DataRow?の「RowState?」プロパティから確認できる（追加、更新、削除のステータスを検出する）。
- 追加：DataRowState?.Added
- 更新：DataRowState?.Modified
- 削除：DataRowState?.Deleted
- 楽観排他の実装をサポートするものに、以下の列挙型がある。
これらの機能を活用することで、DataSet?、DataTable?を使用したバッチ更新処理は、DataAdapter?の自動生成に頼らずとも容易に開発可能である。また、本フレームワークの
バッチ更新処理（C/S２層）のサンプル プログラムは、
「～ \root\programs\C#\Samples\2CS_sample\DenDaoAndBatUpd_sample」
に配置されているので、これを参考にするとわかり易い。
注意点は、複数ポストバックに跨ってデータ編集を行うため、編集中のDataSet?、DataTable?をSessionなどに保持する必要があることである。この場合、サーバ メモリの消費量などに注意が必要である。
補足 †
- .NETでは、CommandBuilder?により、バッチ更新用DataAdapter?の自動生成がサポートされ、
DataAdapter?の「Update」メソッドにDataSet?、DataTable?を渡すことによりバッチ更新が可能。
- しかし、CommandBuilder?には以下のような問題があり、本フレームワークでも、この方式はサポートしない。
- SqlCommandBuilder?仕組みを知らないとコードを理解し難い。
仕組みがブラックボックス、この方式を採用している例が少ない。
- テーブル単位のSELECTにしか対応していない。
JOINのSELECTでは利用できないため、全体の方式を統一できない。
- count = dataAdapter.Update(dtClient)で、
どの行がタイムスタンプアンマッチになったか？などが把握できない。
- INSERT処理
- IDENTITY属性のあるカラムもINSERT文に含めてしまう。
- 新規行を追加するだけの場合、SQLのINSERT文を発行した方が効率的。
（参照処理を伴わない、更新処理全体に対して言える。）
- 楽観排他方式
- 全列を旧行バージョン情報で比較する楽観排他方式
- 性能的に問題（WHERE文に全カラムを含めるため）。
- SQLトレースも上記のパラメタが多くなるので分かりにくくなる。
- timestamp列を含んだ更新ロジックを生成する機能は、サポートされていない。
- また、GETDATE関数などをSQLに含められないため、SQLで
柔軟に更新日付を付与したり、タイムスタンプを更新したりできない。
※ ただし、マスタメンテなど限られた範囲で、CommandBuilder?は有効。
参考 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
