ゼロからのリレーショナルデータベース入門(12)

データベースサーバリプレイスの考え方

株式会社アシスト
東日本顧客支援室
仲谷 靖洋
2009/11/2

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

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

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

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

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

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

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

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

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

●図1 24時間365日のシステム
fig1

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

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

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

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

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

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

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

の3つが挙げられます。

 ここで簡単にOracle Database製品のバージョン表記について説明します。図2のように、Oracle Database製品のバージョン表記には「バージョン番号」、「メンテナンスリリース番号」、「コンポーネント固有のリリース番号」、「プラットフォーム固有のリリース番号」と4種類の意味があります。

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

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

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

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

  • コンポーネント固有のリリース番号

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

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

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


1/3 次のページへ

Index
データベースサーバリプレイスの考え方
→ Page 1
避けては通れないデータベースサーバのリプレイス
リプレイス作業は吉か凶か
リプレイス時に発生する作業
データベースのバージョンおよび適用するパッチの選定

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

Page 3
データ移行手段の選択
作業に問題が発生したときの切り戻し計画

ゼロからのリレーショナルデータベース入門

TechTargetジャパン

Database Expert フォーラム 新着記事

@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

RSSフィード

キャリアアップ

- PR -
@IT Sepcial

イベントカレンダー

PickUpイベント

- PR -
もっと見る
- PR -

お勧め求人情報

ホワイトペーパーTechTargetジャパン

@IT Sepcial
ソリューションFLASH