Oracle Database 12c サポート期限（EOS）と今後の対応策

By /

Oracle Database 12c サポート期限（EOS）と今後の対応策

はじめに：サポート期限が迫るOracle Database 12c

企業の情報システムにおいて、データベースは心臓部と言える存在です。その中でも、Oracle Databaseは長年にわたり多くの企業で基幹システムを支えるデファクトスタンダードとして広く採用されてきました。Oracle Database 12cは、2013年にRelease 1（12.1）、2016年にRelease 2（12.2）がリリースされ、その革新的な機能（マルチテナントアーキテクチャなど）により、多くのユーザーに利用されてきました。

しかし、テクノロジーの進化とライフサイクルの原則に基づき、ソフトウェアには必ず「サポート期限（End of Support, EOS）」が存在します。Oracle Database 12cも例外ではなく、そのサポート期限が間近に迫っています。サポート期限が切れたデータベースを継続して利用することは、企業にとって様々な重大なリスクをもたらします。これらのリスクを回避し、ビジネスの継続性と安定性を確保するためには、サポート期限を正確に把握し、適切な対応策を講じることが不可欠です。

本稿では、Oracle Database 12cの具体的なサポート期限、サポート期限切れがもたらす影響とリスク、そしてユーザーが取りうる具体的な対応策（アップグレード、他データベースへの移行、クラウド移行など）について、詳細かつ包括的に解説します。約5000語というボリュームで、技術的な側面だけでなく、プロジェクト管理、コスト、リスク管理といったビジネス的な側面も含めて網羅的に議論し、読者の皆様が最適な対応策を検討・実行するための一助となることを目指します。

Oracle Database 12cのサポートポリシーと期限詳細

Oracle製品のサポートは、Oracle Lifetime Support Policyに基づいています。このポリシーは、製品のライフサイクル全体を通じて、複数のサポートフェーズを提供することで、顧客の長期的なシステム運用を支援するものです。主なサポートフェーズには以下の3つがあります。

  1. Premier Support:

    • 製品リリースから5年間提供される主要なサポートフェーズです。
    • この期間中は、最新のセキュリティアップデート（Security Patch Update, SPU / Critical Patch Update, CPU）、バグ修正（Patch Set Updates, PSU / Release Updates, RU）、新しいバージョンへのアップグレードツールやドキュメント、技術サポートが無償で提供されます。
    • 最新のセキュリティ脅威に対する保護や、既知の不具合への対応がタイムリーに行われるため、最も安全かつ安定した運用が可能なフェーズと言えます。

  2. Extended Support:

    • Premier Support終了後に、追加費用を支払うことで延長可能なサポートフェーズです。
    • 通常3年間提供されます（延長される場合もあります）。
    • Premier Supportと同様に、セキュリティアップデート、バグ修正、技術サポートが提供されますが、追加費用が発生します。
    • このフェーズを利用することで、システムの移行やアップグレードに時間をかけることが可能になります。ただし、Extended Support期間もいずれ終了します。

  3. Sustaining Support:

    • Premier SupportおよびExtended Supportが終了した後に提供されるサポートフェーズです。
    • 追加費用は不要ですが、提供されるサポート内容は大きく制限されます。
    • 新規のバグ修正やセキュリティアップデートは提供されません。
    • 既存のパッチ（Premier/Extended Support期間中にリリースされたもの）の提供は受けられますが、新しい脆弱性に対するパッチは入手できません。
    • 技術サポートは受けられますが、問題解決には既存のパッチやドキュメントに基づく対応となり、Sustaining Support期間中に発見された未知の不具合に対する新たな修正は期待できません。
    • このフェーズでの運用は、セキュリティリスク、安定性の低下、コンプライアンス違反といった深刻な問題を抱えることになります。

Oracle Database 12cの具体的なサポート期限:

Oracle Database 12cには、Release 1 (12.1) と Release 2 (12.2) の2つの主要なリリースがあります。それぞれのサポート期限は以下の通りです。

  • Oracle Database 12c Release 1 (12.1.0.1 および 12.1.0.2):

    • Premier Support 終了: 2018年7月31日 (12.1.0.2)
    • Extended Support 終了: 2022年7月31日
    • Sustaining Support へ移行済み: 2022年8月1日以降

  • Oracle Database 12c Release 2 (12.2.0.1):

    • Premier Support 終了: 2020年3月31日
    • Extended Support 終了: 2022年3月31日
    • Sustaining Support へ移行済み: 2022年4月1日以降

重要: Oracle Database 12cはいずれのリリースも、すでにPremier SupportおよびExtended Support期間を終了しており、Sustaining Supportフェーズに移行しています。 これは、新規のセキュリティパッチやバグ修正が提供されなくなったことを意味します。

My Oracle Support (MOS) でのサポートステータス確認:

自身の利用しているOracle Databaseのバージョン、エディション、プラットフォームにおける正確なサポート期限や適用可能なパッチ情報は、OracleのサポートポータルであるMy Oracle Support (MOS) で確認することが推奨されます。MOSでは、”Lifetime Support Policy” ドキュメントや、特定の製品に関するサポート情報を検索できます（例: Document ID 742060.1 “Release Schedule of Current Database Releases” など）。システム管理者やデータベース管理者は、定期的にこれらの情報を確認し、最新のサポート状況を把握する必要があります。

サポート期限切れがもたらす影響とリスク

