はじめに
障害で「ORA-00257: アーカイブ・エラー」が発生した。
過去に言われるがままに対応した記憶があるけど、正直コイツがなんなのかよくわからなかった。
で、今日、先週おきた↑↑のアラートが再発したようで何が起きたらしいが、
そろそろコイツなんなのかわからないと話題に入れないので調べることにする。
アーカイブログとは?
によると、
アーカイブログモードとは、障害発生直前までの復旧や、運用中のバックアップ取得を可能にするためのデータベースの運用モードです。
本番環境では、たいていの場合「障害発生直前までの復旧」が必須要件であるため、原則的にアーカイブログモードでの運用が必須です。
MySQLにとってはbinlogみたいなものか?
アーカイブログ運用の注意点
続けて、肥大化の懸念について言及があった
アーカイブログモードでは、データベースに対して適用された更新履歴が失われることがないように、
更新履歴を記録したアーカイブログファイルが定期的に出力されます。
このため、運用を継続するとアーカイブログファイルの数が増えてゆき、ディスク容量を圧迫するため、定期的に削除を実行することが必要でした。
なんだってRMAN、すごいじゃないか!
しかし、Oracle Database 10g以降では、RMANで適切にバックアップを取得し、
適切なサイズのフラッシュリカバリ領域を構成すると、
アーカイブログファイルの定期的な削除作業をOracle Databaseが自動的に実行してくれるため、
通常運用ではメンテナンス作業は不要です。
今回障害が起きたってことはRMANが適切なサイズのフラッシュリカバリ領域を構成できなかったからってことかな?
豆知識:RMANとは?
Recovery Manager(RMAN)とは、データベースでバックアップおよびリカバリ・タスクを実行し、
バックアップ計画の管理を自動化するOracle Databaseクライアントのことです。
Recovery Managerによって、データベースのバックアップ、リストアおよびリカバリが大幅に簡単になります。
豆知識2:フラッシュリカバリ構成とは?
すぐにリカバリできるようのデータ置き場なのかな?それはすごいね。
MySQL的にはスレーブDBみたいなものなのかもしれない。。。ちょっと違うけど。
データベース構成ファイルとは別のディスク装置上に、フラッシュリカバリ領域(11.2より高速リカバリ領域に名称変更)を構成します。
アーカイブログでの適切な運用について
やり方は3つ。
RMANによる定期的なデータベース全体バックアップ
RMAN起動して、バックアップ。まぁ…MySQLでも日次再起動やってるからいつものことかなと。
RMAN> BACKUP DATABASE;
RMANのバックアップ保存方針(RETENTION POLICY)の設定
"7日前までの状態に復旧できるだけのバックアップを保存する場合"とか
"過去2世代分のバックアップを保存する場合"とか、
RMANの設定項目であるバックアップ保存方針(RETENTION POLICY)を運用ポリシーに合わせて設定する。
binlogでも保存期間を設定するから、まぁこれもそこまで珍しくないかなと。
なお、もっとも一般的な要件は、「障害発生直前に戻せればよい」だそうなので
REDUNDANCYを指定して、過去1世代分のバックアップを保存しておけば十分です。
とのことです。
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
フラッシュリカバリ領域を構成する&バックアップファイル、アーカイブログファイルの出力先をフラッシュリカバリ領域にする
↑↑の説明を見ると当たり前かもしれないけど、フラッシュリカバリ領域は作らなくてもいいそうなので
参考サイトではあえて説明してくれてるんだと思う。
あれ?アーカイブログエラーってどういうときに起きるのかよくわからなかったぞ?
アーカイブログがあるとすぐに復旧できるってことが分かった。
で、そいつがなくなってもたちまち困ることは無いってことはわかった。
(ただ、アーカイブログを削除すると即座の復旧ができなくなるので、再度バックアップ取り直してアーカイブログの取得を再開する必要がある)
あとは、、、アーカイブログがおかしくなったときはどうすりゃいいのか、と
アーカイブログがおかしくならないようにどうするかってのはちょっと考える必要がありそうだ。