MySQL 8.0.35 で MySQL InnoDB Clusterを構築してみる。
この記事は、 MySQL Advent Calendar 2023 24日目の記事です。
23日目は @mita2 さんの記事 『MySQL Shell dumpInstance のロジック #2』でした。
はじめに
MySQLに入門が必要になったため、InnoDB Cluster の構築を実施してみようと思い、MySQL Advent Calendarに参加してみました。
ライトな内容ですが、書いてみます。
今まではOracle Databaseを扱うことが多かったです。
構築
環境
OSはOracleLinux8.8を利用しています。
| 役割 | ホスト名 | IP |
|---|---|---|
| DB1(primary) | mysql01 | 192.168.40.31 |
| DB2(secondary) | mysql02 | 192.168.40.32 |
| DB3(secondary) | mysql03 | 192.168.40.33 |
| mysqlsh/mysqlrouter | mysqlr | 192.168.40.34 |
手順
SmartStyleさんのTECHBLOGを参考に構築します。 blog.s-style.co.jp
基本的に同じコマンドで実行していますが、一部差し替えているため、コマンドを書き出していきます。
# 今回は検証なのでfirewalld無効化 (all servers)# systemctl disable --now firewalld # el8系に修正 (all servers)# dnf install -y https://dev.mysql.com/get/mysql80-community-release-el8-1.noarch.rpm # ol8_appstreamレポジトリのmysqlが優先されるので、無効化してmysql-community-serverをインストールする (db servers)# dnf install -y --disablerepo=ol8_appstream mysql-community-server # 後からクラスタステータスを取得する方法 (mysqlrouter/sh) # mysqlsh cluster = dba.getCluster() cluster.status() # mysqlrouterの自動起動有効化+起動 (mysqlrouter/sh) # systemctl enable --now mysqlrouter # ol8_appstreamレポジトリのmysqlが優先されるので、無効化してmysqlクライアントをインストールする (mysqlrouter/sh) # dnf install --disablerepo=ol8_appstream mysql
接続動作確認
mysqlrouter --bootstrapした際に以下が表示されたので、実際に動作確認してみます。
## MySQL Classic protocol - Read/Write Connections: localhost:6446 - Read/Only Connections: localhost:6447
ポート6446ではmysql01(primaryノード)のみに、ポート6447ではmysql02-03にラウンドロビンしていることが確認できました。
mysql -u root -p -h 192.168.40.34 -P 6446 -e "show variables like 'hostname';" [root@mysqlr ~]# mysql -u root -p -h 192.168.40.34 -P 6446 -e "show variables like 'hostname';" Enter password: +---------------+------------------+ | Variable_name | Value | +---------------+------------------+ | hostname | mysql01.snet.com | +---------------+------------------+ [root@mysqlr ~]# [root@mysqlr ~]# mysql -u root -p -h 192.168.40.34 -P 6447 -e "show variables like 'hostname';" Enter password: +---------------+------------------+ | Variable_name | Value | +---------------+------------------+ | hostname | mysql02.snet.com | +---------------+------------------+ [root@mysqlr ~]# mysql -u root -p -h 192.168.40.34 -P 6447 -e "show variables like 'hostname';" Enter password: +---------------+------------------+ | Variable_name | Value | +---------------+------------------+ | hostname | mysql03.snet.com | +---------------+------------------+
ログなど
- /var/log/mysqld.log
ここにクラスタ構築した際のログも一括で出力されているようです。
- /var/lib/mysql/
ここにDBファイルなどが配置されているようでした。
クラスタ再起動方法など
この記事が参考になるでしょうか。
MySQL系レプリケーション構成3種とインストール方法 #Linux - Qiita
ロールの切り替え方法など
オンラインで MySQL InnoDB Cluster の構成を変更する – スマートスタイル技術ブログ
まとめ
アーキテクチャが根本的に違いますが、OracleRACなんかと比べるとかなり簡単に構築できますね。
クラスタの全停止/起動などはMySQL Shellから実施できるため、比較的わかりやすいのかなと思いました。
もう少しさわりながら、MySQLについて知識を深めていければと思いました。
リフレッシュ可能なPDBをさわってみる
この記事は、 JPOUG Advent Calendar 2023 10日目の記事です。
9日目は 明治そして大正昭和平成令和 さんの記事『最新のSQL標準(SQL:2023)とFirebird/MySQL/PostgreSQL』でした。
はじめに
23cの新機能ベースでブログを記載したいと思い、ネタ探ししていました。
マルチテナント初心者なのでリフレッシュ可能なPDBに興味を持ったのでテーマにしてみました。
ただ、よくよく調べると12.2から使えるとのことがわかったので手元にあった19c環境で試していきます。
リフレッシュ可能なPDBができること
- スイッチオーバー
- 自動および手動リフレッシュ
初めはマテリアライズドビューのDB版なのかなと思っていました。
スイッチオーバーも使えるということで、リフレッシュ間隔を調整すればData Guardや基本スタンバイのようにDR用途にも使えるかもしれませんね。
結論
- 関連するマニュアルは複数読みましょう。
- その機能がどのライセンス形態で使えるか事前に確認しましょう。
- 作成するDBリンクはCDBを参照するようにしましょう。
さわってみる
環境
[oracle@db1901 ~]$ opatch lspatches 35643107;Database Release Update : 19.21.0.0.231017 (35643107) 29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)
構築
今回は検証のため1つのCDBにソースPDBとクローンPDBを作成します。
手順は以下を参考に進めます。手順上ソース、クローン側と書き分けますが、今回は一緒のDBで実施します。
ソース側
- アーカイブログであることを確認
SQL> archive log list データベース・ログ・モード アーカイブ・モード 自動アーカイブ 有効 アーカイブ先 /oradata/cdb19/arch 最も古いオンライン・ログ順序 23 アーカイブする次のログ順序 25 現行のログ順序 25
- ローカルUNDOモードであること
SQL> show parameter UNDO_MANAGEMENT NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ undo_management string AUTO
- Oracle Managed Filesが有効化であること(要件の中からこれを選択しました。)
SQL> show parameter DB_CREATE_FILE_DEST NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_create_file_dest string /oradata
- PDB作業用ユーザの作成
CREATE USER C##PDBUSER IDENTIFIED BY "P@ssw0rd"; GRANT CREATE SESSION TO C##PDBUSER CONTAINER=ALL; GRANT SET CONTAINER TO C##PDBUSER CONTAINER=ALL; GRANT CREATE PLUGGABLE DATABASE TO C##PDBUSER CONTAINER=ALL;
クローン側DB
- tnsnames.ora(DBリンク用)
PDB1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = db1901.lab.local)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = pdb1)
)
)
- PDB作業用ユーザの作成
※同じユーザ想定で進めます。
- DBリンク作成
CREATE PUBLIC DATABASE LINK PDB1_LINK CONNECT TO C##PDBUSER IDENTIFIED BY "P@ssw0rd" USING 'PDB1';
→このDBリンクでもうまくいくんですが、CDBを参照したDBリンクの方が良さそうです。
- リフレッシュ可能なPDB作成
conn C##PDBUSER/"P@ssw0rd" CREATE PLUGGABLE DATABASE pdb1_ref_cln FROM PDB1@PDB1_LINK REFRESH MODE EVERY 60 MINUTES; プラガブル・データベースが作成されました。
確認
- PDBの状態を確認してみます。
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB1 READ WRITE NO
4 PDB1_REF_CLN MOUNTED
SQL>
SQL> select PDB_NAME||','||REFRESH_MODE||','||REFRESH_INTERVAL||','||LAST_REFRESH_SCN from dba_pdbs where PDB_NAME='PDB1_REF_CLN';
PDB_NAME||','||REFRESH_MODE||','||REFRESH_INTERVAL||','||LAST_REFRESH_SCN
--------------------------------------------------------------------------------
PDB1_REF_CLN,AUTO,60,1648312
- alert logを確認してみます。
ジョブの実行エラーが出ていますが、PDB1_REF_CLNはMOUNT状態なので問題なしですかね。
2023-12-09T14:16:30.473206+09:00 CREATE PLUGGABLE DATABASE pdb1_ref_cln FROM PDB1@PDB1_LINK REFRESH MODE EVERY 60 MINUTES 2023-12-09T14:16:30.884217+09:00 PDB1(3): AUDSYS.AUD$UNIFIED (SQL_TEXT) - CLOB populated 2023-12-09T14:16:38.170158+09:00 **************************************************************** Pluggable Database PDB1_REF_CLN with pdb id - 4 is created as UNUSABLE. If any errors are encountered before the pdb is marked as NEW, then the pdb must be dropped local undo-1, localundoscn-0x000000000000012e **************************************************************** 2023-12-09T14:16:41.192727+09:00 Applying media recovery for pdb-3 from SCN 1648255 to SCN 1648312 Remote log information: count-1 thr-1,seq-26,logfile-/oradata/cdb19/arch/parlog_1_26_a880de4d_1154562853.arc,los-1643947,nxs-18446744073709551615,maxblks-34090 PDB1_REF_CLN(4):Media Recovery Start 2023-12-09T14:16:41.193534+09:00 PDB1_REF_CLN(4):Serial Media Recovery started PDB1_REF_CLN(4):max_pdb is 6 2023-12-09T14:16:41.240936+09:00 PDB1_REF_CLN(4):Media Recovery Log /oradata/cdb19/arch/parlog_1_26_a880de4d_1154562853.arc 2023-12-09T14:16:41.364009+09:00 PDB1_REF_CLN(4):Incomplete Recovery applied until change 1648312 time 12/09/2023 14:16:38 2023-12-09T14:16:41.366047+09:00 PDB1_REF_CLN(4):Media Recovery Complete (cdb19) Completed: CREATE PLUGGABLE DATABASE pdb1_ref_cln FROM PDB1@PDB1_LINK REFRESH MODE EVERY 60 MINUTES 2023-12-09T14:16:41.510849+09:00 Errors in file /u01/app/oracle/diag/rdbms/cdb19/cdb19/trace/cdb19_j000_23289.trc: ORA-12012: ジョブ"SYS"."PDB1_REF_CLN_595637595_REFRESH"の自動実行エラーが発生し ました ORA-65024: プラガブル・データベースPDB1_REF_CLNはオープンしていません。 ORA-06512: "SYS.DBMS_SQL", 行2995 ORA-06512: 行1
リフレッシュについて
事前にソースPDBでテストデータを作成します。
SQL> SQL> alter session set container = PDB1;
セッションが変更されました。
SQL>
SQL> show con_name;
CON_NAME
------------------------------
PDB1
SQL>
SQL> create table test (id number);
表が作成されました。
SQL> insert into test (id) values (1);
1行が作成されました。
SQL> insert into test (id) values (2);
1行が作成されました。
SQL>
SQL>
SQL> select * from test;
ID
----------
1
2
SQL>
SQL> commit;
コミットが完了しました。
- クローン側でテーブルが存在しないことを確認します。作業後はMOUNT状態に戻します。
SQL> ALTER PLUGGABLE DATABASE PDB1_REF_CLN OPEN READ ONLY;
プラガブル・データベースが変更されました。
SQL> ALTER SESSION SET CONTAINER = PDB1_REF_CLN;
セッションが変更されました。
SQL>
SQL> show con_name;
CON_NAME
------------------------------
PDB1_REF_CLN
SQL>
SQL> select * from test;
select * from test
*
行1でエラーが発生しました。:
ORA-00942: 表またはビューが存在しません。
SQL>
SQL> ALTER SESSION SET CONTAINER = CDB$ROOT;
セッションが変更されました。
SQL> ALTER PLUGGABLE DATABASE PDB1_REF_CLN CLOSE IMMEDIATE;
プラガブル・データベースが変更されました。
SQL>
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB1 READ WRITE NO
4 PDB1_REF_CLN MOUNTED
手動リフレッシュ
やってみます。
SQL> show con_name CON_NAME ------------------------------ CDB$ROOT SQL> SQL> ALTER PLUGGABLE DATABASE PDB1_REF_CLN REFRESH; プラガブル・データベースが変更されました。 SQL>
データも想定通り連携されていますね。
SQL> show con_name;
CON_NAME
------------------------------
PDB1_REF_CLN
SQL>
SQL> select PDB_NAME||','||REFRESH_MODE||','||REFRESH_INTERVAL||','||LAST_REFRESH_SCN from dba_pdbs where PDB_NAME='PDB1_REF_CLN';
PDB_NAME||','||REFRESH_MODE||','||REFRESH_INTERVAL||','||LAST_REFRESH_SCN
--------------------------------------------------------------------------------
PDB1_REF_CLN,AUTO,60,1651574
SQL>
SQL> select * from test;
ID
----------
1
2
SQL>
alertログではこんな感じで出力されます。
2023-12-09T15:15:28.617572+09:00 PDB1_REF_CLN(4):ALTER PLUGGABLE DATABASE PDB1_REF_CLN REFRESH 2023-12-09T15:15:30.293307+09:00 Applying media recovery for pdb-3 from SCN 1650756 to SCN 1651574 Remote log information: count-1 thr-1,seq-26,logfile-/oradata/cdb19/arch/parlog_1_26_a880de4d_1154562853.arc,los-1643947,nxs-18446744073709551615,maxblks-44422 PDB1_REF_CLN(4):Media Recovery Start 2023-12-09T15:15:30.294114+09:00 PDB1_REF_CLN(4):Serial Media Recovery started PDB1_REF_CLN(4):max_pdb is 6 2023-12-09T15:15:30.321190+09:00 PDB1_REF_CLN(4):Media Recovery Log /oradata/cdb19/arch/parlog_1_26_a880de4d_1154562853.arc 2023-12-09T15:15:30.418689+09:00 PDB1_REF_CLN(4):Incomplete Recovery applied until change 1651574 time 12/09/2023 15:15:28 2023-12-09T15:15:30.420904+09:00 PDB1_REF_CLN(4):Media Recovery Complete (cdb19) PDB1_REF_CLN(4):Completed: ALTER PLUGGABLE DATABASE PDB1_REF_CLN REFRESH
自動リフレッシュ
1時間ごとの更新が待てないので、間隔を短くしてみます。
SQL> ALTER PLUGGABLE DATABASE PDB1_REF_CLN REFRESH MODE EVERY 3 MINUTES; ★このタイミングで一度同期されていました。 プラガブル・データベースが変更されました。 SQL> SQL> ALTER SESSION SET CONTAINER = CDB$ROOT; セッションが変更されました。 SQL> select PDB_NAME||','||REFRESH_MODE||','||REFRESH_INTERVAL||','||LAST_REFRESH_SCN from dba_pdbs where PDB_NAME='PDB1_REF_CLN'; PDB_NAME||','||REFRESH_MODE||','||REFRESH_INTERVAL||','||LAST_REFRESH_SCN -------------------------------------------------------------------------------- PDB1_REF_CLN,AUTO,3,1674585
自動更新された場合もalertログとしては同じ内容です。
2023-12-09T21:16:34.824626+09:00 PDB1_REF_CLN(4):alter pluggable database refresh 2023-12-09T21:16:37.053287+09:00 Applying media recovery for pdb-3 from SCN 1674585 to SCN 1674706 Remote log information: count-1 thr-1,seq-26,logfile-/oradata/cdb19/arch/parlog_1_26_a880de4d_1154562853.arc,los-1643947,nxs-18446744073709551615,maxblks-150458 PDB1_REF_CLN(4):Media Recovery Start 2023-12-09T21:16:37.054244+09:00 PDB1_REF_CLN(4):Serial Media Recovery started PDB1_REF_CLN(4):max_pdb is 6 2023-12-09T21:16:37.091550+09:00 PDB1_REF_CLN(4):Media Recovery Log /oradata/cdb19/arch/parlog_1_26_a880de4d_1154562853.arc 2023-12-09T21:16:37.226036+09:00 PDB1_REF_CLN(4):Incomplete Recovery applied until change 1674706 time 12/09/2023 21:16:34 2023-12-09T21:16:37.228165+09:00 PDB1_REF_CLN(4):Media Recovery Complete (cdb19) PDB1_REF_CLN(4):Completed: alter pluggable database refresh
※リフレッシュが動いた時にREAD ONLYでOPENしていると失敗します。
2023-12-09T20:16:41.231298+09:00 PDB1_REF_CLN(4):alter pluggable database refresh 2023-12-09T20:16:41.231506+09:00 PDB1_REF_CLN(4):PDB1_REF_CLN(4):ERROR:PDB needs to be closed for auto refresh PDB1_REF_CLN(4):Completed: alter pluggable database refresh
スイッチオーバーについて
準備
スイッチオーバーの理解のためにドキュメントを読みます。
ALTER PLUGGABLE DATABASE - pdb_refresh_switchover_clause
ALTER PLUGGABLE DATABASE REFRESH MODE MANUAL FROM new_source_pdb@dblink SWITCHOVER;
以下がポイントですかね。
- スイッチオーバーはプライマリPDBから実行する
- DBリンクは、リフレッシュ可能なクローンPDBが現在存在するCDBのRootを指す必要がある。
- リフレッシュ可能なクローンが別のCDBに存在する場合、DBリンク・ユーザはプライマリPDBに存在しなければなりません。（今回は関係なし）
CDB$ROOTを指すDBリンクを作成します。後でマニュアル見て判明するんですが、追加で権限つけておきます。
CREATE PUBLIC DATABASE LINK CDB19_LINK CONNECT TO C##PDBUSER IDENTIFIED BY "P@ssw0rd" USING 'CDB19'; GRANT RESOURCE, CREATE ANY TABLE, UNLIMITED TABLESPACE TO C##PDBUSER CONTAINER=ALL; GRANT SYSOPER TO C##PDBUSER CONTAINER=ALL;
現状の状態を整理します。
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB1 READ WRITE NO
4 PDB1_REF_CLN MOUNTED
SQL>
SQL> select PDB_NAME||','||STATUS||','||REFRESH_MODE||','||REFRESH_INTERVAL||','||LAST_REFRESH_SCN from dba_pdbs;
PDB_NAME||','||STATUS||','||REFRESH_MODE||','||REFRESH_INTERVAL||','||LAST_REFRE
--------------------------------------------------------------------------------
PDB$SEED,NORMAL,NONE,,
PDB1,NORMAL,NONE,, ★ソースPDB
PDB1_REF_CLN,REFRESHING,AUTO,60,1675752 ★リフレッシュ可能なPDB
失うものはなにもないのでスイッチオーバーします。
SQL> conn C##PDBUSER/"P@ssw0rd" 接続されました。 SQL> SQL> ALTER SESSION SET CONTAINER = PDB1; セッションが変更されました。 SQL> SQL> ALTER PLUGGABLE DATABASE REFRESH MODE EVERY 60 MINUTES FROM PDB1_REF_CLN@CDB19_LINK SWITCHOVER; ALTER PLUGGABLE DATABASE REFRESH MODE EVERY 60 MINUTES FROM PDB1_REF_CLN@CDB19_LINK SWITCHOVER * 行1でエラーが発生しました。: ORA-12754: 機能PDB REFRESH SWITCHOVERは、機能がないため無効化されています。 SQL>
19cではEEだけだと、実施できずExadata,ODAから対象みたいです。
23cではFreeとOCIだけですね。
19c Database Licensing Information User Manual
23c Database Licensing Information User Manual
ここまで来て引けないので、ググって見つけたパラメータ"_exadata_feature_on"を設定して、動きを確認します。
... その後、どうしてもSWITCHOVERできず
以下のドキュメントを見つけました。
19c Switching Over a Refreshable Clone PDB
結論としては、クローンPDBを作成するときにPDBへのDBリンクを使っていましたが
CDBへ接続するDBリンクを指定してクローンPDBを作り直したところ何事もなくスイッチオーバーできました。
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB1 MOUNTED
5 PDB1_REF_CLN READ WRITE NO
SQL>
SQL> select PDB_NAME||','||STATUS||','||REFRESH_MODE||','||REFRESH_INTERVAL||','||LAST_REFRESH_SCN from dba_pdbs;
PDB_NAME||','||STATUS||','||REFRESH_MODE||','||REFRESH_INTERVAL||','||LAST_REFRE
--------------------------------------------------------------------------------
PDB$SEED,NORMAL,NONE,,
PDB1,REFRESHING,AUTO,60,1709559 ★リフレッシュ可能なPDB
PDB1_REF_CLN,NORMAL,NONE,, ★ソースPDB
alertログはこんな感じになりました。
2023-12-10T00:15:41.219246+09:00 PDB1(3):ALTER PLUGGABLE DATABASE REFRESH MODE EVERY 60 MINUTES FROM pdb1_ref_cln@CDB19_LINK SWITCHOVER 2023-12-10T00:15:41.446138+09:00 PDB1_REF_CLN(5): AUDSYS.AUD$UNIFIED (SQL_TEXT) - CLOB populated 2023-12-10T00:15:41.472027+09:00 PDB1(3):Pluggable database PDB1 closing PDB1(3):JIT: pid 24637 requesting stop 2023-12-10T00:15:41.478093+09:00 Process termination requested for pid 25659 [source = rdbms], [info = 2] [request issued by pid: 24637, uid: 54321] 2023-12-10T00:15:41.527373+09:00 KILL SESSION for sid=(146, 63746): Reason = PDB close immediate Mode = KILL HARD FORCE -/-/- Requestor = USER (orapid = 56, ospid = 24637, inst = 1) Owner = Process: Q005 (orapid = 69, ospid = 25659) Result = ORA-0 2023-12-10T00:15:42.613787+09:00 PDB1(3):Closing sequence subsystem (559893756181). PDB1(3):Buffer Cache flush started: 3 PDB1(3):Buffer Cache flush finished: 3 Pluggable database PDB1 closed 2023-12-10T00:15:43.123651+09:00 PDB1_REF_CLN(5):Pluggable database PDB1_REF_CLN closing PDB1_REF_CLN(5):JIT: pid 27376 requesting stop PDB1_REF_CLN(5):Buffer Cache flush started: 5 PDB1_REF_CLN(5):Buffer Cache flush finished: 5 Pluggable database PDB1_REF_CLN closed 2023-12-10T00:15:44.196342+09:00 Applying media recovery for pdb-3 from SCN 1708630 to SCN 1709099 Remote log information: count-1 thr-1,seq-26,logfile-/oradata/cdb19/arch/parlog_1_26_a880de4d_1154562853.arc,los-1643947,nxs-18446744073709551615,maxblks-329140 PDB1_REF_CLN(5):Media Recovery Start 2023-12-10T00:15:44.197164+09:00 PDB1_REF_CLN(5):Serial Media Recovery started PDB1_REF_CLN(5):max_pdb is 6 2023-12-10T00:15:44.231864+09:00 PDB1_REF_CLN(5):Media Recovery Log /oradata/cdb19/arch/parlog_1_26_a880de4d_1154562853.arc 2023-12-10T00:15:44.478151+09:00 PDB1_REF_CLN(5):Incomplete Recovery applied until change 1709099 time 12/10/2023 00:15:43 2023-12-10T00:15:44.482014+09:00 PDB1_REF_CLN(5):Media Recovery Complete (cdb19) PDB1_REF_CLN(5):Pluggable database PDB1_REF_CLN pseudo opening PDB1_REF_CLN(5):Undo initialization recovery: Parallel FPTR complete: start:559895739 end:559895741 diff:2 ms (0.0 seconds) PDB1_REF_CLN(5):Undo initialization recovery: err:0 start: 559895739 end: 559895741 diff: 2 ms (0.0 seconds) PDB1_REF_CLN(5):[27376] Successfully onlined Undo Tablespace 2. PDB1_REF_CLN(5):Undo initialization online undo segments: err:0 start: 559895741 end: 559895754 diff: 13 ms (0.0 seconds) PDB1_REF_CLN(5):Undo initialization finished serial:0 start:559895739 end:559895757 diff:18 ms (0.0 seconds) PDB1_REF_CLN(5):Database Characterset for PDB1_REF_CLN is AL32UTF8 PDB1_REF_CLN(5):Pluggable database PDB1_REF_CLN pseudo closing PDB1_REF_CLN(5):Closing sequence subsystem (559895870456). PDB1_REF_CLN(5):Buffer Cache flush started: 5 PDB1_REF_CLN(5):Buffer Cache flush finished: 5 2023-12-10T00:15:44.930512+09:00 Deleted Oracle managed file /oradata/CDB19/0C159397F492603DE0631528A8C00091/datafile/o1_mf_users_lq8zzfwt_.dbf Deleted Oracle managed file /oradata/CDB19/0C159397F492603DE0631528A8C00091/datafile/o1_mf_temp_lq8zzfws_.dbf Deleted Oracle managed file /oradata/CDB19/0C159397F492603DE0631528A8C00091/datafile/o1_mf_undotbs1_lq8zzfwr_.dbf Deleted Oracle managed file /oradata/CDB19/0C159397F492603DE0631528A8C00091/datafile/o1_mf_sysaux_lq8zzfwr_.dbf Deleted Oracle managed file /oradata/CDB19/0C159397F492603DE0631528A8C00091/datafile/o1_mf_system_lq8zzfwp_.dbf 2023-12-10T00:15:45.055963+09:00 PDB1_REF_CLN(5):Pluggable database PDB1_REF_CLN opening in read write PDB1_REF_CLN(5):Undo initialization recovery: Parallel FPTR complete: start:559896218 end:559896219 diff:1 ms (0.0 seconds) PDB1_REF_CLN(5):Undo initialization recovery: err:0 start: 559896218 end: 559896220 diff: 2 ms (0.0 seconds) PDB1_REF_CLN(5):[27376] Successfully onlined Undo Tablespace 2. PDB1_REF_CLN(5):Undo initialization online undo segments: err:0 start: 559896220 end: 559896261 diff: 41 ms (0.0 seconds) PDB1_REF_CLN(5):Undo initialization finished serial:0 start:559896218 end:559896264 diff:46 ms (0.0 seconds) PDB1_REF_CLN(5):Deleting old file#24 from file$ PDB1_REF_CLN(5):Deleting old file#25 from file$ PDB1_REF_CLN(5):Deleting old file#26 from file$ PDB1_REF_CLN(5):Deleting old file#27 from file$ PDB1_REF_CLN(5):Adding new file#28 to file$(old file#24). fopr-1, newblks-48640, oldblks-26880 PDB1_REF_CLN(5):Adding new file#29 to file$(old file#25). fopr-1, newblks-27520, oldblks-21120 PDB1_REF_CLN(5):Adding new file#30 to file$(old file#26). fopr-1, newblks-24320, oldblks-7680 PDB1_REF_CLN(5):Adding new file#31 to file$(old file#27). fopr-1, newblks-640, oldblks-640 2023-12-10T00:15:45.199604+09:00 PDB1_REF_CLN(5):Successfully created internal service PDB1_REF_CLN at open **************************************************************** Post plug operations are now complete. Pluggable database PDB1_REF_CLN with pdb id - 5 is now marked as NEW. **************************************************************** PDB1_REF_CLN(5):Database Characterset for PDB1_REF_CLN is AL32UTF8 PDB1_REF_CLN(5):SUPLOG: Set PDB SUPLOG SGA at PDB OPEN, old 0x0, new 0x0 (no suplog) PDB1_REF_CLN(5):Opening pdb with no Resource Manager plan active PDB1_REF_CLN(5):joxcsys_required_dirobj_exists: directory object exists with required path /u01/app/oracle/product/19.3.0/dbhome_1/javavm/admin/, pid 27376 cid 5 2023-12-10T00:15:46.051865+09:00 Pluggable database PDB1_REF_CLN opened read write 2023-12-10T00:15:46.179461+09:00 PDB1_REF_CLN(5): AUDSYS.AUD$UNIFIED (SQL_TEXT) - CLOB populated 2023-12-10T00:15:52.272969+09:00 PDB1(3):Endian type of dictionary set to little **************************************************************** Pluggable Database PDB1 with pdb id - 3 is created as UNUSABLE. If any errors are encountered before the pdb is marked as NEW, then the pdb must be dropped local undo-1, localundoscn-0x000000000000012e **************************************************************** 2023-12-10T00:15:54.935197+09:00 Applying media recovery for pdb-5 from SCN 1709449 to SCN 1709533 Remote log information: count-1 thr-1,seq-26,logfile-/oradata/cdb19/arch/parlog_1_26_39742b57_1154562853.arc,los-1643947,nxs-18446744073709551615,maxblks-329629 PDB1(3):Media Recovery Start 2023-12-10T00:15:54.936003+09:00 PDB1(3):Serial Media Recovery started PDB1(3):max_pdb is 6 2023-12-10T00:15:54.962876+09:00 PDB1(3):Media Recovery Log /oradata/cdb19/arch/parlog_1_26_39742b57_1154562853.arc 2023-12-10T00:15:55.259903+09:00 PDB1(3):Incomplete Recovery applied until change 1709533 time 12/10/2023 00:15:52 2023-12-10T00:15:55.262904+09:00 PDB1(3):Media Recovery Complete (cdb19) PDB1(3):Completed: ALTER PLUGGABLE DATABASE REFRESH MODE EVERY 60 MINUTES FROM pdb1_ref_cln@CDB19_LINK SWITCHOVER 2023-12-10T00:15:55.322476+09:00 PDB1(3):alter pluggable database refresh 2023-12-10T00:15:57.912705+09:00 Applying media recovery for pdb-5 from SCN 1709533 to SCN 1709559 Remote log information: count-1 thr-1,seq-26,logfile-/oradata/cdb19/arch/parlog_1_26_39742b57_1154562853.arc,los-1643947,nxs-18446744073709551615,maxblks-329658 PDB1(3):Media Recovery Start 2023-12-10T00:15:57.913543+09:00 PDB1(3):Serial Media Recovery started PDB1(3):max_pdb is 6 2023-12-10T00:15:57.959885+09:00 PDB1(3):Media Recovery Log /oradata/cdb19/arch/parlog_1_26_39742b57_1154562853.arc 2023-12-10T00:15:58.125490+09:00 PDB1(3):Incomplete Recovery applied until change 1709559 time 12/10/2023 00:15:55 2023-12-10T00:15:58.130780+09:00 PDB1(3):Media Recovery Complete (cdb19) PDB1(3):Completed: alter pluggable database refresh
まとめ
まだ製品との組み合わせなどで、19cで非CDBを扱う場面が多いのですが
便利な機能はたくさんあるので、23cへのDB移行も見据えて情報仕入れていきたいと感じました。
リンクまとめ
Oracle Databaseから定期情報取得するスクリプトについて
この記事は、 JPOUG Advent Calendar 2022 11日目の記事です。
10日目は wmo6hash さんの記事『Oracle Database Patch Maintenance '22 - wmo6hash::blog』でした。
はじめに
みなさん、スクリプトを使ってOracle Databaseの情報取得されていますか？
パフォーマンスをモニタリングできるツールがあったり、データベースのエディションがEnterprise Editionだとできることも違うかと思います。
このようなことが必要なときは得てして上記に一切当てはまらない環境かと思います。
私が過去にやって学んだことを紹介したいと思います。
※本ブログで公開したスクリプトを利用される際は、必ず十分な動作確認を行なってください。
本スクリプトを利用して不具合が発生した場合でも責任は追いかねます。
結論
スクリプトでsqlplusを用いて情報取得をする場合は以下をテンプレートとして使います。
1度の接続で、SQLを実行し続けるサンプルになります。
シェルスクリプト
- get-dbifo.sh
#/bin/sh LOGFILE="`date '+%Y%m%d_%H%M%S'`.log" ( echo 'connect / as sysdba' while true do echo "@v_session.sql ${LOGFILE}" sleep 60 done ) | sqlplus /nolog exit 0
- v_session.sql
set pages 0 lines 32000 trimo on trims on echo off term off feedback off spool &1 append select count(*) from v$session; spool off
PowerShell
PowerShell版はシェルの焼き直し版になります。
- get-dbifo.ps1
& { echo "conn / as sysdba" echo "set feedback off" for ($i=0; $i -lt 9999; $i++){ echo "@v_session.sql test.log" echo "exec DBMS_LOCK.SLEEP(60)" } } | sqlplus /nolog
v_session.sqlはshell版のものをそのまま使えます。
通常の情報取得だとなぜだめか
私がはじめに作ったのは以下のようなスクリプトでした。シンプルに毎回DBへ接続して情報取得するスクリプトですね。
手軽なスクリプトで作っているため、一般的なプログラミング言語でやるようなコネクションを作って、使い回すというものではありませんね。
- get-dbinfo.sh
#/bin/sh LOGFILE="dbinfo_`date '+%Y%m%d_%H%M%S'`.log" while true do sqlplus / as sysdba @v_session.sql ${LOGFILE} > /dev/null 2>&1 sleep 60 done
- v_session.sql
set pages 0 lines 32000 trimo on trims on echo off term off feedback off spool &1 append select count(*) from v$session; spool off exit
上記で何が問題あるかというと、負荷をかけないと再現しないような障害の調査をしなければいけないときです。
このようなときはデータベースの最大接続上限に張り付くような状態が考えられるため、そもそもDBへ接続できないため情報取得できないなんてことになります。
帰宅前にスクリプト仕掛けて翌朝ログを確認したら、実際に負荷のかかった深夜の情報が取れていなかったなんてとても悲しいですよね。
PowerShell版を作る上での課題など
ブログにする上で、shellだけではと思いPowerShell版を作りましたが、思ったようにうまくいきませんでした。
パイプラインの制限
他の方のブログ(*1)でも記載がありますが、shellでのパイプと動作が違うため以下の改良をしています。
- 無限ループをやめ、必要な分の有限ループにする。
無限ループにすると、スクリプトブロックでの出力が確定しないため、sqlplusでの処理がいつまで経っても始まりません。
- PowerShellのStart-Sleepコマンドレットの代わりにDBMS_LOCK.SLEEPを利用する。
スクリプトブロック内でのSleepはSleepの時間分、SQLの出力を遅くするだけで出力が終わるとSQLが一気に実行されて終わります。リソースの推移なんか見れません。
まとめ
情報収集などは、パフォーマンスをモニタリングできるツール/監視ツールなど行うことがほとんどかと思います。
いざ定期的に情報収集が必要になったら、ぜひお使いになってください。
クラウド(AWS/OCI/GCP/Azure)のサービス名を比較する
この記事はクラウドごとに微妙に違うリソース名を自分用に少しずつまとめていきます。
現状はAWS/Oracle Cloud(OCI)/GCP/Azureをベースにまとめます。
最終更新日2022/1/10
※勉強しながらのため間違っている可能性があります、引用される際は自己責任でお願いいたします。間違いがありましたらご指摘ください。
比較
コンピュートサービス
| 種別 | AWS | OCI | GCP | Azure |
|---|---|---|---|---|
| VM | Amazon EC2 | Compute | Compute Engine | Azure Virtual Machines |
| 容量予約 | Reserved Instance(RI) | Capacity Reservation | 確約利用割引 | Azure Reserved Virtual Machine Instances |
ネットワークサービス
| 種別 | AWS | OCI | GCP | Azure |
|---|---|---|---|---|
| AZ/ゾーン | アベイラビリティゾーン (AZ) | アベイラビリティドメイン (AD) | ゾーン | アベイラビリティゾーン (AZ) |
| ネットワーク | Amazon Virtual Private Cloud (VPC) | 仮想クラウド・ネットワーク (VCN) | Virtual Private Cloud (VPC) | Azure Virtual Network (VNet) |
| 通信許可(サブネット) | ネットワークACL | セキュリティ・リスト | ファイアウォール | ネットワーク セキュリティ グループ(NSG) |
| 通信許可(VM) | セキュリティ・グループ | ネットワーク・セキュリティ・グループ | ファイアウォール | ネットワーク セキュリティ グループ(NSG) |
| ロードバランサー(L7) | ELB - Application Load Balancer | ロード・バランサ | HTTP(S)負荷分散 | Application Gateway |
| ロードバランサー(L4) | ELB - Network Load Balancer | ネットワーク・ロード・バランサ | TCP/UDP負荷分散 | Azure Application Load Balancer |
| ロードバランサー(その他) | ELB - Gateway Load Balancer | - | SSLプロキシとTCPプロキシ負荷分散 | Traffic Manager |
| DNS | Amazon Route 53 | DNS管理 | Cloud DNS | Azure DNS |
| CDN | Amazon CloudFront | - | Cloud CDN | Azure CDN |
| VPN | AWS Site-to-Site VPN | サイト間VPN | Cloud VPN | サイト間VPN接続 |
| 専用線 | AWS Direct Connect | FastConnect | Cloud Interconnect | Azure ExpressRoute |
ストレージサービス
| 種別 | AWS | OCI | GCP | Azure |
|---|---|---|---|---|
| オブジェクト | Amazon Simple Storage Service (Amazon S3) | オブジェクトストレージ アーカイブストレージ |
Cloud Storage | Azure Blob Storage |
| ブロック | Amazon Elastic Block Store (Amazon EBS) | Block Volume Local NVMe |
Persistent Disk Local SSD |
Azure Disk Storage |
データベースサービス
| 種別 | AWS | OCI | GCP | Azure |
|---|---|---|---|---|
| リレーショナル | Amazon RDS | Autonomous Database MySQL |
Cloud SQL Cloud Spanner |
Azure SQL Database Azure Database for MySQL/PostgreSQL |
| DWH | Amazon Redshift | Autonomous Data Warehouse MySQL(Heatwave) |
BigQuery | Azure Synapse Analytics |
| NoSQL(ドキュメント) | Amazon DynamoDB Amazon DocumentDB(MongoDB 互換) |
Oracle NoSQL Database | Firestore | Azure Cosmos DB |
| NoSQL(列指向) | Amazon Redshift(DHW) | Oracle NoSQL Database | Cloud Bigtable | Azure Cosmos DB |
| NoSQL(インメモリ Key-Value) | Amazon ElastiCache Amazon MemoryDB for Redis Amazon DynamoDB |
Oracle NoSQL Database | MemoryStore(Redis/Memcached) | Azure Cache for Redis Azure Cosmos DB? |
| NoSQL(分散) | Amazon Keyspaces(Apache Cassandra 互換) | DataStax | Azure Cosmos DB | |
| NoSQL(グラフ) | Amazon Neptune | Azure Cosmos DB | ||
| 時系列 | Amazon Timestream |
データ分析
| 種別 | AWS | OCI | GCP | Azure |
|---|---|---|---|---|
| Apache Spark/Hadoop | AWS EMR | DataProc | Azure HDInsight |
サーバーレスサービス
| 種別 | AWS | OCI | GCP | Azure |
|---|---|---|---|---|
| ファンクション | AWS Lambda | Functions | Cloud Functions | Azure Functions |
| アプリケーション | App Engine | App Service? |
コンテナサービス
| 種別 | AWS | OCI | GCP | Azure |
|---|---|---|---|---|
| マネージド | Amazon Elastic Kubernetes Service Amazon Elastic Container Service |
Kubernetesクラスタ(OKE) | Google Kubernetes Engine | Azure Kubernetes Service(AKS) |
| フルマネージド | AWS Fargate | Cloud Run | Azure Container Instances (ACI) |
ML/AIサービス
| 種別 | AWS | OCI | GCP | Azure |
|---|---|---|---|---|
| ML | Amazon Machine Learning | 機械学習 | Vertex AI | Azure Machine Learning |
管理サービス
| 種別 | AWS | OCI | GCP | Azure |
|---|---|---|---|---|
| イベント | Amazon EventBridge | イベント・サービス | Eventarc | Event Grid |
| 監査 | AWS CloudTrail | 監査 | Stackdriver Logging | アクティビティ ログ |
| キーマネジメント | AWS Key Management Service | Vault | Cloud Key Management Service | Key Vault |
リンク集
Oracle Clusterware用のREST APIを使ってみる
この記事は、 JPOUG Advent Calendar 2021 11日目の記事です。
10日目は Kenichi Mihara さんの記事『日本の電子政府はなぜイマイチなのか | サイクル＆オラクル』でした。
はじめに
REST APIはなんとなく知っているが実際には使ったことはない状態でした。
21cのClusterwareで使えるようになったことで、次のLTSバージョンに向けて一度使ってみようと重い腰を上げてみました。
Clusterware管理およびデプロイメント・ガイドからOracle Clusterware用のREST APIをベースにやっていきます。
こちらの内容は2021/12時点で以下の環境で実行したものとなります。
環境
Oracle Grid Infrastructure 21c(21.0.0.0.0)
忙しい人向けサマリ
- REST APIにアクセスするユーザのパスワードは
/u01/app/21.0.0/grid/bin/cdpc configで確認できる。 CDPのログはgridのalertログと同じディレクトリ
/u01/app/grid/diag/crs/db2101/crs/trace/crscdpd_*.trc
外部からのアクセスは自セグメント(今回は/24)はデフォルトで許可されている。多分ホストのサブネットマスクで/24部分は変わりそう。
- ファイルが出力されるジョブは、ジョブステータスがCompletedになってからダウンロードする。
- REST APIのジョブはjobExpiryで削除される。
- Gridに関係ないコマンドは実行できない。
初期設定関連
初期パスワードの確認
初めから横道に逸れます。引越しの荷造り中にマンガ読んでしまって進まない系のやつです。
マニュアルの始まりはadminユーザのパスワード変更から始まっており、初期パスワードをどうしても確認したくなりました。
gridのalert.log
MySQL？みたいにパスワードがログに出力されていないかなと思い、gridのalert.logをおもむろにgrep -i cdpをしてみます。
[grid@db2101 ~]$ cd $ORACLE_BASE/diag/crs/db2101/crs/trace/ [grid@db2101 trace]$ grep -i cdp alert.log [grid@db2101 trace]$
はずれでした。
gridインストールログ
ならばということで、次を見ていきます。インストールログはインベントリ/u01/app/oraInventory/logs/の下になりますね。
[grid@db2101 ~]$ cd /u01/app/oraInventory/logs/GridSetupActions2021-09-24_00-51-40AM
[grid@db2101 GridSetupActions2021-09-24_00-51-40AM]$
[grid@db2101 GridSetupActions2021-09-24_00-51-40AM]$ grep -i cdp gridSetupActions2021-09-24_00-51-40AM.out
・・・(略)・・・
[pool-1-thread-1] [ 2021-09-24 01:05:37.141 JST ] [FDOwnershipPermissionsConstraintsParser.processLine:299] Skipping - OS OR Context applicability flag is false for path [${CONFIGURED_CRS_HOME}/crs/install/oracdp.pm] with constraints [FIXABLE]
途中にも怪しいファイルはありましたが、一番下にそれっぽいPerlファイルがあるので見てみます。
[grid@db2101 ~]$ cd /u01/app/21.0.0/grid/crs/install
[grid@db2101 install]$ view oracdp.pm
・・・(略)・・・
868 my $CDPC_BIN = catfile ($CFG->ORA_CRS_HOME, "bin", "cdpc");
869 my $CRSCDPD_BIN = catfile ($CFG->ORA_CRS_HOME, "bin", "crscdpd");
870
871 # Fetch current passwords
872 @runcmd = ("$CDPC_BIN", "config");
873 $status = run_as_user2($crsusr, \@output, @runcmd);
874 if (0 != $status)
875 {
876 print_trace_lines(@output);
877 return FAILED;
878 }
879
880 foreach my $line (@output)
881 {
882 if ($line =~ m/ admin:(.+) wallet/)
883 {
884 $apass = $1;
885 }
842行目付近からmodifyCDPという関数があります。871行目でFetch current passwordsとあるため、前後の処理を見て何となく実行すべきコマンドがわかった気がします。
[grid@db2101 ~]$ cd /u01/app/21.0.0/grid/bin [grid@db2101 bin]$ ./cdpc config Resource 'ora.cdp' has 3 cred members [0] admin:<xxxxxxxxxx> wallet 4885 wpass FALSE url https://scan21:5700/grid/cdp/v1/cdp fqdn scan21 entity id ora.cdp cluster id 650c3bacf1645fa9ff5d80db17ca133a [1] readonly:<xxxxxxxxxx> wallet 4885 wpass FALSE url https://scan21:5700/grid/cdp/v1/cdp fqdn scan21 entity id ora.cdp cluster id 650c3bacf1645fa9ff5d80db17ca133a [2] events:<xxxxxxxxxx> wallet 4885 wpass FALSE url https://scan21:5700/grid/cdp/v1/cdp fqdn scan21 entity id ora.cdp cluster id 650c3bacf1645fa9ff5d80db17ca133a [grid@db2101 bin]$
環境毎にパスワードは違うと思いますが、念のためマスクしました。上記の通りしっかりパスワードが見えました。
答え合わせということでマニュアルにある例J-1 すべてのホームのリストの取得を実行してみます。
[grid@db2101 ~]$ curl -k -X GET https://scan21.snet.com:5700/grid/cmd/v1/cmd/ \ > --user 'admin:<xxxxxxxxxx>' | jq % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1078 100 1078 0 0 5417 0 --:--:-- --:--:-- --:--:-- 5417 { "name": "cmd", "homes": [ { "homeName": "OraGI21Home1", "path": "/u01/app/21.0.0/grid" }, { "homeName": "OraDB21Home1", "path": "/u01/app/oracle/product/21.0.0/dbhome_1" }, ・・・(略)・・・
結果はjsonで返ってくるため、見やすくするためjqコマンドへパイプしました。
パスワードにバッククォートが含まれていたため、シングルクォートで囲っています。
同じくreadonlyユーザも、実行可能でした。
eventsユーザはエラーにはなりませんがレスポンスが返ってきませんでした。パスワード変更自体出来ないため、特別なユーザなんだと思います。
パスワード変更
gridユーザでは権限がなく実行できないため、rootユーザで実行します。
[root@db2101 ~]$ /u01/app/21.0.0/grid/bin/srvctl stop cdp [root@db2101 ~]$ echo 'myAdminPasswd' > /tmp/adminpasswd [root@db2101 ~]# /u01/app/21.0.0/grid/bin/srvctl modify cdp -passfile_admin /tmp /adminpasswd [root@db2101 ~]# echo $? 0 [root@db2101 ~]# /u01/app/21.0.0/grid/bin/srvctl start cdp
再度gridユーザでパスワード確認/u01/app/21.0.0/grid/bin/cdpc configを実行するとadminユーザのパスワードが変わったことを確認できました。
CDPログの確認
grid alertログのディレクトリでgrep -i cdp *をしました。
cdpごとにファイルがあり、世代管理されているようです。アクセスされたAPIなど確認できました。
[root@db2101 ~]# cd /u01/app/grid/diag/crs/db2101/crs/trace [root@db2101 trace]# ls Display all 2515 possibilities? (y or n) [root@db2101 trace]# ll crscdpd* -rw-rw---- 1 grid oinstall 3994759 12月 5 13:21 crscdpd_1.trc -rw-rw---- 1 grid oinstall 531105 12月 5 13:21 crscdpd_1.trm -rw-rw---- 1 grid oinstall 26215016 11月 28 20:17 crscdpd_1_1.trc -rw-rw---- 1 grid oinstall 3502971 11月 28 20:17 crscdpd_1_1.trm -rw-rw---- 1 grid oinstall 26215042 12月 4 15:47 crscdpd_1_2.trc -rw-rw---- 1 grid oinstall 3583867 12月 4 15:47 crscdpd_1_2.trm -rw-rw---- 1 grid oinstall 3873257 12月 5 13:21 crscdpd_2.trc -rw-rw---- 1 grid oinstall 515200 12月 5 13:21 crscdpd_2.trm -rw-rw---- 1 grid oinstall 26215265 11月 28 20:44 crscdpd_2_1.trc -rw-rw---- 1 grid oinstall 3492527 11月 28 20:44 crscdpd_2_1.trm -rw-rw---- 1 grid oinstall 26214967 12月 4 16:21 crscdpd_2_2.trc -rw-rw---- 1 grid oinstall 3577549 12月 4 16:21 crscdpd_2_2.trm -rw-rw---- 1 grid oinstall 379406 12月 4 15:21 crscdpd_3.trc -rw-rw---- 1 grid oinstall 80512 12月 4 15:21 crscdpd_3.trm
クラスタ外部からの接続許可について
まずは初期状態を確認します。
[grid@db2101 ~]$ srvctl config cdp ------------------------------------------------------- CDP名 ポート 許可されるIP ------------------------------------------------------- ora.cdp1.cdp 5700 ora.cdp2.cdp 5700 ora.cdp3.cdp 5700
接続許可 gridユーザではエラーとなるため、rootユーザで実行します。
[root@db2101 bin]# /u01/app/21.0.0/grid/bin/srvctl modify cdp -allow "172.16.2.19/32" [root@db2101 bin]# /u01/app/21.0.0/grid/bin/srvctl config cdp ------------------------------------------------------- CDP名 ポート 許可されるIP ------------------------------------------------------- ora.cdp1.cdp 5700 172.16.2.19/32 ora.cdp2.cdp 5700 172.16.2.19/32 ora.cdp3.cdp 5700 172.16.2.19/32
設定時のログ
2021-12-05 14:13:49.081 : CLSWS:140394522236672: clsws_cli_event: got allowips event 172.16.2.19/32 2021-12-05 14:13:49.081 : CLSWS:140394520135424: clsws_cli_allow_thr: Subnet Mask IP 172.16.2.0/255.255.255.0 converted to CIDR 172.16.2.0/24 2021-12-05 14:13:49.081 : CLSWS:140394520135424: clsws_cli_allow_thr: allowed ip from attr: '172.16.2.0/24' 2021-12-05 14:13:49.081 : CLSWS:140394520135424: clsws_cli_allow_thr: allowed ip from attr: '172.16.2.19/32' 2021-12-05 14:13:53.238 : CLSWS:140394515932928: clsws_cli_status_thr: loop counter 0 cur_len 0
ログを見ていると、広い172.16.2.0/24でも許可されていることが確認できます。172.16.2.19は今回のOracleRACと同じセグメント(172.16.2.0/24)になります。
マニュアルには以下のように書かれていますが、現状はクラスタと同セグ/24は許可リストに初めから入っているようです。
デフォルトでREST APIを安全にするために、クラスタ内のノードのIPアドレス以外からのすべてのリクエストが拒否されます。CDPデーモンはクラスタ内のノードを監視し、IPのいずれとも一致しないCLIエンドポイントへのリクエストをすべて拒否します。
試しに/u01/app/21.0.0/grid/bin/srvctl modify cdp -allow ""のように空で実行するとやはり、クラスタと同セグ/24は許可リストのようです。
2021-12-05 14:17:58.378 : CLSWS:140394522236672: clsws_cli_event: got allowips event 2021-12-05 14:17:58.378 : CLSWS:140394520135424: clsws_cli_allow_thr: Subnet Mask IP 172.16.2.0/255.255.255.0 converted to CIDR 172.16.2.0/24 2021-12-05 14:17:58.378 : CLSWS:140394520135424: clsws_cli_allow_thr: allowed ip from attr: '172.16.2.0/24'
実は許可設定前に、アクセスできないねっていうログを取りたかったのですが、接続できてしまいログを読んだところこのような結末でした。
REST APIを使ってみる
前置きは長くなりましたが、マニュアルを見ながら進めていきます。
ジョブ実行
レスポンスもjsonなので、jqで見やすくしています。
これはマニュアルの例J-2 ジョブの作成(crsctl)およびステータスの監視になります。
[root@dev01 ~]# curl -k -X POST \ > https://172.16.2.57:5700/grid/cmd/v1/cmd/exec \ > '-H "accept: text/plain,text/javascript,application/json"' \ > '-H "content-type: application/vnd.oracle.resource+json;type=singular"' \ > --user admin:myAdminPasswd \ > '-d {"command" : ["crsctl", "stat", "res", "-t"], "runAsUser":"grid", "userPassword":"grid"}' | jq % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 680 100 590 100 90 129 19 0:00:04 0:00:04 --:--:-- 134 { "runAsUser": "grid", "jobId": "oPSnBD_T0hJk7pMo7vswEsry4LKM4zmFFdMBTMl0xQlAG5-jMr3UwAcU_tsZWlL4shtB8ibgEG9LtM9EXmD2uw", "command": [ "crsctl", "stat", "res", "-t" ], "nodeName": "db2101", "jobExpiry": 3600, "status": "Scheduled", "links": [ { "rel": "canonical", "href": "https://172.16.2.57:5700/grid/cmd/v1/cmd/jobs/oPSnBD_T0hJk7pMo7vswEsry4LKM4zmFFdMBTMl0xQlAG5-jMr3UwAcU_tsZWlL4shtB8ibgEG9LtM9EXmD2uw", "mediaType": "application/vnd.oracle.resource+json;type=singular" }, { "rel": "parent", "href": "https://172.16.2.57:5700/grid/cmd/v1/cmd/jobs", "mediaType": "application/vnd.oracle.resource+json;type=collection" } ] }
コマンドの実行結果が1行で出力されるので、どうするか考えたいですね。
何となくjobIdは数値で連番みたいな想像を勝手にしていたので、若干面を食らいました。
[root@dev01 ~]# curl -k -X GET https://172.16.2.57:5700/grid/cmd/v1/cmd/jobs/oPSnBD_T0hJk7pMo7vswEsry4LKM4zmFFdMBTMl0xQlAG5-jMr3UwAcU_tsZWlL4shtB8ibgEG9LtM9EXmD2uw --user admin:myAdminPasswd | jq % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 5595 100 5595 0 0 20825 0 --:--:-- --:--:-- --:--:-- 20799 { "runAsUser": "grid", "jobId": "oPSnBD_T0hJk7pMo7vswEsry4LKM4zmFFdMBTMl0xQlAG5-jMr3UwAcU_tsZWlL4shtB8ibgEG9LtM9EXmD2uw", "command": [ "crsctl", "stat", "res", "-t" ], "nodeName": "db2101", "output": "--------------------------------------------------------------------------------\nName Target State Server State details \n--------------------------------------------------------------------------------\nLocal Resources\n--------------------------------------------------------------------------------\nora.LISTENER.lsnr\n ONLINE ONLINE db2101 STABLE\n ONLINE ONLINE db2102 STABLE\nora.chad\n ONLINE ONLINE db2101 STABLE\n ONLINE ONLINE db2102 STABLE\nora.helper\n OFFLINE OFFLINE db2101 IDLE,STABLE\n OFFLINE OFFLINE db2102 IDLE,STABLE\nora.net1.network\n ONLINE ONLINE db2101 STABLE\n ONLINE ONLINE db2102 STABLE\nora.ons\n ONLINE ONLINE db2101 STABLE\n ONLINE ONLINE db2102 STABLE\n--------------------------------------------------------------------------------\nCluster Resources\n--------------------------------------------------------------------------------\nora.ASMNET1LSNR_ASM.lsnr(ora.asmgroup)\n 1 ONLINE ONLINE db2101 STABLE\n 2 ONLINE ONLINE db2102 STABLE\nora.ASMNET2LSNR_ASM.lsnr(ora.asmgroup)\n 1 ONLINE ONLINE db2101 STABLE\n 2 ONLINE ONLINE db2102 STABLE\nora.DATA.dg(ora.asmgroup)\n 1 ONLINE ONLINE db2101 STABLE\n 2 ONLINE ONLINE db2102 STABLE\nora.LISTENER_SCAN1.lsnr\n 1 ONLINE ONLINE db2101 STABLE\nora.LISTENER_SCAN2.lsnr\n 1 ONLINE ONLINE db2101 STABLE\nora.LISTENER_SCAN3.lsnr\n 1 ONLINE ONLINE db2102 STABLE\nora.MGMT.dg(ora.asmgroup)\n 1 ONLINE ONLINE db2101 STABLE\n 2 ONLINE ONLINE db2102 STABLE\nora.MGMTLSNR\n 1 ONLINE ONLINE db2101 169.254.8.36 10.10.1\n .1 10.10.2.1,STABLE\nora.OCR.dg(ora.asmgroup)\n 1 ONLINE ONLINE db2101 STABLE\n 2 ONLINE ONLINE db2102 STABLE\nora.asm(ora.asmgroup)\n 1 ONLINE ONLINE db2101 Started,STABLE\n 2 ONLINE ONLINE db2102 Started,STABLE\nora.asmnet1.asmnetwork(ora.asmgroup)\n 1 ONLINE ONLINE db2101 STABLE\n 2 ONLINE ONLINE db2102 STABLE\nora.asmnet2.asmnetwork(ora.asmgroup)\n 1 ONLINE ONLINE db2101 STABLE\n 2 ONLINE ONLINE db2102 STABLE\nora.cdp1.cdp\n 1 ONLINE ONLINE db2101 STABLE\nora.cdp2.cdp\n 1 ONLINE ONLINE db2101 STABLE\nora.cdp3.cdp\n 1 ONLINE ONLINE db2102 STABLE\nora.cvu\n 1 ONLINE ONLINE db2101 STABLE\nora.db2101.vip\n 1 ONLINE ONLINE db2101 STABLE\nora.db2102.vip\n 1 ONLINE ONLINE db2102 STABLE\nora.mgmtdb\n 1 ONLINE ONLINE db2101 Open,STABLE\nora.orcl.db\n 1 ONLINE ONLINE db2101 Open,HOME=/u01/app/o\n racle/product/21.0.0\n /dbhome_1,STABLE\n 2 ONLINE ONLINE db2102 Open,HOME=/u01/app/o\n racle/product/21.0.0\n /dbhome_1,STABLE\nora.orcl.orclpdb1.pdb\n 1 ONLINE ONLINE db2101 STABLE\n 2 ONLINE ONLINE db2102 STABLE\nora.qosmserver\n 1 ONLINE ONLINE db2101 STABLE\nora.rhpserver\n 1 OFFLINE OFFLINE STABLE\nora.scan1.vip\n 1 ONLINE ONLINE db2101 STABLE\nora.scan2.vip\n 1 ONLINE ONLINE db2101 STABLE\nora.scan3.vip\n 1 ONLINE ONLINE db2102 STABLE\n--------------------------------------------------------------------------------\n", "processId": 829488, "processStatus": 0, "timeStart": "2021-12-05T08:03:46", "timeFinish": "2021-12-05T08:03:47", "jobExpiry": 3600, "status": "Completed", "links": [ { "rel": "canonical", "href": "https://172.16.2.57:5700/grid/cmd/v1/cmd/jobs/oPSnBD_T0hJk7pMo7vswEsry4LKM4zmFFdMBTMl0xQlAG5-jMr3UwAcU_tsZWlL4shtB8ibgEG9LtM9EXmD2uw", "mediaType": "application/vnd.oracle.resource+json;type=singular" }, { "rel": "parent", "href": "https://172.16.2.57:5700/grid/cmd/v1/cmd/jobs", "mediaType": "application/vnd.oracle.resource+json;type=collection" } ] }
CVUジョブ出力ファイルの取得
cluvfy comp healthcheckコマンドは実行に時間がかかるため、ジョブステータスがCompletedになったのを確認してからダウンロードしましょう。
CDPログを1つだけ見るようにしたいためIP指定にしています。
またそれに伴い証明書の警告がでたため--no-check-certificateをつけています。
[root@dev01 ~]# wget --user admin --password myAdminPasswd https://172.16.2.57:5700/grid/cmd/v1/cmd/jobs/C_GzD1MMhg0h4U9DmKUElRXmcUsYVio6Mq3tPcTEG2sQn-nKWcj9rOACAuU7dlDbzagdhZrdt-bxts7ci79yIQ/outputFile --no-check-certificate --2021-12-05 16:07:40-- https://172.16.2.57:5700/grid/cmd/v1/cmd/jobs/C_GzD1MMhg0h4U9DmKUElRXmcUsYVio6Mq3tPcTEG2sQn-nKWcj9rOACAuU7dlDbzagdhZrdt-bxts7ci79yIQ/outputFile Connecting to 172.16.2.57:5700... connected. WARNING: cannot verify 172.16.2.57's certificate, issued by ‘/O=Oracle_Clusterware/CN=650c3bacf1645fa9ff5d80db17ca133a_1632413658’: Self-signed certificate encountered. WARNING: certificate common name ‘scan21’ doesn't match requested host name ‘172.16.2.57’. HTTP request sent, awaiting response... 401 Unauthorized Reusing existing connection to 172.16.2.57:5700. HTTP request sent, awaiting response... No data received. Retrying. --2021-12-05 16:07:41-- (try: 2) https://172.16.2.57:5700/grid/cmd/v1/cmd/jobs/C_GzD1MMhg0h4U9DmKUElRXmcUsYVio6Mq3tPcTEG2sQn-nKWcj9rOACAuU7dlDbzagdhZrdt-bxts7ci79yIQ/outputFile Connecting to 172.16.2.57:5700... connected. WARNING: cannot verify 172.16.2.57's certificate, issued by ‘/O=Oracle_Clusterware/CN=650c3bacf1645fa9ff5d80db17ca133a_1632413658’: Self-signed certificate encountered. WARNING: certificate common name ‘scan21’ doesn't match requested host name ‘172.16.2.57’. HTTP request sent, awaiting response... 200 OK Length: 187724 (183K) [application/file] Saving to: ‘outputFile’ 100%[===============================================================>] 187,724 --.-K/s in 0.004s 2021-12-05 16:07:41 (42.6 MB/s) - ‘outputFile’ saved [187724/187724]
また、ジョブのステータスチェックをした際に、jsonの中にoutputFileNameというキーがありました。
valueにファイル名があったため、find検索したところ/u01/app/grid/crsdata/db2101/clswscliに一時ファイルが保存されているようでした。
ジョブの削除と削除確認
ここはあまり、特筆する点がありません。
ジョブのステータスを確認するとjobExpiryという項目があり3600と設定があります。1時間でジョブが削除されているようでした。
例J-4 ステータスの監視、ジョブ出力の取得およびCVUジョブ出力ファイルの取得では、"jobExpiry":300としており、実際に実行すると300で設定されていました。
すべてのジョブステータスを表示する。
将来の自分のために、サンプルとして例J-5 すべてのジョブのステータスの監視の出力例を残します。
[root@dev01 ~]# curl -k -X GET https://172.16.2.57:5700/grid/cmd/v1/cmd/jobs/ --user 'admin:myAdminPasswd' | jq % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1800 100 1800 0 0 1432 0 0:00:01 0:00:01 --:--:-- 1433 { "items": [ { "runAsUser": "grid", "jobId": "C_GzD1MMhg0h4U9DmKUElRXmcUsYVio6Mq3tPcTEG2sQn-nKWcj9rOACAuU7dlDbzagdhZrdt-bxts7ci79yIQ", "command": [ "cluvfy", "comp", "healthcheck" ], "nodeName": "db2101", "output": "STATUS=OPERATION_FAILED\nREPORT=/grid/cmd/v1/cmd/jobs/C_GzD1MMhg0h4U9DmKUElRXmcUsYVio6Mq3tPcTEG2sQn-nKWcj9rOACAuU7dlDbzagdhZrdt-bxts7ci79yIQ/outputFile\n", "outputFile": [ { "rel": "canonical", "href": "https://172.16.2.57:5700/grid/cmd/v1/cmd/jobs/jobs/C_GzD1MMhg0h4U9DmKUElRXmcUsYVio6Mq3tPcTEG2sQn-nKWcj9rOACAuU7dlDbzagdhZrdt-bxts7ci79yIQ", "mediaType": "application/file" }, { "rel": "parent", "href": "https://172.16.2.57:5700/grid/cmd/v1/cmd/jobs/jobs/C_GzD1MMhg0h4U9DmKUElRXmcUsYVio6Mq3tPcTEG2sQn-nKWcj9rOACAuU7dlDbzagdhZrdt-bxts7ci79yIQ/outputFile", "mediaType": "application/vnd.oracle.resource+json;type=singular" } ], "outputFileName": "C_GzD1MMhg0h4U9DmKUElRXmcUsYVio6Mq3tPcTEG2sQn-nKWcj9rOACAuU7dlDbzagdhZrdt-bxts7ci79yIQ_outputfile.txt", "preferredFileName": "cvureport_2021-12-05_15-32-16.txt", "processId": 776738, "processStatus": 0, "timeStart": "2021-12-05T06:32:16", "timeFinish": "2021-12-05T06:36:27", "jobExpiry": 3600, "status": "Completed", "links": [ { "rel": "canonical", "href": "https://172.16.2.57:5700/grid/cmd/v1/cmd/jobs/jobs/C_GzD1MMhg0h4U9DmKUElRXmcUsYVio6Mq3tPcTEG2sQn-nKWcj9rOACAuU7dlDbzagdhZrdt-bxts7ci79yIQ", "mediaType": "application/vnd.oracle.resource+json;type=singular" }, { "rel": "parent", "href": "https://172.16.2.57:5700/grid/cmd/v1/cmd/jobs/jobs", "mediaType": "application/vnd.oracle.resource+json;type=collection" } ] }, { "runAsUser": "grid", "jobId": "QRktJp4Q8648q8C8hbwnjUEqAY1VmYMiX-D8SsaznwPfYy8XOih2_sxgwxpnZpFytpH_IbZDi-1GAUf4KsWfbg", "command": [ "srvctl", "config", "cdp" ], "nodeName": "db2101", "output": "-------------------------------------------------------\nCDP Name port allowed ips\n-------------------------------------------------------\nora.cdp1.cdp 5700 \nora.cdp2.cdp 5700 \nora.cdp3.cdp 5700 \n", "processId": 828657, "processStatus": 0, "timeStart": "2021-12-05T08:01:48", "timeFinish": "2021-12-05T08:01:49", "jobExpiry": 3600, "status": "Completed", "links": [ { "rel": "canonical", "href": "https://172.16.2.57:5700/grid/cmd/v1/cmd/jobs/jobs/QRktJp4Q8648q8C8hbwnjUEqAY1VmYMiX-D8SsaznwPfYy8XOih2_sxgwxpnZpFytpH_IbZDi-1GAUf4KsWfbg", "mediaType": "application/vnd.oracle.resource+json;type=singular" }, { "rel": "parent", "href": "https://172.16.2.57:5700/grid/cmd/v1/cmd/jobs/jobs", "mediaType": "application/vnd.oracle.resource+json;type=collection" } ] } ], "links": [ { "rel": "canonical", "href": "https://172.16.2.57:5700/grid/cmd/v1/cmd/jobs", "mediaType": "application/vnd.oracle.resource+json;type=collection" }, { "rel": "parent", "href": "https://172.16.2.57:5700/grid/cmd/v1/cmd", "mediaType": "application/vnd.oracle.resource+json;type=singular" } ] }
自作コマンドのジョブを実行できるのか
ふと思い、ファイルを用意して実行してみました。
[root@db2101 ~]# ll /tmp/get_os_info.sh -rwxr--r-- 1 root root 300 12月 5 16:19 /tmp/get_os_info.sh [root@db2101 ~]# [root@db2101 ~]# cat /tmp/get_os_info.sh #!/bin/bash ip a | grep inet df -hT exit 0
おもむろに実行してみます。
[root@dev01 ~]# curl -k -X POST \
> https://172.16.2.57:5700/grid/cmd/v1/cmd/exec \
> '-H "accept: text/plain,text/javascript,application/json"' \
> '-H "content-type: application/vnd.oracle.resource+json;type=singular"' \
> --user admin:myAdminPasswd \
> '-d {"command" : ["sh", "/tmp/get_os_info.sh"], "runAsUser":"root", "userPassword":"P@ssw0rd"}'
[root@dev01 ~]#
レスポンスが返ってこないし、ジョブ一覧にも表示されない。
ログをみるとinvalid exec requestと言われ実行できないようです。
若干期待しましたが、ですよねという感じです。
2021-12-05 16:31:21.803 : CLSWS:140394539046656: clswsd_wl_check_auth returns 1 2021-12-05 16:31:21.803 : CLSWS:140394539046656: calling clsws_cli_exec for uri /grid/cmd/v1/cmd/exec qs <null> op POST 2021-12-05 16:31:21.803 : CLSWS:140394539046656: clsws_cli_job_parse: Invalid CLI passed sh 2021-12-05 16:31:21.803 : CLSWS:140394539046656: clsws_cli_exec: invalid exec request 2021-12-05 16:31:21.803 : CLSWS:140394539046656: Result 400 BAD_REQ for uri /grid/cmd/v1/cmd/exec op POST 2021-12-05 16:31:21.804 : CLSWS:140394528540416: Closing connection w/conndata 0x7fb008037380
まとめ
細かいところは押さえられていませんが、大枠について知ることができた感じがします。
実施前まで少し心配でしたが、思いのほか簡単に実行できました。
今後のために何かに使えるか考えてみようと思います。
今になってorachkなど実行できるか試してみたくなったので、追って実施しようと思います。
テーブル・インデックスサイズ見積もり（PostgreSQL）
はじめに
OSS-DB Gold対策シリーズです。 サンプル問題を解いてまとめます。 https://oss-db.jp/measures/sample
今回は運用管理からテーブル・インデックスサイズの見積もりをまとめました。
テーブルサイズ見積もり
https://oss-db.jp/sample/gold_management_01/01_120210
見積もり対象のテーブル定義
CREATE TABLE registration ( id BIGINT PRIMARY KEY, reg_event INTEGER NOT NULL, reg_client INTEGER NOT NULL, reg_date TIMESTAMP NOT NULL );
50万行レコード作成した場合のテーブルサイズは？ ブロックサイズは8192byteとし、インデックスサイズは含めないものとする。
①１行あたりのサイズを求めます。 28 + 8 + 4 + 4 + 8 = 52 (byte)
②１ブロックに入る行数を求めます。 (8192 - 24) / 52 = 157 (行) ※ブロックに入るサイズなので小数点以下は切り捨て
③必要なブロック数を求めます。 500,000 / 157 = 3185 (ブロック) ※ブロック数なので小数点以下は切り上げ
④テーブルサイズを求めます。 8192 * 3185 = 26091520 ≒ 25MB
インデックスサイズ見積もり
https://oss-db.jp/sample/gold_management_01/04_130401
見積もり対象のインデックス定義
CREATE INDEX member_index ON member_table (team_id, birthday);
100万行レコード作成した場合のテーブルサイズは？ team_id:INTEGER、birthday:DATEでどちらもNOT NULL制約あり ブロックサイズは8192byteとし、FILLFACTORは90%とする。
①１ブロックあたり使用できすサイズを求めます。 8192 * 0.9 = 7372 (byte)
②１つのリーフページに格納できる行数を求めます。 (7372 - 24 - 16) / (4 + 8 + 4 + 4) = 7332 / 20 ≒ 366 ※ブロックに入るサイズなので小数点以下は切り捨て
②必要なリーフページ数を求めます。 1,000,000 / 366 ≒ 2733 (ページ) ※ブロックに入るサイズなので小数点以下は切り上げ
③ルートおよびインターナルページの必要数を求めます。 ルートページから参照できるページ数 366ページ 2733 / 366 ≒ 8 (インターナルページ数)
④必要なサイズを求める (2733 + 8 + 1) * 8192 = 22462464 ≒ 22MB
データ型ごとのサイズ一覧(抜粋)
https://www.postgresql.jp/document/11/html/datatype.html
数値データ型
| 型名 | サイズ |
|---|---|
| smallint | 2byte |
| integer | 4byte |
| bigint | 8byte |
| decimal | 可変長 |
| numeric | 可変長 |
| real | 4byte |
| double precision | 8byte |
| smallsirial | 2byte |
| serial | 4byte |
| bigserial | 8byte |
日付/時刻データ型
| 型名 | サイズ |
|---|---|
| timestamp [(p)] [without time zone] | 8byte |
| timestamp [(p)] [with time zone] | 8byte |
| date | 4byte |
| time [(p)] [without time zone] | 8byte |
| time [(p)] [with time zone] | 12byte |
| interval [ fields] [(p)] | 16byte |
Oracle RACのSCAN IPを2つで設定してみる
はじめに
今までSCAN IPは1つか3つで設定してきました。
マニュアルにはSCAN IPは3つが推奨と書いてありますが、DBノードが2つだったらSCAN IP(LISTENER)も2つで設定すれば無駄がない？
試したことがなかったので、すでにあるSCAN 3つの環境を2つヘ変更するベースで手順を確認しました。
これができるなら、インストール時も問題ないはず。
結論
SCAN IPを2つでも設定できる。
環境
手順
事前確認
まずは、設定を確認していきます。
- SCAN IP
[root@ron1901 ~]# /u01/app/19.0.0/grid/bin/srvctl config scan SCAN name: ronscan19, Network: 1 Subnet IPv4: 172.16.2.0/255.255.255.0/ens192, static Subnet IPv6: SCAN 1 IPv4 VIP: 172.16.2.37 SCAN VIP is enabled. SCAN 2 IPv4 VIP: 172.16.2.35 SCAN VIP is enabled. SCAN 3 IPv4 VIP: 172.16.2.36 SCAN VIP is enabled.
- SCAN_LISTENER config
[root@ron1901 ~]# /u01/app/19.0.0/grid/bin/srvctl config scan_listener SCAN Listeners for network 1: Registration invited nodes: Registration invited subnets: Endpoints: TCP:1521 SCAN Listener LISTENER_SCAN1 exists SCAN Listener is enabled. SCAN Listener LISTENER_SCAN2 exists SCAN Listener is enabled. SCAN Listener LISTENER_SCAN3 exists SCAN Listener is enabled.
- SCAN_LISTENER status
[grid@ron1901 ~]$ lsnrctl status LISTENER_SCAN2 LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 12-DEC-2020 17:26:17 Copyright (c) 1991, 2020, Oracle. All rights reserved. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN2))) STATUS of the LISTENER ------------------------ Alias LISTENER_SCAN2 Version TNSLSNR for Linux: Version 19.0.0.0.0 - Production Start Date 12-DEC-2020 16:09:55 Uptime 0 days 1 hr. 16 min. 21 sec Trace Level off Security ON: Local OS Authentication SNMP OFF Listener Parameter File /u01/app/19.0.0/grid/network/admin/listener.ora Listener Log File /u01/app/grid/diag/tnslsnr/ron1901/listener_scan2/alert/log.xml Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER_SCAN2))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=172.16.2.35)(PORT=1521))) Services Summary... Service "-MGMTDBXDB" has 1 instance(s). Instance "-MGMTDB", status READY, has 1 handler(s) for this service... Service "86b638145ff27a6fe053f706e80a81f1" has 1 instance(s). Instance "-MGMTDB", status READY, has 1 handler(s) for this service... Service "RON" has 1 instance(s). Instance "RON_1", status READY, has 1 handler(s) for this service... Service "RONXDB" has 1 instance(s). Instance "RON_1", status READY, has 1 handler(s) for this service... Service "SVRON" has 1 instance(s). Instance "RON_1", status READY, has 1 handler(s) for this service... Service "_mgmtdb" has 1 instance(s). Instance "-MGMTDB", status READY, has 1 handler(s) for this service... Service "b3373e9486742742e0531f0210ac53a7" has 1 instance(s). Instance "-MGMTDB", status READY, has 1 handler(s) for this service... Service "gimr_dscrep_10" has 1 instance(s). Instance "-MGMTDB", status READY, has 1 handler(s) for this service... The command completed successfully
- SCANリソース
[root@ron1901 ~]# /u01/app/19.0.0/grid/bin/crsctl stat res ora.scan1.vip ora.scan2.vip ora.scan3.vip ora.LISTENER_SCAN1.lsnr ora.LISTENER_SCAN2.lsnr ora.LISTENER_SCAN3.lsnr -t
--------------------------------------------------------------------------------
Name Target State Server State details
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
1 ONLINE ONLINE ron1902 STABLE
ora.LISTENER_SCAN2.lsnr
1 ONLINE ONLINE ron1901 STABLE
ora.LISTENER_SCAN3.lsnr
1 ONLINE ONLINE ron1901 STABLE
ora.scan1.vip
1 ONLINE ONLINE ron1902 STABLE
ora.scan2.vip
1 ONLINE ONLINE ron1901 STABLE
ora.scan3.vip
1 ONLINE ONLINE ron1901 STABLE
--------------------------------------------------------------------------------
- DBのリスナー設定
[oracle@ron1901 ~]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Sat Dec 12 17:47:16 2020
Version 19.8.0.0.0
Copyright (c) 1982, 2020, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.8.0.0.0
SQL>
SQL> show parameter listener
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
forward_listener string
listener_networks string
local_listener string (ADDRESS=(PROTOCOL=TCP)(HOST=
172.16.2.33)(PORT=1521))
remote_listener string ronscan19:1521
SQL>
SCAN IP(SCAN名)の変更
- 現在はronscan19を使っていますが、2つのIPでラウンドロビンされるtestscanへ変更してみます。
[root@ron1901 ~]# nslookup ronscan19 Server: 172.16.2.17 Address: 172.16.2.17#53 Name: ronscan19.lab.local Address: 172.16.2.35 Name: ronscan19.lab.local Address: 172.16.2.36 Name: ronscan19.lab.local Address: 172.16.2.37 [root@ron1901 ~]# [root@ron1901 ~]# nslookup testscan Server: 172.16.2.17 Address: 172.16.2.17#53 Name: testscan.lab.local Address: 172.16.2.50 Name: testscan.lab.local Address: 172.16.2.51
本番環境ではないのでアグレッシブに変更します。
[root@ron1901 ~]# /u01/app/19.0.0/grid/bin/srvctl modify scan -scanname testscan [root@ron1901 ~]#
先ほど確認した内容を一通り確認していきます。
- SCAN IP
[root@ron1901 ~]# /u01/app/19.0.0/grid/bin/srvctl config scan SCAN name: testscan, Network: 1 Subnet IPv4: 172.16.2.0/255.255.255.0/ens192, static Subnet IPv6: SCAN 1 IPv4 VIP: 172.16.2.51 SCAN VIP is enabled. SCAN 2 IPv4 VIP: 172.16.2.50 SCAN VIP is enabled.
- SCAN_LISTENER config
[root@ron1901 ~]# /u01/app/19.0.0/grid/bin/srvctl config scan_listener SCAN Listeners for network 1: Registration invited nodes: Registration invited subnets: Endpoints: TCP:1521 SCAN Listener LISTENER_SCAN1 exists SCAN Listener is enabled. SCAN Listener LISTENER_SCAN2 exists SCAN Listener is enabled.
- SCAN_LISTENER status
[grid@ron1901 ~]$ lsnrctl status LISTENER_SCAN2 LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 12-DEC-2020 18:13:27 Copyright (c) 1991, 2020, Oracle. All rights reserved. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN2))) STATUS of the LISTENER ------------------------ Alias LISTENER_SCAN2 Version TNSLSNR for Linux: Version 19.0.0.0.0 - Production Start Date 12-DEC-2020 16:09:55 Uptime 0 days 2 hr. 3 min. 32 sec Trace Level off Security ON: Local OS Authentication SNMP OFF Listener Parameter File /u01/app/19.0.0/grid/network/admin/listener.ora Listener Log File /u01/app/grid/diag/tnslsnr/ron1901/listener_scan2/alert/log.xml Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER_SCAN2))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=172.16.2.50)(PORT=1521))) Services Summary... Service "-MGMTDBXDB" has 1 instance(s). Instance "-MGMTDB", status READY, has 1 handler(s) for this service... Service "86b638145ff27a6fe053f706e80a81f1" has 1 instance(s). Instance "-MGMTDB", status READY, has 1 handler(s) for this service... Service "RON" has 1 instance(s). Instance "RON_1", status READY, has 1 handler(s) for this service... Service "RONXDB" has 1 instance(s). Instance "RON_1", status READY, has 1 handler(s) for this service... Service "SVRON" has 1 instance(s). Instance "RON_1", status READY, has 1 handler(s) for this service... Service "_mgmtdb" has 1 instance(s). Instance "-MGMTDB", status READY, has 1 handler(s) for this service... Service "b3373e9486742742e0531f0210ac53a7" has 1 instance(s). Instance "-MGMTDB", status READY, has 1 handler(s) for this service... Service "gimr_dscrep_10" has 1 instance(s). Instance "-MGMTDB", status READY, has 1 handler(s) for this service... The command completed successfully [grid@ron1901 ~]$
- SCAN リソース
[root@ron1901 ~]# /u01/app/19.0.0/grid/bin/crsctl stat res ora.scan1.vip ora.scan2.vip ora.scan3.vip ora.LISTENER_SCAN1.lsnr ora.LISTENER_SCAN2.lsnr ora.LISTENER_SCAN3.lsnr -t
CRS-2613: Could not find resource 'ora.scan3.vip'.
CRS-2613: Could not find resource 'ora.LISTENER_SCAN3.lsnr'.
--------------------------------------------------------------------------------
Name Target State Server State details
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
1 ONLINE ONLINE ron1902 STABLE
ora.LISTENER_SCAN2.lsnr
1 ONLINE ONLINE ron1901 STABLE
ora.scan1.vip
1 ONLINE ONLINE ron1902 STABLE
ora.scan2.vip
1 ONLINE ONLINE ron1901 STABLE
--------------------------------------------------------------------------------
- DBのリスナー設定
[oracle@ron1901 ~]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Sat Dec 12 18:20:31 2020
Version 19.8.0.0.0
Copyright (c) 1982, 2020, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.8.0.0.0
SQL> show parameter listener
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
forward_listener string
listener_networks string
local_listener string (ADDRESS=(PROTOCOL=TCP)(HOST=
172.16.2.33)(PORT=1521))
remote_listener string testscan:1521
SQL>
リソースの調整と初期化パラメータremote_listenerまで書き換えてくれていました。
databaseのalert logには、以下が出力されていました。
[oracle@ron1901 oracle]$ cd $ORACLE_BASE/diag/rdbms/ron/RON_1/trace [oracle@ron1901 trace]$ tailf alert_RON_1.log 2020-12-12T18:06:44.251412+09:00 ALTER SYSTEM SET remote_listener=' ronscan19:1521','testscan:1521' SCOPE=MEMORY SID='RON_1'; 2020-12-12T18:06:44.257388+09:00 ALTER SYSTEM SET listener_networks='' SCOPE=MEMORY SID='RON_1'; 2020-12-12T18:06:46.344161+09:00 ALTER SYSTEM SET remote_listener=' ronscan19:1521','testscan:1521' SCOPE=MEMORY SID='RON_1'; 2020-12-12T18:06:46.347674+09:00 ALTER SYSTEM SET listener_networks='' SCOPE=MEMORY SID='RON_1'; 2020-12-12T18:06:48.572550+09:00 ALTER SYSTEM SET remote_listener=' testscan:1521' SCOPE=MEMORY SID='RON_1'; 2020-12-12T18:06:48.575824+09:00 ALTER SYSTEM SET listener_networks='' SCOPE=MEMORY SID='RON_1'; 2020-12-12T18:06:50.970607+09:00 ALTER SYSTEM SET remote_listener=' testscan:1521' SCOPE=MEMORY SID='RON_1'; 2020-12-12T18:06:50.974416+09:00 ALTER SYSTEM SET listener_networks='' SCOPE=MEMORY SID='RON_1'; 2020-12-12T18:06:56.254759+09:00 ALTER SYSTEM SET remote_listener=' testscan:1521' SCOPE=MEMORY SID='RON_1'; 2020-12-12T18:06:56.257965+09:00 ALTER SYSTEM SET listener_networks='' SCOPE=MEMORY SID='RON_1';
