OPS for NT 入門日本オラクル株式会社 1998年2月18日 1 (注) この資料はOracle8.0を想定して記述しております。 1 アジェンダ OPS for NTの基礎知識 – OPS for NT アーキテクチャ – RAWデバイスの設定とアクセス方法 – クライアントからの接続 – OPS for NT の管理 – アーカイブログ運用 OPS for NT 耐障害テスト結果 2 シングルインスタンス構成インスタンス SGA LGWR DBWR ・・・データベース REDOログファイルデータファイル制御ファイル OPSの動きを説明する前に、通常のシングルノードでのOracleデータベースはどのような構成になっているのかを説明致します。 Oarcleデータベースは「インスタンス」と「データベース」から構成されます。「インスタンス」はSGA(*1)と呼ばれるメモリー領域とLGWRやDBWRといったバックグラウンドプロセス群から構成されています。「データベース」はディスクに保存されたデータファイル・制御ファイル・REDOログファイルといった複数の物理ファイルから構成されています。 *1 SGA ( System Grobal Area ) ＜参考＞ Oracle_SID というのはインスタンス名を表わし、初期化パラメータにある db_nameがデータベース名を表わします。 3 パラレルサーバの構成インスタンス１インスタンス２ SGA LGWR DBWR SGA ・・・ DBWR LGWR ・・・データベース REDOログファイル REDOログファイルデータファイル制御ファイル共有ディスク(RAWデバイス) 上の図はOPSの構成図になります。 OPSの特徴は以下のものが挙げられます。・ Oracleインスタンスは、各ノード上で動作する。・各々のインスタンスは、独立したSGAおよびバックグラウンドプロセス群を所有する。・全てのインスタンスが同じデータファイルと制御ファイルを共有する。・各インスタンスは、独自のREDOログファイルの１セットを持ち、それに対して書き込みを行う。・全てのインスタンスで、同一のデータベースに同時にトランザクションを実行でき、各インスタンスでは、複数のユーザーが同時にトランザクションを実行できる。・単一ノードのOracle同様、行レベルロックが保持される。・データベースはRAWデバイス上に置かなければいけない(*1) *1 これは、「異なるノード間で同じファイルシステムをマウントすることはできない」という理由からです。 4 ＯPＳの構成クライアント Oracle RDBMS Oracle Parallel Server 初期化パラメータファイル Oracle RDBMS Oracle Parallel Server 初期化パラメータファイルハートビート共有ディスク（RAW ）共有ディスク（RAW）ローカルDISK ローカルDISK DB-A データベースファイル制御ファイル REDOログファイル 5 5 OPS for NT サービスの実装異なるインスタンスクライアント・ OracleServiceOPS1 ・ OracleServiceOPS2 ・ OracleTNSListner80 ・ OracleTNSListner80 ・ OracleAgent80 ・ OracleAgent80 OPS2 OPS1 ハートビート共有ディスク（RAW ）共有ディスク（RAW） OPS 同じデータベース 6 6 OPS for NT サービスの実装クライアント・ OracleServiceOPS1 ・ OracleServiceOPS2 ・ OracleTNSListner ・ OracleTNSListner ・ OracleAgent80 ・ OracleAgent80 OPS2 ハートビート共有ディスク（RAW ）共有ディスク（RAW） OPS 同じデータベース 7 7 Oracle Parallel Server アーキテクチャユーザー Oracle クラスタポーティングインタフェースユーザー Applications Applications Oracle DBMS + Parallel Server Oracle DBMS + Parallel Server OSDレイヤ OSDレイヤ Windows NT 4.0 高速インターコネクトハートビート OSDレイヤ OSDレイヤ Windows NT 4.0 共有ディスク（RAWデバイス） RAWデバイス） 8 ＯＳＤレイヤ CM CM IPC IO Start P&M IPC IO Start P&M OSレベルでクラスタの各ノードを監視ノード間通信に利用全てのノードから共有ディスクへの同時アクセスを実現 OPSコンポーネントの起動順序を定義 Oracle Enterprise Manager (OEM) など、管理ツール及びパフォーマンス監視ツールを利用可能にする 9 9 アジェンダ OPS for NTの基礎知識 – OPS for NT アーキテクチャ – RAWデバイスの設定とアクセス方法 – クライアントからの接続 – OPS for NT の管理 – アーカイブログ運用 OPS for NT 耐障害テスト結果 10 RAWデバイスの設定空き領域拡張パーティション論理ドライブフォーマット NTFS ／ FAT RAWパーティションこの状態のものを使うファイルフォーマットしていないのでOSから認識できない 11 RAWデバイスの設定は、ディスクアドミニストレータで行います。 RAWパーティションは、ディスクアドミニストレータ上で拡張パーティションを作成し、それにフォーマットを全く適用しない状態で論理ドライブを割り当てた時に作成されます。 11 RAWデバイスの設定 RAWパーティション … 共有ディスクローカルディスク 12 この図の場合、ディスク2がローカルディスク、ディスク0,1が共有ディスクとなっています。 12 RAWパーティションへのアクセス２．アクセス時はシンボリックリンク名にアクセスする OPS_LOG1T1 シンボリックリンク名１． RAWパーティションとシンボリックリンク名をリンク付ける 13 13 WindowsNT における論理ドライブの命名規則 \Device\HarddiskX\PartitionY X 物理ドライブ番号Ｙ論理ドライブ番号 \Device\Harddisk0\Partition1 14 WindowsNTの場合、論理ドライブは\Device\HarddiskX\PartitionY として定義されます。 XとYはそれぞれ「ディスクアドミニストレータ」ウィンドウに示されている物理ドライブ番号と論理ドライブ番号です。共有ディスク(ディスク0)上で左から1番目の論理ドライブは \Device\Harddisk0\Parririon1 と定義されます。 (Diskの番号は0からPartitionの番号は1から始まることにご注意下さい*1) *1 Partition0はディスク全体を表わすという特別な意味を持っています 14 SETLINKS ユーティリティ（１） RAWパーティションとシンボリックリンク名をリンク付ける C:\> SETLINKS /F: OPS_log1t1 OPS_LOG1t1 \Device\Harddisk0Partition1 シンボリックリンク名 15 OPSではRAWデバイスへのアクセスは論理ドライブに直接アクセスするのではなく、シンボリックリンクを通じて行います。そのためには、シンボリックリンク名と論理ドライブを関連付ける必要がありますが、そのためのユーティリティとしてOPSはSETLINKSユーティリティを用意しています。 15 SETLINKS ユーティリティ（２） OPS_log1t1 OPS_log2t1 OPS_sys01 … \Device\Harddisk0Partition1 \Device\Harddisk0Partition2 \Device\Harddisk1Partition1 … ORALINK1.TBL C:\> SETLINKS /F : ORALINK1.TBL OPS_log1t1 OPS_log２t1 OPS_sys01 16 図上にORALINK1.TBL(*1)というテーブルファイルがありますが、このようなシンボリック名と論理ドライブとの関連を記述したテーブルファイルを作成し、 SETLINKS /F:テーブルファイルと実行することにより、シンボリックリンク名と論理ドライブを関連付ける事ができます。 (この作業は両ノードで行う必要があります) *1 OPSはこのようなテーブルファイルのひな形を用意していますので、このひな形を修正することにより簡単にテーブルファイルを作成することができます。 16 アクセス例 create database ops controlfile reuse logfile '\\.\OPS_log1t1' size 20M reuse, '\\.\OPS_log2t1' size 20M reuse datafile '\\.\OPS_sys01' size 30M reuse character set JA16SJIS; \\.\シンボリックリンク名自ノードを表わす 17 17 RAWデバイスのバックアップ RAWデバイス → NTFS OCOPY80 \\.\OPS_USER01 D:\backup\user01 シンボリックリンク名を使用 NTFS → RAWデバイス OCOPY80 D:\backup\user01 \\.\OPS_USER01 18 RAWデバイスはWindowsNTから認識できない ( WindowsNTエクスプローラから見えない ) ので、通常のCOPYコマンドを使用することができません。そのため、Oracle8でRAWデバイスをバックアップするにはオラクルが提供しているOCOPY80コマンドを使用する必要があります。このコマンドは、RAWデバイスをWindowsNTが認識できるファイルにコピーするコマンドです。 18 アジェンダ OPS for NTの基礎知識 – OPS for NT アーキテクチャ – RAWデバイスの設定とアクセス方法 – クライアントからの接続 – OPS for NT の管理 – アーカイブログ運用 OPS for NT 耐障害テスト結果 19 クライアントからの接続 OPSへの接続は基本的には以下の３つ・明示的な接続・ Net8の Listner Load Balancing を利用した接続・アプリケーション・フェール・オーバでの接続 20 明示的な接続ノード１ノード２どちらのノードに接続するか明示的に指定共有ディスク 21 OPSの場合、クライアントからサーバへの接続する時には、「明示的にサーバを指定する」というのが基本的な考え方です。あるサーバがダウンした時には、そのサーバに接続していたクライアントにエラーメッセージが返されます。そのクライアントが、システムに再接続したければ、稼動しているサーバに明示的に接続し直す必要があります。 21 Listener Load Balancing ( Net2.3～ ) ノード1 ListenerOPS1 InstanceOPS1 ノード2 ランダム ListenerOPS2 InstanceOPS2 22 OPSの接続のやり方には、SQL*Net のListener Load Balancing(LLB)機能を使用する方法があります。 LLBは、1つの接続文字列に「リスナーとインスタンス」のセットを複数設定します。この設定により、１つの接続文字列から複数の「リスナーとインスタンス」に接続がばらけることにより、Load Balancing つまり負荷分散を実現します。 22 Listener Load Balancing ( Net2.3～ ) DESCRIPTION_LIST句を書く事により DESCRIPTION句を複数設定可能 tnsnames.ora ops.world = ( DESCRIPTION_LIST = (DESCRIPTION = ADDRESS = (PROTOCOL = tcp) (HOST = OPS1) (PORT = 1521)) (CONNECT_DATA = (SID = ops1))) (DESCRIPTION = (ADDRESS = (PROTOCOL = tcp) (HOST = OPS2) (PORT = 1521)) (CONNECT_DATA = (SID = ops2)))) ここで設定したアドレスにランダムに接続しにいく 23 Listener Load Balancing ( Net2.3～ ) ノード1 ListenerOPS1 InstanceOPS1 ノード2 ListenerOPS2 InstanceOPS2 既にダウンしているリスナーに接続しに行く時にはクライアントにエラーメッセージが返らずに、自動的に稼動ノードに接続できる 24 LLBは、リスナーが落ちている場合、そのリスナーに接続しようとしますが、リスナーとのコンタクトに失敗した場合は、クライアントにエラーメッセージを返さずに、他のリスナーに接続することができます。 24 Listener Load Balancing ( Net2.3～ ) ノード1 ListenerOPS1 InstanceOPS1 ORA-12203 ノード2 ListenerOPS2 InstanceOPS2 インスタンスがダウンしている時にはクライアントにエラーメッセージが返ってしまい稼動ノードにつながらない。 25 LLBは「インスタンスが落ちていてリスナーが稼動している」状態のリスナーには接続しに行き、インスタンスが落ちているので ORA-12203 などのエラーメッセージを返します。 ORA-12203 TNS: 宛先に接続できません 25 アジェンダ OPS for NTの基礎知識 – OPS for NT アーキテクチャ – RAWデバイスの設定とアクセス方法 – クライアントからの接続 – OPS for NT の管理 – アーカイブログ運用 OPS for NT 耐障害テスト結果 26 OPSCTLユーティリティ SVRMGR ノード１１．tnsnames.oraからOPSノードの情報を取得 tnsnames.ora OPSCTL SVRMGR ノード２２．各ノードのSVRMGRをキック。インスタンスの起動・停止を行う SVRMGR ノード３ 27 OPSCTLはクラスタ内の全てのインスタンスに関する情報をTNSNAMES.ORAから取得します。次にそのノード上のOPSCTLはNet8を通じて、他のノードと交信を行います。 <コマンド例> 全てのインスタンスを起動 OPSCTL START -Cinternal/password -Ndatabase_name 個々のインスタンスの起動 OPSCTL START -Isid -Cinternal/password -Ndatabase_name 全てのインスタンスの停止 OPSCTL STOP -Cinternal/password -Ndatabase_name 個々のインスタンスの停止 OPSCTL STOP -Isid -Cinternal/password -Ndatabase_name <設定上の注意点> ・インスタンスの各SIDが、OPS内で重複していないこと。・ OPSCTLユーティリティが実行されているノード上のTNSNAME.ORAファイルに各インスタンスのエントリが含まれていること。・全てのインスタンスのINIT_COM.ORAおよびINITSID.ORAが ORACLE_HOME\DATABASAE(7.3.4の場合はORACLE_HOME\OPS ) ディレクトリにあること。 27 OEMからのOPSの管理 OEM　コンソール Agent OPSCTL ノード１ Agent OPSCTL ノード２ Agent OPSCTL ノード３ 28 OPSCTLユーティリティを、OEMコンソールからコールすることも可能です。 ( OSDにP&M モジュールが含まれていることが前提です) OPSCTLがOEMコンソールによってコールされると、OPSCTLとの通信には１つのノードだけのIntelligentAgentが使われます。次にそのノード上のOPSCTLはNet8を通じて、他のノードと交信を行います。 28 手動による起動・停止 29 OEM利用すると、OPS全体とOPS個々のインスタンスの起動・停止が実現できます。 <OPS全体の起動> ナビゲータウィンドウからOPSを右クリック。起動を選択。 → 起動画面で「選択したインスタンスのみ」をチェックしない <OPS各インスタンスの起動> ナビゲータウィンドウからOPSを右クリック。起動を選択。 → 起動画面で「選択したインスタンスのみ」をチェック → 「インスタンスの選択」ボタンをクリック → 起動したいインスタンスを選択 <OPS全体の停止><OPS各インスタンスの停止>についても、停止を選択することにより同様のやり方で行うことができます。 29 OPSに対するジョブの発行 30 OEMはOPS全体とOPSの各インスタンスに対してジョブの発行を行うことができます。 OPSに対してのジョブを作成するには、ジョブ作成画面の「宛先のタイプ」からパラレルサーバを選択します。すると「使用可能な宛先」に検出されているOPSサービスが表示されますので、そこで適当なOPSサービスを選択することにより、ジョブを作成することができます。また、OPSの各インスタンスに対してのジョブを作成するには、ジョブ作成画面の「宛先のタイプ」からパラレルサーバインスタンスを選択します。すると「使用可能な宛先」に検出されているOPSの各インスタンスが表示されますので、そこで適当なインスタンスを選択することにより、ジョブを作成することができます 30 OPS用イベントの作成 31 OEMはOPSの各インスタンスに対してのイベントを作成し、それらのイベントの監視を行うことができます。 OPSの各インスタンスに対してのイベントを作成するには、「イベントセットの作成」画面の「サービスタイプ」で「Parallel Server Instance 」を選択します。すると「使用可能な宛先」に検出されているOPSインスタンスが表示されますので、そこで適当なOPSインスタンスを選択することにより、イベントを作成することができます。 31 アジェンダ OPS for NTの基礎知識 – OPS for NT アーキテクチャ – RAWデバイスの設定とアクセス方法 – クライアントからの接続 – OPS for NT の管理 – アーカイブログ運用 OPS for NT 耐障害テスト結果 32 アーカイブログ運用の注意点 • アーカイブログファイルはRAWデバイス上には置けない • LOG_ARCHIVE_FORMATにはログ順序番号とスレッド番号を指定する • リカバリ時にはリカバリセッションによって読み込めなければいけない 33 OPSでアーカイブ運用を行う場合にはいくつか注意点が必要です。まず、一番気を付けなければならないのが、アーカイブログファイルはRAW デバイス上には置けない。という事です。これはアーカイブログファイルは Oracleが動的に名前を付けて生成するという性質を持っているからです。また、アーカイブファイルのフォーマットですが、通常のシングルインスタンスで指定している「ログ順序番号」に加え、インスタンスを識別するスレッド番号を指定します。例) LOG_ARCHIVE_FORMAT = ＬＯＧ％ｓ_％ｔ．ＡＲＣさらに、アーカイブ運用 ( REDOログからアーカイブログにCOPYを行っている )時には、各ノードのローカルディスク等にアーカイブファイルを置きますが、リカバリを行う時には、リカバリセッションが認識できるディレクトリ (LOG_ARCHIVE_DEST)上にアーカイブログがなければなりません。 33 アーカイブ運用構成例ノード1 ノード２ローカルデイスクローカルデイスクアーカイブログファイルアーカイブログファイル REDOログファイルデータファイル共有DISK(RAW) REDOログファイル 34 34 アジェンダ OPS for NTの基礎知識 – OPS for NT アーキテクチャ – RAWデバイスの設定とアクセス方法 – クライアントからの接続 – OPS for NT の管理 – アーカイブログ運用 OPS for NT 耐障害テスト結果 35 Oracleを起動する前の最終チェックユーザー Applications Oracle DBMS + Parallel Server Oracle クラスタポーティングインタフェース OSDレイヤ OSDレイヤ Windows NT 4.0 ユーザーこの階層できちんとクラスタ構成が確立していること !! Applications Oracle DBMS + Parallel Server OSDレイヤ OSDレイヤ Windows NT 4.0 共有ディスク（RAWデバイス） RAWデバイス） 36 ＤＬＭ．ＬＯＧ • Oracleの下の階層できちんとクラスタ構成が出来ているかを確認する事 • dlm の Reconfigurationが行われたノード数を意識する（すべてのノードで同じ時間に同じノード数になっている） • 問題が判明するまでサービス・インスタンスの状態をかえない DLM.LOG 14:23:43-00196-00142- Reconfiguration started: Thu Mar 05 14:23:43 1998 14:23:43-00196-00142- List of ノードs: 0, 14:23:43-001f4-00142- Reconfiguration complete: Thu Mar 05 14:23:43 1998 14:25:02-0034b-00142- Reconfiguration started: Thu Mar 05 14:25:02 1998 14:25:02-0034b-00142- List of ノードs: 0,1, 14:25:07-002ce-00142- Reconfiguration complete: Thu Mar 05 14:25:07 1998 37 dlm.logをチェックすることにより、クラスタ構成の状態を把握することができます。クラスタ構成は、ノードの状況により変化します。障害が発生した場合には、そのノードを切り離し、稼動ノードだけでクラスタ構成を確立し、そのノードが復旧した場合は、復旧ノードを加えた状態でクラスタ構成を確立します。 dlm.logを見ることにより、クラスタ構成の状況を把握することができます。スライドの例を見てみましょう。 Mar05 14:23:43 に Reconfiguration がスタートし、その時は０番のノード（実際にはノード1) のみでReconfigurationが行われていて、complete しています。つまり、この時点では、１ノードだけでクラスタ構成を確立しています。 Mar05 14:25:02 に Reconfiguration がスタートし、その時は０番と１番のノード（実際にはノード1、ノード2)でReconfigurationが行われていて、complete した。つまり、２ノードでクラスタ構成を確立したことになります注) DLM.LOGはOracleService<SID>のサービスの開始時に古いものをクリアし、新たに書き出しを始めます。障害の原因が判明するまでは、むやみにOracleService<SID>の停止・開始を行わないようにして下さい。また、Oracleインスタンスを起動する際には必ずdlm.logを確認して、正常なクラスタ構成が確立されていることを確認後、起動して下さい。 37 ＰＧＭＳ．ＬＯＧ • Ｏｒａｃｌｅ８からDLMがIDLMとなりOracleのコンポーネントとなった。 • Ｏｒａｃｌｅを立ち上げないとログを書いてくれない。 • Ｏｒａｃｌｅ８からは、PGMS.LOGで確認する。 PGMS.LOG 20:06:57 | MESSAGE 20:06:57 | MESSAGE 20:06:57 | MESSAGE 20:06:57 | MESSAGE | 00ea | | 00ea | pGMSNodeMap(): Event(3) CMEVENT_RECONFIG Rcfg(6) NodeMap [00][00][00][02] | 0105 | HandleReconfig(): Reconfig OK - nodes(1) rcfgGen(7) master(1) | 0105 | 15:01:36 | 15:01:36 | 15:01:37 | 15:01:37 | | 00b1 | | 00b1 | pGMSNodeMap(): Event(1) CMEVENT_RECONFIG Rcfg(0) NodeMap [00][00][00][03] | 0049 | HandleReconfig(): Reconfig OK - nodes(2) rcfgGen(2) master(0) | 0049 | MESSAGE MESSAGE MESSAGE MESSAGE 38 38 検証環境サーバーノード数 CPU per node Memory per node 共有ディスク高速インタコネクト OS クラスタソフト Oracleのバージョン . Hitachi FLORA-S series/SM2 2 2 ( PentiumPro 200MHZ ) 512MB Hitachi Disk Array DF350 (HT-4044-C934D) 100BaseT ( HITACHI PC-CN7320 ) Windows NT 4.0, Service Pack 3 MultiServer/Connection Manager for Windows NT Oracle7 Server for Windows NT R7.3.3.0.5 ( ただし、OCOPYのテストの時には7.3.4.2.0を使用 ) 39 今回の障害テストは日立様の協力を得、上記の様な環境でテストを行いました。 39 テストの流れ client1 client２ノード１に接続ノード２に接続 1行Insert into emp 1行Insert into emp 1行Update emp 1行Update emp １行 Delete from Emp １行 Delete from Emp 障害を発生させる COMMIT COMMIT 障害内容の把握復旧 40 障害テストでは、以下のような流れでテストを行いました。データベースには、SCOTT/TIGERユーザーを作成し、EMP表を作る。クライアントマシンから、SQL*Plusを使い、ノード１及びノード２のインスタンスにセッションを張る。 EMP表に対して、2つのSQL*Plusから1行ずつInsertする。 EMP表に対して、2つのSQL*Plusから1行ずつUpdateする。 EMP表に対して、2つのSQL*Plusから1行ずつDeleteする。これらのDML文は、ノード１からはOPS1.sql、ノード２からはOPS2.sqlの各スクリプトで行う。障害を発生させる。障害発生後、2つのSQL*PlusでCommitを発行する。障害内容の把握。 ※障害発生後、前述のOPS1.sql又はOPS2.sqlがlockを保持しているかどうか確認するために、「正常なノード」から「障害発生ノードが更新していたデータ」に対して、更新を行うSQL文を発行しました。 40 インスタンス停止 ORA-１２５７１発生正常動作クライアントノード１ Shutdown Immediate Shutdown Abort ノード２インスタンス１インスタンス２ DB テスト１ 41 ノード１のインスタンスを停止する (Shutdown Immediate / Shutdown Abort) < Client側での障害検知 > ノード1 commitを発行時 → ORA-12571 再接続時 → ORA- 12203 ノード２ commitを発行時 → 正常再接続時 → 正常ノード１が更新していたデータに対して更新処理を行う → ロック待ちなし < 原因の特定 > ノード1上でsvrmgr23を起動し、internalで接続。 select username,status from v$session; の発行。 → ORA-01034が発生。インスタンスが停止していると考えられる。 < 対処方法 > dlm.logによりクラスタ構成を確認した後、インスタンスを起動する。ノード２の更新内容はDBに反映されていますが、ノード１の更新内容はロールバックされ反映されていません。ノード１で行った更新処理を再度行う必要があります。 ORA-12571 ORA-12203 ORA-01034 TNS: パケットライターに障害が発生しました TNS: 宛先に接続できません Oracleは使用不能です 41 OracleService<SID>停止 ORA-１２５７１発生正常動作クライアントノード１ OracleService<SID>停止ノード２インスタンス１インスタンス２ DB 42 テスト２ノード１のOracleService<SID>を停止する < Client側での障害検知 > ノード1 commitを発行時 → ORA-12571 再接続時 → ORA- 12203 ノード２ commitを発行時 → 正常再接続時 → 正常ノード１が更新していたデータに対して更新処理を行う → ロック待ちなし < 原因の特定 > ノード1上でsvrmgr23を起動。 → ORA-09352が発生。これにより、OracleService<SID>が停止していると考えられる。 < 対処方法 > ノード１でサービスを開始、dlm.logによりクラスタ構成を確認した後、インスタンスを起動する。ノード２の更新内容はDBに反映されていますが、ノード１の更新内容はロールバックされ反映されていません。ノード１で行った更新処理を再度行う必要があります。 ORA-12571 ORA-12203 ORA-09352 TNS: パケットライターに障害が発生しました TNS: 宛先に接続できません Windows32ビットの２タスクドライバは新規のOracleタスクを起動できません 42 マシン電源ダウン ORA-０３１１３発生正常動作クライアントノード１マシン電源DOWN ノード２インスタンス１インスタンス２ DB 43 テスト３ノード１の電源を停止する < Client側での障害検知 > ノード1 commitを発行時 → ORA-03113 ノード２ commitを発行時 → 正常再接続時 → ORA- 12203 再接続時 → 正常ノード１が更新していたデータに対して更新処理を行う → ロック待ちなし < 原因の特定 > ノード1を見てみると、電源が落ちていることが確認できる。 < 対処方法 > ノード１で電源を入れ、サービスを開始、dlm.logによりクラスタ構成を確認した後、インスタンスを起動する。ノード２の更新内容はDBに反映されていますが、ノード１の更新内容はロールバックされ反映されていません。ノード１で行った更新処理を再度行う必要があります。 ORA-03113 ORA-12203 通信チャネルでファイルの終わりが検出されました TNS: 宛先に接続できません 43 パブリックネットワーク切断 (1) ORA-０３１１３発生正常動作クライアントノード１ノード１のPublic ケーブルを抜くノード２インスタンス１インスタンス２ DB 44 テスト４ノード１に接続しているPublicケーブルを抜く < Client側での障害検知 > ノード1 commitを発行時 → ORA-3113 再接続時 → ORA- 12203 ノード２ commitを発行時 → 正常再接続時 → 正常ノード１が更新していたデータに対して更新処理を行う → ロック待ち状態 < 原因の特定> ノード1上でsvrmgr23を起動し、internalで接続。 select username,status from v$session; の発行。 → インスタンス１で接続していたユーザがStatusがINACTIVEの状態でセッションが残っている。インスタンスは正常であると分かる。 Lisnrctlでリスナーの状態を確認。 → 正常であると分かる。 Pingコマンドをクライアントに向けて発行。 → Time Outになるので、Network障害であることが確認できる。 < 対処方法 > 次ページ ORA-03113 ORA-12203 通信チャネルでファイルの終わりが検出されました TNS: 宛先に接続できません 44 パブリックネットワーク切断 (2) ロック待ちクライアントネットワーク障害を解決ノード１セッションが切れてしまったクライアントが更新していたデータを、他のセッションから更新しようとするとロック待ち状態になるノード２インスタンス１インスタンス２ DB 45 < 対処方法 > ここで、ネットワークの問題を解決しても、復旧が終わる訳ではない。この場合、インスタンス１でつながっていたユーザのセッションが残ってしまうため、そのユーザが変更をかけていた行に対してのロックがかかった状態のままになってしまう。この時のセッションは V$SessionのSTATUS:INACTIVE という状態で残り続ける。ちなみに、ALTER SYSTEM KILL SESSION ; を残ったセッションに発行しても、STATUS がKILLになるだけで、ロックは保持され続ける。この状態からセッションを消す方法は以下の３つが考えられる。１． SHUTDOWN ABORTを行う。２． SQL*NetのSQLNET.EXPIRE_TIMEのパラメータを設定する３． TCP/IPのKeep Aliveの設定を行う。ノード２の更新内容はDBに反映されていますが、ノード１の更新内容はロールバックされ反映されていません。残ったセッションが消えた後で、ノード１で行った更新処理を再度行う必要があります。注) ・ SQLNET.EXPIRE_TIMEについてはマニュアル「SQL*Netの理解」を参照して下さい。・ NTでのTCP/IPの設定は次のページに説明しています。・また、このケーブル障害時のロックの問題はOPS特有の問題でなく、通常のシングルノードでも起こる問題である。 45 WindowNTでのKeepAliveの設定レジストリでTCP/IPのKeep Aliveを行う。パラメータは HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service\TCPIP\P arameters -\KeepAliveTime デフォルト 7,200,000(２時間) -\KeepAliveInterval デフォルト 1000(1秒) -\TcpMaxDataRetransmissions デフォルト 5(回) 46 WindowsNTの場合は、レジストリでTCP/IPのKeep Aliveを行う。パラメータ詳細は以下の通り。 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service\TCPIP\Parameters (a) KeepAliveTime タイプ：REG_DWORD - ミリセコンド範囲：1-0xFFFFFFFF デフォルト：7,200,000（2時間）最後のデータ送受信が行われてから、KeepAliveパケットを送信するまでの時間を設定する。[KeepAliveTime]時間を経過しても次のパケットが届かない場合に、1回目のKeepAlive パケットが送信される。 (b) KeepAliveInterval タイプ：REG_DWORD - ミリセコンド範囲：1-0xFFFFFFFF デフォルト：1000(1秒) (c) TcpMaxDataRetransmissions タイプ：REG_DWORD - 数範囲：0-0xFFFFFFFF デフォルト：5（回） [KeepAliveInterval]時間後に2回目のKeepAliveパケットが送信される。その後、 [TcpMaxDataRetransmissions]回数、KeepAliveパケットを送信し、返答が無い場合に接続を切断する。この時、2回目以降のKeepAliveパケットの送信間隔は、前回の2倍の時間が設定される。このパラメータの値を変更(特にKeepAliveTimeの時間を短く設定)することにより、TCP/IP のタイムアウトの時間を短くすることができる。このパラメータの値を変更してテストした結果、残ったセッション(STATUS:INVALIDのセッションも)がV$SESSIONから削除され、ロックを解放することが確認できた。今回は、設定を変更することによる、システム全体への影響についての検証までは行いませんでした。実際に使用する際には影響を考えて設定する必要があります。 46 プライベートケーブル切断（１）正常動作 ORA-３１１３発生クライアントノード１のPrivateケーブルを抜くノード１ノード２インスタンス１インスタンス２ DB 47 テスト６ノード１のPrivateケーブルを抜く (1) < Client側での障害検知 > ノード1 commitを発行時 → 正常再接続時 → 正常ノード２ commitを発行時 → 正常再接続時 → ORA-12500 (select 発行時にORA-3113) ノード２が更新していたデータに対して更新処理を行う → ロック待ちなし注) Privateケーブル障害が起き、ノード間通信ができなくなった場合は、クォーラムリソースをつかんでいるノードが生き残る。今回のテストではノード１がクォーラムリソースをつかんだためノード１が生き残こった。ノード２では commitが正常に発行できたが、これはタイミングの問題 (クラスタがノード間通信の障害を判別する前にcommit処理を終えることができた ) であり、commit時点でエラーが発生する場合もある。 < 原因の特定 > 両ノードのOracle Service<SID>を確認。ノード１ → 正常ノード２ → 終了両ノードのdlm.logを確認ノード１ → ノード１でReconfig(１つのノードだけで、クラスタ環境を構築) ノード２ → error １つのノードだけでクラスタ構成が構築されていることにより、Privateケーブルが怪しいと判断。ノード１からノード２にPrivateケーブル経由でPingを発行。Time Out になることにより、Privateケーブル障害が発見できる。 47 プライベートケーブル切断（２）正常動作 ORA-３１１３発生クライアントノード１のPrivateケーブルを抜くノード１ノード２インスタンス１インスタンス２ DB 48 テスト６ノード１のPrivateケーブルを抜く (2) < 対処方法 > ネットワークの問題を解決した後、ノード２で、サービスを開始、dlm.logによりクラスタ構成 (２ノードでクラスタ構成していること)を確認した後、インスタンスを起動する。今回のケースでは、ノード１・ノード２の更新内容が共に反映されていた(両ノードともに commit処理は正常に終了)。ただし、ノード２でのCommit処理時にエラーになり、commitができなかった場合にはノード２で行った更新処理を再度行う必要があります ORA-03113 ORA-12500 通信チャネルでファイルの終わりが検出されました TNS:リスナーが専用サーバ・プロセスの起動に失敗しました 48 ノードのSCSIケーブル切断 ORA-01092発生 (ORA-00603発生) 正常動作クライアントノード１ノード２インスタンス１インスタンス２ノード１の共有 Diskにつながる SCSIケーブルを抜く DB 49 テスト７ノード１の共有DISKにつながるSCSIケーブルを抜く < Client側での障害検知 > ノード1 commitを発行時 → ORA-01092(0603) 再接続時 → ノード２ commitを発行時 → 正常再接続時 → ORA-00472 正常ノード２が更新していたデータに対して更新処理を行う → ロック待ちなし < 原因の特定 > ノード１上でsvrmgr23を起動しinternalで接続を行う。 select username,status from v$session; の発行。 → ORA-1034 ノード１のディスクアドミニストレータで、共有DISKがofflineになっていることを確認 → SCSIケーブル障害の発見 < 対処方法 > この場合、SCSIケーブルを接続しただけでは、データベースを起動することができない。 (ORA-1081やORA-1012が発生) 一度、データベースを shutdown abort し、データベースを再起動する。ノード２の更新内容はDBに反映されていますが、ノード１の更新内容はロールバックされ反映されていません。ノード１で行った更新処理を再度行う必要があります。 ORA-01092 ORA-00603 ORA-00472 ORA-01034 ORA-01081 ORA-01012 Oracleインスタンスが終了しました強制的に接続が切り離されます致命的なエラーが発生したためOracleサーバセッションが終了しました PMONプロセスはエラーで終了しました Oracleは使用不能ですすでに稼働中のOracleを起動しました。まずOracleを停止して下さい。ログオンしていません。 49 共有DISKのSCSIケーブル切断 ORA-01092発生 ORA-00603発生クライアントノード１ノード２インスタンス１共有Diskの SCSIケーブルを抜くインスタンス２ DB 50 テスト８共有DISKのSCSIケーブルを抜く < Client側での障害検知 > ノード1 commitを発行時 → ORA-0603 再接続時 → ORA- 00472 ノード２ commitを発行時 → ORA-1092 再接続時 → ORA- 00472 < 原因の特定 > 両ノードでsvrmgr23を起動し、internalで接続。両ノードで select username,status from v$session; の発行。 → ORA-1034 両ノードのディスクアドミニストレータで、共有DISKがofflineになっていることを確認 → SCSIケーブル障害の発見 < 対処方法 > この場合、SCSIケーブルを接続しただけでは、データベースを起動することができない。 (ORA-1081やORA-1012が発生) 一度、データベースを shutdown abort し、データベースを再起動する。両ノードの更新内容はDBに反映されていません。両ノードで行った更新処理を再度行う必要があります。 ORA-00603 ORA-01092 ORA-00472 ORA-01034 ORA-01081 ORA-01012 致命的なエラーが発生したためOracleサーバセッションが終了しました Oracleインスタンスが終了しました強制的に接続が切り離されます PMONプロセスはエラーで終了しました Oracleは使用不能ですすでに稼働中のOracleを起動しました。まずOracleを停止して下さい。ログオンしていません。 50 ディスク電源ダウン ORA-00603発生 ORA-00603発生クライアントノード１ノード２インスタンス１共有Diskの電源を切断するインスタンス２ DB 51 テスト９共有DISKの電源を切断する < Client側での障害検知 > ノード1 commitを発行時 → ORA-0603 再接続時 → ORA-00472 ノード２ commitを発行時 → ORA-0603 再接続時 → ORA-00472 < 原因の特定 > 両ノードでsvrmgr23を起動し、internalで接続。両ノードで select username,status from v$session; の発行。 → ORA-1034 両ノードのディスクアドミニストレータで、共有DISKがofflineになっていることを確認 → 共有DISKの電源切断を発見 < 対処方法 > この場合、共有DISKの電源を入れただけでは、データベースを起動することができない。一度、データベースを shutdown abort し、データベースを再起動する。両ノードの更新内容はDBに反映されていません。両ノードで行った更新処理を再度行う必要があります。 ORA-00603 ORA-00472 ORA-01034 ORA-01081 ORA-01012 致命的なエラーが発生したためOracleサーバセッションが終了しました PMONプロセスはエラーで終了しました Oracleは使用不能ですすでに稼働中のOracleを起動しました。まずOracleを停止して下さい。ログオンしていません。 51 まとめクライアントから、障害内容を特定することは困難サーバ側での原因究明作業は必須インスタンスの状態の確認 OracleService<SID>の状態の確認 dlm.logの確認 dlm.logによりクラスタ構成の再構築が行われている場合にはPingを実行するディスクアドミニストレータでの共有DISKの確認 52 クライアントからは、障害内容のある程度の予測は出来ますが、特定することは困難だと思われます。やはり、障害時にはある程度スキルをもった技術者による「サーバ側でのトラブルシューティング」が不可欠になります。その際には以下のような作業を行うことにより原因究明が可能になります。・インスタンスの状態の確認・ OracleService<SID>の状態の確認・ dlm.logの確認・ dlm.logによりクラスタ構成の再構築が行われている場合にはPingを実行する・ディスクアドミニストレータでの共有DISKの確認尚、WindowsNTでは、リモートでサーバの作業は出来ませんので、これらの作業はサーバが置いてある現場で行う事になります。また、障害は１つだけとは限りません。複数の障害が同時に起こる場合もありますので、障害解決後には必ずdlm.logを確認し、正常なクラスタ構成が確立していることを確認してから、データベースを立ち上げる必要があります。また、dlm.logはOracleService<SID>のサービスの開始時に古いものをクリアし、新たに書き出しを始めますので、むやみにOracleService<SID>の起動・停止を行わないように気を付けて下さい。 52 最後になりますが、OPSの導入の一番のメリットは、マシンを多重化することによる「システム可用性の向上」ですが、OPSの管理は決して簡単なものではありません。シングルノードのWindowsNTシステムのように、「障害が起きたら、何も考えずに立ち上げ直せば良い」というものではないのです。 OPS for NTは「ある程度管理コストがかかっても、可用性を向上したい」というシステムに向いています。提案時には、お客様にこの事をしっかりと認識してもらうことが大切だと思います。この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。この文書に関連して不都合が生じた場合も、米国オラクル社及び日本オラクル株式会社は一切保証せず、特に責任は負いかねますのでご容赦下さい。また許可なく、改編、引用することを禁じます。 53