#odc16 DB Upgradeの極意: アップグレードのリスクを軽減!データベーステストのベストプラクティス @Oracle Database Connect 2016まとめ

「Oracle Database」のエンジニアを対象にデータベース運用のためのテクニックなどに関するノウハウを紹介するイベントOracle Database Connect 2016に参加してきました。

その時のアップグレードについてのセッションのまとめです。

日本オラクル株式会社

諏佐 嘉之様

アップグレードの意義とは

• システムの信頼性が重要される中でアップグレードやパッチ適用は運用上避けて通れないタスク

障害の未然防止

• パッチを計画的に適用しておくことで、未然に障害を防げるかもしれない
• セキュリティパッチの適用はシステムやサービス、データを攻撃から守るためにも必須

例

• Exadataのお客が遭遇した不具合の内70%は既存のパッチで修正済みだった
• あるお客における障害を精査したら1/3はoracleの製品の不具合だったが、9割は既知の問題だった。また、半年前に修正パッチが出されていた
  • このお客は定期的なパッチ適用を運用に取り組むことにした
  • パッチ適用工数の削減なども考案している

アップグレード戦略を立てる

• ライフタイム・サポート・ポリシー、不具合修正ポリシー、猶予期間がわかっていないとパッチをつくってくれないかもしれない
  • プレミアサポート期間とextendサポート期間は無条件で出すわけでなく、不具合修正ポリシーにのっとって出される
• リリース/スケジュールを把握し、アップグレード戦略を立てる
  • extendedサポートは場合によっては無償期間でサポートされることもあります
  • 新機能積極採用型：11.2.0.4を使っているが、12.2が出たらすぐに移行する
  • 有償extended Support最大限活用型：extended supportが切れたら移行する
  • リスク最適型

アップグレードにおけるリスクはどう軽減するか

• リスクはシステムを停止しなければならないのと、アプリケーションの挙動が変わってしまうリスクがある
• 停止時間を短縮
  • パラレルアップグレードやRACのローリングアップグレード、GoldenGateなどを使ったりする
• 挙動の変化を事前に察知
  • テストをする

躊躇ポイント

• テストに膨大なコストがかかる
  • 非互換調査など影響範囲がわからない
  • 人海戦術による手作業テストが主体
• 長期間かかる上に予定期日をオーバーする
  • アプリケーションの準備、アプリチームの連携が難しい
  • 全て手作業で実施するため見積もり以上に期間がかかる
• リリース後にトラブルが起こる
  • 実際にはSQLのテスト網羅率やシナリオの再現性が低く、パフォーマンスの劣化やエラーが発生
  • テスト一回分の時間しかそもそも確保していない

テストの制度を上げる手法を考える

テストを自動化する

• アップグレードや移行、新機能導入などインフラ変更に伴うテストを自動化するRealApplicationTestingを使ってテストをする
• 本番環境でキャプチャしたデータを用いて検証環境で再生できる
• SQL Performance Analyzer(SPA)
  • 実行計画や単体性能、SQL互換性のチェックが出来る
• Database Replay
• SPA Quick Check
  • 本番環境の制御されたセッションを用いてクイックにSPAテストする
• Consolidated Replay
  • DB統合する時に、ワークロードを積み重ねて流して見る機能

demo

• 11.2.0.4 → 12.1.0.2にアップグレードしてみた場合のSPAを実施してみる
• CloudControlからSQLチューニングセットを選択して11gのSTSを作成する
  • カーソルキャッシュからとるのと、一定期間キャッシュする方法の2種類選択できる
  • 管理DBからもSQLが流れるがアプリだけに絞るなどのフィルタリングも可能
• STSを作成後、STSを12cに転送する
• SQLパフォーマンスアナライザホーム画面に行く
  • ワークフローのテンプレートが用意されているのでガイド付きワークフローを選択
  • 旧環境と新環境とでSQL実行を比較する
    • 経過時間はノイズが入りやすいのでバッファ読み取りを選択した方がいい
• 比較結果から、チューニングのアドバイザも受けられます

一般的なテストとSPAを利用したテストとの違い

• アプリ解析とテスト実施には膨大な工数がかかるが、工数を大幅に削減できる
• SPAを使うとテスト対象アプリの解析、アプリの準備や実行の必要、実行計画や性能変動、非互換の確認などの必要がなくなる
  • チューニングは別見積もりに出しやすくなる

RAT in Cloud

• SQL互換のチェックのためにOracleCloudで測定する方法もあります

@mogmetの所感

システムを更改するときはDBだけでなく、アプリ側の環境も新しくなることが多い気がするので、その場合にはどちらにせよアプリ側も調査するために準備などをしないといけなくなってしまいますが、DBだけ更改するといった状況の場合でしたら積極的にRATを使用して工数を削減していきたいですね。

一度RATが使えるようになったら積極的にパッチの適用の際のテストなどにも用いてリスク軽減に使用できたらと思います。