怖がっトラブルシューティングの経験が一度メーター

保守契約されているが、病院の重要性が急激に増加につながるため、肺炎の武漢は、役に立たないですが、商用の関係はまだここにいる。私たちはツアー号から開始する前に、病院が毎日行う協力を継続するために、同社はまた、配置された1検査。

2020年2月7日には、データベース・ログ・メッセージをチェック。やって切断前の僚友の実装ので。サーバログというカットを思い出させるために存在しています。

その時、ログは理解していないカットメカニズムです。常に正常な状態にカットされた後のメッセージ-20201119ファイルを考えます。

だから検査ファイルとメッセージ-20201119ファイル内のメッセージを見ています。

今日までは、2月に理解するために次のカットのログメカニズムを行うため。チェック設定ファイルの後、7日間のログ切削時間を見つける第七たいが、結果は新しいファイルの終わりとしてカット今日の日付にカットを作成することです

これまでのところ、開始番号19、すべての失われたすべてのログから発見されました。

logrotateの-d -vを通じてデバッグ/etc/logrotate.conf。

結果は、通常のメッセージ-20200202ログファイルと削除メッセージ-20201119ファイルを作成し実行しています。

しかし、新しいログファイルを作成するために、まだ役に立たない、デバッグモード実行logrotateのオフ-dターンを削除

疑い、それが書かれたか削除されているかどうかをディスクの問題が失敗の原因となった。だから、DF -h

結果は、ハングが住んでいたです。

私はどのような状況、日ドロップします。ディスクを切った何。

NORああ、19社の、今のビジネスは、ディスクがハングアップした場合、事業ああを保持すべきではない、正常です。

コールの実装前に、同僚の子供たちが、同僚は、子どもたちが作品のNFSは、RMANバックアップを行う十分なストレージ、ディスクボリュームプラグはなかったと言います。

チェックの/ etc / fstabには持ってない、NFSディスク/バックアクセスできないカタログ。

しかし、showmountは-e 10.20.10.17

これは、ディレクトリのNFSサーバーを表示することができます。

マニュアルだけ-t nfsの10.20.10.17/back /バックに成功マウント。

しかし、障害やその他のパラメータをマウントTIMEO RW、BG、wsizeの、RSIZE内部元の/ etc / fstabファイルの使用。

その後のcrontab -l内の検査を実行するためのバックアップ計画を考える。RMANバックアップです。

PSはAUX | grepをRecovery Managerは、|トイレ-lの結果は、65個のバックアッププロセスがライブハングことを示しました。

一つずつオフRMANのプロセスを殺します

突然感到后怕.1月22到现在2月7号10多天,rman一直是失败的.是不是归档文件一直没有删除.到时候占满空间数据库会拒绝服务.

赶紧进入sql里面

select * from v$flash_recovery_area_usage

100g空间已经使用了76G.再过一周就会爆掉.

这个时间点,医院停业务估计会被狠狠的屌一顿.真的后怕

回头想想,自己有以下问题.

1) 22号医院重启了rac2服务器,导致日志文件里面产生了大量的信息.所以第一天巡检的时候,我忽略是22号的所有日志.包括当天最后一条nfs故障的告警

而且由于心理盲区,认为开始巡检的1号之前的日志和自己没有关系,7天的巡检都没有观察到这一点.

2) 巡检只按照离职同事发我的巡检文档工作,其中没有提及到rac2的rman备份,只有一台单独服务器提供的expdp备份,所以并没有检查服务器的计划任务.忽视了归档日志这一隐患.

希望这篇文章能提醒自己,运维工作看起来简单.但是不上心认真负责,风险很大.特别是接收其他人遗留的项目.

至于mount加参数后无法挂载的问题,今天太晚了 每天解决.