Oracle Database 12cがSustaining Supportフェーズにあるということは、前述の通り、様々な重大なリスクを抱えることを意味します。これらのリスクを軽視することは、ビジネス継続性に深刻な影響を与える可能性があります。主なリスクを以下に詳述します。

  1. セキュリティリスクの増大:

    • 脆弱性の未修正: Sustaining Supportでは新規のセキュリティパッチが提供されません。これは、製品に新たに発見された、あるいは今後発見されるであろうセキュリティ上の脆弱性が修正されないまま放置されることを意味します。攻撃者は常に新しい脆弱性を探し、それを悪用しようとしています。未修正の脆弱性があるデータベースは、サイバー攻撃の格好の標的となります。
    • データ漏洩: 脆弱性を悪用された場合、データベースに格納されている機密情報（顧客データ、取引情報、個人情報など）が不正にアクセスされ、漏洩する危険性があります。データ漏洩は、企業の信頼失墜、損害賠償請求、規制当局からの罰金といった深刻な結果を招きます。
    • サービス停止: セキュリティ攻撃により、データベースが破壊されたり、操作不能になったりする可能性があります。これは、そのデータベースに依存するすべてのアプリケーションやサービスが停止することを意味し、ビジネス活動が麻痺します。ランサムウェア攻撃なども、サポート切れシステムに対する脅威の一つです。
    • コンプライアンス違反: 多くの業界規制（例: PCI DSS、HIPAA、GDPRなど）や社内セキュリティポリシーでは、使用するソフトウェアを常に最新のセキュリティパッチが適用された状態に保つことが求められます。サポート切れのデータベースを使用していると、これらの要件を満たせなくなり、コンプライアンス違反となる可能性があります。これは、監査不合格、事業継続の困難化、法的な責任追及につながることがあります。

  2. 安定性・信頼性の低下:

    • 未修正のバグ: Sustaining Supportでは新規のバグ修正が提供されません。これは、運用中に発生した未知の不具合やパフォーマンス問題に対して、ベンダーからの公式な修正パッチが提供されないことを意味します。システムの安定性が損なわれ、予期せぬ障害やパフォーマンス劣化が発生するリスクが高まります。
    • 障害発生時の復旧困難: 障害が発生した場合、その原因がSustaining Support期間中に発見された新たなバグに起因する場合、ベンダーからの根本的な解決策が得られない可能性があります。問題解決には、既知の情報や回避策に頼るしかなくなり、復旧に時間がかかったり、完全に復旧できなかったりするリスクがあります。また、原因究明のために、自社や外部ベンダーの工数が膨大にかかる可能性があります。
    • パフォーマンス問題への対応困難: パフォーマンスに関する既知の問題が修正されないまま運用が続く可能性があります。また、新たなワークロードやデータ量の増加によって発生したパフォーマンス劣化に対して、ベンダーからのアドバイスやチューニング支援が限定的になる可能性があります。

  3. 技術的負債の増加:

    • 陳腐化: 古いバージョンのデータベースを使い続けることは、技術的な陳腐化を招きます。新しいテクノロジーや開発手法（クラウドネイティブ、コンテナ、マイクロサービスなど）は、最新バージョンのデータベースやドライバを前提としていることが多く、古いバージョンでは連携が困難になる場合があります。
    • 開発・改修の非効率化: 既存アプリケーションの改修や新規開発を行う際、古いバージョンのデータベースに合わせた制約を受けることになります。最新の機能や性能改善を利用できず、開発効率が低下したり、実装が複雑になったりする可能性があります。また、古いバージョンのドライバやライブラリを使用し続けること自体が、セキュリティリスクや他のシステムとの互換性問題を引き起こす可能性もあります。
    • 人材確保の難しさ: Oracle Database 12cのような古いバージョンに関する深い知識と経験を持つエンジニアは、時間の経過とともに減少していきます。新しい技術を学ぶエンジニアが主流となる中で、古いシステムを維持・管理できる人材の確保や育成が困難になる可能性があります。

  4. サポートコストの増加 (間接的):

    • Extended Support期間中は追加費用がかかります。Sustaining Support移行後は直接的なサポート費用はかかりませんが、問題発生時の原因究明や回避策の検討、自社でのパッチ適用検証、セキュリティ対策の強化（WAFやIDS/IPSなどの追加導入）、外部コンサルタントへの依頼といったコストが間接的に増加する可能性があります。また、システム停止によるビジネス機会損失や復旧にかかる費用は計り知れません。

これらのリスクは相互に関連しており、単一のリスクが他のリスクを誘発・増幅させる可能性があります。例えば、セキュリティ脆弱性が原因でシステム停止が発生し、それがコンプライアンス違反にもつながるといった連鎖的な問題が発生し得ます。したがって、Oracle Database 12cのサポート期限切れは、単なる技術的な問題ではなく、ビジネス継続性に関わる経営課題として捉える必要があります。

今後の対応策：サポート期限切れにどう対応するか

Oracle Database 12cのサポート期限がSustaining Supportへ移行している現状を踏まえ、企業は早急に以下のいずれかの対応策を検討・実行する必要があります。対応策の選択は、現在のシステム構成、ビジネス要件、予算、移行期間、社内の技術力などを総合的に考慮して行う必要があります。

基本的な対応策の選択肢は以下の通りです。

(a) サポート対象バージョンへのアップグレード: 現在のOracle Database環境を、サポート期間内の新しいバージョン（例: 19c, 23c）にアップグレードします。
(b) 他のデータベースへの移行: Oracle Databaseから、他のベンダーのデータベース（例: PostgreSQL, SQL Server, MySQLなど）へシステムを移行します。
(c) Oracle Cloudへの移行: オンプレミス環境のOracle Databaseを、Oracle Cloud Infrastructure (OCI) 上で提供されるデータベースサービス（例: OCI Database Service, Autonomous Database）に移行します。
(d) 現状維持 (Sustaining Supportでの運用): サポート期限が切れた状態で運用を継続します。ただし、これは推奨されない、非常にリスクの高い選択肢です。

