topimg.jpg


Oracleライセンス方法の見積もり

2015年3月追記

Oracleライセンス方法の見積もり

なんか、最近Oracleの仮想化環境上での考え方が変わったみたい。
なので、下記の情報は、考え方が古い可能性があるので
ちゃんとOracleの代理店とかに聞いたほうが良い。


複雑でお高いOracle DBMSライセンスの見積もりをすることになったので、その覚書。

【ケーススタディ1】
●条件
 ・物理サーバA:Xeon 4ソケット・3CPU×4コア/CPU
 ・物理サーバB:Xeon 4ソケット・3CPU×4コア/CPU
 ・稼動インスタンス数:2 ※いずれも現用系で同時に稼動する
 ・仮想化:なし
 ・使用ユーザ数:1000人
 ・クラスタ:他社PPを利用したHAクラスタ構成
       現用系を物理サーバA、待機系を物理サーバBとして利用。
       待機系では年間10日以下の稼動時間とする。
       
●必要ライセンス価格
 ・前提
  ⇒コンピュータ数
    年間10日以下しか物理サーバBではインスタンスが稼動しないため、待機系のライセンスは発生しない。
  ⇒最大搭載可能CPU数
    4ソケットのためSEの条件を満たしている。SE Oneは2ソケットなのでNG。
  ⇒インスタンス
    2インスタンス稼動しているが、いずれも同一サーバ内のみでの稼動のため、ライセンスには影響なし。
    
(Oracle EEの場合)  
 ・Processorライセンスの場合
  ⇒価格
   1プロセッサあたりライセンス単価 × コア係数 × コア数合計
    =¥ 5,163,000 × 0.5 × (3×4)
    =¥30,978,000
 ・Named User Plusライセンスの場合
  ⇒価格
   1ユーザあたりのライセンス単価 × ユーザ数合計
    =¥ 103,300 × 1000
    =¥103,300,000
  ⇒最少ユーザ数
   25NUP/コア×12コア×コア係数0.5
    =150NUP < 1000人
(Oracle SEの場合)
 ・Processorライセンスの場合
  ⇒価格
   1プロセッサあたりライセンス単価 × CPU数 
    =¥1,902,200 × 3
    =¥5,706,600
 ・Named User Plusライセンスの場合
  ⇒価格
   1ユーザあたりのライセンス単価 × ユーザ数合計
    =¥ 38,000 × 1000
    =¥38,000,000
  ⇒最少ユーザ数
   5NPU/コンピュータ×1コンピュータ
    =5NPU < 1000人

    
  
【ケーススタディ2】
●条件
 ・物理サーバA:Xeon 4ソケット・3CPU×4コア/CPU
 ・物理サーバB:Xeon 4ソケット・3CPU×4コア/CPU
 ・論理サーバa:2CPU×2コア/CPU
 ・論理サーバb:2CPU×2コア/CPU
 ・仮想化:VMWare ESXで物理サーバA、物理サーバB上で論理サーバを稼動させている。
      論理サーバaは物理サーバAのみで稼動、論理サーバbは物理サーバBのみで稼動。
 ・クラスタ:他社PPを利用したHAクラスタ構成
       現用系を論理サーバA、待機系を論理サーバBとして利用。
       待機系では年間10日以下の稼動時間とする。

●必要ライセンス価格
 ・ライセンス課金対象CPUの考え方
   Oracle VM、VMware、Hyper-VなどはSoft Partitioningの分類となっていて、
   Oracle製品が稼働する物理サーバーの全プロセッサで課金される。
   そのため、基本的に、必要ライセンス価格は【ケーススタディ1】と同様になると思われる。
  


