| Oracle® TimesTen In-Memory Database Scaleoutユーザーズ・ガイド リリース18.1 E98636-05 |
|
 前 |
 次 |
次の章では、TimesTen Classicデータベースからデータを移行したり、リポジトリを使用したり、TimesTen Scaleoutデータベース内のデータをバックアップおよびリストアする方法について説明します。
TimesTen Scaleoutを使用すると、データベースをTimesTen ClassicからTimesTen Scaleoutに移行できます。TimesTen Scaleoutでは、TimesTen Classicのほとんどの機能がサポートされ、含まれています。TimesTen CacheまたはTimesTenレプリケーションの機能はサポートされていません。TimesTen Scaleoutでサポートされている機能の詳細は、TimesTen ScaleoutとTimesTen Classicの比較を参照してください。これらの手順は、TimesTen Classicデータベースに使用できます。次のオブジェクトは移行できません。
LOB列が含まれる表。
ROWID列が含まれる表。
インメモリー列圧縮が行われている表。
エージング・ポリシーが設定されている表。
キャッシュ・グループ。
レプリケーション・スキーム。
TimesTen ClassicからTimesTen Scaleoutにデータベースを移行する前の前提条件:
管理インスタンスおよびデータ・インスタンス含むグリッドを作成します。詳細は、第4章「グリッドの設定」を参照してください。
TimesTen Classicデータベースのバックアップを作成します。詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのttBackupおよびttRestoreを参照してください。
Oracle TimesTen In-Memory Databaseインストレーション、移行およびアップグレード・ガイドのデータベースのバックアップとリストアを参照してください。
TimesTen Classicデータベースのバックアップを作成した後、表からLOB列を削除することを検討してください。TimesTen Scaleoutでは、LOB列が含まれる表をインポートできず、表にLOB列が含まれている場合は、インポート・プロセスでエラー・メッセージが表示されます。これらの列を削除するには、DROPキーワードを含むALTER TABLE文を使用します。詳細は、Oracle TimesTen In-Memory Database SQLリファレンスのALTER TABLEを参照してください。
ROWID列を含む表がある場合は、アプリケーションでROWIDベースのアクセスを使用しないことを検討してください。TimesTen Classicでは、ROWID列のセマンティクスはTimesTen Scaleoutとは異なります。詳細は、データ分散でのROWIDの理解を参照してください。
表の分散スキーム間のパフォーマンスのトレードオフを理解します。詳細は、表の分散スキームの定義を参照してください。
この項の手順では、TimesTen Classicデータベースから移行できないオブジェクトを削除する方法について説明します。
データベースをTimesTen ClassicからTimesTen Scaleoutデータベースに移行するには、データベース・スキーマをエクスポートし、サポートされているオブジェクトをTimesTen Classicデータベースから移行します。これらを新しいTimesTen Scaleoutデータベースにリストアします。
すべてのアプリケーションをTimesTen Classicデータベースから切断します。
TimesTen Classicインスタンスで、ttSchemaユーティリティの-listオプションを使用してデータベース・スキーマをエクスポートします。-listオプションでは、TimesTen Scaleoutでサポートされているオブジェクトのみを指定します。database1をデータベースの名前に置き換えてください。
% ttSchema -list tables,views,sequences,synonyms database1 > /tmp/database1.schema
ttSchemaユーティリティの詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのttSchemaを参照してください。
TimesTen Classicインスタンスで、ttMigrateユーティリティを使用してデータベースのコピーを保存します。
% ttMigrate -c database1 /tmp/database1.data Saving user PUBLIC User successfully saved. ... Sequence successfully saved.
ttMigrateユーティリティの詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのttMigrateを参照してください。
データベース・スキーマおよび移行オブジェクト・ファイルを、いずれかのデータ・インスタンスからアクセス可能なファイル・システムにコピーします。任意のデータ・インスタンスを選択でき、特に指定のないかぎり、この同じデータ・インスタンスからすべての追加手順を実行する必要があります。
選択したデータ・インスタンスで、テキスト・エディタを使用してデータベース・スキーマ・ファイルを編集し、TimesTen ScaleoutでサポートされていないSQL文および句を削除し、表の分散スキーム句を追加します。これは、ステップ3で作成したデータベース・スキーマ・ファイルです。
次のSQL文を削除します。
CREATE CACHE GROUP
CREATE REPLICATION
CREATE ACTIVE STANDBY PAIR
CREATE INDEX (これらの文を削除する前に次のノートを確認してください)
|
ノート: CREATE INDEX文はTimesTen Scaleoutでサポートされていますが、データが分散された後に索引を作成すると、より効率的です。ただし、DISTRIBUTE BY REFERENCE分散スキームで分散する子表の場合は、子表のFOREIGN KEY句も参照される親表のCREATE INDEX文も削除しないでください。ステップ9で、データがTimesTen Scaleoutデータベースに挿入された後に索引がリストアされます。 |
次のCREATE TABLE句を削除します。
COMPRESS BY
FOREIGN KEY (これらの文を削除する前に前述のノートを確認してください)
AGING
CREATE USER文を追加して、database1.schema内のオブジェクトによって参照されるスキーマ所有者を作成します。たとえば、hr.employeesには、CREATE USER hr IDENTIFIED BY password文が必要になります。ユーザーとしてログインする場合は、これらのユーザーに権限を追加することも必要になることがあります。
すべての表定義の分散スキーム句を追加します。CREATE TABLE文の分散スキームを指定しない場合、TimesTen ScaleoutはDISTRIBUTE BY HASH分散スキームを使用して表のデータを分散します。
|
ノート: DISTRIBUTE BY REFERENCE分散スキームを使用する場合は、外部キー制約の子キー列をNOT NULLとして宣言してください。 |
表定義に分散スキームを追加する前に、分散スキーム間のパフォーマンスのトレードオフを理解しておいてください。TimesTen Scaleoutデータベースにおける分散スキームの詳細は、表の分散スキームの定義を参照してください。
TimesTen Scaleoutの管理インスタンスから、TimesTen Scaleoutデータベースを作成します。詳細は、データベースの作成 を参照してください。
選択したデータ・インスタンスで、インスタンス管理者としてログインし、データベース・スキーマ・ファイルからデータベース・スキーマを作成します。new_database1を新しいTimesTen Scaleoutデータベースの名前に置き換えてください。
% ttIsql -connStr "DSN=new_database1" -f /tmp/database1.schema Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=new_database1"; Connection successful: ... exit; Disconnecting... Done.
|
ノート: ttIsqlコマンドの出力を出力ファイルにリダイレクトすると役立つことがあります。この出力により、コマンドが正常に実行されたことを確認できます。出力をファイルにリダイレクトするには、ttIsql -connStr "DSN=new_database1" -f /tmp/database1.schemaコマンドの後に> myoutput.txtを追加します。 |
選択したデータ・インスタンスで、次のttMigrateコマンドを使用して、すべてのユーザー表の行をリストアします。
% ttMigrate -r -gridRestoreRows new_database1 /tmp/database1.data Restoring table HR.EMPLOYEES ... 10/10 rows restored. Table successfully restored.
選択したデータ・インスタンスで、次のttMigrateコマンドを使用して、索引および外部キーをリストアします。
% ttMigrate -r -gridRestoreFinale new_database1 /tmp/database1.data Restoring table HR.EMPLOYEES ... 10/10 rows restored. Table successfully restored.
|
ノート: DISTRIBUTE BY REFERENCE分散スキームを使用しているため、ステップ5でFOREIGN KEY句を削除しなかった場合は、TimesTen Scaleoutでいくつかの外部キーを作成できないことを示すエラー・メッセージが表示されることがあります。これらの外部キーをステップ5で作成した場合は、これらのメッセージを無視してください。 |
データベースがTimesTen Scaleoutで動作可能になったら、TimesTen Scaleoutデータベースのバックアップを作成して、データベースの有効なリストア・ポイントを作成します。詳細は、データベースのバックアップおよびリストアを参照してください。データベースのバックアップが作成されると、データベース・スキーマ・ファイル(この例では、/tmp/database1.schema)およびデータベースのttMigrateコピー(この例では、/tmp/database1.data)を削除できます。
グリッドで、リポジトリは、データベース、データベース・エクスポート、ログ・ファイルと構成ファイルのコレクションのバックアップを格納するために使用されます。TimesTen Scaleoutでは、リポジトリを、各ホストにNFSを使用してマウントされるディレクトリ・パスとして、または各ホストに直接マウントされないディレクトリ・パスとして定義できます。複数のグリッドで1つのリポジトリを使用できます。
リポジトリには複数のコレクションが含められます。コレクションは、データベース、データベース・エクスポート、または保存された一連のデーモン・ログと構成ファイルのバックアップになります。コレクションは、基本的には、コレクションの名前を使用するサブディレクトリとなり、リポジトリ内に格納されます。各コレクションには、ファイルとサブコレクションの組合せを含めることができます。
データベースのバックアップ、データベースのエクスポートおよびログと構成ファイルのコレクションを格納できる十分なファイル・システム領域があるリポジトリを作成してください。
データベースのバックアップやエクスポートまたはデーモン・ログ・コレクションの作成前に、グリッドのリポジトリを作成する必要があります。
TimesTen Scaleoutを使用すると、リポジトリに関する次の手順を実行できます。
データベースのバックアップやエクスポートまたはデーモン・ログ・コレクションの作成前に、グリッドのリポジトリを構成する必要があります。ttGridAdmin repositoryCreateコマンドでは、-methodパラメータの値に応じて、リポジトリを、各ホストにNFSを使用してマウントされるディレクトリ・パスとして、またはSSHやSCPを使用して各ホスト上でアクセス可能なディレクトリ・パスとして作成します。
|
ノート: リポジトリに有効な名前の詳細は、Oracle TimesTen In-Memory Databaseリファレンスのグリッド・オブジェクトおよびオブジェクト・ネーミングを参照してください。 |
すべてのインスタンスが同じネットワーク上にあり、すべてのインスタンスで同じNFSを使用する必要がある場合は、マウント(NFS)方式のみを使用できます。SCP方式はどのシステムでも使用できますが、グリッドの規模が大きくなると、遅くなる場合があります。
例10-1 各ホストにNFSを使用してマウントされるディレクトリ・パスとしてリポジトリを作成する
この例では、グリッドの各ホストにNFSを使用してマウントされるディレクトリ・パスとしてリポジトリを作成します。-pathパラメータで指定されたディレクトリが存在し、各要素でインスタンス管理者によってアクセス可能であることを確認してください。このディレクトリでは、すべての要素のマウント・パスが同じであることが必要です。たとえば、ディレクトリ・パスがある要素で/repositoriesにマウントされている場合は、すべての要素で/repositoriesにマウントされている必要があります。
% ttGridAdmin repositoryCreate repo1 -path /repositories -method mount Repository repo1 created
例10-2 SSHまたはSCPを使用して各ホスト上でアクセス可能なディレクトリ・パスとしてリポジトリを作成する
この例では、グリッドの各ホストに直接マウントされないディレクトリ・パスとしてリポジトリを作成します。-pathパラメータで指定されたパス値が-addressパラメータで指定されたホストに存在することを確認してください。addressパラメータは、リポジトリが存在するホストの完全修飾ドメイン名です。また、各ホストでscpコマンドを使用して、-pathパラメータで指定されたパス値のファイルにアクセスできることを確認してください。ttGridAdmin gridSshConfigコマンドを使用して、ホストがSSHを介して相互に通信できることを確認できます。詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのSSHの構成(gridSshConfig)を参照してください。
% ttGridAdmin repositoryCreate repo2 -path /repositories -method scp -address host1.example.com Repository repo2 created
ttGridAdmin repositoryCreateコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのリポジトリの作成(repositoryCreate)を参照してください。
1つのリポジトリを複数のグリッドで使用できますが、各グリッドがそのリポジトリに関連付けられていることが条件となります。既存のリポジトリがある場合、グリッドの各ホストがリポジトリのパスにアクセスできるかぎり、別のグリッドにアタッチできます。-methodパラメータの値に応じて、リポジトリを、各ホストにNFSを使用してマウントされるディレクトリ・パスとして、またはSSHやSCPを使用して各ホスト上でアクセス可能なディレクトリ・パスとしてアタッチできます。ただし、リポジトリは、作成に使用されたものと同じ-methodでのみアタッチできます。たとえば、-method mountでリポジトリを作成した場合は、-method mountでのみリポジトリを別のグリッドにアタッチできます。
例10-3 各ホストにNFSを使用してマウントされるディレクトリ・パスとしてリポジトリをアタッチする
この例では、グリッドの各ホストにNFSを使用してマウントされるディレクトリ・パスとしてリポジトリをアタッチします。-pathパラメータで指定されたパス値が存在し、グリッドの各ホストでインスタンス管理者によってアクセス可能であることを確認してください。
リポジトリの名前は、リポジトリをアタッチする各グリッドで同じにする必要があります。
% ttGridAdmin repositoryAttach repo1 -path /repositories -method mount Repository repo1 attached
例10-4 SSHまたはSCPを使用して各ホスト上でアクセス可能なディレクトリ・パスとしてリポジトリをアタッチする
この例では、グリッドの各ホストに直接マウントされないディレクトリ・パスとしてリポジトリをアタッチします。各ホストでscpコマンドを使用して、-pathパラメータで指定されたパス値のファイルにアクセスできることを確認してください。addressパラメータは、リポジトリが存在するホストの完全修飾ドメイン名です。
リポジトリの名前は、リポジトリをアタッチする各グリッドで同じにする必要があります。
% ttGridAdmin repositoryAttach repo2 -path /repositories -method scp -address host1.example.com Repository repo2 attached
ttGridAdmin repositoryAttachコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのリポジトリのアタッチ(repositoryAttach)を参照してください。
TimesTen Scaleoutでは、グリッドで使用する必要がなくなったリポジトリをグリッドから破棄するのではなくデタッチできます。
グリッドからリポジトリをデタッチするには、グリッドからデタッチするリポジトリの名前を指定します。
% ttGridAdmin repositoryDetach repo1 Repository repo1 detached
グリッドからリポジトリをデタッチしても、ディレクトリまたはそのリポジトリのコンテンツは削除されません。
ttGridAdmin repositoryDetachコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのリポジトリのデタッチ(repositoryDetach)を参照してください。
TimesTen Scaleoutでは、グリッドにアタッチされているすべてのリポジトリおよびリポジトリ内のすべてのコレクションのリストを表示できます。
グリッドにアタッチされているすべてのリポジトリのリストを表示するには、次の手順を実行します。
% ttGridAdmin repositoryList Repository Method Location Address ---------- ------ ------------------- -------- repo1 mount /repositories/repo1
グリッドにアタッチされている各リポジトリに含まれているすべてのコレクションのリストを表示するには、次の手順を実行します。
% ttGridAdmin repositoryList -contents Repository Collection Type Date Details ---------- ------------- ------------- ------------------------ ------------------ repo1 B20170222145544 Backup 2017-02-22T14:55:48.000Z Database database1 repo1 B20170615142115 Backup 2017-06-15T14:21:20.000Z Database database1 repo2 L20170615143145 gridLogCollect 2017-06-15T14:31:48.000Z repo2 L20170616102242 gridLogCollect 2017-06-16T10:22:50.000Z
|
ノート: リポジトリの名前を追加して、特定のリポジトリに含まれているコレクションのみを表示できます。たとえば、ttGridAdmin repositoryList repo1 -contentsを実行すると、repo1リポジトリのすべてのコレクションが表示されます。 |
ttGridAdmin repositoryListコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのリポジトリのリスト(repositoryList)を参照してください。
データを保護するには、TimesTen Scaleoutのバックアップおよびリストア機能が必要不可欠です。潜在的なデータ損失のリスクを最小化するために、定期的なバックアップを実行することをお薦めします。データベースのバックアップを実行すると、TimesTen Scaleoutによって、各レプリカ・セット上で非同期的にバックアップが実行され、バックアップされる各レプリカ・セットのサブコレクションが作成されます。
TimesTen Scaleoutデータベースのバックアップおよびリストアを検討するときには、次のことに注意してください。
現在のグリッド・トポロジのサイズは、データベース・バックアップのグリッドからのトポロジ以上である必要があります。現在のグリッド・トポロジの大きさがn個のレプリカ・セットに十分でない場合は、TimesTen Scaleoutでエラー・メッセージが表示されます。つまり、3個のレプリカ・セットを含むデータベースをバックアップし、レプリカ・セットが2個のみのデータベースにリストアすると、操作が失敗します。ただし、TimesTen Scaleoutのエクスポート機能とインポート機能を使用すると、データベースをレプリカ・セットが多いグリッド・トポロジからレプリカ・セットが少ないグリッド・トポロジのデータベースにインポートできます。詳細は、データベースのエクスポートおよびインポートを参照してください。
同じグリッド・トポロジのグリッドにバックアップをリストアでき、そのグリッドがバックアップの作成元と同じグリッドの場合も同様です。つまり、3個のレプリカ・セットがあるデータベースのバックアップを作成した場合は、3個のレプリカ・セットがある同じグリッドまたは新しいグリッドにリストアできます。
バックアップは、バックアップが作成されたグリッドよりもトポロジが大きいグリッドにリストアできます。n個のレプリカ・セットを持つデータベースをバックアップすると、リストア操作では、正確にn個のレプリカ・セットを含むデータベースが作成されます。ただし、現在のグリッド・トポロジが元のグリッド・トポロジより大きい場合、TimesTen Scaleoutでは、追加要素が作成されますが、これらの要素はデータベースの分散マップに追加されず、データはこれらの要素に格納されません。かわりに、リストアでは、元のグリッド・トポロジと同じ数のレプリカ・セットが移入されるのみとなります。つまり、3個のレプリカ・セットがあるデータベースのバックアップを作成した場合は、バックアップを4個のレプリカ・セットがある新しいグリッドにリストアできます。ただし、リストアでは、4個のレプリカ・セットのうち3個が移入されるのみとなります。このため、すべてのレプリカ・セットに移入するには、ttGridAdmin dbDistributeコマンドを使用して、リストア後にすべてのレプリカ・セット間でデータを再分散する必要があります。詳細は、データベース内のデータの再分散を参照してください。
バックアップには、通常とステージングの2つのタイプがあります。
通常のバックアップは、グリッドの各ホストでNFSを使用してマウントされたリポジトリまたはグリッドの各ホストがSSH/SCPを使用して接続しているリポジトリで実行できます。通常のバックアップの作成に要する時間はデータベースのサイズによって異なりますが、どのバックアップもほぼ同じ所要時間で完了することが予想されます。
ステージング・バックアップは、グリッドの各ホストがSSH/SCPを使用して接続しているリポジトリでのみ実行できます。最初のステージング・バックアップの完了には通常のバックアップとほぼ同じ時間がかかる(またはネットワークのパフォーマンスによってはさらに時間がかかる)可能性がありますが、後続のすべてのステージング・バックアップの完了にはその時間のわずかしかかかりません。ステージング・バックアップは、メイン・サイトに依存しない2番目のサイトで定期的なバックアップを作成する場合に最適です。
各バックアップ操作に必要なファイル・システム領域の詳細は、バックアップまたはエクスポートのサイズの決定を参照してください。
|
ノート: データがリストアされるデータベースが、メジャー・アップグレードなど、パッチの互換性がないTimesTen Scaleoutのバージョンのものである場合は、データベースをバックアップおよびリストアできません。かわりに、そのデータベースをエクスポートしてインポートする必要があります。詳細は、データベースのエクスポートおよびインポートを参照してください。 |
TimesTen Scaleoutを使用すると、バックアップに関する次の手順を実行できます。
定期的なバックアップでは、潜在的なデータ損失のリスクが最小限に抑えられます。データベースをバックアップする前に、グリッドのリポジトリが構成済であることを確認してください。詳細は、リポジトリの使用を参照してください。
この例では、データベースdatabase1のバックアップが作成され、リポジトリrepo1にそのバックアップが格納されます。デフォルトでは、バックアップには、現在の日付と時刻に基づいて、Byyyymmddhhssという名前が付けられます。バックアップ名の接頭辞Bは、バックアップを表します。管理インスタンスでttGridAdmin dbBackupコマンドを実行してください。
|
ノート: -nameパラメータを追加して、バックアップ名を指定できます。たとえば、ttGridAdmin dbBackup database1 -repository repo1 -name mybackupを実行すると、mybackupという名前のバックアップが作成されます。 |
% ttGridAdmin dbBackup database1 -repository repo1 dbBackup B20170222145544 started
データベースのサイズ、データベースで使用されているレプリカ・セットの数、二次記憶域デバイスのパフォーマンスおよびネットワークのパフォーマンスによってバックアップ時間は異なります。ttGridAdmin dbBackupコマンドは、バックアップ・プロセスを起動するのみで、出力はバックアップが完了したことを示すものではありません。バックアップのステータスを確認するには、ttGridAdmin dbBackupStatusコマンドを使用します。詳細は、バックアップのステータスの確認を参照してください。
ttGridAdmin dbBackupコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベースのバックアップ(dbBackup)を参照してください。
SCP方式を使用したリポジトリへの通常のバックアップでは、レプリカ・セットごとに最新のチェックポイントおよびトランザクション・ログ・ファイルのコピーが2つ必要です。一方のコピーは、レプリカ・セットごとに1つの要素のチェックポイントおよびログ・ファイルで構成され、これらはインスタンス・ホームのディレクトリに一時的にコピーされます。2番目のコピーは、リポジトリで送信および格納された、レプリカ・セットごとの同じチェックポイントおよびログ・ファイルで構成され、これらによってバックアップ自体が構成されます。
TimesTen Scaleoutでは、SCPリポジトリへのステージング・バックアップを作成できます。このタイプのバックアップを使用すると、チェックポイントおよびログ・ファイルのローカル・コピーの作成によるオーバーヘッドがなくなり、リポジトリにリモート・コピーを作成するために必要なネットワーク・トラフィックが減少します。これを実現するために、ステージング・バックアップでは、一時的なローカル・ファイル(最新のログ・ファイルを除く)ではなくシンボリック・リンクを使用し、リポジトリ上にステージング・ディレクトリを保持します(最新のバックアップで使用されたレプリカ・セットごとのチェックポイントおよびログ・ファイルを含む)。次のステージング・バックアップでは、各レプリカ・セットから最新のログ・ファイルがコピーされ、ステージング・ディレクトリ内の残りのファイルがネットワークを介して同期されます。最後に、リポジトリでステージング・ディレクトリ内の結果ファイルを使用してバックアップが作成され、データ・インスタンスおよびネットワークからそのタスクの負荷が取り除かれます。
|
ノート:
|
次の各項では、ステージング・バックアップの推奨設定およびステージング・バックアップの作成方法について説明します。
データベースのステージング・バックアップを開始する前に、次の点を考慮してください。
ステージング・バックアップには、次の前提条件があります。
パスワードなしSSHアクセス: ステージング・バックアップでは、インスタンス(データおよび管理)を持つすべてのホストで、リポジトリをホストするシステムに対してインスタンス管理者がパスワードなしでSSHアクセスできる必要があります。詳細は、パスワードなしSSHの設定を参照してください。
rsyncコマンド: ステージング・バックアップでは、データ・インスタンスを持つホストおよびリポジトリを割り当てるシステムで、rsyncコマンドを使用できる必要があります。
ステージング・バックアップは、SSHを使用してデータ転送および制御を行います。データ・インスタンスを持つすべてのホストについて、ステージング・バックアップの信頼性を向上させるために、インスタンス管理者のSSH構成ファイル(/home/instance_administrator/.ssh/config)またはグローバルSSH構成ファイル(/etc/ssh/ssh_config)を更新することを検討してください。次のオプションが役に立つことがあります。
HostName: このオプションを使用して、リポジトリの複数の別名を指定できます。SSHはこれらを順番に試行します。各ホストに異なる順序の複数の別名のリストを指定してください。
Port: SSHはデフォルトでポート22を使用します。SSHがNATゲートウェイを通過する必要がある場合は、別のポート番号を使用することが必要になることがあります。
BindAddressまたはBindInterface: これらのオプションを使用して、リポジトリへのアクセスに使用するイーサネット・インタフェースSSHを制御できます。
ConnectionAttempts: デフォルトでは、SSHは1回のみ接続を試行します。このオプションを使用して、SSHが中断して失敗の通知を返すまでに接続を試行する回数を設定できます。
ConnectTimeout: デフォルトでは、SSHはシステムTCPタイムアウトを使用します。このオプションを使用して、SSH接続を確立するためのタイムアウト(秒単位)を設定できます。待機時間の長いWANリンクでは、この接続タイムアウトを長くすることを検討してください。
ProxyJump: このオプションを使用して、リポジトリに接続するためのプロキシとなる要塞ホストを設定できます。データ・インスタンスを持つホストは、リポジトリのような他のホストではなく、要塞ホストにアクセスできる場合があります。同様に、要塞ホストはリモート・リポジトリにアクセスできる場合があります。高可用性を実現するために複数の要塞ホストを構成できます。
ServerAliveCountMax: このオプションを使用して、リポジトリからのメッセージを受信しないまま暗号化されたチャネル経由で送信されるキープアライブ・メッセージの最大数を設定できます。このしきい値に達すると、接続は終了します。このオプションは、ServerAliveIntervalオプションとともに使用する必要があります。
ServerAliveInterval: このオプションを使用して、リポジトリからデータを受信しなくなってから、ホストがキープアライブ・メッセージを送信するまでの時間(秒単位)を設定できます。これは、リポジトリがクラッシュしたり、ネットワークが停止したことを検出するのに役立ちます。
リポジトリをホストしているシステムについて、グローバルSSHデーモン構成ファイル(/etc/ssh/sshd_config)でこのオプションを設定することを検討してください。
MaxStartups: このオプションを使用して、SSHデーモンへの同時未認証接続の最大数を設定できます。startパラメータをレプリカ・セット数より大きい値に設定し、fullパラメータをstartパラメータの値の10倍にすることを検討してください。たとえば、10個のレプリカ・セットがある場合は、このオプションを次のように設定します。
MaxStartups 15:30:150
BackupFailThreshold初期接続属性では、バックアップの開始時からLogDirディレクトリに蓄積できるトランザクション・ログ・ファイルの数を決定し、この数を超えると、TimesTenはチェックポイント操作の保留を強制的に解放します。バックアップが完了する前にチェックポイントが開始された場合、バックアップは無効になります。
BackupFailThreshold属性は、バックアップが安全に完了できるように十分大きい値に設定してください。たとえば、バックアップが完了するのに通常はn秒かかり、データベースが1秒にm個のトランザクション・ログ・ファイルを作成する場合は、BackupFailthresholdをn * mより大きい値に設定します。特定の時間単位ごとにデータベースによって生成されるログ・ファイルの数は、書込みワークロードに正比例し、LogFileSize属性に設定された値に反比例します。
初期接続属性の値を変更する方法の詳細は、データベースの接続属性の変更を参照してください。
BackupFailThreshold、LogDirおよびLogFileSize接続属性の詳細は、Oracle TimesTen In-Memory Databaseリファレンスの接続属性を参照してください。
ステージング・バックアップによる領域不足エラーを回避するために、次のことを確認します。
各データ・インスタンスで使用されるファイル・システムには、インスタンス・ホームの1つのトランザクション・ログ・ファイル用の十分な領域(LogFileSize)と、バックアップ操作の進行中に生成される可能性があるすべてのトランザクション・ログ・ファイルをLogDirに格納するのに十分な領域(BackupFailThreshold * LogFileSize)があること。
リポジトリで使用されるファイル・システムに、保持する数のバックアップの格納に十分な領域と、同じデータベースのステージング・バックアップすべてについてステージング・ディレクトリに1.25バックアップ用の十分な領域があること。
各バックアップ操作に必要なファイル・システム領域の詳細は、バックアップまたはエクスポートのサイズの決定を参照してください。
LogFileSize、LogDirおよびBackupFailThreshold接続属性の詳細は、Oracle TimesTen In-Memory Databaseリファレンスの接続属性を参照してください。
後続のステージング・バックアップに必要な最小限のWANスループットは、データベースの集計サイズ、バックアップに必要な時間およびステージング・リポジトリと定義済の転送圧縮で示される高速化要因によって異なります。一連のステージング・バックアップを実行して、ネットワークと設定全体のパフォーマンスにより(さらに、通常のバックアップよりも後続のステージング・バックアップのほうが本質的に利点があるため)、通常のワークロード条件下で定期的なステージング・バックアップのバックアップ時間がどれだけ短縮されるかをテストする必要があります。次の式について考えてみます。
Minimum WAN throughput = file size of a backup/(desired backup time * (first staged backup time/average subsequent staged backups time))
各バックアップ操作に必要なファイル・システム領域の詳細は、バックアップまたはエクスポートのサイズの決定を参照してください。
次の例では、database1データベースのstgbackup1という名前のステージング・バックアップが作成され、scprepo1リポジトリにそのバックアップが格納されます。ステージング・バックアップは、秒当たり62 MBの集約ネットワーク・トラフィックと、そのネットワーク・トラフィックの圧縮レベル9を使用するように設定されます。
% ttGridAdmin dbBackup database1 -repository scprepo1 -name stgbackup1 -backupType staged -bwlimit 62 -compression 9 dbBackup stgbackup1 started
|
ノート: アクティブ管理インスタンスでインスタンス管理者としてttGridAdmin dbBackupコマンドを実行していることを確認してください。 |
データベースのサイズ、データベースで使用されているレプリカ・セットの数、二次記憶域デバイスのパフォーマンスおよびネットワークのパフォーマンスによってバックアップ時間は異なります。ttGridAdmin dbBackupコマンドは、バックアップ・プロセスを起動するのみで、出力はバックアップが完了したことを示すものではありません。バックアップのステータスを確認するには、ttGridAdmin dbBackupStatusコマンドを使用します。詳細は、バックアップのステータスの確認を参照してください。
ttGridAdmin dbBackupコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベースのバックアップ(dbBackup)を参照してください。
ttGridAdmin dbBackupStatusコマンドを使用すると、特定のデータベースのすべてのバックアップ・プロセスの進行状況を表示できます。
次の例では、データベースdatabase1のすべてのバックアップ・プロセスのステータスが表示されます。
% ttGridAdmin dbBackupStatus database1
Database Backup Repository Host Instance Elem State Started Finished
--------- --------------- --------- ----- --------- ---- --------- ---------------------- --------
database1 B20170222145544 repo1 Completed 2017-02-22T14:55:44.000Z Y
host4 instance1 2 Complete
host5 instance1 3 Complete
ttGridAdmin dbBackupStatusの出力で、バックアップ・プロセス全体の状態がCompletedとしてマークされていることを確認してください。状態の値がFailedと表示される場合は、次のタスクを実行します。
ttGridAdmin dbStatus database1 -detailsコマンドを使用して、その要素のホストおよびインスタンスが稼働していることを確認します。各レプリカ・セットの1つ以上のホストが稼働中である場合は、ttGridAdmin dbBackupコマンドは、データベースの全体バックアップを作成できます。詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベースのステータスのモニター(dbStatus)を参照してください。
バックアップを作成しようとしているリポジトリに、データベースのバックアップの作成に十分な空きファイル・システム領域があることを確認してください。
バックアップが失敗した場合は、異なるバックアップ名を使用して、別のバックアップを実行することもできます。新しいバックアップ名でもバックアップが正常に実行されない場合は、問題を診断し、必要な修正を実行します。問題を解決した後、ttGridAdmin dbBackupDeleteを使用して、失敗したバックアップを削除します。TimesTen Scaleoutでは、失敗したバックアップは自動的には削除されません。次に、ttGridAdmin dbBackupコマンドを使用して新しいバックアップを開始します。使用可能なファイル・システム領域に応じて、次のコマンドを任意の順序で使用できます。詳細は、バックアップの削除およびデータベースのバックアップを参照してください。
ttGridAdmin dbBackupStatusコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベース・バックアップのステータス(dbBackupStatus)の表示を参照してください。
TimesTen Scaleoutでは、バックアップは自動的には削除されません。失敗したバックアップまたは古いバックアップがあるバックアップを削除するか、ファイル・システム領域を解放できる場合があります。
ttGridAdmin repositoryList -contentsコマンドを使用して、使用可能なバックアップとそれらに対応するリポジトリのすべてを表示します。詳細は、リポジトリおよびコレクションのリストを参照してください。
次の例では、リポジトリrepo1からB20170222145544という名前のバックアップを削除します。
% ttGridAdmin dbBackupDelete -repository repo1 -name B20170222145544 Backup B20170222145544 deleted
TimesTen Scaleoutでは、バックアップに含まれるコレクションおよびすべてのサブコレクションが削除されます。
ttGridAdmin dbBackupDeleteコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベース・バックアップの削除(dbBackupDelete)を参照してください。
データベースのリストアを実行する場合は、データベース定義名が他のデータベースで使用中でない必要があります。たとえば、別のデータベースでdatabase1という名前が使用されている場合は、リストアしたデータベースにdatabase1にという名前を付けることはできません。
バックアップされたデータベースのデータベース定義は、リストアするデータベースのデータベース名と一致している必要はありません。たとえば、payrollデータベースのバックアップをnew_payrollデータベース定義にリストアできます。
バックアップしたデータベースのK-safety値はリストア・データベースのK-safety値と一致している必要はありません。
データベース定義には、少なくともバックアップされたデータベースのデータベース定義と同じ数の接続が必要です。
次の例では、リポジトリrepo1のバックアップB20170222145544からデータベースres_db1をリストアします。管理インスタンスでttGridAdmin dbRestoreコマンドを実行してください。
% ttGridAdmin dbRestore res_db1 -repository repo1 -backup B20170222145544 dbRestore B20170222145544 started
|
ノート: リストアを実行する前に、res_db1データベース定義が存在することを確認してください。このデータベース定義からデータベースを作成する必要はありません。詳細は、データベース定義の作成を参照してください。 |
リストア時間は、バックアップのサイズ、データベースが使用しているレプリカ・セットの数、二次記憶域デバイスのパフォーマンスおよびネットワークのパフォーマンスによって異なります。ttGridAdmin dbRestoreコマンドはリストア・プロセスを起動するのみで、出力はリストアが完了したことを示すものではありません。リストア・プロセスは、各要素に対して非同期的に実行されます。リストアのステータスを確認するには、ttGridAdmin dbRestoreStatusコマンドを使用します。詳細は、リストアのステータスの確認を参照してください。
ttGridAdmin dbRestoreコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベースのリストア(dbRestore)を参照してください。
ttGridAdmin dbRestoreStatusコマンドを使用すると、特定のデータベースのリストア・プロセスの進行状況を表示できます。
次の例では、データベースres_db1のすべてのリストア・プロセスのステータスが表示されます。
% ttGridAdmin dbRestoreStatus res_db1
Database Restore Repository Host Instance Elem State Started Finished
-------- ------- ---------- ----- --------- ---- ------------------------------------------------ -
res_db1 mybkup repo1 Restore_Finale_Complete 2017-03-03T13:19:39.000Z Y
host3 instance1 Restore_Instance_Complete
host4 instance1 Restore_Instance_Complete
host5 instance1 Restore_Instance_Complete
host6 instance1 Restore_Finale_Comnplete
ttGridAdmin dbRestoreStatusの出力で、グリッドの各要素のリストアが完了していることを確認してください。データベース名のある行のState列がCompletedとしてマークされている場合、リストア操作は完全に完了しています。
ttGridAdmin dbRestoreStatusの出力で、リストア・プロセス全体の状態がCompletedとしてマークされていることを確認してください。ある要素の状態の値がFailedかRestore_Instance_Failedである場合、または全体的な状態がRestore_Finale_FailedかRestore_Init_Failedである場合は、ttGridAdmin dbCloseおよびttGridAdmin dbUnloadの各コマンドを使用してデータベースを停止します。データベースを停止した後、ttGridAdmin dbDestroyコマンドを使用して、正常にリストアされなかったデータベースを削除します。次に、リストア操作を再試行してください。詳細は、メモリーからのデータベースのアンロードおよびデータベースの破棄を参照してください。
ttGridAdmin dbRestoreStatusコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベース・リストアのステータス(dbRestoreStatus)の表示を参照してください。
TimesTen Scaleoutのエクスポートおよびインポート機能を使用すると、2つのグリッド・データベース間でデータを移行できます。
次の状況では、データベースのエクスポートが必要になります。
ソース・データベースが、メジャー・アップグレードなどの、パッチとの互換性のないTimesTen Scaleoutバージョンのものです。両方のタイプのアップグレードの詳細(パッチの互換性など)は、グリッドのアップグレードを参照してください。
宛先データベースのグリッド・トポロジのレプリカ・セットが、データベースのエクスポート元となるグリッド・トポロジよりも少なくなっています。
データベースをエクスポートすると、TimesTen Scaleoutによって、各レプリカ・セットのエクスポートが非同期的に実行され、エクスポートされる各レプリカ・セットのサブコレクションが作成されます。
各エクスポート操作に必要なファイル・システム領域の詳細は、バックアップまたはエクスポートのサイズの決定を参照してください。
TimesTen Scaleoutを使用すると、データベース・エクスポートに関する次の手順を実行できます。
データベースをエクスポートする前に、グリッドのリポジトリが構成済であることを確認してください。詳細は、リポジトリの使用を参照してください。
データベース・エクスポートの実行前にデータベースへのすべてのアプリケーション接続を切断して、データベース・エクスポート操作中にアプリケーションによってデータが変更されないようにします。また、データベースをクローズして、データベースへの新規接続ができないようにします。エクスポート操作中にトランザクションがコミットされると、データベースの一貫性が失われる可能性があります。
この例では、データベースdatabase1のデータベース・エクスポートが作成され、リポジトリrepo1にそのエクスポートが格納されます。デフォルトでは、データベース・エクスポートには、現在の日付と時刻に基づいて、Myyyymmddhhssという名前が付けられます。管理インスタンスでttGridAdmin dbExportコマンドを実行してください。
|
注意: -nameパラメータを追加して、データベース・エクスポート名を指定できます。たとえば、ttGridAdmin dbExport database1 -repository repo1 -name myexportを実行すると、myexportという名前のデータベース・エクスポートが作成されます。 |
% ttGridAdmin dbExport database1 -repository repo1 dbExport M20170302144218 started
データベース・エクスポート時間は、データベースのサイズ、データベースが使用しているレプリカ・セットの数、二次記憶域デバイスのパフォーマンスおよびネットワークのパフォーマンスによって異なります。データベース・エクスポートのステータスを確認するには、ttGridAdmin dbExportStatusコマンドを使用します。詳細は、データベース・エクスポートのステータスの確認を参照してください。
ttGridAdmin dbExportコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベースのエクスポート(dbExport)を参照してください。
ttGridAdmin dbExportStatusコマンドを使用すると、特定のデータベースのすべてのデータベース・エクスポート・プロセスの進行状況を表示できます。
次の例では、データベースdatabase1のすべてのデータベース・エクスポート・プロセスのステータスが表示されます。
% ttGridAdmin dbExportStatus database1
Database Export Repository Host Instance Elem State Started
--------- --------------- ---------- ---- -------- ---- ---------- ------------------------
database1 M20170321073022 repo1 Completed 2017-03-21T07:30:27.000Z
host3 instance1 Complete
host5 instance1 Complete
ttGridAdmin dbExportStatusの出力で、グリッドのレプリカ・セットごとにデータベース・エクスポートが完了していることを確認してください。要素の状態の値がFailedと表示される場合は、次のタスクを実行します。
ttGridAdmin dbStatus database1 -detailsコマンドを使用して、その要素のホストおよびインスタンスが稼働していることを確認します。詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベースのステータスのモニター(dbStatus)を参照してください。
バックアップを作成しようとしているリポジトリに、データベースのバックアップの作成に十分な空きファイル・システム領域があることを確認してください。
エクスポートの失敗の原因となった問題を解決した後、ttGridAdmin dbExportDeleteを使用して、失敗したデータベース・エクスポートを削除します。TimesTen Scaleoutでは、失敗したデータベース・エクスポートは自動的には削除されません。次に、ttGridAdmin dbExportコマンドを使用して新しいデータベース・エクスポートを開始します。詳細は、データベース・エクスポートの削除およびデータベースのエクスポートを参照してください。
ttGridAdmin dbExportStatusコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベース・エクスポートのステータス(dbExportStatus)の表示を参照してください。
TimesTen Scaleoutでは、データベース・エクスポートは自動的には削除されません。失敗したデータベース・エクスポートまたは古いデータベース・エクスポートがあるデータベース・エクスポートを削除するか、ファイル・システム領域を解放できる場合があります。
ttGridAdmin repositoryList -contentsコマンドを使用して、使用可能なデータベース・エクスポートとそれらに対応するリポジトリのすべてを表示します。詳細は、リポジトリおよびコレクションのリストを参照してください。
次の例では、リポジトリrepo1からM20170321073022という名前のデータベース・エクスポートを削除します。
% ttGridAdmin dbExportDelete -repository repo1 -name M20170321073022 Export M20170321073022 deleted
TimesTen Scaleoutでは、データベース・エクスポートに含まれるすべてのサブコレクションが削除されます。
ttGridAdmin dbExportDeleteコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベース・エクスポートの削除(dbExportDelete)を参照してください。
データベース・エクスポートをインポートする前に、次の点を考慮してください。
データベース・インポートを実行する場合は、インポート先のデータベースが存在する必要があります。データベースは、データが格納されていても空でもかまいません。元のデータベースのユーザーまたは表を作成する必要はありません。
エクスポートしたデータベースのデータベース名は、データベース・エクスポートをインポートするデータベースのデータベース名と一致している必要はありません。たとえば、payrollデータベースのデータベース・エクスポートをnew_payrollデータベースにインポートできます。
エクスポートしたデータベースのK-safety値は、データベース・エクスポートをインポートするグリッドのK-safety値と一致している必要はありません。
データベース・インポートの実行前にデータベースへのすべてのアプリケーション接続を切断して、データベース・インポート操作中にアプリケーションによってデータが変更されないようにします。また、データベースをクローズして、データベースへの新規接続ができないようにします。インポート操作中にトランザクションがコミットされると、データベースの一貫性が失われる可能性があります。詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベースのクローズ(dbClose)を参照してください。
次の例では、リポジトリrepo1のデータベース・エクスポートM20170321073022からデータベースimport_dbをインポートします。管理インスタンスでttGridAdmin dbImportコマンドを実行してください。
% ttGridAdmin dbImport import_db -repository repo1 -name M20170321073022 -numThreads 8 dbImport M20170321073022 started
インポート時間は、データベース・エクスポートのサイズ、データベースが使用しているレプリカ・セットの数、二次記憶域デバイスのパフォーマンスおよびネットワークのパフォーマンスによって異なります。インポート操作のパフォーマンスを向上させるには、-numThreadsオプションを使用して、エクスポート・データベースから行を同時に読み取ってインポート・データベースに挿入するスレッド数を指定します。
ttGridAdmin dbImportコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベースのインポート(dbImport)を参照してください。
ttGridAdmin dbImportStatusコマンドを使用すると、特定のデータベースのインポート・プロセスの進行状況を表示できます。
次の例では、データベースimport_dbのすべてのインポート・プロセスのステータスが表示されます。
% ttGridAdmin dbImportStatus import_db
Database Import Repository Host Instance Elem State Started
--------- ----------------------------- -------- ---- ---------- ----------------------------------
database1 M20170321073022 repo1 Import_Finale_Complete2017-03-21T10:30:27.000Z
host3 instance1 1 Import_Rows_Complete
host5 instance1 1 Import_Rows_Complete
ttGridAdmin dbImportStatusの出力で、グリッドの各要素のインポート操作が完了していることを確認してください。データベース名のある行のState列がCompletedとしてマークされている場合、インポート操作は完全に完了しています。
要素の状態の値がFailedと表示される場合は、ttGridAdmin dbDestroyコマンドを使用して、正常にインポートされなかったデータベースを削除します。次に、データベースを再作成してインポート操作を再試行してください。詳細は、データベースの破棄を参照してください。
ttGridAdmin dbImportStatusコマンドの詳細は、Oracle TimesTen In-Memory Databaseリファレンスのデータベース・インポートのステータス(dbImportStatus)の表示を参照してください。
リポジトリに格納されているすべてのデータベースのバックアップおよびエクスポートでは、レプリカ・セットごとに、PermSize属性に割り当てられている値と最新チェックポイントの後に作成されたトランザクション・ログ・ファイルの合計サイズの合計に等しいファイル・システム領域(MB)が必要です。
トランザクション・ログ・ファイルのファイル・サイズおよびバックグラウンド・チェックポイント間で通常書き込まれるサイズは、データベースの構成によって異なります。CkptFrequency、CkptLogVolume、LogFileSizeなどの典型的なワークロードや属性の設定は、バックアップまたはエクスポート操作で考慮する必要があるトランザクション・ログ・ファイルの数の決定に直接影響します。詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のトランザクション・ログ・ファイルの記憶域のプロビジョニングを参照してください。
さらに、各データ・インスタンスには、通常のバックアップ、エクスポート、リストアまたはインポート操作ごとに、データベース・バックアップまたはデータベース・エクスポートのサイズをレプリカ・セットの数で除算した値と同等の使用可能な一時ファイル・システム領域(/instance_home/grid/admin/temp/)が必要になります。ステージング・バックアップでは、1つのトランザクション・ログ・ファイル(LogFileSize)と同等の一時ファイル・システム領域のみが必要です。
