📄 Oracle実務ガイドv1.1(PDF)をダウンロード →

ライセンスメトリクスの基本:Processor vs. NUP vs. Named User

Oracle Databaseのライセンスには複数のメトリクスが存在します。どのメトリクスを選ぶかによってコストが数倍変わるため、メトリクス選択の判断基準を正確に理解することが出発点です。

メトリクス課金単位有利な条件最低ユーザー数
Processor コア数 × コア係数(Intel x86は0.5) ユーザー数が多い・不特定多数がアクセスするシステム 制限なし
Named User Plus(NUP) アクセスする実ユーザー数(最低25 NUP/Processor) ユーザー数が限定的・特定の社内システム SE2は最低10 NUP/サーバー
Named User(旧EE) 指名ユーザー数(廃止済、後継はNUP) —(新規選択不可)

NUPの「25 NUP/Processor最低条件」を見落とす例が多い。たとえば4コアサーバー(係数0.5で2 Processor相当)にEE-NUPを適用する場合、実際のユーザーが5人でも最低50 NUPを購入しなければならない。ユーザー数が少ない環境でも「本当にNUPが安いか」は計算が必要。

仮想化環境の地雷:Oracle License Information User Manual(LIUM)

Oracle Databaseを仮想化環境(VMware vSphere・Microsoft Hyper-V等)で動かす場合、Oracle社のLIUM(License Information User Manual)が定めるルールが適用されます。このルールを知らずに仮想化構成を組むと、監査時に甚大なバックペイを要求されるリスクがあります。

Oracle Soft Partitioningの原則: VMware・Hyper-V・Solaris Zones(非Global Zone)等の「ソフト区画」は、Oracleがライセンス境界として認めません。物理サーバー上のCPUコア全数をベースにライセンスを計算します。

Hard Partitioningのみが認められる理由

Oracleがライセンス境界として認める「ハードパーティション」は、物理的または特定の技術的な分離が保証された構成のみです。認められる例:Oracle VM Server for x86(OVM)・IBM LPAR(AIX)・Solaris Capped Zones・HPE SuperDome Flex等。VMware vSphereは「ソフトパーティション」とみなされるため、vSphere上のVMにOracleを乗せた場合、その物理サーバーの全コアがライセンス対象になります。

仮想化技術Oracleの分類ライセンス計算範囲
VMware vSphere / ESXi ソフトパーティション(非承認) 物理サーバーの全コア数
Microsoft Hyper-V ソフトパーティション(非承認) 物理サーバーの全コア数
Oracle VM Server(OVM) ハードパーティション(承認) VMに割り当てたvCPU数のみ
AWS EC2(ベアメタル除く) ACE契約あり→vCPU数で計算 ACE適用時はvCPU × 0.5
OCI(Oracle Cloud) OCPU単位(vCPU × 0.5) 契約OCPUのみ

Partitioning Policyと追加オプション管理

Oracle Partitioning(パーティショニング)はOracle Databaseの有料オプションの一つですが、使用した時点で「購入済み」とみなされます。インストール時のパラメータ設定でパーティショニング機能が有効になっていると、実際にパーティションテーブルを使用していなくてもライセンス違反となります。

OptionsとManagement Packsの監査ポイント

Oracle DatabaseのEEには多数のオプションがあり、使用した機能がオプション対象かどうかの確認は「DBA_FEATURE_USAGE_STATISTICSビュー」で確認できます。監査前の自己診断として、以下のオプションの使用有無を確認することが推奨されます:Diagnostics Pack・Tuning Pack・Partitioning・Advanced Security・Real Application Clusters(RAC)・Active Data Guard。

OCI移行とACE(Authorized Cloud Environments)

Oracle Databaseのクラウド移行において、Oracle Cloud Infrastructure(OCI)への移行は特別なメリットがあります。OCI上でOracle Databaseを動かす場合、UCLAs(Universal Cloud License Agreements)のもと、既存のオンプレライセンスの持ち込み(BYOL:Bring Your Own License)が可能です。

ACE(Authorized Cloud Environments)の活用

2022年以降、OracleはAWS・Azure・Google Cloud・Alibaba Cloud等の主要クラウドを「Authorized Cloud Environment(ACE)」として指定し、これらのクラウドにBYOLする場合はvCPU × 0.5でProcessorライセンスを計算するルールを整備しました。ただし、ACEのルールはクラウドプロバイダー・インスタンスタイプ・Databaseエディションによって細部が異なるため、適用前に最新のLIUMを参照する必要があります。

OCI上でのUCLA BYOLは、オンプレとOCIの間でアクティブ・アクティブ構成(同時に両方で動かす)は原則できません。UCLAでは「同一ライセンスのオンプレとクラウドの同時使用は最大10日間」というルールがあります。

DR・フェイルオーバー時のライセンス規定

Oracleの技術サポートポリシーには「フェイルオーバー先のスタンバイサーバーのライセンス要否」についての規定があります。Active Data Guard(ADG)を使用する場合、スタンバイ側でRead Onlyクエリを受け付けると本番と同数のライセンスが必要です。Data Guardのみ(パッシブスタンバイ)の場合は、フェイルオーバーが発生していない期間は10日間以内の切り替え猶予があります。

監査対応の実務

Oracleの監査(LMS:License Management Services)は抜き打ちに近い形で要請されます。事前準備として、「スクリプトによるOracle製品インストール状況の全社棚卸し」を定期実施することが必要です。Oracleが提供するLMS用スクリプト(CollectionScript.sql等)を四半期に一度実行し、インストール済み製品・バージョン・オプション使用状況を記録・保存しておくことが最善の対応です。

交渉の急所

監査が来た後ではなく、契約更新前に「ライセンスポジションの棚卸し(ELP:Effective License Position)」を自社で計算しておくことが交渉の前提です。過剰ライセンスがあれば解約交渉の材料に、不足があれば事前に正規化することで監査ペナルティを回避できます。CSI(Customer Support Identifier)の合算と正規化による保守費削減も、更新交渉時の重要な論点です。

📄 Oracle Database ベンダーマネジメント実務ガイド v1.1

ライセンスメトリクス選択・仮想化環境対応・LIUM詳細・OCI移行・DR規定・監査対応の全プロセスを収録。イタムス株式会社(ITAMS)が提供するVMAJのベンダーマネージャ向け実務ガイドです。

ダウンロード(無料・PDF) →