Oracle RACのロードバランシング
1.クライアント
接続文字列でLOAD_BALANCE = YESを指定してロード・バランシング・ノードを指定します。デフォルトでは有効になっていません。
2. サーバー側
local_listenerとremote_listenerによる負荷分散で、ローカルとリモートの負荷状況を把握。
接続数レベルでの負荷分散は、ロードバランシングによって確保することができます。DNSとの併用を推奨する必要があります。
よくあるケースを共有
環境：
11.2.0.4
正しいコンフィギュレーション
local_listener=)
remote_listener=
ケース1：local_listenerの設定ミス：
現象：
データベースは、ASMを含むようにパラメータ化され、GIを再起動した後、データベースが接続できないことが判明しました。明らかにリブート方法は適用されず、リブートとパラメータ修正アクションを行いましたが、まず第一に、パラメータレベルがリスニングまたは接続関連のパラメータに関与していないことが除外されました。
質問です：
なぜ再起動がリンクの問題を引き起こすのですか？
問題の特定：
データベースが接続することはできません、現象は、リンクタイムアウト、ポートが見つかりません、ローカルパラメータが正しく設定されていることがわかりました、ログがアクションを変更しました：
SUCCESS: diskgroup DATA がマウントされました。
注：データベースRACとディスクグループリソースora.DATA.dgの依存関係は確立されています。
7月7日（火）22:28:46 2020
理由分析：このパラメータは手動で変更されるのではなく、GI が DB をプルアップするときに自動的に設定されます。ポート1523は確かにここでも使用されています。 1523を使用するリスナーがシステム内にあり、これはOracleの予期された動作ではありませんが、この種の問題は本当に注意すべきです。
関連するバグがあり、まだ確定していません：
ケース2：remote_listenerの設定ミス
現象：
また、再起動は、アプリケーションは、再起動後に接続することはできません、前者は、人々がそれを踏んだ後に落とし穴を掘りました。この再起動は、メンテナンスの再起動ではなく、異常な再起動であり、再起動の理由は、主に問題によって引き起こされるremote_listenerの開始後に確認するために、詳細に入ることはありません、このパラメータは、ヌルアプリケーションへのアクセス異常の後に再起動します。
理由：なぜ空なのですか？
誰かがこのパラメータを手動で変更したことを確認すると、パラメータはspfileに硬化されず、メモリにのみ硬化されました。この操作の理由は、インスタンスがspfileを使用せずにpfileを使用して起動されたため、一連のポットホールによって再起動後にパラメータが失われたためです。
概要
その後、トラブルシューティングのアイデアに異常をリンクするように更新されます、これらの2つの構成に加えて、また、落とし穴を繰り返さないように、データベースルーチン検出項目に入れてください。
