データベースサーバリプレイスの考え方：ゼロからのリレーショナルデータベース入門（12）（1/3 ページ）

全12回の連載も今回で最終回です。手間暇かけて構築したデータベースサーバに必ず訪れる「リプレース」という作業について、移行計画を作成するに当たっての考え方と具体的な検討項目を説明します。【更新版】

[佐瀬力，株式会社アシスト]

避けては通れないデータベースサーバのリプレース

　データベースサーバの運用は、定期的な製品のバージョンアップと、稼働するハードウェアの見直し（リプレース）が欠かせません。

　バージョンアップはソフトウェアとしての機能強化をシステムに取り入れたり、不具合を修正し安定稼働させたりするために行います。リプレースはハードウェアの保守提供期間終了に対応するだけでなく、システム規模の変化にマシンスペックを適合させるためのリサイジング作業としても行われます。いずれも、構築したシステムの安定稼働と成長を支える作業として重要なものです。

　特に、稼働するハードウェアを入れ替える「リプレース」という作業は、その後数年間のシステム規模の変化や運用形態を見据えるとともに、その上で稼働するソフトウェアの見直しも付随するため、非常に重要なイベントと位置付けることができます。

　本稿では、稼働しているデータベースを新環境に移植することを含めたハードウェアの「リプレース」に伴う作業全体を「リプレース作業」と呼び、具体的な作業手順を踏まえた考慮点や注意点を説明します。

リプレース作業は吉か凶か

　多くのデータベースが「24時間365日で稼働」しています。停止できるタイミングがあっても平日の夜間だけ、日曜日だけ、などと限られています。データベースを長時間停止できないという制約から、たとえ不具合対応として修正パッチを適用しなければならない場合であっても、やむを得ず運用回避策で対応するケースが多くあります。また、修正パッチの適用にはアプリケーションや運用面も考慮した動作確認が必要になるため、システムメンテナンス計画の時間内に組み込むことは容易ではありません。

　「リプレース作業」の場合は一層ハードルが高く、最小限の停止時間で別のハードウェア環境に移植し、翌日から何事もなかったかのようにサービスを再開させなければなりません。そのためリプレース作業は「面倒だ」と、後ろ向きに捉える方も多いと思います。しかし、多くの場合はリプレースのタイミングでOracle Databaseなどのソフトウェアを再導入するため、先ほどの修正パッチの適用に悩むことなく、新バージョンに入れ替えて最新の機能を利用することが可能になるのです。

図1　24時間365日稼働するシステムのイメージ

リプレース時に発生する作業

　ここで、実際にリプレース時に発生する作業項目を整理してみましょう。

　リプレース作業には、OSやハードウェアのサイジングなど多くのポイントがありますが、ここではOracle Databaseをリプレースする際のポイントに絞って、順にご紹介します。

• データベースのバージョンおよび適用するパッチの選定
• データ移行手段の選択
• 移行計画のポイント

データベースのバージョンおよび適用するパッチの選定

　新環境で利用するOracle Databaseのバージョンはどのように選定すればよいでしょうか。Oracle Databaseのバージョン選定におけるポイントは

1. アプリケーションの動作保証
2. 製品の安定性
3. 製品ライフサイクルとサポート提供期間

の3つが挙げられます。

　ここで簡単にOracle Database製品のバージョン表記について説明します。図2のように、Oracle Database製品のバージョン表記には「メジャーリリース」「メンテナンスリリース」「（Databaseでは未使用の番号）」「PSR（Patch Set Release）識別番号」「環境固有のメンテナンス番号」があります。

　Oracle Database製品は「Oracle9i」以降、バージョンごとに「Release1（以下、R1）」と「Release2（以下、R2）」を出荷しています。R1からR2への変更には、新機能の追加や大きな機能修正が伴うため、メジャーバージョンと同じ程度の機能変更による影響を考慮する必要があります。また、4桁目および5桁目はPSRや個別パッチのリリース番号であり、Oracle Databaseのバージョン選定では、4桁目と5桁目の修正パッチ類も含め「アプリケーションの動作保証」「製品の安定性」「製品ライフサイクルとサポート提供期間」を総合的に考慮する必要があります。

　また12cより後のバージョン表記はリリースされる年とひも付くようになると、Oracle OpenWorld 2017で発表されました。これにより、12cの次は一気に飛んで18cになりました。

図2　Oracle Database 製品のバージョン表記

• メジャーリリース

　いわゆる「Oracle Database 12c」の「12」部分に当たります

• メンテナンスリリース番号

　いわゆる「Release1」「Release2」として表現されるメンテナンスリリースです。この部分が「1」の製品は当該バージョンにおける「Release1」として出荷されたもの、「2」となる製品は当該バージョンにおける「Release2」として出荷されたものです

• PSR識別番号（コンポーネント固有のリリース番号）

　適用済みPSRのリリース番号です。この部分を確認することで、どのPSRが適用されているのかを判別できます

• プラットフォーム固有のリリース番号

　Linux版、AIX版のように、プラットフォーム別に作成される個別パッチを表します。ただし、個別パッチについては適用済みの全てのパッチがこの番号で表現されるわけではありませんので、必ずインベントリ情報などを参照し確認する必要があります