そのSQLCODE覚えたぞ・・・！！とアヌビスのスタンドが出そうだ。
アーカイブログなら動かせばいいんだが、アクティブが溢れたときが
やばい。マニュアルの対策がはっきり言って意味フ。
http://publib.boulder.ibm.com/infocenter/db2luw/v8//topic/com.ibm.db2.udb.doc/core/rsql1700.htm
（SQL1762を検索）
合っているかわからんけど、こうなった場合のアクション
・archivelog コマンドでアクティブログをクローズする
→ http://publib.boulder.ibm.com/infocenter/db2luw/v8//topic/com.ibm.db2.udb.doc/core/r0004476.htm?resultof=%22%41%72%63%68%69%76%65%22%20%22%61%72%63%68%69%76%65%22%20
・archivelog コマンドのための接続すらできない場合
空き容量を広げる
・空き容量を広げられない場合（HA停止できないなど）は
のこりの容量に収まるようにログの設定を変える。（小さくする）
しかし、これは最後の手段である。
（LOGPRIMARY または LOGFILSIZ を変える）
・ログの設定を変更した時点でログが初期化されるので、diagで確認する
・オフラインバックアップを取得し、データを保全
・LIST HISTORYコマンドでバックアップ時のアクティブログを確認する
→ http://publib.boulder.ibm.com/infocenter/db2luw/v8//topic/com.ibm.db2.udb.doc/core/r0001991.htm?resultof=%22%4c%49%53%54%e3%80%80%48%49%53%54%4f%52%59%22%20
（ Earliest Log からCurrent Logのこと）
・db2stopし、不要なアクティブログを捨てる
・db2startし、diagにエラーが無いことを確認する。
・ログの設定を戻す（LOGPRIMARY または LOGFILSIZ）
・db2stop ＆ db2start
アーカイブが溢れた時、LOGPRIMARY の数を超えて容量いっぱいまで
アクティブが溢れるのは何故だろうな。なんか設定あるんだろうか。
参考リンク
http://db2watch.com/wiki/index.php/%E3%83%AD%E3%83%BC%E3%83%AB%E3%83%95%E3%82%A9%E3%83%AF%E3%83%BC%E3%83%89%E5%9B%9E%E5%BE%A9%E3%81%99%E3%82%8B%E3%81%AB%E3%81%AF
http://coredump.news-site.net/tech/db2/recovery/db2_recovery_contents.html
> アクティブが溢れる
LOGSECONDが大きめに設定されているのではないでしょうか。
LOGPRIMARY 6
LOGSECOND 4
で定義されてんですけどねぇ・・。(´-ω-`)
これだと、5000*4K*(6+4)= 200MB しょ・・。
なぜかFSいっぱいまで使い切った挙げ句に
くたばるんですよね。
アーカイブ容量を広げてやると、そこに自動退避されるときもあるんだけど。
DB2のバグの可能性も考えられますので、IBMサポートに連絡されるのが良いと思います。
[DB2 LUW] アクティブ・ログ・パスのログ・ファイル数
https://www.ibm.com/support/pages/db2-luw-%E3%82%A2%E3%82%AF%E3%83%86%E3%82%A3%E3%83%96%E3%83%BB%E3%83%AD%E3%82%B0%E3%83%BB%E3%83%91%E3%82%B9%E3%81%AE%E3%83%AD%E3%82%B0%E3%83%BB%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E6%95%B0
EDUから参照されている場合は再利用できないので、新規作成しちゃう、ってのが設定数より増えるパターンのようですな。
HADRやpureScaleではさらに別の理由で増えるとのこと。ログ容量お見積りの際には注意が要りますな。