Crs-4124

Oracleログファイルを介してCRSの起動プロセスについて学習します



Learn About Startup Process Crs Through Oracle Log Files



このトピックを共有したい理由は、正常に起動できないCRSの障害、手がかりが見つからなかった無力感とパニックに最初に遭遇したとき、それを今でも覚えているからです。当時の私と同じ初心者が多いと思います。 CRSの問題に直面したとき、彼らには何の手がかりもないかもしれません。実際、障害の分析も同様です。内部を知ることができれば、手のひらをひっくり返すのと同じくらい簡単に故障解析ができると思います。



今日は、関連するログファイルを介してCRSの起動プロセスを分析します。この方法でCRSの起動プロセスを理解し、将来の初心者のCRS問題を分析できるようになることを願っています。助けになる。 '



まず、コンセプトを明確にする必要があります。CRSとは何ですか？

ここで説明するために、ここで説明するCRSはCRSDプロセスではなく、RACの高可用性データベース用に提供されたクラスタリングソフトウェアのセットを指します。



それでは、今日のトピックを正式に始めましょう。まず、次の「RACコンポーネントの起動図」を見てみましょう。 Oracleのバージョン間の違いにより、今回使用したバージョンは11gR2です。後で、関連するトレースファイルとログファイルの内容により、これらのコンポーネントの起動プロセスと、それらが行ったことをより明確に確認できます。




上記のRACコンポーネントの起動関係図から、CRSのさまざまなコンポーネントの起動関係を大まかに理解できます。


起動プロセス全体は依然として非常に複雑に見え、階層も非常に明確です。もちろん、最も重要なものはOHASDからCSSDAGENT、OHASDからORAROOTAGENT、そしてCRSDであり、最後にCRSDは管理対象アプリケーション（またはアプリケーションリソース）を起動してこれらのステップを開始します。

この写真を見ているだけでは、初心者には覚えにくいですが、それでも構いません。ゆっくりと写真を保存して見ることができます。これらのプロセスの関連するログファイルの内容から、考え方を変えて上の図の意味を理解しましょう。

もちろん、RAC関連のログを表示する場合は、最初にそれらを見つける必要があります。 RACCRS関連のログファイルの場所は次のとおりです。


Clusterwareデーモンログはすべて/ log /の下にあります。 / log /の下の構造：

alert.log-ほとんどのクラスターウェアの問題については、まずここをご覧ください
./admin：
。/エージェント：
./agent/crsd：
./agent/crsd/oraagent_oracle：
./agent/crsd/ora_oc4j_type_oracle：
./agent/crsd/orarootagent_root：
./agent/ohasd：
./agent/ohasd/oraagent_oracle：
./agent/ohasd/oracssdagent_root：
./agent/ohasd/oracssdmonitor_root：
./agent/ohasd/orarootagent_root：
。/クライアント：
./crsd：
./cssd：
./ctssd：
./discmon：
./evmd：
./gipcd：
./gnsd：
./gpnpd：
./mdnsd：
./ohasd：
./racg：
./racg/racgeut：
./racg/racgevtf：
./racg/racgmain：
./srvm：


ログファイルの場所がわかったら、起動ログをたどってCRS起動プロセス全体を監視します。

ここでの起動環境は2ノードrac、バージョンは11.2.0.4、オペレーティングシステムはRedHat 6、2番目のノードのCRSソフトウェアは閉じているため、分析の起動プロセスがより簡単で明確になります。

CRSが開始されると、最初に記録されるのはアラームログです。次に、アラームログから始めます。 RACアラームログは、alert.logテキストファイルという名前の/ log /ディレクトリに配置されます。




警告の赤い文字からわかるように、最初のステップは、OLRサービスとOHASサービスの起動を完了することです。これら2つのサービスの役割を簡単に紹介します。

OLRはローカルクラスターレジストリであり、その主な機能は、ohasdデーモンのクラスター構成情報と初期化リソース定義情報を提供することです。クラスタがohasdを起動すると、/ etc / oracle /olr.locファイルからOLRの場所が読み取られます。 OLRのデフォルトは$ GRID_HOME / cdata / .olr


OLRのコンテンツは、ocrdump-localfilenameを使用してファイルにエクスポートして表示できます。

11g R2バージョン以降、OHASDはクラスター起動の唯一の開始点です。クラスタ内のすべてのデーモンに対応するリソースを管理する責任があります。


デーモンプロセスログを確認する前に、CRSでのプロセスのログレコードの一般的な形式を簡単に紹介します。

：[成分][]：


次に、この期間中のOHASサービスのログを見てみましょう。このログは/ log // ohasdディレクトリに配置され、ohasd.logという名前が付けられます。



OHASDログの赤い情報から、最初のステップはOLRファイルを初期化してから、OLRの情報を確認することであることがわかります。最後の赤い部分は、RD（Resource Discovery Service）が開始されたことを示します。これは、ohasdが正式に開始されたことを意味します。

次に、ohasdログ情報を確認します。



