- - PR -
ファイルの先頭から削除
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-08-25 09:40
おはようございます、カーニーです。
まとめレスで失礼します。
残念ながらファイル名は事前に指定できないのです。 (PIDを使ってプロセス単位に生成される)
うーん、技術的な可否はともかく、プロダクトの保証対象外と言われてしまいそうで気が進まないですね・・・。 ただ選択肢の1つとして、もう少し調査してみようかと思います。 良いアイディアをどうもありがとうございました。 | ||||||||
|
投稿日時: 2004-08-25 12:45
> うーん、技術的な可否はともかく、プロダクトの保証対象外と言われてしまいそうで気が進まないですね・・・
自分で言っておきながらですが、私も気が進みませんね。 私なら、「ディスク使用量を監視して、閾値を超えたら、コネクションプールのリセット&クローズされたログファイルの回収」を何とか自動化できないか、という方向で検討するかなぁ。 | ||||||||
|
投稿日時: 2004-08-25 16:02
Oracle のことは Oracle で、ということで少し調べてみました。
以下に同様の質問がありましたが、やはりアーカイブログファイルを自動的に削除するという方法はないとのことでした。 http://fukkey.dyndns.org/pins/ora/010531/31319.html けれども、Oracle 8i 以降で提供されている RecoveryManager (RMAN) を使うと、Oracle サービスを動作させたまま他のマシンにアーカイブログを転送しつつ、転送が済んだものは Oracle サーバマシン上から削除できるようです。 これが最も現実的な解に思えますがいかがでしょうか。 (ただし、Oracle の設定としては割と高度な部類に入りますのでご注意ください) 無論、一つのアーカイブログが巨大化しないようなトランザクション設計やコネクションプーリング設定に留意することも重要です。 | ||||||||
|
投稿日時: 2004-08-25 17:11
Oracleよりの話ですね。
ログって話の流れからすると「トレースログ」ですよね。 毎晩DB停止のスケジュールが存在するならば、 その際にログも掃除すればOKです。 いや24時間稼動だ!というのであれば、 うぅぅぅん.... 憶測ですよ! ALTER SYSTEM SET USER_DUMP_DEST = xxxxxx でログの出力先を変えます。 ただし、既存セッションには有効では無いので1晩寝かせます。 次の日、再度 ALTER SYSTEM SET USER_DUMP_DEST = xxxxxx で出力先フォルダーを元に戻しますが、その前に昨日の ログファイルを退避します。 ってのはどうでしょ。 浅知恵なのでご注意ぅお! | ||||||||
|
投稿日時: 2004-08-25 23:54
惜しいです! audit_trail=os の監査ログでした。 あと僕の場合、特定のシステムに従事しているわけでなくパッケージ製品のほうなんで、運用に多くの前提を置くことができないのが辛いところです。 いずれにしても、皆さん、ご意見をどうもありがとうございます。 色々な考えを聞くことができて、とても参考になります。 | ||||||||
|
投稿日時: 2004-08-26 01:56
「今さら」な感がありますが。
そりは無理と思うです。 ファイルシステムそのものを変えなくてはなりません。 「カーネルソースにちょっと手を入れる」ですむ話じゃなくて、 「カーネルを大幅に書き換える」になると思うです。 # (ガベージコレクションがはじまる前の)LFS みたいなのだと # わりと簡単そうですが、全く実用性を欠いたファイルシステムに # なりそうです。 | ||||||||
|
投稿日時: 2004-08-26 11:19
ログローテーションを使えば済むような気もします。
(例) /etc/logrotate.d/orahogeを作ります。その中身は、 /var/log/orahoge/* { weekly rotate 8 missingok postrotate /usr/bin/killall -HUP orahoge endscript } orahogeの下のファイルは皆リネームされるので、postrotateか別のcronでリネーム後のファイルを移動すればと思います。 |