Oracleのアップグレードでダウンタイムを減らすには
この記事を読むとできるようになること
Oracleのアップグレードのどの手順でダウンタイム(ユーザーがOracleにアクセスできない時間)が発生するかがわかる
ダウンタイムの目標に対してどのような方法を取りうるかがわかる
Oracleのアップグレードの概要（おさらいを兼ねて）
「クイック・スタート・ガイド」によると、アップグレードは以下のような手順で行うのでした。
手順１：データベースとアプリケーション動作保証を検証する
手順２：Oracle Databaseを最新のリリース更新と一緒にインストールする
手順３：AutoUpgrade機能を使用してアップグレードする
手順４：正しい機能、オプション、パックを使用してテストする
本番稼働に影響するのは手順３のところです。
本番データベースを利用するユーザーをデータベースから切り離してダウンタイムが開始です。 AutoUpgradeでアップグレード作業を開始します。 アップグレード作業自体はAutoUpgradeが行ってくれますが、具体的にはデータ・ディクショナリ(※1)を更新します。 アップグレード作業が完了後、ユーザーをデータベースに再接続します。これでダウンタイムが終了です。
(※1)データ・ディクショナリ：データベース内のスキーマ・オブジェクト(表、索引、パッケージなど)の定義、オブジェクトが使用している領域の情報、整合性制約の情報、ユーザー情報、権限とロール、といった、実際にデータベースが機能するために欠かせない情報です。SYSTEM表領域で管理しています。
さて、アップグレードと同時にハードウェアを新しくするケースが多いのではないでしょうか？ その場合、旧データベースから新データベースへのデータ移行が必要です。
ですので実際には「本番データベースを利用するユーザーをデータベースから切り離し、データ移行およびアップグレード作業を行い、ユーザーをデータベースに再接続させる」という作業がダウンタイムとなります。
Data Pump(※2)を使って素直に作業するとデータ移行とアップグレード作業中がすべてダウンタイムとなります。作業はシンプルですが、データベースが大きい環境ではダウンタイムが長時間になってしまいます。
(※2)Data Pump：データ移行ツール。データベースのデータとメタデータ(表・索引の定義情報など)をあるデータベースから別のデータベースへ移行することができる。
ダウンタイムを減らす方法は？
アップグレード手順の「手順１」で自システムの動作条件を確認し、どのようなツール／手順で移行／アップグレードするのかを決めていきます。
例えば、もしお金の制限が無ければGoldenGate(※3)を使ってダウンタイムをほぼゼロにできます。
新ハードウェアに新環境をインストールし、新環境にデータベースを複製します。
新環境のデータベースをアップグレードします。
旧環境から新環境にGoldenGateを使ってデータを同期します。
アップグレード当日にユーザーを旧環境から新環境へ切り替えます。この切り替え時間が「ダウンタイム」となります。このGoldenGateを使う方法がダウンタイムが最も短くできる方法です。
(※3)GoldenGate：論理レプリケーションツール。別途ライセンス費用がかかる。
(参考)
そこまでお金をかけられなくても、Data Guardを使ってダウンタイムを短縮する方法があります。
方法１
新ハードウェアに新環境をインストールし、新環境にデータベースを複製(※4)します。
旧環境から新環境にData Guardを使ってデータを同期します。
アップグレード当日にユーザーを旧環境から切り離します。
REDO適用が完了後、新環境をアップグレードします。
ユーザーを新環境へ接続します。ユーザーを旧環境から切り離してから新環境へ接続した時間が「ダウンタイム」となります。
方法２
新ハードウェアに新環境をインストールし、新環境にデータベースを複製します。
旧環境から新環境にData Guardを使ってデータを同期します。
新環境を「物理スタンバイ」から「論理スタンバイ」に変更します。(※5)
「論理スタンバイ」を停止し、新環境を新Oracle Homeで起動し、アップグレードします。
「論理スタンバイ」を再開し、データを同期します。
アップグレード当日にユーザーを旧環境から新環境へ切り替えます。この切り替え時間が「ダウンタイム」となります。「論理スタンバイ」での同期はGoldenGateによる同期よりも遅いですが、方法1よりもダウンタイムを短くできます。
(※4)RMANによるデータベース複製やバックアップからの復元により複製します。
(※5)物理スタンバイ／論理スタンバイ：REDOを適用によりプライマリのデータブロックをそのままスタンバイに適用して物理的にコピーするのが物理スタンバイ。REDOからSQL文を取り出し、プライマリのSQL実行をスタンバイで再現するのが論理スタンバイ。
(参考)
具体的な手順は？
基本的に「クイック・スタート・ガイド」の手順通りに進めていきます。 合わせて実施したい作業や目標(データ移行やダウンタイムの削減)に合わせて関連する資料を読んで手順を組み立てます(※6)。 テスト環境で移行／アップグレードをテストし、ログを確認します。 エラーが無くなり、ダウンタイム目標を達成できるまで移行／アップグレードテストを繰り返します。 合わせて新環境でのSQL性能テストを行い、すべてのSQLが性能目標を達成するまでチューニングとテストを繰り返します。 本番当日になったら本番移行／アップグレードを行い、ユーザーを新環境へ接続します。
(※6)一緒に行う作業や、ダウンタイム削減目標が高くなるほど、手順が複雑で長くなる傾向があります。
気を付ける点は？
GoldenGateを使った移行
別途ライセンス費用がかかります。技術的な検討の前に費用の検討をする必要があります。
DataGuardを使った移行
新しいハードウェアに旧Oracle製品をインストールする必要があります(「手順１」で動作条件を確認する)
新環境へ移行後すぐにDataGuard環境で稼働させるため、新しいハードウェア側で先にDataGuardを構築しておく必要があります
データベースの負荷が高い場合、「論理スタンバイ」によるレプリケーションが遅すぎて採用できないかもしれません。
ディクショナリ統計の収集
アップグレード作業は、具体的にはデータ・ディクショナリの更新です。アップグレード作業の前にディクショナリ統計を収集しておくと、アップグレード当日にディクショナリ統計の収集をスキップでき時間短縮になります。
まとめ
実際のシステムでは、ハードウェアの入れ替えとOracleのアップグレードを同時に行うケースが多いです。 したがって「データ移行」と「アップグレード」を行う必要があるのですが、この作業中はユーザーが利用できない時間(ダウンタイム)となります。 ダウンタイムを削減するためのツールはいくつもあります。 「クイック・スタート・ガイド」に従い、一緒に行いたい作業(新ハードウェアへの移行／データ移行)や目標(ダウンタイム○時間以内)に関連するドキュメントに沿って手順を作成します。 データ移行／アップグレードとSQL性能のテストを十分行って問題無いことを確認後に本番移行を行います。
執筆者プロフィール：小澤 雅弘
DBMSベンダー、ISPなどでDB関連のプロジェクトを20数年経験。得意領域はDBのパフォーマンスチューニング。
この公式ブロガーの関連記事
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/
PHOTO：UnsplashのAnnie Spratt