2 TimesTenデータベースの管理

TimesTenデータベースの管理の内容は次のとおりです。

• ユーザー接続に対するデータベースのオープンおよびクローズ

• メモリーからのデータベースのロードとアンロード

• RAMポリシーの指定

• データベースからの切断

• データベースのメモリー領域サイズの指定

• TimesTenの記憶域のプロビジョニング

• ttBulkCpユーティリティを使用したデータのバルク・コピー

• TimesTenを使用したスレッド・プログラミング

• TimesTenデータベースのデフラグ

• データベースが単一インスタンスか分散データベースかの確認

ユーザー接続に対するデータベースのオープンおよびクローズ

アプリケーションをデータベースに接続できるようにするには、データベースをオープンする必要があります。データベースがクローズされると、新しいユーザー接続は失敗します。

• TimesTen Classicでは、デフォルトで、データベースは自動的にオープンされ、ユーザー接続で接続できます。

• TimesTen Scaleoutでは、デフォルトで、データベースは手動でオープンされるまでクローズされています。詳細は、『Oracle TimesTen In-Memory Database Scaleoutユーザーズ・ガイド』のユーザー接続のためのデータベースのオープンに関する項を参照してください。

データベースをクローズして、データベースへの新しいユーザー接続を拒否できます。

• TimesTen Classic: ttAdmin -closeコマンドを使用して、データベースを新しいユーザー接続に対してクローズします。

  データベースはRAMポリシーの設定に従って自動的にロードまたはアンロードできるため、データベースのステータス(オープンまたはクローズ)は、データベースがメモリーに現在ロードされているかどうかと連携しません。このため、データベースはアンロード時にオープン状態であったり、ロード時にクローズ状態であったりする可能性があります。RAMポリシーの例は、「TimesTen Classic用のメモリーへのデータベースのロード」を参照してください。

  データベースを手動でアンロードする前に、データベースをクローズする必要があります。クローズしたデータベースをメモリーにロードする場合、ロード処理が完了するまでデータベースはオープンできません。ttAdmin -openコマンドを使用すると、データベースを再オープンできます。例は、「メモリーからのTimesTen Classicデータベースのアンロード」を参照してください。

• TimesTen Scaleout: メモリーからデータベースをアンロードする前に、データベースを手動でクローズする必要があります。詳細は、『Oracle TimesTen In-Memory Database Scaleoutユーザーズ・ガイド』のメモリーからのデータベースのアンロードに関する項を参照してください。

次のいずれかを使用して、データベースのステータスを確認します。

• TimesTen Classic: ttStatusユーティリティを使用して、データベースのステータスを確認します。詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのttStatusを参照してください。

• TimesTen Scaleout: ttGridAdmin dbStatusコマンドを使用して、データベースのステータスを表示します。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のデータベースのステータスのモニター(dbStatus)に関する項を参照してください。

メモリーからのデータベースのロードとアンロード

TimesTenはインメモリー・データベースです。そのため、データベースを最初にファイル・システムからメモリーにロードして、接続に使用できるようにする必要があります。データベースをメモリーにロードする際に、ファイル・システム上のチェックポイント・ファイルから永続メモリー領域の内容が読み取られます。一時メモリー領域は、データベースをメモリーにロードする際に作成され、データベースをアンロードする際に削除されます。永続メモリーおよび一時メモリーの詳細は、「データベースのメモリー領域サイズの指定」を参照してください。

• TimesTen Scaleoutの場合: グリッド管理者は、ttGridAdminユーティリティを使用して、データベースをロードおよびアンロードする方法を制御します。詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのttGridAdminを参照してください。

• TimesTen Classicの場合: RAMポリシーは、データベースが予期せずアンロードされた場合にデータベースを自動的にメモリーに再ロードするかどうかなど、データベースをメモリーにロードする方法とタイミングを指定します。異なるRAMポリシーの詳細は、「RAMポリシーの指定」を参照してください。

  インスタンス管理者のみがデータベースを手動でロードできます。デフォルトでは、TimesTenでは、アイドル・データベース(接続のないデータベース)は、それに対する最初の接続が確立されたときに自動的にメモリーにロードされます。詳細は、「TimesTen Classic用のメモリーへのデータベースのロード」を参照してください。

  データベースがメモリーにロードされた後には、使用している機能、およびttAdminユーティリティで設定したキャッシュ・ポリシーおよびレプリケーション・ポリシーに応じて、データベースのキャッシュ・エージェントおよびレプリケーション・エージェントを明示的に起動する必要がある場合があります。

メモリーからのTimesTen Classicのデータベースのロードとアンロードについては、次の各項で説明します。

• TimesTen Classic用のメモリーへのデータベースのロード

• メモリーからのTimesTen Classicデータベースのアンロード

TimesTen Classic用のメモリーへのデータベースのロード

1. TimesTen Classicのデータベースをメモリーにロードしようとする前に、ttStatusユーティリティを使用してTimesTenデーモンが実行中であることを確認します。次の出力は、TimesTenデーモンが稼働していないことを示します。

   % ttStatus
   ttStatus: Could not connect to the TimesTen daemon.
   If the TimesTen daemon is not running, please start it by running "ttDaemonAdmin -start".
   

2. 必要に応じてTimesTenデーモンを起動します。

   % ttDaemonAdmin -start
   

3. RAMポリシー設定は、データベースをメモリーからロードまたはアンロードするかどうか、その方法およびタイミングを指定するものであるため重要です。TimesTenデータベースのデフォルトのRAMポリシーは、inUseです。

   データベースをメモリーにロードする前に、RAMポリシーを設定できます。詳細は、RAMポリシーの指定を参照してください。

   次の例では、TimesTenデータベースのRAMポリシーをmanualに設定します。

   % ttAdmin -ramPolicy manual database1
   
   RAM Residence Policy            : manual
   Manually Loaded In RAM          : False
   Replication Agent Policy        : manual
   Replication Manually Started    : False
   Cache Agent Policy              : manual
   Cache Agent Manually Started    : False
   Database state                  : open
   

4. ttAdminユーティリティを使用して、データベースをメモリーにロード(または再ロード)するか、データベースをメモリーからアンロードします。

   RAMポリシーがデータベースdatabase1に対してmanualに設定されている場合は、ttAdmin -ramloadユーティリティを使用してTimesTenデータベースをメモリーにロードします。ttAdminユーティリティの-ramLoadオプションは、RAMポリシーがmanualのときにしか使用できません。

   % ttAdmin -ramLoad database1
   
   RAM Residence Policy            : manual
   Manually Loaded In RAM          : True
   Replication Agent Policy        : manual
   Replication Manually Started    : False
   Cache Agent Policy              : manual
   Cache Agent Manually Started    : False
   Database state                  : open
   

   RAMポリシーがmanualの場合は、それをalwaysに変更して、データベースを常に再ロードするように指定できます。

   ttAdmin -ramPolicy always database1
   

   RAMポリシーがinUseの場合は、猶予期間を0より大きくして、アイドル状態のときにその期間の間データベースがメモリーに保持されるようにします。

   % ttAdmin -ramPolicy inUse -ramGrace 200 database1
   
   RAM Residence Policy            : inUse plus grace period
   RAM Residence Grace (Secs)      : 200
   Replication Agent Policy        : manual
   Replication Manually Started    : False
   Cache Agent Policy              : manual
   Cache Agent Manually Started    : False
   Database state                  : open
   

   データベースdatabase1のRAMポリシーがmanualで、データベースが以前に受信接続でクローズしていた場合は、ttAdmin -ramload -openコマンドを使用して、TimesTenデータベースのメモリーへのロードとオープンの両方を行うことができます。

   % ttAdmin -ramLoad -open database1
   
   RAM Residence Policy            : manual
   Manually Loaded In RAM          : True
   Replication Agent Policy        : manual
   Replication Manually Started    : False
   Cache Agent Policy              : manual
   Cache Agent Manually Started    : False
   Database state                  : open
   

5. データベースがレプリケーションに対して構成済である、またはデータベースのキャッシュである場合、ttAdminユーティリティを実行してレプリケーション・エージェントおよびキャッシュ・エージェントを起動します。

   レプリケーションを開始するには、次の手順を実行します。

   ttAdmin -repStart database1
   

   TimesTen Cacheを起動するには、次の手順を実行します。

   ttAdmin -cacheStart database1
   

これらのユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する項とttDaemonAdminに関する項を参照してください。

メモリーからのTimesTen Classicデータベースのアンロード

TimesTen Classicデータベースは、アプリケーションまたはTimesTenエージェント(キャッシュ・エージェントやレプリケーション・エージェントなど)が接続している場合は共有メモリーにロードされたままになります。また、TimesTen Classicデータベースは、アプリケーションやエージェントが接続されていなくても、特定のRAMポリシーが設定されている場合に共有メモリーに保持されることがあります。

TimesTen Classicのデータベースをメモリーからアンロードする前に、まずデータベースを閉じ、データベースへのアクティブな接続をすべて閉じ、データベースのRAMポリシーをmanualまたはinUseに設定する必要があります。