それぞれの対応策について、メリット・デメリット、具体的な検討事項、プロジェクトの進め方を詳細に解説します。

対応策(a): サポート対象バージョンへのアップグレード

最も一般的かつ、Oracle Databaseの機能を最大限に活用し続けたい場合に推奨される対応策です。Oracle Databaseのアップグレードは、同一ベンダー製品であるため、比較的容易な移行パスが用意されています。

メリット:

  • Oracle Databaseの機能を継続利用: 長年培ってきたOracle Databaseの運用ノウハウや、Oracle独自の高機能（RAC, Data Guard, Partitioning, Advanced Compressionなど）を引き続き利用できます。
  • 比較的容易な移行パス: Oracleが提供するアップグレードツール（DBUA, Data Pumpなど）を利用することで、他のデータベースへの移行に比べて手間やリスクを抑えられる可能性があります。
  • Oracleエコシステムの活用: Oracle製品間の連携（例: Fusion Middleware, EBSなど）や、Oracle認定ベンダーのソリューションを引き続き利用できます。
  • 新機能の利用: 新しいバージョンで追加された性能改善、可用性向上、セキュリティ強化、開発効率向上などの機能を利用できます。

デメリット:

  • アップグレード作業のコストと時間: 計画策定、互換性検証、テスト、実際のアップグレード作業に時間と工数がかかります。特に大規模なシステムや複雑な構成の場合、数ヶ月から1年以上の期間を要することもあります。
  • アプリケーションの互換性検証: アップグレード後のデータベースに対して、既存のアプリケーションが問題なく動作するかどうか、徹底的な互換性検証が必要です。SQL文の挙動変更、廃止機能、新機能による影響などを確認する必要があります。
  • ライセンス費用の変動: 新しいバージョンへのアップグレードに伴い、エディション変更やオプション追加などによってライセンス費用が変動する可能性があります。

アップグレード先の候補:

Oracle Databaseのサポート対象バージョンは、Long Term Release (LTR) と Innovation Release (IR) に分けられます。LTRは長期間（通常5年間のPremier Support + 3年間のExtended Support）サポートが提供されるため、基幹システムなど長期的な運用が求められる環境に適しています。IRは最新機能が先行して提供されますが、サポート期間が短く（通常2年間のPremier Supportのみ）、最新技術を試したい開発環境や非本番環境向けです。

Oracle Database 12cからのアップグレード先として最も一般的なのは、以下のLTRバージョンです。

  • Oracle Database 19c:

    • Oracle Database 12c R2 (12.2) の後の最初のLTRです。非常に多くの企業で採用されており、安定性が高いと評価されています。
    • Premier Support 終了: 2024年4月30日
    • Extended Support 終了: 2027年4月30日（有償）
    • Oracle Cloudでは、さらに延長サポートが提供される場合があります。
    • 既存の12c環境からのアップグレードパスが確立されています。
    • 様々な新機能やパフォーマンス改善が取り込まれています。

  • Oracle Database 23c:

    • 現在の最新LTRとして位置づけられています（2023年9月にリリースされたCloud Free版が先行）。オンプレミス版は今後リリース予定です。
    • “App Simple” をコンセプトに、開発者向けの新機能が多く含まれています（JSON Relational Duality, GraalVM integration, Microservices supportなど）。
    • サポート期間は19cと同様、長期となる見込みです。
    • まだ新しいバージョンであるため、実績や安定性に関する情報は19cに比べて少ない可能性があります。

アップグレード計画のステップ:

