| Oracle® TimesTen In-Memory Databaseインストレーション・ガイド リリース11.2.1 B55285-05 |
|
 戻る |
 次へ |
TimesTenデータベースが共有メモリー上にある場合、そのサイズ、ロギング・オプション、TimesTenソフトウェアのリリース番号、チェックポイントとディスク上のトランザクション・ログ・ファイルの位置など、その属性の多くは固定です。この章では、新しいリリースのTimesTenをインストールする際のそれらの属性の変更、およびTimesTenデータベースのアップグレードの手順について説明します。
次の項では、インストールしたTimesTenリリースの互換性およびキャラクタ・セットについて説明します。
以前のリリースのTimesTenでは、リリースを示すのに5つの数字(7.0.0.0.0以上)または3つの数字(7.0.0.0.0より前のリリースで、6.0.17など)を使用していました。TimesTenリリース11.2.1.1.0以上、TimesTenのリリース番号は3つの部分で構成されています。最初の3つの数字は、11.2.1など、TimesTenのメジャー・リリースを示します。4つ目の数字はTimesTenのメジャー・リリースのパッチ・リリースを示し、5つ目の数字はポート・パッチを示します。たとえば、TimesTenリリース番号11.2.1.5.1は、TimesTenリリース11.2.1の5つ目のパッチ・リリース、1つ目のポート・パッチであることを示しています。
TimesTenデータベースは、メジャー・リリース間では互換性はありませんが、パッチ・リリース間では常に互換性があります。たとえば、TimesTenリリース7.0.5.1.0で作成したデータベースは、TimesTenリリース11.2.1.1.0アプリケーションと互換性はありませんが、TimesTen 11.2.1.1.0で作成したデータベースは、TimesTenリリース11.2.1.5.0アプリケーションと互換性があります。
TimesTenのリリースを指す場合、リリース番号はメジャー・リリース番号のみに省略されることがよくあります。たとえば、リリース11.2.1.1.0は11.2.1に省略される場合があります。
TimesTenでは、下位互換性のために保持されている元のTimesTenデータ型に加え、Oracleデータ型を選択できます。すべてのデータ型の詳細は、Oracle TimesTen In-Memory Database SQLリファレンスのデータ型の仕様に関する説明を参照してください。いくつかのOracleデータ型の名前は、下位互換用のTimesTenデータ型と同じであるため、データ型を示すのに一連の別名があります。別名がどのデータ型を示すかは、データベースに設定されたTypeModeによって異なります。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のTypeModeに関する説明を参照してください。
TimesTenの下位互換用のデータ型は、リリース7.0より前のTimesTenデータ型とレプリケーション互換があります。ただし、TimesTenの下位互換用のデータ型は、TimesTen IMDB Cache to Oracleと互換性がなく、IMDB Cache to Oracleでは、Oracleデータ型のみを使用します。IMDB Cache to Oracleを使用する場合は、ttMigrateを使用してデータベースのアップグレードを実行する際に、元のTimesTenデータ型を新しいOracleデータ型に変換する必要があります。詳細は、「Oracleデータ型へのデータ型の変換」を参照してください。
Oracleデータ型は、リリース7.0より前のTimesTenとレプリケーション互換がありません。7.0より前のTimesTenとのレプリケーションが必要なアップグレードを実行する場合は、元のデータ型をTimesTenデータ型にアップグレードする必要があります。詳細は、「TimesTenデータ型としてのデータ型のアップグレード」を参照してください。
TimesTenでは、データベースの作成時に特定のキャラクタ・セットをサポートするようにデータベースを構成する必要があります。データベースのキャラクタ・セットは、データベース属性DatabaseCharacterSetを使用して指定します。この属性の値は、キャラクタ・フィールドに対して入出力されるキャラクタと、キャラクタ・データの格納およびソート方法を決定するために使用されます。詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のデータベースのキャラクタ・セットの選択に関する説明を参照してください。
TimesTen 7.0より前のリリースからデータベースをアップグレードする前に、データベースのDSNにDatabaseCharacterSet属性を追加して、データベース・キャラクタ・セットを指定する必要があります。リリース7.0より前のTimesTenでは、この属性は無視されます。ほとんどの場合、現在の地域で意味をなすものであり、ご使用のデータベースに存在するキャラクタ・データと一致するデータベース・キャラクタ・セットを選択します。ただし、次の3つの重要な制限を考慮する必要があります。
TimesTen IMDB Cache to Oracleとともにデータベースを使用する場合は、TimesTenデータベースが接続するOracleデータベースで指定したキャラクタ・セットと同じDatabaseCharacterSetの値を指定する必要があります。
キャラクタ・セットが異なるデータベース間でレプリケーションは実行できません。リリース7.0より前のTimesTenで作成されたデータベースには、データベース・キャラクタ・セットが指定されていないため、特別なデータベース・キャラクタ・セット(TIMESTEN8)が作成され、TimesTenの現行のリリースで作成したデータベースと、それより前のリリースで作成したデータベースの間でレプリケーションの互換性が保持されます。レプリケーションを使用したオンライン・アップグレードとしてデータベースをアップグレードする場合は(「レプリケーションを使用したオンライン・アップグレードの実行」を参照)、DSNでDatabaseCharacterSetとしてTIMESTEN8を指定する必要があります。
TimesTen Client/Serverを使用しており、TimesTen 7.0より前のリリースからアップグレード済の、Client ODBCライブラリとリンクしたアプリケーションを持つデータベースに接続する場合は、互換性を確保するために、DSNにDatabaseCharacterSetとしてTIMESTEN8を指定する必要があります。「TimesTenリリース6.0以上からのクライアント/サーバーのオンライン・アップブレードの実行」を参照してください。
|
注意: TIMESTEN8データベース・キャラクタ・セットは、リリース7.0より前のTimesTenから移行する場合のみ使用します。データベースをリリース7.0より前のTimesTenにレプリケートしたり、7.0より前のクライアント・アプリケーションに接続する必要がない場合は、ttMigrateを使用して、データベースをTIMESTEN8以外のデータベース・キャラクタ・セットに変換する必要があります。詳細は、「データベース・キャラクタ・セットの変換」を参照してください。 |
TimesTenには、データベースのアップグレード時に使用可能な3つのユーティリティが含まれています。
ttBackupユーティリティおよびttRestoreユーティリティではそれぞれ、TimesTenデータベースのイメージ・コピーをエクスポートおよびインポートできます。このデータベース・イメージは、TimesTenのパッチ・リリース間でのみ互換性があるため、バックアップおよびリストア時にビットレベルが同じ(32-bitまたは64-bit)TimesTenを使用する必要があります。ttBackupおよびttRestoreユーティリティを使用して、次の操作を実行できます。
あるTimesTenインスタンスから、同じメジャー・リリース・バージョンのTimesTenを実行している別のTimesTenインスタンスへのデータベースの移動。
あるコンピュータから、同じメジャー・リリース・バージョンのTimesTenを実行している別のコンピュータへのデータベースの移動。
あるパッチ・リリースのTimesTen(11.2.1.1.0など)から別のパッチ・リリースのTimesTen(11.2.1.2.0など)へのデータベースの移動。
一方、ttMigrateユーティリティでは、TimesTenのメジャー・リリース間および32-bitと64-bitのバージョン間での移行に使用可能な、リリースに依存しない形式でTimesTenデータベースがエクスポートされます。次の操作を実行するには、ttMigrateユーティリティを使用する必要があります。
あるメジャー・リリースのTimesTen(7.0など)から別のメジャー・リリース(11.2.1など)へのデータベースの移動。
TimesTenの32-bitバージョンから64-bitバージョン(またはその逆)へのデータベースの移動。
TimesTenデータベースのサイズの縮小。
|
注意: ttMigrateユーティリティでは、異なるハードウェア・プラットフォーム間でデータベースを移行することはできません。たとえば、WindowsのデータベースをSolarisのデータベースに移行することはできません。また、ttMigrateのリリースは、コピー元またはコピー先となるデータベースのリリースと一致している必要があります。次の項で説明する手順では、以前のバージョンのttMigrateユーティリティを使用して元のデータベースの表をディスク・ファイルに保存し、新しいバージョンのttMigrateユーティリティを使用して新しいデータベースにファイルをリストアします。 |
Windowsでは、これらのユーティリティはODBC Driver Managerを使用します。
UNIXプラットフォームでは、これらのユーティリティはTimesTen Data Manager ODBCドライバに直接リンクしています。
これらのユーティリティとその他のユーティリティの構文と使用方法の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のユーティリティに関する説明を参照してください。
リリース11.2.1以上のTimesTenではアクセス制御は必須です。アクセス制御のない以前のバージョンのTimesTenを使用していて、現行のリリースへのアップグレード後に最初にデータベース・オブジェクトを保護しないようにするには、次のSQLコマンドを使用して、PUBLICにADMINシステム権限を付与する必要があります。
GRANT ADMIN TO PUBLIC;
PUBLICにADMIN権限を付与すると、すべてのユーザーがあらゆるデータベース・オブジェクトに対して無制限にアクセス可能になり、インスタンス管理者が実行する必要のあるタスク以外のすべての管理タスクを実行できるようになります。PUBLICへのADMIN権限の付与は、一時的な対処方法として、アップグレードの目的においてのみ行う必要があります。
|
注意: この方法ではシステムが本質的に安全でなくなるため、長期的には使用しないことをお薦めします。 |
TimesTen 7.0より前のリリースからアップグレードを実行する場合、データベースのデータ型をTimesTenデータ型として保持するか、またはOracleデータ型に変換するかを選択する必要があります。どちらを選択するかは、データベースの使用計画と希望のアップグレード方法によって決まります。
|
注意: TimesTen IMDB Cacheとともにデータベースを使用する場合は、データ型をOracleデータ型に変換する必要があります。ただし、この場合、レプリケーションを使用したオンライン・アップグレードは実行できません。データ型が同様のデータ型のみにレプリケートされる可能性があるためです。TimesTen 7.0以上からアップグレードする際にデータ型をOracleデータ型に変換済である場合、これは問題になりません。 |
TimesTen 7.0より前のリリースのデータ型をOracleデータ型に変換するには、アップグレード手順の一部としてデータベースをリストアする際に、ttMigrateの-convertTypesToOraオプションを使用する必要があります。たとえば、アップグレード手順の一部としてデータベースsalesdataをリストアする場合は、次のコマンドを使用してデータ型をOracleデータ型にアップグレードします。
ttMigrate -r -convertTypesToOra salesdata salesdata.mig
詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のTimesTenからOracleデータ型への変換に関する説明を参照してください。
|
注意: いくつかのデータ型についてOracleバージョンとTimesTenバージョンでは動作がわずかに異なるため、リリース7.0より前のTimesTen用に書かれたすべてのアプリケーションは、新しいリリースのTimesTenでデプロイする前に、Oracleデータ型を使用して十分テストする必要があります。 |
|
注意: レプリケーションを使用してオンライン・アップグレードを実行する場合は、データ型をTimesTenデータ型としてアップグレードする必要があります。詳細は、「レプリケーションを使用したオンライン・アップグレード」を参照してください。 |
TimesTen 7.0より前のリリースのデータベースのデータ型をTimesTenデータ型としてアップグレードする場合は、ttMigrateを使用してデータベースをリストアする際に特別なオプションを使用する必要はありません。TimesTen 7.0より前のリリースのデータ型は、自動的にTimesTenデータ型としてリストアされます。
DSN属性DatabaseCharacterSetを使用して、各TimesTenデータベースに対してキャラクタ・セットを指定する必要があります。いくつかの場合、アップグレード・プロセスの一部として、構成済のデータベース・キャラクタ・セットを変更する必要があります。データベース・キャラクタ・セットの変換が必要なケースには、次の2つがあります。
レプリケーションまたはクライアント/サーバー(あるいはその両方)を使用したオンライン・アップグレードによって、リリース7.0より前のTimesTenのデータベースをアップグレードするために、データベース・キャラクタ・セットをTIMESTEN8に指定しました。すべてのデータベースとクライアント・アプリケーションでアップグレードが完了したら、この特別な移行用のキャラクタ・セットから、地域で使用する各国のキャラクタ・セットに各データベースを変換する必要があります。「TIMESTEN8キャラクタ・セットからの変換」を参照してください。
データベースのキャラクタ・セットを、最初に指定したものから、より要件に合う新しいものに変更する必要があります。「TIMESTEN8以外のキャラクタ・セットからの変換」を参照してください。
ttMigrateを使用して、TIMESTEN8から他の任意のキャラクタ・セットにデータベースを変換する場合があります。次の手順を実行します。
ttMigrateを使用して、データベースをファイルに保存します。たとえば、データベースsalesdataをファイルsalesdata.migに保存するには、次のコマンドを使用します。
ttMigrate -c DSN=salesdata salesdata.mig
データベースを破棄します。
ttDestroy salesdata
データベースのDSN属性値DatabaseCharacterSetを、新しいキャラクタ・セットを指定する値に変更します。たとえば、データベースで、TIMESTEN8ではなくWE8ISO8859P1を使用する場合は、ODBCINIファイルで次の行を使用します。
DatabaseCharacterSet=WE8ISO8859P1
-noCharsetConversionコマンドライン・オプションを指定したttMigrateを使用して、データベースをファイルからロードします。このオプションでは、新しいキャラクタ・セットを使用してデータがDSNにロードされる際、キャラクタ値は変更されないことが保証されます。例:
ttMigrate -r -noCharsetConversion DSN=salesdata salesdata.mig
|
注意: データベースをTIMESTEN8から誤ったキャラクタ・セットに変換した場合は、キャラクタ・データに不要な変更を行わなくても、同じ手順を使用して、データベースを適切なキャラクタ・セットに変換できます。 |
ttMigrateを使用して、任意のキャラクタ・セットから他のキャラクタ・セットにデータベースを変換する場合があります。次の手順を実行します。
ttMigrateを使用して、データベースをファイルに保存します。たとえば、データベースsalesdataをファイルsalesdata.migに保存するには、次のコマンドを使用します。
ttMigrate -c DSN=salesdata salesdata.mig
データベースを破棄します。
ttDestroy salesdata
データベースのDSN属性値DatabaseCharacterSetを、新しいキャラクタ・セットを指定する値に変更します。たとえば、データベースで、WE8ISO8859P1を使用する場合は、ODBCINIファイルで次の行を使用します。
DatabaseCharacterSet=WE8ISO8859P1
ttMigrateを使用してデータベースをファイルからロードします。TimesTenによって、キャラクタ・データは、ファイルが保存されたキャラクタ・セットから、DSNによって使用されるキャラクタ・セットに自動的に変換されます。例:
ttMigrate -r DSN=salesdata salesdata.mig
|
注意: 特定のキャラクタ・セットでは、キャラクタ・セット間でマッピングが存在しない場合に、変換プロセスでキャラクタ・データが失われる可能性があります。 |
TimesTenでは、次のアップグレードを実行できます。
リリース11.2.1.1.0(11.2.1の最初のパッチ・リリース)からリリース11.2.1.2.0(11.2.1の2番目のパッチ・リリース)へ移行する場合など、TimesTenの新しいパッチ・リリースに移行するために、インプレース・アップグレードを使用できます。以前のリリースのTimesTenを削除した後、TimesTenの新しいパッチ・リリースをインストールして、新しいリリースの既存のデータベースに接続できます。既存のデータベースに対しては、特別な処理は不要です。
インプレース・アップグレード: アップグレード処理中、すべてのアプリケーションをデータベースから切断する必要があります。インプレース・アップグレードでは、TimesTenのバックアップおよび移行ユーティリティを使用しなくても、既存のデータベースを維持できます。
オフライン・アップグレードの実行中、アプリケーションはデータベースを使用できません。通常、オフライン・アップグレード処理には、アップグレードしたデータベースをコピーするための十分なディスク領域が必要となります。
オフライン・アップグレードは、次の目的に使用します。
TimesTenの新しいメジャー・リリースまたはパッチ・リリースへの移行
異なるディレクトリまたはコンピュータへの移行
データベースのサイズの縮小
32-bitおよび64-bitのデータベース間での移行
アプリケーションによるデータベースへの継続的なアクセスが不要であれば、オフライン・アップグレードを実行します。たとえば、週末に保守作業が予定されている場合は、その時にアップグレードを実行します。
オフライン・アップグレードでは、アップグレード処理中、すべてのアプリケーションをデータベースから切断する必要があります。また、共有メモリーのデータベースをアンロードする必要もあります。オフライン・アップグレードでは、TimesTenのttMigrateまたはttBackupユーティリティを使用する必要があります。(『Oracle TimesTen In-Memory Databaseリファレンス』のttMigrateおよびttBackupに関する項を参照してください。)
TimesTenの新しいメジャー・リリースにアップグレードする場合、連続してアプリケーションを使用可能な状態にする必要があるミッション・クリティカルなデータベースがある場合があります。データベースが異なるリリースのTimesTenで構成されている場合でも、TimesTenレプリケーションを使用して、データベースの2つのコピーの同期をとることができます。これによって、データベースの一方のコピーをアップグレードしている間に、もう一方のコピーにアプリケーションを接続したままにできます。アップグレードが完了すると、アクティブなデータベースに対して行われたすべての更新は、アップグレードされたデータベースに即時に送信されるため、アプリケーションは、データの損失や停止時間なしでアップグレードされたデータベースに切り替えることができます。詳細は、「レプリケーションを使用したオンライン・アップグレードの実行」を参照してください。
オンライン・アップグレード処理は、アップグレード実行中のユーザー表の更新のみをサポートします。CREATE TABLEやCREATE INDEXなどのデータ定義への変更はレプリケートされません。また、レプリケートする表には、PRIMARY KEYまたは一意索引(NULLを指定できない列)が含まれている必要があります。アップグレードするデータベースの2つのコピーが必要なため、アップグレードを1つのシステムで実行する場合は、データベースが通常必要とする量の2倍のメモリーとディスク領域を使用可能にします。
TimesTen Client/Serverインストールを新しいメジャー・リリースにアップグレードする場合は、クライアント/サーバー・オンライン・アップグレードを実行することによって、停止時間を最小限に抑えることができます。この処理の実行中に、以前のリリースのTimesTenクライアントは、新しいリリースにアップグレードされたデータベースと通信し続けることができます。「TimesTenリリース6.0以上からのクライアント/サーバーのオンライン・アップブレードの実行」を参照してください。
クライアント/サーバー・オンライン・アップグレード処理は、アップグレードするデータベースへのクライアント・アプリケーションのアクセスが中断するのを最小限に抑えますが、中断をなくすことはできません。すべてのクライアントに対するデータベースの、ほぼ連続した可用性を維持するには、「レプリケーションを使用したオンライン・アップグレード」に示す方法を使用します。この手順では、元のデータベースを新しいリリースにアップグレードしている間、同一のコピーが以前のリリースのTimesTen Serverに対し引き続き使用可能な状態になります。アップグレードした元のデータベースが新しいリリースのTimesTen Serverに対して使用可能になった後、同じポートをリスニングしたまま以前のリリースを停止し、新しいリリースを起動します。この方法で可用性が途切れるのは、以前のサーバーが停止してから新しいサーバーが起動するまでの非常に短い期間のみです。
Windowsの場合、複数のリリースのTimesTenを同時にインストールすることはできません。したがって、リリース6.0より前のTimesTenからアップグレードする場合、Windowsでは、クライアント/サーバーを使用したオンライン・アップグレードは実行できません。また、2台の異なるコンピュータ(アップグレードする各リリースのデータベースごとに1台)を使用しないかぎり、クライアント/サーバー・オンライン・アップグレードの手順と、レプリケーションを使用したオンライン・アップグレードを実行するための手順を組み合せることはできません。
既存のデータベースを、外部形式にエクスポートせずにアップグレードするには、インプレース・アップグレードを実行します。インプレース・アップグレードを実行するには、すべてのアプリケーションをデータベースから切断し、データベースを共有メモリーからアンロードする必要があります。次の項では、データベースのインプレース・アップグレードの実行方法について説明します。
TimesTenデータベースは、アプリケーションまたはTimesTenエージェント(キャッシュ・エージェントやレプリケーション・エージェントなど)が接続している間は共有メモリーにロードされたままです。また、ttAdminユーティリティを使用してデータベースのRAMポリシーを変更した場合は、アプリケーションまたはエージェントが接続していなくても、データベースは共有メモリーに保持されます。(『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する項を参照してください。) データベースをアンロードするには、次の手順を実行します。
すべてのアプリケーションをデータベースから切断します。
この例では、データベースoriginalは、以前のリリースからのデータベースです。データベースupgradeは、新しいリリースのデータベースです。レプリケーションを開始している場合、データベースのレプリケーションを中断し、次のコマンドを使用して、メモリーからアンロードするデータベースのレプリケーションを停止します。
ttRepAdmin -receiver -name upgrade -state pause original ttRepAdmin -receiver -name original -state pause upgrade ttAdmin -repStop upgrade
データベースのキャッシュ・エージェントを起動している場合は、次のコマンドを使用してキャッシュ・エージェントを停止します。
ttAdmin -cacheStop upgrade
RAMポリシーがデータベースのアンロードを許可するかを確認します。RAMポリシーがmanualに設定されている場合は、次のコマンドを使用してデータベースをアンロードします。
ttAdmin -ramUnload upgrade
RAMポリシーがalwaysまたはinUseに設定されている場合は、manualに変更します。RAMポリシーがinUseであり、猶予期間が設定されている場合は、猶予期間に0(ゼロ)を設定するか、または猶予期間に設定した時間が経過するまで待機します。
ttStatusユーティリティを使用して、データベースがメモリーからアンロードされたことを確認します。(『Oracle TimesTen In-Memory Databaseリファレンス』のttStatusに関する説明を参照してください。)
データベースに同時接続されるすべてのアプリケーションは、同じメジャー・リリースのTimesTen ODBCドライバと直接リンクする必要があります。パッチ・リリースが異なるTimesTenデータベースは、構造的には同等または同じです。たとえば、リリース11.2.1.1.0から11.2.1.3.0へのアップグレードでは、ttMigrateユーティリティを使用して既存のデータベースを移行する必要はありません。ただし、新しいメジャー・リリースまたはパッチ・リリースのインストール時には、アプリケーションを切断し、TimesTenデーモンを停止する必要があります。これらの手順を明示的に実行していない場合は、以前のリリースのTimesTenデーモン・プロセスが停止され、事実上すべてのアプリケーションがデータベースから切断されます。アップグレードの準備として、TimesTenをアップグレードする前に、すべてのデータベースがメモリーからアンロードされていることを確認します。
データベースをメモリーからアンロードする手順については、「データベースのアンロード」を参照してください。
データベースを外部ファイルにエクスポートし、変更したデータベースをインポートすることで、オフライン・アップグレードを実行できます。このような更新手順を実行するには、すべてのアプリケーションをデータベースから切断し、共有メモリーからデータベースをアンロードする必要があります。継続的な接続を必要とするアプリケーションについては、「レプリケーションを使用したオンライン・アップグレードの実行」を参照してください。
|
注意: アップグレードされるデータベースをレプリケートする場合は、ttMigrateを使用して、データベースをリリース間で移動する必要があります。また、ttMigrate -r -renameオプションを使用して、表の所有者の名前を変更する場合は、レプリケーション・スキームに関連している他のすべてのデータベースの表の所有者の名前も変更する必要があります。 |
パッチ・リリース間での移動など、データベースのサイズや構造を変更する必要のない単純なアップグレードには、ttBackupおよびttRestoreユーティリティを使用できます。メジャー・リリースのアップグレードなど、データベースの構造を変更する必要のあるアップグレードには、ttMigrateユーティリティを使用する必要があります。ttMigrateユーティリティは、リリースに依存しないより柔軟な形式でデータベースをエクスポートします。ttBackupユーティリティは、パッチ・リリース間のみで互換性のあるデータベースのイメージ・コピーをエクスポートします。データベースを異なるコンピュータまたはディレクトリに移動する場合は、ttBackupユーティリティを使用します。次の処理を行うには、ttMigrateユーティリティを使用する必要があります。
TimesTenの新しいメジャー・リリースまたはパッチ・リリースへの移行
データベースのサイズの縮小
32-bitおよび64-bitのデータベース間での移行
オフライン・アップグレードの一般的な手順は、次のとおりです。
すべてのアプリケーションをデータベースから切断し、メモリーからデータベースをアンロードします。詳細は、「データベースのアンロード」を参照してください。
-cおよび-noRepUpgradeオプションを指定してttMigrateを使用するか、またはttBackupを使用してデータベースをバックアップします。
新しいリリースのTimesTenをインストールします。詳細は、「TimesTenのインストール」を参照してください。
-rおよび-noRepUpgradeオプションを指定してttMigrateを使用するか、またはttRestoreを使用して、バックアップしたデータベースをTimesTenの新しいリリースにリストアします。
アップグレードしたデータベースにアプリケーションを再接続します。
|
注意: ttMigrateを使用した後は、アクティブ・スタンバイ・ペアを構成しないリストア先データベースのすべての自動リフレッシュ・キャッシュ・グループで、ソース・データベースでの設定にかかわらずAUTOREFRESH STATEがOFFに設定されます。ALTER CACHE GROUP文を使用して、AUTOREFRESH STATEをONに設定しなおしてください。 |
TimesTenデーモンは、データベースのチェックポイント・ファイルのフルパス名を使用してデータベースを識別します。TimesTenデータベースを別のディレクトリに移動するには、ttBackupユーティリティを使用してデータベースをバックアップし、新しいデータベースのパス名を示す新しいDSN定義を作成します。その後で、ttRestoreを使用して、データベースを新しい場所にリストアします。新しい場所でデータベースが適切に機能することを確認してから、ttDestroyを使用してディスク領域を解放し、以前のデータベースを削除します。
たとえば、一時記憶域として/tmp/dumpディレクトリを使用し、/old/SalesData/salesのデータベースSalesData(DSN=SalesData)を、NewSalesData(DSN=NewSalesData)という名前で/new/SalesData/salesに移動するには、次のコマンドを使用します。
mkdir /tmp/dump
ttBackup -dir /tmp/dump -fname salesdata "DSN=SalesData"
NewSalesDataデータベースのDSN定義を作成して、新しいデータベースのパス/new/SalesData/sales/NewSalesDataを指定します。
ttRestore -dir /tmp/dump -fname salesdata "DSN=NewSalesData"
(NewSalesDataが正常に動作することを確認します。)
rm -r /tmp/dump
ttDestroy /old/SalesData/sales/SalesData
SalesDataデータベースのDSN定義を削除します。
|
注意: 移動したデータベースをレプリケートするように構成した場合、レプリケーションを再構成する必要があります。 |
ttBackupおよびttRestoreユーティリティを使用して、同じCPUアーキテクチャを持ち、同じオペレーティング・システムを実行している2つのコンピュータ間でデータベースを移動することができます。
|
注意: レプリケートしたデータベースを他のコンピュータに移動する前に、TimesTenレプリケーションを実行しておく必要があります。この手順については、Oracleサポート・サービスにお問い合せください。 |
CPUアーキテクチャとオペレーティング・システムが同じシステム間でデータベースをコピーするには、次の手順を実行します。
ttBackupを使用して、元のシステムのデータベースをバックアップします。
バックアップを新しいシステムに移動します。
移動したデータベースにレプリケートするすべてのデータベースのレプリケーション・スキームを再構成して、新しいホスト・コンピュータを指定します。(レプリケーション・スキームでのホストの指定方法の詳細は、『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』を参照してください。)
ttRestoreを使用して、バックアップをリストアします。
次の例では、ttBackupの-oフラグを使用して、バックアップに標準出力を適用します。-oフラグを使用すると、バックアップは単一のファイルに格納され、ネットワークを介して他のシステムに簡単にコピーすることができます。他のシステムにデータベースをコピーした後で、新しいデータベースのコピーにアクセスできるように、データソース名を作成する必要があります。
ソース・システムの/ds/Sales/Dataのデータベースsalesdataを、宛先システムの/data/Sales/Viewのデータベースsalesviewに移動するには、次のコマンドを使用します。
| 手順 | ソース・システム上 | 宛先システム上 |
|---|---|---|
| 1. | ttBackup -o "DSN=SalesData" >/tmp/salesbackup |
|
| 2. | /tmp/salesbackupとして宛先システムに対してftp /tmp/salesbackupを実行します。
注意: |
|
| 3. | ttRestore -i"DSN=SalesView" </tmp/salesbackup |
|
| 4. | rm /tmp/salesbackup |
|
| 5. | rm /tmp/salesbackup |
データベースに特定のサイズの永続パーティション(PermSize DSN属性で示される)を定義した場合は、表または行を削除しても、それより小さいサイズでロードすることはできません。ttBackupで作成したデータベースのコピーにも、データベースの永続パーティションのサイズが適用されます。
データベースの永続パーティションの割当てサイズを減らすには、ttMigrateユーティリティに-noRepUpgradeオプションを指定して、コピーを保存します。その後、永続パーティションのサイズを小さくしてデータベースを再作成し、データをリストアします。
|
注意: データベースの永続パーティションのサイズは、現在、データベースに格納されているデータで実際に必要なサイズより小さくすることはできません。この値は、表sys.monitorのperm_in_use_size列を問い合せることによって判断できます。 |
データベースの永続パーティションのサイズを小さくするには、次の手順を実行します。
ttMigrate -c -noRepUpgradeを使用して、以前のデータベースをバックアップします。
より小さいPermSize値を指定するデータベースの新しいコピー用に、新しいDSN定義を作成します。
ttMigrate -r -noRepUpgradeを使用して、バックアップをリストアします。
|
注意: 手順2で新しいDSNを作成するのではなく、元のDSNを変更する場合は、ttDestroyユーティリティを使用して元のデータベース・ファイルを破棄してから、バックアップをリストアする必要があります。 |
次に示す手順では、データベースのサイズを400MBから100MBに縮小します。データベースは/ds/Sales/Dataに格納されており、DSNはsalesdataです。
ttMigrate -c -noRepUpgrade DSN=salesdata /tmp/salesbackup
ttDestroy salesdata
DSN salesdataを更新して、サイズを100MBにします。
ttMigrate -r -noRepUpgrade "DSN=salesdata;AutoCreate\=1" /tmp/salesbackup
|
注意: DSNのTempSize属性を変更し、データベースをメモリーからアンロードしてから再接続することで、データベースの一時パーティションのサイズを変更することが可能です。データベースをメモリーからアンロードする手順については、「データベースのアンロード」を参照してください。 |
32-bitのTimesTenデータベースの内部形式は、64-bitの形式とは異なります。32-bitのデータベースを64-bitのデータベースに変換するには、次の手順を実行します。
TimesTenの32-bitのttMigrateユーティリティに-noRepUpgradeオプションを指定して使用し、32-bitのデータベースをエクスポートします。
64-bitのデータベースのデータソース名(DSN)を作成します。詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のUNIX上でのデータ・マネージャDSNの作成に関する項またはWindows上でのデータ・マネージャDSNの作成に関する項を参照してください。
64-bitのttMigrateユーティリティに-noRepUpgradeオプションを指定して使用し、手順1で作成したファイルを64-bitデータベースのDSNにインポートします。
たとえば、32-bitデータベースのDSNがsalesdata32で、64-bitデータベースのDSNがsalesdata64であると想定します。TimesTenの32-bitインスタンスが/opt/TimesTen/giraffe32に、64-bitインスタンスが/opt/TimesTen/giraffe64にインストールされているとすると、必要な手順は次のとおりです。
/opt/TimesTen/giraffe32/bin/ttMigrate -c -noRepUpgrade DSN=salesdata32/tmp/salesbackup
/opt/TimesTen/giraffe64/bin/ttMigrate -r -noRepUpgrade "DSN=salesdata64;AutoCreate=1"/tmp/salesbackup
|
注意: TimesTenは、32-bitおよび64-bitのデータベース間でのレプリケーションをサポートしません。 |
TimesTenの複数のメジャー・リリースを、システムに同時にインストールすることができます。ただし、あるメジャー・リリースで作成したTimesTenのデータベースには、異なるメジャー・リリースのアプリケーションから直接アクセスすることはできません。たとえば、TimesTenのメジャー・リリース間でのデータの移行を、TimesTen 6.0から11.2.1で行う場合、ttMigrateユーティリティを使用して以前のリリースのデータをエクスポートし、さらにttMigrateユーティリティを使用して新しいリリースからインポートする必要があります。このアップグレードの手順は、「32-bitおよび64-bitのデータベース間での移動」の手順に似ています。
互いにレプリケートする2つ以上のデータベースをアップグレードする必要がある場合は、レプリケーションがアップグレート中およびアップグレード後も確実に動作し続けるように、いくつかの追加の手順を実行する必要があります。たとえば、レプリケートする2つのデータベース(ホスト・コンピュータmasterhostのmaster1とホスト・コンピュータsubscriberhostのsubscriber1)をTimesTenリリース6.0からTimesTenリリース11.2.1に移行する場合、次の手順を実行します。
|
注意: TimesTen 11.2.1には、キャッシュ・グリッドという新しい機能が導入されています。この機能はデフォルトで有効になっていますが、データベースにキャッシュ・グループを作成する前に追加の構成を行う必要があります。11.2.1より前のリリースのキャッシュ・グループを含むデータベースをアップグレードする場合は、アップグレードの開始前に、各DSN定義でCacheGridEnable属性を0に設定しておく必要があります。詳細は、『Oracle In-Memory Database Cacheユーザーズ・ガイド』を参照してください。 |
レプリケーションに静的なTCP/IPポートを使用するように、両方のデータベースでレプリケーション・スキームを構成します。これが必要なのは、次の手順の途中で、異なる2つのTimesTenのリリース間でレプリケーションが発生するためです。レプリケーション・ポートを動的に割り当てるために各リリースが相手のメイン・デーモンを検出できない場合があります。詳細は、『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のポートの割当てに関する説明を参照してください。
コンピュータmasterhostで、6.0リリースのttAdminユーティリティを使用して、データベースのレプリケーション・デーモンを停止します。
ttAdmin -repStop master1
次に、リリース6.0のttMigrateユーティリティに-cオプションを指定して使用し、データベースmaster1をバイナリ・ファイルにバックアップします。
ttMigrate -c DSN=master1 master1.bak
リリース6.0のttDestroyユーティリティを使用して、データベースmaster1を破棄します。データベースのファイルは、data_store_pathディレクトリに格納されています。
ttDestroy /data_store_path/master1
リリース11.2.1のttMigrateユーティリティに-rオプションを指定して使用し、データベースmaster1をバイナリ・ファイルからリストアします。データベースをリストアすると、自動的にリリース6.0からリリース11.2.1にアップグレードされます。非常に大きいデータベースをリストアする場合は、ttMigrateに-Cオプションを使用して、データベースに対して定期的にチェックポイント操作を実行します。操作が完了する前にいくつかのポイントでリストアが失敗する場合は、これによって時間が節約されます。詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のチェックポイント操作に関する項を参照してください。
ttMigrate -r -C 20 DSN=master1 master1.bak
リリース11.2.1のttAdminユーティリティを使用して、レプリケーション・デーモンを起動します。
ttAdmin -repStart master1
この時点で、リリース11.2.1のデータベースmaster1とリリース6.0のデータベースsubscriber1の間でレプリケーションが行われます。
ここで、データベースsubscriber1をリリース6.0からリリース11.2.1にアップグレードします。次の手順を実行します。
コンピュータsubscriberhostで、リリース6.0のttAdminユーティリティを使用して、レプリケーション・デーモンを停止します。
ttAdmin -repStop subscriber1
リリース6.0のttDestroyユーティリティを使用して、データベースsubscriber1を破棄します。データベースのファイルは、data_store_pathディレクトリに格納されています。
ttDestroy data_store_path/subscriber1
11.2.1より前のリリースからアップグレードする場合は、レプリケーションを使用してデータベースを複製するためにADMIN権限を持つユーザーを作成する必要があります。たとえば、スタンバイ・マスター・データベースにパスワードpatpwdを使用するユーザーpatを作成するには、次のコマンドを使用します。
CREATE USER pat IDENTIFIED BY patpwd; GRANT ADMIN TO pat;
リリース11.2.1のttRepAdminユーティリティに-duplicateオプションを指定して使用し、レプリケーションによりデータベースsubscriber1をデータベースmaster1から複製します。
ttRepAdmin -duplicate -from master1 -host masterhost -uid pat -pwd patpwd -setMasterRepStart subscriber1
リリース11.2.1のttAdminユーティリティを使用して、レプリケーション・デーモンを起動します。
ttAdmin -repStart subscriber1
これで、データベースがアップグレードされ、互いにレプリケートされました。
「オフライン・アップグレードの実行」では、すべてのアプリケーションの停止が必要なTimesTenデータベースでの様々なメンテナンス操作について説明しました。この項では、TimesTenレプリケーション機能を使用して、データの継続使用が必要なアプリケーションのオンライン・アップグレードを実行する方法について説明します。オンライン・アップグレードは、TimesTenのメジャー・リリース間での移行時に実行できます。パッチ・リリースへの移行では、かわりにインプレースまたはオフライン・アップグレードを実行することもできます。
通常、データの高可用性が求められるアプリケーションでは、TimesTenレプリケーションを使用して、最新のデータベースのコピーを1つ以上保持しておきます。一方が更新中の場合にも、これらの2つのコピーをアプリケーションで使用できるように保持することで、オンライン・アップグレードが機能します。この項で説明する手順では、双方向のレプリケーション・スキームが構成されていて、2つのデータベースに対して実行されていると想定しています(『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』を参照)。
|
注意: 異なるリリース間でレプリケーションが機能するのは、最新リリースのTimesTenのデータベースが、以前のリリースのTimesTenのデータベースからアップグレードされている場合のみです。最新リリースのTimesTenで作成されたデータベースと、以前のリリースとのレプリケーションは、サポートされていません。たとえば、リリース5.1のTimesTenで作成されたデータベースと、リリース7.0のTimesTenで作成されたデータベース間のレプリケーションは、サポートされていません。ただし、あるデータベースをリリース5.1で作成し、もう一方のデータベースをリリース5.1で作成してから、リリース7.0にアップグレードした場合、これらのデータベース間ではレプリケーションがサポートされます。 |
|
注意: セキュリティ上の理由から、通常、TimesTen 7.0とそれより前のリリースのデータベースの間でのレプリケーションは許可されていません。レプリケーションを使用してオンライン・アップグレードを実行するには、TimesTen 7.0以上のメイン・デーモンを-insecure-backwards-compatオプションを使用して起動する必要があります。 |
次の項では、レプリケーションを使用したオンライン・アップグレードの実行方法について説明します。
以前のリリースのTimesTenから新しいリリースへのデータベースのアップグレードは、データベースのレプリケートされる2つのコピーのいずれかからすべてのアプリケーションを切断して、以前のリリースのttMigrateユーティリティを使用してデータベースのバックアップを作成し、新しいリリースのttMigrateユーティリティを使用して新しいリリースのデータベースにバックアップをロードしてから、すべてのアプリケーションをアップグレード済のデータベースに再接続することで実行されます。
|
注意: データベース・オブジェクトの所有者の名前を変更するために使用されるttMigrate -r -renameオプションは、オンライン・アップグレードでは使用できません。 |
オンライン・アップグレードの一般的な手順は、次のとおりです。
すべてのアプリケーションをアップグレードするデータベースから切断します。
アップグレードするシステムでレプリケーションを停止します。
-cオプションを指定して以前のリリースのttMigrateを使用し、アップグレードするシステムに存在するデータベースをバックアップします。
アップグレード中のシステムに新しいリリースのTimesTenをインストールします。
-rオプションを指定して新しいリリースのttMigrateを使用し、アップグレード中のシステムでレプリケートされたデータベースをリストアします。
アップグレードしたデータベースにすべてのアプリケーションを再接続します。
アップグレードしたシステムでレプリケーションを再起動します。
|
注意: ttMigrateを使用した後は、アクティブ・スタンバイ・ペアを構成しないアップグレード済データベースのすべての自動リフレッシュ・キャッシュ・グループで、アップグレード前のデータベースでの設定にかかわらずAUTOREFRESH STATEがOFFに設定されます。ALTER CACHE GROUP文を使用して、AUTOREFRESH STATEをONに設定しなおしてください。 |
継続的な可用性を維持するため、切断されたデータベースのコピーでアップグレードが実行される間、アプリケーションはデータベースのいずれかで引き続き実行されます。TimesTenレプリケーションでは、アップグレード期間中にデータベースのアクティブなコピーに加えられる更新を保持し、レプリケーションが再開されると更新内容をアップグレードされたデータベースに転送して適用します。レプリケートされた更新が完全に適用されると、アプリケーションはアップグレードされたデータベースに再接続されます。
次の表に、レプリケーションの実行中にオンライン・アップグレードを実行する手順を示します。アップグレード・システムは、データベースのアップグレードが実行されているシステムで、アクティブなシステムは、アプリケーションが引き続き接続されるデータベースを含むシステムです。
前述の手順をアップグレード・システムで実行した後、同じ手順を使用して、アクティブ・システムをアップグレードできます。
オンライン・アップグレードを実行できるのは、すべてのユーザー表がレプリケーション要件を満たしているデータベースに対してのみです。すべてのユーザー表には、PRIMARY KEY宣言が含まれているか、NULLを指定できない列に一意索引が宣言されている必要があります。
レプリケーションを使用してオンライン・アップグレードを実行する場合は、静的ポートを使用するようにレプリケーションを構成する必要があります。『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のポートの割当てに関する説明を参照してください。
双方向レプリケーション構成が存在しない1つのシステムでオンライン・アップグレードを実行する場合、アップグレード中のデータベースの2つのコピーをサポートするのに十分なメモリーとディスク領域が使用可能であることを確認する必要があります。アップグレード中は、元のデータベースとそのコピーの両方がアクティブなままです。本番アプリケーションのパフォーマンスを維持するために、2つ目のシステムでデータベースのコピーを作成することもできます。
ttMigrateユーティリティを使用して作成したデータベースのバックアップ・コピーを格納するために、追加のディスク領域を割り当てる必要があります。通常、バックアップ・コピーのサイズは、使用中のデータベースのサイズとほぼ同じです。このサイズを確認するには、ttIsqlを使用してsys.monitor表を問い合せます。
Command> SELECT perm_in_use_size FROM sys.monitor;
この項では、具体的な例を使用して、双方向でレプリケートされている2つのTimesTenデータベースをオンラインでアップグレードする手順について説明します。
|
注意: TimesTen 11.2.1には、キャッシュ・グリッドという新しい機能が導入されています。この機能はデフォルトで有効になっていますが、データベースにキャッシュ・グループを作成する前に追加の構成を行う必要があります。11.2.1より前のリリースのキャッシュ・グループを含むデータベースをアップグレードする場合は、アップグレードの開始前に、各DSN定義でCacheGridEnable属性を0に設定しておく必要があります。詳細は、『Oracle In-Memory Database Cacheユーザーズ・ガイド』を参照してください。 |
ここでは、アップグレードの対象となる2つのTimesTenシステムを、アップグレード・システム(TimesTenインスタンスとデータベースがアップグレードされる)およびアクティブ・システム(アップグレード期間中、操作可能でアプリケーションに接続される)と呼びます。この手順が完了した後、同じ手順を繰り返してアクティブ・システムをアップグレードできます。ただし、アップグレードされたTimesTenインスタンスを最初にテストするために、アクティブ・システムの変換を遅延することもできます。
この例では、アップグレード・システムは、サーバーupgradehost上のデータベースupgradeで構成されています。アクティブ・システムは、サーバーactivehost上のデータベースactiveで構成されています。
次に示す手順は、その順序どおりに示されています。オンライン・アップグレードの手順は、次のとおりです。
| 手順 | アップグレード・システム | アクティブ・システム |
|---|---|---|
| 1. | データベースがリリース間で通信できるように静的レプリケーション・ポート番号を設定し、ttIsqlを使用してレプリケーション・スキームrepschemeを変更します。
|
データベースがリリース間で通信できるように静的レプリケーション・ポート番号を設定し、ttIsqlを使用してレプリケーション・スキームrepschemeを変更します。
|
| 2. | データベースに接続されているすべての本番アプリケーションを切断します。かわりに、アップグレード・システムで実行されているワークロードがアクティブ・システムでの動作を開始する必要があります。 | ttRepAdminユーティリティを使用して、データベースactiveからデータベースupgradeへのレプリケーションを一時停止します。
ttRepAdmin -connStr DSN=active -receiver -name upgrade -state pause このコマンドにより、データベース |
| 3. | データベースactiveに送信されるすべてのレプリケーションの更新を待機します。データベースupgradeで、更新の確認用として予約されている表に認識可能な更新を適用することで、更新がすべて送信されたことを確認できます。データベースactiveに更新が適用されると、すべての以前の更新が送信されたことになります。 |
|
| 4. | ttAdminを使用して、レプリケーション・エージェントを停止します。
ttAdmin -repStop upgrade これ以降、データベース |
ttAdminを使用して、レプリケーション・エージェントを停止します。
ttAdmin -repStop active これ以降、データベース レプリケーション・エージェントの起動と停止の詳細は、『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のレプリケーション・エージェントの起動と停止に関する説明を参照してください。 |
| 5. | ttRepAdminを使用して、データベースupgradeからデータベースactiveへのレプリケーションを停止します。
ttRepAdmin -connStr DSN=upgrade -receiver -name active -state stop この手順によって、 |
|
| 6. | ttMigrateを使用して、データベースupgradeをバックアップします。データベースが非常に大規模な場合は、この手順に長時間かかる可能性があります。/backupファイル・システムに十分なディスク領域の空きがある場合は、次のttMigrateコマンドを使用します。
ttMigrate -c DSN=upgrade /backup/upgrade.dat |
|
| 7. | ttMigrateコマンドが正常に実行された場合、データベースupgradeを破棄します。
永続データベース(Temporary=0)を破棄するには、 ttDestroy upgrade 一時データベース(Temporary=1)を破棄するには、 ttAdmin -ramUnload upgrade |
データベースactiveのレプリケーション・エージェントを再開します。
ttAdmin -repStart active |
| 8. | 新しいリリースのTimesTenをインストールします。 | レプリケーション状態をstartに設定して、activeからupgradeへのレプリケーションを再開します。
ttRepAdmin -connStr DSN=active -receiver -name upgrade -start start |
| 9. | ttMigrateを使用して、手順6で作成したバックアップを新しいリリースのTimesTenのデータベースupgradeにロードします。
ttMigrate -r "DSN=upgrade;AutoCreate=0" /backup/upgrade.dat データベースが一時データベース(Temporary=1)の場合は、最初に ttAdmin -ramLoad upgrade 注意: この手順では、アップグレードしているTimesTenの新しいリリースの |
|
| 10. | ttRepAdminを使用して、データベース「アクティブ」の受信側の状態を再設定し、レプリケーションをstop状態に設定した後start状態に設定することで、レプリケーション・ブックマークおよびログを消去します。
ttRepAdmin -connStr DSN=upgrade -receiver -name active -reset ttRepAdmin -connStr DSN=upgrade -receiver -name active -state stop sleep 10 ttRepAdmin -connStr DSN=upgrade -receiver -name active -state start 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のパッチ・リリースをアップグレードするには、各データベースで次のタスクを実行します。
ttRepStop組込みプロシージャまたはttAdminユーティリティを使用して、データベースのレプリケーション・エージェントを停止します。たとえば、スタンバイ・データベースmaster2のレプリケーション・エージェントを停止するには、次のコマンドを使用します。
ttAdmin -repStop master2
TimesTenパッチをインストールします。「データベースのインプレース・アップグレードの実行」を参照してください。
ttRepStart組込みプロシージャまたはttAdminユーティリティを使用して、レプリケーション・エージェントを再開します。
ttAdmin -repStart master2
アクティブ・マスター・データベースをアップグレードするには、アクティブ・マスター・データベースとスタンバイ・マスター・データベースの役割を逆にしてから、インプレース・アップグレードを行う必要があります。
アクティブ・マスター・データベースで更新を生成しているすべてのアプリケーションを一時停止します。
スタンバイ・マスター・データベースの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)に接続します。
前のアクティブ・マスター・データベース(現在のスタンバイ・マスター・データベース)をアップグレードします。「データベースのインプレース・アップグレードの実行」を参照してください。
ttRepStart組込みプロシージャまたはttAdminユーティリティを使用して、アップグレードしたデータベースのレプリケーションを再起動します。
ttAdmin -repStart master2
新しくアップグレードしたデータベースを再びアクティブ・マスター・データベースにするには、『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のアクティブ・マスター・データベースとスタンバイ・マスター・データベースの役割の入替えに関する項を参照してください。
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 to TimesTen開発者および管理者ガイド』のアクティブ・スタンバイ・ペアの設定に関する項を参照してください。
アクティブ・スタンバイ・ペアをアップグレードする準備ができたら、アップグレードする必要のある最初のデータベースがスタンバイ・マスターとなります。このノードのアップグレード中はスタンバイ・マスター・データベースが存在しないため、アクティブ・マスター・データベースでの更新は、サブスクライバ・データベースに直接伝播されます。
アクティブ・マスター・データベースでttRepStateSave組込みプロシージャを実行して、アクティブ・マスター・データベースに、スタンバイ・マスターへの更新のレプリケートを停止するように指示ます。たとえば、ホストmaster2hostのスタンバイ・マスター・データベースmaster2へのレプリケートを停止するには、次のコマンドを使用します。
call ttRepStateSave( 'FAILED', 'master2', 'master2host' );
ttRepStop組込みプロシージャまたはttAdminユーティリティを使用して、スタンバイ・マスター・データベースのレプリケーション・エージェントを停止します。たとえば、スタンバイ・マスター・データベースmaster2のレプリケーション・エージェントを停止するには、次のコマンドを使用します。
ttAdmin -repStop master2
スタンバイ・マスター・データベースが存在するノードをアップグレードします。「オフライン・アップグレードの実行」を参照してください。
ttRepStart組込みプロシージャまたはttAdminユーティリティを使用してスタンバイ・マスター・データベースのレプリケーション・エージェントを開始します。
ttAdmin -repStart master2
アップグレードしたスタンバイ・マスター・データベースがアクティブ・マスター・データベースと同期化すると、このアップグレード済のスタンバイ・マスター・データは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
マスター・データベースを破棄したノードで、アップグレードを行います。データベース自体は破棄されているため、データベースをアップグレードする必要はありません。
11.2.1より前のリリースからアップグレードする場合は、現行のアクティブ・マスター・データベースを複製するために、このデータベースに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
サブスクライバ・データベースを破棄したノードで、アップグレードを実行します。
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 -cacheStop master2
ttRepStart組込みプロシージャまたはttAdminユーティリティを使用して、レプリケーション・エージェントを再開します。
ttAdmin -repStart master2
アクティブ・マスター・データベースをアップグレードするには、アクティブ・マスター・データベースとスタンバイ・マスター・データベースの役割を逆にしてから、インプレース・アップグレードを行う必要があります。
アクティブ・マスター・データベースで更新を生成しているすべてのアプリケーションを一時停止します。
スタンバイ・マスター・データベースの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)に接続します。
前のアクティブ・マスター・データベース(現在のスタンバイ・マスター・データベース)をアップグレードします。「データベースのインプレース・アップグレードの実行」を参照してください。
ttCacheStart組込みプロシージャまたはttAdminユーティリティを使用して、アップグレードしたデータベースのキャッシュ・エージェントを再開します。
ttAdmin -cacheStart master1
ttRepStart組込みプロシージャまたはttAdminユーティリティを使用して、アップグレードしたデータベースのレプリケーションを再起動します。
ttAdmin -repStart master1
新しくアップグレードしたデータベースを再びアクティブ・マスター・データベースにするには、『Oracle TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド』のアクティブ・マスター・データベースとスタンバイ・マスター・データベースの役割の入替えに関する項を参照してください。
TimesTenのメジャー・リリース間でアクティブ・スタンバイ・ペアをアップグレードする場合は、各データベースのTCP/IPポートを明示的に指定する必要があります。アクティブ・スタンバイ・ペアのレプリケーション・スキームで各データベースのPORT属性が構成されていない場合は、アップグレードの準備として次の手順を実行する必要があります。
アクティブ・マスター・データベースでttRepStateSave組込みプロシージャを実行して、アクティブ・マスター・データベースに、スタンバイ・マスターへの更新のレプリケートを停止するように指示ます。たとえば、ホストmaster2hostのスタンバイ・マスター・データベースmaster2へのレプリケートを停止するには、次のコマンドを使用します。
call ttRepStateSave( 'FAILED', 'master2', 'master2host' );
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 to TimesTen開発者および管理者ガイド』のアクティブ・スタンバイ・ペアの設定に関する項を参照してください。
スタンバイ・マスター・データベースが存在するノードで、メジャー・アップグレードを開始します。このノードのアップグレード中はスタンバイ・マスター・データベースが存在しないため、アクティブ・マスター・データベースでの更新は、サブスクライバ・データベースに直接伝播されます。
|
注意: TimesTen 11.2.1には、キャッシュ・グリッドという機能が導入されています。この機能はデフォルトで有効になっていますが、データベースにキャッシュ・グループを作成する前に追加の構成を行う必要があります。11.2.1より前のリリースからアップグレードする際は、アップグレードの開始前に、各DSN定義でCacheGridEnable属性を0に設定しておく必要があります。詳細は、『Oracle In-Memory Database Cacheユーザーズ・ガイド』を参照してください。 |
アクティブ・マスター・データベースでttRepStateSave組込みプロシージャを実行して、アクティブ・マスター・データベースに、スタンバイ・マスターへの更新のレプリケートを停止するように指示ます。たとえば、ホストmaster2hostのスタンバイ・マスター・データベースmaster2へのレプリケートを停止するには、次のコマンドを使用します。
call ttRepStateSave( 'FAILED', 'master2', 'master2host' );
ttRepStop組込みプロシージャまたはttAdminユーティリティを使用して、スタンバイ・マスター・データベースのレプリケーション・エージェントを停止します。たとえば、スタンバイ・マスター・データベースmaster2のレプリケーション・エージェントを停止するには、次のコマンドを使用します。
ttAdmin -repStop master2
ttCacheStop組込みプロシージャまたはttAdminユーティリティを使用して、スタンバイ・マスター・データベースのキャッシュ・エージェントを停止します。
ttAdmin -cacheStop master2
スタンバイ・マスター・データベースが存在するノードをアップグレードします。「オフライン・アップグレードの実行」を参照してください。
ttCacheStart組込みプロシージャまたはttAdminユーティリティを使用して、スタンバイ・マスター・データベースのキャッシュ・エージェントを開始します。
ttAdmin -cacheStart master2
ttRepStart組込みプロシージャまたはttAdminユーティリティを使用してスタンバイ・マスター・データベースのレプリケーション・エージェントを開始します。
ttAdmin -repStart master2
アップグレードしたスタンバイ・マスター・データベースがアクティブ・マスター・データベースと同期化すると、このアップグレード済のスタンバイ・マスター・データはRECOVERING状態からSTANDBY状態に移行します。また、アップグレード済のスタンバイ・マスター・データベースは、サブスクライバに更新の送信も開始します。スタンバイ・マスター・データベースがSTANDBY状態になるタイミングは、スタンバイ・マスター・データベースでttRepStateGet組込みプロシージャをコールすることで決まります。
call ttRepStateGet;
アクティブ・マスター・データベースで更新を生成しているすべてのアプリケーションを一時停止します。
スタンバイ・マスター・データベースのDSNおよびホストを使用して、アクティブ・マスター・データベースのttRepSubscriberWait組込みプロシージャを実行します。たとえば、すべてのトランザクションがホストmaster2hostのスタンバイ・マスターmaster2にレプリケートされるようにするには、次のコマンドを使用します。
call ttRepSubscriberWait( null, null, 'master2', 'master2host', 120 );
ttRepStop組込みプロシージャまたはttAdminユーティリティを使用して、アクティブ・マスター・データベースのレプリケーション・エージェントを停止します。たとえば、アクティブ・マスター・データベースmaster1のレプリケーション・エージェントを停止するには、次のコマンドを使用します。
ttAdmin -repStop master1
ttCacheStop組込みプロシージャまたはttAdminユーティリティを使用して、アクティブ・マスター・データベースのキャッシュ・エージェントを停止します。
ttAdmin -cacheStop master1
スタンバイ・マスター・データベースで、ttRepStateSet組込みプロシージャを使用して、データベースをACTIVE状態に設定します。このデータベースがアクティブ・スタンバイ・ペアのアクティブ・マスターになります。
call ttRepStateSet( 'ACTIVE' );
アクティブ・マスター・データベースでttRepStateSave組込みプロシージャを実行して、新しいアクティブ・マスター・データベース(この例では、master2)に、現在のスタンバイ・マスター(master1)への更新のレプリケートを停止するように指示します。たとえば、ホストmaster1hostのスタンバイ・マスター・データベースmaster1へのレプリケートを停止するには、次のコマンドを使用します。
call ttRepStateSave( 'FAILED', 'master1', 'master1host' );
ttDestroyユーティリティを次のように使用して、前のアクティブ・マスター・データベースを破棄します。
ttDestroy master1
マスター・データベースを破棄したノードで、アップグレードを行います。データベース自体は破棄されているため、データベースをアップグレードする必要はありません。
11.2.1より前のリリースからアップグレードする場合は、現行のアクティブ・マスター・データベースを複製するために、このデータベースにADMIN権限を持つユーザーを作成する必要があります。たとえば、スタンバイ・マスター・データベースにパスワードpatpwdを使用するユーザーpatを作成するには、次のコマンドを使用します。
CREATE USER pat IDENTIFIED BY patpwd; GRANT ADMIN TO pat;
ttRepAdminユーティリティを使用して、現行のアクティブ・マスター・データベースから新しいスタンバイ・マスター・データベースを複製します。たとえば、キャッシュ・ユーザーIDがterryでキャッシュ・パスワードがterrypwdのデータベースmaster1に、ホストmaster2hostのデータベースmaster2を複製するには、データベースmaster1を含むホストで次のコマンドを使用します。
ttRepAdmin -duplicate -from master2 -host master2host -uid pat -pwd patpwd -cacheuid terry -cachepwd terrypwd -keepCG -setMasterRepStart "DSN=master1;UID=;PWD=;PWDCrypt="
|
注意: データベースはインスタンス管理者のみが作成できますが、キャッシュ・グループを含むデータベースのDSNは多くの場合、UID、PWDまたはPWDCrypt属性(あるいはこれらすべての属性)で構成されます。複製時にttRepAdminユーティリティによってデータベースが作成されるようにするには、接続文字列でUID、PWDまたはPWDCrypt(あるいはこれらすべて)に空白値を指定して、インスタンス管理者として接続します。 |
ttCacheStart組込みプロシージャまたはttAdminユーティリティを使用して、新しいスタンバイ・マスター・データベースのキャッシュ・エージェントを開始します。
ttAdmin -cacheStart master1
ttRepStart組込みプロシージャまたはttAdminユーティリティを使用して新しいスタンバイ・マスター・データベースのレプリケーション・エージェントを開始します。
ttAdmin -repStart master1
ttRepStop組込みプロシージャまたはttAdminユーティリティを使用して、最初のサブスクライバ・データベースのレプリケーション・エージェントを停止します。たとえば、サブスクライバ・データベースsubscriber1のレプリケーション・エージェントを停止するには、次のコマンドを使用します。
ttAdmin -repStop subscriber1
ttDestroyユーティリティを使用して、サブスクライバ・データベースを破棄します。
ttDestroy subscriber1
サブスクライバ・データベースを破棄したノードで、アップグレードを実行します。
ttRepAdminユーティリティを使用して、スタンバイ・マスター・データベースからサブスクライバ・データベースを複製します。
ttRepAdmin -duplicate -from master1 -host master1host -uid scott -pwd tiger -noKeepCG -setMasterRepStart subscriber1
ttRepStart組込みプロシージャまたはttAdminユーティリティを使用して、複製したサブスクライバ・データベースのレプリケーション・エージェントを開始します。
ttAdmin -repStart subscriber1
TimesTen Serverは、TimesTen Client ODBCドライバ・リリース6.0以上にリンクされているすべてのユーザー・アプリケーションと直接通信できます。TimesTen Client/Serverインストールをアップグレードする場合、データベースへのクライアント・アクセスの要件に応じて少なくとも次の2つの方法があります。
アップグレード対象のデータベースをクライアント・アプリケーションで継続して使用可能にする必要がない場合は、以前のバージョンのサーバーを停止し、ttMigrateを使用してデータベースの移行を実行した後で、新しいリリースのサーバーを起動できます。新バージョンのサーバーは、以前のリリースと同じサーバー・ポートでリスニングが行われるように構成する必要があります。
データベースをクライアント・アプリケーションで継続して使用可能にする必要がある場合は、「レプリケーションを使用したオンライン・アップグレードの実行」の手順を実行して、データベースの1つ目のコピーの移行時に2つ目のコピーを継続して使用可能にすることができます。
|
注意: セキュリティ上の理由から、通常、TimesTen 7.0と以前のリリース間でのクライアント/サーバー通信は許可されていません。クライアント/サーバーを使用してオンライン・アップグレードを実行するには、TimesTen 7.0のメイン・デーモンを-insecure-backwards-compatオプションを使用して起動する必要があります。 |
最小限の再構成で新しいメジャー・リリースへのTimesTen Client/Serverシステムのオンライン・アップグレードを実行するには、次の手順を実行します。
以前のリリースのTimesTenのTimesTen Serverを停止します。この時点から新しいリリースのTimesTen Serverが起動される時点まで、クライアント・アプリケーションからデータベースにアクセスすることはできません。クライアントでデータベースを更新しようとしても正常には実行されないため、必要に応じて、ユーザー・アプリケーションを停止する必要があります。
新しいリリースのTimesTenをインストールします。インストール時に、以前のリリースのTimesTenと同じポートでリスニングが行われるようにサーバーを構成します。
ttMigrateを使用してデータベースを以前のリリースから新しいリリースに移行します。この手順の例は、「32-bitおよび64-bitのデータベース間での移動」を参照してください。
新しいリリースのTimesTen Serverを起動します。これで、アップグレードされたデータベースにクライアント・アプリケーションからアクセスできるようになります。
|
注意: この手順では、両方のリリースのTimesTen Serverが同じポートでリスニングを行うように構成されているため、以前のリリースのサーバーを再起動する必要がある場合は、まず、異なるポートでリスニングが行われるようにそのサーバーを構成する必要があります。 |
ttMigrateを使用してデータベースを移行するプロセスは、データベースが非常に大規模な場合、時間がかかる可能性があります。クライアント/サーバーのオンライン・アップグレード手順の実行時にクライアント・アプリケーションからデータベースにほとんど途切れずアクセスする必要がある場合は、次の手順を実行して、オンライン・アップグレードを実行する手順をレプリケーションに統合することができます。
以前のリリースと同じポートでリスニングが行われるようにTimesTen Serverが構成されていることを確認して、新しいリリースのTimesTenをインストールします。インストール・スクリプトで、新しいサーバーを起動するかどうかを尋ねられます。noと答える必要があります。
「レプリケーションを使用したオンライン・アップグレードの実行」の手順を実行して、データベースのいずれかのコピーをアップグレードします。クライアント・アプリケーションはもう一方のアップグレードされないデータベースのコピーに接続されたままです。
すべてのクライアントを以前のリリースのデータベースから切断します。
以前のリリースのTimesTen Serverを停止します。
以前のリリースから新しいリリースへのデータベースのすべての更新が終了するまで待機します。
新しいリリースのTimesTen Serverを起動します。これは以前のリリースと同じポートでリスニングを開始するため、構成を変更せずにクライアント・アプリケーションを新しいリリースのデータベースに接続できるようになります。
データベースでレプリケーションを構成すると、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
|
 Copyright © 1996, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|