Mac De Oracle - １０万円 de RAC #40 Tweet

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

1. ハードウェアの価格と構成
2. Linux (CentOS 4.4)のインストール
3. ネットワークの構成
4. Openfilerのインストール
5. OpenfilerによるiSCSIボリュームの構成
6. Oracle RACノードでのiSCSIボリュームの構成　その１。　その２。
7. Oracle所有者と関連ディレクトリの作成及び環境変数の設定
8. Oracle向けLinuxサーバーの構成（カーネルパラメータの設定）
9. hangcheck-timerカーネル・モジュールの構成
10. Oracle RACノード間リモートアクセスの構成
11. Oracle RACノード構成ファイルの確認
12. Oracle Cluster File System (OCFS2)のインストール及び構成　その１/その２/その３
13. Oracle Automatic Storage Management(ASMLib 2.0)のインストール及び構成
14. Oracle 10gソフトウェアのダウンロード
15. Oracle10g R2インストール事前作業　その１/その２/その３/その４
16. Oracle10g Clusterwareのインストール
17. Oracle10g R2 Database softwareのインストール　その１/その２
18. Oracle10g R2 Companion CD softwareのインストール
19. TNS Listenerの構成
20. Oracle Cluster databaseの作成　その１/その２
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　サービスの起動が失敗している。。。
ということで、１０万円 De RACの次回投稿は、環境の回復後ということになってしまった。（いやはや、最悪は再構築か？？？　まぁ、そうなった場合でもたいした手間ではないのだが。。。。一度、やり直しているし。openfilerのiscsi-targetサービスが起動すれば全ては解決できることなので、もしかすると意外に簡単なことなのかもしれないが。。。）　

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