| Oracle® TimesTen In-Memory Databaseインストレーション・ガイド 11gリリース2 (11.2.2) B66440-07 |
|
 前 |
 次 |
この章では、TimesTenについて、あるリリースから新しいリリースへのアップグレードのプロセスについて説明します。次のトピックが含まれています。
この項では、TimesTenのアップグレード前に考慮するいくつかの事項を説明します。
この項では、特にTimesTen 7.0より前のリリースからのアップグレードにおけるデータ型に関する考慮事項を説明します。この項の内容は次のとおりです。
TimesTenでは、下位互換性のために保持されている元のTimesTenデータ型に加えて、Oracle Databaseデータ型を選択できます。すべてのデータ型の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のデータ型の仕様に関する説明を参照してください。いくつかのOracle Databaseデータ型の名前は、下位互換用のTimesTenデータ型と同じであるため、データ型を示す一連の別名があります。別名がどのデータ型を表すかは、データベースのTypeMode設定によって異なります。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のTypeModeに関する説明を参照してください。
TimesTenの下位互換用のデータ型は、リリース7.0より前のTimesTenデータ型とレプリケーション互換があります。ただし、TimesTenの下位互換用のデータ型は、TimesTen Cacheと互換性がありません。TimesTen CacheではOracle Databaseデータ型のみ使用します。TimesTen Cacheを使用するには、ttMigrate (『Oracle TimesTen In-Memory Databaseリファレンス』を参照)を使用してデータベースを移行する際に、元のTimesTenデータ型をOracle Databaseデータ型に変換する必要があります。詳細は、後述の「Oracle Databaseデータ型へのTimesTenデータ型の変換」を参照してください。
Oracle Databaseデータ型は、リリース7.0より前のTimesTenとレプリケーション互換がありません。7.0より前のTimesTenとのレプリケーションが必要なアップグレードを実行する場合は、元のデータ型をTimesTenデータ型にアップグレードする必要があります。詳細は、「TimesTenデータ型の保持」を参照してください。
TimesTen 7.0より前のリリースからアップグレードを実行する場合、データベースのデータ型をTimesTenデータ型として保持するか、またはOracle Databaseデータ型に変換するかを選択する必要があります。どちらを選択するかは、データベースの使用計画と希望のアップグレード方法によって決まります。
次の項で、それぞれの方法を説明しています。
TimesTen Cacheとともにデータベースを使用する場合は、TimesTenデータ型をOracle Databaseデータ型に変換する必要があります。
TimesTen 7.0より前のリリースからデータ型をOracle Databaseデータ型に変換するには、アップグレード手順の一部としてデータベースをリストアする際に、ttMigrate (『Oracle TimesTen In-Memory Databaseリファレンス』を参照)に-convertTypesToOraオプションを指定する必要があります。たとえば、アップグレード手順の一部としてデータベースsalesdataをリストアする場合は、次のコマンドを使用してデータ型をOracle Databaseデータ型にアップグレードします。
ttMigrate -r -convertTypesToOra salesdata salesdata.mig
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のTimesTenからOracle Databaseデータ型への変換に関する説明を参照してください。
|
注意:
|
レプリケーションを使用してオンライン・アップグレードを実行する場合は、データ型をTimesTenデータ型として保持する必要があります。詳細は、「レプリケーションを使用したオンライン・アップグレード」を参照してください。
TimesTen 7.0より前のリリースのデータベースのデータ型をTimesTenデータ型として保持する場合は、ttMigrateを使用してデータベースをリストアする際に特別なオプションを使用する必要はありません。TimesTen 7.0より前のリリースのデータ型は、自動的にTimesTenデータ型としてリストアされます。
この項では、データベース・キャラクタ・セットに関する考慮事項を説明します。TimesTen 7.0より前のリリースからのアップグレードに関連する考慮事項が含まれます。この項の内容は次のとおりです。
TimesTenでは、データベースの作成時に特定のキャラクタ・セットをサポートするようにデータベースを構成する必要があります。データベースのキャラクタ・セットは、『Oracle TimesTen In-Memory Databaseリファレンス』で説明しているデータベース属性DatabaseCharacterSetを使用して指定します。この属性の値は、キャラクタ・フィールドに対して入出力されるキャラクタと、キャラクタ・データの格納およびソート方法を決定します。詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のデータベースのキャラクタ・セットの選択に関する説明、および『Oracle TimesTen In-Memory Databaseリファレンス』のサポートされているキャラクタ・セットに関する説明を参照してください。
次の点に注意してください。
TimesTen Cacheとともにデータベースを使用する場合、またはttLoadFromOracle組込みプロシージャを使用してOracle DatabaseからTimesTen表を移入する場合は、TimesTenデータベースが接続するOracle Databaseで指定したキャラクタ・セットと同じDatabaseCharacterSetの値を指定する必要があります。
キャラクタ・セットが異なるデータベース間でレプリケーションは実行できません。
TimesTen 7.0より前のリリースからアップグレードする場合は、次の重要な制限事項を考慮してください。
リリース7.0より前のTimesTenで作成されたデータベースには、データベース・キャラクタ・セットが指定されていないため、特別なデータベース・キャラクタ・セット(TIMESTEN8)が作成され、TimesTenの現行のリリースで作成したデータベースと、それより前のリリースで作成したデータベースの間でレプリケーションの互換性が保持されます。レプリケーションを使用したオンライン・アップグレードとしてTimesTenをアップグレードする場合は(「レプリケーションを使用したオンライン・アップグレードの実行」を参照)、DSNでDatabaseCharacterSetとしてTIMESTEN8を指定する必要があります。
TimesTen Client/Serverを使用しており、TimesTen 7.0より前のリリースからアップグレードしたTimesTenインスタンスにある、Client ODBCライブラリとリンクしたアプリケーションを持つデータベースに接続する場合は、互換性を確保するために、DSNにDatabaseCharacterSetとしてTIMESTEN8を指定する必要があります。「クライアント/サーバーのオンライン・アップグレードの実行」を参照してください。
|
注意: TIMESTEN8データベース・キャラクタ・セットは、リリース7.0より前のTimesTenから移行する場合のみ使用します。データベースをリリース7.0より前のTimesTenにレプリケートしたり、7.0より前のクライアント・アプリケーションに接続する必要がない場合は、ttMigrate(『Oracle TimesTen In-Memory Databaseリファレンス』参照)を使用して、データベースをTIMESTEN8以外のデータベース・キャラクタ・セットに変換する必要があります。詳細は、次の項「データベース・キャラクタ・セットの変換」を参照してください。 |
いくつかの場合、アップグレード・プロセスの一部として、構成済のデータベース・キャラクタ・セットを変更する必要があります。データベース・キャラクタ・セットの変更が必要なケースには、次の2つがあります。
データベースのキャラクタ・セットを、最初に指定したものから、より要件に合う新しいものに変更する必要があります。
レプリケーションまたはクライアント/サーバーを使用したオンライン・アップグレードによって、リリース7.0より前のTimesTenをアップグレードするために、データベース・キャラクタ・セットをTIMESTEN8に指定しました。すべてのデータベースとクライアント・アプリケーションでアップグレードが完了したら、この特別な移行用のキャラクタ・セットから、地域で使用する各国のキャラクタ・セットに各データベースを変換する必要があります。
ttMigrateを使用して、任意のキャラクタ・セットから他のキャラクタ・セットにデータベースを変換できます。次の手順を実行します。
ttMigrateを使用して、データベースをファイルに保存します。たとえば、データベースsalesdataをファイルsalesdata.migに保存するには、次のコマンドを使用します。
ttMigrate -c salesdata salesdata.mig
ttDestroyを使用して、データベースを破棄します。
ttDestroy salesdata
データベースのDSN属性値DatabaseCharacterSetを、新しいキャラクタ・セットを指定する値に変更します。たとえば、データベースで、WE8ISO8859P1を使用する場合は、ODBCINIファイルで次の行を使用します。
DatabaseCharacterSet=WE8ISO8859P1
ttMigrateを使用してデータベースをファイルからロードします。TimesTenによって、キャラクタ・データは、ファイルが保存されたキャラクタ・セットから、DSNによって指定されるキャラクタ・セットに自動的に変換されます。
ttMigrate -r salesdata salesdata.mig
|
注意:
|
「データベース・ファイルおよびその他のユーザー・ファイルの場所の考慮事項」に示すとおり、TimesTenのインストール・パスにデータベース・ファイルまたはユーザー・ファイルを保存しないことを強くお薦めします。アップグレードまたはアンインストールの際に削除される場合があります。
ただし、データベースがインストール・ディレクトリの下にない場合は、次の一般的な手順で各データベースを別の場所に移動できます。
ttBackupユーティリティを使用してデータベースをバックアップします。
ttDestroyユーティリティを使用して、データベースを破棄します。
DataStoreおよびLogDir接続属性がインストール・パス以外の場所を参照するように、データベースのDSN定義を更新します。
ttRestoreユーティリティを使用してデータベースを新しい場所にリストアします。
これらのユーティリティおよび属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ユーティリティ」および「接続属性」を参照してください。
「他のディレクトリへのデータベースの移動」も参照してください。
リリース11.2.1以上のTimesTenではアクセス制御は必須です。アクセス制御のない以前のリリースのTimesTenを使用していて、現行のリリースへのアップグレード後に最初にデータベース・オブジェクトを保護しないようにするには、次のSQLコマンドを使用して、PUBLICにADMINシステム権限を付与する必要があります。
GRANT ADMIN TO PUBLIC;
PUBLICにADMIN権限を付与すると、すべてのユーザーがあらゆるデータベース・オブジェクトに対して無制限にアクセス可能になり、インスタンス管理者が実行する必要のあるタスク以外のすべての管理タスクを実行できるようになります。PUBLICへのADMIN権限の付与は、一時的な対処方法として、アップグレードの目的においてのみ行う必要があります。
|
注意: この方法ではシステムが本質的に安全でなくなるため、長期的には使用しないことをお薦めします。 |
ttMigrateユーティリティを使用してレプリケーション・スキームの一部であるデータベースをアップグレードする場合、ttMigrate -cを使用して最初にレプリケーション・スキームを作成したデータベースに、ttMigrate -rを使用してレプリケーション・スキームをリストアする必要があります。移行ファイルを別のデータベースにリストアしようとするとエラーが発生し、レプリケーション・スキームはリストアされません。
実行できるアップグレードの種類(インプレース・アップグレード、オンライン・アップグレードまたはオフライン・アップグレード)は、アップグレードのレベル(メジャーまたはマイナー)およびその他の要素により異なります。メジャー・アップグレードは、異なるTimesTenメジャー・リリース間(11.2.1.x.xから11.2.2.x.xなど)のアップグレードです。一方、同じメジャー・リリースでパッチ・リリースの異なるTimesTenデータベースは、構造的に同等または同じであるため、新しいパッチ・リリースへのアップグレード(11.2.2.6.0から11.2.2.7.0など)は、マイナー・アップグレードとみなされます。
次の各項では、アップグレードの種類について説明します。
マイナー・アップグレードでは、通常は、既存のデータベースの移行が必要になります。UNIXしすてむでは、インプレース・アップグレードを実行できます。
メジャー・アップグレードでは、通常は、状況に応じてオンライン・アップグレードを実行できます。
オフライン・アップグレードが必要となる状況は、オフライン・アップグレードの項で説明します。
|
重要: アップグレードを実行する前に、次の手順を実行する必要があります。
|
リリース11.2.2.6.0からリリース11.2.2.7.0に移行する場合など、TimesTenの新しいパッチ・リリースに移行するために、UNIXシステムでインプレース・アップグレードを使用できます。これらの手順は、Windowsシステムでもアンインストールおよびインストールの手順として実行できます。
インプレース・アップグレードを実行するには、UNIXインストーラのオプションを使用して既存のインスタンスをアップグレードします。古いリリースのアンインストールおよび新しいリリースのインストールは、1つの操作で実行されます。新しいソフトウェアのライブラリおよびバイナリは、これまでと同じ場所にインストールされます。デフォルトの応答を選択すると、既存のデータベースが保持されます(データベースがinstall_dirディレクトリにない場合)。TimesTenのバックアップ・ユーティリティおよび移行ユーティリティを使用する必要はありません。
インプレース・アップグレード時には、すべてのアプリケーションは、アップグレード対象のTimesTenインスタンスにあるデータベースから切断する必要があります。
Windowsシステムでは、最初にTimesTenを削除し、DSNの保持を指定し、次に新しいリリースをインストールする同様の手順を実行して、パッチ・リリース間を移行できます。UNIXでのインプレース・アップグレードと同様、バックアップ・ユーティリティおよび移行ユーティリティを使用する必要はありません。
「インプレース・アップグレードの実行」を参照してください。
|
重要: アップグレードする前に、TimesTenインストール・ディレクトリにデータベースまたは重要なファイルがないことを確認してください。関連情報については、「データベース・ファイルおよびその他のユーザー・ファイルの場所に関する考慮事項」および「既存のデータベース・ファイルの場所」を参照してください。 |
オフライン・アップグレードの実行中は、アプリケーションでデータベースを利用できます。通常、オフライン・アップグレード処理には、アップグレードするTimesTenインスタンスの各データベースを2つコピーできる十分なディスク領域が必要となります。
オフライン・アップグレードを使用して次の内容を実行できます。
ttMigrateを使用してTimesTenの新しいメジャー・リリースへ移行
ttBackupおよびttRestoreを使用してTimesTenの新しいマイナー／リリースまたはパッチ・リリースへ移行
オフライン・アップグレードでは、アップグレード処理中、すべてのアプリケーションをTimesTenから切断する必要があります。また、共有メモリーのデータベースをアンロードする必要もあります。オフライン・アップグレードではTimesTen ttMigrateユーティリティ(メジャー・アップグレード用)またはttBackupユーティリティを使用する必要があります。(『Oracle TimesTen In-Memory Databaseリファレンス』のttMigrateに関する説明およびttBackupに関する説明を参照してください。)
「オフライン・アップグレードの実行」を参照してください。
TimesTenの新しいメジャー・リリースにアップグレードする場合、連続してアプリケーションから使用可能な状態にする必要があるミッション・クリティカルなデータベースがある場合があります。データベースが異なるリリースのTimesTenで構成されている場合でも、TimesTenレプリケーションを使用して、データベースの2つのコピーの同期をとることができます。これによって、一方のデータベースのTimesTenインスタンスをアップグレードしている間に、データベースのもう一方のコピーにアプリケーションを接続したままにできます。アップグレードが完了すると、アクティブなデータベースに対して行われたすべての更新は、アップグレードされたTimesTenインスタンスのデータベースに即時に送信されるため、アプリケーションは、データの損失や停止時間なしで切り替えることができます。詳細は、「レプリケーションを使用したオンライン・アップグレードの実行」を参照してください。
オンライン・アップグレード処理は、アップグレード実行中のユーザー表の更新のみをサポートしています。CREATE TABLEやCREATE INDEXなどのデータ定義への変更はレプリケートされません。また、レプリケートする表には、PRIMARY KEYまたは一意索引(NULLを指定できない列)が含まれている必要があります。
アップグレードではデータベースの2つのコピー(データベースが複数ある場合はそれぞれの2つのコピー)が必要なため、アップグレードを1つのシステムで実行する場合は、データベースが通常必要とする量の2倍のメモリーとディスク領域が使用可能である必要があります。
TimesTen Client/Serverインストールを新しいメジャー・リリースにアップグレードする場合は、クライアント/サーバー・オンライン・アップグレードを実行することによって、停止時間を最小限に抑えることができます。この処理の実行中に、以前のリリースのTimesTenクライアントは、新しいリリースにアップグレードされたTimesTenインスタンスのデータベースと通信し続けることができます。「クライアント/サーバーのオンライン・アップグレードの実行」を参照してください。
クライアント/サーバー・オンライン・アップグレード処理は、アップグレードするTimesTenインスタンスのデータベースへのクライアント・アプリケーションのアクセスが中断するのを最小限に抑えますが、中断をなくすことはできません。すべてのクライアントに対するデータベースの、ほぼ連続した可用性を維持するには、前の項「レプリケーションを使用したオンライン・アップグレード」に示す方法を使用します。この手順では、アップグレードしている間、同一のコピーが以前のリリースのTimesTen Serverに対し引き続き使用可能な状態になります。元のデータベースが新しいリリースのTimesTen Serverに対して使用可能になった後、同じポートをリスニングしたまま以前のリリースを停止し、新しいリリースを起動します。この方法で可用性が途切れるのは、以前のサーバーが停止してから新しいサーバーが起動するまでの非常に短い期間のみです。
パッチ・リリース間の移動(同じTimesTenメジャー・リリース)の場合、UNIXシステムのTimesTenインスタンスのインプレース・アップグレードを実行できます。たとえば、11.2.2.x.xリリースからそれ以降の11.2.2.x.xリリースに移行します。データベースの移行は必要ありません。
Windowsシステムでは、このようなアップグレードのインストーラ・オプションはありません。かわりに、パッチ・リリース間を移行する場合でも、TimesTenのアンインストールおよびインストールを個別に実行する必要があります。UNIXでのインプレース・アップグレードと同様、データベースの移行は必要ありません。
アップグレードの前に、インスタンス内の各データベースについて、すべてのアプリケーションはデータベースから切断する必要があり、データベースは共有メモリーからアンロードする必要があります。
次の項では、インプレース・アップグレードの実行またはWindowsでの同等の処理について説明します。
TimesTenデータベースは、アプリケーションまたはTimesTenエージェント(キャッシュ・エージェントやレプリケーション・エージェントなど)が接続している場合は共有メモリーにロードされたままです。アプリケーションやエージェントが接続されていなくても、ttAdminユーティリティで設定した特定のRAMポリシー構成のためにデータベースが共有メモリーに保持されることもあります。(『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明を参照してください。)
アップグレード対象のTimesTenインスタンスのメモリーからデータベースをアンロードするには、次の手順を実行します。TimesTenインスタンスのデータベースごとに、すべての手順を完了する必要があります。
すべてのアプリケーションをデータベースから切断します。
レプリケーション・エージェントがデータベースで実行されている場合は、レプリケーションの状態をpauseに設定し、レプリケーション・エージェントを停止します。この例は、アクティブ・スタンバイ・ペア(activedbとstandbydb)を参照しています。この場合、activedbは、アップグレード対象のTimesTenインスタンスに属しています。この例では、レプリケーションの状態を、activedbからstandbydbへ、そしてpauseへ設定して、activedb上のレプリケーション・エージェントを停止します。standbydbは、アップグレード対象のTimesTenインスタンスに属していないと想定します。
ttRepAdmin -receiver -name activedb -state pause standbydb ttAdmin -repStop activedb
キャッシュ・エージェントがデータベースで実行されている場合は、キャッシュ・エージェントを停止します。この例は、TimesTen Cacheを使用し、アップグレード対象のTimesTenインスタンスに属しているデータベースcachedbを参照しています。(この例では、レプリケーションを考慮していません。キャッシュ・エージェントが実行されている場合、データベースにレプリケーションが設定されているかどうかにかかわらずこの手順を実行する必要があります。)
ttAdmin -cacheStop cachedb
ttAdminを使用してメモリーからデータベースをアンロードします。最初の例はRAMポリシーがmanualに設定されていることを想定し、アップグレード中のTimesTenインスタンスに属するデータベースupgradedbを参照します。(この例では、レプリケーションを考慮していません。この手順は、データベースにレプリケーションまたはキャッシュが設定されているかどうかにかかわらず実行する必要があります。)
ttAdmin -ramUnload upgradedb
または、RAMポリシーがalwaysに設定されている場合は、manualに変更した後で、メモリーからデータベースをアンロードします。例:
ttAdmin -ramPolicy manual -ramUnload upgradedb
または、RAMポリシーがinUseであり、猶予期間が設定されている場合は、猶予期間に0(ゼロ)を設定するか、または猶予期間に設定した時間が経過するまで待機します。これでデータベースがアンロードされます。例:
ttAdmin -ramGrace 0 upgradedb
ttStatusユーティリティを使用して、データベースがメモリーからアンロードされたことを確認します。このユーティリティにより、データ・ストアへの接続がないことが示されます。(データベースがメモリーにロードされると、サブデーモン接続が自動作成されます。)
『Oracle TimesTen In-Memory Databaseリファレンス』のttStatusに関する説明を参照してください。
必要に応じてTimesTenデーモンを停止します。(インプレース・アップグレード時は、デーモンは自動的に停止します。)
ttDaemonAdmin -stop
後述の「メモリーへのデータベースの再ロード」も参照してください。
|
注意: たとえば、activedb、cachedbおよびupgradedbデータベースは、同じデータベースにすることができます。TimesTenデータベースは、構成済のレプリケーションとキャッシュの両方と、それにmanual以外のRAMポリシーを持つことができます。 |
UNIXシステムでインプレース・アップグレードを実行するには、(新しいインスタンスをインストールするのではなく)TimesTenインストーラ・オプションを使用して既存のインスタンスをアップグレードします。UNIXインストーラ・オプションについては、「TimesTenのインストール」を参照してください。
古いリリースのアンインストールおよび新しいリリースのインストールは、1つのプロセスで実行されます。新しいソフトウェアのライブラリおよびバイナリは、これまでと同じ場所にインストールされます。install_dir/infoおよびinstall_dir/network/admin/samplesのファイルを削除するかどうかの確認を求められます。デフォルトの応答「no」を選択すると、既存のデータベースが保持されます(データベースがinstall_dirディレクトリ下にない場合)。構成はinfoディレクトリに保持され、データベースを移行する必要はありません。
Windowsシステムでは、このようなアップグレードのインストーラ・オプションはありません。かわりに、パッチ・リリース間(同じTimesTenメジャー・リリース内)を移行する場合は、TimesTenをアンインストールした後、新しいリリースをインストールする必要があります。Windowsでのアンインストールについては、「WindowsシステムでのTimesTenの削除」で説明します。アンインストール時にDSNを保存すると、既存のデータベースが保持され(データベースがinstall_dirディレクトリ下にない場合)、データベースを移行することなくデータベースの構成が保持されます。Windowsでのインストールは、「TimesTenのインストール」で説明します。
|
重要: アップグレードする前に、TimesTenインストール・ディレクトリにデータベースまたは重要なファイルがないことを確認してください。関連情報については、「データベース・ファイルおよびその他のユーザー・ファイルの場所に関する考慮事項」および「既存のデータベース・ファイルの場所」を参照してください。 |
メモリーからデータベースをアンロードし(「メモリーからのデータベースのアンロード」のとおり)、TimesTenインスタンスをアップグレードした後で、次のようなコマンドを使用してデータベースをメモリーに再ロードします。(これらの例は、互いに無関係です。)該当する場合は、アップグレードされたインスタンスのデータベースごとに、そのような手順を実行する必要があります。
TimesTenデーモンが開始していることを確認します。(インプレース・アップグレード時は、デーモンは自動的に開始されます。)必要に応じて次の操作を実行します。
ttDaemonAdmin -start
ttAdminを使用してデータベースをメモリーに再ロードします。アップグレード前にRAMポリシーのupgradedbがmanualに設定されている場合、次の操作を実行します。
ttAdmin -ramLoad upgradedb
または、RAMポリシーがアップグレード前にalwaysに設定されていた場合は、alwaysに戻します。これでデータベースが再ロードされます。例:
ttAdmin -ramPolicy always upgradedb
または、RAMポリシーがinUseに設定されていて、猶予期間を0に変更した場合は、元の設定に変更してください。例:
ttAdmin -ramPolicy inUse -ramGrace 300 upgradedb
レプリケーションを再起動するには(アクティブ・スタンバイ・ペアのactivedbがアップグレード対象のTimesTenインスタンスにあると想定)、次のようにします。
ttRepAdmin -receiver -name activedb -state start standbydb ttAdmin -repStart activedb
TimesTen Cacheを再起動するには(cachedbがキャッシュを使用し、また、アップグレード対象のTimesTenインスタンスにあると想定)、次のようにします。
ttAdmin -cacheStart cachedb
データベースを外部ファイルにエクスポートし、変更したデータベースをインポートすることで、オフライン・アップグレードを実行できます。このようなアップグレード手順を実行するには、すべてのアプリケーションをデータベースから切断し、共有メモリーからデータベースをアンロードする必要があります。継続的な接続を必要とするアプリケーションについては、「レプリケーションを使用したオンライン・アップグレードの実行」を参照してください。
この項では、次のトピックを取り扱います:
これらの手順は、スタンドアロンのTimesTenデータベースに使用できます。レプリケーションおよびTimesTen Cacheのシナリオは考慮されていません。
TimesTenの複数のメジャー・リリースを、システムに同時にインストールすることができます。ただし、あるメジャー・リリースで作成したTimesTenのデータベースには、異なるメジャー・リリースのアプリケーションから直接アクセスすることはできません。たとえば、TimesTenのメジャー・リリース間でのデータの移行を、TimesTen 11.2.1から11.2.2で行う場合、ttMigrateユーティリティを使用して以前のリリースのデータをエクスポートし、さらにttMigrateユーティリティを使用して新しいリリースからインポートする必要があります。
|
注意: TimesTenのメジャー・アップグレードでオフライン・アップグレードが必要になる特定のシナリオの詳細は、「キャッシュ・グループを使用したアクティブ・スタンバイ・ペアのオンライン・アップグレード」および「Oracle Clusterware使用時のTimesTenのオフライン・アップグレードの実行」を参照してください。 |
オフライン・アップグレードの一般的な手順は、次のとおりです。この手順は、古いリリースがインストールされている状態で新しいリリースをインストールすることを想定しています。新しいリリースでデータベースが正しく構成されて完全に使用可能なことを確認するまで、一般的にこの手順を使用することをお薦めします。
古いリリースで、データベースごとに次操作を実行します。
すべてのアプリケーションをデータベースから切断します。
ttMigrateを-cを指定して実行し、データベース・コンテンツのコピーを保存します。例:
ttMigrateCS -c salesdata salesdata.dat
データベースをメモリーからアンロードします。詳細は、「メモリーからのデータベースのアンロード」を参照してください。オフライン・アップグレードでは、メモリーからデータベースをアンロードした後、TimesTenデーモンを停止します(ttDaemonAdmin -stop)。
必要に応じて、ttDestroyユーティリティを使用して古いデータベースを破棄します。新しいデータベースが古いデータベースと同じ場所にある場合は、この手順は必須です。
重要: 予防措置として、最初にttBackupを使用してデータベースをバックアップすることをお薦めします。新しいリリースでデータベースが使用可能になると、バックアップを削除できます。
各データベースで前述の手順を完了したら、TimesTenの新しいリリースをインストールします。詳細は、第1章「TimesTenのインストール」を参照してください。
次に、システムの環境変数PATHおよびLD_LIBRARY_PATHが新しいTimesTenリリースを正しく参照するように設定されていることを確認します。
新しいリリースで、データベースごとに次の操作を実行します。
アップグレード後、DataStore接続属性が正しく設定されていることを確認します。
次の例のように、AutoCreate=1を使用してデータベースを再作成します。
ttIsql -connstr "dsn=salesdata;AutoCreate=1" -e "quit"
この時点でデータベースは空です。
-rおよび-relaxedUpgrade (通常)を指定してttMigrateを使用して、バックアップしたデータベースを新しいTimesTenリリースにリストアします。例:
ttMigrate -r -relaxedUpgrade salesdata salesdata.dat
新しいリリースでデータベースが正しく設定されて完全に使用可能になれば、必要に応じて古いリリースをアンインストールします。アンインストールは、第1章「TimesTenのインストール」で説明しています。
同じメジャー・リリース・ラインの新しいマイナー・リリースまたはパッチ・リリースに移行するには、ttBackupおよびttRestoreユーティリティを使用します。
|
注意:
|
新しいマイナー・リリースまたはパッチ・リリースへのオフライン・アップグレードの一般的な手順は次のとおりです。
古いリリースで、データベースごとに次操作を実行します。
すべてのアプリケーションをデータベースから切断します。
ttBackupを使用して、元のシステムのデータベースをバックアップします。例:
ttBackup -dir /tmp/dump -fname salesdata SalesData
データベースをメモリーからアンロードします。詳細は、「メモリーからのデータベースのアンロード」を参照してください。オフライン・アップグレードでは、メモリーからデータベースをアンロードした後、TimesTenデーモンを停止します(ttDaemonAdmin -stop)。
必要に応じて、ttDestroyユーティリティを使用して古いデータベースを破棄します。新しいデータベースが古いデータベースと同じ場所にある場合は、この手順は必須です。
各データベースで前述の手順を完了したら、TimesTenの古いリリースをアンインストールして新しいリリースをインストールします。詳細は、第1章「TimesTenのインストール」を参照してください。
次に、システムの環境変数PATHおよびLD_LIBRARY_PATHが新しいTimesTenリリースを正しく参照するように設定されていることを確認します。
新しいリリースで、データベースごとに次の操作を実行します。
アップグレード後、DataStore接続属性が正しく設定されていることを確認します。
ttRestoreを使用して新しいシステムでバックアップをリストアします。例:
ttRestore -dir /tmp/dump -fname salesdata SalesData
「オフライン・アップグレードの実行」では、すべてのアプリケーションの停止が必要なTimesTenデータベースでの様々なメンテナンス操作について説明しました。この項では、TimesTenレプリケーション機能を使用して、データの継続使用が必要なアプリケーションのオンライン・アップグレードを実行する方法について説明します。
通常、データの高可用性が求められるアプリケーションでは、TimesTenレプリケーションを使用して、最新のデータベースのコピーを1つ以上保持しておきます。これらの2つのコピーの一方が更新中の場合にも、一方をアプリケーションで使用できるように保持することで、オンライン・アップグレードが機能します。この項で説明した手順は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の「単方向または双方向のレプリケーション」の説明のとおり、双方向のレプリケーション・スキームが構成されていて、2つのデータベースに対して実行されていることを前提としています。
次の点に注意してください。
異なるリリース間でレプリケーションが機能するのは、最新リリースのTimesTenのデータベースが、以前のリリースのTimesTenのデータベースからアップグレードされている場合のみです。最新リリースのTimesTenで作成されたデータベースと、以前のリリースとのレプリケーションは、サポートされていません。たとえば、リリース7.0.6.x.xのTimesTenで作成されたデータベースと、11.2.2.x.xのTimesTenで作成されたデータベース間のレプリケーションは、サポートされていません。ただし、あるデータベースを7.0.6.x.xで作成し、もう一方のデータベースをリリース7.0.6.x.xで作成してから、リリース11.2.2.x.xのTimesTenにアップグレードした場合、これらのデータベース間ではレプリケーションがサポートされます。
アクティブ・スタンバイ・ペアについては、必要に応じて、「キャッシュ・グループを使用しないアクティブ・スタンバイ・ペアのオンライン・アップグレード」および「キャッシュ・グループを使用したアクティブ・スタンバイ・ペアのオンライン・アップグレード」を参照してください。読取り専用キャッシュ・グループの場合、キャッシュ・グループを使用したアクティブ・スタンバイ・ペアのオンライン・メジャー・アップグレードのみがサポートされます。かわりに、「キャッシュ・グループが構成されているアクティブ・スタンバイ・ペアのオフライン・アップグレード」を参照してください。
Oracle Clusterwareの使用については、必要に応じて、「Oracle Clusterware使用時のTimesTenのオンライン・アップグレードの実行」を参照してください。Oracle Clusterwareによって管理されるアクティブ・スタンバイ・ペアの場合、オンライン・メジャー・アップグレードはサポートされません。かわりに、「Oracle Clusterware使用時のTimesTenのオンライン・アップグレードの実行」を参照してください。
次の項では、レプリケーションを使用したオンライン・アップグレードの実行方法について説明します。
以前のリリースのTimesTenから新しいリリースへのデータベースのアップグレードは、データベースのレプリケートされる2つのコピーのいずれかからすべてのアプリケーションを切断して、以前のリリースのttMigrateユーティリティを使用してデータベースのバックアップを作成し、新しいリリースのttMigrateユーティリティを使用して新しいリリースのデータベースにバックアップをロードしてから、すべてのアプリケーションをアップグレード済のTimesTenインスタンスのデータベースに再接続することで実行されます。
オンライン・アップグレードの一般的な手順は、次のとおりです。
すべてのアプリケーションをアップグレードするTimesTenインスタンスのデータベースから切断します。
アップグレードするTimesTenインスタンスのレプリケーションを停止します。
-cオプションを指定して以前のリリースのttMigrateを使用し、アップグレードするTimesTenインスタンスに存在するデータベースをバックアップします。
アップグレード中のシステムに新しいリリースのTimesTenをインストールします。
-rオプションを指定して新しいリリースのttMigrateを使用し、アップグレード済のTimesTenのインスタンスでレプリケートされたデータベースをリストアします。
アップグレードしたTimesTenのインスタンスでレプリケーションを再起動します。
アップグレードしたTimesTenインスタンスのデータベースに、すべてのアプリケーションを再接続します。
|
注意: ttMigrateを使用した後は、アクティブ・スタンバイ・ペアを構成しないアップグレード後のデータベースのすべての自動リフレッシュ・キャッシュ・グループで、アップグレード前のデータベースでの設定にかかわらずAUTOREFRESH STATEがOFFに設定されます。ALTER CACHE GROUP文を使用して、AUTOREFRESH STATEをONに設定しなおしてください。 |
継続的な可用性を維持するため、切断されたデータベースのコピーのTimesTenインスタンスでアップグレードが実行される間、アプリケーションはデータベースの一方のコピーで引き続き実行されます。TimesTenレプリケーションでは、アップグレード期間中にデータベースのアクティブなコピーに加えられる更新を保持し、レプリケーションが再開されると更新内容をアップグレード後のデータベースに転送して適用します。レプリケートされた更新が完全に適用されると、アプリケーションはアップグレード後のデータベースに再接続されます。
オンライン・アップグレードは、すべてのユーザー表がレプリケーション要件を満たしているデータベースでのみ実行できます。すべてのユーザー表には、PRIMARY KEY宣言が含まれているか、NULLを指定できない列に一意索引が宣言されている必要があります。
レプリケーションを使用してオンライン・アップグレードを実行する場合は、静的ポートを使用するようにレプリケーションを構成する必要があります。『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のポートの割当てに関する説明を参照してください。
双方向レプリケーション構成が存在しない1つのシステムでオンライン・アップグレードを実行する場合、アップグレードが実行されているデータベースの2つのコピーをサポートするのに十分なメモリーとディスク領域が使用可能であることを確認する必要があります。アップグレード中は、元のデータベースとそのコピーの両方がアクティブなままです。本番アプリケーションのパフォーマンスを維持するために、2つ目のシステムでデータベースのコピーを作成することもできます。
ttMigrateユーティリティを使用して作成したデータベースのバックアップ・コピーを格納するために、追加のディスク領域を割り当てる必要があります。通常、バックアップ・コピーのサイズは、使用中のデータベースのサイズとほぼ同じです。このサイズを確認するには、ttIsqlを使用してsys.monitor表を問い合せます。
Command> SELECT perm_in_use_size FROM sys.monitor;
次の表に、レプリケーションの実行中にオンライン・アップグレードを実行する手順を示します。アップグレード・システムは、データベースのアップグレードが実行されているシステムで、アクティブなシステムは、アプリケーションが引き続き接続されるデータベースを含むシステムです。
|
注意: 次のステップで、標準アップグレードを行います。接続属性ReplicationApplyOrderingが0に設定されているTimesTen 11.2.1のデータベースや、ReplicationParallelismが<2に設定されているTimesTen 11.2.1または11.2.2のデータベースからのアップグレードでは、リリースが同じメジャー・リリース・ラインであっても、データベースの再作成が必要です。 |
前述の手順をアップグレード・システムで実行した後、同じ手順を使用して、アクティブ・システムをアップグレードできます。
この項では、具体的な例を使用して、双方向でレプリケートされている2つのTimesTenデータベースのシナリオでオンライン・アップグレードを実行する手順について説明します。
|
注意: TimesTen 11.2.1には、キャッシュ・グリッド機能が導入されています。この機能はデフォルトで有効になっていますが、データベースにキャッシュ・グループを作成する前に追加の構成を行う必要があります。11.2.1より前のリリースのキャッシュ・グループを含む環境をアップグレードする場合は、その開始前に、各DSN定義でCacheGridEnable属性を0に設定しておく必要があります。詳細は、Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイドのキャッシュ・グリッドの作成に関する説明を参照してください。 |
ここでは、2つのTimesTenシステムを、アップグレード・システム(TimesTenインスタンスとデータベースがアップグレードされる)およびアクティブ・システム(アップグレード期間中、操作可能でアプリケーションに接続される)と呼びます。手順が完了した後、同じ手順を繰り返してアクティブ・システムをアップグレードできます。ただし、アップグレードされたTimesTenインスタンスを最初にテストするために、アクティブ・システムの変換を遅延することもできます。
この例では、アップグレード・システムは、サーバーupgradehost上のデータベースupgradeで構成されています。アクティブ・システムは、サーバーactivehost上のデータベースactiveで構成されています。
次に示す手順は、その順序どおりに示されています。オンライン・アップグレードの手順は、次のとおりです。
| 手順 | アップグレード・システム | アクティブ・システム |
|---|---|---|
| 1. | データベースがリリース間で通信できるように静的レプリケーション・ポート番号を設定し、ttIsqlを使用してレプリケーション・スキームrepschemeを変更します。
|
データベースがリリース間で通信できるように静的レプリケーション・ポート番号を設定し、ttIsqlを使用してレプリケーション・スキームrepschemeを変更します。
|
| 2. | データベースに接続されているすべての本番アプリケーションを切断します。かわりに、アップグレード・システムで実行されているワークロードがアクティブ・システムでの動作を開始する必要があります。 | ttRepAdminユーティリティを使用して、データベースactiveからデータベースupgradeへのレプリケーションを一時停止します。
ttRepAdmin -receiver -name upgrade -state pause active このコマンドにより、データベース |
| 3. | データベースactiveに送信されるすべてのレプリケーションの更新を待機します。データベースupgradeで、更新の確認用として予約されている表に認識可能な更新を適用することで、更新がすべて送信されたことを確認できます。データベースactiveに更新が適用されると、すべての以前の更新が送信されたことになります。 |
|
| 4. | ttAdminを使用して、レプリケーション・エージェントを停止します。
ttAdmin -repStop upgrade これ以降、データベース |
ttAdminを使用して、レプリケーション・エージェントを停止します。
ttAdmin -repStop active これ以降、データベース レプリケーション・エージェントの起動と停止の詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の「レプリケーション・エージェントの起動と停止」に関する説明を参照してください。 |
| 5. | ttRepAdminを使用して、データベースupgradeからデータベースactiveへのレプリケーションを停止します。
ttRepAdmin -receiver -name active -state stop upgrade この手順によって、 |
|
| 6. | ttMigrateを使用して、データベースupgradeをバックアップします。データベースが非常に大規模な場合は、この手順に長時間かかる可能性があります。/backupファイル・システムに十分なディスク領域の空きがある場合は、次のttMigrateコマンドを使用します。
ttMigrate -c upgrade /backup/upgrade.dat |
|
| 7. | ttMigrateコマンドが正常に実行された場合、データベースupgradeを破棄します。
永続データベース( ttDestroy upgrade 一時データベース( ttAdmin -ramUnload upgrade |
データベースactiveのレプリケーション・エージェントを再開します。
ttAdmin -repStart active |
| 8. | 新しいリリースのTimesTenをインストールします。 | レプリケーション状態をstartに設定して、activeからupgradeへのレプリケーションを再開します。
ttRepAdmin -receiver -name upgrade -start start active |
| 9. | ttMigrateを使用して、手順6で作成したバックアップを新しいリリースのTimesTenのデータベースupgradeにロードします。
ttMigrate -r upgrade /backup/upgrade.dat データベースが一時データベース( ttAdmin -ramLoad upgrade 注意: この手順では、アップグレードしているTimesTenの新しいリリースの |
|
| 10. | ttRepAdminを使用して、データベースactiveの受信側の状態を再設定し、レプリケーションをstop状態に設定した後start状態に設定することで、レプリケーション・ブックマークおよびログを消去します。
ttRepAdmin -receiver -name active -reset upgrade ttRepAdmin -receiver -name active -state stop upgrade sleep 10 ttRepAdmin -receiver -name active -state start upgrade sleep 10 注意: コンピュータのリソースやオペレーティング・システムによっては、状態の変更に最大で10秒かかるものもあるため、それぞれの状態が確実に有効になるように |
|
| 11. | ttAdminを使用して、新しいデータベースupgradeのレプリケーション・エージェントを開始し、データベースactiveへの更新の送信を開始します。
ttAdmin -repStart upgrade |
|
| 12. | データベースupgradeがデータベースactiveから更新を受信するかを確認します。データベースactiveで、更新の確認用として予約されている表に認識可能な更新を適用することで、更新が送信されたことを確認できます。upgradeに更新が適用されると、レプリケーションが動作していることになります。 |
アプリケーションがデータベースactiveで実行中の場合は、データベースupgradeの移行が正常に終了し、更新がactiveからupgradeに正しくレプリケートされたことを確認するまで、そのまま実行しておきます。 |
| 13. | 更新が正常にレプリケートされていることを確認したら、すべてのアプリケーションをデータベースactiveから切断し、データベースupgradeに再接続できます。activeからの最後の更新がupgradeにレプリケートされたことを確認した後、activeのTimesTenインスタンスはアップグレード可能となります。
注意: 新しいリリースのTimesTenでデータベース |
アクティブ・スタンバイ・ペア・レプリケーションにより、アプリケーションへのデータの可用性が向上します。アクティブ・スタンバイ・ペアでは、非同期ライトスルー・キャッシュ・グループも使用する構成でTimesTenの新しいメジャー・リリースへアップグレードする場合を除き、オンライン・アップグレードを実行してTimesTenのアップグレード中にデータの可用性を継続して維持できます。この項では、次の手順について説明します。
|
注意: 非同期ライトスルーまたは読取り専用キャッシュ・グループのみがアクティブ・スタンバイ・ペアでサポートされます。 |
この項では、アクティブ・スタンバイ・ペアを使用した、キャッシュ・グループのないシナリオにおけるオンライン・アップグレードについて説明します。
概要、制限および要件については、「レプリケーションを使用したオンライン・アップグレードの実行」も参照してください。
スタンバイ・マスター・データベースおよびサブスクライバ・データベースの新しいTimesTenのパッチ・リリースへのオンライン・マイナー・アップグレードを実行するには、各データベースで次のタスクを実行します。この手順では、キャッシュ・グループはないものとします。
ttRepStop組込みプロシージャまたはttAdminユーティリティを使用して、データベースのレプリケーション・エージェントを停止します。たとえば、スタンバイ・データベースmaster2のレプリケーション・エージェントを停止するには、次のコマンドを使用します。
ttAdmin -repStop master2
新しいTimesTenのパッチ・リリースをインストールします。「インプレース・アップグレードの実行」を参照してください。
ttRepStart組込みプロシージャまたはttAdminユーティリティを使用して、レプリケーション・エージェントを再開します。
ttAdmin -repStart master2
アクティブ・マスター・データベースの新しいTimesTenパッチ・リリースへのマイナー・アップグレードを実行するには、アクティブ・マスター・データベースとスタンバイ・マスター・データベースの役割を逆にしてから、インプレース・アップグレードを行う必要があります。この手順では、キャッシュ・グループはないものとします。
アクティブ・マスター・データベースで更新を生成しているすべてのアプリケーションを一時停止します。
スタンバイ・マスター・データベースのDSNおよびホストを使用して、アクティブ・マスター・データベースのttRepSubscriberWait組込みプロシージャを実行します。たとえば、すべてのトランザクションがホストmaster2hostのスタンバイ・マスターmaster2にレプリケートされるようにするには、次のようにします。
call ttRepSubscriberWait( null, null, 'master2', 'master2host', 120 );
ttRepStop組込みプロシージャまたはttAdminユーティリティを使用して、現行のアクティブ・マスター・データベースのレプリケーション・エージェントを停止します。たとえば、アクティブ・マスター・データベースmaster1のレプリケーション・エージェントを停止するには、次のようにします。
ttAdmin -repStop master1
現行のアクティブ・マスター・データベースでttRepDeactivate組込みプロシージャを実行します。これによって、データベースがIDLE状態になります。
call ttRepDeactivate;
スタンバイ・マスター・データベースで、ttRepStateSet組込みプロシージャを使用して、データベースをACTIVE状態に設定します。このデータベースがアクティブ・スタンバイ・ペアのアクティブ・マスターになります。
call ttRepStateSet( 'ACTIVE' );
手順1で一時停止したアプリケーションを再開し、現在アクティブ・マスターとして動作しているデータベース(この例では、データベースmaster2)に接続します。
|
注意: この時点では、新しいアクティブ・データベースからサブスクライバ・データベースへのレプリケーションは発生しません。レプリケーションは、新しいスタンバイ・データベースがアップグレードされ、新しいスタンバイ・データベースのレプリケーション・エージェントが実行されてから再開されます。 |
前のアクティブ・マスター・データベース(今のスタンバイ・マスター・データベース)のTimesTenインスタンスをアップグレードします。「インプレース・アップグレードの実行」を参照してください。
ttRepStart組込みプロシージャまたはttAdminユーティリティを使用して、アップグレードしたTimesTenインスタンスのデータベースのレプリケーションを再起動します。
ttAdmin -repStart master2
新しくアップグレードしたTimesTenインスタンスのデータベースを再びアクティブ・マスター・データベースにするには、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のアクティブ・マスター・データベースとスタンバイ・マスター・データベースの役割の入替えに関する説明を参照してください。
アクティブ・スタンバイ・ペアからTimesTenの新しいメジャー・リリースへのオンライン・アップグレードを実行するには、各データベースのTCP/IPポートを明示的に指定する必要があります。アクティブ・スタンバイ・ペアのレプリケーション・スキームで各データベースのPORT属性が構成されていない場合は、アップグレードの準備として次の手順を実行する必要があります。この手順では、キャッシュ・グループはないものとします。(読取り専用キャッシュ・グループの場合、キャッシュ・グループを使用したアクティブ・スタンバイ・ペアのオンライン・メジャー・アップグレードのみがサポートされます。)
ttRepStop組込みプロシージャをコールするか、ttAdminユーティリティを使用して、すべてのデータベースでレプリケーション・エージェントを停止します。たとえば、データベースmaster1のレプリケーション・エージェントを停止するには、次のようにします。
ttAdmin -repStop master1
アクティブ・マスター・データベースで、ALTER ACTIVE STANDBY PAIR文を使用してアクティブ・スタンバイ・ペアのすべてのデータベースのPORT属性を指定します。たとえば、ホストmaster1hostのデータベースmaster1、ホストmaster2hostのmaster2、ホストsubscriber1hostのsubscriber1でPORT属性を設定するには、次のようにします。
ALTER ACTIVE STANDBY PAIR ALTER STORE master1 ON "master1host" SET PORT 30000 ALTER STORE master2 ON "master2host" SET PORT 30001 ALTER STORE subscriber1 ON "subscriber1host" SET PORT 30002;
ttDestroyユーティリティを使用して、スタンバイ・マスター・データベースおよびすべてのサブスクライバを破棄します。たとえば、データベースsubscriber1を破棄するには、次のようにします。
ttDestroy subscriber1
通常の手順に従ってアクティブ・スタンバイ・ペアを起動し、アクティブ・マスターからスタンバイ・データベースおよびサブスクライバ・データベースを複製します。『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のキャッシュ・グループのないアクティブ・スタンバイ・ペアの設定に関する説明を参照してください。
アクティブ・スタンバイ・ペアのTimesTenインスタンスをアップグレードするには、まずスタンバイ・マスターのインスタンスをアップグレードします。このノードのアップグレード中はスタンバイ・マスター・データベースが存在しないため、アクティブ・マスター・データベースでの更新は、サブスクライバ・データベースに直接伝播されます。スタンバイ・ノードのアップグレード後に、アクティブ・ロールとスタンバイ・ロールが切り替えられ、新しいアクティブ・ロールから新しいスタンバイ・ロールが作成されます。最後に、サブスクライバ・ノードがアップグレードされます。
アクティブ・マスター・データベースでttRepStateSave組込みプロシージャを実行して、アクティブ・マスター・データベースに、スタンバイ・マスターへの更新のレプリケートを停止するように指示ます。たとえば、ホストmaster2hostのスタンバイ・マスター・データベースmaster2へのレプリケートを停止するには、次のようにします。
call ttRepStateSave( 'FAILED', 'master2', 'master2host' );
ttRepStop組込みプロシージャまたはttAdminユーティリティを使用して、スタンバイ・マスター・データベースのレプリケーション・エージェントを停止します。次の例では、スタンバイ・マスター・データベースmaster2のレプリケーション・エージェントを停止します。
ttAdmin -repStop master2
ttMigrateユーティリティを使用してスタンバイ・マスター・データベースをバイナリ・ファイルにバックアップします。
ttMigrate -c master2 master2.bak
ttMigrateの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』を参照してください。
ttDestroyユーティリティを使用して、アクティブ・マスター・データベースを破棄します。
ttDestroy master2
古いリリースを削除し、新しいリリースのTimesTenをスタンバイ・マスター・ホストmaster2hostにインストールします。「UNIXシステムへのTimesTenのインストール」または「WindowsシステムへのTimesTenのインストール」を参照してください。
master2hostの新しいTimesTenインスタンスで、ttMigrateを使用して、前に作成したバイナリ・ファイルからスタンバイ・マスター・データベースをリストアします。(この例では、20MB分のデータがリストアされるたびにチェックポイント操作が実行されます。)
ttMigrate -r -C 20 master2 master2.bak
ttRepStart組込みプロシージャまたはttAdminユーティリティを使用してスタンバイ・マスター・データベースのレプリケーション・エージェントを開始します。
ttAdmin -repStart master2
アップグレードしたTimesTenインスタンスのスタンバイ・マスター・データベースがアクティブ・マスター・データベースと同期化すると、このスタンバイ・マスター・データはRECOVERING状態からSTANDBY状態に移行します。また、このスタンバイ・マスター・データベースは、サブスクライバに更新の送信も開始します。スタンバイ・マスター・データベースがSTANDBY状態になるタイミングは、ttRepStateGet組込みプロシージャをコールすることで決まります。
call ttRepStateGet;
アクティブ・マスター・データベースで更新を生成しているすべてのアプリケーションを一時停止します。
スタンバイ・マスター・データベースのDSNおよびホストを使用して、アクティブ・マスター・データベースのttRepSubscriberWait組込みプロシージャを実行します。たとえば、すべてのトランザクションがホストmaster2hostのスタンバイ・マスターmaster2にレプリケートされるようにするには、次のようにします。
call ttRepSubscriberWait( null, null, 'master2', 'master2host', 120 );
ttRepStop組込みプロシージャまたはttAdminユーティリティを使用して、アクティブ・マスター・データベースのレプリケーション・エージェントを停止します。たとえば、アクティブ・マスター・データベースmaster1のレプリケーション・エージェントを停止するには、次のようにします。
ttAdmin -repStop master1
スタンバイ・マスター・データベースで、ttRepStateSet組込みプロシージャを使用して、データベースをACTIVE状態に設定します。このデータベースがアクティブ・スタンバイ・ペアのアクティブ・マスターになります。
call ttRepStateSet( 'ACTIVE' );
アクティブ・マスター・データベースでttRepStateSave組込みプロシージャを実行して、新しいアクティブ・マスター・データベース(この例では、master2)に、現在のスタンバイ・マスター(master1)への更新のレプリケートを停止するように指示します。たとえば、ホストmaster1hostのスタンバイ・マスター・データベースmaster1へのレプリケートを停止するには、次のようにします。
call ttRepStateSave( 'FAILED', 'master1', 'master1host' );
ttDestroyユーティリティを次のように使用して、前のアクティブ・マスター・データベースを破棄します。
ttDestroy master1
古いリリースを削除し、master1hostに新しいTimesTenをインストールします。
11.2.1より前のTimesTenバージョンからアップグレードする場合、アクセス制御が導入されていると、データベースを複製するために新しいアクティブ・マスター・データベースでADMIN権限を持つユーザーを作成する必要があります。(11.2.1以降からアップグレードする場合は、ttMigrateによって移行したADMINユーザーを使用できる場合があります。)たとえば、スタンバイ・マスター・データベースにパスワードpatpwdを使用するユーザーpatを作成するには、次のようにします。
CREATE USER pat IDENTIFIED BY patpwd; GRANT ADMIN TO pat;
ttRepAdminユーティリティを使用して、新しいスタンバイ・マスター・データベースを複製することによって、新しいスタンバイ・マスター・データベースを作成します。たとえば、ホストmaster2hostのデータベースmaster2をデータベースmaster1に複製するには、データベースmaster1を含むホストで次のコマンドを使用します。
ttRepAdmin -duplicate -from master2 -host master2host -uid pat -pwd patpwd -setMasterRepStart master1
ttRepStart組込みプロシージャまたはttAdminユーティリティを使用して新しいスタンバイ・マスター・データベースのレプリケーション・エージェントを開始します。
ttAdmin -repStart master1
ttRepStop組込みプロシージャまたはttAdminユーティリティを使用して、最初のサブスクライバ・データベースのレプリケーション・エージェントを停止します。たとえば、サブスクライバ・データベースsubscriber1のレプリケーション・エージェントを停止するには、次のようにします。
ttAdmin -repStop subscriber1
ttDestroyユーティリティを使用して、サブスクライバ・データベースを破棄します。
ttDestroy subscriber1
古いリリースを削除し、新しいリリースのTimesTenをサブスクライバ・ホストにインストールします。
ttRepAdminユーティリティを使用して、新しいスタンバイ・マスター・データベースを複製することによってサブスクライバ・データベースを作成します。
ttRepAdmin -duplicate -from master1 -host master1host -uid pat -pwd patpwd -setMasterRepStart subscriber1
ttRepStart組込みプロシージャまたはttAdminユーティリティを使用して、複製したサブスクライバ・データベースのレプリケーション・エージェントを開始します。
ttAdmin -repStart subscriber1
この項では、アクティブ・スタンバイ・ペアおよびキャッシュ・グループを使用したシナリオにおけるオンライン・マイナー・アップグレードについて説明します。
概要、制限および要件については、「レプリケーションを使用したオンライン・アップグレードの実行」も参照してください。
スタンバイ・マスター・データベースおよびサブスクライバ・データベースの新しいTimesTenのパッチ・リリースへのオンライン・マイナー・アップグレードを実行するには、キャッシュ・グループを使用した構成で、各データベースで次のタスクを実行します(例外については説明を参照)。
ttRepStop組込みプロシージャまたはttAdminユーティリティを使用して、データベースのレプリケーション・エージェントを停止します。たとえば、スタンバイ・データベースmaster2のレプリケーション・エージェントを停止するには、次のようにします。
ttAdmin -repStop master2
ttCacheStop組込みプロシージャまたはttAdminユーティリティを使用して、スタンバイ・データベースのキャッシュ・エージェントを停止します。
ttAdmin -cacheStop master2
TimesTenパッチをインストールします。「インプレース・アップグレードの実行」を参照してください。
ttCacheStart組込みプロシージャまたはttAdminユーティリティを使用して、スタンバイ・データベースのキャッシュ・エージェントを再開します。
ttAdmin -cacheStart master2
ttRepStart組込みプロシージャまたはttAdminユーティリティを使用して、レプリケーション・エージェントを再開します。
ttAdmin -repStart master2
|
注意: 手順2および手順4のキャッシュ・エージェントの停止および再起動は、サブスクライバ・データベースには適用できません。 |
アクティブ・マスター・データベースの新しいTimesTenのパッチ・リリースへのオンライン・マイナー・アップグレードを実行するには、キャッシュ・グループを使用した構成で、各データベースで次の手順を実行します。最初に、アクティブ・マスター・データベースとスタンバイ・マスター・データベースの役割を逆にしてから、インプレース・アップグレードを行う必要があります。
アクティブ・マスター・データベースで更新を生成しているすべてのアプリケーションを一時停止します。
スタンバイ・マスター・データベースのDSNおよびホストを使用して、アクティブ・マスター・データベースのttRepSubscriberWait組込みプロシージャを実行します。たとえば、すべてのトランザクションがホストmaster2hostのスタンバイ・マスターmaster2にレプリケートされるようにするには、次のようにします。
call ttRepSubscriberWait( null, null, 'master2', 'master2host', 120 );
ttRepStop組込みプロシージャまたはttAdminユーティリティを使用して、現行のアクティブ・マスター・データベースのレプリケーション・エージェントを停止します。たとえば、アクティブ・マスター・データベースmaster1のレプリケーション・エージェントを停止するには、次のようにします。
ttAdmin -repStop master1
ttCacheStop組込みプロシージャまたはttAdminユーティリティを使用して、現行のアクティブ・マスター・データベースのキャッシュ・エージェントを停止します。
ttAdmin -cacheStop master1
現行のアクティブ・マスター・データベースでttRepDeactivate組込みプロシージャを実行します。これによって、データベースがIDLE状態になります。
call ttRepDeactivate;
スタンバイ・マスター・データベースで、ttRepStateSet組込みプロシージャを使用して、データベースをACTIVE状態に設定します。このデータベースがアクティブ・スタンバイ・ペアのアクティブ・マスターになります。
call ttRepStateSet( 'ACTIVE' );
手順1で一時停止したアプリケーションを再開し、現在アクティブ・マスターとして動作しているデータベース(この例では、データベースmaster2)に接続します。
前のアクティブ・マスター・データベース(今のスタンバイ・マスター・データベース)のTimesTenインスタンスをアップグレードします。「インプレース・アップグレードの実行」を参照してください。
ttCacheStart組込みプロシージャまたはttAdminユーティリティを使用して、アップグレード後のデータベースのキャッシュ・エージェントを再開します。
ttAdmin -cacheStart master1
ttRepStart組込みプロシージャまたはttAdminユーティリティを使用して、アップグレード後のデータベースのレプリケーションを再開します。
ttAdmin -repStart master1
アップグレード後のデータベースを再びアクティブ・マスター・データベースにするには、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のアクティブ・データベースとスタンバイ・データベースの役割の入替えに関する説明を参照してください。
読取り専用キャッシュ・グループを使用したアクティブ・スタンバイ・ペアのシナリオで、リリース11.2.1.x.xからリリース11.2.2.x.xへのTimesTenメジャー・アップグレードを実行するには、次の手順を実行します。
この手順では、アクティブ・マスター・データベースmaster1はホストmaster1host、スタンバイ・マスター・データベースmaster2はホストmaster2hostにあるとします。
|
注意: ここで述べている組込みプロシージャおよびユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「組込みプロシージャ」および「ユーティリティ」を参照してください。 |
アクティブ・マスター・ホストでttAdminユーティリティを実行し、アクティブ・マスター・データベースのレプリケーション・エージェントを停止します。
ttAdmin -repStop master1
アクティブ・マスター・データベースでDROP ACTIVE STANDBY PAIR文を使用し、アクティブ・スタンバイ・ペアを削除します。たとえば、ttIsqlユーティリティから次のようにします。
Command> DROP ACTIVE STANDBY PAIR;
アクティブ・マスター・データベースでCREATE ACTIVE STANDBY PAIR文を使用し、キャッシュ・グループを除外した新しいアクティブ・スタンバイ・ペアを作成します。各データベースのTCP/IPポートは必ず明示的に指定してください。
Command> CREATE ACTIVE STANDBY PAIR master1 ON "master1host",
master2 ON "master2host"
STORE master1 ON "master1host" PORT 20000
STORE master2 ON "master2host" PORT 20010
EXCLUDE CACHE GROUP cacheuser.readcache;
|
注意: ttIsqlユーティリティでcachegroupsコマンドを使用し、データベースに定義するキャッシュ・グループをすべて指定できます。この例では、readcacheはcacheuserによって所有されている読取り専用のキャッシュ・グループです。 |
アクティブ・マスター・データベースでttRepStateSet組込みプロシージャを呼び出し、アクティブ・マスター・データベースのレプリケーション状態をACTIVEに設定します。
Command> call ttRepStateSet('ACTIVE');
アクティブ・マスター・データベースのレプリケーション状態がACTIVEに設定されていることを確認するには、ttRepStateGet組込みプロシージャを呼び出します。
Command> call ttRepStateGet(); < ACTIVE, NO GRID > 1 row found.
アクティブ・マスター・データベースでttRepStart組込みプロシージャを呼び出し、レプリケーション・エージェントを起動します。
Command> call ttRepStart();
スタンバイ・マスター・ホストでttAdminユーティリティを実行し、スタンバイ・マスター・データベースのレプリケーション・エージェントを停止します。
ttAdmin -repStop master2
スタンバイ・マスター・ホストでttAdminユーティリティを実行し、スタンバイ・マスター・データベースのキャッシュ・エージェントを停止します。
ttAdmin -cacheStop master2
スタンバイ・マスター・ホストでttDestroyユーティリティを実行し、スタンバイ・マスター・データベースを破棄します。-forceオプションを追加するか、最初にすべてのキャッシュ・グループを削除する必要があります。
ttDestroy -force master2
ttRepAdminユーティリティで新しいスタンバイ・マスター・データベースを複製することによって、新しいスタンバイ・マスター・データベースを作成します。たとえば、master2データベースのmaster1hostホスト上にあるmaster1データベースを複製するには、master2データベースを含むホストで次のように実行します。
ttRepAdmin -duplicate -from master1 -host master1host -UID pat -PWD patpwd -keepCG -cacheUid cacheuser -cachePwd cachepwd master2
|
注意: これを複製するには、アクティブ・マスター・データベースでADMIN権限が定義されているユーザーが必要です。この例では、patpwdパスワードで識別されるpatユーザーが、ADMIN権限を持っています。
キャッシュ・グループ表を維持するには、 |
新しいスタンバイ・マスター・データベースでDROP CACHE GROUP文を使用し、キャッシュ・グループをすべて削除します。
Command> DROP CACHE GROUP cacheuser.readcache;
スタンバイ・マスター・ホストでttMigrateユーティリティを実行し、スタンバイ・マスター・データベースをバイナリ・ファイルにバックアップします。
ttMigrate -c master2 master2.bak
スタンバイ・マスター・ホストでttDestroyユーティリティを実行し、スタンバイ・マスター・データベースを破棄します。
ttDestroy master2
古いリリースを削除し、新しいリリースのTimesTenをスタンバイ・マスター・ホストにインストールします。「UNIXシステムへのTimesTenのインストール」または「WindowsシステムへのTimesTenのインストール」を参照してください。
スタンバイ・マスター・ホスト上の新しいTimesTenインスタンスで、ttMigrateユーティリティを実行し、前の手順で作成したバイナリ・ファイルからスタンバイ・マスター・データベースをリストアします。
ttMigrate -r -C 20 master2 master2.bak
|
注意: この例では、20MB分のデータがリストアされるたびにチェックポイント操作が実行されます。 |
スタンバイ・マスター・データベースでCREATE USER文を使用し、新しいキャッシュ管理ユーザーを作成します。
Command> CREATE USER cacheuser2 IDENTIFIED BY cachepwd;
Command> GRANT CREATE SESSION, CACHE_MANAGER, CREATE ANY TABLE, DROP ANY TABLE
TO cacheuser2;
|
注意: 新しいキャッシュ管理ユーザーはOracleデータベースに作成し、キャッシュ・グリッドおよびキャッシュ・グループ操作の実行に必要な最小限の権限をそのユーザーに付与する必要があります。『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のOracle Databaseでのユーザーの作成に関する説明を参照してください。 |
キャッシュ管理ユーザーとしてスタンバイ・マスター・データベースに接続し、ttCacheUidPwdSet組込みプロシージャを呼び出して、新しいキャッシュ管理ユーザーの名前とパスワードを設定します。接続文字列内のOraclePWD接続属性で、Oracleデータベースのキャッシュ管理ユーザーのパスワードを必ず指定してください。
ttIsql "DSN=master2;UID=cacheuser2;PWD=cachepwd;OraclePWD=oracle"
Command> call ttCacheUidPwdSet('cacheuser2','oracle');
スタンバイ・マスター・データベースでttCacheStart組込みプロシージャを呼び出し、キャッシュ・エージェントを起動します。
Command> call ttCacheStart();
スタンバイ・マスター・データベースでttRepStart組込みプロシージャを呼び出し、レプリケーション・エージェントを起動します。
Command> call ttRepStart();
レプリケーション状態は、自動的にSTANDBYに設定されます。ttRepStateGet組込みプロシージャをコールしてこれを確認できます。(非同期で実行され、少し時間がかかります。)
Command> call ttRepStateGet(); < STANDBY, NO GRID > 1 row found.
スタンバイ・マスター・データベースでCREATE READONLY CACHE GROUP文を使用し、読取り専用キャッシュ・グループをすべて作成します。
Command> CREATE READONLY CACHE GROUP cacheuser2.readcache
AUTOREFRESH INTERVAL 10 SECONDS
FROM oratt.readtbl
(keyval NUMBER NOT NULL PRIMARY KEY, str VARCHAR(32));
|
注意: キャッシュ管理ユーザーが、Oracleデータベースのキャッシュ・グループ表に対するSELECT権限を持っていることを確認してください。この例でcacheuser2ユーザーは、Oracleデータベースのorattユーザーによって所有されているreadtbl表に対するSELECT権限を持っています。詳細は、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュするOracleデータベース表の作成に関する説明を参照してください。 |
スタンバイ・マスター・データベースでLOAD CACHE GROUP文を使用し、Oracleデータベース表からTimesTenキャッシュ・グループにデータをロードします。
Command> LOAD CACHE GROUP cacheuser2.readcache
COMMIT EVERY 200 ROWS;
アクティブ・マスター・データベースで更新を生成しているすべてのアプリケーションを一時停止します。
アクティブ・マスター・データベースで、スタンバイ・マスター・データベースのDSNおよびホストを使用して、ttRepSubscriberWait組込みプロシージャを呼び出します。たとえば、すべてのトランザクションをmaster2hostホスト上のmaster2データベースにレプリケートするには、次のようにします。
Command> call ttRepSubscriberWait(NULL,NULL,'master2','master2host',120);
アクティブ・マスター・データベースでttRepStop組込みプロシージャを呼び出し、レプリケーション・エージェントを停止します。
Command> call ttRepStop();
アクティブ・マスター・データベースでttRepDeactivate組込みプロシージャを呼び出し、アクティブ・マスター・データベースのレプリケーション状態をIDLEに設定します。
Command> call ttRepDeactivate();
スタンバイ・マスター・データベースでttRepStateSet組込みプロシージャを呼び出し、スタンバイ・マスター・データベースのレプリケーション状態をACTIVEに設定します。このデータベースとそのホストが、アクティブ・スタンバイ・ペアのレプリケーション・スキームでアクティブ・マスターになります。
Command> call ttRepStateSet('ACTIVE');
|
注意: この例では、master2hostホスト上のmaster2データベースが、アクティブ・スタンバイ・ペアのレプリケーション・スキームでアクティブ・マスターになったところです。同様に、master1hostホスト上のmaster1は、これ以降、アクティブ・スタンバイ・ペアのレプリケーション・スキームにおけるスタンバイ・マスターとみなされます。 |
新しいアクティブ・マスター・データベースでttRepStop組込みプロシージャを呼び出し、レプリケーション・エージェントを停止します。
Command> call ttRepStop();
アクティブ・マスター・データベースでALTER CACHE GROUP文を使用し、すべてのキャッシュ・グループのAUTOREFRESHモードをPAUSEDに設定します。
Command> ALTER CACHE GROUP cacheuser2.readcache
SET AUTOREFRESH STATE PAUSED;
アクティブ・マスター・データベースでDROP ACTIVE STANDBY PAIR文を使用し、アクティブ・スタンバイ・ペアを削除します。
Command> DROP ACTIVE STANDBY PAIR;
アクティブ・マスター・データベースでCREATE ACTIVE STANDBY PAIR文を使用し、キャッシュ・グループを含めた新しいアクティブ・スタンバイ・ペアを作成します。各データベースのTCP/IPポートは必ず明示的に指定してください。
Command> CREATE ACTIVE STANDBY PAIR master1 ON "master1host",
master2 ON "master2host"
STORE master1 ON "master1host" PORT 20000
STORE master2 ON "master2host" PORT 20010;
アクティブ・マスター・データベースでttRepStateSet組込みプロシージャを呼び出し、アクティブ・マスター・データベースのレプリケーション状態をACTIVEに設定します。
Command> call ttRepStateSet('ACTIVE');
アクティブ・マスター・データベースでttRepStart組込みプロシージャを呼び出し、レプリケーション・エージェントを起動します。
Command> call ttRepStart();
ステップ21で停止したアプリケーションがあれば再開し、新しいアクティブ・マスター・データベースに接続します。
新しいスタンバイ・マスター・ホストでttDestroyユーティリティを実行し、新しいスタンバイ・マスター・データベースを破棄します。
ttDestroy master1
古いリリースを削除し、新しいリリースのTimesTenをスタンバイ・マスター・ホストにインストールします。
ttRepAdminユーティリティで新しいスタンバイ・マスター・データベースを複製することによって、新しいスタンバイ・マスター・データベースを作成します。たとえば、master2hostホスト上のmaster2データベースをmaster1データベースに複製するには、master1データベースを含むホストで次のように実行します。
ttRepAdmin -duplicate -from master2 -host master2host -UID pat -PWD patpwd -keepCG -cacheUid cacheuser2 -cachePwd cachepwd master1
スタンバイ・マスター・ホストでttAdminユーティリティを実行し、スタンバイ・マスター・データベースのキャッシュ・エージェントを起動します。
ttAdmin -cacheStart master1
スタンバイ・マスター・ホストでttAdminユーティリティを実行し、スタンバイ・マスター・データベースのキャッシュ・エージェントを起動します。
ttAdmin -repStart master1
非同期ライトスルー・キャッシュ・グループのあるアクティブ・スタンバイ・ペアのシナリオでTimesTenメジャー・アップグレードを実行するには、オフライン・アップグレードが必要です。これについては、後の項で説明します。
キャッシュ・グループを使用したアクティブ・スタンバイ・ペアのシナリオで、リリース11.2.1.x.xからリリース11.2.2.x.xへのTimesTenメジャー・アップグレードを実行するには、次の手順を実行します。このアップグレードはオフラインで実行する必要があります。
|
注意: この手順では、7.0.x以前のTimesTenリリースからのアップグレードはサポートされていません。その場合は、代替として、アップグレード前にレプリケーション・スキームからキャッシュ・グループを除外し、キャッシュ・グループを使用しないアップグレードの手順を使用して、除外したキャッシュ・グループをアップグレード後にレプリケーション・スキームに含めます。キャッシュ・グループを使用しないアップグレードについては、「アクティブ・スタンバイ・ペアのオンライン・メジャー・アップグレード」を参照してください。 |
この手順では、アクティブ・マスター・データベースmaster1はホストmaster1host、スタンバイ・マスター・データベースmaster2はホストmaster2hostにあるとします。(ここで述べている組込みプロシージャおよびユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「組込みプロシージャ」および「ユーティリティ」を参照してください。)
アップグレード前に、アクティブ・データベースの更新をすべて停止します。
master1から、ttRepSubscriberWait組込みプロシージャをコールし、すべてのデータ更新がスタンバイ・データベースに適用されるようにします。numsecには適切な待機時間を指定します。
call ttRepSubscriberWait(null, null, 'master2', 'master2host', numsec);
master2から、ttRepSubscriberWait組込みプロシージャをコールし、すべてのデータ更新がOracle Databaseに適用されるようにします。
call ttRepSubscriberWait(null, null, '_ORACLE', null, numsec);
master1hostで、ttAdminユーティリティを使用してアクティブ・データベースのレプリケーション・エージェントを停止します。
ttAdmin -repStop master1
master2hostで、ttAdminを使用してスタンバイ・データベースのレプリケーション・エージェントを停止します。
ttAdmin -repStop master2
master1hostで、ttCacheStop組込みプロシージャをコールするか、ttAdminを使用してアクティブ・データベースのキャッシュ・エージェントを停止します。
ttAdmin -cacheStop master1
master2hostで、ttCacheStopをコールするか、ttAdminを使用してスタンバイ・データベースのキャッシュ・エージェントを停止します。
ttAdmin -cacheStop master2
master1hostで、ttMigrateユーティリティを使用して、アクティブ・データベースをバイナリ・ファイルにバックアップします。
ttMigrate -c master1 master1.bak
master1hostで、ttDestroyユーティリティを使用してアクティブ・データベースを破棄します。-forceオプションを使用するか、最初にすべてのキャッシュ・グループを削除する必要があります。-forceを使用する場合は、後でスクリプトcacheCleanup.sqlを実行します。
ttDestroy -force /data_store_path/master1
cacheCleanup.sqlスクリプトは、キャッシュ・ユーザーとしてOracle Databaseに接続後に実行するSQL*Plusスクリプトで、TimesTen_install_dir/oraclescriptsディレクトリにあります。パラメータとして、TimesTenのホスト名とデータベース名をフルパスを指定します。詳細は、Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイドの自動リフレッシュ・キャッシュ・グループで使用されるOracle Databaseオブジェクトの削除に関する説明を参照してください。
古いバージョンを削除し、新しいメジャー・リリースのTimesTenをmaster1hostにインストールします。詳細は、「UNIXシステムへのTimesTenのインストール」または「WindowsシステムへのTimesTenのインストール」を参照してください。
ttIsqlとDSN接続属性設定AutoCreate=1を使用して、11.2.2.x.xに新しいデータベースを作成します。この新しいデータベースでキャッシュ・ユーザーを作成します。次の例は、このキャッシュ・ユーザーを作成し、適切なアクセス権を付与するためにttIsqlで実行する一連のコマンドを示しています。
次の手順のttMigrate -rを実行するには、キャッシュ・ユーザーにはADMIN権限が必要です。移行が完了したら、希望する場合は、このユーザーからADMIN権限を取り消します。
Command> CREATE USER cacheuser IDENTIFIED BY cachepassword; Command> GRANT CREATE SESSION, CACHE_MANAGER, CREATE ANY TABLE, DROP ANY TABLE TO cacheuser; Command> GRANT ADMIN TO cacheuser;
master1hostの新しいTimesTenインスタンスで、キャッシュ・ユーザーとしてttMigrateユーティリティを使用して、前に作成したバイナリ・ファイルからmaster1をリストアします。(この例では、20MB分のデータがリストアされるたびにチェックポイント操作が実行されます。Oracle DatabaseでのパスワードはTimesTenと同じとします。)
ttMigrate -r -cacheuid cacheuser -cachepwd cachepassword -C 20 -connstr "DSN=master1;uid=cacheuser;pwd=cachepassword;oraclepwd=cachepassword" master1.bak
master1hostで、ttAdminを使用してレプリケーション・エージェントを開始します。
ttAdmin -repStart master1
|
注意: また、この手順によりデータベースはアクティブ状態になります。ここでttRepStateGet組込みプロシージャ(パラメータなし)をコールして状態を確認できます。 |
master1hostで、ttCacheStart組込みプロシージャをコールするか、ttAdminを使用してキャッシュ・エージェントを開始します。
ttAdmin -cacheStart master1
次に、ttStatusユーティリティを使用して、レプリケーションおよびキャッシュ・エージェントが開始されているかを確認できます。
各自動リフレッシュ・キャッシュ・グループをAUTOREFRESH PAUSED状態にします。この例では、ttIsqlを使用します。
Command> ALTER CACHE GROUP mycachegroup SET AUTOREFRESH STATE paused;
master1から、各キャッシュ・グループを再ロードし、キャッシュ・グループの名前と捜査中のコミットの頻度を指定します。この例では、ttIsqlを使用します。
Command> LOAD CACHE GROUP cachegroupname COMMIT EVERY n ROWS;
オプションとして、パラレル・ロードも指定できます。LOAD CACHE GROUP SQL 文の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』を参照してください。
master2hostで、ttDestroyユーティリティを使用してスタンバイ・データベースを破棄します。-forceオプションを使用するか、最初にすべてのキャッシュ・グループを削除する必要があります。-forceを使用する場合は、前述のように後でスクリプトcacheCleanup.sqlを実行します。
ttDestroy -force /data_store_path/master2
古いバージョンを削除し、新しいメジャー・リリースのTimesTenをmaster2hostにインストールします。
master2hostの新しいTimesTenインスタンスでttRepAdminを-duplicateオプションで使用し、アクティブ・データベースmaster1の複製を作成してスタンバイ・データベースmaster2として使用します。master1の適切な管理ユーザーを指定し、キャッシュ・マネージャのユーザーとパスワードを指定し、キャッシュ・グループを保持します。
ttRepAdmin -duplicate -from master1 -host master1host -uid pat -pwd patpwd -cacheUid orcluser -cachePwd orclpwd -keepCG master2
master2hostで、ttAdminを使用してレプリケーション・エージェントを開始します。(かわりに、前の手順でttRepAdminオプションの-setMasterRepStartを使用できます。)
ttAdmin -repStart master2
master2で、レプリケーションの状態が自動的にSTANDBYに設定されます。ttRepStateGet組込みプロシージャをコールしてこれを確認できます。(非同期で実行され、少し時間がかかります。)
call ttRepStateGet();
master2hostで、ttCacheStart組込みプロシージャをコールするか、ttAdminを使用してキャッシュ・エージェントを開始します。
ttAdmin -cacheStart master2
その後、ttStatusユーティリティを使用して、レプリケーションおよびキャッシュ・エージェントが開始されているかを確認できます。
読取り専用のサブスクライバ・データベースを作成する場合は、各サブスクライバ・ホストで、ttRepAdminユーティリティの-duplicateオプションを使用して、スタンバイ・データベースを複製できます。次の例では、読取り専用のサブスクライバに適切なように、キャッシュ表を標準のTimesTen表に変換するため、前述の手順と同じADMINユーザーおよび-nokeepCGオプションを使用して、subscriber1を作成します。
ttRepAdmin -duplicate -from master2 -host master2host -nokeepCG -uid pat -pwd patpwd subscriber1
関連情報については、『Oracle TimesTen In-Memory Databaseレプリケーション・ガイド』の障害時リカバリ・サブスクライバのローリング・アウトに関する説明を参照してください。
この項では、Oracle ClusterwareとともにTimesTenを使用する場合のTimesTenのオフライン・アップグレードの手順を説明します。TimesTenのアップグレード中に、Oracle Clusterwareを独立してアップグレードするオプションもあります。(オンライン・アップグレードの詳細は、「Oracle Clusterware使用時のTimesTenのオンライン・アップグレードの実行」を参照してください。)
|
注意:
|
この手順では、特に記載されている場合を除き、クラスタ内のいずれのホストからでもttCWAdminコマンドを実行できます。各コマンドはすべてのホストに影響します。
アクティブ・スタンバイ・ペアのデータベースでレプリケーション・エージェントを停止します。
ttCWAdmin -stop -dsn advancedDSN
アクティブ・スタンバイ・ペアを削除します。
ttCWAdmin -drop -dsn advancedDSN
TimesTenクラスタ・エージェントを停止します。これによって、クラスタからホストが削除され、TimesTenデーモンが停止します。
ttCWAdmin -shutdown
目的のホストでTimesTenをアップグレードします。
TimesTenマイナー・アップグレードを実行するには、クラスタの各ノードに、同じメジャー・リリース・ライン(たとえばすべてがリリース11.2.2.x.xなど)のTimesTenがある必要があります。「インプレース・アップグレードの実行」のとおり、インプレース・アップグレードを実行できます。
TimesTenのメジャー・アップグレードを実行するには、オフライン・アップグレードの実行に関する説明のとおり、ttMigrateを使用する必要があります。
Oracle Databaseドキュメントの説明に従って、必要に応じてOracle Clusterwareをアップグレードします。
「Installing and Upgrading」リンクを選択します。
ご使用のプラットフォームのGrid Infrastructureインストール・ガイドを参照します。
『Oracle Clusterware管理およびデプロイメント・ガイド』のOracle Clusterwareのアップグレードの概要に関する説明も参照してください。
TimesTenで使用するには、Clusterwareリリース11.1.0.7から11.2.0.3にアップグレードするか、11.2.0.2から11.2.0.3にアップグレードできますが、11.1.0.7から11.2.0.2へはアップグレードできません。
Oracle Clusterwareをアップグレード済の場合、ttmodinstallユーティリティ(『Oracle TimesTen In-Memory Databaseリファレンス』を参照)を使用して、Oracle ClusterwareでTimesTenを構成します。各ホストには、次を入力します。
ttmodinstall -crs
ttmodinstallによってttcrsagent.optionsファイルを上書きする権限が要求された場合、yes(デフォルト)を選択します。
ttcrsagent.optionsの関連情報については、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の各ホストへのTimesTenインストールに関する説明およびTimesTenクラスタ・エージェントの開始に関する説明を参照してください。
TimesTenクラスタ・エージェントを起動します。これには、ttcrsagent.optionsで指定されたクラスタ内で定義されたホストを含みます。これにより、TimesTenデーモンも起動します。
ttCWAdmin -init
アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。
ttCWAdmin -create -dsn advancedDSN
重要: このコマンドを実行するホストからcluster.oracle.iniファイルにアクセスできる必要があります。(このファイルの詳細は『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のcluster.oracle.iniファイルによるOracle Clusterware管理の設定に関する説明を参照してください。)
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn advancedDSN
この項では、アクティブ・スタンバイ・ペアがOracle Clusterwareによって管理されている構成で、TimesTenのオンライン・ローリング・インプレース・マイナー・バージョン・アップグレード(TimesTenのリリース11.2.2.x.xから新しいリリース11.2.2.x.xへのアップグレード)を実行する方法について説明します。(オフライン・アップグレードの詳細は、「Oracle Clusterware使用時のTimesTenのオフライン・アップグレードの実行」を参照してください。)
この章では、次の項目について説明します。
|
注意:
|
TimesTenのオンライン・ローリング・インプレース・アップグレードには、次の基本構成がサポートされています。いずれの場合も、Oracle Clusterwareによってホストが管理されます。
2つのホスト上の1つのアクティブ・スタンバイ・ペア。
各ホストに1つのTimesTenデータベースを備えた複数のアクティブ・スタンバイ・ペア。
各ホストに1つ以上のTimesTenデータベースを備えた複数のアクティブ・スタンバイ・ペア。
(追加のスペア・システムを備えたものなど、他のシナリオもこれらのシナリオの1つと事実上同等です。)
Oracle Clusterwareを使用しているときにTimesTenをアップグレードするための次の前提に注意してください。
既存のアクティブ・スタンバイ・ペアは適切に構成され、動作しています。
スタンバイ・データベースを停止および起動するためのOracle Clusterwareコマンドは、適切に使用されています。
インプレース・アップグレードを実行しても、アクティブ・データベースおよびスタンバイ・データベース用のTimesTen環境は変化しません。
インプレース・アップグレードは、TimesTen 11.2.2.x.xリリースから、後のTimesTen 11.2.2.x.xリリースに対するものです。これらの手順はTimesTenのマイナー・アップグレード専用です。Oracle Clusterwareによってアクティブ・スタンバイ・ペアが管理される構成では、現時点でオンライン・メジャー・アップグレードはサポートされていません。
Oracle Clusterwareは、リリース11.2.0.2または11.2.0.3です。
インプレース・アップグレードは、各ホストの1つのTimesTenインストールに適用されます。
少なくとも2つのホストがOracle Clusterwareによって管理されています。
Oracle Clusterwareによって管理されている複数のアクティブ・データベースまたはスタンバイ・データベースは、クラスタに少なくとも2つのホストがある場合のみホストに存在できます。
|
重要:
|
|
注意: Oracle Clusterwareのアップグレードについては、Oracle Databaseのドキュメントを参照してください。
『Oracle Clusterware管理およびデプロイメント・ガイド』のOracle Clusterwareのアップグレードの概要に関する説明も参照してください。 |
この項では、次の作業について説明します。
|
注意: 次の項の例では、ホスト名はhost2、DSNはmyDSN、TimesTenインスタンス名はupgrade2およびインスタンス管理者はterryです。 |
これらの手順を実行して、アクティブ・スタンバイ・ペアが適切に機能していることを確認します。
次のことを確認します。
アクティブ・データベースおよびスタンバイ・データベースでTimesTen 11.2.2.x.xリリースが実行されます。
アクティブ・データベースおよびスタンバイ・データベースは、Oracle Clusterwareによって管理される別々のホストです。
レプリケーションが機能しています。
アクティブ・スタンバイ・ペアのレプリケーション・スキームにキャッシュ・グループが含まれている場合、次のことが正しくなります。
AWTおよびSWTによる、スタンバイTimesTenデータベースからOracle Databaseへの書込みが機能しています。
Oracle DatabaseからアクティブTimesTenデータベースへのリフレッシュが機能しています。
ttCWAdmin -status -dsn yourDSNコマンドを入力して、次のことを確認します。
アクティブ・データベースは、スタンバイ・データベースとは違うホストにあります。
アクティブ・データベースの状態は'ACTIVE'で、ステータスは'AVAILABLE'です。
スタンバイ・データベースの状態は'STANDBY'で、ステータスは'AVAILABLE'です。
アクティブ・データベースでttStatusコマンドを入力して、次のことを確認します。
ttCRSactiveserviceおよびttCRSmasterプロセスが実行されています。
サブデーモンおよびレプリケーション・エージェントが実行されています。
アクティブ・スタンバイ・ペアのレプリケーション・スキームにキャッシュ・グループが含まれている場合、キャッシュ・エージェントは実行されています。
スタンバイ・データベースでttStatusコマンドを入力して、次のことを確認します。
ttCRSsubserviceおよびttCRSmasterプロセスが実行されています。
サブデーモンおよびレプリケーション・エージェントが実行されています。
アクティブ・スタンバイ・ペアのレプリケーション・スキームにキャッシュ・グループが含まれている場合、キャッシュ・エージェントは実行されています。
スタンバイ・データベースを停止するには、次の手順を実行します。
次のようなOracle Clusterwareコマンドを入力して、スタンバイ・データベースのホスト上のOracle Clusterwareマスター・プロセス、デーモン・プロセスおよびエージェント・プロセスの名前を取得します。grep TTによって出力がフィルタされています。
crsctl status resource -n standbyHostName | grep TT
Oracle Clusterwareコマンドを使用してスタンバイ・データベースを停止します。Oracle Clusterwareコマンドは、スタンバイ・データベースのマスター・プロセス、TimesTenインストールのデーモン・プロセスおよびTimesTenインストールのエージェント・プロセスを停止します。
crsctl stop resource TT_Master_upgrade2_terry_myDSN_1 crsctl stop resource TT_Daemon_upgrade2_terry_host2 crsctl stop resource TT_Agent_upgrade2_terry_host2
TimesTenメイン・デーモンを停止します。
ttDaemonAdmin -stop
ttDaemonAdmin -stopコマンドでエラー10028が発生する場合は、コマンドを再試行してください。
次の手順で、スタンバイ・データベースのTimesTenインスタンスのインプレース・アップグレードを実行します。
現行のTimesTenリリースのインストール・メディアのsetup.shスクリプトを使用して、インプレース・アップグレードを実行します。インプレース・アップグレードは、スタンバイ・データベースの11.2.2.x.xインストールより前のものをアンインストールします。現行リリースの新しいインストールは、同じディレクトリ構造にインストールする必要があります。
インプレース・アップグレードは、スタンバイ・データベースに次のファイルを維持する必要があります。
スタンバイ・データベース・ファイル(チェックポイント・ファイル、トランザクション・ログ・ファイルなど)
sys.odbc.ini
ttendaemon.options
cluster.oracle.ini
(このファイルの詳細は『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のcluster.oracle.iniファイルによるOracle Clusterware管理の設定に関する説明を参照してください。)
ttcrsagent.options
このファイルの関連情報については、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の各ホストへのTimesTenインストールに関する説明およびTimesTenクラスタ・エージェントの開始に関する説明を参照してください。
tnsnames.ora
「インプレース・アップグレードの例」を参照してください。
Oracle Clusterware用の新しいインストールを構成します。
スタンバイ・データベースを起動するには、次の手順を実行します。
次のttCWAdminコマンドを入力して、TimesTenメイン・デーモン、TimesTen Oracle Clusterwareエージェント・プロセスおよびTimesTen Oracle Clusterwareデーモン・プロセスを起動します。
ttCWAdmin -init -hosts localhost
スタンバイ・データベースのOracle Clusterwareマスター・プロセスを起動します。
crsctl start resource TT_Master_upgrade2_terry_MYDSN_1
ttCWAdmin -switchコマンドを使用して、アクティブデータベースとスタンバイデータベースのロールを切り替えて、他のマスター・データベースのインプレース・アップグレードを有効にします。
ttCWAdmin -switch -dsn myDSN
次のタスクを起動する前に、ttCWAdmin -statusコマンドを使用して、切替え操作が完了したことを確認します。
Oracle Clusterware crsctl status resourceコマンドを使用して、新しいスタンバイ・データベースのホスト上のマスター・プロセス、デーモン・プロセスおよびエージェント・プロセスの名前を取得します。この例では、ホストhost1を想定し、grep TTにより出力をフィルタします。
crsctl status resource -n host1 | grep TT
「スタンバイ・データベースの停止」のときのようなコマンドを入力します。適切なインスタンス名、インスタンス管理者、DSNおよびホスト名を使用します。例:
crsctl stop resource TT_Master_upgrade2_terry_MYDSN_0 crsctl stop resource TT_Daemon_upgrade2_terry_host1 crsctl stop resource TT_Agent_upgrade2_terry_host1 ttDaemonAdmin -stop
「スタンバイ・データベースのインプレース・アップグレードの実行」のときのようなコマンドを入力します。
「スタンバイ・データベースの開始」を参照してください。ただし、前述の「新しいスタンバイ・データベースの停止」に記載のcrsctl status resourceコマンドで取得したマスター・プロセス名を使用します。
ttCWAdmin -init -hosts localhost crsctl start resource TT_Master_upgrade2_terry_MYDSN_0
前の項「1つのアクティブ・スタンバイ・ペアに対応したアップグレード・タスク」のとおり、複数ペアのホストで複数のアクティブ・スタンバイ・ペアのTimesTenインスタンスをアップグレードする処理は、2つのホストで1つのアクティブ・スタンバイ・ペアをアップグレードする処理と基本的に同じです。アクティブ・スタンバイ・ペアのアップグレードを一度に実行するのがベスト・プラクティスです。
ttCWAdmin -statusコマンドを使用して、Oracle Clusterwareによって管理されているデータベースの状態を調べます。
前の項「数多くのホストのペアでの複数アクティブ・スタンバイ・ペのアップグレード」の説明のとおり、複数のアクティブ・スタンバイ・ペアは複数ペアのホスト上に存在できます。または、複数のアクティブ・スタンバイ・ペアはホストの1つのペア上で構成できます。1つのシナリオとして、すべてのアクティブ・データベースを1つのホストで稼働させ、すべてのスタンバイ・データベースを別のホストで稼働させることができます。より典型的なシナリオでは、ワークロードのバランスを向上させるため、各ホストで複数のアクティブ・データベースとスタンバイ・データベースを稼働させることができます。
図3-1に、Oracle Clusterwareによって管理されている2つのホスト上の2つのアクティブ・スタンバイ・ペアを示します。host1上のactive1というアクティブ・データベースは、host2上のstandby1にレプリケートされます。host2上のactive2というアクティブ・データベースは、host1上のstandby2にレプリケートされます。両方のスタンバイ・データベースからのAWT更新は、Oracle Databaseに伝播されます。Oracle Databaseからの読取り専用の更新は、アクティブ・データベースに伝播されます。
この構成の場合、キャッシュ・グループ用の書込みスループットが増え、リソースの使用のバランスが向上することがあります。この種類の構成において、sys.odbc.iniのエントリ例およびcluster.oracle.iniファイルの例については、次の項「構成ファイルの例: ホストの1つのペア上の複数のアクティブ・スタンバイ・ペア」を参照してください。(このファイルの詳細は『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のcluster.oracle.iniファイルによるOracle Clusterware管理の設定に関する説明を参照してください。)
「数多くのホストのペアでの複数アクティブ・スタンバイ・ペのアップグレード」の説明のとおり、.ホストの1つのペア上の複数のアクティブ・スタンバイ・ペアをインプレース・ローリング・アップグレードする処理は、ホストの複数のペア上の複数のアクティブ・スタンバイ・ペアのアップグレードと本質的に同等です。
ただし、アクティブ・データベースとスタンバイ・データベースが2つのホストで混在している場合は、最初にすべてのスタンバイ・データベースを1つのホストに切り替え、すべてのアクティブ・データベースをもう1つのホストに切り替えます。ttCWAdmin -switch -dsn DSNコマンドを使用して、ホスト間のアクティブ・データベースとスタンバイ・データベースを切り替えます。すべてのアクティブ・データベースが1つのホストに切り替わり、すべてのスタンバイ・データベースがもう1つのホストに切り替わると、「スタンバイ」ホスト全体をアップグレードするために次の手順を実行します。
インプレース・アップグレードは、TimesTenインストール全体と、1つのホスト上にある関連のデータベースに影響を及ぼすことに注意してください。
スタンバイ・データベースが目的のホストで実行されることを確認します。ttCWAdmin -status -dsn DSNコマンドおよびttCWAdmin -statusコマンドを使用します。
Oracle Clusterware stopコマンドを変更して、すべてのスタンバイ・データベースがあるホスト上のすべてのマスター・プロセスを停止します。
Oracle Clusterware startコマンドを変更して、すべてのスタンバイ・データベースがあるホスト上のすべてのマスター・プロセスを起動します。
次の項では、関連した例について説明します。
次にsys.odbc.iniエントリの例を示します。
[databasea] Driver=/scratch/terry/TimesTen/upgrade2/lib/libtten.so DataStore=/scratch/terry/ds/databasea PermSize=40 TempSize=32 PLSQL=1 DatabaseCharacterSet=WE8MSWIN1252 OracleNetServiceName=ORCL [databaseb] Driver=/scratch/terry/TimesTen/upgrade2/lib/libtten.so DataStore=/scratch/terry/ds/databaseb PermSize=40 TempSize=32 PLSQL=1 DatabaseCharacterSet=WE8MSWIN1252 OracleNetServiceName=ORCL [databasec] Driver=/scratch/terry/TimesTen/upgrade2/lib/libtten.so DataStore=/scratch/terry/ds/databasec PermSize=40 TempSize=32 PLSQL=1 DatabaseCharacterSet=WE8MSWIN1252 OracleNetServiceName=ORCL [databased] Driver=/scratch/terry/TimesTen/upgrade2/lib/libtten.so DataStore=/scratch/terry/ds/databased PermSize=40 TempSize=32 PLSQL=1 DatabaseCharacterSet=WE8MSWIN1252 OracleNetServiceName=ORCL
次に、cluster.oracle.iniファイルの例を示します。
[databasea] MasterHosts=host1,host2 CacheConnect=Y [databaseb] MasterHosts=host2,host1 CacheConnect=Y [databasec] MasterHosts=host2,host1 CacheConnect=Y [databased] MasterHosts=host1,host2 CacheConnect=Y
cluster.oracle.iniファイルは、1つのアクティブ・データベースおよび1つのスタンバイ・データベースを各ホストに配置します。これを行うには、MasterHost属性に指定されているホスト名の順序を反転させます。
次のようなOracle Clusterwareコマンドを入力して、スタンバイ・データベースのホスト上のOracle Clusterwareマスター・プロセス、デーモン・プロセスおよびエージェント・プロセスの名前を取得します。grep TTによって出力がフィルタされています。
crsctl status resource -n standbyHostName | grep TT
次のスクリプトは、Oracle Clusterwareが管理する同じホスト上の複数のデータベース用のスタンバイの停止スクリプトの例です。TimesTenインスタンス名はupgrade2です。インスタンス管理者はterryです。ホストはhost2です。databaseaとdatabasebという2つのスタンバイ・データベースがあります。
crsctl stop resource TT_Master_upgrade2_terry_DATABASEA_0 crsctl stop resource TT_Master_upgrade2_terry_DATABASEB_1 crsctl stop resource TT_Daemon_upgrade2_terry_HOST2 crsctl stop resource TT_Agent_upgrade2_terry_HOST2 ttDaemonAdmin -stop
次のスクリプトは、同じ構成向けのスタンバイの開始スクリプトの例です。
ttCWAdmin -init -hosts localhost crs start resource TT_Master_upgrade2_terry_DATABASEA_0 crs start resource TT_Master_upgrade2_terry_DATABASEB_1
この項では、インプレース・アップグレードの例について説明します。
% ./setup.sh
There is 1 TimesTen instance installed locally :
1) sb1122 (TimesTen11.2.2.4)
Of the following options :
[1] Install a new instance
[2] Upgrade an existing instance
[3] Display information about an existing instance
[q] Quit the installation
Which would you like to perform? [ 1 ] 2
NOTE: There is only one instance which can be upgraded.
Instance Name : sb1122
Product Installed : TimesTen11.2.2.4
Installation Directory : /scratch/sboand/TimesTen/sb1122
BitLevel : 64
Component Installed : Client/Server and DataManager
Daemon Port : 33333
NOTE: Upgrading will remove the selected instance (and any directories or files
under its path) and then re-install into the same directory. You will
have the option to retain configuration files in :
/scratch/sboand/TimesTen/sb1122/info
Would you like to upgrade this instance? [ yes ]
NOTE: <install_dir>/info contains information related to the data
stores that have been created with this release. If you remove
/scratch/sboand/TimesTen/sb1122/info
you will no longer be able to access your data stores,
nor would you be able to restore nor migrate your data.
Would you also like to remove all files in <install_dir>/info? [ no ]
Would you like to remove the DemoDataStore directory in
/scratch/sboand/TimesTen/sb1122/info/DemoDataStore? [ yes ] no
Would you also like to remove all files in <install_dir>/network/admin/samples? [ no ]
/scratch/sboand/TimesTen/sb1122 Removed (retained <install_dir>/info)
TimesTen uninstall completed.
Of the three components:
[1] Client/Server and Data Manager
[2] Data Manager Only
[3] Client Only
Which would you like to install? [ 1 ]
Upgrading installation in /scratch/sboand/TimesTen/sb1122
Where would you like to create the daemon home directory?
[ /scratch/sboand/TimesTen/sb1122/info ]
The daemon logs will be located in /scratch/sboand/TimesTen/sb1122/info
Would you like to specify a different location for the daemon logs? [ no ]
Installing into /scratch/sboand/TimesTen/sb1122 ...
Uncompressing ...
NOTE: For security, we recommend that you restrict access to the
TimesTen installation to members of a single OS group. Only members of
that OS group will be allowed to perform direct mode connections to
TimesTen, and only members of that OS group will be allowed to perform
operations that access TimesTen data stores, TimesTen files and shared
memory. The OS group defaults to the primary group of the instance
administrator. You can default to this group, choose another OS group
or you can make this instance world-accessible. If you choose to make
this instance world-accessible, all database files and shared memory
are readable and writable by all users.
Restrict access to the TimesTen installation to the group 'g900'? [ yes ]
NOTE: Enabling PL/SQL will increase the size of some TimesTen libraries.
Would you like to enable PL/SQL for this instance? [ yes ]
Do you want to replace the ttendaemon.options file in
/scratch/sboand/TimesTen/sb1122/info? [ yes ] no
NOTE: The existing daemon options file has been retained. The default options
file was written as
/scratch/sboand/TimesTen/sb1122/info/ttendaemon.options.sb1122.
In order to use the 'TimesTen Cache' feature in any databases
created within this installation, you must set a value for the TNS_ADMIN
environment variable. It can be left blank, and a value can be supplied later
using <install_dir>/bin/ttModInstall.
A value for TNS_ADMIN (/scratch/sboand/TimesTen/sb1122/network/admin/samples) was
found in the previous daemon options file.
Please enter a value for TNS_ADMIN (s=skip)?
[ /scratch/sboand/TimesTen/sb1122/network/admin/samples ] s
Installing server components ...
What is the TCP/IP port number that you want the TimesTen Server to listen on?
[ 33334 ]
Do you want to install QuickStart and the TimesTen Documentation? [ no ]
Would you like to install the documentation (without QuickStart)? [ yes ] no
An existing cluster.oracle.ini file has been detected in
/scratch/sboand/TimesTen/sb1122/info.
Would you like to replace the existing cluster.oracle.ini file? [ no ]
The existing cluster.oracle.ini file will be used.
The sample cluster.oracle.ini file will be saved as
'/scratch/sboand/TimesTen/sb1122/info/cluster.oracle.ini.tt1122'.
An existing sys.odbc.ini file has been detected in
/scratch/sboand/TimesTen/sb1122/info.
NOTE: You may not be able to successfully run the demos if you keep your
existing sys.odbc.ini file. If you choose to replace the existing
file, a backup will be made automatically.
Would you like to replace the existing
/scratch/sboand/TimesTen/sb1122/info/sys.odbc.ini file ? [ no ]
The existing sys.odbc.ini file will be used.
The sample sys.odbc.ini file will be saved as
'/scratch/sboand/TimesTen/sb1122/info/sys.odbc.ini.sb1122'.
An existing tnsnames.ora file has been detected in
/scratch/sboand/TimesTen/sb1122/network/admin/samples.
Would you like to replace the existing
/scratch/sboand/TimesTen/sb1122/network/admin/samples/tnsnames.ora file ? [ no ]
The existing tnsnames.ora file will be used.
The sample tnsnames.ora file will be saved as
'/scratch/sboand/TimesTen/sb1122/network/admin/samples/tnsnames.ora.tt1122'.
Installing client components ...
An existing sys.ttconnect.ini file has been detected in
/scratch/sboand/TimesTen/sb1122/info.
NOTE: You may not be able to successfully run the Client/Server demos if you keep
your existing sys.ttconnect.ini file. If you choose to replace the existing
file, a backup will be made automatically.
Would you like to replace the existing
/scratch/sboand/TimesTen/sb1122/info/sys.ttconnect.ini file ? [ no ]
The existing sys.ttconnect.ini file will be used.
The sample sys.ttconnect.ini file will be saved as
'/scratch/sboand/TimesTen/sb1122/info/sys.ttconnect.ini.sb1122'.
Would you like to use TimesTen Replication with Oracle Clusterware? [ no ] yes
A Clusterware installation was detected in /scratch/oracle/crs/app/11.2.0/grid
Please provide the path to the Oracle Clusterware installation on this machine
(s=skip)? [ /scratch/oracle/crs/app/11.2.0/grid ]
NOTE: The TimesTen Clusterware agent port must be the same on all nodes
of the cluster. Please refer to the TimesTen documentation for
additional information.
Please enter a port number for the TimesTen Clusterware agent? [ 33339 ]
Executing '/scratch/oracle/crs/app/11.2.0/grid/bin/olsnodes' ...
Oracle Clusterware is currently configured on the following nodes :
1. host1
2. host2
3. host3
4. host4
5. host5
NOTE: By default, all of the nodes listed above will be added to the TimesTen
Replication with Oracle Clusterware configuration. You can also
specify your own list of nodes based on the list above.
Would you like to specify a node list for TimesTen Replication with Oracle
Clusterware? [ no ] yes
From the nodes above, please provide a list of nodes that you would like to add
(ex: 1,2 or skip)? [ ] 4,5
TimesTen Replication with Oracle Clusterware will be configured for the following nodes :
host4
host5
Are you sure? [ yes ]
Overwrite the existing TimesTen Clusterware options file? [ no ]
The new TimesTen Clusterware options file will be located here :
/scratch/sboand/TimesTen/sb1122/info/ttcrsagent.options.tt1122.
NOTE: The TimesTen daemon startup/shutdown scripts have not been installed.
Run the 'setuproot' script :
cd /scratch/sboand/TimesTen/sb1122/bin
./setuproot -install
This will move the TimesTen startup script into its appropriate location.
The startup script is currently located here :
'/scratch/sboand/TimesTen/sb1122/startup/tt_sb1122'.
The documentation was not installed.
To manually install the documentation, run the command 'setup.sh -installDoc'
The 11.2.2.6 Release Notes are located here :
'/scratch/sboand/TimesTen/sb1122/README.html'
Starting the daemon ...
TimesTen Daemon startup OK.
End of TimesTen installation.
自動パラレル・レプリケーションがデフォルトで有効化されます(TimesTenリリース11.2.2.2.0以上)。11.2.2の古いリリースおよびリリース11.2.1では、ユーザー独自のレプリケーションが利用可能でしたが、自動パラレル・レプリケーションは利用できませんでした。リリース11.2.2.8.0のTimesTenでは、コミット依存性を無効にした自動パラレル・レプリケーションが利用可能です。
|
注意: 『Oracle TimesTen In-Memory Databaseリファレンス』に記載されているReplicationApplyOrdering属性の値は変更されています。リリース11.2.2.2.0以上では、値0によって自動パラレル・レプリケーションが有効化されます。11.2.2.2.0よりも前のリリースでは、値0によってユーザー独自のパラレル・レプリケーションを無効化します。リリース11.2.2.8.0以上では、値に2を指定すると、コミット依存性を無効にして自動パラレル・レプリケーションを有効にすることができます。 |
パラレル・レプリケーションが有効でないデータベースから、パラレル・レプリケーションが有効なこのリリースのデータベースに、オンラインまたはオフラインのアップグレードを実行できます(コミット依存性は有効または無効)。
ここからは、オフライン・アップグレードが必要となるシナリオとともに、追加の考慮事項を説明します。
パラレル・レプリケーションを使用するシステムをアップグレードする際は、次の考慮事項に留意してください。
パラレル・レプリケーションを有効にしないアクティブ・スタンバイ・ペアを考慮します。TimesTenインスタンスをリリース11.2.2.3.0以上にアップグレードして自動パラレル・レプリケーションを使用するには(ReplicationApplyOrdering属性のデフォルト値は0)、アクティブ・スタンバイ・ペアをアップグレードする適切な手順を実行します。「アクティブ・スタンバイ・ペア・レプリケーションを使用したアップグレードの実行」を参照してください。
キャッシュ・グループがなく、自動パラレル・レプリケーションが有効なアクティブ・スタンバイ・ペア(ReplicationApplyOrderingの属性で値が0)を考えてみます。TimesTenインスタンスをリリース11.2.2.8.0以上にアップグレードし、コミット依存性を無効にして自動パラレル・レプリケーションを使用する(ReplicationApplyOrdering属性の値が2)には、アクティブ・スタンバイ・ペアをオンライン・メジャー・アップグレードする手順を実行します。「アクティブ・スタンバイ・ペアのオンライン・メジャー・アップグレード」を参照してください。データベースをリストアする前に、ReplicationApplyOrdering属性の値は0から2に変更する必要があります。例:
ttMigrate -r "DSN=master2;ReplicationApplyOrdering=2;ReplicationParallelism=2; LogBufParallelism=4" master2.bak
|
注意: 同じアクティブ・スタンバイ・ペアのオンライン・メジャー・アップグレード手順を使用すれば、ReplicationApplyOrdering=2のレプリケーション・スキームを持つTimesTenデータベースを、ReplicationApplyOrdering=0のデータベースにアップグレードできます。
コミット依存性を無効にした自動パラレル・レプリケーションでは、キャッシュ・グループなしの非同期アクティブ・スタンバイ・ペアのみがサポートされます。詳細は、『Oracle TimesTen In-Memory Databaseレプリケーション・ガイド』のパラレル・レプリケーションの構成に関する説明を参照してください。 |
ReplicationParallelism属性が1よりも大く、ReplicationApplyOrdering属性の値が異なるデータベース同士ではレプリケートできません。
次のシナリオの場合、オフライン・アップグレードを使用する必要があります。
ユーザー指定のパラレル・レプリケーションから自動パラレル・レプリケーションへ移行する場合。たとえば、11.2.2.3.0よりも前のリリースから、ReplicationApplyOrdering属性をデフォルト値(0)に設定したリリース11.2.2.3.0以上への場合。
自動パラレル・レプリケーション環境から、ReplicationParallelism属性の値によって示されるように異なるトラック数を持つ別の自動パラレル・レプリケーション環境へ移行する場合。
メジャー・リリース間(11.2.1.x.xから11.2.2.x.xなど)を移行し、非同期ライトスルー・キャッシュ・グループを使用する場合。
11.2.1.x.xにおける非同期ライトスルーの通常のレプリケーションから、11.2.2.x.xの非同期ライトスルーの自動パラレル・レプリケーションへ移行する場合。
オフライン・アップグレードの場合、「オフライン・アップグレードの実行」に記載されている手順を使用できます。あるいは、一方をアップグレードし、ttRepAdmin -duplicate -recreateコマンドを使用して新規データベースを作成できます。
データベースでレプリケーションを構成すると、ttMigrate -rコマンドを実行するたびに、接頭辞ttrep_schema_version-が付いた表の新しいセットが作成されます。これらの表には、リリース間にわたるレプリケーション・スキームの履歴が提供されます。
これらの表は、領域を大幅に消費するようなことはありません。また、アップグレードの問題をデバッグする際に役立ちます。ただし、ttMigrateを実行してもレプリケーションで問題が発生しなかった場合は、これらの表を削除することができます。
たとえば、2つの移行を実行した後、データベースに次のような表が含まれる場合があります。
TTREP_SCHEMA_VERSION_004.REPELEMENTS TTREP_SCHEMA_VERSION_004.REPLICATIONS TTREP_SCHEMA_VERSION_004.REPPEERS TTREP_SCHEMA_VERSION_004.REPSTORES TTREP_SCHEMA_VERSION_004.REPSUBSCRIPTIONS TTREP_SCHEMA_VERSION_004.REPTABLES TTREP_SCHEMA_VERSION_004.TTSTORES TTREP_SCHEMA_VERSION_005.REPELEMENTS TTREP_SCHEMA_VERSION_005.REPLICATIONS TTREP_SCHEMA_VERSION_005.REPPEERS TTREP_SCHEMA_VERSION_005.REPSTORES TTREP_SCHEMA_VERSION_005.REPSUBSCRIPTIONS TTREP_SCHEMA_VERSION_005.REPTABLES TTREP_SCHEMA_VERSION_005.TTSTORES
TimesTen Serverは、TimesTen Client ODBCドライバ・リリース6.0以上にリンクされているすべてのユーザー・アプリケーションと直接通信できます。TimesTen Client/Serverインストールをアップグレードする場合、データベースへのクライアント・アクセスの要件に応じて少なくとも次の2つの方法があります。
アップグレード対象のTimesTenインスタンスのデータベースをクライアント・アプリケーションで継続して使用可能にする必要がない場合は、以前のバージョンのサーバーを停止し、ttMigrateを使用してデータベースの移行を実行した後で、新しいリリースのサーバーを起動できます。新バージョンのサーバーは、以前のリリースと同じサーバー・ポートでリスニングが行われるように構成する必要があります。
データベースをクライアント・アプリケーションで継続して使用可能にする必要がある場合は、「レプリケーションを使用したオンライン・アップグレードの実行」の手順を実行して、データベースの1つ目のコピーの移行時に2つ目のコピーを継続して使用可能にすることができます。
最小限の再構成で新しいメジャー・リリースへのTimesTen Client/Serverシステムのオンライン・アップグレード(11.2.1.x.xから11.2.2.x.xなど)を実行するには、次の手順を実行します。
以前のリリースのTimesTenのTimesTen Serverを停止します。この時点から新しいリリースのTimesTen Serverが起動される時点まで、クライアント・アプリケーションからデータベースにアクセスすることはできません。クライアントでデータベースを更新しようとしても正常には実行されないため、必要に応じて、ユーザー・アプリケーションを停止する必要があります。
新しいリリースのTimesTenをインストールします。インストール時に、以前のリリースのTimesTenと同じポートでリスニングが行われるようにサーバーを構成します。
ttMigrateを使用してデータベースを以前のリリースから新しいリリースに移行します。この手順の例については、「TimesTenの他のメジャー・リリースへの移行」を参照してください。
新しいリリースのTimesTen Serverを起動します。これで、アップグレード後のデータベースにクライアント・アプリケーションからアクセスできるようになります。
|
注意: この手順では、両方のリリースのTimesTen Serverが同じポートでリスニングを行うように構成されているため、以前のリリースのサーバーを再起動するには、まず、異なるポートでリスニングが行われるようにそのサーバーを構成する必要があります。 |
ttMigrateを使用してデータベースを移行するプロセスは、データベースが非常に大規模な場合、時間がかかる可能性があります。クライアント/サーバーのオンライン・アップグレード手順の実行時にクライアント・アプリケーションからデータベースにほとんど途切れずアクセスする必要がある場合は、次の手順を実行して、オンライン・アップグレードを実行する手順をレプリケーションに統合することができます。
以前のリリースと同じポートでリスニングが行われるようにTimesTen Serverが構成されていることを確認して、新しいリリースのTimesTenをインストールします。インストール・スクリプトで、新しいサーバーを起動するかどうかを尋ねられます。noと答える必要があります。
「レプリケーションを使用したオンライン・アップグレードの実行」の手順を実行して、データベースのいずれかのコピーでTimesTenインスタンスをアップグレードします。クライアント・アプリケーションはもう一方のアップグレードされないデータベースのコピーに接続されたままです。
すべてのクライアントを以前のリリースのデータベースから切断します。
以前のリリースのTimesTen Serverを停止します。
以前のリリースから新しいリリースへのデータベースのすべての更新が終了するまで待機します。
新しいリリースのTimesTen Serverを起動します。これは以前のリリースと同じポートでリスニングを開始するため、構成を変更せずにクライアント・アプリケーションを新しいリリースのデータベースに接続できるようになります。