ノート: 次のステップで使用する例では、database1が、アンロードされるデータベースです。これがレプリケーション・スキーム内のアクティブなマスターであり、TimesTen Cacheで構成されていることを前提としています。データベースには、レプリケーションとキャッシュの両方を構成でき、manual以外のRAMポリシーを設定できます。

1. データベースを閉じて、データベースに接続するための新しい要求を拒否します。

   ttAdmin -close database1
   

2. すべてのアプリケーションをデータベースから切断します。

   データベースへのアクティブな接続をすべて閉じるには、ttAdmin -disconnectコマンドを実行します。詳細は、このマニュアル内のデータベースからの切断、およびOracle TimesTen In-Memory DatabaseリファレンスのttAdminを参照してください。

3. レプリケーション・エージェントがデータベースで実行されている場合は、レプリケーションの状態をpauseに設定し、レプリケーション・エージェントを停止します。この例では、アクティブ・マスターdatabase1からスタンバイ・マスターstandbydbへのレプリケーション状態をpauseに設定してから、アクティブ・マスターdatabase1でレプリケーション・エージェントを停止します。

   ttRepAdmin -receiver -name database1 -state pause standbydb
   ttAdmin -repStop database1
   

4. キャッシュ・エージェントがデータベースで実行されている場合は、キャッシュ・エージェントを停止します。

   ttAdmin -cacheStop database1
   

5. RAMポリシーがmanualまたはinUseに設定されていることを確認します。次に、データベースをメモリーからアンロードします。詳細は、RAMポリシーの指定を参照してください。

   RAMポリシーがalwaysに設定されている場合は、それをmanualに変更してから、ttAdmin -ramPolicy -ramUnloadユーティリティ・オプションを使用してデータベースをメモリーからアンロードします。

   ttAdmin -ramPolicy manual -ramUnload database1
   

   RAMポリシーがmanualに設定されている場合は、ttAdmin -ramUnloadユーティリティを使用してデータベースをアンロードします。

   ttAdmin -ramUnload database1
   

   RAMポリシーがinUseに設定されており、猶予期間が設定されている場合は、猶予期間に0(ゼロ)を設定するか、猶予期間に設定した時間が経過するまで待機します。これでデータベースがアンロードされます。アクティブな接続をすべてクローズすると、RAMポリシーがinUseのデータベースがメモリーからアンロードされます。

   ttAdmin -ramGrace 0 database1
   

6. ttStatusユーティリティを実行して、データベースがメモリーからアンロードされ、データベースが閉じられていることを確認します。プロセスがない場合、データベースはアンロードされます。出力に「Closed for user connections」と表示されている場合、データベースは閉じられています。

   詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのttStatusを参照してください。

7. 必要に応じてTimesTenデーモンを停止します。

   ttDaemonAdmin -stop
   

ttAdminユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明を参照してください。

RAMポリシーの指定

TimesTen Classicでは、TimesTen Classicデータベースをメイン・メモリーにロードまたはアンロードするタイミングを決定するRAMポリシーを指定できます。TimesTen Classicデータベースごとに異なるRAMポリシーを設定できます。

ノート: TimesTen Scaleoutでは、システム管理者によるttGridAdminユーティリティを使用したデータベースの手動ロードおよびアンロードがサポートされています。

RAMポリシーのオプションは次のとおりです。

• 「manual」: データベースはシステム管理者によって手動でロードおよびアンロードされます。ロードされると、管理者がデータベースをアンロードする(ttAdmin -ramUnloadを使用)まで、またはリカバリ不能なエラー条件が発生しないかぎり、TimesTenによってデータベースはロードされたままになります。データベースは、管理者のみがシステムRAMに明示的にロードできます(ttAdmin -ramLoadオプションを使用)。これは、データベースの不要なロードまたはアンロードを回避できるため、推奨されるRAMポリシーです。

  ttAdmin -ramLoadオプションおよび-ramUnloadオプションの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のデータベース・ロード・ポリシーの設定に関する項を参照してください。データベース・エラーのリカバリに関する詳細は、「自動リカバリ失敗後のRAMポリシーの変更」を参照してください。

• inUse: データベースは、データベースへの最初の接続をオープンするとメモリーにロードされ、1つ以上の接続がオープンしているかぎり、メモリーに常駐したままになります。データベースへの最後の接続をクローズすると、データベースはメモリーからアンロードされます。これがデフォルトのポリシーです。

• inUse with RamGrace: データベースは、データベースへの最初の接続をオープンするとメモリーにロードされ、1つ以上の接続がオープンしているかぎり、メモリーに常駐したままになります。データベースへの最後の接続をクローズすると、猶予期間中、データベースはメモリーに常駐したままになります。データベースは、猶予期間中データベースに接続されているプロセスがない場合にのみメモリーからアンロードされます。猶予期間は、随時設定および再設定できます。猶予期間は、次に猶予期間が変更されるまでのみ有効です。

  
  

  ノート: アプリケーションで、TimesTenデータベースが最初の接続で自動的にロードされ、最後の切断で自動的にアンロードされる必要がある場合は、RAMポリシーをinUseまたはinUse with RamGraceに設定します。ただし、大規模なデータベースを使用する本番システムでRAMポリシーをinUseに設定すると、データベースが予期せずにアンロードおよびリロードされるというパフォーマンスの問題が発生する可能性があります。

  
  

• always: データベースはメモリーに常駐したままになります。TimesTenデーモンは再起動すると、データベースを自動的に再ロードします。リカバリ不能なエラー条件が発生しないかぎり、必ずデータベースは自動的に再ロードされます。

  alwaysのRAMポリシーは注意して使用する必要があります。障害が発生した場合、データベースを自動的にリロードすることは有益ではありません。また、システムの起動時にすべてのデータベースが同時にロードされると、システムの起動パフォーマンスに影響を与える場合があります。エラー・リカバリについては「自動リカバリ失敗後のRAMポリシーの変更」、およびデータベースをリロードしようとしたときに発生する可能性があることについては「自動リカバリ失敗後のデータベースの自動リロードを防止する」を参照してください。

システム管理者は、RAMポリシーを設定するか、ttAdminユーティリティまたはC API RAMポリシー・ユーティリティを使用してTimesTen Classic内のデータベースを手動でロードまたはアンロードします。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明または『Oracle TimesTen In-Memory Database C開発者ガイド』のTimesTenユーティリティAPIに関する説明を参照してください。

ノート: デフォルトでは、致命的なエラー後のデータベースの自動リカバリが失敗した場合、TimesTen Classicはalwaysおよびmanual RAMポリシーをInUseに変更して、失敗の再発を防止します。RAMポリシーの変更を防止する方法に関する詳細は、「自動リカバリ失敗後のRAMポリシーの変更」を参照してください。

次の例では、ttdata DSNで識別されるデータベースについてRAMポリシーをmanualに設定します。

ノート: 1行目で、RAMレジデント・ポリシーがmanualに設定されています。その他の出力には、ttAdminユーティリティで設定できる他のポリシーも示されています。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス・ガイド』のttAdminに関する説明を参照してください。

% ttAdmin –ramPolicy manual ttdata
RAM Residence Policy            : manual
Replication Agent Policy        : manual
Replication Manually Started    : False
Cache Agent Policy              : manual
Cache Agent Manually Started    : False
Database state                  : open

自動リカバリ失敗後のRAMポリシーの変更

致命的なエラーによってデータベースが無効になり、TimesTen Classicによって実行された自動データベース・リカバリが失敗した場合、デフォルトでは以下が発生します。

• manualおよびalwaysのRAMポリシーには変更はありません。

• レプリケーション・エージェントとキャッシュ・エージェントは再起動されません。

• データベースのリロードが数回失敗すると、TimesTen ClassicはpolicyInactiveモードを設定し、データベースのロードがそれ以上試行されないようにします。

ノート: 無効なデータベースがメモリーにまだ存在している間に大きなデータベースをメモリーにリロードすると、使用可能RAMが一杯になることがあります。データベースの自動リロードを防止する方法の詳細は、「自動リカバリ失敗後のデータベースのリロードを防止する」を参照してください。

自動リカバリ失敗後のデータベースの自動リロードを防止する

致命的なエラーが原因でデータベースが無効化された後、TimesTen Classicは、データベースがRAMポリシー、キャッシュ・エージェントのポリシーおよびレプリケーション・エージェントのポリシーの設定と一貫性を維持しているかぎり、データベースのリロードとリカバリを試みます。ただし、ユーザー・プロセスは、データベースの無効化を認識していない場合に引き続きデータベースに接続されていることがあります。この場合、すべてのユーザー・プロセスが接続を閉じるまで、無効化されたデータベースがメモリー上に存在します。したがって、無効化されたデータベースと新しくリロードされたデータベースの両方がメモリーに共存することがあります。データベースが大きい場合、これが問題になることがあります。