cssdagent、orarootagent、oraagent、cssdmonitorデーモンの起動を開始し、いくつかのリソース（crf、diskmon、ctss、cluster_interconnect.haip、crsd、mdns、gpnp、gipc、evm、asm、css、cssdmonitorなど）を初期化します。



上記の情報は、開始する必要のあるリソースを対応するプロセスに送信するためのものです。次に、対応するプロセスログ（ログの場所の先頭を参照）をチェックして、これら4つのプロセス（cssdagent、orarootagent、oraagent、cssdmonitor）が担当するリソースを確認します。



ログから開始されたプロセスをログから抽出して表示します。




元の「RACコンポーネントの起動図」をもう一度確認してみましょう。


考えてみてください。起動プロセス全体がログの内容に完全に対応していますか？

ここでは、これら4つのデーモン（cssdagent、orarootagent、oraagent、cssdmonitor）の機能を簡単に紹介します。

  • Cssdagent：ocssd.binデーモンの起動と監視を担当します。

  • Orarootagent：このエージェントプロセスはrootユーザーとして開始され、ユーザーがrootであるリソースの管理を担当します。

  • Oraagent：このプロセスはoracleまたはgridユーザーとして開始され（ログファイル名は_.logで終わります）、oracleまたはgridユーザーのリソースを管理します。

  • Cssdmonitor：ocssd.binデーモンの監視のみを担当します。

次のプロセスで、CRSDはすべてのアプリケーション（またはアプリケーションに対応するリソース）を開始します。ただし、ここでは、対応するリソース情報を開始する必要はありません。この時点でCRSアラームログ情報に記録されているコンテンツを見てみましょう。

アラームログから、GPNPの起動後にCSSDの起動情報が表示されることがわかります。 CSSDの起動は、少なくともGPNPの起動が完了した後に開始する必要があります。ここで、OCSSDのログを観察します。

ログから、クラスターのバージョンが11.2.0.4であることがわかり、GIPCのステータスがチェックされます。現在のチェック結果はダウンしています。

ここでは、これらのプロセスとスレッドの機能を確認する方法についての質問に答えます。正確に推測する方法。


現在、CRSの各スレッドとコンポーネントの特定の機能を説明する公式の本は見つかりませんでした。少なくとも私はまだそれを見つけていません。誰かが持っているなら、私にコピーを送ってください、ありがとう。

ここでは、私が推測する方法を説明します。

通常の状況では、コンポーネント名は4桁で、基本的に最初の2つの英語または4つの英語だけを見て推測します。たとえば、[AGFW]のこのコンポーネントはどういう意味ですか？最初の2つの英語はAGであることがわかりますが、CRSのどの単語がAGで始まりますか？それはエージェントです。次に、このコンポーネントが表示されたときにログを監視しています。これはすべてAGENTのエージェントプロセスに関連しており、少なくともエージェントの機能的責任にも関連しています。前述のように、AGENTは対応するユーザーのリソースを管理する責任があります。前のログから、基本的にリソースを開始していることがわかります。 FWの具体的な意味を明確に知る方法はありませんが（個人的には必ずしもFILE WORKSETだと思います）、少なくともこのコンポーネントがAGENTに関連していることはわかっています。


したがって、このアイデアを使用して、clssscmainスレッドなどのスレッドの特定の意味を分析してみましょう。同様に、最初の2桁はclであり、これはクラスターの最初の2つの英語の単語であると見なすことができ、CLSSはCSSと同等であり、clssscmainのスレッドはcssとscmainの2つの部分に分割され、mainは私たちが知っている完全な単語。今それを取り除いてください。これは、scとmainの2つの部分に分けられます。そして、scはcssdの起動フェーズに表示され、開始チェックとして理解できます。次に、それを組み合わせてcss start check main、cssはチェック用のメインスレッドを開始します。このスレッドに続くコンテンツを比較すると、これが当てはまるように思われることがわかります。


このような考え方で、次のログに表示されるスレッドの意味を分析します。

スレッドclssnmReadDiscoveryProfileとclssnmvDDiscThreadの役割を推測しようとします。

  • clssnmReadDiscoveryProfile：cssノードマネージャー読み取りディスカバリプロファイル

  • clssnmvDDiscThread：cssノードマネージャー投票ディスク検出スレッド


決定する以下の内容によると、おそらくそうです。

ここで、ログの内容を解釈してみましょう。つまり、CSSDのノード管理機能は、RDプロファイルを読み取って投票ファイルの文字列パラメータを検索し、CSSDノード管理機能の投票ディスク検出スレッドは投票ディスクを検索します。


最初にCRSログを読み取ることができるようになったので、何かを見ても慌てる必要はありません。予備読みである理由は、この方法は万能薬ではないため、重要なのは通常の蓄積です。もちろん、特定のスレッドやモジュールの一般的な機能を知る方法は他にもあります。ここで発見するのはあなたにお任せします。次に、CSSDのログを読み取ります。



1つのノードステータスのみがALIVEであること、再構成の必要がないこと、CSSD構成が完了していることを確認し、アラームログ情報を再度確認します。




CSSDの開始後、CTSS、OCR、EVMD、CRSDが次々に開始されます。

