| Oracle® TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド リリース11.2.1 B56053-02 |
|
 戻る |
 次へ |
| Oracle® TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド リリース11.2.1 B56053-02 |
|
戻る |
次へ |
Oracle Clusterwareは、アプリケーションを監視および制御して高可用性を実現します。この章では、Oracle Clusterwareを使用してTimesTenのアクティブ・スタンバイ・ペアの可用性を管理する方法について説明します。
Oracle Clusterwareの詳細は、Oracle Databaseドキュメントの『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
この章の内容は次のとおりです。
図7-1に、同じローカル・ネットワークに1つの読取り専用サブスクライバを持つアクティブ・スタンバイ・ペアを示します。アクティブ・データベース、スタンバイ・データベースおよび読取り専用サブスクライバは異なるノードにあります。TimesTenを実行しているがアクティブ・スタンバイ・ペアの一部ではないノードが2つあります。アクティブ・データベースの更新は、アプリケーションによって行われます。スタンバイおよびサブスクライバからの読取りもアプリケーションによって行われます。すべてのノードは共有記憶域に接続されています。
Oracle Clusterwareを使用すると、ノード障害およびその他のイベントに対応して、TimesTenデータベースおよびアプリケーションの起動、監視および自動フェイルオーバーを行うことができます。詳細は、「予定されたメンテナンス」および「障害からのリカバリ」を参照してください。
Oracle Clusterwareは、TimesTenの2つの可用性レベルで実装できます。基本的な可用性レベルでは、クラスタ内の2つのマスター・ノードおよび最大127の読取り専用サブスクライバ・ノードが管理されます。アクティブ・スタンバイ・ペアは、ローカル・ホスト名またはIPアドレスを使用して定義されます。両方のマスター・ノードに障害が発生すると、ユーザーが介入してアクティブ・スタンバイ・スキームを新しいホストに移行する必要があります。両方のマスター・ノードに障害が発生すると、Oracle Clusterwareによってユーザーへの通知が行われます。
高度な可用性レベルでは、アクティブ、スタンバイおよび読取り専用サブスクライバ・データベースの仮想IPアドレスが使用されます。初期アクティブ・スタンバイ・ペアの一部ではない追加のノードをクラスタに含めることもできます。障害が発生した場合、仮想IPアドレスを使用することで、追加のノードの1つが、障害の発生したノードの役割を自動的に引き継ぐことができます。
アプリケーションがクライアント/サーバー構成のTimesTenに接続している場合、自動クライアント・フェイルオーバーによって、クライアントは、障害が発生した後にアクティブな役割を持つマスター・データベースに自動的に再接続できます。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTen ClientおよびServerでの作業に関する説明および『Oracle TimesTen In-Memory Databaseリファレンス』のTTC_FailoverPortRangeに関する説明を参照してください。
ttCWAdminユーティリティを使用して、Oracle Clusterwareで管理されているクラスタ内のTimesTenアクティブ・スタンバイ・ペアを管理します。各アクティブ・スタンバイ・ペアの構成は、デフォルトで、cluster.oracle.iniという初期化ファイルに手動で作成されます。このファイルの情報は、Oracle Clusterwareのリソースを作成する場合に使用されます。リソースは、各TimesTenデーモン、データベース、TimesTenプロセス、ユーザー・アプリケーションおよび仮想IPアドレスの管理に使用されます。ttCWAdminユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCWAdminに関する説明を参照してください。cluster.oracle.iniファイルの詳細は、「cluster.oracle.iniファイル」を参照してください。
Oracle Clusterwareを使用して、次の構成のみを管理できます。
読取り専用サブスクライバを持つ（または持たない）アクティブ・スタンバイ・ペア
AWTキャッシュ・グループが構成された（読取り専用サブスクライバを持つ（または持たない））アクティブ・スタンバイ・ペア
読取り専用キャッシュ・グループが構成された（読取り専用サブスクライバを持つ（または持たない））アクティブ・スタンバイ・ペア
AWTキャッシュ・グループおよび読取り専用キャッシュ・グループが構成された（読取り専用サブスクライバを持つ（または持たない））アクティブ・スタンバイ・ペア
ttCWAdminコマンドの実行に必要な権限の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCWAdminに関する説明を参照してください。
Oracle Clusterwareリリース11.1.0.7は、TimesTenアクティブ・スタンバイ・ペアのレプリケーションでサポートされています。ネットワークと記憶域の要件およびOracle Clusterware構成ファイルの情報は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
Oracle ClusterwareおよびTimesTenは、すべてのノードで同じ場所にインストールされている必要があります。
各マシンのクロックの誤差が250ミリ秒以内であるように、すべてのマシンがネットワーク・タイム・プロトコル（NTP）または同様のシステムを使用する必要があります。
Oracle Clusterwareを使用してアクティブ・スタンバイ・ペアを管理する場合、次のコマンドおよびSQL文は使用できません。
SQL文CREATE ACTIVE STANDBY PAIR、ALTER ACTIVE STANDBY PAIRおよびDROP ACTIVE STANDBY PAIR
ttAdminユーティリティの-repStartおよび-repStopオプション
ttAdminユーティリティの-cacheStartおよび-cacheStopオプション（アクティブ・スタンバイ・ペアの作成後）
ttRepAdminユーティリティの-duplicateオプション
ttRepStartおよびttRepStop組込みプロシージャ
また、ttCWAdmin -shutdownをコールする前にttDaemonAdmin -stopをコールしないでください。
Oracle Clusterwareと統合されたTimesTenでは、このような操作は、ttCWAdminユーティリティおよびcluster.oracle.iniファイル内の属性によって行われます。
組込みやユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』を参照してください。SQL文の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』を参照してください。
cluster.oracle.iniという初期化ファイルを作成します。このファイルの情報は、TimesTenデータベース、TimesTenプロセス、ユーザー・アプリケーションおよび仮想IPアドレスを管理するOracle Clusterwareリソースの作成に使用されます。
ユーザーはcluster.oracle.iniファイルをテキスト・ファイルとして作成し、アクティブ・データベースのホスト上のデーモンのホーム・ディレクトリに配置します。デフォルトでは、このディレクトリは次のとおりです。
LinuxおよびUNIXの場合は、install_dir/infoディレクトリ
Windowsの場合は、c:\TimesTen\install_dir\srv\infoディレクトリ
cluster.oracle.iniファイルで使用できるすべての属性については、第8章「Oracle ClusterwareのTimesTen構成属性」を参照してください。
cluster.oracle.iniファイルのエントリ名は、次に示す既存のDSNと同じである必要があります。
LinuxまたはUNIXの場合は、sys.odbc.ini内
Windowsの場合は、システムDSN内
たとえば、「基本的な可用性の構成」で説明されているcluster.oracle.iniファイルの[basicDSN]が、sys.odbc.iniファイル内に存在する必要があります。
エントリ名およびDSNは、データベース・ファイル名と同じである必要があります。データベース・ファイル名については、「データベースのDSNの定義」を参照してください。
この項では、次の構成用のcluster.oracle.iniファイルの例を示します。
この例では、サブスクライバを持たないアクティブ・スタンバイ・ペアを示します。アクティブ・データベースおよびスタンバイ・データベースのホストは、それぞれhost1およびhost2です。ホストのリストはカンマで区切ります。必要に応じて、読みやすくするために空白を含めることができます。
ttCWAdminユーティリティを使用して、Oracle Clusterwareで管理されているクラスタ内のTimesTenアクティブ・スタンバイ・ペアを管理します。
[basicDSN] MasterHosts=host1,host2
この例では、host3にある、1つのサブスクライバを持つアクティブ・スタンバイ・ペアのcluster.oracle.iniファイルを示します。
[basicSubscriberDSN] MasterHosts=host1,host2 SubscriberHosts=host3
この例では、アクティブ・データベースおよびスタンバイ・データベースのホストは、それぞれhost1およびhost2です。host3およびhost4は、フェイルオーバーに使用できる追加のノードです。サブスクライバ・ノードはありません。MasterVIPは、マスター・データベースに対して定義されている仮想IPアドレスを指定します。VIPInterfaceは、パブリック・ネットワーク・アダプタの名前です。VIPNetMaskは、仮想IPアドレスのネットマスクを定義します。
[advancedDSN] MasterHosts=host1,host2,host3,host4 MasterVIP=192.168.1.1, 192.168.1.2 VIPInterface=eth0 VIPNetMask=255.255.255.0
この例では、host4上の1つのサブスクライバを示します。マスター・データベースのフェイルオーバーに使用できる追加のノードが1つと、サブスクライバ・データベースのフェイルオーバーに使用できる追加のノードが1つあります。MasterVIPおよびSubscriberVIPは、マスター・データベースおよびサブスクライバ・データベースに対して定義されている仮想IPアドレスを指定します。VIPInterfaceは、パブリック・ネットワーク・アダプタの名前です。VIPNetMaskは、仮想IPアドレスのネットマスクを定義します。
[advancedSubscriberDSN] MasterHosts=host1,host2,host3 SubscriberHosts=host4,host5 MasterVIP=192.168.1.1, 192.168.1.2 SubscriberVIP=192.168.1.3 VIPInterface=eth0 VIPNetMask=255.255.255.0
追加のノードが次のようになっていることを確認します。
TimesTenがインストールされている。
ダイレクト・リンクのアプリケーションがインストールされている（構成の一部である場合）。「アプリケーション・フェイルオーバーの実装」を参照してください。
アクティブ・スタンバイ・ペアが1つ以上のAWTまたは読取り専用キャッシュ・グループをレプリケートする場合、CacheConnect属性をyに設定します。
この例では、高度な可用性構成で1つのサブスクライバを持つアクティブ・スタンバイ・ペアを指定します。アクティブ・スタンバイ・ペアによって、1つ以上のキャッシュ・グループがレプリケートされます。
[advancedCacheDSN] MasterHosts=host1,host2,host3 SubscriberHosts=host4, host5 MasterVIP=192.168.1.1, 192.168.1.2 SubscriberVIP=192.168.1.3 VIPInterface=eth0 VIPNetMask=255.255.255.0 CacheConnect=y
アクティブ・スタンバイ・ペアがキャッシュ・グリッドのメンバーになっている場合、GridPort属性を設定して、アクティブ・データベースとスタンバイ・データベースにポート番号を割り当てます。
この例では、高度な可用性構成でサブスクライバを持たないアクティブ・スタンバイ・ペアを指定します。そのアクティブ・スタンバイ・ペアは、キャッシュ・グリッドのメンバーになっています。
[advancedGridDSN] MasterHosts=host1,host2,host3 MasterVIP=192.168.1.1, 192.168.1.2 VIPInterface=eth0 VIPNetMask=255.255.255.0 CacheConnect=y GridPort=16101, 16102
Oracle Clusterwareと統合されたTimesTenでは、アクティブ・スタンバイ・ペアの任意のデータベースにリンクされたアプリケーションのフェイルオーバーを簡素化できます。ダイレクト・リンクのアプリケーションと、Oracle ClusterwareおよびTimesTenと同じマシンにあるクライアント/サーバー・アプリケーションの両方を管理できます。
アプリケーションのフェイルオーバーに必要なcluster.oracle.iniファイルの属性は、次のとおりです。
AppName: Oracle Clusterwareで管理されるアプリケーションの名前。
AppStartCmd: アプリケーションを起動するコマンドライン。
AppStopCmd: アプリケーションを停止するコマンドライン。
AppCheckCmd: AppNameで指定されたアプリケーションのステータスを確認するアプリケーションを実行するためのコマンドライン。
AppType: アプリケーションのリンク先となるデータベースを定義します。使用可能な値は、Active、Standby、Subscriber（すべて）およびSubscriber[index]です。
オプションとして、AppFailureThreshold、AppFailoverDelayおよびAppScriptTimeoutを設定することもできます。これらの属性にはデフォルト値があります。
TimesTenアプリケーション・モニター・プロセスは、ユーザー指定のスクリプトまたはAppCheckCmdで指定されたプログラムを使用して、アプリケーションを監視します。アプリケーションのステータスを確認するスクリプトは、成功の場合は0を返し、失敗の場合は0以外を返すように記述されている必要があります。0（ゼロ）以外の値が検出されると、Oracle Clusterwareは、障害が発生したアプリケーションをリカバリするためのアクションを実行します。
この例では、サブスクライバを持たないアクティブ・スタンバイ・ペアに対して構成されている高度な可用性を示します。readerアプリケーションは、スタンバイ・データベースのデータを問い合せるアプリケーションです。
[appDSN] MasterHosts=host1,host2,host3,host4 MasterVIP=192.168.1.1, 192.168.1.2 VIPInterface=eth0 VIPNetMask=255.255.255.0 AppName=reader AppType=Standby AppStartCmd=/mycluster/reader/app_start.sh AppStopCmd=/mycluster/reader/app_stop.sh AppCheckCmd=/mycluster/reader/app_check.sh
AppStartCmd、AppStopCmdおよびAppCheckCmdには引数を含めることができます。たとえば、Windows上の有効なcluster.oracle.iniファイルについて考えてみます。この例では、アプリケーションは、アクティブ・データベースに直接リンクされています。アプリケーションを起動、停止および確認するスクリプトでは、DSNおよび実行するアクションの引数（-start、-stopおよび-check）を取ります。
AppStartCmd、AppStopCmdおよびAppCheckCmdに指定されたパスを囲む二重引用符に注意してください。引用符が必要な理由は、パスに空白が使用されているためです。
[appWinDSN] MasterHosts=host1,host2,host3,host4 MasterVIP=192.168.1.1, 192.168.1.2 VIPInterface=Local Area Connection VIPNetMask=255.255.255.0 AppName=UpdateApp AppType=Active AppStartCmd="C:\Program Files\UserApps\UpdateApp.exe" -dsn myDSN -start AppStopCmd= "C:\Program Files\UserApps\UpdateApp.exe" -dsn myDSN -stop AppCheckCmd="C:\Program Files\UserApps\UpdateApp.exe" -dsn myDSN -check
2つ以上のアプリケーションのフェイルオーバーを構成できます。AppNameを使用してアプリケーションを指定し、AppName属性のすぐ後に続くAppType、AppStartCmd、AppStopCmdおよびAppCheckCmdの値を指定します。読みやすくするために空白行を含めることができます。次に例を示します。
[app2DSN] MasterHosts=host1,host2,host3,host4 MasterVIP=192.168.1.1, 192.168.1.2 VIPInterface=eth0 VIPNetMask=255.255.255.0 AppName=reader AppType=Standby AppStartCmd=/mycluster/reader/app_start.sh AppStopCmd=/mycluster/reader/app_stop.sh AppCheckCmd=/mycluster/reader/app_check.sh AppName=update AppType=Active AppStartCmd=/mycluster/update/app2_start.sh AppStopCmd=/mycluster/update/app2_stop.sh AppCheckCmd=/mycluster/update/app2_check.sh
両方のマスター・ノードに障害が発生し、その後復旧した場合、Oracle Clusterwareは、自動的にマスター・データベースをリカバリできます。一時的な二重の障害から自動リカバリするには、次の条件が満たされている必要があります。
アクティブ・スタンバイ・ペアにRETURN TWOSAFEが指定されていない。
AutoRecoverがyに設定されている。
RepBackupDirが共有記憶域のディレクトリを指定している。
RepBackupPeriodが0より大きい値に設定されている。
両方のマスター・ノードに永続的な障害が発生した場合、Oracle Clusterwareは、自動的にマスター・データベースを2つの新しいノードにリカバリできます。次の条件が満たされている必要があります。
高度な可用性（仮想IPアドレスおよび少なくとも4つのホスト）が構成されている。
アクティブ・スタンバイ・ペアがキャッシュ・グループをレプリケートしていない。
キャッシュ・グリッドが構成されていない。
RETURN TWOSAFEが指定されていない。
AutoRecoverがyに設定されている。
RepBackupDirが共有記憶域のディレクトリを指定している。
RepBackupPeriodが0より大きい値に設定されている。
TimesTenは最初にアクティブ・データベースの全体バックアップを実行し、次に増分バックアップを実行します。オプションの属性RepfullbackupCycleを指定すると、TimesTenがその後の全体バックアップを実行するタイミングを管理できます。デフォルトでは、TimesTenは、増分バックアップを5回実行するたびに完全バックアップを1回実行します。
RepBackupDirおよびRepBackupPeriodをバックアップに構成している場合、TimesTenは、アクティブになるすべてのマスター・データベースのバックアップを実行します。データベースが再度アクティブにならないかぎり、アクティブからスタンバイになったデータベースに対して実行されたバックアップは削除されません。2つのデータベースの完全バックアップに十分な領域が共有記憶域にあることを確認します。ttCWAdmin -restoreによって、正しいバックアップ・ファイルが自動的に選択されます。
増分バックアップでは、トランザクション・ログ・ファイルのログ・レコードの量が増えます。RepBackupPeriodおよびRepfullbackupCycleの値を十分に小さくし、トランザクション・ログ・ファイルのログ・レコードが大量にならないようにします。バックアップおよびログ・レコードの相互作用の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttBackupユーティリティに関する説明を参照してください。
[autorecoveryDSN]
MasterHosts=host1,host2,host3,host4
MasterVIP=192.168.1.1, 192.168.1.2
VIPInterface=eth0
VIPNetMask=255.255.255.0
AutoRecover=y
RepBackupDir=/shared_drive/dsbackup
RepBackupPeriod=3600
アクティブ・スタンバイ・ペアにキャッシュ・グループがある場合、または両方のマスター・ホストの障害から手動でリカバリする場合は、AutoRecoverがn（デフォルト）に設定されていることを確認します。手動リカバリには次が必要です。
RepBackupDirが共有記憶域のディレクトリを指定している
RepBackupPeriodが0より大きい値に設定されている
この例では、手動リカバリの属性設定を示します。AutoRecoverのデフォルト値はnであるため、このファイルには含まれていません。
[manrecoveryDSN]
MasterHosts=host1,host2,host3
MasterVIP=192.168.1.1, 192.168.1.2
VIPInterface=eth0
VIPNetMask=255.255.255.0
RepBackupDir=/shared_drive/dsbackup
RepBackupPeriod=3600
RepDDL属性は、アクティブ・スタンバイ・ペアを作成するSQL文を表します。RepDDL属性はオプションです。これは、アクティブ・スタンバイ・ペアから表、キャッシュ・グループおよび順序を除外する場合に使用できます。
RepDDLをcluster.oracle.iniファイルに含める場合は、ReturnServiceAttribute、MasterStoreAttributeまたはSubscriberStoreAttributeをcluster.oracle.iniファイルに指定しないでください。これらのレプリケーション設定は、RepDDL属性に含めるようにしてください。
RepDDLの値を指定する場合、データベース・ファイル名の接頭辞に<DSN>マクロを使用します。マスター・ホスト名を指定するには、<MASTERHOST[1]>および<MASTERHOST[2]>マクロを使用します。TimesTenは、構成で仮想IPアドレスが使用されているかどうに応じて、MasterHostsまたはMasterVIP属性の正しい値に置換します。同様に、サブスクライバ・ホスト名を指定するには、<SUBSCRIBERHOST[n]>マクロを使用します。ここで、nは、1からSubscriberHosts属性値の合計数までの数値、仮想IPアドレスが使用されている場合は1からSubscriberVIP属性値の合計数までの数値です。
RepDDL属性を使用して、アクティブ・スタンバイ・ペアから表、キャッシュ・グループおよび順序を除外します。
[excludeDSN] MasterHosts=host1,host2,host3,host4 SubscriberHosts=host5,host6 MasterVIP=192.168.1.1, 192.168.1.2 SubscriberVIP=192.168.1.3 VIPInterface=eth0 VIPNetMask=255.255.255.0 RepDDL=CREATE ACTIVE STANDBY PAIR \ <DSN> ON <MASTERHOST[1]>, <DSN> ON <MASTERHOST[2]> SUBSCRIBER <DSN> ON <SUBSCRIBERHOST[1]>\ EXCLUDE TABLE pat.salaries, \ EXCLUDE CACHE GROUP terry.salupdate, \ EXCLUDE SEQUENCE ttuser.empcount
レプリケーション・エージェントのトランスミッタは、次の方法でルート情報を取得します（優先順に示します）。
RepDDL設定のROUTE句から（ROUTE句が指定されている場合）。高度な可用性を構成している場合は、ROUTE句を指定しないでください。
Oracle Clusterwareから。Oracle Clusterwareは、ローカル・ホストとリモート・ホストのプライベート・ホスト名およびパブリック・ホスト名を提供するとともに、リモート・デーモンのポート番号を提供します。プライベート・ホスト名は、パブリック・ホスト名より優先されます。レプリケーション・エージェントのトランスミッタはIPCソケットに接続できないため、Oracle Clusterwareがレプリケーション・スキームに関して保持している情報を使用してリモート・デーモンへの接続を試行します。
アクティブ・ホストおよびスタンバイ・ホストから。失敗した場合、レプリケーション・エージェントはホスト名に基づいた接続方法を選択します。
この例では、RepDDLにROUTE句を指定します。
[routeDSN] MasterHosts=host1,host2,host3,host4 RepDDL=CREATE ACTIVE STANDBY PAIR \ <DSN> ON <MASTERHOST[1]>, <DSN> ON <MASTERHOST[2]>\ ROUTE MASTER <DSN> ON <MASTERHOST[1]> SUBSCRIBER <DSN> ON <MASTERHOST[2]>\ MASTERIP "192.168.1.2" PRIORITY 1\ SUBSCRIBERIP "192.168.1.3" PRIORITY 1\ MASTERIP "10.0.0.1" PRIORITY 2\ SUBSCRIBERIP "10.0.0.2" PRIORITY 2\ MASTERIP "140.87.11.203" PRIORITY 3\ SUBSCRIBERIP "140.87.11.204" PRIORITY 3\ ROUTE MASTER <DSN> ON <MASTERHOST[2]> SUBSCRIBER <DSN> ON <MASTERHOST[1]>\ MASTERIP "192.168.1.3" PRIORITY 1\ SUBSCRIBERIP "192.168.1.2" PRIORITY 1\ MASTERIP "10.0.0.2" PRIORITY 2\ SUBSCRIBERIP "10.0.0.1" PRIORITY 2\ MASTERIP "140.87.11.204" PRIORITY 3\ SUBSCRIBERIP "140.87.11.203" PRIORITY 3\
クラスタを作成および初期化するには、次の手順を実行します。
クラスタで複数のアクティブ・スタンバイ・ペアを使用する予定の場合は、「クラスタへの複数のアクティブ・スタンバイ・ペアの挿入」を参照してください。
リモート障害時リカバリ・サブスクライバを構成する場合は、「障害時リカバリ・サブスクライバの構成」を参照してください。
Oracle Clusterwareをインストールします。デフォルトでは、すべてのホストで同時にインストールが実行されます。ご使用のプラットフォーム用のOracle Clusterwareのインストール・ドキュメントを参照してください。
インストールが正常に完了すると、Oracle Clusterwareは自動的に起動します。
TimesTenをクラスタ内の各ホスト（追加のホストを含む）の同じ場所にインストールします。
LinuxおよびUNIXの場合は、インストーラによって次の値が要求されます。
TimesTenクラスタ・エージェントに関連付けられているTCP/IPポート番号。各ノードで異なるポート番号を使用できます。ポート番号を指定しない場合、TimesTenでは、デフォルトのTimesTenポートが使用されます。
Oracle Clusterwareの場所。すべてのノードで同じ場所である必要があります。
スペア・ホストを含むクラスタ内のホスト（ホスト名はカンマで区切ります）。すべてのノードで同じリストである必要があります。
LinuxおよびUNIXプラットフォームの場合、インストーラでは、これらの値を使用してttcrsagent.optionsファイルが作成されます。詳細は、『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のTimesTenのインストールに関する説明を参照してください。インストール後にttmodinstall -crsを使用してファイルを作成することもできます。Linuxの場合、必要に応じて、setup.shに-recordおよび-batchオプションを使用して、追加のホストに同じインストールを実行することもできます。
Windowsの場合、インストール後に各ノードでttmodinstall -crsを実行し、ttcrsagent.optionsファイルを作成します。
ttmodinstallの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttmodinstallに関する説明を参照してください。
TimesTenクラスタ情報は、Oracle Cluster Registryに保存されます。UNIXまたはLinuxプラットフォームのrootユーザー、またはWindowsのインスタンス管理者として、次のコマンドを入力します。
ttCWAdmin -ocrConfig
Oracle ClusterwareおよびTimesTenがホストにインストールされている場合、この手順を繰り返す必要はありません。
ttCWAdmin -initコマンドをホストの1つで実行して、TimesTenクラスタ・エージェントを起動します。次に例を示します。
ttCWAdmin -init
TimesTenクラスタ・エージェントが起動すると、Oracle ClusterwareによってTimesTenデーモンの監視が開始され、障害が発生すると再起動されます。
アクティブ・データベースを配置するホストにデータベースを作成します。DSNはデータベース・ファイル名と同じである必要があります。
表、AWTキャッシュ・グループおよび読取り専用キャッシュ・グループなどのスキーマ・オブジェクトを作成します。キャッシュ・グループはロードしないでください。
アクティブ・データベースを配置するホストのsys.odbc.iniファイルと同じsys.odbc.iniファイルを、クラスタに含めるすべてのホストで作成します。
アクティブ・データベースを配置するホストで、cluster.oracle.iniファイルを作成します。内容と場所の詳細は、「cluster.oracle.iniファイル」を参照してください。
高度な可用性を実現するには、クラスタ内の任意のホストでttCWAdmin -createVIPsコマンドを実行します。UNIXの場合は、このコマンドをrootユーザーとして実行する必要があります。次に例を示します。
ttCWAdmin -createVIPs -dsn myDSN
ttCWAdmin -createコマンドを任意のホストで実行し、アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。次に例を示します。
ttCWAdmin -create -dsn myDSN
アクティブ・データベースを配置するホストを選択するように要求されます。
このコマンドによって、暗号化パスフレーズが要求されます。この暗号化パスフレーズをユーザーが再度必要とすることはありません。また、ADMIN権限を持つ内部ユーザーのユーザーIDおよびパスワードがsys.odbc.iniファイルに見付からない場合は、これらの情報も要求されます。この内部ユーザーは、アクティブ・スタンバイ・ペアを作成するために使用されます。
CacheConnectが有効な場合は、コマンドによって、Oracle Databaseのユーザー・パスワードが要求されます。Oracleパスワードは、キャッシュ・グループの自動リフレッシュ状態を設定するために使用されます。
ttCWAdmin -startコマンドを任意のホストで実行し、アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。次に例を示します。
ttCWAdmin -start -dsn myDSN
アクティブ・スタンバイ・ペアにキャッシュ・グループが含まれている場合、LOAD CACHE GROUP文を使用し、Oracle表からキャッシュ・グループをロードします。
Oracle Clusterwareを使用してクラスタ内の複数のアクティブ・スタンバイ・ペアを管理する場合、cluster.oracle.iniファイルに追加の構成を含めます。たとえば、このcluster.oracle.iniファイルには、2つのアクティブ・スタンバイ・ペアのレプリケーション・スキームの構成情報が含まれています。
[advancedSubscriberDSN] MasterHosts=host1,host2,host3 SubscriberHosts=host4, host5 MasterVIP=192.168.1.1, 192.168.1.2 SubscriberVIP=192.168.1.3 VIPInterface=eth0 VIPNetMask=255.255.255.0 [advSub2DSN] MasterHosts=host1,host2,host3 SubscriberHosts=host4, host5 MasterVIP=192.168.1.4, 192.168.1.5 SubscriberVIP=192.168.1.6 VIPInterface=eth0 VIPNetMask=255.255.255.0
追加のレプリケーション・スキームに対して次の手順を実行します。
データベースを作成および移入します。
仮想IPアドレスを作成します。ttCWAdmin -createVIPsコマンドを使用します。
アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。ttCWAdmin -createコマンドを使用します。
アクティブ・スタンバイ・ペアを開始します。ttCWAdmin -startコマンドを使用します。
プライマリ・サイトにリモート障害時リカバリ・サブスクライバを持つアクティブ・スタンバイ・ペアを作成できます。「アクティブ・スタンバイ・ペアでの障害時リカバリ・サブスクライバの使用」を参照してください。Oracle Clusterwareは、アクティブ・スタンバイ・ペアは管理しますが、障害時リカバリ・サブスクライバは管理しません。プライマリ・サイトに障害が発生した場合、ユーザーが切替えを実行する必要があります。
Oracle Clusterwareを使用してリモート障害時リカバリ・サブスクライバを持つアクティブ・スタンバイ・ペアを管理するには、次の手順を実行します。
RepDDLまたはRemoteSubscriberHosts Clusterware属性を使用し、リモート障害時リカバリ・サブスクライバに関する情報を提供します。次に例を示します。
[advancedDRsubDSN] MasterHosts=host1,host2,host3 SubscriberHosts=host4, host5 RemoteSubscriberHosts=host6 MasterVIP=192.168.1.1, 192.168.1.2 SubscriberVIP=192.168.1.3 VIPInterface=eth0 VIPNetMask=255.255.255.0 CacheConnect=y
ttCWAdmin -createを使用し、プライマリ・サイトにアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。この操作では障害時リカバリ・サブスクライバは作成されません。
ttCWAdmin -startを使用し、アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
アクティブ・スタンバイ・ペアによってレプリケートされるキャッシュ・グループをロードします。
「障害時リカバリ・サブスクライバのローリング・アウト」の手順に従って、障害時リカバリ・サブスクライバを設定します。
Oracle Clusterwareは、様々な種類の障害から自動的にリカバリできます。この項では、いくつかの障害例およびOracle Clusterwareで障害を管理する方法について説明します。
この項の内容は次のとおりです。
アクティブ・データベースが存在するノードで障害が発生した場合、Oracle Clusterwareでは、スタンバイ・データベースの状態が自動的にACTIVEに変更されます。アプリケーション・フェイルオーバーが構成されている場合は、アプリケーションによって新しいアクティブ・データベースの更新が開始されます。
図7-2では、スタンバイ・データベースの状態がACTIVEに変更され、アプリケーションによって新しいアクティブ・データベースが更新されています。
Oracle Clusterwareによって、障害が発生したデータベースまたはホストの再起動が試行されます。成功すると、そのデータベースがスタンバイ・データベースになります。
図7-3に、前のアクティブ・ノードがスタンバイ・ノードになったクラスタを示します。
前のアクティブ・ノードの障害が永続的であり、高度な可用性が構成されている場合は、追加のノードの1つでスタンバイ・データベースが起動されます。
図7-4に、追加のノードの1つでスタンバイ・データベースが起動されたクラスタを示します。
スタンバイ・ノードで障害が発生した場合、Oracle Clusterwareによって、まず、そのデータベースまたはホストの再起動が試行されます。スタンバイ・データベースを同じホストで再起動できず、高度な可用性が構成されている場合は、追加のノードでスタンバイ・データベースが起動されます。
図7-5は、障害後の新しいホストのスタンバイ・データベースを示します。
サブスクライバ・ノードで障害が発生した場合、Oracle Clusterwareによって、まず、そのデータベースまたはホストの再起動が試行されます。データベースを同じホストで再起動できず、高度な可用性が構成されている場合は、追加のノードでサブスクライバ・データベースが起動されます。
この項の内容は次のとおりです。
Oracle Clusterwareでは、次のような場合に、両方のマスター・ノードで一時的な障害が発生し、その後ノードが復旧した後に自動リカバリを実行できます。
アクティブ・スタンバイ・ペアにRETURN TWOSAFEが指定されていない。
AutoRecoverがyに設定されている。
RepBackupDirが共有記憶域のディレクトリを指定している。
RepBackupPeriodが0より大きい値に設定されている。
Oracle Clusterwareでは、次のような場合に、両方のマスター・ノードで発生した永続的な障害からの自動リカバリを実行できます。
高度な可用性（仮想IPアドレスおよび少なくとも4つのホスト）が構成されている。
アクティブ・スタンバイ・ペアがキャッシュ・グループをレプリケートしていない。
キャッシュ・グリッドが構成されていない。
アクティブ・スタンバイ・ペアにRETURN TWOSAFEが指定されていない。
AutoRecoverがyに設定されている。
RepBackupDirが共有記憶域のディレクトリを指定している。
RepBackupPeriodが0より大きい値に設定されている。
cluster.oracle.iniファイルの例は、「両方のマスター・ノードの永続的な障害からのリカバリ」を参照してください。
この項では、障害が発生したマスター・ノードが、TimesTenおよびOracle Clusterwareがインストールされている新しいホストにリカバリされることを想定しています。次の手順では、例としてmanrecoveryDSNデータベースおよびcluster.oracle.iniファイルを使用します。
高度な可用性構成で手動リカバリを実行するには、次の手順を実行します。
TimesTenクラスタ・エージェントがローカル・ホストで実行されていることを確認します。
ttCWAdmin -init -hosts localhost
バックアップ・データベースをリストアします。リストアするデータベースと同じDSNを持つデータベースがホストにないことを確認します。
ttCWAdmin -restore -dsn manrecoveryDSN
データベースにキャッシュ・グループがある場合、そのキャッシュ・グループを削除して再度作成します。
新しいホストがcluster.oracle.iniファイルのMasterHostsおよびSubscriberHostsで指定されていない場合、新しいホストが含まれるようにファイルを変更します。
この手順では、manrecoveryDSNを使用します。cluster.oracle.iniファイルにはすでに追加のホストが指定されているため、manrecoveryDSNにはこの手順は必要はありません。
アクティブ・スタンバイ・ペアのレプリケーション・スキームを再度作成します。
ttCWAdmin -create -dsn manrecoveryDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn manrecoveryDSN
この項では、障害が発生したマスター・ノードが、TimesTenおよびOracle Clusterwareがインストールされている新しいホストにリカバリされることを想定しています。次の手順では、例としてbasicDSNデータベースおよびcluster.oracle.iniファイルを使用します。
基本的な可用性構成で手動リカバリを実行するには、次の手順を実行します。
アクティブ・スタンバイ・ペアのデータベース用に新しいホストを取得します。
TimesTenクラスタ・エージェントがローカル・ホストで実行されていることを確認します。
ttCWAdmin -init -hosts localhost
バックアップ・データベースをリストアします。リストアするデータベースと同じDSNを持つデータベースがホストにないことを確認します。
ttCWADmin -restore -dsn basicDSN
データベースにキャッシュ・グループがある場合、そのキャッシュ・グループを削除して再度作成します。
cluster.oracle.iniファイルのMasterHostsおよびSubscriberHostsエントリを更新します。この例では、basicDSNデータベースを使用します。MasterHostsエントリはhost1からhost10に変更されます。SubscriberHostsエントリはhost2からhost20に変更されます。
[basicDSN] MasterHosts=host10,host20
アクティブ・スタンバイ・ペアのレプリケーション・スキームを再度作成します。
ttCWAdmin -create -dsn basicDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn basicDSN
両方のマスター・ノードで障害が発生し、データベースが破損する場合があります。同じマスター・ノードにリカバリするには、次の手順を実行します。
レプリケーション・エージェントおよびキャッシュ・エージェントが停止し、アプリケーションが両方のデータベースから切断されていることを確認します。この例では、basicDSNデータベースを使用します。
ttCWAdmin -stop -dsn basicDSN
ttDestroyユーティリティを使用し、新しいアクティブ・データベースを配置するノードでデータベースを破棄します。
ttDestroy basicDSN
バックアップ・データベースをリストアします。
ttCWADmin -restore -dsn basicDSN
データベースにキャッシュ・グループがある場合、そのキャッシュ・グループを削除して再度作成します。
アクティブ・スタンバイ・ペアのレプリケーション・スキームを再度作成します。
ttCWAdmin -create -dsn basicDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn basicDSN
cluster.oracle.iniファイルでReturnServiceAttribute Clusterware属性を使用し、RETURNサービスRETURN TWOSAFEを利用できるようにアクティブ・スタンバイ・ペアを構成できます。RETURN TWOSAFEが構成されている場合、両方のノードで障害が発生した後、いずれかまたは両方のノードでデータベース・ログを利用できることがあります。ただし、RETURN TWOSAFEは、レプリケーションを自動的に再起動したり、アプリケーションを自動的に再接続できるように設計されていません。まず、データベース・ログからアクティブ・スタンバイ・ペアを再度作成するか、バックアップからデータベースをリストアしておく必要があります。
次のcluster.oracle.iniの例では、データベース・ログを利用できなかった場合のバックアップ構成を示します。
[basicTwosafeDSN]
MasterHosts=host1,host2
ReturnServiceAttribute=RETURN TWOSAFE
RepBackupDir=/shared_drive/dsbackup
RepBackupPeriod=3600
次のリカバリ手順を実行します。
レプリケーション・エージェントおよびキャッシュ・エージェントが停止し、アプリケーションが両方のデータベースから切断されていることを確認します。
ttCWAdmin -stop -dsn basicTwosafeDSN
アクティブ・スタンバイ・ペアを削除します。
ttCWAdmin -drop -dsn basicTwosafeDSN
前のアクティブ・データベースまたはスタンバイ・データベースのどちらがより新しいかを判断し、新しい方のデータベースを使用してアクティブ・スタンバイ・ペアを再度作成します。アクティブ・データベースを配置するホストを選択するように要求されます。
ttCWAdmin -create -dsn basicTwosafeDSN
どちらのデータベースも使用できない場合、バックアップからデータベースをリストアします。
ttCWAdmin -restore -dsn basicTwosafeDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn basicTwosafeDSN
二重のホスト障害のより極端なケースとして、3つ以上のマスター・ホストの障害対応について説明します。次のガイドラインを使用します。
停電やネットワーク障害などの場合は、障害の根本原因に対処します。
アクティブ・データベースおよびスタンバイ・データベース用の少なくとも2つの正常なホストを識別または取得します。
cluster.oracle.iniファイルのMasterHostsおよびSubscriberHostsエントリを更新します。
その後実行するアクションのガイドラインは、「高度な可用性の場合の手動リカバリ」および「基本的な可用性の場合の手動リカバリ」を参照してください。
この項の内容は次のとおりです。
アクティブ・スタンバイのスキーマ変更には、次のアクションが含まれます。
サブスクライバ・データベースを追加または削除します。
データベース属性を変更します。サブスクライバには、PORTおよびTIMEOUT属性のみを設定できます。
アクティブ・スタンバイ・ペアのレプリケーション・スキームに表、順序またはキャッシュ・グループを含めます。
アクティブ・スタンバイ・ペアのレプリケーション・スキームから表、順序またはキャッシュ・グループを除外します。
アクティブ・スタンバイ・ペアのスキーマを変更するには、次のタスクを実行します。
アクティブ・スタンバイ・ペアのデータベースでレプリケーション・エージェントを停止します。これらのコマンドでは、例としてadvancedCacheDSNを使用します。
ttCWAdmin -stop -dsn advancedCacheDSN
アクティブ・スタンバイ・ペアを削除します。
ttCWAdmin -drop -dsn advancedCacheDSN
必要に応じて、スキーマを変更します。
アクティブ・スタンバイ・ペアのレプリケーション・スキームを再度作成します。
ttCWAdmin -create -dsn advancedCacheDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn advancedCacheDSN
TimesTenをアップグレードするには、次の手順を実行します。
アクティブ・スタンバイ・ペアのデータベースでレプリケーション・エージェントを停止します。
ttCWAdmin -stop -dsn advancedDSN
アクティブ・スタンバイ・ペアを削除します。
ttCWAdmin -drop -dsn advancedDSN
ホストでTimesTenクラスタ・エージェントを停止します。これにより、クラスタからホストが削除され、TimesTenデーモンが停止されます。
ttCWAdmin -shutdown -hosts localhost
目的のホストでTimesTenをアップグレードします。クラスタのすべてのノードに、同じメジャー・リリースのTimesTenが存在する必要があります。メジャー・リリース間でのアップグレードの場合は、ttMigrateユーティリティを使用します。『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のデータベースのアップグレードに関する説明を参照してください。
TimesTenクラスタ・エージェントを起動します。これにより、クラスタにホストが追加され、TimesTenデーモンが起動されます。
ttCWAdmin -init
アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。
ttCWAdmin -create -dsn advancedDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn advancedDSN
アクティブ・スタンバイ・ペアに読取り専用サブスクライバを追加するには、次の手順を実行します。
すべてのデータベースでレプリケーション・エージェントを停止します。この例では、advancedSubscriberDSNを使用します。これにはすでにサブスクライバが含まれており、高度な可用性が構成されています。
ttCWAdmin -stop -dsn advancedSubscriberDSN
アクティブ・スタンバイ・ペアを削除します。
ttCWAdmin -drop -dsn advancedSubscriberDSN
cluster.oracle.iniファイルを変更します。
SubscriberHosts属性にサブスクライバを追加します。
クラスタが高度な可用性用に構成されている場合、仮想IPアドレスをSubscriberVIP属性に追加します。
これらの属性を使用する例については、「高度な可用性の構成」を参照してください。
アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。
ttCWAdmin -create -dsn advancedSubscriberDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn advancedSubscriberDSN
アクティブ・スタンバイ・ペアから読取り専用サブスクライバを削除するには、次の手順を実行します。
すべてのデータベースでレプリケーション・エージェントを停止します。この例では、advancedSubscriberDSNを使用します。これにはサブスクライバが含まれており、高度な可用性が構成されています。
ttCWAdmin -stop -dsn advancedSubscriberDSN
アクティブ・スタンバイ・ペアを削除します。
ttCWAdmin -drop -dsn advancedSubscriberDSN
cluster.oracle.iniファイルを変更します。
SubscriberHosts属性からサブスクライバを削除するか、アクティブ・スタンバイ・ペアにサブスクライバが残っていない場合は属性全体を削除します。
SubscriberVIP属性から仮想IPアドレスを削除するか、アクティブ・スタンバイ・ペアにサブスクライバが残っていない場合は属性全体を削除します。
アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。
ttCWAdmin -create -dsn advancedSubscriberDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn advancedSubscriberDSN
すでにアクティブ・スタンバイ・ペアを管理しているクラスタに（サブスクライバを持つ（または持たない））アクティブ・スタンバイ・ペアを追加するには、次の手順を実行します。
最初にアクティブ・データベースを配置するホストに、データベースを作成して移入を行います。「1つのホストでのTimesTenデータベースの作成および移入」を参照してください。
cluster.oracle.iniファイルを変更します。この例では、advancedSubscriberDSNの構成がすでに含まれたcluster.oracle.iniファイルに、advSub2DSNを追加します。新しいアクティブ・スタンバイ・ペアは、元のアクティブ・スタンバイ・ペアとは異なるホストにあります。
[advancedSubscriberDSN] MasterHosts=host1,host2,host3 SubscriberHosts=host4, host5 MasterVIP=192.168.1.1, 192.168.1.2 SubscriberVIP=192.168.1.3 VIPInterface=eth0 VIPNetMask=255.255.255.0 [advSub2DSN] MasterHosts=host6,host7,host8 SubscriberHosts=host9, host10 MasterVIP=192.168.1.4, 192.168.1.5 SubscriberVIP=192.168.1.6 VIPInterface=eth0 VIPNetMask=255.255.255.0
新しい仮想IPアドレスを作成します。この操作を実行する場合、LinuxおよびUNIXでは、ユーザーはrootであることが必要です。
ttCWAdmin -createVIPs -dsn advSub2DSN
新しいアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。
ttCWAdmin -create -dsn advSub2DSN
新しいアクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn advSub2DSN
（サブスクライバを持つ（または持たない））アクティブ・スタンバイ・ペアをクラスタから削除するには、次の手順を実行します。
アクティブ・スタンバイ・ペアのすべてのデータベースで、レプリケーション・エージェントを停止します。この例では、「クラスタへのアクティブ・スタンバイ・ペアの追加」で追加されたadvSub2DSNを使用します。
ttCWAdmin -stop -dsn advSub2DSN
アクティブ・スタンバイのレプリケーション・スキームを削除します。
ttCWAdmin -drop -dsn advSub2DSN
アクティブ・スタンバイ・ペアの仮想IPアドレスを削除します。
ttCWAdmin -dropVIPs -dsn advSub2DSN
cluster.oracle.iniファイルを変更します（オプション）。advSub2DSNのエントリを削除します。
データベースを破棄する場合、このアクティブ・スタンバイ・ペアの構成に含まれる各ホストにログオンし、ttDestroyユーティリティを使用します。
ttDestroy advSub2DSN
ttDestroyの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDestroyに関する説明を参照してください。
ホストを追加するには、クラスタが高度な可用性用に構成されている必要があります。この項の例では、advancedSubscriberDSNを使用しています。
クラスタに2つのスペア・マスター・ホストを追加するには、次のようなコマンドを入力します。
ttCWAdmin -addMasterHosts -hosts "host8,host9" -dsn advancedSubscriberDSN
クラスタに1つのスペア・サブスクライバ・ホストを追加するには、次のようなコマンドを入力します。
ttCWAdmin -addSubscriberHosts -hosts "subhost1" -dsn advancedSubscriberDSN
ホストをクラスタから削除するには、クラスタが高度な可用性用に構成されている必要があります。マスター・ホストの1つを削除するには、MasterHostsに3つ以上のホストがリストされている必要があります。サブスクライバ・ホストの1つを削除するには、サブスクライバ・データベースの数よりも少なくとも1つ多いホストがSubscriberHostsにリストされている必要があります。
この項の例では、advancedSubscriberDSNを使用しています。
クラスタから2つのスペア・マスター・ホストを削除するには、次のようなコマンドを入力します。
ttCWAdmin -delMasterHosts "host8,host9" -dsn advancedSubscriberDSN
クラスタから1つのスペア・サブスクライバ・ホストを削除するには、次のようなコマンドを入力します。
ttCWAdmin -delSubscriberHosts "subhost1" -dsn advancedSubscriberDSN
フェイルオーバー後、アクティブ・データベースおよびスタンバイ・データベースはフェイルオーバー前とは異なるホストに配置されます。アクティブ・データベースとスタンバイ・データベースの役割を入れ替えるには、オープン・トランザクションが存在しないことを確認してから、ttCWAdminユーティリティの-switchオプションを使用します。オープン・トランザクションが存在する場合、コマンドは失敗します。
次に例を示します。
ttCWAdmin -switch -dsn basicDSN
クラスタが高度な可用性用に構成されている場合、ttCWAdminユーティリティの-relocateオプションを使用して、ローカル・ホストから、cluster.oracle.iniファイルのMasterHosts属性で指定されている次に利用可能なスペア・ホストに、データベースを移動できます。ローカル・ホストのデータベースがアクティブな役割を持っている場合、-relocateオプションでは、まず役割の入替えが行われます。したがって、新しく移行されたアクティブ・データベースはスタンバイに、スタンバイ・データベースはアクティブになります。
-relocateオプションは、ホストをオフラインにする必要がある場合にデータベースを移動するために有効です。このコマンドを使用する前に、オープン・トランザクションが存在しないことを確認してください。
次に例を示します。
ttCWAdmin -relocate -dsn advancedDSN
ホストのオペレーティング・システムまたはハードウェアをアップグレードしたり、ネットワーク・メンテナンスを実行する必要がある場合は、Oracle Clusterwareを停止して自動スタートアップを無効にします。rootまたはOS管理者として、次のOracle Clusterwareコマンドを実行します。
# crsctl stop crs # crsctl disable crs
TimesTenを停止します。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenアプリケーションの停止に関する説明を参照してください。
ホストのメンテナンスを実行します。その後、自動スタートアップを有効にしてOracle Clusterwareを開始します。
# crsctl enable crs # crsctl start crs
これらのコマンドの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
クラスタ内のすべてのホストを停止する必要がある場合、各ホストでOracle Clusterwareを個々に停止します。rootまたはOS管理者として、次のOracle Clusterwareコマンドを実行します。
# crsctl stop crs # crsctl disable crs
TimesTenを停止します。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenアプリケーションの停止に関する説明を参照してください。
メンテナンスを実行します。その後、自動スタートアップを有効にしてOracle Clusterwareを開始します。
# crsctl enable crs # crsctl start crs
これらのコマンドの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
ttCWAdmin -createコマンドでアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成する場合、Oracle Clusterwareによって内部ユーザーのユーザー名およびパスワードの入力が要求されます。また、アクティブ・スタンバイ・ペアにキャッシュ・グループが存在する場合は、キャッシュ管理ユーザー名およびパスワードも保存されます。内部ユーザーまたはキャッシュ管理ユーザーのユーザー名またはパスワードを変更するには、クラスタを再度作成する必要があります。
アクティブ・スタンバイ・ペアのレプリケーションを作成した内部ユーザーのユーザー名またはパスワードを変更したり、キャッシュ管理ユーザー名またはパスワードを変更するには、次の手順を実行します。
アクティブ・スタンバイ・ペアのデータベースでレプリケーション・エージェントを停止します。これらのコマンドでは、例としてadvancedCacheDSNを使用します。
ttCWAdmin -stop -dsn advancedCacheDSN
アクティブ・スタンバイ・ペアを削除します。
ttCWAdmin -drop -dsn advancedCacheDSN
該当するユーザー名またはパスワードを変更します。
内部ユーザー名またはパスワードを変更するには、CREATE USER文またはALTER USER文を使用します。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のデータベースでのユーザーの作成または指定に関する説明を参照してください。
キャッシュ管理ユーザー名またはパスワードを変更するには、ttCacheUidPwdSet組込みプロシージャを使用します。『Oracle In-Memory Database Cacheユーザーズ・ガイド』のキャッシュ管理ユーザー名およびパスワードの設定に関する説明を参照してください。
アクティブ・スタンバイ・ペアのレプリケーション・スキームを再度作成します。
ttCWAdmin -create -dsn advancedCacheDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn advancedCacheDSN