ノート: データベースのリロードとリカバリを実行するかどうかはRAMポリシーによって決定されるだけでなく、キャッシュ・エージェントとレプリケーション・エージェントも無効化後にデータベースをリロードするかどうかの要素になります。障害の後にデーモンがエージェントを自動的に再起動するようにキャッシュ・エージェントとレプリケーション・エージェントのポリシーを設定すると、エージェントはデータベースへの接続を開始します。これが初めての接続であれば、デーモンはデータベースをリロードし、リカバリを実行します。 キャッシュ・エージェントおよびレプリケーション・エージェントのポリシーの詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』のレプリケーション・エージェントの起動および停止に関する説明、『Oracle TimesTen Application-Tier Database Cacheユーザーズ・ガイド』のキャッシュ・エージェント起動ポリシーの設定に関する説明および『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明を参照してください。

無効化の後にデータベースが自動的にリロードすることを防止するには、ttAdmin -noautoreloadコマンドを使用します。デフォルトの自動データベース・リロード動作に戻すには、ttAdmin -autoreloadコマンドを使用します。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する説明を参照してください。

ノート: ttRamPolicyAutoReloadSet組込みプロシージャは、ttAdmin -noautoreloadおよびttAdmin -autoreloadと同じ処理を実行します。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttRamPolicyAutoReloadSetに関する説明を参照してください。

次のいずれかによってデータベースの初期化とリカバリが開始し、通常の動作に戻ります。

• TimesTenデーモンが再起動する。

• プロセスが正常に接続される。

• 管理者がデータベースのttAdminコマンドを実行し、RAMポリシーの変更、RAMロードの実施、キャッシュまたはレプリケーション・エージェントの開始のいずれかを行う。

データベースの自動リロードを防止する動作を設定した場合、リロードされていないデータベースに接続しようとすると次のエラーメッセージが表示されることがあります。

Error 707, "Attempt to connect to a data store that has been manually unloaded from RAM"

データベースからの切断

最初に正しい順序でアプリケーションの接続を切断することで、データベースを停止またはアンロードできます。強制切断オプションは、アイドル状態または応答しないものを含め、接続されているすべてのアプリケーションをデータベースから非同期的に切断します。

• データベースの共有メモリー・セグメントから安全に切断およびデタッチします。

• アイドル状態か応答のない接続を正常に切断します。

次の項では、TimesTenデータベースから接続を切断する方法について説明します。

• TimesTen Scaleoutデータベースからの切断

• TimesTen Classicデータベースからの切断

TimesTen Scaleoutデータベースからの切断

TimesTen Scaleoutデータベースからすべてのアプリケーションを個別に切断できない場合は、ttGridAdmin dbDisconnectコマンドを使用して、データベースからすべてのユーザー接続を切断します。詳細は、Oracle TimesTen In-Memory Database Scaleoutユーザーズ・ガイドのメモリーからのデータベースのアンロードを参照してください。

TimesTen Classicデータベースからの切断

ttAdmin -disconnectコマンドを使用してTimesTen Classicデータベースへのすべての接続を切断できます。ただし、sys.odbc.iniファイル内のDSN定義でForceDisconnectEnabled接続属性を1に設定することで、最初に強制切断の機能を有効にする必要があります。詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのForceDisconnectEnabledを参照してください。

制御はコマンド・プロンプトに戻りますが、強制切断操作は完了までに数秒(または数分)かかることがあります。ttStatusユーティリティで、強制切断操作のステータスを確認します。

強制切断操作の進行中は、新しい接続リクエストはメイン・デーモンによって拒否されます。強制切断操作が完了すると、新しい接続が受け入れられます。

緊急度レベルで、どのくらい緊急に接続を強制切断する必要があるかを指定できます。

• -transactionalオプションは、オープン状態のトランザクションがコミットまたはロールバックされるまで待機してから切断します。アイドル状態の接続には影響しません。

• -immediateオプションは、オープン状態のトランザクションをロールバックしてから即座に切断します。このオプションでは、アイドル状態の接続も切断されます。

• -abortオプションは、切断のためにダイレクト・モードのすべてのアプリケーション・プロセスおよびクライアント/サーバー・プロセス(ttcserver)を中止します。

ほとんどの場合は、transactional緊急度レベルとimmediate緊急度レベルを使用する必要があります。必要に応じて-disconnectコマンドを2回実行することをお薦めします。最初にtransactional緊急度レベルを使用します。その後、しばらくしてから、ttStatusを使用して、接続が閉じられたかどうかを確認します。まだすべての接続が閉じられたわけではない場合は、immediate緊急度レベルを使用します。

abort緊急度レベルを使用する必要があるのは、transactional緊急度レベルとimmediate緊急度レベルのどちらでも、指定された接続すべてを正常に切断できなかった場合のみです。abortオプションを使用すると、中止操作によって、データベースに接続されているすべてのユーザーとttcserverサーバー・プロセスが終了されるため、トランザクションが失われる可能性があります。

粒度レベルで、切断する接続のタイプを指定できます。

• -usersオプション(デフォルト)は、データベースへのすべてのユーザー接続を切断します。たとえば、データベース・メンテナンスの実行準備時にこの粒度レベルを使用します。

• -unloadオプションは、サブデーモン接続を含め、データベースへのすべての接続を切断します。たとえば、データベースのアンロード試行時にこの粒度レベルを使用します。

ノート: always RAMポリシーは、unload粒度レベルと競合します。これらを同時に使用すると、エラーが返されます。

ttAdmin -disconnectコマンドの使用方法の詳細は、Oracle TimesTen In-Memory Databaseリファレンスの強制切断を参照してください。

例2-1 すべての接続の切断およびTimesTen Classicデータベースのアンロード

次のスクリプトは、まずtransactional緊急度レベルを指定してttAdmin -disconnectを実行することで、すべての接続を切断し、データベースをアンロードします。その後、このスクリプトはしばらく待機し、immediate緊急度レベルを試す前に、接続が切断されたかどうかを評価します。

#!/bin/sh
 
# disconnect users and unload the database with the transactional urgency level
ttAdmin -disconnect -transactional -unload database1
 
# wait 10 seconds for the forced disconnect to finish
COUNT = 0
while [ ttStatus | grep "pending disconnection" ] || [ $COUNT -ne 10 ]
do
  sleep 1
  COUNT=$((COUNT+1))
done
 
# increase the urgency level to immediate
if [ ttStatus | grep "pending disconnection" ]; then
  ttAdmin -disconnect -immediate -unload database1
fi

ttStatusユーティリティを使用して進行状況を確認します。強制切断操作の間に、出力において、保留中の切断が示されます。

TimesTen status report
 
Daemon pid 10457 port 6627 instance user1
TimesTen server pid 10464 started on port 6629
------------------------------------------------------------------------
------------------------------------------------------------------------
Data store /disk1/databases/database1
Daemon pid 10457 port 6627 instance user1
TimesTen server pid 10464 started on port 6629
There are 14 connections to the data store, ***14 pending disconnection***
Shared Memory KEY 0x0210679b ID 949092358
PL/SQL Memory KEY 0x0310679b ID 949125127 Address 0x5000000000
Type            PID     Context             Connection Name              ConnID
Process         10484   0x00007f3ddfeb4010  tt_181                            1
...

データベースのメモリー領域サイズの指定

TimesTenは、連続した単一のメモリー領域内に2つの個別のメモリー領域を作成してデータベース領域を管理します。1つの領域には永続データが格納され、もう1つには一時データが格納されます。

• 永続データには、TimesTenデータベースを構成する表および索引が含まれます。データベースをメモリーにロードする際に、永続メモリー領域の内容がファイル・システム上のファイルから読み込まれます。永続メモリー領域は、チェックポイント処理の際にファイル・システムに書き込まれます。TimesTenでは、例外的なパフォーマンスを実現するために、すべてのデータがRAMに格納されます。新しいデータの断片のための領域が残っていない場合、データベースはエラーをスローします。PermSizeは、データベースの再起動によって増加できますが、減少できません。

• 一時データには、ロック、カーソル、コンパイルしたコマンド、およびコマンドの実行と問合せ評価に必要なその他の構造が含まれます。一時メモリー領域は、データベースをメモリーにロードする際に作成され、データベースをアンロードする際に削除されます。

データベースがメモリーに格納されている場合にデータベースのサイズを制御する接続属性には、PermSizeおよびTempSizeがあります。PermSize属性には、永続メモリー領域のサイズを指定し、TempSize属性には一時メモリー領域のサイズを指定します。

ノート: これらの属性の詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのPermSizeおよびTempSizeを参照してください。

永続データ・パーティションおよび一時メモリー領域のサイズは、データベースをメモリーにロードする際に設定され、データベースがメモリーに格納されている間は変更できません。いずれかの領域のサイズを変更するには、メモリーからデータベースをアンロードし、PermSize属性またはTempSize属性の値を変更して再度接続する必要があります。メモリーからのデータベースのアンロードの詳細は、「メモリーからのデータベースのロードとアンロード」を参照してください。

