障害は突然やってくる。OracleDatabaseリカバリコンテスト

JPOUG#14で発表した内容になります。
Oracle Databaseの障害対応スキルアップのために、自社で実施した取り組みを共有いたしました。

Transcript

1. Oracle Cloud 失注への軌跡 ～ 努力は無駄にならない ～ しゃちほこオラクル倶楽部 第７回 西尾 孝之 障害は突然やってくる！ Oracle Databaseリカバリコンテストでチームのスキルを一段上へ！ 2025年9月12日 【JPOUG Tech Talk Night #14】 - Takayuki Nishio -
2. オーガナイザー紹介 | 西尾 孝之 / Takayuki Nishio 資格 ・ORACLE MASTER : Platinum DBA 2019, 12c , 11c , 10g , 9i , 8i ・AWS : Database Speciality , Data Analytics , Machine-Learning 認定証 ・マッターホルン登頂…4478m ・モンブラン登頂………4810m ・キリマンジャロ登頂…..5895m Oracleと山を愛するエンジニア(22年目) 2025 OCI Top Engineers 表彰
3. アジェンダ｜ チームの実践スキルアップ手法 DBリカバリコンテスト概要 1 2 3 想定障害シナリオ（基本編） 想定障害シナリオ（本当にあった怖い話編） 障害は突然やってくる！ スキルアップ実践手法
4. DB障害対応のスキルをどう鍛えるか？ ＜弊社の業務＞ 弊社はOracle製品の保守窓口として、お客様から多様な問い合わせを受け付けている。 ＜対象製品は様々＞ Database、Fusion Middleware (WebLogic,Forms and Reports) BI, Golden Gate , Oracle Cloud 等 ＜問い合わせの内容は？＞ 製品の使い方、運用中のエラー、障害 ＜普段のスキルアップは？＞ 扱う製品の導入訓練（複数OS,複数Ver） 問い合わせナレッジの共有 ナレッジベースでの実施確認 エラー発生時にどんなログをみるか、どんな対応をするか
5. 課題 人によって製品知識に偏りがでる。 ⇒ Oracle製品を扱う以上、 Databaseは当たり前として標準以上のスキルを身に着けてほしい 構築訓練は実施しているが、障害対応で「手を動かせるか」は別。 ⇒ スピード感をもった対応ができるようにしてほしい → リカバリコンテストで楽しく障害対応を学んでみよう！
6. リカバリコンテスト実施概要 ＜目的＞ 楽しみながら学べる場をつくる 実践的な障害対応スキルを強化 今までの問い合わせログの内容を自然に共有 ＜ルール＞ 参加者は1人で対応をする マニュアルや、MOS検索といった公式ドキュメントは参照OK（ChatGPT不可） ＜採点基準＞ 復旧までのスピード データ損失の有無 ※バックアップスキルも含めて確認 ＜環境＞ Oracle Database 19c を使用 OCIで障害発生済みのDBを構築。サーバをコピーすることで、人数分の環境を簡単に作成。 ＜発生させた障害＞ 開催者側でシナリオを想定し、障害を発生させた
7. 想定障害シナリオ：基本編
8. 想定障害シナリオ｜ 基本編 突然DBインスタンスが停止した。 ※制御ファイルが1つ破損 このシナリオで、DB障害に対する基礎を確認。 ・インスタンスのステータスは？ ⇒ どの状態まで起動できている？ ・障害が発生したら、何から調査する？ ⇒ アラートログをみる ・エラー番号の調査方法 ・アーキテクチャの基礎が理解できているか？
9. 想定障害シナリオ：本当にあった怖い話編
10. 想定障害シナリオ｜ 本当にあった怖い話編 ログマイナーを実行したら、DB止まったんだけど execute dbms_logmnr.add_logfile( logfilename=>'/u03/app/oracle/redo/DB0910_5CW_NRT/onlinelog/o1_mf_1_nd2zwllc_.log' ,options=>dbms_logmnr.NEW); ログマイナー実行コマンド → SQL*Plusで実行するところ、OSコマンド上で実行してしまう。 「logfilename=>オプション」が Linuxのリダイレクトになってしまった。 結果、REDOログファイルのサイズが 0バイトに、、、 ※REDOログファイルは多重化なし
11. 想定障害シナリオ｜ 本当にあった怖い話編 GUIツールでデータを削除するつもりが表を消してしまった サンプルデータ
12. 想定障害シナリオ｜ 本当にあった怖い話編 SELECT文を実行したらエラーになる。SELECTできるテーブルもある。 SELECT * FROM employees WHERE emp_id = 10001; エラーになるSELECT文 → 特定の表領域（データファイル）破損。 確認したところバックアップがない状況。 SELECT * FROM customers WHERE cust_id = 10001; エラーにならないSELECT文
13. 想定障害シナリオ｜ 本当にあった怖い話編 半年ぶりにDBサーバのOSを再起動したら、アプリケーションからDBに 接続できない。DBサーバ上のSQL*Plusは接続できるんだけど SQL> SELECT status FROM V$INSTANCE; ⇒ OPEN であることは確認できる。 DBサーバ上でSTATUSを確認した結果、OPEN → lsnrctl status で確認すると、DBサービスが登録されていない → 初期化パラメータ local_listener に 接続識別子が指定されている → tnsnames.oraから 上記に指定された接続識別子が消えている （メンテ時に他サーバのファイルで置き換えていた）
14. 実施風景 ｜ 緊張感は半端ない。ついついキーボードをたたく音が強くなる。 たまに聞こえる勝利の雄たけび タイムアップ後の捨て台詞。 あと10秒あれば！！！ わかってたのに！！！
15. こんな気づきがありました｜ 複数インスタンスが扱えない（環境変数ORACLE_SIDの理解不足） ⇒ 普段 Fusion を扱ってる若手。LinuxやDBの経験が少ない RMAN苦手意識。やっぱりバックアップはオフラインでしょ信仰（簡単だから） ⇒ 便利っぽいのは分かっているが、OSコピーでおわる簡単さに惹かれている 意外に新機能は若手のほうが知っていることも。 ベテランのほうがあえて回り道の障害対応。 ⇒ 知識のUPDATEは必要。 知識としてリカバリ方法が分かっていても、なかなか実践が難しい。 ⇒ リカバリコンテストに繰り返し参加！！
16. ありがとうございました Thank you