CTSS、EVMD、お​​よびCRSDプロセスの機能の簡単な紹介は次のとおりです。

  • CTSS：クラスターノードの時刻の同期を担当するコンポーネント。オブザーバーとアクティビティには2つのモードがあります

  • OCR：クラスター内のすべてのリソースに関する情報

  • EVMD：クラスター時間の生成と記録、およびノー​​ド間でのイベントの受け渡しを担当します

  • CRSD：クラスターリソースの高可用性を実現するために、クラスター内のアプリケーション（またはアプリケーションに対応するリソース）を管理します。 OCRも管理する


コマンドcrs_statを使用して、ここに記載されているリソースを表示できます。



これらは、CRSによって管理されるリソースです。


CRSDデーモンが実行されている場合、CRS（Oracle Clusterware）が開始されます。その後、CRSDは、データベースインスタンスを含むさまざまなリソースの起動を担当します（AUTO_STARTパラメーターが正しい場合）。

CRSの起動順序については、公式文書で次のように説明されています。


レベル1：OHASDスポーン：

  • cssdagent-CSSDの生成を担当するエージェント。

  • orarootagent-ルートが所有するすべてのohasdリソースの管理を担当するエージェント。

  • oraagent-オラクルが所有するすべてのohasdリソースの管理を担当するエージェント。

  • cssdmonitor-CSSDとノードの状態を（cssdagentとともに）監視します。

レベル2：OHASDルートエージェントが生成します：

  • CRSD-クラスターリソースの管理を担当するプライマリデーモン。

  • CTSSD-クラスター時刻同期サービスデーモン

  • Diskmon

  • ACFS（ASMクラスターファイルシステム）ドライバー

レベル2：OHASD oraagentスポーン：

  • MDNSD-DNSルックアップに使用されます

  • GIPCD-プロセス間およびノー​​ド間通信に使用されます

  • GPNPD-グリッドプラグアンドプレイプロファイルデーモン

  • EVMD-イベントモニターデーモン

  • ASM-ASMインスタンスを監視するためのリソース

レベル3：CRSDスポーン：

  • orarootagent-ルートが所有するすべてのcrsdリソースの管理を担当するエージェント。

  • oraagent-Oracleが所有するすべてのcrsdリソースの管理を担当するエージェント。

レベル4：CRSDルートエージェントが生成します：

  • ネットワークリソース-パブリックネットワークを監視する

  • スキャンVIP-シングルクライアントアクセス名仮想IP

  • Node VIPs - One per node

  • ACFSレジスター-ASMクラスターファイルシステムをマウントするため

  • GNS VIP（オプション）-GNSのVIP

レベル4：CRSD oraagentスポーン：

  • ASMリソース-ASMインスタンスリソース

  • ディスクグループ-ASMディスクグループの管理/監視に使用されます。

  • DBリソース-DBとインスタンスの監視と管理に使用されます

  • SCANリスナー-単一クライアントアクセス名のリスナー、SCANVIPでリッスン

  • リスナー-ノードVIPでリッスンしているノードリスナー

  • サービス-サービスの監視と管理に使用されます

  • ONS-Oracle Notification Service

  • eONS-拡張されたOracleNotificationService

  • GSD-9iの下位互換性のため

  • GNS（オプション）-グリッドネーミングサービス-名前解決を実行します

ここでは、RACのCRS起動プロセスについて説明しました。起動プロセス全体を理解した後、起動時のエラーによりRACの起動に失敗した場合、起動時のプロセスのエラー情報に基づいて失敗の原因を分析・診断し、関連する問題を迅速に解決します。障害。

といった：

  • OHASDを開始できません。OLRファイルが存在するかどうかを確認する必要がある場合があります。

  • CRSDを開始できませんでしたが、CSSDが正常に開始できないことが原因ですか？

  • CSSDを開始できません。投票ディスクに問題はありますか？


これらの質問は、CRSの起動プロセスを理解することに基づいて考えることができます。もちろん、この起動プロセスは最も単純なものであり、他のノードはシャットダウンされます。したがって、CRSログの読み取り方法を学ぶことも非常に重要です。私もここであなたと私自身の考えを共有します。お役に立てば幸いです。

最後に、もう1つの質問について考えてみましょう。CRSDまたはASMを最初に開始するのは誰ですか。

公式文書によると：

OCRがASMに格納されている場合は、ora.asmリソース（ASMインスタンス）が開始され、OCRが配置されているディスクグループがマウントされている必要があります。そうでない場合、crsd.logに次の同様の情報が表示されます。



注：バージョン11.2では、ASMはcrsd.binの前に起動し、OCRを含むディスクグループが自動的にマウントされます。

テストでは、ASMを自動的に起動しないように設定してから、サーバーを再起動します。ASMは引き続き自動的に起動し、対応するOCRディスクグループがマウントされています。




今日の共有はここで終わります。このトピックはあなたにもたらされます。また、RACをより明確に理解し、それが何であるか、そしてなぜそれが優れているのかを知ることも誰にとっても重要です。