【Oracle】 リリースモデル解説

本記事の目的

Oracle Database Administration (oracle Gold)の学習がメインである。
個人的に理解するのにわかりにくかったところを記事としてまとめた。

目次

1. 今回の内容
2. g・R・cについて
3. 12c R2以降のモデル 解説
4. 12c R1以前のモデル 解説
5. Oracle 12c R2ファミリーについて

1.今回の内容

今回は、oracleのリリースモデルについての記事である。
リリースモデルは、12c R1以前と12c R2以降とで、体系が変わってくるので
それらをわかりやすく記載したい。

2. i・g・R・cについて

oracleのバージョンには、
・9i
・11g R1
・19c

上記のように、メジャーリリース番号の末尾にローマ字が記載されている。
これはそれぞれ、以下の意味合いで使用されている。

i：Internet(インターネット)
時代の背景としてインターネットが、普及
→インターネット関連の機能を強化した意味も込めたi

g：grid
grid機能が、新たに追加されたことの意味が込められたg

R：Release
Releaseバージョン、リリース世代を示している

c：Cloud
時代の背景としてcloudが、普及
→cloudに対応した機能の強化した意味を込めたc

3. 12c R2以降のモデル 解説

■年次リリースモデルについて

2018年(18c)から、基本的に毎年新しいメジャーバージョンのリリースを行っている。
20cは、新型コロナウイルスの影響でリリースは見送られた。
20cのように、絶対毎年メジャーリリースするというわけではない。

メジャーリリースが行われると、最新以前の製品のサポート期間が終了に迫ってきていることを示している
→新しくリリースされた製品を購入してDB移行を検討する必要が出てくる

■リリース番号について

リリース番号は、以下のように5つのフィールドに分けることができる

　　　　　　　　重要なのは、前の3つのフィールド！！

第1フィールド：
19が当たる。
これは、メジャーリリース番号で、リリースされた最初の年の末尾2桁が入る。
基本的に年次リリースなので、毎年最新バージョンが出る。
20c：新型コロナウイルスの影響で見送り
22c：なさそう。。。？

19c→23cのようにアップグレード行う際、データ移行が必要である。

第2フィールド：
3が当たる。
これは、マイナーリリース(RU)を充てると更新されるフィールドになる。
年次リリースモデルの場合、四半期(1,4,7,10月)に修正パッチが提供されるため、それらを適用すると、このフィールドは都度更新される。
パッチ適用を行う場合は、データ移行は不要。

第3フィールド：
1が当たる。
これは、RUの修正版であるRURを充てると更新されるフィールドである。
これもRU同様、年次リリースモデルの場合、四半期(1,4,7,10月)に修正パッチが提供される。
RURは、2つまでしか提供されないため、このフィールドに入る数字は、
0 or 1 or 2
の3パターンである。

第4フィールド：
0が当たる。
将来的に使用する可能性がある予備のフィールドである。
基本的に現状、何も入らないため0が入っている。

第5フィールド：
xxxxxが当たる。
RUのリリース日が入る。

詳細は、Oracle HPを参照してほしい。

■RU(Release Update)について

RUは、以下の情報が含まれる
・バグの修正
・新機能や改善
・セキュリティアップデート
・パフォーマンス改善

以下、補足情報である。
・修正情報は、累積的である。
つまり、過去すべてのリリースアップデートの修正が含まれる
例えば、
oracle 19.3.0をインストールした後に、最新のRU(22)のパッチを適用
→19.22.0になる
これは、これまでの修正情報等すべて含まれていることを示す。

・新機能について、バグが入っている可能性があるので運用している方はRUのみ充てる場合は、要注意！

■RUR(Release Update Revisions)について

RUで発生したバグの修正とセキュリティアップデートが入っている。

Q. セキュリティアップデートはなぜ頻繁にする必要があるの？
A.新しい脅威は常に進化してるから。また、データ保護の法改正も頻繁に代わるため。

4.12c R1以前のモデル 解説