【ケーススタディ3】
●条件
 ・物理サーバA:Xeon 4ソケット・3CPU×4コア/CPU
 ・物理サーバB:Xeon 4ソケット・3CPU×4コア/CPU
 ・論理サーバa:2CPU×2コア/CPU
 ・仮想化:VMWare ESXで物理サーバA、物理サーバB上で論理サーバを稼動させている。
      論理サーバaは物理サーバA、Bのいずれかで稼動。
      VMWare vSphereのDRS機能を利用し、自動的にVMotionが発生する。
      論理サーバaは物理サーバA,Bを状況に応じて行ったり来たりする。
 ・クラスタ:なし
       
●必要ライセンス価格      
 ・ライセンス課金対象コンピュータの考え方
   物理サーバA,Bの2台分のライセンスが発生すると思われる。
   そのため、価格は【ケーススタディ1】の2倍。
   
   
   
   
   
【ケーススタディ4】
●条件
 ・物理サーバA:Xeon 4ソケット・3CPU×4コア/CPU
 ・物理サーバB:Xeon 4ソケット・3CPU×4コア/CPU
 ・論理サーバa:2CPU×2コア/CPU
 ・仮想化:VMWare ESXで物理サーバA、物理サーバB上で論理サーバを稼動させている。
      論理サーバaは基本的には物理サーバAで稼動。障害時に物理サーバBで稼動する。
      VMWare vSphereのDRS機能は制限をかけており、自動的にVMotionが発生することはない。
 ・クラスタ:VMware HA機能を利用し、障害時に論理サーバaを物理サーバBで稼動させる。(コールドスタンバイ構成)
       物理サーバBでは年間10日以下の稼動時間とする。(すぐにAへ戻す)
       
●必要ライセンス価格      
 ・ライセンス課金対象コンピュータの考え方
   物理サーバA,Bの2台分のライセンスが発生すると思われる。
   そのため、価格は【ケーススタディ1】の2倍。
   根拠は以下の「引用」。この構成ではOracleが定めるフェイルオーバー構成に該当しないから
   「HA構成で10日以下は課金されないルール」が適用されないように見える。
   
  (引用)Oracle公式 製品価格/ライセンス情報 Q7
    Q.7 複数の物理サーバーによるサーバー仮想化環境を構築した場合のライセンスカウントは
       どのようになりますか?
    A Oracle VM、VMware、Hyper-VなどはSoft Partitioningの分類となり、Oracle製品が稼働する
      物理サーバーの全プロセッサがライセンスカウントの対象となります。物理サーバー間で
      仮想マシンが移動する可能性がある場合には、Oracle製品の
     移動元/移動先の両方にライセンスが必要となります。なお、障害発生時にプログラムが稼働する
     仮想マシンを切り替える構成は、「データリカバリーポリシー」における「フェイルオーバー」
     の構成には該当しません。

   しかし、以下のような全く違う意見を言っているサイトもあり、ネットでは1台分でOKという
   意見もちらほらある。
     ORACLE SEライセンスの考え方はこれであってますか?
     http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q12113716252





こんな感じ。ちなみに、Oracleの営業に確認したわけじゃないから、間違っているかもしれん。
その点はご了承願いたい。


●参考
意外と知らない!?オラクル・ライセンス見積ABC
http://www.oracle.com/technetwork/jp/ondemand/database/db-new/120126-oraclelicensedb-1503671-ja.pdf
VMware 仮想環境における Oracle データベースライセンス
http://blogs.flexerasoftware.com/elo-japan/2012/09/oracle-database-licensing-in-a-vmware-virtual-environment-part-1-of-3.html
Oracle公式 製品価格/ライセンス情報 FAQ Q6~9あたり
http://www.oracle.com/jp/corporate/pricing/faq/faq-06-187876-ja.html#Faq6-6
Oracle公式 日本国内価格表
http://www.oracle.com/jp/corporate/pricing/price/index.html





それにしても、ややこしい。まあ、これもOracle社の戦略なのだろう。
複雑な料金体系にして、よく理解できないユーザから大金を巻き上げると。
あ、これ携帯電話会社の戦略と同じですな。

スポンサーサイト
  1. 2015/03/31(火) 02:56:28|
  2. oracle
  3. | トラックバック:0
  4. | コメント:0