アップグレードプロジェクトを成功させるためには、以下のステップを計画的に実行することが重要です。

  1. 現状分析:

    • 現在のOracle Database 12cの正確なバージョン、エディション、パッチレベルを確認します。
    • 稼働しているOSバージョン、ハードウェアスペックを確認します。
    • データベースに接続しているアプリケーション（自社開発、パッケージ製品）のリストアップと、その接続方法（JDBC/OCIドライバのバージョン）、対応OSを確認します。
    • 使用しているOracle Databaseのオプション機能（Partitioning, RAC, Data Guardなど）を確認します。
    • データベースの容量、トランザクション量、パフォーマンス要件などを把握します。
    • バックアップ・リカバリ構成を確認します。

  2. アップグレード先バージョンの選定:

    • Oracle Database 19cまたは23c（またはその時点での最新LTR）を候補とします。
    • 各バージョンのサポート期間、新機能、既存アプリケーションとの互換性情報を比較検討します。
    • アプリケーションベンダーがどのOracle Databaseバージョンをサポートしているかを確認します。
    • 一般的には、安定性と実績のある19cが有力な選択肢となりますが、最新機能が必要な場合は23cも検討します。

  3. テスト環境構築と互換性検証:

    • ターゲットバージョンと同じ構成のテスト環境を構築します。
    • 本番環境からデータを移行し、可能な限り本番に近いデータ量・構成でテストを実施します。
    • アプリケーション互換性検証: 最も重要なステップです。
      • 主要な業務プロセスを網羅的に実行し、機能的な問題がないか確認します。
      • 既存のSQL文、PL/SQLプロシージャ、トリガーなどの挙動に変化がないか確認します。Explain Planなどで実行計画の変化も確認します。
      • 使用しているOCI/JDBCドライバのバージョンがターゲットバージョンに対応しているか確認し、必要に応じてアップデートします。
      • 文字コード（Character Set）の互換性、特にAL32UTF8などのUTF-8関連での潜在的な問題を検証します。
      • パフォーマンス検証: 本番環境と同等またはそれ以上の負荷をかけ、処理時間やリソース使用率が許容範囲内か確認します。劣化が見られる場合は、SQLチューニングや初期化パラメータの見直しを行います。
      • バッチ処理、レポーティング処理などの実行時間を計測し、影響を確認します。
    • Oracleが提供する互換性チェックツール（例: Pre-Upgrade Information Tool）を活用します。

  4. アップグレード方法の検討:

    • 主に以下の方法があります。
      • Database Upgrade Assistant (DBUA): 対話式GUIツールで、比較的容易にアップグレードできます。小規模～中規模のデータベースに適しています。
      • Data Pump Export/Import: 既存データベースからデータをExportし、新しいデータベースにImportする方法。完全にクリーンな環境に移行できますが、全データのExport/Importに時間がかかり、ダウンタイムが長くなる傾向があります。
      • RMAN Restore/Recover: 既存データベースのバックアップを新しい環境でリストアし、リカバリする方法。データベース全体の構造を保持できます。
      • Full Transportable Tablespaces: データベース全体を表領域単位で新しい環境に移動する方法。データ移行が高速ですが、いくつかの制約があります。
      • GoldenGate: リアルタイムレプリケーションツールを利用して、本番稼働中のデータベースから新しいデータベースにデータを同期させながら移行する方法。ダウンタイムを最小限に抑えられますが、設定・運用が複雑でコストもかかります。
    • システムの特性（データ量、許容ダウンタイム、構成の複雑さなど）に基づいて最適な方法を選択します。大規模システムでダウンタイムを最小化したい場合は、GoldenGateなどのレプリケーションツールや、RMAN/Data Pumpを利用した段階的な移行を検討します。

  5. パイロットアップグレードと本番移行計画策定:

    • 本番環境と同等の環境（または一部の非本番環境）で、選定したアップグレード方法を用いてテストを行います。手順、所要時間、発生しうる問題を事前に把握します。
    • 本番移行の具体的な手順書を作成します。ロールバック手順も必ず準備します。
    • 移行ウィンドウ（ダウンタイム）を設定し、関連システムとの連携やビジネス部門への影響を調整します。週末や深夜などのシステム停止が許容される時間帯を選定することが一般的です。
    • 移行チームの役割分担、連絡体制、緊急時の対応フローを明確にします。

  6. 本番アップグレード実施と稼働確認:

    • 計画に基づいて本番アップグレードを実行します。
    • 移行中のログを詳細に記録します。
    • アップグレード完了後、アプリケーションの動作確認、基本的なSQL実行、接続性確認などを実施します。
    • パフォーマンス監視を開始し、問題がないか確認します。

  7. アップグレード後の運用体制構築:

    • 新しいバージョンにおける運用・監視方法を確立します（バックアップ、リカバリ、パッチ適用、パフォーマンス監視ツールなど）。
    • データベース管理者（DBA）や開発者に、新バージョンの機能や変更点に関するトレーニングを実施します。
    • 定期的なパッチ適用計画を策定・実行します。

対応策(b): 他のデータベースへの移行

Oracle Database固有の機能への依存が少ないシステムや、ライセンスコストの削減を重視する場合に検討される対応策です。PostgreSQL、SQL Server、MySQLといったリレーショナルデータベースや、MongoDBなどのNoSQLデータベースが移行先候補となります。

メリット:

  • ライセンスコスト削減の可能性: オープンソースデータベース（PostgreSQL, MySQLなど）は通常ライセンス費用がかかりません。商用データベースでも、Oracleに比べてライセンス費用が抑えられる場合があります。
  • 特定の技術スタックとの親和性: 移行先のデータベースが、開発チームが使い慣れている技術スタック（例: Java + PostgreSQL, .NET + SQL Server）と親和性が高い場合、開発効率が向上する可能性があります。
  • ベンダーロックインの回避: 特定ベンダーへの依存度を下げることができます。

デメリット:

  • 移行の複雑性: Oracle Databaseから他のデータベースへの移行は、同一ベンダー内でのアップグレードに比べてはるかに複雑で、技術的なハードルが高いです。
    • スキーマ変換: データ型、シーケンス、トリガー、ビューなどの定義が異なるため、変換作業が必要です。
    • SQL/PL/SQLの書き換え: Oracle固有のSQL関数、構文、PL/SQLプロシージャ/ファンクション/パッケージなどは、移行先のデータベースに合わせて書き換える必要があります。これはアプリケーションコードの大規模な改修につながる可能性があります。
    • データ移行: 大量のデータを正確かつ整合性を保って移行する必要があります。
    • パフォーマンスチューニング: Oracleと他のデータベースでは、オプティマイザの動作やチューニング方法が異なるため、移行後のパフォーマンス最適化が必要です。
    • 機能の互換性: Oracleの高可用性機能（RAC, Data Guard）、セキュリティ機能（VPD, Advanced Security）、パフォーマンス機能（Partitioning, Advanced Compression）などと同等または代替となる機能を、移行先のデータベースで実現できるか検討が必要です。
  • 運用ノウハウの習得: 移行先のデータベースに関する新たな運用ノウハウ（インストール、設定、監視、バックアップ、リカバリ、トラブルシューティングなど）を習得する必要があります。
  • 移行ツールの限界: Oracleから他のデータベースへの変換・移行を支援するツールは存在しますが、完全に自動化することは難しく、手作業による修正が必ず発生します。

