JMCは非常に便利なツールなんですけどね。
ライセンス形態がチョット微妙なので、ウチの商用環境では使わずに、JMXで代用です。
Oracleの仮想環境下でのCPUライセンスの考え方って、仮想環境が動作するすべての物理サーバのCPUコア数分って考え方だったと思うので…

ｗｗｗｗ、ありがちです。

あと、一部の設定ファイルが共有ディスクじゃなくて、ローカルにおいてあって、バッチがとまるとか。
クラスタ制御コマンドのタイムアウト時間内にチェックディスクが終わらなくて、そのままクラスタダウンとか。

まぁ、良くありますよね。

Impress の家電Watchで出てましたね。

http://kaden.watch.impress.co.jp/docs/column_review/kdnreview/20140415_644251.html

タイマ付きではないですけど。
１．５諭吉程度なので、安くなりましたよね。

早く決めてくれ。
年末調整の改修が間に合わん。

ありえそうなパターンでひとつ。

たとえば、債権債務管理と支払管理が別々のサブになっていて、
銀行の支店統廃合があって、口座マスタのメンテナンスをした場合、

・債権債務側の仕様がインタフェース時に有効な口座情報
・支払側は支払日において有効な口座情報

ってな感じだと、インタフェース時には口座が有効だけど、
支払時には支店がなくなって口座マスタが取れない、なんてことが起こりえます。

で、支払なんで、夜間バッチでエラーではじいておしまい、なんてことをすると、
支払できないなんてことが発生し、信用問題ですよね。
なので、こういう場合には、夜間に開発者にエスカレして対応するんですよ。

実際には、データの状態を確認して、いったん支払を起こしておいて、
翌朝、一番に顧客（ユーザ）に確認をして、データにパッチを当てるなんてことになるんですけど。

#2581459のコメントにもあるように、
サブシステムごとに導入年度や利用者、ベンダが違うから、
I/Fの仕様齟齬でありえないデータを突っ込まれて、バッチがずっこけるなんて、
ままあることですよ。

別に24/365が要件のシステムの話してるわけじゃなくて、
24/365じゃないシステムだって、夜間の繰越処理とかがあれば、こけたら、
翌オンラインに影響があるから、夜間に対応するの当たり前でしょ。

データ起因のソフトウェア停止って、冗長化関係ないじゃん。
腐ったデータを食べて、エラーログだけ出して、後続を実行てワケにはいかないシステムもあるのよ、世の中には。

いや、いくら冗長化しても夜間バッチこけたら、対応しないといけないでしょ。
業務システムのバッチ処理がこける原因って、データ要素が大きいから、監視するだけの運用者じゃ対応できんもの。
それに契約の関係で重要情報の閲覧権限もってないこともあるし。
世の中、そんな簡単じゃないのよね。

ウチも移行をほぼ終えたけど、一部アプリケーションの関係で残さざるをないヤツらがいるのよね。
どことも接続していないから、リスクは低いんだろうけど、全廃は難しいわ。