■従来のリリースモデルについて

数年に一度10g→11gのように、メジャーリリース番号が変わるリリース体系になっている。
年次リリースモデルでも記載したが、
メジャーリリースが行われると、最新以前の製品のサポート期間が終了に迫ってきていることを示している
→新しくリリースされた製品を購入してDB移行を検討する必要が出てくる

■リリース番号について

リリース番号も、以下のように5つのフィールドに分けることができる

　　　　　　　　重要なのは、前の4つのフィールド！！

12cR2は

• 第1フィールド=12
• 第2フィールド⁼2

の文字を採用している。

また、よく12.2.0.1のように第5フィールドが省略されることがある。

第1フィールド：
11が当たる。
これは、メジャーリリース番号でリリースした年は関係なく、11の次は12のように決まってるっぽい。
裏付けとして、
11gのリリース年：2009年 9月
12cのリリース年：2013年 1月

参照資料

11g→12cのようにアップグレード行う際、データ移行を行う必要がある

第2フィールド：
2が当たる。
これは、データベース・リリース番号の更新を指す。
メジャーリリースの間で、行われている。
具体的なメジャーリリースとの切り分けとしては、以下のことが挙げられる。
▼メジャーリリースは、製品全体のアーキテクチャを修正する

11gと12cを例に出すと
11g：データベースのクラスタリングやリソース管理の強化
12c：クラウド環境への対応が強化

▼データベース・リリース番号の更新は、メジャーリリースバージョン内での機能強化やバグ修正
12cR1と12cR2を例に出すと
12cR1：CDB内で最大252個のPDBを設計可能
12cR2：CDB内で最大4096個のPDBを設計可能

更新の頻度は、第1フィールドと同様に不定期で行われる。
12cR1→12cR2みたいなへのアップグレード行う際、データ移行を行う必要がある。

第3フィールド：
1が当たる。
アプリケーションサーバーリリース番号
基本的にはこのフィールドの更新によって、oracle本体の機能修正等が発生することは、ほとんどない。
また、ここのフィールドは、実際にほとんど更新されたことがなかったため、基本的にこのフィールドは、0の普遍値として考えて問題ない。
Oracle Application Server 概要

第4フィールド：
4が当たる。
コンポーネント固有のリリース番号
SQLの関数のバグ修正やセキュリティ強化等のマイナーアップデートをイメージしてほしい。
これを更新する際は、PSRというパッチを適用する。
データ移行は不要となっている。
更新頻度は不定期(1‐2年に一度ペース)

第5フィールド：
0が当たる。
プラットフォーム固有のリリース番号
主にセキュリティ面とPSRの不具合を修正するためのアップデート
これを更新する際は、PSUというパッチを適用する。
データ移行は不要となっている。
更新頻度は4半期に一度

こちらの資料めちゃくちゃわかりやすいので是非確認してみてください

■PSR(Patch Set Release)について

1-2年程度に一度oracle社からリリースされていたパッチセット
PSRは、以下の情報が含まれている。

• バグの修正
• 新機能や改善
• パフォーマンス改善

基本的に

• 11cR1のように第2フィールド⁼1の場合は、PSRが一つ(11.1.0.1~11.1.0.2)
• 11cR2のように第2フィールド=2の場合は、PSRが三つ(11.2.0.1~11.2.0.4)
  提供される。

■PSU(Patch Set Update)について

四半期に一度リリースされるパッチ
バグ修正やセキュリティの強化が入っている

5.Oracle 12c R2ファミリーについて

12.2.0.2と18c リリースが同等
12.2.0.3と19c リリースが同等

実際には、12.2.0.2というモデルにアップデートするPSRリリースされておらず、12.2.0.1の次は18cである。
このことから、18cはしばしば12.2.0.2に相当するといわれている。
つまり、Oracle Database 12c Release 2（12.2.0.1）を使用している場合、次のアップデートは18c以降のバージョンになる！！

上記が、Oracle 12c R2ファミリーの概要である。