移行先の候補と特徴:

  • PostgreSQL:
    • 強力なオープンソースリレーショナルデータベース。Oracleとの互換性が比較的高いとされており、Oracleからの移行先として近年注目されています。
    • 豊富なデータ型、拡張性、標準SQLへの準拠度が高いです。
    • コミュニティによる活発な開発が行われています。
    • 移行ツール（例: ora2pg）やクラウドサービス（例: Amazon RDS for PostgreSQL, Azure Database for PostgreSQL, OCI Database with PostgreSQL）が提供されています。
    • ただし、OracleのPL/SQLをPostgreSQLのPL/pgSQLに変換する作業は複雑になることが多いです。
  • SQL Server:
    • Microsoftが提供する商用リレーショナルデータベース。Windows環境との親和性が高いです。
    • BI/分析機能が充実しています。
    • Oracleからの移行ツール（例: SQL Server Migration Assistant for Oracle (SSMA)）が提供されています。
    • Oracleとは設計思想が異なる部分が多く、SQL構文やプロシージャの書き換え、トランザクション処理の違いなどを考慮する必要があります。
  • MySQL:
    • 広く普及しているオープンソースリレーショナルデータベース。Webアプリケーションとの連携実績が豊富です。
    • 処理性能が高く、大規模な読み取りが多いワークロードに適しています。
    • ただし、Oracle固有の複雑な機能やPL/SQLを多用しているシステムの場合、MySQLへの移行は技術的なハードルが高くなる可能性があります。
  • NoSQL Databases (MongoDB, Cassandraなど):
    • リレーショナルデータベースとは異なるデータモデル（ドキュメント指向、カラム指向など）を持つデータベースです。
    • 非構造化データや大量データの高速処理、柔軟なスキーマ変更などに強みを持ちます。
    • リレーショナルデータベースからNoSQLへの移行は、データモデリングの根本的な見直しが必要となり、アプリケーションコードの改修も大規模になるため、特定の要件（例: スケーラビリティ、データ構造の柔軟性）がある場合にのみ検討されます。一般的な基幹システムでOracleの代替とするのは難しい場合が多いです。

移行計画のステップ:

他のデータベースへの移行も、アップグレードと同様に綿密な計画と実行が必要です。

  1. 現状分析と移行先の選定:

    • 現在のOracle Databaseの構成、データ量、トランザクション特性、使用機能（Oracle固有機能への依存度）を詳細に分析します。
    • ビジネス要件、予算、必要な機能、社内の技術スキルなどを考慮し、最適な移行先データベースを選定します。機能比較、性能評価、コスト比較（ライセンス、運用、開発）を徹底的に行います。
    • アプリケーションが移行先のデータベースに対応しているか確認します。
    • 可能であれば、POC (Proof of Concept) を実施し、技術的な実現可能性やパフォーマンスを評価します。

  2. スキーマ・データ変換計画:

    • Oracle Databaseのスキーマ（テーブル定義、インデックス、制約など）を、移行先のデータベースのスキーマ定義に変換する方法を検討します。
    • Oracle固有のデータ型や機能（例: VARRAY, Nested Table, Bitmap Indexなど）をどう変換するかを定義します。
    • データ移行の方法を検討します（Export/Importツール、ETLツール、移行支援ツールなど）。データ量が多い場合は、差分移行やリアルタイムレプリケーションが必要になる場合があります。

  3. アプリケーション改修計画:

    • Oracle固有のSQL構文、PL/SQL、ヒント句などを、移行先のデータベースの構文に合わせて書き換える作業を計画します。
    • アプリケーションコードの中で、データベース接続処理、エラーハンドリング、トランザクション処理など、データベースに依存する部分を特定し、修正方法を定義します。
    • 使用しているDBドライバやライブラリを移行先対応のものに変更し、その影響を確認します。

  4. テスト環境構築、変換・改修・データ移行テスト:

    • 移行先データベースのテスト環境を構築します。
    • スキーマ変換、データ移行、アプリケーションコードの書き換えを実施し、テスト環境で動作確認を行います。
    • 機能テスト、結合テスト、システムテストを実施し、すべての業務プロセスが問題なく動作するか確認します。
    • 性能テスト: 本番環境と同等またはそれ以上の負荷をかけ、処理時間、スループット、レスポンスタイムなどが許容範囲内か確認します。性能劣化が見られる場合は、スキーマ設計の見直し、インデックス最適化、SQLチューニングなどを行います。移行先のデータベースに合わせたチューニングノウハウが必要になります。

  5. 本番移行計画:

    • 本番環境へのデータ移行方法、ダウンタイム、ロールバック手順を詳細に定義します。
    • データ整合性をどのように保証するか、綿密な計画を立てます（例: 移行前後のレコード数一致、チェックサム確認など）。
    • ダウンタイムを最小化したい場合は、リアルタイムレプリケーションツールや、業務影響の少ない時間帯を選定するといった工夫が必要です。

  6. 本番移行実施と稼働確認:

    • 計画に基づいて本番移行を実行します。
    • 移行中のログを詳細に記録し、問題発生に備えます。
    • 移行完了後、稼働確認と性能監視を実施します。

  7. 移行後の運用体制構築とエンジニア育成:

    • 移行先のデータベースに関する新たな運用・監視体制を構築します（バックアップ、リカバリ、監視、パッチ管理、チューニングなど）。
    • データベース管理者（DBA）や開発者に、移行先データベースのアーキテクチャ、機能、運用方法に関するトレーニングを実施します。必要に応じて外部研修やコンサルタントを活用します。

対応策(c): Oracle Cloud (OCI) への移行

オンプレミス環境のOracle Databaseを、Oracle Cloud Infrastructure (OCI) 上のデータベースサービスに移行する対応策です。Oracle Databaseの最新機能やクラウドならではのメリットを享受できます。