次の項では、データベース・サイズの管理について説明します。

• データベースのメモリー領域サイズの見積りおよび変更

• PermSize属性およびTempSize属性の監視

• TimesTen Classicのデータベース・サイズの縮小

• メモリー不足の警告受信

データベースのメモリー領域サイズの見積りおよび変更

データベース操作は、十分なメモリーの割当てがないと、正常に完了できません。最初に、TimesTenの永続および一時メモリー領域およびトランザクション・ログ・バッファの適切なサイズを決定します。

ttSizeユーティリティを使用するか、適切な見積りが得られるまでアプリケーションを実行して、次のTimesTen接続属性を設定します。

• PermSize: 実際のデータが格納されているデータベースの永続メモリー領域のサイズ(MB単位)。すべてのデータを保持できるようPermSizeを十分に確保してください。この値は、大きくすることはできますが、このデータベースに対して小さくすることはできません。

  TimesTen Classicでは、データベースを小さいサイズで再作成することによって、永続メモリー領域を縮小できます。詳細は、「TimesTen Classicのデータベース・サイズの縮小」を参照してください。

  
  

  ノート: ttSizeユーティリティは、TimesTen Classicのデータベースに最適化されています。TimesTen ScaleoutデータベースのPermSize接続属性の適切な値を評価する方法の詳細は、『Oracle TimesTen In-Memory Database Scaleoutユーザーズ・ガイド』のPermSize属性の値の決定に関する項を参照してください。

  
  

• TempSize: TimesTen Classicの場合、TempSizeはデータベースの一時領域に割り当てられるメモリーの合計容量をMBで示します。TimesTen Scaleoutの場合、TempSizeは、要素の一時領域に割り当てられるメモリーの合計容量をMBで示します。TempSizeが不十分な場合、関連データベース処理が失敗する可能性があります。このサイズは、データベースの再起動で変更できます。

• LogBufMB: 内部トランザクション・ログ・バッファのサイズ(MB単位)。デフォルトでは、LogBufMBは64MBです。詳細は、「ログ・バッファおよびログ・ファイル・サイズ・パラメータの構成」を参照してください。

これらの属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のPermSize、TempSize、LogBufMBおよびLogFileSizeを参照してください。

次に、システムの共有メモリー・セグメントの最大サイズがデータベースを格納するために十分な大きさであることを確認します。データベースによって使用されることが予想される接続の最大数を使用します。すべての値の単位はMB (メガバイト)です。次よりも大きくなるようにします。

PermSize + TempSize + LogBufMB + 1 + (.043 * connections)

ノート: TimesTen Classicデータベースがレプリケーション用に構成されている場合は、データベースのすべてのレプリカについてデータベース・サイズを再構成します。データベースのサイズを変更した後、データベースをメモリーにロードし、キャッシュ・エージェントおよびレプリケーション・エージェントを再起動します。

システム上に複数のTimesTenデータベースがあり、それぞれが独自の共有メモリー・セグメントを使用している場合、共有メモリー・セグメントの最大サイズは最大データベースに対応できる十分な大きさである必要があります。

次に、必要な共有メモリー割当て合計を決定します(適切な単位に変換されます)。システム上に複数のTimesTenデータベースがある場合、データベースごとに前述の式を使用して、共有メモリー割当て合計をこれらすべてに対応できる十分な大きさにする必要があります。(その後、たとえばLinuxでは、この値をページ・サイズ(通常、4096バイト)で除算して、ページ単位のメモリー割当て合計を取得します。)

ノート: TimesTen Classicで、追加の共有セグメントを作成する場合、PL/SQLではPLSQL_MEMORY_SIZE接続属性を使用し、Client/Serverでは(timesten.confの)-server_shmsize構成オプションを使用します。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のPLSQL_MEMORY_SIZEに関する項を参照してください。デフォルト値または同様に小さいサイズを使用する場合は、これらのセグメントに対応するために共有メモリー内に十分な未使用領域がある必要があります。

最後に、データベースの無効化を許容する場合は、少なくともTimesTenデータベースの最大サイズの2倍以上の物理メモリーが必要になります。許容しないが、無効化が発生した場合は、データベースを使用するすべてのプロセスおよび接続が検出されて終了されるまで、データベースをメモリーに再ロードできません。

Oracle TimesTen In-Memory Databaseインストレーション、移行およびアップグレード・ガイドのLinuxの前提条件も参照してください。

PermSize属性およびTempSize属性の監視

SYS.V$MONITORおよびSYS.GV$MONITORシステム・ビューには、PermSizeおよびTempSizeの使用状況の監視に使用できるいくつかの列があります。具体的には、PERM_ALLOCATED_SIZE、TEMP_ALLOCATED_SIZE、PERM_IN_USE_SIZE、PERM_IN_USE_HIGH_WATER、TEMP_IN_USE_SIZEおよびTEMP_IN_USE_HIGH_WATERの各列です。これらの各列には、データベースに現在割り当てられているサイズや、データベースの使用中のサイズがKB単位で表示されます。この情報は、接続が確立または解放されるたび、およびトランザクションがコミットまたはロールバックされるたびにシステムによって更新されます。

たとえば、全ワークロードを実行し、一時領域の使用量の多い水位標(TEMP_IN_USE_HIGH_WATER)を監視して、一時領域の使用量を評価できます。最高水位標は、ttMonitorHighWaterReset組込みプロシージャを使用してリセットできます。また、必要に応じて、TempSizeを監視対象のTEMP_IN_USE_HIGH_WATER値に変更し、10%を追加することもできます。

ノート: ttIsqlのdssizeコマンドを使用して、この情報を提供することもできます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttIsql dssizeコマンドの使用に関する項およびttIsqlに関する項を参照してください。

データベース内のブロック・レベルの断片化を監視するには、SYS.V$BLOCK_INFOまたはSYS.GV$BLOCK_INFOシステム表を使用するか、ttBlockInfo組込みプロシージャをコールします。

これらのビューの詳細は、『Oracle TimesTen In-Memory Databaseシステム表およびビュー・リファレンス』のSYS.GV$MONITORに関する項、SYS.V$MONITORに関する項、SYS.GV$BLOCK_INFOに関する項またはSYS.V$BLOCK_INFOに関する項を参照してください。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttBlockInfoに関する説明を参照してください。

TimesTen Classicのデータベース・サイズの縮小

TimesTen Classicデータベースに特定のサイズの永続領域(PermSize DSN属性で示される)を定義した場合は、表または行を削除しても、それより小さいサイズに縮小できません。

TimesTen Classicデータベースの永続領域の割当てサイズを減らすには、ttMigrateユーティリティを実行してデータベースのコピーを保存してから、永続領域のサイズがより小さいデータベースを再作成し、データをリストアします。

TimesTen Classicデータベースの永続領域サイズを縮小するには、次のステップを実行します。

1. ttAdmin -disconnectコマンドを使用して、データベースからアプリケーションを切断します。詳細は、このマニュアル内の「TimesTen Classicデータベースからの切断」、および『Oracle TimesTen In-Memory Databaseリファレンス』のttAdminに関する項を参照してください。

2. ttMigrate -cオプションを使用してデータベースのデータ・ファイルを作成します。

   % ttMigrate -c database1 /tmp/database1
   

3. メモリーからTimesTen Classicデータベースをアンロードします。詳細は、「メモリーからのTimesTen Classicデータベースのアンロード」を参照してください。

4. より小さいPermSize値を指定するデータベースの新しいコピー用に、新しいDSN定義を作成します。新しいDSNを作成するのではなく、元のDSNを変更する場合は、ttDestroyユーティリティを使用して元のTimesTen Classicデータベースを破棄してから、バックアップをリストアする必要があります。

5. AutoCreate=1を指定したttIsqlを使用して、TimesTen Classicデータベースを再作成します。

   ttIsql -connstr "dsn=database1;AutoCreate=1" -e "quit"
   

   この時点でデータベースは空です。

6. ttMigrate -rオプションおよび-relaxedUpgradeオプションを使用して、バックアップをリストアします。

   % ttMigrate -r -relaxedUpgrade database1 /tmp/database1
   

ノート: TimesTen Classicデータベースの永続領域のサイズは、現在データベースに格納されているデータで必要なサイズより小さくすることはできません。この値は、v$monitorシステム・ビューのperm_in_use_size列を問い合せることで判断できます。 また、この手順を使用して、部分的な全表ページ、または索引ノードと範囲外の値を格納するヒープ・バッファに起因する断片化を減らすためにTimesTen Classicデータベースを圧縮することもできます。

メモリー不足の警告受信

メモリー不足の警告を受信するには、アプリケーションでttWarnOnLowMemory組込みプロシージャをコールする必要があります。

TimesTen Classicには、メモリー不足の警告を発行するタイミングを指定するPermWarnThresholdおよびTempWarnThresholdの2つの一般接続属性も用意されています。いずれの属性も、パーセントで値を指定します。

TimesTenの記憶域のプロビジョニング

記憶域のプロビジョニングとは、サーバーの記憶域領域を割り当てるプロセスです。

