Exadata Database Service 四半期インフラ・メンテナスを複数日に分割・適用順番を変えてみる

この記事は Oracle Cloud Infrastructure Advent Calendar 2025 Day 20の記事として書いています。 qiita.com

Oracle Cloud Infrastructureのサービスの１つであるExadata Database Service on Dedicated Infrastrucuture (ExaDB-D)では、四半期に１度のオラクルが実施するインフラ側のメンテナンスがあります。 複数の修正やセキュリティ対応のために、オラクル管理範囲に対して更新作業が実施されるもので、Exadata Systems Softwareと呼ばれるExadataのソフトウェア・コンポーネントのアップデートです。

このメンテナンスを複数回に分けたり適用順番を変えることができる新機能「四半期ごとのExadata Infrastructureメンテナンス計画および実行の拡張」が2025年2月に実装されていたのですが実際に設定した結果をまとめたいと思います。

なお、Exadata Database Service on Cloud at Customer(ExaDB-C@C)でも2024年8月に同様の機能が実装されており共通の内容ですが、画面がExaDB-Dのものなので、本記事はExaDB-Dのものとして公開します。

はじめに

今回メンテナンスの設定をするシステムは、データーベース・サーバー２台＋ストレージ・サーバー３台の最小構成です。 デフォルトの設定では、下記の

• 1回のメンテナンス・ウィンドウで全てのサーバーを更新

• 1台ずつローリング適用(データーベース・サーバー1→2→...ストレージ・サーバー1→2...と数字順)

となっています。ローリング適用は、適用中のサーバーでは再起動がかかりますが、Real Applcation Clusters(RAC)・Oracle Grid Infrastructure(GI)といったデーターベースやストレージのクラスタリングによって、データーベースとして(サービスとして)はオンラインのまま実行されます。オンラインで実行される一方で、１台ずつシーケンスで実行されるので、サーバー数が多ければ多いほどメンテナンス・ウィンドウが長くなってきます。(メンテナンス・ウィンドウ=メンテナンスの推定時間の情報は MOS KB 181723 Exadata Infrastructure maintenance timeframes をご確認ください)

１度のメンテナンス・ウィンドウを短くするには、

• 非ローリング(全停止)
• メンテナンスを複数回に分ける

のいずれかになります。

今回は、「メンテナンスを複数回に分ける」を実施します

設定方法

インフラストラクチャ・メンテナンスの設定は、下記のいずれかになります。

1. プリファレンスの設定(今後計画されるものへの事前設定)
2. 計画済みのスケジュールの変更

今回は、1の「プリファレンスの設定」で見ていきます。

メンテナンス・スケジューリング・ポリシーの作成

Exadata Infrastructure > 左のバーにある「スケジュール・ポリシー」を選択。「メンテナンス・スケジューリング・ポリシーの作成」をクリック

各項目を選択していきます。

メンテナンス・スケジューリング・ポリシーの作成画面

最初は1回分の内容しか入力できないので、複数回にわけたい場合はポリシー作成後に編集していきます。

ウィンドウ期間の強制

ここで注目したいのが、「期間(時間)」と「ウィンドウ期間の強制」です。「期間(時間)」はデフォルトでは平均のメンテナンス時間が入っているのですが、1回の許容できるメンテナンス・ウィンドウ(時間)を入力して、「ウィンドウ期間の強制」を有効(スライドして青にする)と、1回のメンテナンスは「期間(時間)」で設定された時間でしか実施されないようになります。

ドキュメント: メンテナンス・スケジューリング・ポリシー

次に、2回目のメンテナンスを明示的にポリシー設定します。 作成されたメンテナンス・スケジューリング・ポリシー名をクリックし、「メンテナンス・ウィンドウ」タブをみてみます。

先ほど設定した内容でポリシーが１レコードできているので、「メンテナンス・ウィンドウの追加」をクリックします。 例では、1回目に設定した翌週の同時間帯に実施されるように入力してみました。

これで、メンテナンス・スケジューリング・ポリシーの作成は完了です。

ポリシーをメンテナンスのプリファレンスに設定

次に、メンテナンス対象のExadata インフラストラクチャに、作成したポリシーを反映していきます。 Exadata インフラストラクチャ > 「アクション」 > 「メンテナンスのプリファレンスの編集」

メンテナンスの構成で、「顧客管理スケジュール」と「スケジューリング・ポリシーのメンテナンス・ウィンドウのプリファレンスを使用をクリックし、ポリシーの選択で作成したポリシーを選択します。

すると、下の方に表示される「メンテナンス・スケジューリング・プラン」がポリシーに基づいた内容で表示されます。

この例だと、２回にわたって計画されることになっており、 1回目 : 各四半期の最初の月の第１日曜日15:00(UTC)からDBサーバー２台+ストレージ・サーバー1台 2回目: 各四半期の最初の月の 第１日曜日15:00(UTC)からストレージ・サーバー2台 という内容になっています。ここで表示される対象のサーバーは、DBサーバー->ストレージ・サーバーの順番で実施していき、1回目でウィンドウ期間の強制 で指定した時間内に収まらないものを2回目に実施する、という形で自動設定されます。

内容を確認したら、「保存」します。

「メンテナンス・スケジューリング・プラン」タブをみると、先ほどの内容が反映されています。

各メンテナンスのアップデート対象を変更

前述したように、デフォルトで入った対象サーバーを変えてみます。

よくある相談の例に沿って、変更してみます。

相談1 : 「データベース・サーバーとストレージ・サーバーを別日にできないか」

2回のメンテナンスがデータベース・サーバーとストレージ・サーバーで分かれるように編集していきます。 今は1回目に予定しているストレージ・サーバー１台を2回目に移動させて、1回目がデータベース・サーバーだけ、2回目がストレージ・サーバーだけにします。

移動先のメンテナンスの右端の…から「編集」をクリック。

アクション・タイプで「ストレージ・サーバーのExadata完全ソフトウェア更新」の右端の…から「編集」をクリック。

ストレージ・サーバーの数が「２」になっているので、「ストレージ・サーバーの追加」をクリック

１回目のメンテナンス・ウィンドウを選択し、ストレージ・サーバー１台分を選択して「保存」

ストレージ・サーバーの数が「３」になったので「編集」をクリック

1回目がデータベース・サーバーだけ、2回目がストレージ・サーバーだけというプランに変わりました。

相談2 : 「２ノード目のデータベース・サーバーから先にメンテナンス実施できないか」

メンテナンス実施のデーターベース・サーバーの順番を変えていいます。

「メンテナンス・スケジューリング・プラン」タブで、対象にデータベース・サーバーが含まれるメンテナンス・ウィンドウの右端…の「編集」をクリック

アクション・タイプ「DBサーバーのExadata完全ソフトウェア更新」の右端…の「編集」をクリック

「スケジュール・アクションの編集」でDBサーバーが上から適用順に並んでいるので、順番を変更したいサーバーの右端…の「編集」をクリックし、UPもしくはDOWNで順番を変更 ※ 2025年12月現在、日本語の画面では誤った翻訳になっているのでわかりにくくなっているため、英語でのスクリーンショットを貼ります。現在修正対応中です。

順番が変わったことを確認し、「編集」をクリック

「メンテナンス・スケジューリング・プラン」タブでも、サーバーの順番が変わったことが確認できます。

なお、ここまでの設定で不備があると、各ポリシーなどの"状態"が「注意が必要」ステータスになるので、ドキュメントのNote部分を参考にしながら設定を確認していください。 ドキュメント: 注意が必要な状態のメンテナンス・スケジュール・ポリシーの編集

計画されたスケジュールを確認

Exadata Infrastructure > Exadataインフラストラクチャの情報 > メンテナンス > 次の四半期メンテナンス > 「表示」> メンテナンス・ウィンドウ から計画された日時と詳細を確認します。

「メンテナンス・スケジューリング・プラン」を編集していく画面でもメッセージがでていましたが、メンテナンス・スケジューリング・プランを変更した内容は計画済のメンテナンスや、メンテナンス・スケジューリング・ポリシーで設定した開始月より前のものには反映されないので注意が必要です。

今回の環境では、作業をした時点ですでにメンテナンスが予定済だったので、もともと設定されていた内容に基づきプランされており、ここまでの設定は反映されていません。

もし計画済のメンテナンスの内容を編集したい場合は、この画面から変更が可能です。

計画されたスケジュールの変更

ここまでのメンテナンス・スケジューリング・プランの作成と類似の設定項目が編集できます。

メンテナンス・ウィンドウの編集

メンテナンス・アクションの編集

まとめ

今回は、メンテナンスを複数回に分ける方法を紹介しました。メンテナンス・ウィンドウを短くする選択肢は他にもあるので、今度まとめて公開したいと思います。

今年のOCI Advent Calendarはシリーズ４まで作成され、さらに盛り上がっていますね。執筆者の皆様、ありがとうございます。

Oracle Exadataの性能関連機能を試してみる - Oracle LiveLabs

この記事は Oracle Cloud Infrastructure Advent Calendar 2024 Day 18の記事として書いています。

はじめに

またもや前回の記事からだいぶ開いてしまいました。

Oracle LiveLabsにある、 Oracle Exadata platform Performance Features

apexapps.oracle.com

の内容を使って、Exadataの特徴的な高性能を引き出す機能を確認できるので、ご紹介させていただきます。

Oracle LiveLabsとは

Oracleのサービスや製品について、様々なユースケースでお試していただく方法を紹介しているサイトです。2024/12月時点で約1000弱のユースケースが登録されていて、ユーザーの使ってみたい製品やサービス、やってみたいことに応じて環境や方法が解説されています。

試せる内容

Oracle Exadata platform Performance Features　の内容として、本記事を書いている2024/12現在では下記の内容が紹介されています。

• Lab 1: Create Lab Environment : 環境準備。サンプル・データやスクリプトはGithub上に用意されています
• Lab 2: Explore Exadata Storage : CLIを利用したExadata Storageサーバーの情報を確認。ExaDB-Dでは、exacliを利用して実施可能です
• Lab 3: Smart Scan : 自動で処理をExadata Storage Serverオフロードをし、DBサーバー側への転送量・DBサーバー上での処理量を減らすという代表的な機能の１つを試す内容。
• Lab 4: Hybrid Columnar Compression : 表サイズの圧縮する機能の内容。
• Lab 5: Flash Cache :
• Lab 6: Storage Indexes : ストレージ側に自動でインデックス(索引)を作り、不要なI/Oを削減する機能を確認する内容。

Introductionの内容を見ると、今後も内容が追加されていきそうな様子が伺えるので、このページの今後の更新も楽しみです。

環境について

今回使用した環境はこちらです。

• サービス: Exadata Database Service on Dedicated Infrastructure(ExaDB-D) X8M
• Oracle Database 23.6.0.24.10
• Exadata System Software 24.1.5.0.0.241016

後述しますが、LiveLabsに記載のある全ての内容を実施したかったので、今回はExaDB-Dの環境で実行しています。

今回の内容は、Exadataの環境であればほとんどの内容が試せます。

クラウドサービスであれば、Exadata上のOracle Cloud InfrastructureのOracle Databaseサービスの、Autonomous Database、Exadata Database Serviceであればすぐに実施可能です。 現在触れるExadata環境がないといった場合には、Alway Freeの範囲内でAutonomous Databaseを利用して実施してみてください。

とはいえ、サービスによってユーザーができること・できないこと(制限)があるので注意です。 今回のLiveLabsの内容でいうと、実行できる内容は下記の通りです。

Autonomous Database

・"Lab2 Explore Exadata Storage"は不可。(ユーザーがStorage Server側の情報を見れないため)

・"Lab4 Hybrid Columnar Compression" はADWデフォルト有効。ATPはデフォルト無効なので、別途表に対してHCC有効化の設定が必要。

Exadata Database Service on Dedicated Infrastructure(ExaDB-D)

・全て実施可能(ただし、"Lab2 Explore Exadata Storage"はLiveLabsの内容を、別のCLI(exacli)を使う必要あり)

Exadata Database Service on Exascale Infrastructure(ExaDB-XS)

・"Lab2 Explore Exadata Storage"は不可。(ユーザーがStorage Server側の情報を見れないため)

・"Lab5 Flash Cache"を実行するには、別途Flash Cacheの追加が必要

実際に触ってみる

基本的にLiveLabsに手順が載っているので、それを参考にしながらで進められると思います。本記事では、LiveLabsに書いてある内容ではわかりにくかったところやエラーがでた内容をを記載していきます。 (ドキュメント作成者にはフィードバックしているので、いずれ更新されると思います。なので、それまでの間の一時的な補足内容として、みていただければと思います。)

全体的

・Introductionに You have created a dedicated non-CDB database or a PDB in a CDB that is not shared with other PDBs とあるように、内容がNon-CDB構成も想定して書かれています。そのため、CDB構成の場合にはPDBでLabの内容を実行することをお勧めします。

Lab 1 : Create Lab Environment

環境準備の中で気になった・エラーが出た部分をメモ。

Task 1 : Create the USERS tablepspace and SH user

OCIのOracle Databaseサービス上のデータベースには、デフォルトでUSERS表領域が作成されているので、サンプルのSQLを実行するとエラーになります。

SQL> CREATE TABLESPACE users DATAFILE SIZE 4G AUTOEXTEND ON NEXT 1G;
CREATE TABLESPACE users DATAFILE SIZE 4G AUTOEXTEND ON NEXT 1G
*
ERROR at line 1:
ORA-01543: tablespace 'USERS' already exists

なので、既存のUSERS表領域を利用するか、別名で実行しましょう。

Task 2 : Import the table data : 表データのインポート

・Step 2

gitlabにデータのdmpファイルやスクリプトがおいてあるので、OCIの自分の環境へ直接ダウンロードしたかったので、Oracle LinuxのComputeインスタンスにダウンロードしました。(ネットワーク(VNC)の設定で、外部との通信許可をしている環境のみ)

データのdmpファイルをダウンロード

$ wget https://github.com/oracle-livelabs/cloud-database-services/raw/refs/heads/main/exadata-features/prep/files/exadata_features_hol_tables.dmp -P ./

・Step 4

ファイルを共有ストレージではなく、特定のノード上に配置しているので、impdpを実行する際にノード指定で実行しないとエラーになるので注意です。

ORA-39002: invalid operation
ORA-39070: Unable to open the log file.
ORA-39087: Directory name EXADATA_FEATURES_HOL is invalid.

Lab 2 : Explore Exadata Storage

このLabの内容は、Exadata Storage Serverの情報がユーザーからはみることができない、Autonomous DatabaseやExadata Database Service on Exascale Infrastructureでは実行できない内容です。 今回はExadata Databse Service on Dedicated Infrastructure(ExaDB-D)で実行しているので、ExaDB-Dでストレージ・サーバーの情報をみるexacliを利用して実行します。

docs.oracle.com

ExaDB-Dでのexacliの実行方法は、前の記事で書いているのでご参考までに

minamin96.hatenablog.com

・Task 1 １〜５は指示通りで実行できます。 ６で特定のgriddiskの詳細について参照する内容になっていますが、使用している環境のgriddiskの名前がわからない場合には先に確認する必要があるので、先に下記コマンドを実行して確認してください。

 list griddisk 

Lab 3 : Smart Scan

このLabから実際に機能を試す内容になりますが、スクリプトがどこにあるかリンク情報が見つからない・・・ ダンプファイルで案内されていたページから探っていったところ、下記に発見したので、ここのファイルをダウンロードして実行しました。

github.com

実際にLabの内容を実行した結果だけ掲載すると、、

・Task 1 のSmart Scanが動かない場合(falseにしてSQLを実行) lab_smart_scan02.sql

SQL> select a.name, round(b.value/1024/1024, 0) MB
  2  from v$sysstat a, v$mystat b
  3  where a.statistic# = b.statistic# and
  4  a.name in ('physical read total bytes',
  5          'cell IO uncompressed bytes',
  6          'cell physical IO interconnect bytes',
  7          'cell physical IO bytes eligible for predicate offload',
  8          'cell physical IO interconnect bytes returned by smart scan');

NAME                                     MB
---------------------------------------------------------------- ----------
physical read total bytes                          3459
cell physical IO interconnect bytes                    3459
cell IO uncompressed bytes                        0
cell physical IO bytes eligible for predicate offload             0
cell physical IO interconnect bytes returned by smart scan        0

・Task 2 : Smart Scanが動いた場合

SQL> select a.name, round(b.value/1024/1024, 0) MB
  2  from v$sysstat a, v$mystat b
  3  where a.statistic# = b.statistic# and
  4  a.name in ('physical read total bytes',
  5          'cell IO uncompressed bytes',
  6          'cell physical IO interconnect bytes',
  7          'cell physical IO bytes eligible for predicate offload',
  8          'cell physical IO interconnect bytes returned by smart scan');

NAME                                     MB
---------------------------------------------------------------- ----------
physical read total bytes                          3457
cell physical IO interconnect bytes                   2
cell IO uncompressed bytes                         1491
cell physical IO bytes eligible for predicate offload              3457
cell physical IO interconnect bytes returned by smart scan        2

Task1では、"cell physical IO interconnect bytes"の値から全てストレージ・サーバーからDBサーバーに返されているのがわかりますが、 Task2では、"cell physical IO bytes eligible for predicate offload"でほとんどがSmart Scanの対象となって、"cell physical IO interconnect bytes returned by smart scan"からストレージ・サーバーからDBサーバーに返されたIOサイズが小さいことがわかります。つまり、この処理がほとんどストレージ・サーバー側で実行された=オフロードされたことがわかります。

その他、上記で出てきている統計名については、津島博士の記事にわかりやすくまとめられているので、ぜひご参照ください

津島博士のパフォーマンス講座　第69回　Oracle Exadata Database Machineについて

Lab 4 : Hybrid Columnar Compression

特に問題なく実行可能な内容でしたので、実際にLabの内容を実行した結果だけ掲載すると、、

・作成した表の情報。

HCC無効、HCC(ARCHIVE HIGH)、HCC(QUERY HIGH)の３種類。

SQL> select table_name, compression, compress_for
  2  from user_tables
  3  where table_name IN ('CUSTOMERS', 'MYCUST_QUERY', 'MYCUST_ARCHIVE');

TABLE_NAME             COMPRESS COMPRESS_FOR
------------------------------ -------- ------------------------------
CUSTOMERS              DISABLED
MYCUST_ARCHIVE             ENABLED  ARCHIVE HIGH
MYCUST_QUERY               ENABLED  QUERY HIGH

・表のサイズ確認

SQL> select segment_name, round(sum(bytes)/1024/1024, 0) MB
  2  from user_segments
  3  where segment_name in ('CUSTOMERS', 'MYCUST_QUERY', 'MYCUST_ARCHIVE')
  4  group by segment_name;

SEGMENT_NAME                   MB
------------------------------ ----------
CUSTOMERS                1856
MYCUST_ARCHIVE                109
MYCUST_QUERY                  268

Lab 5 : Flash Cache

(力尽きたので、後で追記します・・・)

Lab 6 : Storage Indexes

特に問題なく実行可能な内容でしたので、実際にLabの内容を実行した結果だけ掲載すると、、

SQL> select a.name, round(b.value/1024/1024, 0) MB
  2  from v$sysstat a, v$mystat b
  3  where a.statistic# = b.statistic# and
  4  a.name in ('physical read total bytes',
  5          'cell IO uncompressed bytes',
  6          'cell physical IO interconnect bytes',
  7          'cell physical IO bytes eligible for predicate offload',
  8          'cell physical IO interconnect bytes returned by smart scan',
  9          'cell physical IO bytes saved by storage index');

NAME                                     MB
---------------------------------------------------------------- ----------
physical read total bytes                          1835
cell physical IO interconnect bytes                   0
cell IO uncompressed bytes                        6
cell physical IO bytes eligible for predicate offload              1835
cell physical IO bytes saved by storage index                  1622
cell physical IO interconnect bytes returned by smart scan        0

6 rows selected.

"cell physical IO bytes saved by storage index"という統計名の値が出ていますが、これがStorage Indexによって削減されたI/Oサイズになります。

最後に

クラウドサービスを利用することで、Exadata 特有のSmart Storageの機能が試しやすくなりました。実際にSmart Storage機能の効果がでているかの確認方法としても参考になるので、ぜひ一度LiveLabsの内容をみていただければと思います。

つぶやき: 育休からの復帰後、業務をこなすのに必死で記事を書く時間が取れていないですが、次回の記事(このブログ以外も含め)が2025のAdvent Calendarにならないように、来年は頑張りたいと思います。

Exadata Database Service on Dedicated Infrastrucure (ExaDB-D) でストレージの情報をみる方法

Exadata Database Service on Dedicated Infrastrucure (ExaDB-D) サービスは、VMのOS以上がお客様管理範囲のサービスになりますが、exacli というツールを使うことで、VMのOS上からストレージ・サーバーの情報を確認することができます。

docs.oracle.com

Exadataを触ったことがある方に向けた説明としては、ストレージ・サーバーで実行するcellcliを、DBサーバー側からリモートで管理するツールとしてオンプレミスでも利用されているツールです。ただし、ExaDB-DではExacliから実行できるコマンドが制限されています。マニュアルをみるとわかりますが、ほとんどがLISTコマンド(情報の確認)で、DIAGPACKやIORMPLANに対してだけCREATE/ALTER/DROP/LISTが許可されています。

事前準備

exacliを実行する場合、下記のコマンドをopcユーザーで実行します。

$ exacli -l cloud_user_<clusternmae> -c <Storage Server IP>
Password: <password>

上記の<>の部分は環境ごとに異なるため、まずはこの内容の確認が必要です。

クラスタ名を確認

gridユーザーで下記を実行します

$ crsctl get cluster name
CRS-6724: Current cluster name is 'clu3'

この環境でのクラスタ名はclu3ということがわかりました。

exacliで接続する際のパスワードの確認

rootユーザーで次のコマンドを実行すると、設定されている値が表示されます

#/opt/exacloud/get_cs_data.py
ExaCli initial password is:
xxxxxxxxxxx

ストレージ・サーバーのIPを確認

マニュアルに記載がないのですが、ストレージ・サーバーのIP情報も必要です。

#cat /etc/oracle/cell/network-config/cellip.ora
cell="xxx.xxx.xxx.40;xxx.xxx.xxx.41"
cell="xxx.xxx.xxx.42;xxx.xxx.xxx.43"
cell="xxx.xxx.xxx.44;xxx.xxx.xxx.45"

exacliで接続

事前準備で確認した内容をもとに、実行していきます。opcユーザーで実行します。

接続コマンド

$ exacli -l cloud_user_<clusternmae> -c <Storage Server IP>

例)

$ exacli -l cloud_user_clu3 -c xxx.xxx.xxx.40
Password: <password>

ストレージの情報取得

最後に、実行例を載せておきます。

• 実行環境は、X8Mです

LUNの情報

exacli cloud_user_clu3@xxx.xxx.xxx.40> list lun attributes name, id, status, disktype
     0_0     0_0     normal  HardDisk
     0_1     0_1     normal  HardDisk
     0_2     0_2     normal  HardDisk
     0_3     0_3     normal  HardDisk
     0_4     0_4     normal  HardDisk
     0_5     0_5     normal  HardDisk
     0_6     0_6     normal  HardDisk
     0_7     0_7     normal  HardDisk
     0_8     0_8     normal  HardDisk
     0_9     0_9     normal  HardDisk
     0_10    0_10    normal  HardDisk
     0_11    0_11    normal  HardDisk
     10_0    3ac80eda:3bace425:6ea8c723:cd704b19     normal  FlashDisk
     4_0     57a3e166:0dff23d5:bdf4d91d:7f04c246     normal  FlashDisk
     5_0     0b4eee1e:60ea30ce:800652d9:ca7cec85     normal  FlashDisk
     6_0     590e2f4b:5f7d8bdc:369b8829:3a58a7c9     normal  FlashDisk
     P0_D1   885e0d64-05a3-432d-a878-ed1fe906960e    normal  PMEM
     P0_D10  7d336164-6f36-41eb-b9e5-36cc0ed7e2ac    normal  PMEM
     P0_D3   a2533c75-e3f3-4901-a576-6d48e47412e9    normal  PMEM
     P0_D5   60a85dd8-7f0f-49e9-ba73-5ce09687bbed    normal  PMEM
     P0_D6   cf48afc8-3f6c-49bd-aa55-5bd66c4e77ca    normal  PMEM
     P0_D8   a9c90eb1-f7c7-46b9-a5d5-505567f8b90c    normal  PMEM
     P1_D1   503ce83b-89a9-4068-a82c-de1f4e67f368    normal  PMEM
     P1_D10  74448a12-a528-4b8c-8174-eeabaef2a2ac    normal  PMEM
     P1_D3   f4d1ac5a-5369-416b-a016-16942722a556    normal  PMEM
     P1_D5   218513aa-4f4a-40a5-8f27-369f7fd3ad6b    normal  PMEM
     P1_D6   0e9c77c8-33e7-42d8-b3e0-dd9165361043    normal  PMEM
     P1_D8   65db3a90-8dd1-4e87-814c-889e095ed37e    normal  PMEM

IORMPLANの確認

exacli cloud_user_clu3@xxx.xxx.xxx.40> LIST IORMPLAN DETAIL
     name:                   kix101110exdcl02_IORMPLAN
     catPlan:
     dbPlan:
     clusterPlan:
     objective:              auto
     status:                 active

IORMに関しては、コンソール上からDB間のshareの設定はできるのですが、dbplanの細かい設定がしたい場合などはexacliでも設定可能です。 コンソール上から、２つのデータベースが作成されているVMクラスタに対して、2:1でshareを設定した状態でLIST IORMPLAN DETAILを実行すると、

exacli cloud_user_clu3@xxx.xxx.xxx.40> LIST IORMPLAN DETAIL
     name:                   kix101110exdcl02_IORMPLAN
     catPlan:
     dbPlan:                 name=default,share=1,flashcachelimit=15897.20833333333G
                             name=DB1210_xjx_kix,share=1,flashcachelimit=15897.20833333333G,asmcluster=clu3
                             name=DB1212_2kp_kix,share=1,flashcachelimit=15897.20833333333G,asmcluster=clu3
     clusterPlan:
     objective:              auto
     status:                 active

許可されていない操作を実行した場合

オンプレミスのExadataでのCELLCLIコマンドを、同様に実行できるか確認してみます。 前述したような許可されているコマンド以外を実行すると、下記のようなエラーが出ます。

exacli cloud_user_clu3@xxx.xxx.xxx.40> ALTER CELL hardDiskScrubInterval=weekly

CELL-06015: Current user does not have privileges to run this command.

その他、実行可能な操作に関してはマニュアルをご確認ください。

docs.oracle.com

OCI ExaDB-DのOS上のDB/GIパッチを１ノードずつ適用する方法

この記事はOracle Cloud Infrastructure Advent Calendar 2023 Day21の記事として書いています。

qiita.com

Oracle Cloud Infrastructure Advent Calendar 2023 Day20 の記事は、@takuya_0301 さんの記事「OKE上に展開したLLMでRAGやってみた」でした。

はじめに

２人の産休育休で前回の記事からだいぶあいてしまい、久々の記事です。

今回は、OCI Exadata Database Service on Dedicated Infrastructure (通称 : ExaDB-D)のDB/GIのパッチ適用(更新)を１ノードずつ行う方法を試したので、メモ書きとしてまとめます。

顧客が管理するVM内のOS、Oracle Database(DB)、Oracle Grid Infrastructure(GI)などのコンポーネントのメンテナンスは、顧客のタイミングで実施が可能です。コンソールやAPIからも簡単に適用可能ですが、その場合、VMクラスタ内の全ノードにローリングで適用されます。１ノードずつ適用したい場合は、コマンドツールで実行することで対応可能です。コンソールやAPI側で定期的に状態を監視しているので、コマンドラインで実行後も、タイムラグはあるものの検知されて反映されます。

なお、今回はdbaastools バージョン : 23.4.0.0.0での結果となります。定期的にdbaascliは更新されるので、実施する際には最新マニュアルをご確認ください。

適用方法

１ノードずつ実行したい場合は、VM内にプリインストールされているCLIを利用して行います。

• Oracle Database : dbaascli dbhome patch
• Grid Infrastructure : dbaascli grid patch
• OS : patchmgr

今回は、DBとGIを対象に書くので、dbaascliの内容になります。 OCIドキュメントのExaDB-Dのdbaascliの章で、DBへのパッチ適用方法とGIへのパッチ適用方法がまとめられている箇所がありますが、この例は全ノードを一気に実行する例なので、今回はdbaascli コマンド・リファレンスを見てみましょう

検証情報

• ExaDB-D X9Mインフラストラクチャ上の 2ノードのVMクラスタ
• dbaastools バージョン : 23.4.0.0.0
• DB/GIともに19.20.0.0.0に対する RU 19.21.0.0.0 のパッチ適用

GIパッチ適用

クラウドのツールを利用したGIのパッチ適用(更新)方法は、in-placeになります。

準備

GIへのパッチ適用については、まずはマニュアルのコンソールからの適用の内容や流れを確認することをお勧めします。

・現在のGridホームの情報を表示

# dbaascli system getGridHomes
DBAAS CLI version 23.3.2.0.0
Executing command system getGridHomes
Job id: 12b968e9-f3aa-4c40-9036-aa69ebc12edc
Session log: /var/opt/oracle/log/system/getGridHomes/dbaastools_xxx.log
{
  "OraGiHome19000" : {
    "homePath" : "/u01/app/19.0.0.0/grid",
    "homeName" : "OraGiHome19000",
    "version" : "19.20.0.0.0",
    "createTime" : 1697731875000,
    "updateTime" : 1697731875000,
    "unifiedAuditEnabled" : false,
    "ohNodeLevelDetails" : {
      "<ノード1>" : {
        "nodeName" : "<ノード1>",
        "version" : "19.20.0.0.0"
      },
      "<ノード2>" : {
        "nodeName" : "<ノード2>",
        "version" : "19.20.0.0.0"
      }
    },
    "messages" : [ ]
  }
}

マニュアル dbaascli コマンド・リファレンス dbaascli system getGridHomes

・適用可能なパッチを確認

# dbaascli cswlib showImages --product grid
DBAAS CLI version 23.3.2.0.0
Executing command cswlib showImages --product grid
Job id: b7f5132b-d2c1-4354-b895-25422e22173e
Session log: /var/opt/oracle/log/cswLib/showImages/dbaastools_xxx.log
Log file location: /var/opt/oracle/log/cswLib/showImages/dbaastools_xxx.log

############ List of Available grid Artifacts  #############

1.IMAGE_TAG=grid_19.20.0.0.0
  VERSION=19.20.0.0.0
  DESCRIPTION=19c JUL 2023 GI Image
2.IMAGE_TAG=grid_19.18.0.0.0
  VERSION=19.18.0.0.0
  DESCRIPTION=19c JAN 2023 GI Image
3.IMAGE_TAG=grid_19.19.0.0.0
  VERSION=19.19.0.0.0
  DESCRIPTION=19c APR 2023 GI Image
4.IMAGE_TAG=grid_19.21.0.0.0
  VERSION=19.21.0.0.0
  DESCRIPTION=19c OCT 2023 GI Image
Images can be downloaded using their image tags. For details, see help using 'dbaascli cswlib download --help'.
dbaascli execution completed

マニュアル データベースおよびグリッド・インフラストラクチャで使用可能なソフトウェア・イメージおよびバージョンのリスト

プリチェック

・19.21.0.0.0を適用できる状態かをチェック

# dbaascli grid patch --targetVersion 19.21.0.0.0 --executePrereqs

実行ログ

# dbaascli grid patch --targetVersion 19.21.0.0.0 --executePrereqs
DBAAS CLI version 23.3.2.0.0
Executing command grid patch --targetVersion 19.21.0.0.0 --executePrereqs
Job id: 61416363-e8fb-4994-9126-894473b7bea2
Session log: /var/opt/oracle/log/grid/patch/dbaastools_2023-10-31_02-51-05-PM_1403.log
Loading PILOT...
Session ID of the current execution is: 68
Log file location: /var/opt/oracle/log/grid/patch/pilot_2023-10-31_02-51-08-PM_1891
-----------------
Running initialization job
Completed initialization job
-----------------
Running validate_nodes job
Completed validate_nodes job
-----------------
Running validate_target_version job
Completed validate_target_version job
-----------------
Running validate_backup_locations job
Completed validate_backup_locations job
-----------------
Running validate_source_home job
Completed validate_source_home job
-----------------
Running validate_creg_file_existence job
Completed validate_creg_file_existence job
-----------------
Running validate_crs_stack_state job
Completed validate_crs_stack_state job
-----------------
Running validate_databases job
Completed validate_databases job
-----------------
Running validate_disk_space job
Completed validate_disk_space job
-----------------
Running validate_perm_on_dir job
Completed validate_perm_on_dir job
-----------------
Running validate_users_umask job
Completed validate_users_umask job
-----------------
Running unpackage_patches job
Completed unpackage_patches job
-----------------
Running remove_zipped_patches job
Completed remove_zipped_patches job
-----------------
Running replace_opatch job
Completed replace_opatch job
-----------------
Running check_patch_conflicts job
Completed check_patch_conflicts job
-----------------
Running restore_opatch_prereqs_only job
Completed restore_opatch_prereqs_only job
-----------------
Running cleanup_prereqs_only job
Completed cleanup_prereqs_only job
dbaascli execution completed

マニュアル Oracle Grid Infrastructureパッチ適用の事前チェック

ノード指定でのパッチ適用

--targetVersion で適用するバージョン、--nodeList で適用するノードのホスト名を指定します。 --nodesで指定するノードに含まれるノードから実行してください。 例)ノード１に対しての実行はノード１上から、ノード2・3に対しての実行はノード2・3いずれかから

# dbaascli grid patch --targetVersion 19.21.0.0.0 --nodeList <適用するノードのホスト名>

実行ログ

# dbaascli grid patch --targetVersion 19.21.0.0.0 --nodeList <ノード1>
DBAAS CLI version 23.3.2.0.0
Executing command grid patch --targetVersion 19.21.0.0.0 --nodeList <ノード1>
Job id: 4c79c36e-c8e8-4f06-b0c7-1e96fe3aab7a
Session log: /var/opt/oracle/log/grid/patch/dbaastools_2023-10-31_04-13-34-PM_22831.log
Loading PILOT...
Session ID of the current execution is: 75
Log file location: /var/opt/oracle/log/grid/patch/pilot_2023-10-31_04-13-37-PM_23308
-----------------
Running initialization job
Completed initialization job
-----------------
Running validate_nodes job
Completed validate_nodes job
-----------------
Running validate_target_version job
Completed validate_target_version job
-----------------
Running validate_backup_locations job
Completed validate_backup_locations job
-----------------
Running validate_source_home job
Completed validate_source_home job
-----------------
Running validate_creg_file_existence job
Completed validate_creg_file_existence job
-----------------
Running validate_crs_stack_state job
Completed validate_crs_stack_state job
-----------------
Running validate_databases job
Completed validate_databases job
-----------------
Running validate_disk_space job
Completed validate_disk_space job
-----------------
Running validate_perm_on_dir job
Completed validate_perm_on_dir job
-----------------
Running validate_users_umask job
Completed validate_users_umask job
-----------------
Running unpackage_patches job
Completed unpackage_patches job
-----------------
Running remove_zipped_patches job
Completed remove_zipped_patches job
-----------------
Running replace_opatch job
Completed replace_opatch job
-----------------
Running check_patch_conflicts job
Completed check_patch_conflicts job
Acquiring write lock: _u01_app_19.0.0.0_grid
Acquiring write lock: provisioning
-----------------
Running pre_patch_lock_manager job
Completed pre_patch_lock_manager job
-----------------
Running create_global_backup_loc job
Completed create_global_backup_loc job
-----------------
Running rotate_image_backup job
Completed rotate_image_backup job
-----------------
Running backup_image job
Completed backup_image job
-----------------
Running rotate_config_backup job
Completed rotate_config_backup job
-----------------
Running backup_config-<ノード1> job
Completed backup_config-<ノード1> job
-----------------
Running save_local_backup-<ノード1> job
Completed save_local_backup-<ノード1> job
-----------------
Running stop_db_instances-<ノード1> job
Completed stop_db_instances-<ノード1> job
-----------------
Running run_rootcrs_prepatch-<ノード1> job
Completed run_rootcrs_prepatch-<ノード1> job
-----------------
Running stop_tfa-<ノード1> job
Completed stop_tfa-<ノード1> job
-----------------
Running check_processes-<ノード1> job
Completed check_processes-<ノード1> job
-----------------
Running rollback_conflicting_patches-<ノード1> job
Completed rollback_conflicting_patches-<ノード1> job
-----------------
Running apply_gi_oneoffs_prepatch-<ノード1> job
Completed apply_gi_oneoffs_prepatch-<ノード1> job
-----------------
Running apply_ru-<ノード1> job
Completed apply_ru-<ノード1> job
-----------------
Running stop_processes-<ノード1> job
Completed stop_processes-<ノード1> job
-----------------
Running apply_gi_oneoffs_postpatch-<ノード1> job
Completed apply_gi_oneoffs_postpatch-<ノード1> job
-----------------
Running rootadd_rdbms_script-<ノード1> job
Completed rootadd_rdbms_script-<ノード1> job
-----------------
Running run_rootcrs_postpatch-<ノード1> job
Completed run_rootcrs_postpatch-<ノード1> job
-----------------
Running start_db_instances-<ノード1> job
Completed start_db_instances-<ノード1> job
-----------------
Running update_opatch_log_ownership-<ノード1> job
Completed update_opatch_log_ownership-<ノード1> job
-----------------
Running disable_diagsnap-<ノード1> job
Completed disable_diagsnap-<ノード1> job
-----------------
Running restore_tfa_status-<ノード1> job
Completed restore_tfa_status-<ノード1> job
-----------------
Running remove_local_backup-<ノード1> job
Completed remove_local_backup-<ノード1> job
-----------------
Running cleanup-<ノード1> job
Completed cleanup-<ノード1> job
-----------------
Running cleanup_patched_home_backup job
Completed cleanup_patched_home_backup job
-----------------
Running post_patch_validation job
Completed post_patch_validation job
-----------------
Running update_creg job
Completed update_creg job
-----------------
Running post_patch_lock_manager job
Completed post_patch_lock_manager job
Releasing lock: _u01_app_19.0.0.0_grid
Releasing lock: provisioning
-----------------
Running generate_system_details job
Acquiring native write lock: global_dbsystem_details_generation
Releasing native lock: global_dbsystem_details_generation
Completed generate_system_details job
dbaascli execution completed

参考: ノード2に対して、ノード1から適用しようとした時のエラー

-----------------
Running validate_nodes job
Execution of validate_nodes failed
[FATAL] [DBAAS-70064] Specified cluster nodes '[<ノード2>]' does not include local node name '[<ノード1>]'.
   ACTION: Local node needs to be part of cluster nodes to perform the operation.
*** Executing jobs which need to be run always... ***

マニュアル dbaascli コマンド・リファレンス dbaascli grid patch

適用後の情報

$ opatch lspatches

35762404;OCW Interim patch for 35762404
35763448;ENFORCE V2 CHECKS ONLY FOR CLIENT CLOUD MNEMONIC QUERIES
34697081;NOT SHIPPING LIBAUTH_SDK_IAM.SO IN 23 SHIPHOME INSTALL
35638318;JDK BUNDLE PATCH 19.0.0.0.231017
35652062;ACFS RELEASE UPDATE 19.21.0.0.0 (35652062)
35643107;Database Release Update : 19.21.0.0.231017 (35643107)
35553096;TOMCAT RELEASE UPDATE 19.0.0.0.0 (35553096)
35099674;DSTV41 UPDATE - TZDATA2022G - NEED OJVM FIX
35050341;OJVM RELEASE UPDATE: 19.19.0.0.230418 (35050341)
33575402;DBWLM RELEASE UPDATE 19.0.0.0.0 (33575402)

OPatch succeeded.

・一部のノードでしか適用していない状態で、GIの情報を確認

[root@vmem-6gl0h1 opc]# dbaascli system getGridHomes
DBAAS CLI version 23.3.2.0.0
Executing command system getGridHomes
Job id: 9124f1cd-9130-4ed4-9466-42e2199b23ba
Session log: /var/opt/oracle/log/system/getGridHomes/dbaastools_2023-10-31_05-01-56-PM_175719.log
{
  "OraGiHome19000" : {
    "homePath" : "/u01/app/19.0.0.0/grid",
    "homeName" : "OraGiHome19000",
    "version" : "19.0.0.0.0",
    "createTime" : 1698737961000,
    "updateTime" : 1698737961000,
    "unifiedAuditEnabled" : false,
    "ohNodeLevelDetails" : {
      "<ノード1>" : {
        "nodeName" : "<ノード1>",
        "version" : "19.21.0.0.0"
      },
      "<ノード2>" : {
        "nodeName" : "<ノード2>",
        "version" : "19.20.0.0.0"
      }
    },
    "messages" : [ ]
  }
}
dbaascli execution completed

・全ノードで適用した状態で、GIの情報を確認

# dbaascli system getGridHomes
DBAAS CLI version 23.3.2.0.0
Executing command system getGridHomes
Job id: e941a44b-28b2-4da7-8495-6df39a08e01a
Session log: /var/opt/oracle/log/system/getGridHomes/dbaastools_2023-10-31_06-51-03-PM_295053.log
{
  "OraGiHome19000" : {
    "homePath" : "/u01/app/19.0.0.0/grid",
    "homeName" : "OraGiHome19000",
    "version" : "19.21.0.0.0",
    "createTime" : 1698737961000,
    "updateTime" : 1698737961000,
    "unifiedAuditEnabled" : false,
    "ohNodeLevelDetails" : {
      "v<ノード1>" : {
        "nodeName" : "<ノード1>,
        "version" : "19.21.0.0.0"
      },
      "<ノード2>" : {
        "nodeName" : "<ノード2>",
        "version" : "19.21.0.0.0"
      }
    },
    "messages" : [ ]
  }
}
dbaascli execution completed

マニュアル dbaascli コマンド・リファレンス dbaascli system getGridHomes

無事コンソール上でも、適用後のバージョンに情報が反映されていました

DBパッチ適用

まず、DBのパッチ適用(更新)方法としては、in-placeのOracleホーム(DBホーム)へのパッチ適用と、out-of-placeのDBの移動がありますが、１ノードずつ実行したい場合はin-placeのOracleホームへのパッチ適用になります

マニュアル: dbaascli dbHome patch

準備

・Oracleホームの情報を確認 パッチ適用のコマンド dbaascli dbHome patch --oracleHome で指定するOracleホームのパスを確認します。

マニュアルには、dbaascli dbHome patchでターゲットのOracleホームを --oracleHome か --oracleHomeName パラメータで指定するように書かれているのですが、コンソールから確認できるのは、--oracleHome = Oracleホームのパスの情報なので、今回は簡単に確認できる--oracleHome を使用します。

ちなみに、--oracleHomeName は、--oracleHome の名前がわかっている上でdbaascli dbHome getDetailsを実行すると確認できる "homeName"です。

# dbaascli dbHome getDetails --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_5
DBAAS CLI version 23.4.1.0.0
Executing command dbHome getDetails --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_5
Job id: 8ada5970-9a63-4b74-b1cc-1511df61864e
Session log: /var/opt/oracle/log/dbHome/getDetails/dbaastools_2023-11-17_02-19-27-PM_121372.log
{
  "homePath" : "/u02/app/oracle/product/19.0.0.0/dbhome_5",
  "homeName" : "OraHome6",
  "version" : "19.20.0.0.0",
  "createTime" : 1700188575000,
  "updateTime" : 1700188575000,
  "unifiedAuditEnabled" : false,
  "ohNodeLevelDetails" : {
    "<ノード1>" : {
      "nodeName" : "<ノード1>",
      "version" : "19.20.0.0.0"
    },
    "<ノード1>" : {
      "nodeName" : "<ノード2>",
      "version" : "19.20.0.0.0"
    }
  },
  "messages" : [ ]
}
dbaascli execution completed

マニュアル dbaascli コマンド・リファレンス dbaascli dbHome getDetails

プリチェック

・19.21.0.0.0を適用できる状態かをチェック

# dbaascli dbHome patch --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_5 --targetVersion 19.21.0.0.0 --executePrereqs

実行ログ

# dbaascli dbHome patch --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_5 --targetVersion 19.21.0.0.0 --executePrereqs
DBAAS CLI version 23.4.1.0.0
Executing command dbHome patch --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_5 --targetVersion 19.21.0.0.0 --executePrereqs
Job id: b3acc326-c719-4353-b2f9-5279124cd4c3
Session log: /var/opt/oracle/log/dbHome/patch/dbaastools_2023-11-17_02-27-05-PM_162325.log
Loading PILOT...
Session ID of the current execution is: 951
Log file location: /var/opt/oracle/log/dbHome/patch/pilot_2023-11-17_02-27-08-PM_163064
-----------------
Running initialization job
Completed initialization job
-----------------
Running validate_user_input job
Completed validate_user_input job
-----------------
Running validate_nodes job
Completed validate_nodes job
-----------------
Running validate_oracle_home job
Completed validate_oracle_home job
-----------------
Running validate_source_version job
Completed validate_source_version job
-----------------
Running validate_target_version job
Completed validate_target_version job
-----------------
Running validate_creg_file_existence job
Completed validate_creg_file_existence job
-----------------
Running validate_diag_perm job
Completed validate_diag_perm job
-----------------
Running validate_backup_loc job
Completed validate_backup_loc job
-----------------
Running validate_patch_across_nodes job
Completed validate_patch_across_nodes job
-----------------
Running validate_users_umask job
Completed validate_users_umask job
-----------------
Running validate_gold_image_url job
Completed validate_gold_image_url job
-----------------
Running validate_disk_space job
Completed validate_disk_space job
-----------------
Running validate_audit_files_in_source_home job
Completed validate_audit_files_in_source_home job
-----------------
Running download_gold_image job
Completed download_gold_image job
-----------------
Running validate_gold_image job
Completed validate_gold_image job
-----------------
Running run_installer_prereqs job
Completed run_installer_prereqs job
-----------------
Running check_patch_conflict job
Completed check_patch_conflict job
-----------------
Running remove_unzip_loc job
Completed remove_unzip_loc job
dbaascli execution completed

マニュアル dbaascli コマンド・リファレンス dbaascli dbHome patch

ノード指定でのパッチ適用

--targetVersionで適用するバージョン、--nodesで適用対象のノードのホスト名を指定します。 コマンドは、--nodesで指定するノードに含まれるノードから実行してください。 例)ノード１に対しての実行はノード１上から、ノード2・3に対しての実行はノード2・3いずれかから

# dbaascli dbHome patch --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_5 --targetVersion 19.21.0.0.0 --nodes <ノード名>

実行ログ

# date;dbaascli dbHome patch --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_5 --targetVersion 19.21.0.0.0 --nodes <ノード1>
DBAAS CLI version 23.4.1.0.0
Executing command dbHome patch --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_5 --targetVersion 19.21.0.0.0 --nodes <ノード1>
Job id: 62702836-eee6-4b21-8fed-910e645621de
Session log: /var/opt/oracle/log/dbHome/patch/dbaastools_2023-11-17_02-34-43-PM_213714.log
Loading PILOT...
Session ID of the current execution is: 952
Log file location: /var/opt/oracle/log/dbHome/patch/pilot_2023-11-17_02-34-46-PM_214321
-----------------
Running initialization job
Completed initialization job
-----------------
Running validate_user_input job
Completed validate_user_input job
-----------------
Running validate_nodes job
Completed validate_nodes job
-----------------
Running validate_oracle_home job
Completed validate_oracle_home job
-----------------
Running validate_source_version job
Completed validate_source_version job
-----------------
Running validate_target_version job
Completed validate_target_version job
-----------------
Running validate_creg_file_existence job
Completed validate_creg_file_existence job
-----------------
Running validate_diag_perm job
Completed validate_diag_perm job
-----------------
Running validate_backup_loc job
Completed validate_backup_loc job
-----------------
Running validate_patch_across_nodes job
Completed validate_patch_across_nodes job
-----------------
Running validate_users_umask job
Completed validate_users_umask job
-----------------
Running validate_gold_image_url job
Completed validate_gold_image_url job
-----------------
Running validate_disk_space job
Completed validate_disk_space job
-----------------
Running validate_audit_files_in_source_home job
Completed validate_audit_files_in_source_home job
-----------------
Running download_gold_image job
Completed download_gold_image job
-----------------
Running validate_gold_image job
Completed validate_gold_image job
-----------------
Running run_installer_prereqs job
Completed run_installer_prereqs job
-----------------
Running check_patch_conflict job
Completed check_patch_conflict job
Acquiring write lock: _u02_app_oracle_product_19.0.0.0_dbhome_5
-----------------
Running pre_patch_lock_manager job
Completed pre_patch_lock_manager job
-----------------
Running copy_image-<ノード1> job
Completed copy_image-<ノード1> job
-----------------
Running detach_home-<ノード1> job
Completed detach_home-<ノード1> job
-----------------
Running move_home-<ノード1> job
Completed move_home-<ノード1> job
-----------------
Running move_image_to_home_loc-<ノード1> job
Completed move_image_to_home_loc-<ノード1> job
-----------------
Running setup_db_home-<ノード1> job
Completed setup_db_home-<ノード1> job
-----------------
Running update_inventory-<ノード1> job
Completed update_inventory-<ノード1> job
-----------------
Running root_script_execution-<ノード1> job
Completed root_script_execution-<ノード1> job
-----------------
Running move_config_files-<ノード1> job
Completed move_config_files-<ノード1> job
-----------------
Running backup_old_home job
Completed backup_old_home job
-----------------
Running post_patch_lock_manager job
Completed post_patch_lock_manager job
Releasing lock: _u02_app_oracle_product_19.0.0.0_dbhome_5
-----------------
Running cleanup job
Completed cleanup job
-----------------
Running generate_dbsystem_details job
Acquiring native write lock: global_dbsystem_details_generation
Releasing native lock: global_dbsystem_details_generation
Completed generate_dbsystem_details job
dbaascli execution completed

マニュアル dbaascli コマンド・リファレンス dbaascli dbHome patch

適用後の情報

・一部のノードでしか適用していない状態で、Oracleホームの情報を確認

# dbaascli dbHome getDetails --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_5

DBAAS CLI version 23.4.1.0.0
Executing command dbHome getDetails --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_5
Job id: 82f27e9e-5cd7-4958-a8bf-c7b974fece66
Session log: /var/opt/oracle/log/dbHome/getDetails/dbaastools_2023-11-17_02-55-56-PM_312093.log
{
  "homePath" : "/u02/app/oracle/product/19.0.0.0/dbhome_5",
  "homeName" : "OraHome6",
  "version" : "19.0.0.0.0",
  "createTime" : 1700188575000,
  "updateTime" : 1700199519000,
  "unifiedAuditEnabled" : false,
  "ohNodeLevelDetails" : {
    "<ノード1>" : {
      "nodeName" : "<ノード1>",
      "version" : "19.21.0.0.0"
    },
    "<ノード2>" : {
      "nodeName" : "<ノード2>",
      "version" : "19.20.0.0.0"
    }
  },
  "messages" : [ ]
}
dbaascli execution completed

一部のノードだけだと、コンソール上には反映されず

・全ノードで適用した状態で、Oracleホームの情報を確認

[root@exaem-i704n2 opc]# dbaascli dbHome getDetails --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_5
DBAAS CLI version 23.4.1.0.0
Executing command dbHome getDetails --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_5
Job id: 9136e244-cc24-4124-a53b-06fac39db7c7
Session log: /var/opt/oracle/log/dbHome/getDetails/dbaastools_2023-11-17_03-09-16-PM_31151.log
{
  "homePath" : "/u02/app/oracle/product/19.0.0.0/dbhome_5",
  "homeName" : "OraHome6",
  "version" : "19.21.0.0.0",
  "createTime" : 1700188575000,
  "updateTime" : 1700200875000,
  "unifiedAuditEnabled" : false,
  "ohNodeLevelDetails" : {
    "<ノード1>" : {
      "nodeName" : "<ノード1>",
      "version" : "19.21.0.0.0"
    },
    "<ノード2>" : {
      "nodeName" : "<ノード2>",
      "version" : "19.21.0.0.0"
    }
  },
  "messages" : [ ]
}
dbaascli execution completed

マニュアル dbaascli コマンド・リファレンス dbaascli dbHome getDetails

無事コンソール上でも、適用後のバージョンに情報が反映されていました

さいごに

dbaascliを利用すると、コンソール/APIで実施するよりも細かい指定が可能です。 注意点としては、コンソール/APIから実施する場合には、実行ができないまたは影響がでる可能性がある処理を行おうとすると、画面での選択がグレーアウト or 実行時に別の処理が実行中というエラーで、別の処理との同時実行によるトラブルを防止する仕組み(ロック)になっていますが、dbaascliで更新作業中はコンソール/APIにはそのロックがかからないので、同時実行してしまうとどちらかの処理が失敗もしくは影響を及ぼする可能性があります。そのため、コマンドツールでの実行時は、別の作業者が作業しないように調整していただいた方が良いかと思います。

Oracle Cloud InfrastructureのDatabase ManagementにExaCSを登録してみる

この記事はOracle Cloud Infrastructure Advent Calendar 2021 Day23の記事として書いています。

qiita.com

今年もAdvent Calendarの季節がやってきました。 年末だからと余裕をこいているとなぜか毎年急に忙しくなり、まさに師走というように駆け回る12月を過ごしております。この記事も期日(Advent Calendarの担当日)に間に合うか、冷や汗をかきながら書いています。

今回は、Oracle Cloud InfrastructureのOracle Cloud Observability and Management Platformで利用可能なデータベース管理機能のDatabase Management=データベース管理に、Exadata Cloud Service(ExaCS)のデータベースを登録してみたいと思います。

目次

Oracle Cloud Observability and Management Platformの概要

オラクルの運用管理ソリューションご紹介(2021/02 版) from オラクルエンジニア通信

Database Managementの概要はSlide 28からです。

Exadata Cloud Service上のOracle Databaseを管理対象にしてみる

事前準備

事前準備の内容は、下記のドキュメントの"一般的な前提条件タスク"と"Oracle Cloudデータベース関連の前提条件タスク"を参考に。 docs.oracle.com やったことをざっとまとめると、

1. [OCIコンソール作業] 管理対象のデータベースの用意
2. [DB作業] 管理対象のデータベースのサービス名確認してメモ
3. [DB作業] データベース管理に必要な権限をデータベース・ユーザーに付与(今回はDBSNMPユーザーを使用)
4. [OCIコンソール作業] ユーザー・グループに権限を割り当てるポリシーの作成
5. [OCIコンソール作業] Oracle Cloud Infrastrucutre ボールトサービスでボールトを作成
6. [OCIコンソール作業] 作成したボールトのシークレットに、3で設定したデータベース・ユーザー・パスワードを保存
7. [OCIコンソール作業] データベース管理のプライベート・エンドポイントを作成
8. [OCIコンソール作業] データベース管理とデータベース間の通信の有効化

Exadata Cloud Service上のデータベースを登録

データベースをデータベース管理に登録する画面にいく方法としては、 1. データベース管理の画面から、管理対象データベースを登録 2. 管理対象のデータベースの詳細ページから、データベース管理機能を有効化 のいずれかで可能です。

1. データベース管理の画面から、管理対象データベースを登録する方法

データーベース管理の画面でデータベースを登録

データベース管理のページに行き、左側のメニューから「管理」＞「管理対象データベース」をクリックして、 「データベース管理の有効化」をクリック

2. 管理対象のデータベースの詳細ページから、データベース管理機能を有効

管理対象のデータベースの詳細ページから有効化

管理対象のデータベースの詳細ページの上部の「データベース情報」＞「関連付けられたサービス」＞「データベース管理」の「有効化」をクリックするか、 下部の「リソース」＞「メトリック」をクリックして、右側にでる「有効化」ボタンをクリック

データベース管理を有効化

有効化画面１

• データベースタイプ : 今回はExaCS上のデータベースを登録するので「ExaCS」
• VMクラスタの場所 : 対象のデータベースが稼働するVMクラスタ
• データベース・ホーム : 対象のデータベースが属するデータベース・ホーム
• データベース : 対象のデータベース
• サービス名 : 対象のデータベースに接続するためのサービス名

サービス名以外はプルダウンで選択できるのですが、サービス名だけは記述式なので、事前準備でメモしておいたものを記入します。

有効化画面２

• データベース・ユーザー名 : 事前準備で権限を付与したユーザー
• データベース・ユーザー・パスワード・シークレットの場所 : 事前準備で作成したシークレット
• プライベート・エンドポイントの場所 : 事前準備で作成したプライベート・エンドポイント
• 管理オプション : 今回は完全管理を選択します。

管理オプションの「完全管理」と「基本管理」の違いは、ざっくりいうと

基本管理