メリット:

  • インフラ管理不要: ハードウェア、OS、ストレージなどのインフラ管理から解放されます。パッチ適用やバックアップなどの運用作業の一部もサービス側で提供されます。
  • スケーラビリティ: 必要に応じてCPU、メモリ、ストレージなどを柔軟にスケールアップ・スケールダウンできます。
  • Oracleの最新機能利用: OCI上で提供されるデータベースサービスは、常に最新のOracle Databaseバージョンやパッチが利用可能です。
  • TCO削減の可能性: 初期投資を抑え、従量課金モデルによるコスト最適化や、運用管理工数の削減によるTCO削減が期待できます。
  • 移行ツールの提供: Oracleが提供するクラウド移行支援ツール（Data Pump, RMAN, Cloud Migration Serviceなど）を利用できます。
  • 高可用性・ディザスターリカバリ: OCIのリージョンやアベイラビリティドメインを活用した高可用性構成や、Oracle Data Guardを利用した効率的なDRサイト構築が可能です。
  • Autonomous Database: さらに運用を自動化したい場合は、Autonomous Databaseという選択肢もあります。

デメリット:

  • クラウド移行の技術的ハードル: オンプレミスとは異なるクラウド環境（VCN, Subnet, Security List, Identity and Access Management (IAM) など）に関する知識が必要です。
  • ネットワーク設計: オンプレミスシステムとの連携に必要なネットワーク設計（FastConnect, VPN Connectなど）が必要です。
  • セキュリティ: クラウド環境におけるセキュリティ設定（VCNのネットワークセキュリティ、セキュリティリスト、WAF、監査ログなど）を適切に行う必要があります。責任共有モデルに基づき、OS以上のレイヤーのセキュリティは顧客責任となります。
  • 既存システムとの連携: オンプレミスの他のシステムや SaaS アプリケーションとの連携方法を検討・実装する必要があります。

OCIで利用可能なDBサービス:

OCIでは様々なレベルの管理を提供するOracle Databaseサービスが利用可能です。

  • OCI Virtual Machine DB Service: OCI上のVMにOracle Databaseを構築するサービス。OS以上の管理は顧客が行います。柔軟な構成が可能ですが、管理負担は比較的高めです。
  • OCI Bare Metal DB Service: OCI上のベアメタルサーバーにOracle Databaseを構築するサービス。VMよりも高いパフォーマンスが期待できます。管理負担はVM DB Serviceと同様です。
  • OCI Exadata Cloud Service / Cloud@Customer: OCIのデータセンター内、あるいは顧客データセンター内に設置されたExadata上でOracle Databaseを利用するサービス。大規模かつ高い性能・可用性が求められる基幹システムに適しています。Oracleがハードウェア・OSレイヤーの管理を行います。
  • OCI Autonomous Database (Shared / Dedicated): Oracleが提供する自律型データベースサービス。データベースのプロビジョニング、パッチ適用、チューニング、バックアップ、セキュリティなどが自動化されます。管理負担が大幅に軽減されます。
    • Autonomous Transaction Processing (ATP): トランザクション処理ワークロード向け
    • Autonomous Data Warehouse (ADW): データウェアハウスワークロード向け

OCI移行計画のステップ:

OCIへの移行も、計画的なアプローチが重要です。

  1. クラウド移行戦略の検討:

    • どのような形でクラウドを利用するか（IaaSとしてのDB移行、PaaSとしてのDBaaS利用、Autonomous Database利用など）を決定します。
    • クラウド移行の目的（コスト削減、運用効率化、BCP/DR強化、最新技術活用など）を明確にします。

  2. 移行対象データベースの評価とOCIサービスの選定:

    • 現在のOracle Databaseのワークロード特性（OLTP, DWH, Mix）、データ量、性能要件、必要な機能などを評価します。
    • 評価結果に基づき、最適なOCIデータベースサービス（VM, BM, Exadata CS, Autonomous Databaseなど）を選定します。エディション（SE2, EE, EE-HP, EE-EP）やオプション（RAC, Partitioningなど）も決定します。

  3. OCI環境の設計・構築:

    • OCIアカウントのセットアップ、VCN (Virtual Cloud Network)、Subnet、Security List, Network Security Groupなどのネットワーク基盤を設計・構築します。
    • IAMポリシーを設定し、必要なユーザーやグループに適切な権限を付与します。
    • オンプレミス環境との接続が必要な場合は、FastConnectやVPN Connectを設計・構築します。

  4. 移行方法の選定とテスト:

    • 主な移行方法には以下があります。
      • Data Pump: 既存のExportファイルをOCI Object Storage経由で転送し、OCI上のDBサービスにImportする方法。
      • RMAN Backup & Restore: 既存のRMANバックアップファイルをOCI Object Storageに転送し、OCI上のDBサービスでリストア・リカバリする方法。
      • OCI Database Migration Service: Oracleが提供するGUIベースの移行ツール。Data PumpやGoldenGateを利用した移行をサポートします。
      • GoldenGate: オンプレミスとOCI間のリアルタイムレプリケーションを設定し、ダウンタイムを最小限に抑えて移行する方法。
    • データ量、許容ダウンタイム、技術的な実現可能性を考慮して最適な移行方法を選定し、テスト環境で検証します。

  5. アプリケーションのクラウド対応検証・改修:

    • クラウド環境に移行したデータベースへの接続性、パフォーマンス、機能性を検証します。
    • 必要に応じて、アプリケーションコードの修正（例: 接続文字列の変更）、ドライババージョンのアップデートなどを行います。
    • クラウド環境でのスケーラビリティや耐障害性を考慮したアプリケーション設計になっているか確認します。

  6. パイロット移行と本番移行計画:

    • テスト環境や小規模なシステムでパイロット移行を実施し、手順や所要時間を確認します。
    • 本番移行の具体的な手順書を作成し、ロールバック手順も準備します。
    • 移行ウィンドウを設定し、関連システムやビジネス部門との連携を確認します。

  7. 本番移行実施と稼働確認:

    • 計画に基づいて本番移行を実行します。
    • 移行完了後、稼働確認、アプリケーション動作確認、パフォーマンス監視を実施します。

  8. クラウド環境での運用・監視体制構築:

    • OCIの運用・監視ツール（Monitoring Service, Logging Service, OCI Cloud Guardなど）を活用した監視体制を構築します。
    • バックアップ・リカバリ計画、パッチ適用計画（PaaS/Autonomous DBの場合はOracleが実施）、障害発生時の対応フローを確立します。
    • クラウド環境特有のセキュリティ設定（VCN/NSGの設定、IAMポリシー、監査ログ）を定期的に見直し、強化します。
    • コスト監視を継続的に実施し、リソースの最適化を行います。