Oracleクライアントとリスナーの動作

●Oracleのソケット動作
①データベース側は、リスナーがlistenすべきポート番号等の情報をlistener.oraから読み込み、listen状態になる
 ⇒lsnrctlというツールを利用して起動する。OSプロンプト上で、lsnrctl startで
  デフォルトのリスナーを起動できる。
②アプリケーション側は、Oracleクライアント(Oracle Net等)を通して、tnsnames.oraからリスナーへ接続するために必要な情報(アドレス、ポート番号、サービス名等)を読み込み、Oracleクライアントへ引き渡す
 ⇒アプリケーション側は、tnsnames.oraに記述された接続識別子のみをソースコードで
  記述してさえいればよい。ただし、JDBC Thinドライバの場合は、tnsnames.oraを使用しないため、 
  接続のために必要な情報を直接記述する必要がある(アドレス、ポート番号、サービス名)。
③Oracleクライアントが指定された接続先のリスナーとの間にソケットを確立する
④リスナーがサーバプロセスを生成し、ソケットを引き継ぐ
⑤サーバプロセスがOracleクライアントからのリクエストを処理する



参考
Oracle Database概要 11gリリース2(11.2)
16 アプリケーションおよびネットワークのアーキテクチャ
http://download.oracle.com/docs/cd/E16338_01/server.112/b56306/dist_pro.htm

  
  1. 2010/03/21(日) 03:53:46|
  2. oracle
  3. | トラックバック:0
  4. | コメント:0

トランザクションエントリ(ITL)について

●トランザクションエントリ(ITL)
・ブロックを変更するトランザクションは、ITLを獲得する必要がある
・ITLはブロックヘッダに存在する(空き領域に存在することもある)
・ITLはデータブロック内の変更情報を管理する(この変更情報はUNDO表領域で使用される)
・ITLはトランザクションの行ロック排他制御にも利用される
INITRANSでITL数の初期値が設定される
MAXTRANSでITL数の最大値が設定される
 ⇒10gでは常に255で設定されている
 ⇒ITL が不足すると MAXTRANS まで自動的に拡張する
 ⇒最大値が255だからといって、1ブロックに255個のITLを作れるわけではない
  →空き領域による制限
   1エントリ毎に可変トランザクションヘッダ(KTBIT)で使用する24Byteの容量を必要とする。
   ブロック内の容量が足りなくなれば、ITLを作ることができなくなる。
  →ブロックサイズによる制限
   ブロックサイズによって、ITLの最大数はあらかじめ決められている。
   ブロックサイズ:ITLの最大値
   2KB : 41
   4KB :  84
   8KB : 169
   16KB : 255
   32KB : 255

参考
ITL (Interested Transaction List)
http://www.shift-the-oracle.com/table/ITL.html
トランザクションエントリに関する検証 その1
http://www.insight-tec.com/mailmagazine/ora3/vol143.html
索引の使い分けでパフォーマンスを向上できるケース
http://www.atmarkit.co.jp/fdb/rensai/orasql09/orasql09_4.html
  1. 2010/03/20(土) 04:23:13|
  2. oracle
  3. | トラックバック:0
  4. | コメント:0

Oracleのデータ構造について


データ構成


●テーブルスペース(表領域)
・複数のセグメントから構成される
・OS側では1つ以上の物理ファイルで構成される
・代表的な表領域として、下記①~⑤が挙げられる。
 ①システム表領域(SYSTEM)
 ⇒データディクショナリ表が格納される
  →データディクショナリには、オブジェクトの管理情報や
   ストアドサブプログラムのコンパイル済みコード等が格納される
 ②システム補助表領域(SYSAUX)
 ⇒OEM等のOracleコンポーネント製品で利用される表が格納される
 ③UNDO表領域(UNDOTBS1等)
 ⇒1つ以上のUNDOセグメントが格納される
 ④一時表領域(TEMP等)
 ⇒PGAのソート領域が足りなかった場合、この領域にもソート処理に必要な情報が格納される
 ⑤ユーザ表領域
 ⇒アプリケーションで使用される表や索引を格納するユーザ用の表領域
