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の「プリファレンスの設定」で見ていきます。
メンテナンス・スケジューリング・ポリシーの作成
Exadata Infrastructure > 左のバーにある「スケジュール・ポリシー」を選択。「メンテナンス・スケジューリング・ポリシーの作成」をクリック
各項目を選択していきます。
ウィンドウ期間の強制
ここで注目したいのが、「期間(時間)」と「ウィンドウ期間の強制」です。「期間(時間)」はデフォルトでは平均のメンテナンス時間が入っているのですが、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
の内容を使って、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を利用して実行します。
ExaDB-Dでのexacliの実行方法は、前の記事で書いているのでご参考までに
・Task 1 １〜５は指示通りで実行できます。 ６で特定のgriddiskの詳細について参照する内容になっていますが、使用している環境のgriddiskの名前がわからない場合には先に確認する必要があるので、先に下記コマンドを実行して確認してください。
list griddisk
Lab 3 : Smart Scan
このLabから実際に機能を試す内容になりますが、スクリプトがどこにあるかリンク情報が見つからない・・・ ダンプファイルで案内されていたページから探っていったところ、下記に発見したので、ここのファイルをダウンロードして実行しました。
実際に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上からストレージ・サーバーの情報を確認することができます。
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.
その他、実行可能な操作に関してはマニュアルをご確認ください。
OCI ExaDB-DのOS上のDB/GIパッチを１ノードずつ適用する方法
この記事はOracle Cloud Infrastructure Advent Calendar 2023 Day21の記事として書いています。
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ホームへのパッチ適用になります
準備
・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の記事として書いています。
今年も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の概要
- Exadata Cloud Service上のOracle Databaseを管理対象にしてみる
- Database Managementの画面を確認
- 最後に
Oracle Cloud Observability and Management Platformの概要
Database Managementの概要はSlide 28からです。
Exadata Cloud Service上のOracle Databaseを管理対象にしてみる
事前準備
事前準備の内容は、下記のドキュメントの"一般的な前提条件タスク"と"Oracle Cloudデータベース関連の前提条件タスク"を参考に。 docs.oracle.com やったことをざっとまとめると、
- [OCIコンソール作業] 管理対象のデータベースの用意
- [DB作業] 管理対象のデータベースのサービス名確認してメモ
- [DB作業] データベース管理に必要な権限をデータベース・ユーザーに付与(今回はDBSNMPユーザーを使用)
- [OCIコンソール作業] ユーザー・グループに権限を割り当てるポリシーの作成
- [OCIコンソール作業] Oracle Cloud Infrastrucutre ボールトサービスでボールトを作成
- [OCIコンソール作業] 作成したボールトのシークレットに、3で設定したデータベース・ユーザー・パスワードを保存
- [OCIコンソール作業] データベース管理のプライベート・エンドポイントを作成
- [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)のものであり、現在とは異なる可能性がありますので適宜最新状況をご確認ください。
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)を行うという定義を『イベント』機能で設定します。
- ある特定のイベント = 自動バックアップを取得 + そのバックアップジョブが失敗 <--『イベント』で設定
- 設定したアクション = メール通知 <--『通知』で設定
2. 設定方法
通知設定
あるイベントを検知したらメールが飛ぶように、まずは「通知」の設定を行います
・アプリケーション統合 > 通知
・『トピックの作成』をクリックして、今回の設定のためのトピックを作成します。今回は、「eminamin-notification」という名前にしました。
・作成されたトピックの名前をクリック
・通知の方法を設定するために、『サブスクリプションの作成』をクリック
・今回はメール通知にしたいので、プロトコルで『電子メール』を選択して、電子メール欄に通知する宛先のアドレスを入力し、『作成』
作成したサブスクリプションを有効にするまで、ステータスはPENDINGになります。
メールアドレスが正しいかの確認ができると有効(ACTIVE)になるので、メールを確認しましょう。
先ほど実際に入力したメールアドレスが正しければ、メールが届いていると思います。そのメールの本文に記載のあるリンクをクリックすると
サブスクライブできたというページが開かれます。そして、コンソールにもどるとサブスクリプションのステータスがACTIVEになっているのが確認できました。
これで、通知の設定は完了です。
イベントの設定
ある特定のイベントが発生したのを検知したら、設定したアクションを行う、ということを『イベント』で設定します。
前述した通り、今回対象にするイベントの条件は『自動バックアップを取得』 + 『そのバックアップジョブが失敗』の２つです。
・アプリケーション統合 > イベント・サービス
・イベントの『ルールの作成』をクリック
・ルール条件に２つの条件を作成します
条件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を入力
設定は以上！
3. 確認
バックアップが失敗したらメール通知がされるかどうか、早速試してみましょう。
・『バックアップの作成』を実行
事前にバックアップが失敗する設定にしておいたので、想定通り失敗します
・メールを確認
期待通り、メール通知がきてました！
あとは、通知を受け取ったら設定や環境の状態を確認して、きちんとバックアップが取れる状態に直します。 今のところ、バックアップが成功している時には来ていません。
通知内容をもう少しかっこよくさせたいなぁと思うので、それはまた今度。。
Oracle Databaseのサービス比較編 資料公開
2019/03/29(金)に、下記のイベントで講演した際の資料が公開されました。
Oracle Database Technology Night 日本データセンター開設前に知っておくべきこと -Oracle Databaseのサービス比較編
Oracle Technology Networkの連載の方でも書いているのですが、 Oracle Cloudが提供しているOracle Databaseのクラウドサービスにもいくつか種類があるので、 どれがどう違うのかをきかれることが多々あり、まとめてみました。
クラウド・サービスは日々進化しているので、公演日時点での内容として見ていただければ幸いです。