対応策(d): 現状維持 (Sustaining Supportでの運用)

Oracle Database 12cをSustaining Supportの状態で運用し続けるという選択肢です。これは強く推奨されない、非常にリスクの高い対応策であることを改めて強調します。

メリット:

  • 移行コストがかからない（短期的には）: システムの入れ替えや移行作業に伴う直接的なコスト（プロジェクト費用、人件費、ツール費用など）は発生しません。

デメリット:

  • リスクが非常に高い:
    • セキュリティリスク: 新規のセキュリティパッチが提供されないため、新たな脆弱性が発見された場合、無防備な状態になります。これは、データ漏洩、システム停止といった致命的なセキュリティインシデントに直結する可能性が非常に高いです。
    • 安定性・信頼性: 新規のバグ修正が提供されないため、未知の不具合によってシステム障害が発生するリスクが高まります。障害発生時の原因特定や復旧が困難になります。
    • 技術サポートの限定性: Oracleからの技術サポートは、既存のパッチやドキュメントに基づくものに限定されます。Sustaining Support期間中に発生した問題に対する新たな調査や根本的な解決策は提供されません。
    • コンプライアンス違反: セキュリティ基準や監査要件を満たせなくなる可能性が高く、事業継続が困難になったり、法的な責任を問われたりするリスクがあります。
    • 技術的負債の深刻化: システムの陳腐化がさらに進み、将来的なアップグレードや移行がますます困難かつ高コストになります。

どのような場合に検討されるか（限定的なケース）:

現状維持が検討されるのは、以下のような限定的なケースのみです。

  • 廃止予定のシステム: 近い将来（例えば数ヶ月以内）に完全に廃止されることが確定しているシステム。ただし、廃止までの期間にもリスクは存在するため、十分なリスク評価が必要です。
  • 厳重に隔離された環境: 外部ネットワークから完全に物理的または論理的に隔離されており、かつアクセスが非常に限定的な環境で稼働しているシステム。それでも内部犯行や他の経路からの攻撃リスクはゼロではありません。
  • リスクを完全に許容できるビジネス部門: 上記のリスクを十分に理解し、万が一インシデントが発生した場合でもビジネス継続に影響がない、あるいは許容できると経営層が判断した場合。しかし、ほとんどの基幹システムではこの判断は非常に困難です。

現状維持を選択する場合に取るべき最低限のリスク軽減策:

リスクを承知で現状維持を選択する場合でも、最低限以下の対策を講じる必要があります。ただし、これらの対策は根本的な解決策ではなく、リスクを「軽減」するものでしかないことを理解しておく必要があります。

  • ネットワーク隔離: データベースサーバーを外部ネットワークから厳重に隔離します。不要なポートを閉じ、アクセス元IPアドレスを制限するなど、ファイアウォール設定を強化します。
  • アクセス権限の厳格化: データベースへのアクセス権限を最小限にし、不要なユーザーアカウントを無効化します。特権ユーザーの管理を徹底します。
  • WAF/IDS/IPSの導入: Web Application Firewall (WAF)、侵入検知システム (IDS)、侵入防御システム (IPS) などを導入し、不正アクセス試行を検知・ブロックします。
  • 脆弱性スキャン: 定期的にデータベースサーバーや関連システムに対して脆弱性スキャンを実施し、既知の脆弱性の有無を確認します。ただし、Sustaining Supportでは新しい脆弱性に対する情報やパッチは提供されません。
  • 厳重な監視: データベースのログやOSログを詳細に監視し、不審なアクティビティやエラーを早期に検知できる体制を構築します。
  • バックアップの強化: 障害発生時に備え、バックアップ・リカバリ体制を強化します。ただし、バックアップ自体が攻撃を受ける可能性も考慮が必要です。
  • 代替手段の準備: 万が一の障害やセキュリティインシデント発生に備え、ビジネスを継続するための代替手段や手動オペレーションの準備を行います。

繰り返しますが、Sustaining Supportでの運用は、新規セキュリティパッチが提供されないという致命的な問題を抱えています。上記対策をもってしても、ゼロデイ脆弱性など未知の脅威に対しては無防備となります。したがって、基幹システムや機密情報を扱うシステムにおいては、現状維持という選択肢は極めて危険であり、推奨されません。

移行プロジェクトの成功に向けた共通の考慮事項