・表領域の管理方法には以下の2種類がある
 ①ローカル管理
 ⇒データファイルのヘッダにエクステント管理情報を格納する
  →データディクショナリ表へのIOが発生しないため、若干性能がいい
  →表領域のエクステントサイズの変更ができない
  →更新処理のほとんどがダイレクトパスインサートである等、特殊な事情
   がない限り、ローカル管理方式を採用することがメジャー
 ②ディクショナリ管理
 ⇒データディクショナリにエクステント管理情報を格納する
  →データディクショナリ表へのIOが発生するため、若干性能が悪い
  →表領域のエクステントサイズの変更ができる
  →大量のエクステントを解放する処理が行われた場合(TRUNCATEやコアレス等)、
   STエンキュー(領域管理トランザクションのキュー取り出し処理)が大量に発生し、
   一時的に大幅な性能劣化を招く
  

●セグメント
・複数のエクステントから構成される
・表や索引のオブジェクト=セグメント
・ソート用やUNDO用のようなOracleが自動的に管理するセグメントもある
・セグメントの空きエクステントがなくなった場合、表領域から新たにエクステントが割り当てられる
・代表的なセグメントとして、下記①~⑨が挙げられる。
 ①表
 ②表パーティション
 ③索引
 ④索引パーティション
 ⑤UNDOセグメント
 ⑥一時セグメント
 ⑦LOB
 ⑧LOBパーティション
 ⑨クラスタ表(異なる表で共通の列があった場合、複数の表間で同じデータブロック共有する)
ハイウィータマーク(HWM)によって、セグメント内でどこまでのブロックが使用済みになっているかを認識している。あるセグメントに新しいトランザクションによって新規に行が挿入されるとき、HWMより下に十分な容量の未使用ブロックが存在していなかった場合、新しいエクステントがそのセグメントに割り当てられる。
 ⇒HWMより上のブロック(新しく割り当てられるエクステント)
  →未フォーマットかつ未使用
 ⇒HWMより下のブロック(現在まで獲得しているエクステント)
  →割り当て済みだが未フォーマットかつ未使用
  →フォーマット済みかつデータが格納されている
  →フォーマット済みだがデータが削除されたため未使用
  のいずれか
  

●エクステント
・複数のブロックから構成される
・表や索引を作成する際、エクステントサイズを指定できる。
・エクステントの数が多すぎるとパフォーマンスが低下する可能性もある
 ⇒目安としては100以上のエクステント数を持つセグメントが多数あれば、パフォーマンスに
  悪影響を与えることがあります。特に索引のエクステントが多いと、RangeScanで検索する
  SQL処理でのパフォーマンスが低下します。

  引用
  表領域とディスクI/Oの要注意ポイント
  http://www.atmarkit.co.jp/fdb/rensai/oraobstacle08/oraobstacle08_1.html
・エクステントの数とサイズは記憶域パラメータでセグメントごとに設定される。優先順位は下記①~③において、①>②>③の順。
 ①セグメントのSTORAGE句
 ②表領域のSTORAGE句
 ③Oracle Databaseのデフォルト
 