• TimesTenインストールの記憶域の割当て: TimesTenインストールには、すべてのソフトウェアが含まれています。

  各TimesTenインストールに1.5 GB以上を割り当てることを計画します。同じシステムで複数のインスタンスを実行する場合、これらすべてで1つのTimesTenインストールを共有できます。ソフトウェア・バージョンのアップグレードを組み込むには、その領域の量と追加の領域をプロビジョニングする必要があります。

• TimesTenインスタンスの記憶域の割当て: 各TimesTenインスタンスは、独自のデーモン・プロセスのセット(および関連するデーモン・ログ・ファイル)を実行します。

  各TimesTenインスタンスに256 MB以上を割り当てることを計画します。

• チェックポイント・ファイル: 各TimesTenデータベースには、2つのチェックポイント・ファイル用のディスク領域が必要です。各ファイルはDataStore属性で指定されたディレクトリに格納されます。各チェックポイント・ファイルはファイル・システム上で大きくなるので、サイズが小さくなることはありません。そのため、各チェックポイント・ファイルのサイズは、データベースが永続メモリー領域でアクセスしたことのあるデータベースの最大サイズに等しくなることがあります。そのため、各チェックポイント・ファイルが永続メモリーに定義された領域の量(PermSize接続属性で定義)とほぼ同じになると仮定して計画する必要があります。

  データベースの永続領域の合計を2倍して30%を加えた領域を割り当てることを計画します。

  
  

  ノート: TimesTen Classicでは、Preallocate接続属性を1に設定すると、TimesTenはチェックポイント・ファイルへの接続時にファイル・システム領域を保持できます。これは大規模なデータベースで役立ちます。これにより、データがデータベースに追加されるときに、ファイル・システムに常にチェックポイント・ファイル用の領域が確保されます。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のPreallocateに関する項を参照してください。

  
  

• トランザクション・ログ・ファイル: トランザクション・ログ・ファイルは、見積もることが最も難しい領域要件です。トランザクション・ログ・ファイルの領域のプロビジョニングを計画する方法は、「トランザクション・ログ・ファイルの記憶域のプロビジョニング」を参照してください。

• TimesTen Scaleoutのリポジトリのバックアップ・ファイルまたはエクスポート・ファイルに対応するローカル領域。

  SCPがアタッチされたリポジトリを使用する場合、すべての操作は、最初にターゲット・インスタンスによってローカルに保存されてから、リポジトリにコピーされます。ターゲット・データ・インスタンスにより、最初にバックアップ(またはエクスポート)ファイルが$timesten_home/grid/admin/tempディレクトリに格納されます。最終的にリポジトリに格納されるバックアップ・ファイルまたはエクスポート・ファイルの最大サイズに対応できるように、このディレクトリに十分な記憶域をプロビジョニングする必要があります。

  PermSizeにレプリカ・セットの数を乗算した領域を割り当てることを計画します。

• TimesTen Scaleoutでのリポジトリの記憶域のプロビジョニング。

  1つのバックアップ・ファイルには、各レプリカ・セットの1つの要素が含まれます。そのため、データベース内の表のすべての行を含めるために必要なバックアップ・ファイルの数は、データベース内のレプリカ・セットの数に対応します。

  
  

  ノート: ハッシュ分散表の場合、各バックアップ・ファイルには表の行の一部のみが含まれます。ハッシュ分散表の行は、レプリカ・セットの数に分散されます。 複製された表の場合、各バックアップ・ファイルには各表のすべての行が含まれます。

  
  

  PermSizeにレプリカ・セットの数を乗算した領域を割り当てることを計画します。

トランザクション・ログ・ファイルの記憶域のプロビジョニング

ノート: テスト環境内では、より正確なトランザクション・ログのボリュームの見積りを生成できます。

トランザクション・ログ・ファイルに必要なファイル・システム領域の割当てを見積もる場合は、次のことを考慮してください。

• TimesTenは、いずれかのチェックポイント・ファイルからのリカバリをサポートするのに十分なトランザクション・ログ・ファイルを保持します。トランザクション・ログ・ファイルが蓄積されるかどうかは、バックグラウンドのチェックポイント処理の設定(CkptLogVolumeおよびCkptFrequency初期接続属性で定義)によって決まります。さらに、TimesTenでは、3つの追加のトランザクション・ログ・ファイルの領域を事前に割り当てます。

• TimesTenでは、バックグラウンド処理にファジー・チェックポイント処理を使用します。トランザクション・ログ・ファイルは、ファジー・チェックポイント処理中に蓄積される可能性があります。チェックポイントの作成にかかる時間は、PermSize接続属性に割り当てられた値を使用して計算されます。

• トランザクション・ログ・ファイルは、増分バックアップで蓄積されることがあります。

• TimesTen Scaleoutでは、各レプリカ・セット内の要素ごとに、トランザクション・ログ・レコードを格納する独自のトランザクション・ログ・ファイルがあります。トランザクションによってレプリカ・セット内のデータが変更された場合、通常はレプリカ・セットの両方の要素に変更が記録されます。ただし、レプリカ・セット内のいずれかの要素が停止している場合、アクティブな要素のトランザクション・ログ・ファイルにのみ変更が記録されます。レプリカ・セット内の1つの要素が非常に長い時間停止している場合、トランザクション・ログ・ファイルが蓄積される可能性があります。

• TimesTen Classicでは、トランザクション・ログ・ファイルは、一時的なレプリケーションの停止中またはサブスクライバが停止している場合に、マスターに蓄積されることがあります。

  
  

  ノート: CREATE REPLICATION文およびALTER REPLICATION文のFAILTHRESHOLD句を使用して、保持するトランザクション・ログ・ファイルの数を制限できます。

  
  

これらの接続属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のCkptLogVolumeに関する項、CkptFrequencyに関する項およびPermSizeに関する項を参照してください。これらのSQL文の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』のCREATE REPLICATIONに関する項およびALTER REPLICATIONに関する項を参照してください。

トランザクション・ログのボリュームの見積りは、ピーク更新トランザクション率、およびデータベースを変更する各トランザクションの平均複雑度によって異なります。

次の点を考慮してください。

• Bは、トランザクション当たりのトランザクション・ログのボリュームをバイト単位で表します。

• Cは、更新される列の数を表します。最小トランザクション更新(1つの数値列の更新)では、400バイトのトランザクション・ログ・データが生成されます。追加の数値列を更新するたびに、さらに250バイトが生成されます。

• Vは、書込みトランザクションごとに、挿入または更新される大きいデータの平均サイズを表します(CHAR、VARCHAR2、BINARY、VARBINARYまたはLOBの型の列)。

各トランザクションのトランザクション・ログのボリュームを見積もるには、次の式を使用します。

B = 400 + ((C-1) * 250) + V

次のように、最初の列は後続のすべての列より150バイトのみ大きいことに注意してください。

B = (C * 250) + (400-250) + V

これを簡単にすると次のようになります。

B =(C * 250) + 150 + V

トランザクション・ログの推定ボリューム(B)に予想されるピーク・トランザクション率を乗算して、予想されるピーク・トランザクション・ログ率を計算します。

説明:

• L = トランザクション・ログ・ファイルにプロビジョニングする合計記憶域領域(バイト単位)。

• C = 書込みトランザクションごとに挿入または更新される列の平均数。

• V = 書込みトランザクションごとに挿入または更新される大きいデータの平均バイト(CHAR、VARCHAR2、BINARYまたはVARBINARYの列)。

• S = 必要なトランザクション・ログの保存時間(秒)。

• T = S秒間隔の、平均の1秒当たりのピーク・トランザクション率。

• f = 挿入、更新または削除処理を含むトランザクションの割合。

• 最後に、不測の事態に備えて、推定ファイル・システム領域をさらに30%増やします。

これらのすべての係数を考慮し、次の式に従って、プロビジョニングされるトランザクション・ログ・ファイル領域をバイト単位で見積もります。

L = ((C * 250) + 150 + V) * S * T * f * 1.3

例2-2 記憶域のプロビジョニングの見積り

たとえば、ワークロードは35%の更新トランザクションで構成されています。各トランザクションは4つの列を更新します。これには2つの文字列が含まれ、それぞれ平均30バイトが更新されます。ワークロードは1秒当たり100万トランザクションで実行され、1時間分のトランザクションを格納するのに十分なトランザクション・ログ領域が必要です。

• C = 4列

• V = 30

• S = 3600

• T = 1,000,000

• f = 35% = 0.35

このワークロードには次の領域が必要です。

L = ((4 * 250) + 150 + 30) * 3,600 * 1,000,000 * 0.35 * 1.3 = 1.9 TB

したがって、トランザクション・ログ・ファイルのファイル・システム領域として1.9 TBをプロビジョニングします。

ttBulkCpユーティリティを使用したデータのバルク・コピー

ttBulkCpユーティリティでは、TimesTen表とASCIIファイルの間でデータをコピーできます。

ttBulkCpユーティリティを使用して、データベース内の既存の表の特定の側面を管理できます。ttBulkCpユーティリティを使用すると、既存の表へのデータ行の追加、ASCIIファイルへのデータの保存、TimesTenデータベース内の表へのデータ行のロードが可能です。

追加する行には、表と同じ列数を含める必要があります。また、各列のデータは、その列に定義されているデータ型である必要があります。

ttBulkCpユーティリティはASCIIファイルに保存されたデータに対して処理を行うため、列数とデータ型がTimesTenデータベースの表の列数とデータ型と一致し、検出されたファイルがttBulkCpと互換性がある場合、このユーティリティを使用して他のアプリケーションからデータをインポートすることもできます。

• TimesTen表からASCIIファイルへのデータのコピー

• ASCIIファイルからTimesTen表へのデータのコピー

TimesTen表からASCIIファイルへのデータのコピー

-oオプションを使用してttBulkCpユーティリティを実行し、TimesTen表からASCIIファイルにデータをコピーします。

ノート: TimesTenユーザーが情報のコピー元の表に対するSELECT権限を持っていることを確認してください。

例2-3 ttBulkCp -oモード

この例では、database1データベースのhr.employees表からemployees.dmpファイルにデータをコピーします。

% ttBulkCp -o -connstr "DSN=database1;UID=HR;PWD=hr" hr.employees > employees.dmp

ttBulkCpユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttBulkCpに関する項を参照してください。

ASCIIファイルからTimesTen表へのデータのコピー

ttBulkCpユーティリティでは、ASCIIファイルからデータベース表にデータをコピーできます。ttBulkCpユーティリティは、表に重複する行をコピーしません。

• -iオプションを使用したttBulkCpの実行

• TimesTen Classicでの-directLoadオプションを使用したttBulkCpの実行

-iオプションを使用したttBulkCpの実行

-iオプションを指定してttBulkCpユーティリティを使用すると、ファイルからデータをロードできます。このオプションでは、標準のINSERT SQL文を使用して、TimesTenデータベースの特定の表にデータをロードします。

TimesTen Scaleoutでは、ttBulkCpユーティリティにより、表の分散スキームに基づいて、各行が対応する要素に挿入されます。TimesTen Scaleoutでは、1つの場所または複数の場所から表を移入できます。TimesTen ScaleoutでのttBulkCpユーティリティの使用方法の詳細は、『Oracle TimesTen In-Memory Database Scaleoutユーザーズ・ガイド』のデータベースへのデータのバルク・ロードに関する項を参照してください。

ノート: TimesTenユーザーが情報のコピー先の表に対するINSERT権限を持っていることを確認してください。

例2-4 ttBulkCp -iモード

この例では、employees.dmpファイルからdatabase1データベースのhr.employees表にデータをコピーします。

% ttBulkCp -i -connstr "DSN=database1;UID=HR;PWD=hr" hr.employees employees.dmp

employees.dmp:
    107 rows inserted
    0 duplicate rows not inserted
    107 rows total

ttBulkCpユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttBulkCpに関する項を参照してください。

TimesTen Classicでの-directLoadオプションを使用したttBulkCpの実行

-directLoadオプションを使用してttBulkCpユーティリティを実行し、ASCIIファイルからTimesTen Classicデータベース表にデータをコピーします。-directLoadオプションは、標準のINSERT SQL文を使用してデータをロードします。ttBulkCp -directLoadオプションは、直接接続を使用するアプリケーションでのみ使用できます。これを使用すると、クライアント/サーバー接続の使用時に必要なオーバーヘッドの一部が回避され、-iオプションよりもパフォーマンスが向上します。

パフォーマンスを向上させるために、-directLoadオプションを指定してデータをロードする前に、索引を削除することを検討してください。ttSchemaユーティリティを使用して、TimesTen Classicデータベースの表に作成されているすべての索引の定義を表示します。ロード操作が完了したら、手動で表に索引を再作成します。ttSchemaユーティリティの詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのttSchemaを参照してください。

ノート: TimesTenユーザーが情報のコピー先の表に対するINSERT権限を持っていることを確認してください。

例2-5 ttBulkCp -directLoadオプション

この例では、employees.dmpファイルからdatabase1データベースのhr.employees表にデータをコピーします。

% ttBulkCp -directLoad -connstr "DSN=database1;UID=HR;PWD=hr" hr.employees employees.dmp

employees.dmp:
    107 rows inserted
    0 duplicate rows not inserted
    107 rows total

ttBulkCpユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttBulkCpに関する項を参照してください。

TimesTenを使用したスレッド・プログラミング

TimesTenでは、データベースへのマルチスレッド・アプリケーション・アクセスがサポートされています。データベースに接続すると、すべてのスレッドで、この接続に対する処理を発行できます。

通常、スレッドは、スレッド固有の接続に対して処理を発行するので、他のすべてのスレッドでは別のトランザクションが存在します。スレッドの作成および削除が頻繁に行われる環境では、接続をプールに保持することでパフォーマンスを向上できます。スレッドは、必要に応じてこのプールから接続を割り当てて、接続および切断によるオーバーヘッドを回避できます。

TimesTenでは、複数のスレッドで同じ接続に対してリクエストを発行できるため、トランザクションにリクエストが混在します。これらのリクエストは、TimesTenによってシリアライズされます(アプリケーションによっては、独自のシリアライズが必要な場合があります)。

また、TimesTenは、1つのスレッドで複数の接続にリクエストを出したり、同一のデータベースまたは異なるデータベースに対して、複数の個別トランザクションおよび同時トランザクションを制御することができます。

TimesTenデータベースのデフラグ

一部の状況では、TimesTenデータベースではメモリー・フラグメンテーションが進行しているため、大量の空きメモリーが既存の表の部分的に埋まったページに割り当てられていることがあります。これにより、空きメモリーが不足するため、他のユーザーにメモリーを割り当てられなくなることがあります(他の表用の新しいページなど)。このような状況では、メモリーを他のユーザーが利用できるようにするために、データベースをデフラグする必要があります。

表がALTER TABLE ADD SQL文で変更されてから、2番目の表パーティションが作成されます。デフラグメンテーションにより、2番目の表パーティションを削除し、すべての表の列を含む1つの表パーティションを作成できます。2番目の表パーティションが作成された場合、領域の利用およびパフォーマンスを向上するために、データベースを定期的にデフラグすることをお薦めします。

次のプロシージャは、両方のタイプのデータベース断片化に対応します。

• TimesTen Scaleoutデータベースのオフライン・デフラグメンテーション

• TimesTen Classicデータベースのオフライン・デフラグメンテーション

• TimesTen Classicデータベースのオンライン・デフラグメンテーション

TimesTen Scaleoutデータベースのオフライン・デフラグメンテーション

TimesTen Scaleoutデータベースは、エクスポート処理およびインポート処理の一部としてデフラグされます。そのため、TimesTen Scaleoutデータベースをデフラグするには、ttGridAdmin dbExportコマンドおよびdbImportコマンドを使用します。詳細は、『Oracle TimesTen In-Memory Database Scaleoutユーザーズ・ガイド』のデータベースのエクスポートおよびインポートに関する項を参照してください。

TimesTen Classicデータベースのオフライン・デフラグメンテーション

TimesTen Classicデータベースをデフラグするには、次のようにttMigrateユーティリティを使用します。

1. データベースへのすべての接続を停止します。

2. ttMigrateを使用してデータベースのコピーを保存します。

   % ttMigrate -c ttdb ttdb.dat
   

3. 管理ユーザーとして、ttdbデータベースを再構築します。

   % ttMigrate -r -relaxedUpgrade -connstr "dsn=ttdb" ttdb.dat
   

   
   

   ノート: ttMigrate -r -relaxedUpgradeコマンドを使用して、最大表のデフラグメンテーションを実現できます。-relaxedUpgradeオプションも表パーティションを圧縮します。表パーティションを圧縮しない場合は、ttMigrate -r -relaxedUpgradeコマンドから-relaxedUpgradeオプションを削除します。

   
   

このとき

• すべてのユーザー、キャッシュ・グループおよびアクティブ・スタンバイ・ペアはttdbにリストアされています。

• キャッシュ・グループは、AUTOREFRESH STATE = OFF状態にあります。

• キャッシュ・エージェントおよびレプリケーション・エージェントは実行されていません。

ALTER TABLE ADD SQL文を使用して表に列を追加するときに表パーティションを追加できます。詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス』の「ALTER TABLE」のノートを参照してください。パフォーマンス上の考慮事項については、「ALTER TABLEの回避」も参照してください。

ttMigrateの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttMigrate」を参照してください。

TimesTen Classicデータベースのオンライン・デフラグメンテーション

(最小の総サービス・ダウンタイムで) TimesTen Classicデータベースをデフラグするには、ttMigrate -relaxedUpgradeおよびttRepAdmin -duplicateユーティリティを組み合せて使用します。これらのデータベースは、TABLE DEFINITION CHECKINGがRELAXEDに設定されているレプリケーション・スキームに関係しています。また、ttMigrate -relaxedUpgradeオプションによってパーティションを圧縮します。

ノート: TimesTen Classicデータベースでアクティブ・スタンバイ・ペアのレプリケーション・スキームが使用されている場合に、アクティブ・スタンバイ・ペアのレプリケーション・スキームにいずれのキャッシュ・グループも含まれていないか、またはREADONLYキャッシュ・グループのみが含まれている場合は、これらのデータベースのみをデフラグできます。

次の項では、レプリケーション・スキームに関係しているTimesTen Classicデータベースをデフラグする方法について説明します。

ノート: 各項で示す例は、ユーザーがレプリケーション・スキームの構成および管理に精通していることを前提としています。詳細は、『Oracle TimesTen In-Memory Database開発者および管理者ガイド』の「スタート・ガイド」に関する説明を参照してください。

• アクティブ・スタンバイ・ペアのレプリケーション・スキーム内のTimesTen Classicデータベースのオンライン・デフラグメンテーション

• アクティブ・スタンバイ・ペアではないレプリケーション・スキーム内のTimesTen Classicデータベースのオンライン・デフラグメンテーション

アクティブ・スタンバイ・ペアのレプリケーション・スキーム内のTimesTen Classicデータベースのオンライン・デフラグメンテーション

次の項では、アクティブ・スタンバイ・ペアのレプリケーション・スキームに関係しているTimesTen Classicデータベースをデフラグする方法について説明します。

• スタンバイ・データベースの移行および再構築

• アクティブ・ロールとスタンバイ・ロールの入替え

• スタンバイの廃棄および新しいスタンバイの再作成

この項の例では、アクティブ・データベースがttdb1でスタンバイ・データベースがttdb2のアクティブ・スタンバイ・ペア・レプリケーション・スキームによるオンライン・デフラグメンテーションの実行方法を示しています。

スタンバイ・データベースの移行および再構築

スタンバイのTimesTenデータベースに対するレプリケーションを停止してそのスタンバイ・データベースのコピーを保存し、そのスタンバイ・データベースをデフラグする方法を次に示します。

ノート: スタンバイ・データベースをデフラグしている間、アプリケーション処理をアクティブ・データベースで続行できます。

スタンバイ・データベースのコピーを保存するには、次の手順を実行します。

1. スタンバイ・データベース(ttdb2)でレプリケーション・エージェントを停止します。

   % ttAdmin –repStop ttdb2
   

2. サブスクライバがある場合、アクティブ・データベースでttRepStateSaveを実行し、スタンバイのステータスを失敗に設定します。スタンバイ・データベースが使用できない間は、アクティブ・データベースへの更新は、サブスクライバ・データベースに直接レプリケートされます。

   Coomand> call ttRepStateSave('FAILED', 'ttdb2', 'ttsrv2');
   

3. ttMigrateを使用してスタンバイ・データベースのコピーを保存します。

   % ttMigrate -c ttdb2 ttdb2.dat
   

4. キャッシュ・エージェントを停止し、キャッシュ・グループを削除し、スタンバイを廃棄します。

   % ttAdmin –cacheStop ttdb2
   

   キャッシュ・マネージャ・ユーザーとして接続されている間に、すべてのキャッシュ・グループを削除します。

   Command> DROP CACHE GROUP t_cg;
   

   スタンバイ・データベースを破棄します。

   % ttDestroy ttdb2
   

5. スタンバイ・データベースを再構築します。インスタンス管理者として、スタンバイに次のことを実行します。

   % ttIsql ttdb2
   

6. キャッシュ・マネージャ・ユーザーを作成し、このユーザーにADMIN権限を付与します。

   Command> CREATE USER cacheadmin IDENTIFIED BY cadminpwd;
   Command> GRANT CREATE SESSION, CACHE_MANAGER, CREATE ANY TABLE,
    DROP ANY TABLE TO cacheadmin;
   Command> GRANT ADMIN TO cacheadmin;
   

   
   

   ノート: ttMigrate –rを実行するには、キャッシュ・マネージャ・ユーザーにはADMIN権限が必要です。移行が完了したら、希望する場合は、このユーザーからADMIN権限を取り消します。 ttMigrateの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttMigrate」を参照してください。

   
   

7. キャッシュ・マネージャ・ユーザーとして、ttdb2データベースを再構築します。

   % ttMigrate -r -relaxedUpgrade -cacheuid cacheadmin -cachepwd cadminpwd 
   -connstr "dsn=ttdb2;uid=cacheadmin;pwd=cadminpwd;oraclepwd=oraclepwd" ttdb2.dat
   

   このとき

   • すべてのユーザー、キャッシュ・グループおよびアクティブ・スタンバイ・ペアはttdb2にリストアされています。

   • キャッシュ・グループは、AUTOREFRESH STATE = OFF状態にあります。

   • キャッシュ・エージェントおよびレプリケーション・エージェントは実行されていません。

8. キャッシュ・マネージャ・ユーザーとして、スタンバイでキャッシュ・エージェントを起動します。

   % ttAdmin –cacheStart ttdb2
   

9. キャッシュ・グループをロードします。

   Command> ALTER CACHE GROUP t_cg SET AUTOREFRESH STATE PAUSED;
   Command> LOAD CACHE GROUP t_cg COMMIT EVERY 256 ROWS PARALLEL <nThreads>;
   

   
   

   ノート: このロード操作の場合に、TimesTenにデータを挿入するために使用するCPUコアの数に基づいてnThreadsを選択します。 複数の読取り専用キャッシュ・グループがある場合、TimesTenおよびOracle Databaseリソースが使用可能なときは、複数のLOAD操作を別々のセッションでパラレルで実行することをお薦めします。

   
   

10. 完了したら、キャッシュ・グループの状態を確認します。

    Command> cacheGroups;
    Cache Group CACHEADMIN.T_CG:
      Cache Group Type: Read Only
      Autorefresh: Yes
      Autorefresh Mode: Incremental
      Autorefresh State: On
      Autorefresh Interval: 10 Seconds
      
      Autorefresh Status: ok
      Aging: No aging defined
     
      Root Table: ORATT.T
      Table Type: Read Only
     
    1 cache group found.
    

11. スタンバイ・データベースでレプリケーション・エージェントを起動します。

    % ttAdmin -repStart ttdb2
    

12. スタンバイでレプリケーションの状態を確認します。

    % ttIsql ttdb2
    Command> call ttRepStateGet;
    < STANDBY >
    1 row found.
    

スタンバイ・データベース(ttdb2)はデフラグされ、アクティブ・データベースとスタンバイ・データベースの両方は機能しています。

アクティブ・ロールとスタンバイ・ロールの入替え

アクティブ・データベースにデータベース・デフラグメンテーションを実行するには、アクティブ・データベースとスタンバイ・データベースのロールを入れ替えます。アクティブ(ttdb1)はスタンバイ・データベースになります。元のスタンバイ(ttdb2)はアクティブ・データベースになります。

1. すべてのアプリケーション処理を停止し、ttAdmin -disconnectコマンドを使用してすべてのアプリケーション接続を切断します。処理中の問合せのみが、ttdb2 TimesTenデータベースで稼働するように移動できます。詳細は、このマニュアル内のデータベースからの切断、およびOracle TimesTen In-Memory DatabaseリファレンスのttAdminを参照してください。

2. 現行のスタンバイ・データベース(ttdb2)のデータベース名およびホストを入力パラメータとして、現行のアクティブ・データベース(ttdb1)でttRepSubscriberWait組込みプロシージャをコールします。これにより、キューに入れられたすべての更新が現行のスタンバイ・データベースに送信されます。

   
   

   ノート: waitTimeを-1に設定した場合、コールは、コール前にコミットされたすべてのトランザクションがサブスクライバに送信されるまで待機します。 ただし、waitTimeを任意の値(NULL以外の値にします)に設定する場合、操作を実行する前に、timeOut戻りパラメータの値が0x00であることを確認してください。戻り値が0x01の場合、コール前にコミットされたすべてのトランザクションがサブスクライバに送信されるまでttRepSubscriberWait組込みプロシージャをコールします。 ttRepSubscriberWait組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttRepSubscriberWaitに関する説明を参照してください。

   
   

   Command> call ttRepSubscriberWait(NULL,NULL,'ttdb2','ttsrv2', 100);
   

3. 現行のアクティブ・データベースでレプリケーション・エージェントを停止します。

   Command> call ttRepStop;
   

4. 現行のアクティブ・データベースでttRepDeactivate組込みプロシージャをコールします。これによって、このデータベースはIDLE状態になります。

   Command> call ttRepDeactivate;
   Command> call ttRepStateGet;
   < IDLE >
   1 row found.
   

5. 古いスタンバイ・データベースでttRepStateSet('ACTIVE')組込みプロシージャをコールしてスタンバイをアクティブに昇格します。このデータベースがアクティブ・スタンバイ・ペアのアクティブ・データベースになります。ttRepStateGet組込みプロシージャを使用して、データベースがアクティブになったことを確認します。

   Command> call ttRepStateSet('ACTIVE');
   Command> call ttRepStateGet;
   < ACTIVE >
   1 row found.
   