どの対応策を選択するにしても、サポート期限という明確な期日がある中でプロジェクトを成功させるためには、共通して考慮すべき重要な事項があります。

  1. タイムライン:

    • Oracle Database 12cのサポート期限（すでにSustaining Support移行済み）から逆算し、現実的なプロジェクト期間を設定することが極めて重要です。
    • 計画策定、ベンダー選定、環境構築、設計、開発・改修、テスト、リハーサル、本番移行といった各フェーズに必要な期間を見積もり、余裕を持ったスケジュールを組みます。
    • 特に、互換性検証やアプリケーション改修は想定以上に時間がかかることが多いため、十分な期間を確保する必要があります。
    • サポート切れ後の期間が長引くほどリスクは増大するため、迅速な意思決定と計画推進が求められます。

  2. コスト:

    • プロジェクトにかかる総コストを正確に見積もります。以下の要素が含まれます。
      • 新しいデータベースのライセンス費用（アップグレードの場合は差額、新規導入の場合はフルコスト）
      • ハードウェアまたはクラウドインフラストラクチャの費用
      • 設計、開発、テスト、移行作業に関わる人件費（社内リソース、外部ベンダー費用）
      • 移行ツール、変換ツール、テストツールなどの導入費用
      • エンジニアのトレーニング費用
      • テスト環境構築費用
      • 万が一の失敗や遅延によるビジネス損失コスト（リスクコスト）
    • アップグレードや移行だけでなく、サポート切れによるリスク顕在化時のコスト（復旧費用、損害賠償、信頼失墜など）も含めて評価し、投資対効果を判断します。

  3. チームとスキル:

    • プロジェクトに必要な技術スキル（対象データベースの知識、OS、ネットワーク、アプリケーション開発、プロジェクト管理など）を持つメンバーを確保します。
    • 社内リソースが不足する場合は、外部の専門ベンダーやコンサルタントの活用を検討します。ベンダー選定は、実績、技術力、サポート体制などを総合的に評価して行います。
    • プロジェクトチーム内の役割分担、責任範囲、コミュニケーションラインを明確にします。

  4. テストと検証:

    • システムの安定性と信頼性を確保するために、テストと検証は極めて重要です。
    • 単体テスト、結合テスト: 個々のコンポーネントやモジュール、それらの連携部分が設計通りに動作するか確認します。
    • システムテスト: システム全体として要件を満たしているか、正常系・異常系処理を含めて網羅的に確認します。
    • 受入テスト: ユーザー部門やビジネス部門が、新しいシステムが業務要件を満たしているか確認します。
    • 性能テスト: 想定される負荷をかけ、処理時間、スループット、リソース使用率などが許容範囲内か確認します。ボトルネックの特定とチューニングを行います。
    • 移行テスト: 実際のデータ移行手順、所要時間、データ整合性を検証します。複数回のリハーサルを実施し、本番移行のリスクを最小化します。
    • セキュリティテスト: 脆弱性スキャンやペネトレーションテストを実施し、セキュリティ上の問題がないか確認します。

  5. リスク管理:

    • プロジェクト遂行中に発生しうる潜在的なリスク（例: スケジュール遅延、予算超過、技術的な問題発生、パフォーマンス劣化、データ不整合、セキュリティインシデント、関係者間の意見対立など）を事前に特定します。
    • 特定したリスクに対して、発生確率、影響度を評価します。
    • リスク発生を回避または最小化するための対策（リスク軽減策）を検討し、計画に組み込みます。
    • リスクが顕在化した場合の対応策（コンティンジェンシープラン、ロールバック計画）を準備します。
    • リスク監視を継続的に行い、状況に応じて対策を見直します。

  6. コミュニケーション:

    • プロジェクト関係者（経営層、IT部門、開発部門、運用部門、事業部門、外部ベンダーなど）との密なコミュニケーションが不可欠です。
    • プロジェクトの目的、進捗状況、課題、リスクなどを定期的に共有し、関係者間の認識合わせを行います。
    • 特に、アプリケーション改修や業務への影響が大きい場合は、事業部門との連携を強化し、理解と協力を得ることが重要です。

  7. ドキュメンテーション:

    • アップグレード/移行の手順書、新しい環境の設定情報、アーキテクチャ図、運用手順書などを詳細に文書化します。
    • テスト結果、発生した問題とその対応策も記録しておきます。
    • 適切なドキュメンテーションは、プロジェクトの引き継ぎ、将来的な運用・メンテナンス、トラブルシューティングに役立ちます。

まとめ

Oracle Database 12cは、すでにPremier SupportおよびExtended Support期間を終了し、Sustaining Supportフェーズに移行しています。これは、Oracleからの新規セキュリティパッチやバグ修正が提供されないことを意味し、使用を続けることはセキュリティリスク、安定性・信頼性の低下、コンプライアンス違反、技術的負債の増加といった、企業にとって無視できない重大なリスクをもたらします。

これらのリスクを回避し、ビジネスの継続性と将来的な発展を確保するためには、Oracle Database 12cをサポート対象バージョン（Oracle Database 19cや23cなど）にアップグレードするか、他のデータベースに移行するか、Oracle Cloudに移行するといった対応策を、サポート期限から逆算して計画的に実行することが不可欠です。現状維持（Sustaining Supportでの運用）は、リスクが非常に高いため、限定的な例外を除いて推奨されない選択肢です。

どの対応策を選択するにしても、プロジェクトの成功には、綿密な計画、十分な予算とリソース、専門知識を持ったチーム、 thoroughなテストと検証、そして関係者間の緊密なコミュニケーションが不可欠です。特に、アプリケーションの互換性検証や、ダウンタイムを最小化するための移行方法の検討は、プロジェクトの成否を左右する重要な要素となります。

Oracle Database 12cのサポート切れは、企業にとってITインフラストラクチャを見直し、最新技術を活用する機会でもあります。クラウドへの移行や、よりモダンなデータベース技術の導入を検討することで、運用効率の向上、コスト最適化、ビジネスの変化への迅速な対応といったメリットを得られる可能性があります。

情報システムの心臓部であるデータベースを、常にサポートされた安全で安定した状態で運用し続けることは、企業の信頼を守り、競争力を維持するための基盤となります。Oracle Database 12cをご利用中の企業は、本稿で解説した情報を参考に、自社の状況に最適な対応策を速やかに検討・実行されることを強く推奨いたします。計画的な移行こそが、ビジネスを成功に導く鍵となります。手遅れになる前に、今すぐ行動を開始しましょう。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール