« Mac De Oracle - 10万円 de RAC #39 | トップページ | 10万円 de RAC 番外編 - Cluster Databaseの削除 »

2007年2月19日 (月)

Mac De Oracle - 10万円 de RAC #40

10万円 de RACのつづき。簡単なTransparent Application Failover (TAF)の確認。

  1. ハードウェアの価格構成
  2. Linux (CentOS 4.4)のインストール
  3. ネットワークの構成
  4. Openfilerのインストール
  5. OpenfilerによるiSCSIボリュームの構成
  6. Oracle RACノードでのiSCSIボリュームの構成 その1。 その2
  7. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
  8. Oracle向けLinuxサーバーの構成(カーネルパラメータの設定)
  9. hangcheck-timerカーネル・モジュールの構成
  10. Oracle RACノード間リモートアクセスの構成
  11. Oracle RACノード構成ファイルの確認
  12. Oracle Cluster File System (OCFS2)のインストール及び構成 その1/その2/その3
  13. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
  14. Oracle 10gソフトウェアのダウンロード
  15. Oracle10g R2インストール事前作業 その1/その2/その3/その4
  16. Oracle10g Clusterwareのインストール
  17. Oracle10g R2 Database softwareのインストール その1/その2
  18. Oracle10g R2 Companion CD softwareのインストール
  19. TNS Listenerの構成
  20. Oracle Cluster databaseの作成 その1/その2
  21. Oracle Net Serviceの確認
  22. 表領域の作成と変更
  23. Oralce RAC ClusterとDatabase構成の確認
  24. Clusterの開始と停止の確認
  25. 簡単なTransparent Application Failover (TAF)の確認
  26. PowerBook G4のJDeveloper10g/SQL Developer/SQL*Plusなどからの接続確認(Mac De Oracleではお約束!なので)
注)
MacOSX 10.4.8(PowerPC)へのOracle10g clientインストールは特に新しいネタでもないので記事として書く予定はないが、MacOSX 10.4.8(PowerPC)のJDeveloper10g、SQL DeveloperやSQL*Plusからの接続確認等の記録は載せる予定である。



今回は、Transparent Application Failover (TAF)を確認する。

とは言っても、大掛かりな方法で確認する訳ではなく、SQL*PlusとSQLを利用したお手軽な方法で行う。



オリジナルと異なるところは、環境変数NLS_LANGが、日本語のキャラクタセットだというところだけなので、特に追記することもなく、一気に確認を。

CentOSがUTF-8ベースであることもあり、環境変数LANG=ja_JP.UTF-8、環境変数NLS_LANG=japanese_japan.AL32UTF8 としてある。データベースキャラクタセットもAL32UTF8としてある。
MacOSXのTerminalは、これらに併せて、UTF-8に設定してある。(以下に示す確認では、日本語を表示することもないのだが、環境としてはそのようになっている。)

尚、手順など、OTN USの元ネタ「29. Transparent Application Failover (TAF)」とほぼ同様なのでそちらも参照されたい。

● tnsnames.oraには、以下のような設定があるはずである。

FAILOVER_MODEパラメータを見てもらうと分かるが、FAILOVERのタイプは、SELECTで、方法は、BASICとなっている。
これは、ノードAに接続しselect文を実行していたセッションは、ノードAに障害が発生しFAILOVERした場合でもノードBに引き継がれ、何事も無かったかのように処理が継続されることを意味する。
また、ノードAに接続し、insert文、update文、delete文のいずれかを実行していたセッションは、FAILOVERが発生した場合、ノードBにセッションは引き継がれ、所定の回復措置を行ったあとで処理(アプリケーション側でのハンドリングを必要とする)を継続できることを意味する。(所定の回復措置とは、FAILOVERが発生したことを示すエラーをキャッチし、現行トランザクションをロールバックし、トランザクションを再開始することを意味する)

ORCLTEST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = discus1-vip.macdeoracle.jp)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = discus2-vip.macdeoracle.jp)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl.discus.info)
(FAILOVER_MODE =
(TYPE = SELECT)
(METHOD = BASIC)
(RETRIES = 180)
(DELAY = 5)
)
)
)

以下、SQL*Plusで接続し、問い合せを実行後、接続しているインスタンス(下記例では、orcl2)をshutdown abortで強制停止し、意図的にFAILOVERを発生させた。その後、同じ問い合せを実行すると接続しているインスタンスは、Cluster内で起動している残りのインスタンス(下記例では、orcl1)に切り替わっていることが確認できる。その際、FAILOVERによるエラー等は一切発生しない。更新トランザクションのFAILOVERについては別エントリで。

SQL> col instance_name for a13
SQL> col failover_method for a15
SQL> col failed_over for a11
SQL> col failover_type for a10
SQL> col host_name for a26
SQL> l
1 select
2 instance_name,
3 host_name,
4 null as failover_type,
5 null as failover_method,
6 null as failed_over
7 from
8 v$instance
9 union
10 select
11 null,
12 null,
13 failover_type,
14 failover_method,
15 failed_over
16 from
17 v$session
18 where
19* username = 'SYSTEM'
SQL> /

INSTANCE_NAME HOST_NAME FAILOVER_T FAILOVER_METHOD FAILED_OVER
------------- -------------------------- ---------- --------------- -----------
orcl2 discus2.macdeoracle.jp
SELECT BASIC NO

SQL>
SQL> !
[oracle@discus1 ˜]$ srvctl status database -d orcl
Instance orcl1 is running on node discus1
Instance orcl2 is running on node discus2
[oracle@discus1 ˜]$ srvctl stop instance -d orcl -i orcl1 -o abort
[oracle@discus1 ˜]$ srvctl status database -d orcl
Instance orcl1 is not running on node discus1
Instance orcl2 is running on node discus2
[oracle@discus1 ˜]$ srvctl start instance -d orcl -i orcl1
[oracle@discus1 ˜]$ srvctl status database -d orcl
Instance orcl1 is running on node discus1
Instance orcl2 is running on node discus2
[oracle@discus1 ˜]$ srvctl stop instance -d orcl -i orcl2 -o abort
[oracle@discus1 ˜]$ srvctl status database -d orcl
Instance orcl1 is running on node discus1
Instance orcl2 is not running on node discus2
[oracle@discus1 ˜]$ exit
exit

SQL> /

INSTANCE_NAME HOST_NAME FAILOVER_T FAILOVER_METHOD FAILED_OVER
------------- -------------------------- ---------- --------------- -----------
orcl1 discus1.macdeoracle.jp
SELECT BASIC YES

SQL>


次回へつづく。



今日、Oracle RACを起動して、MacOSXのOracle Clientから接続した例や、更新系トランザクションのFAILOVERの例を作ろうと思っていたら、なんと、共有DISK(iSCSI)が起動しない。

Openfilerの管理画面やコマンドで確認してみても、iscsi-target サービスの起動が失敗している。。。
ということで、10万円 De RACの次回投稿は、環境の回復後ということになってしまった。(いやはや、最悪は再構築か??? まぁ、そうなった場合でもたいした手間ではないのだが。。。。一度、やり直しているし。openfilerのiscsi-targetサービスが起動すれば全ては解決できることなので、もしかすると意外に簡単なことなのかもしれないが。。。) 

何はともあれ、続きは書くのでご安心を。

|

トラックバック


この記事へのトラックバック一覧です: Mac De Oracle - 10万円 de RAC #40:

コメント

コメントを書く