- Oracle Database
- Oracle Cloud
Autonomous Database 23ai 新機能！Select AIでSQLやデータを自動生成！
Oracle Database 23aiでは生成AIに関連する新機能が多く追加。特にAutonomous Database 23aiの「Select AI」機能は大規模言語モデル（LLM）を使用して、自然言語による問い合わせやテストデータの自動生成が可能に。本記事では、Select AIの機能について検証結果を交えて紹介します。
|
|
Oracle Databaseの誇るクラスタリング機能Oracle Real Application Clusters（以降、RAC）は、Oracle Database 10gよりエディションを問わず（Standard Edition Oneを除く）導入可能なこともあり、これまで多くのユーザーに利用されてきました。Oracle Database 19c以降はStandard Edition2（以降、SE2）でのRACのサポートが終了したため、SE2向けの新たな高可用性ソリューションとしてStandard Edition High Availability（以降、SEHA）が発表されました。
当記事ではSEHAの可用性に関する検証結果を報告します。
SEHAは、Oracle Database 19c Release Update 19.7から提供されるSE2向けの高可用性ソリューションです。
オラクルエンジニア通信
Standard Edition High Availabilityを提供開始
SEHAは、Oracle Clusterware、Oracle自動ストレージ管理(Oracle ASM)、Oracle ASMクラスタファイルシステム(Oracle ACFS)など、Oracle Grid Infrastructure(GI)の一部であるクラスタ機能とストレージソリューションを活用しているため、Third Party製のクラスタウェアなどを利用したHA構成のシステムと比較し、Oracle Database と親和性の高いクラスタソリューションです。
例えば、クラスタの待機ノードでもASMインスタンスが稼働しており、共有ディスクのASMディスクグループが常にマウントされているため、フェイルオーバー発生時には待機ノードでのインスタンスリカバリのみでデータベースが再開できるなど、フェイルオーバー時間をThird Party製クラスタウェアよりも大きく短縮することができます。
|
|
また、フェイルオーバーだけではなく、リロケートも可能なため、計画的なシステムメンテナンス時のサービス継続も実現します。
■フェイルオーバーのイメージ ■リロケートのイメージ
|
|
|
※注意※
可用性構成を採用する場合、必要となるOracleライセンスにご注意ください。
参考情報：Oracleデータ・リカバリ・ポリシー
ライセンスに関する詳細は以下よりお問い合わせください。
Oracle Databaseのライセンスのご相談
実際にSEHAのフェイルオーバーやリロケートの動作を検証してみましょう。
今回使用したシステムは下記の構成です。
OS：Oracle Linux 7.8 64bit
ホスト名：fence01.ashisuto.co.jp（ノード1）
fence02.ashisuto.co.jp（ノード2）
GI/DB：Release Update 19.7.0.0.0
データベース名：orcl（CDB）
orcl_pdb（PDB）
--クラスタの構成情報
[grid@fence01 ~]$ srvctl config all
Oracle Clusterware configuration details
========================================
Oracle Clusterware basic information
------------------------------------
Operating system Linux
Name fence-cluster
Class STANDALONE
Cluster nodes fence02, fence01
Version 19.0.0.0.0
Groups SYSOPER:asmoper SYSASM:asmadmin SYSRAC:asmadmin
SYSDBA:asmdba
OCR locations +DATA
Voting disk DATA
locations
Voting disk file /dev/sda1
paths
Cluster network configuration details
-------------------------------------
Interface name Type Subnet Classification
ens192 IPV4 192.168.176.0/24 PUBLIC
ens224 IPV4 10.0.1.0/24 PRIVATE, ASM
ens256 IPV4 10.0.2.0/24 PRIVATE
SCAN configuration details
--------------------------
SCAN "fence-scan" details
+++++++++++++++++++++++++
Name fence-scan
IPv4 subnet 192.168.176.0/24
DHCP server type static
End points TCP:1521
SCAN listeners
--------------
Name VIP address
LISTENER_SCAN1 192.168.176.59
ASM configuration details
-------------------------
Mode remote
Password file +DATA
SPFILE +DATA
ASM disk group details
++++++++++++++++++++++
Name Redundancy
DATA EXTERN
RECO EXTERN
Database configuration details
==============================
Database "ora.orcl.db" details
------------------------------
Name ora.orcl.db
Type SINGLE
Version 19.0.0.0.0
Role PRIMARY
Management AUTOMATIC
policy
SPFILE +DATA
Password file +DATA
Groups OSDBA:dba OSOPER:oper OSBACKUP:backupdba OSDG:dgdba OSKM:kmdba
OSRAC:racdba
Oracle home /u01/app/oracle/product/19.0.0/dbhome_1
--データベースの構成 [oracle@fence01 ~]$ srvctl config database -db orcl -all 一意のデータベース名: orcl データベース名: orcl Oracleホーム: /u01/app/oracle/product/19.0.0/dbhome_1 Oracleユーザー: oracle spfile: +DATA/ORCL/PARAMETERFILE/spfile.302.1042334205 パスワード・ファイル: +DATA/ORCL/PASSWORD/pwdorcl.311.1042872735 ドメイン: ashisuto.co.jp 開始オプション: open 停止オプション: immediate データベース・ロール: PRIMARY 管理ポリシー: AUTOMATIC サーバー・プール: ディスク・グループ: RECO,DATA マウント・ポイントのパス: サービス: タイプ: SINGLE データベースは有効です データベースはノード: で個別に有効になっています データベースはノード: で個別に無効になっています OSDBAグループ: dba OSOPERグループ: oper データベース・インスタンス: orcl 構成されたノード: fence01,fence02 CSSクリティカル: no CPU数: 0 メモリー・ターゲット: 0 最大メモリー: 0 データベース・サービスのデフォルト・ネットワーク番号: データベースは管理者によって管理されています
データベースインスタンスの稼働ノードの切り替わりを、以下の2つのケースで検証しました。
・クラスタ障害による「フェイルオーバー」
・計画的なリソースの「リロケート」
なお、検証環境はコンテナ構成で行っており、CDBの起動時にPDBもOPENするよう事前にSAVE STATEを設定しています。
SQL> alter pluggable database ORCL_PDB open; プラガブル・データベースが変更されました。 SQL> alter pluggable database ORCL_PDB save state; プラガブル・データベースが変更されました。 SQL> select * from DBA_PDB_SAVED_STATES; CON_ID CON_NAME INSTANCE_NAME CON_UID GUID STATE RESTRICTED ------ --------- ------------- ---------- -------------------------------- ------ ---------- 3 ORCL_PDB orcl 4162591447 A7599F4EE5443B65E05337B0A8C0756D OPEN NO
ノードリブートなどの障害を想定し、ノード間通信を監視するデーモンであるocssd.binをkillしてフェイルオーバーを発生させました。
まず、現状はクラスタが正常に稼働していることを確認します。
[grid@fence01 ~]$ crsctl stat res -t -------------------------------------------------------------------------------- Name Target State Server State details -------------------------------------------------------------------------------- Local Resources -------------------------------------------------------------------------------- ora.LISTENER.lsnr ONLINE ONLINE fence01 STABLE ONLINE ONLINE fence02 STABLE ora.chad ONLINE ONLINE fence01 STABLE ONLINE ONLINE fence02 STABLE ora.net1.network ONLINE ONLINE fence01 STABLE ONLINE ONLINE fence02 STABLE ora.ons ONLINE ONLINE fence01 STABLE ONLINE ONLINE fence02 STABLE -------------------------------------------------------------------------------- Cluster Resources -------------------------------------------------------------------------------- ora.ASMNET1LSNR_ASM.lsnr(ora.asmgroup) 1 ONLINE ONLINE fence01 STABLE 2 ONLINE ONLINE fence02 STABLE 3 ONLINE OFFLINE STABLE ora.DATA.dg(ora.asmgroup) 1 ONLINE ONLINE fence01 STABLE 2 ONLINE ONLINE fence02 STABLE 3 OFFLINE OFFLINE STABLE ora.LISTENER_SCAN1.lsnr 1 ONLINE ONLINE fence01 STABLE ora.MGMTLSNR 1 ONLINE ONLINE fence01 169.254.3.76 10.0.1. 10 10.0.2.10,STABLE ora.RECO.dg(ora.asmgroup) 1 ONLINE ONLINE fence01 STABLE 2 ONLINE ONLINE fence02 STABLE 3 OFFLINE OFFLINE STABLE ora.asm(ora.asmgroup) 1 ONLINE ONLINE fence01 Started,STABLE 2 ONLINE ONLINE fence02 Started,STABLE 3 OFFLINE OFFLINE STABLE ora.asmnet1.asmnetwork(ora.asmgroup) 1 ONLINE ONLINE fence01 STABLE 2 ONLINE ONLINE fence02 STABLE 3 OFFLINE OFFLINE STABLE ora.cvu 1 ONLINE ONLINE fence01 STABLE ora.fence01.vip 1 ONLINE ONLINE fence01 STABLE ora.fence02.vip 1 ONLINE ONLINE fence02 STABLE ora.mgmtdb 1 ONLINE ONLINE fence01 Open,STABLE ora.orcl.db 1 ONLINE ONLINE fence01 Open,HOME=/u01/app/o racle/product/19.0.0 /dbhome_1,STABLE ora.qosmserver 1 ONLINE ONLINE fence01 STABLE ora.scan1.vip 1 ONLINE ONLINE fence01 STABLE --------------------------------------------------------------------------------
ocssd.binのPIDを確認しkillコマンドでプロセスを停止させます。
--ocssd.bin を KILL する [grid@fence01 ~]$ ps -eldf |grep ocssd.bin 4 S grid 4136 1 0 -40 - - 571810 futex_ 01:58 ? 00:00:40 /u01/app/19.0.0/grid/bin/ocssd.bin 0 S grid 17691 14812 0 80 0 - 28579 pipe_w 06:29 pts/0 00:00:00 grep --color=auto d.bin [grid@fence01 ~]$ kill -9 4136
ocssd.binを停止させるとクラスタを構成するノード間のハートビートが途切れ、障害が発生したノードはOSリブートが発生します。
--ノード1が停止したためCluster Resourceはノード2へフェイルオーバー [grid@fence02 ~]$ crsctl stat res -t -------------------------------------------------------------------------------- Name Target State Server State details -------------------------------------------------------------------------------- Local Resources -------------------------------------------------------------------------------- ora.LISTENER.lsnr ONLINE ONLINE fence02 STABLE ora.chad ONLINE ONLINE fence02 STABLE ora.net1.network ONLINE ONLINE fence02 STABLE ora.ons ONLINE ONLINE fence02 STABLE -------------------------------------------------------------------------------- Cluster Resources -------------------------------------------------------------------------------- ora.ASMNET1LSNR_ASM.lsnr(ora.asmgroup) 1 ONLINE OFFLINE STABLE 2 ONLINE ONLINE fence02 STABLE 3 ONLINE OFFLINE STABLE ora.DATA.dg(ora.asmgroup) 1 ONLINE OFFLINE STABLE 2 ONLINE ONLINE fence02 STABLE 3 OFFLINE OFFLINE STABLE ora.LISTENER_SCAN1.lsnr 1 ONLINE OFFLINE STABLE ora.MGMTLSNR 1 ONLINE ONLINE fence02 169.254.3.208 10.0.1 .20 10.0.2.20,STABLE ora.RECO.dg(ora.asmgroup) 1 ONLINE OFFLINE STABLE 2 ONLINE ONLINE fence02 STABLE 3 OFFLINE OFFLINE STABLE ora.asm(ora.asmgroup) 1 ONLINE OFFLINE STABLE 2 ONLINE ONLINE fence02 Started,STABLE 3 OFFLINE OFFLINE STABLE ora.asmnet1.asmnetwork(ora.asmgroup) 1 ONLINE OFFLINE STABLE 2 ONLINE ONLINE fence02 STABLE 3 OFFLINE OFFLINE STABLE ora.cvu 1 ONLINE ONLINE fence02 STABLE ora.fence01.vip 1 ONLINE INTERMEDIATE fence02 FAILED OVER,STABLE ora.fence02.vip 1 ONLINE ONLINE fence02 STABLE ora.mgmtdb 1 ONLINE OFFLINE STABLE ora.orcl.db 1 ONLINE OFFLINE fence02 STARTING ora.qosmserver 1 ONLINE OFFLINE fence02 STARTING ora.scan1.vip 1 ONLINE OFFLINE fence02 STARTING -------------------------------------------------------------------------------- --データベースがノード2で起動したことを確認 [grid@fence02 ~]$ crsctl stat res -t -w "TYPE = ora.database.type" -------------------------------------------------------------------------------- Name Target State Server State details -------------------------------------------------------------------------------- Cluster Resources -------------------------------------------------------------------------------- ora.orcl.db 1 ONLINE ONLINE fence02 Open,HOME=/u01/app/o racle/product/19.0.0 /dbhome_1,STABLE --------------------------------------------------------------------------------
リソースのフェイルオーバーが完了したことを確認し、データベースへ接続を試みます。
--接続確認 [oracle@fence02 ~]$ sqlplus sys/oracle@orcl as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on 土 6月 13 06:55:06 2020 Version 19.7.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. 最終正常ログイン時間: 土 6月 13 2020 06:54:57 +09:00 Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production Version 19.7.0.0.0 に接続されました。 SQL> select status from v$instance; STATUS ------------------------------------ OPEN SQL> show con_name CON_NAME ------------------------------ CDB$ROOT SQL> show pdbs CON_ID CON_NAME OPEN MODE RESTRICTED ---------- ---------- ---------- ---------- 2 PDB$SEED READ ONLY NO 3 ORCL_PDB READ WRITE NO
CDBのorclへ接続しインスタンスがOPENであること、加えてフェイルオーバー後PDBのorcl_pdbもOPENしていることが確認できました。
ノード障害が発生しても、SEHAであればこのように稼働ノードを切り替えることで継続的なサービスの提供が実現できます。
システムメンテナンスを行う必要があるがサービス提供の中断が難しい場合など、リソースを待機ノードへ計画的に移動させることも可能です。
現在インスタンスが稼働しているノードを確認し、対向ノードへリソースを移動させます。
--現在データベースはノード2で実行されている [oracle@fence01 ~]$ srvctl status database -db orcl インスタンスorclはノードfence02で実行中です。 --稼働ノードを切り替える [oracle@fence01 ~]$ srvctl relocate database -db orcl -node fence01 [oracle@fence01 ~]$ srvctl status database -db orcl インスタンスorclはノードfence01で実行中です。
稼働ノードの切り替え後も接続が可能であることを確認します。
--接続確認 [oracle@fence01 ~]$ sqlplus sys/oracle@orcl as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on 月 6月 15 20:31:30 2020 Version 19.7.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. 最終正常ログイン時間: 月 6月 15 2020 20:27:58 +09:00 Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production Version 19.7.0.0.0 に接続されました。 SQL> show con_name CON_NAME ------------------------------ CDB$ROOT SQL> show pdbs CON_ID CON_NAME OPEN MODE RESTRICTED ---------- ---------- ---------- ---------- 2 PDB$SEED READ ONLY NO 3 ORCL_PDB READ WRITE NO
※注意※
リロケートにおいても前述のOracleデータ・リカバリ・ポリシーは適用されるため、切り替え時は綿密なメンテナンスの計画をお勧めします。
障害発生時に稼働ノードが意図せず切り替わった場合に備え、従来のRACでも利用されている接続時フェイルオーバーや透過的アプリケーションフェイルオーバーが利用可能です。
|
|
接続時フェイルオーバーとは、tnsnames.oraの接続先ホストへ接続リクエストを行った際に何らかの障害で接続が行えない場合に、TNSエラーを即座に返すことでTCPタイムアウトを発生させず別の接続ホストへ再接続を行う機能です。
検証では上記の機能を応用し、ノード1とノード2の接続情報を記載しておくことでデータベースインスタンスの稼働ノードが切り替わっても、ユーザが意識することなくクライアントから接続できることを確認しています。
まず、tnsnames.oraは下記のようにインスタンスが稼働し得るノードのVIPを接続先ホストとして記載します。
[oracle@fence01 ~]$ vi $ORACLE_HOME/network/admin/tnsnames.ora # tnsnames.ora Network Configuration File: /u01/app/oracle/product/19.0.0/dbhome_1/network/admin/tnsnames.ora # Generated by Oracle configuration tools. ORCL_PDB = (DESCRIPTION = (ADDRESS_LIST = (FAILOVER = ON) (ADDRESS = (PROTOCOL = TCP)(HOST = fence01-vip.ashisuto.co.jp)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = fence02-vip.ashisuto.co.jp)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl_pdb.ashisuto.co.jp) ) )
現在インスタンスはノード1で稼働しています。
上記の接続識別子ORCL_PDBを使用してデータベースへ問題なくログオンができます。
--現在はノード1で実行されている [oracle@fence01 ~]$ srvctl status database -db orcl インスタンスorclはノードfence01で実行中です。 [oracle@fence01 ~]$ sqlplus sys/oracle@orcl_pdb as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on 月 6月 15 22:33:40 2020 Version 19.7.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. 最終正常ログイン時間: 月 6月 15 2020 20:49:14 +09:00 Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production Version 19.7.0.0.0 に接続されました。 SQL> select INSTANCE_NAME,HOST_NAME,STATUS,EDITION,DATABASE_TYPE 2 from V$INSTANCE; INSTANCE_NAME HOST_NAME STATUS EDITION DATABASE_TYPE -------------- ---------------------- ------ -------- --------------- orcl fence01.ashisuto.co.jp OPEN SE2 SINGLE SQL> exit Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production Version 19.7.0.0.0との接続が切断されました。
データベースをリロケートし稼働ノードをノード2へ切り替え、再度接続を確認します。
--データベースをノード2へリロケート [oracle@fence01 ~]$ srvctl relocate database -db orcl -node fence02 [oracle@fence01 ~]$ srvctl status database -db orcl インスタンスorclはノードfence02で実行中です。 --接続確認 [oracle@fence01 ~]$ sqlplus sys/oracle@orcl_pdb as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on 月 6月 15 22:37:12 2020 Version 19.7.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. 最終正常ログイン時間: 月 6月 15 2020 22:33:40 +09:00 Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production Version 19.7.0.0.0 に接続されました。 SQL> select INSTANCE_NAME,HOST_NAME,STATUS,EDITION,DATABASE_TYPE 2 from V$INSTANCE; INSTANCE_NAME HOST_NAME STATUS EDITION DATABASE_TYPE -------------- ---------------------- ------ -------- --------------- orcl fence02.ashisuto.co.jp OPEN SE2 SINGLE
上記のようにV$INSTANCE.HOST_NAMEにはノード2のホスト名が表示され、現在orclインスタンスがノード2で稼働していることがわかります。
稼働ノードが切り替わってもtnsnames.oraの記述や接続識別子の書き換えを伴わず、ユーザが意識することなくデータベースへ接続が可能です。
なお、今回の検証では接続先ホストにノードVIPを使用しましたが、もちろんSCAN VIPでも接続時フェイルオーバーが行えます。
透過的アプリケーションフェイルオーバー（TAF）とは、接続中のセッションに障害が発生した場合に別のリスナーを介しセッションをフェイルオーバーする機能です。
検証ではSCANリスナーを介した接続を行い、何れのノードで障害が発生した場合にも有効なリスナーへ接続をリダイレクトできるように設定しました。
[oracle@fence01 ~]$ vi $ORACLE_HOME/network/admin/tnsnames.ora # tnsnames.ora Network Configuration File: /u01/app/oracle/product/19.0.0/dbhome_1/network/admin/tnsnames.ora # Generated by Oracle configuration tools. ORCL_PDB = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = fence-scan.ashisuto.co.jp)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl_pdb.ashisuto.co.jp) (FAILOVER_MODE = (METHOD = BASIC)(TYPE = SESSION)(retries = 20)) ) )
上記の接続識別子を使用してセッションを確立した状態で、インスタンスの稼働ノードのCRSを停止し、フェイルオーバー後のインスタンスへ接続を確立できるか確認しました。
ノード1でインスタンスが稼働している状態から検証を開始します。
--現在はノード1でデータベースが実行されている [oracle@fence02 ~]$ sqlplus sys/oracle@orcl_pdb as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on 月 6月 15 22:53:31 2020 Version 19.7.0.0.0 Copyright (c) 1982, 2019, Oracle. All rights reserved. 最終正常ログイン時間: 月 6月 15 2020 22:50:34 +09:00 Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production Version 19.7.0.0.0 に接続されました。 SQL> select INSTANCE_NAME,HOST_NAME,STATUS,EDITION,DATABASE_TYPE 2 from V$INSTANCE; INSTANCE_NAME HOST_NAME STATUS EDITION DATABASE_TYPE -------------- ---------------------- ------ -------- --------------- orcl fence01.ashisuto.co.jp OPEN SE2 SINGLE
接続したセッションがTAFが有効であることをあらかじめ確認します。
--TAFが有効なセッションか確認 ※V$SESSION.FAILOVER_TYPEがNONE以外の場合、TAFが有効なセッションです。 SQL> select userenv('SID') from dual; USERENV('SID') -------------- 22 SQL> select SID,USERNAME,SERVICE_NAME,FAILOVER_TYPE,FAILOVER_METHOD,FAILED_OVER 2 from V$SESSION 3 where FAILOVER_TYPE != 'NONE'; SID USERNAME SERVICE_NAME FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER --- -------- ------------ -------------- --------------- ------------- 22 SYS orcl_pdb SESSION BASIC NO
現在ノード1でインスタンスが稼働しているため、ノード1のCRSを停止させてセッションがフェイルオーバーするかを確認します。
--ノード1でインスタンスが稼働しているので、ノード1のCRSを停止
[root@fence01 grid]# crsctl stop crs
CRS-2791: 'fence01'上にある、Oracle高可用性サービス管理下のリソースの停止を開始しています
CRS-2673: 'ora.crsd'('fence01')の停止を試行しています
CRS-2790: サーバー'fence01'上にある、Cluster Ready Services管理下のリソースの停止を開始しています
CRS-2673: 'ora.orcl.db'('fence01')の停止を試行しています
CRS-2673: 'ora.chad'('fence01')の停止を試行しています
CRS-2677: 'ora.chad'('fence01')の停止が成功しました
CRS-2677: 'ora.orcl.db'('fence01')の停止が成功しました
CRS-33673: リソース・グループ'ora.asmgroup'をサーバー'fence01'で停止しようとしています
CRS-2673: 'ora.RECO.dg'('fence01')の停止を試行しています
CRS-2673: 'ora.DATA.dg'('fence01')の停止を試行しています
CRS-2673: 'ora.LISTENER.lsnr'('fence01')の停止を試行しています
CRS-2677: 'ora.RECO.dg'('fence01')の停止が成功しました
CRS-2677: 'ora.DATA.dg'('fence01')の停止が成功しました
CRS-2673: 'ora.asm'('fence01')の停止を試行しています
CRS-2677: 'ora.asm'('fence01')の停止が成功しました
CRS-2673: 'ora.ASMNET1LSNR_ASM.lsnr'('fence01')の停止を試行しています
CRS-2677: 'ora.LISTENER.lsnr'('fence01')の停止が成功しました
CRS-2673: 'ora.fence01.vip'('fence01')の停止を試行しています
CRS-2677: 'ora.fence01.vip'('fence01')の停止が成功しました
CRS-2677: 'ora.ASMNET1LSNR_ASM.lsnr'('fence01')の停止が成功しました
CRS-2673: 'ora.asmnet1.asmnetwork'('fence01')の停止を試行しています
CRS-2677: 'ora.asmnet1.asmnetwork'('fence01')の停止が成功しました
CRS-33677: リソース・グループ'ora.asmgroup'がサーバー'fence01'で正常に停止しました。
CRS-2672: 'ora.fence01.vip'('fence02')の起動を試行しています
CRS-2676: 'ora.fence01.vip'('fence02')の起動が成功しました
CRS-2672: 'ora.orcl.db'('fence02')の起動を試行しています
CRS-2676: 'ora.orcl.db'('fence02')の起動が成功しました
CRS-2673: 'ora.ons'('fence01')の停止を試行しています
CRS-2677: 'ora.ons'('fence01')の停止が成功しました
CRS-2673: 'ora.net1.network'('fence01')の停止を試行しています
CRS-2677: 'ora.net1.network'('fence01')の停止が成功しました
CRS-2792: 'fence01'上にある、Cluster Ready Services管理下のリソースの停止が完了しました
CRS-2677: 'ora.crsd'('fence01')の停止が成功しました
CRS-2673: 'ora.asm'('fence01')の停止を試行しています
CRS-2673: 'ora.crf'('fence01')の停止を試行しています
CRS-2673: 'ora.drivers.acfs'('fence01')の停止を試行しています
CRS-2673: 'ora.mdnsd'('fence01')の停止を試行しています
CRS-2677: 'ora.drivers.acfs'('fence01')の停止が成功しました
CRS-2677: 'ora.crf'('fence01')の停止が成功しました
CRS-2677: 'ora.mdnsd'('fence01')の停止が成功しました
CRS-2677: 'ora.asm'('fence01')の停止が成功しました
CRS-2673: 'ora.cluster_interconnect.haip'('fence01')の停止を試行しています
CRS-2677: 'ora.cluster_interconnect.haip'('fence01')の停止が成功しました
CRS-2673: 'ora.ctssd'('fence01')の停止を試行しています
CRS-2673: 'ora.evmd'('fence01')の停止を試行しています
CRS-2677: 'ora.ctssd'('fence01')の停止が成功しました
CRS-2677: 'ora.evmd'('fence01')の停止が成功しました
CRS-2673: 'ora.cssd'('fence01')の停止を試行しています
CRS-2677: 'ora.cssd'('fence01')の停止が成功しました
CRS-2673: 'ora.gipcd'('fence01')の停止を試行しています
CRS-2673: 'ora.gpnpd'('fence01')の停止を試行しています
CRS-2677: 'ora.gpnpd'('fence01')の停止が成功しました
CRS-2677: 'ora.gipcd'('fence01')の停止が成功しました
CRS-2793: 'fence01'上にある、Oracle高可用性サービス管理下のリソースの停止が完了しました
CRS-4133: Oracle高可用性サービスは停止されました。
ノード1で稼働時のインスタンスに接続されていたときはSIDが”22”でしたが、次に確認するとSIDは”147”へ変化しており、V$SESSION.FAILED_OVERはYESとフェイルオーバーされたセッションであることが確認できました。
また、現在接続されているインスタンスの稼働ノードはノード2であるため、TAFが動作することが確認できました。
--セッションがフェイルオーバーされたことを確認 ※FAILOVER_TYPEがSESSIONの場合、Doc ID 1744118.1にあるように ORA-25408を検知しセッションがフェイルオーバーします。 SQL> select SID,USERNAME,SERVICE_NAME,FAILOVER_TYPE,FAILOVER_METHOD,FAILED_OVER 2 from V$SESSION 3 where FAILOVER_TYPE != 'NONE'; select SID,USERNAME,SERVICE_NAME,FAILOVER_TYPE,FAILOVER_METHOD,FAILED_OVER * 行1でエラーが発生しました。: ORA-25408: 安全にコールを再実行することはできません。 SQL> / SID USERNAME SERVICE_NAME FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER --- -------- ------------- -------------- --------------- --------------- 147 SYS orcl_pdb SESSION BASIC YES SQL> select INSTANCE_NAME,HOST_NAME,STATUS,EDITION,DATABASE_TYPE 2 from v$instance; INSTANCE_NAME HOST_NAME STATUS EDITION DATABASE_TYPE -------------- ---------------------- ------ -------- --------------- orcl fence02.ashisuto.co.jp OPEN SE2 SINGLE
TAFは実行中の処理を継続させることが可能な処理がSELECTのみであったり、OCIのライブラリを使用するためJDBC Thin接続では利用できないなど、設計面で実装が難しい機能ではありますが、SEHAの構成であっても利用できることを確認できました。
次に、オラクル社純正の他の高可用性構成とSEHAを比較してみましょう。
Oracle Database 19cからSE2ライセンスであればSEHAかOracle Restart（スタンドアロンサーバーでGIを利用したシングルインスタンス）、Oracle Database Enterprise Edition（以降、EE）であればRACやRAC One Nodeのオプションも選択肢となります。
|
|
Active/ActiveであるRAC構成は障害時も生存ノードで処理を継続し続けられることから、高可用性の面で抜きん出ており、加えてスケーラビリティの点でもクラスタ参加ノードの増減が柔軟な点が非常に魅力的です。
RAC One Nodeも含め、EEの構成ではローリングアップグレードがサポートされることから、システム停止なくパッチ適用が可能な点も強みです。
機能面の比較については下記のオラクル社ドキュメントもあわせてご紹介します。
Clusterware Administration and Deployment Guide 19c
High Availability Options for Oracle Database
当記事では、SEHAの特徴や検証結果をご紹介しました。
SE RACのサポート終了に伴い、システム更改時にOracleDBの可用性構成の見直しが伴うことが予想されます。
バージョンアップやシステムのリプレースにあたっては、本記事でご紹介した「可用性」の観点以外にも、システムに求められている的確な要件を把握した上で「コスト」「性能」「拡張性」「運用・保守性」「セキュリティ」などの非機能要件を慎重に検討することが重要なポイントとなります。
・どのような障害を想定し、どの程度の停止時間を許容するのか
・適切なコストバランスを保つためにどのようなエディションを選択するのか
・システムの安定稼働を実現するためにどの程度の性能基準とするのか
・将来的な拡張性を見据えてどのようなやハードウェアを選択すのか
・システムを運用・保守していく上で必要な監視、管理の仕組みをどのように構成するのか
・リスクを未然に防ぎ、データを守るためにはどのようにすれば良いのか
etc
このような非機能要件も十分に考慮して、バージョンやエディションを適切に選択していただくことを強くお勧めします。
現行システムがSE RACのお客様は既存のSE2ライセンスをご利用いただきSEHAへ構成を変更するのか、また、EEにマイグレーションをしてRAC構成を踏襲しつつEEの様々な機能を積極的に活用するのか。当記事がお客様にとって最適なOracleDBのエディション検討の参考情報になれば幸いです。
|
|---|
アシスト北海道
2016年アシスト北海道へ入社後、Oracle Databaseのサポート業務に従事。入社2年目より夜間休日帯など営業時間外の緊急対応を主に担当。現在は通常時間帯のサポート業務を担当しており、第一線で日々奮闘中。...show more
■本記事の内容について
本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。
■商標に関して
・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。
Oracle Database 23aiでは生成AIに関連する新機能が多く追加。特にAutonomous Database 23aiの「Select AI」機能は大規模言語モデル（LLM）を使用して、自然言語による問い合わせやテストデータの自動生成が可能に。本記事では、Select AIの機能について検証結果を交えて紹介します。
RMANを使って表単位リカバリをする際には制御ファイルのバックアップにも注意する必要があります。世代管理の設定次第では意図せずリカバリができないことがあるため、注意点をお伝えします。
前回の記事では、HCXの概要をお伝えしました。今回はOCVSでHCXを利用するための検討ポイントや前提事項を説明します！