●Oraleブロック
・Oracleが扱うデータの最小単位
・1つ以上のOSブロックで構成される
・ブロックサイズは表領域作成時に指定でき、2KB、4KB、8KB、16KB、32KBのいずれかを指定できる
・ブロックの構成として、下記①~③で主に構成される
 ①オーバーヘッド
  ⇒下記3つの情報が格納される
   →ブロックヘッダ
    データブロックのディスクアドレスやセグメントタイプ、トランザクション履歴情報等など、
    一般的な情報が格納される。また、トランザクションエントリ用の領域も確保される。
   →表ディレクトリ
    このブロックに行を持つ表についての情報が格納される
   →行ディレクトリ 
    このブロックの行データの中に実際に存在する各行個別の情報(アドレス情報等)が格納される
  ⇒オーバーヘッドは上から順に書き込まれていく
 ②空き領域
 ⇒オーバーヘッドと行データを格納するために、事前に確保している
 ⇒下記2つのパラメータによって、ブロック内の空き領域は調整される
   →PCTFREE
   空き領域をブロック内でどれだけ確保するかの閾値。PCTFREE=10だと、ブロック内
   の90%まではオーバーヘッドと行データで使用でき、90%を超えると新規行データを
   追加できなくなる。残りの10%は既存行データ更新のために空き領域にしておく。
   →PCTUSED
   PCTFREEで指定した限界使用量に一度達したブロックが、次に新規行データを使用
   できるようになるまでの閾値。PCTFREE=10、PCTUSED=40だと、オーバーヘッド
   と行データの使用量が一度90%以上になったブロックに対して、再び新規行データ
   を追加できるようになるには、使用量が40%未満に下がらなくてはならない。
 ③行データ
  ⇒表データまたは索引データが格納される
  ⇒レコード長が長い場合は、1レコードが複数のブロックに渡って格納される場合もある。
   また、LOB型のデータ(大きなサイズのデータ型)をカラムに持つレコードは、
   ロケータ( LOB の格納先のポインタを格納する構造体)を利用してLOB専用の領域に
   実データが格納される。
  ⇒ブロックの下から順に書き込まれていく






参考
Oracle Database概要 11gリリース2(11.2)
12 論理記憶域構造
http://download.oracle.com/docs/cd/E16338_01/server.112/b56306/logical.htm
システム表領域
http://www.shift-the-oracle.com/tablespace/system-tablespace.html
ローカル管理表領域
http://www.shift-the-oracle.com/tablespace/local-management-tablespace.html
ディクショナリ管理表領域
http://www.shift-the-oracle.com/tablespace/dictionary-management-tablespace.html
ブロック、エクステント、セグメント
http://www.shift-the-oracle.com/oracle/datablock-extent-segment.html
ORACLE MASTER Silver DBAポイント解説
第4回 Oracleの表領域の管理
http://jibun.atmarkit.co.jp/lskill01/rensai/omsdb04/omsdb01.html
ORACLE MASTER Silver DBAポイント解説
第5回 記憶領域構造とUNDOデータの管理
http://jibun.atmarkit.co.jp/lskill01/rensai/omsdb05/omsdb01.html
LOB 型の格納方式
http://www.shift-the-oracle.com/table/lob-storage.html
  1. 2010/03/20(土) 03:43:30|
  2. oracle
  3. | トラックバック:0
  4. | コメント:0

Oracleのキャッシュ構成

キャッシュ

●システムグローバル領域(SGA)
 下記①~⑥の情報を、全てのサーバプロセス、バックグラウンドプロセスで共有する。

 SGA_TARGETにて自動管理の有無、SGA_MAX_SIZEにて最大値を設定できる。自動管理にした場合は、DB_CACHE_SIZE、SHARED_POOL_SIZE、LARGE_POOL_SIZE、JAVA_POOL_SIZE、STREAMS_POOL_SIZEが自動でサイズが調整されるが、LOG_BUFFERは自動管理の対象外である。

①データベースバッファキャッシュ
 データファイルから読み込んだブロックを保持する。また、サーバプロセスによって更新されたデータを、データファイルに反映するまで保持する。
②共有プール
・ライブラリキャッシュ(共有SQL領域)
 SQLのハード解析結果や実行計画を保持する。
・データディクショナリキャッシュ
 データベースのオブジェクトに関する構成情報や統計情報を保持する
・サーバ結果キャッシュ
 SQLの問い合わせ結果セットを保持する
・予約プール
 5KBより大きいデータをOracleが利用する際、それらのデータを連続したチャンクとして保持する
③REDOログバッファ
 REDOエントリを、REDOログに書き込むまで保持する。
