VMWare のすべてのサーバーCPUコアでOracleDBのEnterprise版がライセンス要求される
基本的にStandard版（SE/SE1/SE2）利用は、ソケット単位でのライセンスで物理サーバーで2ソケット（SE除く）を最大とするという制限が設けられています。また、NUPは、基本的には小規模でユーザーリストを管理して主に開発環境用途に用いられます。ところが、SEのNUPやProcessorライセンスが気付けばVMWareの環境にお引っ越ししていた、なんてことがよくあるのが今日です。しかも、Oracle Enterprise Manager のオプションはその大部分が有償でEnterprise版専用オプションとなっているため、厳密な管理をしていないと有償オプションを気が付かないうちに使用してしまっている、なんてことが発生します。少なくとも私がご相談を受けた案件の90％のユーザーさんが、これらのケースにあてはまります。ある程度の規模のユーザーさんであれば、ほぼ100％これらのケースにあてはまるシステムが存在します。
恐ろしいのは、仮想環境において一カ所でもこのケースが発生していると、その影響は全仮想環境のサーバーのCPUコアでのライセンス要求へと、爆発的にリスクが高くなることです。これが、Soft Partitioning ポリシーの非常に恐ろしいところなのです。つまり、「Oracle と VMWare を混ぜると危険、爆発します！」ということなのです。何年も注意喚起はしてきたのですがなかなか浸透しないので、今一度忠告致しますが、コンプライアンス上のリスクは災害級です。是非、十分に注意して対策、コントロールしてください。対応方法については過去のコラムでも言及していますが、ポイントを以下にまとめます。

① 物理サーバーに閉じ込める
② 共有ストレージを使用しない。VMWare同様、爆発します（またはLUNで制限する）
③ VMWare 環境においてはSE2 Proc をすべてのソケットに充足し、オプションを使用しない
（だいたい気が付かないでオプション利用しています）
④ L3スイッチでVLAN構成をとり物理的ネットワークセグメントで分母を制限する
⑤ NUPは開発のみで利用（小規模組織で利用者名簿管理できる場合を除く）
混ぜると爆発します

上記の対策が不十分であるとどうなるのか？「爆発します」つまり、仮想環境のすべてのサーバーのCPUコアでライセンスが要求される可能性が高くなり、数百ライセンスのEnterprise版が要求される論拠となってしまいます。
例え、それが1システムでも？「はい」たとえそれが大規模な仮想環境上の1システムでも、です。
「そんなバカな、大げさに言ってるんでしょ？脅かして、もっと真剣に管理しないとダメですよって言いたいから」とよく言われますが、とても控えめに言っています。
実際にユーザーさんが経験されると「武内さんが言ってたことはホントなんですね！」となるのですが、そうなってからでは遅いので、できればそうなる前に対策してください。

コロナ禍でも監査は減らない
コロナ禍の影響で税務署の監査は対面でのやり取りがあるので感染リスクを考慮し減少している、と言われていますが、Oracle社の監査は逆に増加していると言われています。その原因の一つが監査パートナーを増やしていることや、リモートでの監査を実施し、データをポータルにアップロードする形態をとっていることなどがあげられます。
欧米では大手組織に限らず中小規模の組織にも監査レターが来ていると言われています。日本国内においても上場企業であれば、ほぼ確実に監査対象となることは間違いありません。手遅れになる前に、「自主監査」を実施し、「自主的な是正」によりコンプライアンス対策を万全にしておきましょう。