6. アクティブ・データベースだったデータベースでレプリケーション・エージェントを停止します。

   % ttAdmin -repStop ttdb1
   

7. 新しいアクティブ・データベースでttRepStateSaveを実行し、以前のアクティブ・データベースの状態を失敗に設定します。スタンバイ・データベースが使用できない間は、アクティブ・データベースへの更新は、サブスクライバ・データベースに直接レプリケートされます。

   Command> call ttRepStateSave('FAILED', 'ttdb1', 'ttsrv1');
   

8. 新しいアクティブ・データベース(ttdb2)でアプリケーションのフル・ワークロードを再起動します。

このデータベースがアクティブ・スタンバイ・ペアのスタンバイ・データベースとして機能するようになります。

スタンバイの廃棄および新しいスタンバイの再作成

新しいアクティブからttRepAdmin -duplicateを使用して、スタンバイを廃棄し、新しいスタンバイを再作成します。これらのステップの間、アクティブ・データベースではアプリケーション処理は続行できます。

1. 新しいスタンバイ・データベースでキャッシュ・エージェントを停止します。

   % ttAdmin –cacheStop ttdb1
   

2. キャッシュ・マネージャ・ユーザーとして、すべてのキャッシュ・グループを削除します。

   Command> DROP CACHE GROUP t_cg;
   

3. データベースを破棄します。

   % ttDestroy ttdb1
   

4. 新しいアクティブを複製して新しいスタンバイ・データベースを再作成します。

   % ttRepAdmin -duplicate -from ttdb2 -host ttsrv2 –setMasterRepStart -UID 
   ttadmin -PWD ttadminpwd -keepCG -cacheUID cacheadmin -cachePWD cadminpwd ttdb1
   

5. 新しいスタンバイ・データベースでキャッシュ・エージェントおよびレプリケーション・エージェントを起動します。

   % ttAdmin –cacheStart ttdb1
   % ttAdmin –repStart ttdb1
   

このプロセスにより、ごく数秒の間サービスが中断するのみで、アクティブ・データベースとスタンバイ・データベースの両方がデフラグされます。

アクティブ・スタンバイ・ペアではないレプリケーション・スキーム内のTimesTen Classicデータベースのオンライン・デフラグメンテーション

次の項では、アクティブ・スタンバイ・ペアではないレプリケーション・スキームに関係しているTimesTen Classicデータベースをデフラグする方法について説明します。

• スタンバイ・データベースの移行および再構築

• レプリケーション・スキームの変更

• データベースの破棄および再作成

ノート: 次の項では、双方向レプリケーション・スキームに関係しているデータベースをデフラグする方法について説明します。双方向レプリケーション・スキームでは、各データベースはマスターおよびサブスクライバの両方になります。

この項の例では、2つのTimesTenデータベース(それぞれttdb1およびttdb2という名前)で双方向および一方向レプリケーションによるオンライン・デフラグメンテーションを実行する方法を示します。一方向レプリケーションの例では、ttdb1はマスターを表し、ttdb2はサブスクライバを表します。

データベースの移行および再構築

この手順の第1ステップは、TimesTen Classicデータベースの1つでレプリケーションを停止し、このデータベースをデフラグすることです。

ノート: データベースの1つをデフラグしている間、他のデータベースではアプリケーション処理を続行できます。

データベースのコピーを保存するには、次の手順を実行します。

1. データベースの1つでレプリケーション・エージェントを停止します。

   ttdb2データベースの場合:

   % ttAdmin –repStop ttdb2
   

2. ttMigrateを使用してttdb1データベースのコピーを保存します。

   % ttMigrate -c ttdb2 ttdb2.dat
   

3. データベースを破棄します。

   % ttDestroy ttdb2
   

4. ADMIN権限のあるTimesTenユーザーとして、ttdb2データベースを再構築します。

   % ttMigrate -r -relaxedUpgrade -connstr "dsn=ttdb2;uid=ttadmin;pwd=ttadminpwd" ttdb2.dat
   

   このとき

   • すべてのユーザーがttdb2に格納されました。

   • レプリケーション・エージェントは稼働していません。

5. ttdb2でレプリケーション・エージェントを再起動します。

   % ttAdmin -repStart ttdb2
   

ttdb2 TimesTenデータベースがデフラグされました。

レプリケーション・スキームの変更

ttdb1データベースにデータベース・デフラグメンテーションを実行するには、次の操作を実行します。

1. すべてのアプリケーション処理を停止し、ttAdmin -disconnectコマンドを使用してすべてのアプリケーション接続を切断します。すべての処理をttdb2 TimesTenデータベースで稼働するように移動できます。詳細は、このマニュアル内のデータベースからの切断、およびOracle TimesTen In-Memory DatabaseリファレンスのttAdminを参照してください。

2. デフラグしたデータベース(ttdb2)のデータベース名およびホストを入力パラメータとして、デフラグされていないデータベース(ttdb1)でttRepSubscriberWait組込みプロシージャをコールします。これにより、キューに入れられたすべての更新が両方のデータベースに送信されます。

   
   

   ノート: waitTimeを-1に設定した場合、コールは、コール前にコミットされたすべてのトランザクションがサブスクライバに送信されるまで待機します。 ただし、waitTimeを任意の値(NULL以外の値)に設定する場合、操作を実行する前に、timeOut戻りパラメータの値が0x00であることを確認してください。戻り値が0x01の場合、コール前にコミットされたすべてのトランザクションがサブスクライバに送信されるまでttRepSubscriberWait組込みプロシージャをコールします。 ttRepSubscriberWait組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttRepSubscriberWaitに関する説明を参照してください。

   
   

   ttdb1の場合:

   % ttIsql ttdb1
   
   Command> call ttRepSubscriberWait(NULL,NULL,'ttdb2','ttsrv2', 100);
   

   双方向レプリケーション・スキームを使用する場合、ステップ3およびステップ4をスキップしてステップ5に進んでください。

3. 一方向レプリケーション・スキームの場合(ttdb1がマスターでttdb2がサブスクライバ)、両方のTimesTenデータベースでレプリケーション・スキームを破棄します。

   ttdb1の場合:

   % ttIsql ttdb1
   
   Command> DROP REPLICATION r1;
   

   ttdb2の場合:

   % ttIsql ttdb2
   
   Command> DROP REPLICATION r1;
   

4. 一方向レプリケーション・スキームの場合、マスター(ttdb1)およびサブスクライバ(ttdb2)でレプリケーション・スキームを破棄します。

   ttdb1の場合:

   % ttIsql ttdb1
   
   Command> DROP REPLICATION r1;
   

   ttdb2の場合:

   % ttIsql ttdb2
   
   Command> DROP REPLICATION r1;
   

5. ttdb2でレプリケーション・エージェントを起動します。

   % ttAdmin -repStart ttdb2
   

6. ttdb1でレプリケーション・エージェントを停止します。

   % ttAdmin -repStop ttdb1
   

一方向レプリケーション・スキームを変更する場合、ttdb2データベースは一方向スキームでマスター・データベースとして稼働しており、ttdb1データベースは一方向レプリケーション・スキームでサブスクライバ・データベースとして稼働しています。

データベースの破棄および再作成

ttRepAdmin -duplicateを使用して、デフラグされていないレプリケーション・スキーム内のTimesTenデータベースを破棄して再作成します。これらのステップの間、デフラグしたデータベースではアプリケーション処理を続行できます。

1. データベースを破棄します。

   % ttDestroy ttdb1
   

2. レプリケーション・スキームに関係したデフラグ済のTimesTen Classicデータベース(ttdb2)を複製して、新しいTimesTen Classicデータベース(ttdb1)を再作成します。

   % ttRepAdmin -duplicate -from ttdb2 -host ttsrv2 –setMasterRepStart -UID ttadmin -PWD ttadminpwd ttdb1
   

3. 新しいスタンバイ・データベースでレプリケーション・エージェントを起動します。

   % ttAdmin –repStart ttdb1
   

この処理は、一方向レプリケーション・スキームまたは双方向レプリケーション・スキームのいずれに属するTimesTen Classicデータベースも、数秒のサービス停止時間のみでデフラグします。

データベースが単一インスタンスか分散データベースかの確認

接続しているのが単一インスタンス(TimesTen Classic)データベースか、分散(TimesTen Scaleout)データベースかを確認する場合は、ttConfiguration組込みプロシージャを使用してttGridEnableパラメータの値をコールします。組込みプロシージャは、分散データベースの場合はttGridEnable=1を戻し、単一インスタンス・データベースの場合はttGridEnable=0を戻します。

Command> CALL ttConfiguration('ttGridEnable');
< TTGridEnable, 1 >
1 row found.
Command>

ttConfiguration組込みプロシージャの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttConfigurationに関する項を参照してください。