④ラージプール
 「共有サーバのセッション情報」「I/Oスレーブ(OSの非同期IOをシミュレートすることによって、データファイルへの書き込みを非同期で行うプロセス)」「Recovery Manager(RMAN)」に関連する情報を保持する。
⑤Javaプール
 javaのストアドプロシージャ等、JVM内の全セッションで利用するデータを保持する
⑥ストリームプール
 Oracle Streams(メッセージキューイングやデータレプリケーションを提供する機能)で使用するデータを保持する


●プログラムグローバル領域(PGA)
 下記①~③の情報を、各サーバプロセス、バックグラウンドプロセス個別で利用する。
 PGA_AGGREGATE_TARGETを指定することによって自動管理の有無と最大値を設定できる。自動管理にした場合は、SORT_AREA_SIZE、HASH_AREA_SIZEなどが自動でサイズ調整される。

①SQL作業領域(※1)
・ソート領域
 ORDER BY、GROUP BY等のソート処理や、ソート/マージ結合に必要な作業領域を保持する
・ハッシュ領域
 ハッシュ結合でハッシュ表を作成する際に必要な作業領域を保持する
・ビットマップマージ領域
 ビットマップ索引スキャンで取得したビットマップをマージする際に必要な情報を保持する
②プライベートSQL領域(≒カーソル)(※2)
 カーソルは「SQL問合せ結果を一時的に蓄えておく領域」のようなものである。カーソルが保有するポインタ情報を元に、アプリケーションがSQL問合せ結果をより詳細な形で(複数結果のセットに対して1行ずつ等)取得することが可能になる。
 1セッションが利用できるプライベートSQL領域の数は初期化パラメータOPEN_CURSORSによって指定する。また、初期化パラメータCURSOR_SHARINGにて、同じカーソルを共有する為のSQL文の判定基準を指定することによって、バインド変数を使用していないSQLでもバインド変数と同等の効果を得ることができる。
 プライベートSQL領域は、下記2種類の領域を保持する。
・ランタイム領域
 SQLの実行状態情報を保持する。フルスキャンが現在何行まで行われたか等、リアルタイムのSQL情報が格納される。SQL文が完了すると、ラインタイム領域は解放される。
・持続領域
 SQLのバインド情報を保持する。カーソルがクローズするまで情報が保持される。
③セッションメモリ(※3)
 ユーザグローバル領域(UGA)と呼ばれる、ユーザのセッションに関する情報を保持する

(※1)専用サーバ接続のときのみPGAに格納される。共有サーバ接続の際は、(SORT_AREA_SIZEとSORT_AREA_RETAINED_SIZEを同じ値に設定することによって)ラージプールに格納される。
(※2)持続領域の位置に関しては、専用サーバ接続の場合のみPGAに格納される。共有サーバ接続の場合は、SGAの中に確保される。ランタイム領域に関しては、いずれの場合もPGAに格納される。
(※3)専用サーバ接続のときのみPGAに格納される。共有サーバ接続の際は、SGAにに格納される。



参考
Oracle Database概要 11gリリース2(11.2)
14 メモリー・アーキテクチャ
http://download.oracle.com/docs/cd/E16338_01/server.112/b56306/memory.htm
SGAのメモリ自動管理(SGA_TARGET)
http://oracle.se-free.com/tuning/B3_sga_target.html
PGAのメモリ自動管理(PGA_AGGREGATE_TARGET)
http://oracle.se-free.com/tuning/B3_pga_aggregate_target.html
最大カーソル数( OPEN_CURSORS )
http://oracle.se-free.com/tuning/B6_open_cursors.html
カーソル共有方式( CURSOR_SHARING )
http://oracle.se-free.com/tuning/B6_cursors_sharing.html
12.2. カーソル
http://www.techscore.com/tech/sql/12_02.html


  1. 2010/03/14(日) 10:26:50|
  2. oracle
  3. | トラックバック:0
  4. | コメント:0
次のページ