• 追加コストなし(無料)で利用可能
• CPU使用率やストレージ利用状況など14個の基本的なメトリック
• CDBのパフォーマンス・ハブのASH分析、SQL管理機能

完全管理

• 有償(詳細は最初の概要資料のSlide 15あたり)
• データベースの管理および管理
• オプション機能に含まれる、ADDMやブロック・セッションなどもみれるパフォーマンス・ハブや、SQL監視や表領域監視など
• データベースはどのエディションでも利用可能。Standard Editionに関してパフォーマンス・ハブは利用不可
• Exadata管理

今回は新機能のExadata管理がみたかったので完全管理にしています。

さて、無事に有効化されました

遭遇したエラー

「データベースの登録」をしようとした際に、下記エラーにて失敗しました

Operation failed because password secret is not accessible by Database Management

事前準備でポリシーに追加が必要な内容で不足があった模様。 下記の内容を追加

Allow group <group_name>  to manage secret-family in tenancy

Allow service dpd to read secret-family in tenancy 

Allow group <group_name>  to read secret-family in tenancy where target.vault.id = '{ボールトのocid}'

Database Managementの画面を確認

では、有効化されたのでデータベース管理の画面をいくつか見てみたいと思います

まずは、対象のデータベースの詳細ページでみれるメトリック。

メトリック

つぎにパフォーマンス・ハブをみたいので、データベースの詳細ページ上部の「パフォーマンス・ハブ」ボタンをクリック

ASH分析、SQLモニタリング、ADDM、ブロックしているセッション、Exadataとタブが並びます

SQLモニタリングで特定のSQLをクリックすると、リアルタイムSQLモニタリングも楽々

Exadata タブを見てみます Oracle管理レイヤーのフラッシュやディスク側も見れてますね。

今度は、データベース管理のページから。 複数データベースを管理していると便利なフリート・サマリーのページですが、時間がなくて今回は１つしかまだ登録していないので、「管理対象データベースの詳細」を。

サマリー、表領域、ユーザー、データベース・パラメータ(ここから編集可能)、クラスタ・キャッシュ・ジョブ、関連付けられたデータベース・グループ、SQLチューニングアドバイザのページがあります。

最後に

今回は、Oracle Cloud のデータベース管理機能でExadata Cloud Service 上のデータベースの管理を有効化してみました。 まずは有効化をしてみる、という内容にしたので、複数データベース、複数サービス(DBCSやAutonomous Database)を一元管理した場合や、ちゃんと処理をかけた状態でのモニタリングをしてみたいとおもいます。

Oracle Cloud Infrastructure Databaseのバックアップが失敗したら通知させる方法

この記事は「Oracle Cloud Infrastructure Advent Calendar 2019 - Adventar」の12月8日の記事として書かれています。 記事の内容は執筆時(2019/12/08)のものであり、現在とは異なる可能性がありますので適宜最新状況をご確認ください。

adventar.org

Oracle Cloud 上でPaaSとしてOracle Databaseを利用できるサービス、 Oracle Cloud Infrastructure - Database (通称 OCI DBCS。VM/BM/Exadataを含みます)だと、データベースのバックアップを自動で定期取得してくれるように設定をすることが可能です。また、Autonomous Database ではデフォルトで自動取得されます。

その機能を利用するにあたり、最近よく聞かれるのが

「バックアップ取得が失敗したら通知する方法ありますか？」

たしかに定期取得されるように設定しているバックアップが何らかの原因でとれていなくて、いざ必要な時に「バックアップがとれてなかったです！もどせません！」なんてことにはなりたくないですよね。

ということで、今回は「バックアップが失敗したら通知する」ように設定してみたいと思います。

1. 前提

今回の内容が利用可能な対象サービス

• Oracle Cloud Infrasctructure - Database (Virtual Machine / Bare Metal / Exadata)
• Oracle Autonomous Database (Autonomous Transaction Processing / Autonomous Data Warehouse)

→　今回は、OCI Database(OCI DBCS)のVirtual Machineを利用しました

利用する機能

• イベント
• 通知 (今回はメール通知を利用します)

マニュアル Oracle Cloud Infrastructure Documentation Events 英語 日本語 マニュアル Oracle Cloud Infrastructure Documentation Notifications 英語 / 日本語

やりたいこと

ある特定のイベントが発生したのを検知したら、設定したアクションを行う、ということを設定します。

具体的には、今回は下記の イベント(1)を検知したらアクション(2)を行うという定義を『イベント』機能で設定します。

1. ある特定のイベント = 自動バックアップを取得 + そのバックアップジョブが失敗 <--『イベント』で設定
2. 設定したアクション = メール通知 <--『通知』で設定

2. 設定方法

通知設定

あるイベントを検知したらメールが飛ぶように、まずは「通知」の設定を行います

・アプリケーション統合 > 通知

OCIのコンソールのメニューの [アプリケーション統合] > [通知]

・『トピックの作成』をクリックして、今回の設定のためのトピックを作成します。今回は、「eminamin-notification」という名前にしました。

トピックの作成

・作成されたトピックの名前をクリック

・通知の方法を設定するために、『サブスクリプションの作成』をクリック

トピックの詳細

・今回はメール通知にしたいので、プロトコルで『電子メール』を選択して、電子メール欄に通知する宛先のアドレスを入力し、『作成』

サブスクリプションの作成

作成したサブスクリプションを有効にするまで、ステータスはPENDINGになります。 メールアドレスが正しいかの確認ができると有効(ACTIVE)になるので、メールを確認しましょう。 先ほど実際に入力したメールアドレスが正しければ、メールが届いていると思います。そのメールの本文に記載のあるリンクをクリックすると

サブスクライブできたというページが開かれます。そして、コンソールにもどるとサブスクリプションのステータスがACTIVEになっているのが確認できました。 これで、通知の設定は完了です。

イベントの設定

ある特定のイベントが発生したのを検知したら、設定したアクションを行う、ということを『イベント』で設定します。

前述した通り、今回対象にするイベントの条件は『自動バックアップを取得』 + 『そのバックアップジョブが失敗』の２つです。

・アプリケーション統合 > イベント・サービス

OCIのコンソールのメニューの[アプリケーション統合]>[イベント・サービス]

・イベントの『ルールの作成』をクリック

ルールの作成

・ルール条件に２つの条件を作成します

条件1 : 自動バックアップを取得

• 『イベント・タイプ』 を選択
• サービス名 : 『Database』
• イベント・タイプ : 『Database - Create Backup End』

バックアップ取得ジョブのイベント・タイプには、『Database - Create Backup Begin』と『Database - Create Backup End』がありますが、ジョブの成功/失敗がわかるのはEndのイベントのため、『Database - Create Backup End』を選択します

条件2 : その(バックアップ)ジョブが失敗

• 『属性』 を選択
• 属性名 : 『lifecycleState』
• 属性 : 『FAILED』を入力

その他) 条件3 : 特定のデータベースのみを対象とする場合

様々なサービス・インスタンスが立ち上がっている環境で、すべてのDatabaseサービスのバックアップの通知がきたら困るので、対象のデータベースのみの通知を受けるために、下記に設定も付け加えています

• 属性』 を選択
• 属性名 : 『databaseId』
• 属性 : DatabaseのOCIDを入力

データベースのOCIDの情報

設定は以上！

3. 確認

バックアップが失敗したらメール通知がされるかどうか、早速試してみましょう。

・『バックアップの作成』を実行 事前にバックアップが失敗する設定にしておいたので、想定通り失敗します

・メールを確認 期待通り、メール通知がきてました！

バックアップが失敗した際のメール通知

あとは、通知を受け取ったら設定や環境の状態を確認して、きちんとバックアップが取れる状態に直します。 今のところ、バックアップが成功している時には来ていません。

通知内容をもう少しかっこよくさせたいなぁと思うので、それはまた今度。。

Oracle Databaseのサービス比較編 資料公開

2019/03/29(金)に、下記のイベントで講演した際の資料が公開されました。

Oracle Database Technology Night 日本データセンター開設前に知っておくべきこと -Oracle Databaseのサービス比較編

Oracle Technology Networkの連載の方でも書いているのですが、 Oracle Cloudが提供しているOracle Databaseのクラウドサービスにもいくつか種類があるので、 どれがどう違うのかをきかれることが多々あり、まとめてみました。

クラウド・サービスは日々進化しているので、公演日時点での内容として見ていただければ幸いです。