7 XStream Outのトラブルシューティング

XStream Out構成に関する問題を診断および修正できます。

7.1 XStream Outでの問題の診断

いくつかの異なる手法を使用してXStream Outでの問題を診断できます。

7.1.1 アラートの表示

アラートとは、潜在的に問題があったり、クリティカルのしきい値を超えた場合に発せられる警告のことです。

アラートには2つのタイプがあります。

  • ステートレス: 必ずしもシステムの状態と結び付かない単一イベントを示すアラート。たとえば、取得が特定のエラーで中断したことを示すアラートはステートレス・アラートです。

  • ステートフル: 特定のシステム状態に関連するアラート。ステートフル・アラートは、通常は数値に基づき、警告レベルとクリティカル・レベルでしきい値が定義されます。たとえば、警告レベルが85%でクリティカル・レベルが95%の現在のStreamsプール・メモリー使用率に関するアラートは、ステートフル・アラートです。

Oracleデータベースでは、次の条件でステートレス・アラートが生成されます。

  • 取得プロセスが中断された場合

  • アウトバウンド・サーバーが中断された場合。

Streamsプールのメモリー使用量が、STREAMS_POOL_USED_PCTメトリックに指定されたパーセンテージを超えた場合、Oracle Databaseは、ステートフルXStreamアラートを生成します。このメトリックは、DBMS_SERVER_ALERTパッケージのSET_THRESHOLDプロシージャを使用して管理できます。

Oracle Enterprise Manager Cloud Controlでアラートを表示するか、次のデータ・ディクショナリ・ビューを問い合せることができます。

  • DBA_OUTSTANDING_ALERTSビューでは、現行のステートフル・アラートが記録されます。DBA_ALERT_HISTORYビューでは、クリアされたステートレス・アラートおよびステートフル・アラートが記録されます。たとえば、Streamsプールでのメモリー使用量が指定されたしきい値を超えると、DBA_OUTSTANDING_ALERTSビューにステートフル・アラートが記録されます。

  • DBA_ALERT_HISTORYデータ・ディクショナリ・ビューには、DBA_OUTSTANDING_ALERTSビューからクリアされたアラートが表示されます。たとえば、Streamsプールでのメモリー使用量が指定されたしきい値を下回ると、DBA_OUTSTANDING_ALERTSビューに記録されていたアラートがクリアされ、DBA_ALERT_HISTORYビューに移動します。

たとえば、現行のステートフル・アラートをリストするには、DBA_OUTSTANDING_ALERTSビューで次の問合せを実行します。

COLUMN REASON HEADING 'Reason for Alert' FORMAT A35
COLUMN SUGGESTED_ACTION HEADING 'Suggested Response' FORMAT A35
 
SELECT REASON, SUGGESTED_ACTION 
   FROM DBA_OUTSTANDING_ALERTS
   WHERE MODULE_ID LIKE '%XSTREAM%';

ステートレス・アラートと、クリアされたXStreamステートフル・アラートをリストするには、DBA_ALERT_HISTORYビューで次の問合せを実行します。

COLUMN REASON HEADING 'Reason for Alert' FORMAT A35
COLUMN SUGGESTED_ACTION HEADING 'Suggested Response' FORMAT A35
 
SELECT REASON, SUGGESTED_ACTION 
   FROM DBA_ALERT_HISTORY 
   WHERE MODULE_ID LIKE '%XSTREAM%';

ほとんどのアラートは、問題の原因が消失するか、またはデータベース管理者によって確認されると自動的にクリアされます。

関連項目:

7.1.2 Streams構成レポートおよびヘルス・チェック・スクリプトの使用

Streams構成レポートおよびヘルス・チェック・スクリプトは、Oracle Streams用に設計されたものですが、XStream Out構成のXStreamコンポーネントに関する重要な情報が提供されます。このレポートは、XStreamの前提条件を満たしているかどうかの確認、XStreamの対象データベース・オブジェクトの識別に役立ちます。

また、このレポートでは、データベースのルールを分析して、XStreamルールに関する一般的な問題を特定することもできます。

Streams構成レポートおよびヘルス・チェック・スクリプトは、My Oracle Support(旧Oracle MetaLink)のWebサイトで使用可能です。スクリプトを実行するには、次の手順を実行します。

  1. Webブラウザを使用して、My Oracle Support Webサイトに移動します。
  2. My Oracle Supportにログインします。

    注意:

    My Oracle Supportの登録済ユーザーでない場合は、「こちらで登録してください」をクリックして登録します。

  3. 次のタイトルのデータベース掲示板を検索します。
    Streams Configuration Report and Health Check Script
    

    この掲示板のドキュメントIDは273674.1です。

  4. 手順に従ってご使用のリリースに対するスクリプトダウンロードし、スクリプトを実行して結果を分析します。

7.1.3 トレース・ファイルとアラート・ログでの問題のチェック

各取得プロセスおよびアウトバウンド・サーバーに関するメッセージは、プロセスが実行されているデータベースのトレース・ファイルに記録されます。

ローカル取得プロセスはソース・データベースで実行され、ダウンストリーム取得プロセスはダウンストリーム・データベースで実行されます。これらのトレース・ファイルのメッセージはXStream Out構成の問題を特定し、解決するのに役立ちます。

バックグラウンド・プロセスのすべてのトレース・ファイルは、自動診断リポジトリに書き込まれます。トレース・ファイル名はオペレーティング・システム固有ですが、通常、各ファイルにはそれを書き込むプロセスの名前が含まれます。

たとえば、一部のオペレーティング・システムでは、プロセスのトレース・ファイル名はsid_xxxx_iiiii.trcとなります。その意味は次のとおりです。

  • sidはデータベースのシステム識別子です

  • xxxxはプロセスの名前です

  • iiiiiはオペレーティング・システムのプロセス番号です

また、取得プロセスおよびアウトバウンド・サーバーの両方のwrite_alert_logパラメータをyに設定できます。このパラメータをyに設定(デフォルト)すると、取得プロセスまたはアウトバウンド・サーバーが停止した理由を示すメッセージがデータベースのアラート・ログに書き込まれます。

DBMS_XSTREAM_ADMパッケージのSET_PARAMETERプロシージャを使用して、取得プロセスまたはアウトバウンド・サーバーのtrace_level適用パラメータを設定すると、トレース・ファイル内の情報を制御できます。

関連項目:

7.1.3.1 取得プロセスのトレース・ファイル

取得プロセスは、CPnnという名前のOracleバックグラウンド・プロセスです。nnには文字および番号が含まれます。

たとえば、一部のオペレーティング・システムでは、取得プロセスが実行されているデータベースのシステム識別子がhqdbで、取得プロセス番号が01であれば、その取得プロセスのトレース・ファイル名はhqdb_CP01で始まります。

関連項目:

取得プロセスの取得プロセス番号を表示する問合せについては、各取得プロセスに関する変更取得情報の表示を参照

7.1.3.2 LogMinerトレース・ファイル

LogMinerトレース・ファイルはXStream Outの問題の理解に役立ちます。

LogMinerトレース・ファイルは並列度取得プロセス・パラメータが0より大きい値に設定されている場合に作成されます。少なくとも3つのLogMinerトレース・ファイルが生成されて自動診断リポジトリに書き込まれます。

7.1.3.3 アウトバウンド・サーバーのトレース・ファイル

アウトバウンド・サーバーは、APnnという名前のOracleバックグラウンド・プロセスで、nnには文字および数字が含まれます。

たとえば、一部のオペレーティング・システムでは、アウトバウンド・サーバーが実行されているデータベースのシステム識別子がhqdbで、アウトバウンド・サーバー番号が01であれば、そのアウトバウンド・サーバーのトレース・ファイル名はhqdb_ap01_xxxx.trcで始まります。

アウトバウンド・サーバーは、他のプロセスも使用します。アウトバウンド・サーバーに関する情報は、これらのプロセスの1つ以上のトレース・ファイルに記録される場合があります。リーダー・サーバーと適用サーバーのプロセス名はASnnであり、nnには文字および番号が含まれます。したがって、一部のオペレーティング・システムでは、アウトバウンド・サーバーが実行されているデータベースのシステム識別子がhqdbであり、プロセス番号が01であれば、アウトバウンド・サーバーで使用されるプロセスに関する情報を含むトレース・ファイルの名前はhqdb_AS01で始まります。

7.1.3.4 クライアント・アプリケーションのトレース・ファイル

クライアント・アプリケーションのトレース・ファイルはXStream Outの問題を分離するのに役立ちます。

エラーをトラブルシューティングする、問題を主要なコンポーネントに分離する、または潜在的なパフォーマンスの問題を特定する場合は、XStream環境のすべての主要なソースからのトレース・ファイルを確認することをお薦めします。確認する1つの主要なソースは、クライアント・アプリケーションのトレース・ファイルです。クライアントのトレース・ファイルは、$ORACLE_HOME/diag/clients/ディレクトリに配置されます。

7.2 XStream Outでの問題と解決策

XStream Outに関する一般的な問題の解決策を実装できます。

一般的には、Oracle Streams適用プロセスをトラブルシューティングするのと同じ方法で、XStreamアウトバウンド・サーバーをトラブルシューティングできます。また、XStream Out環境には、取得プロセス、キューが含まれており、他のコンポーネントである、伝播、ルール、およびルールベースの変換などが含まれる場合があります。これらのコンポーネントをトラブルシューティングするには、Oracle Streams概要および管理のトラブルシューティングの説明を参照してください。

7.2.1 OCIクライアント・アプリケーションがアウトバウンド・サーバーに接続できない

XStreamクライアント・アプリケーションは、Oracle Call Interface (OCI) OCIXStreamOutAttach()関数を使用して、アウトバウンド・サーバーに接続できません。

次の項では、考えられる問題とそれらの解決策について説明します。

問題1: 接続ユーザーとしてクライアント・アプリケーションが接続されていない

クライアント・アプリケーションがアウトバウンド・サーバーの接続ユーザーとしてアウトバウンド・サーバーのデータベースに接続されていません。クライアント・アプリケーションが別のユーザーとしてデータベースに接続されています。

接続ユーザーがアクセスできるXStream Outサーバーに関する情報を出力する手順:

  1. アウトバウンド・サーバー・データベースにXStream管理者として接続します。

    SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。

  2. 接続ユーザーを判別するには、次の問合せを実行します。

    SELECT SERVER_NAME, 
           CONNECT_USER, 
           CAPTURE_NAME, 
           SOURCE_DATABASE,
           CAPTURE_USER,
           QUEUE_OWNER
      FROM ALL_XSTREAM_OUTBOUND;
    

    この問合せは、アウトバウンド・サーバーに接続し、アウトバウンドLCRを処理できるユーザーの名前(connect_user)を表示します。

解決策1

問題1を修正する手順:

  • アウトバウンド・サーバーへの接続の前に、接続ユーザーとしてデータベースに接続するようにクライアント・アプリケーションを変更します。

問題2: クライアント・アプリケーションがサービス・ハンドルを渡さない

クライアント・アプリケーションがアウトバウンド・サーバーにサービス・ハンドルを渡していません。

解決策2

問題2を修正する手順:

  • OCISvcCtxを使用して(OCIServerではありません)サービス・ハンドルを渡すようにクライアント・アプリケーションを変更します。

7.2.2 XStream Outで変更がクライアント・アプリケーションに到達しない

XStream Out構成で、取得され、XStreamクライアント・アプリケーションにストリームされるはずのデータベースの変更が、クライアント・アプリケーションに到達しません。

次の項では、考えられる問題とそれらの解決策について説明します。

問題1: 取得プロセスが遅れる

取得プロセスが遅れています。

取得プロセスが遅れているかどうかを判断する手順:

  1. アウトバウンド・サーバー・データベースにXStream管理者として接続します。

    SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。

  2. 次の問合せを実行します。

    COLUMN CAPTURE_NAME HEADING 'Capture|Name' FORMAT A15
    COLUMN STATE HEADING 'State' FORMAT A15
    COLUMN CREATE_MESSAGE HEADING 'Last LCR|Create Time'
    COLUMN ENQUEUE_MESSAGE HEADING 'Last|Enqueue Time'
    
    SELECT CAPTURE_NAME, STATE,
           TO_CHAR(CAPTURE_MESSAGE_CREATE_TIME, 'HH24:MI:SS MM/DD/YY') CREATE_MESSAGE,
           TO_CHAR(ENQUEUE_MESSAGE_CREATE_TIME, 'HH24:MI:SS MM/DD/YY') ENQUEUE_MESSAGE
      FROM V$XSTREAM_CAPTURE;
    

    この問合せは、取得プロセスの現在の状態を示します。この問合せでは、取得プロセスが最後の論理変更レコード(LCR)を作成した時刻と、取得プロセスが最後にLCRをエンキューした時刻も表示されます。戻された時刻が、データベースの変更が行われた時刻より前である場合、取得プロセスは遅れを取り戻して変更を取得する必要があります。

解決策1

必要なアクションはありません。通常、取得プロセスは介入を必要とせずに、自力で遅れを取り戻します。

問題2: ルールまたはルールベースの変換が変更を除外している

ルールまたはルールベースの変換が、取得する必要のある変更を除外しています。

取得プロセスにより取得され、伝播によりソース・キューから宛先キューに送信され、アウトバウンド・サーバーによってXStreamクライアント・アプリケーションに送信されるLCRは、ルールによって決まります。ルールが適切に構成されていない場合、クライアント・アプリケーションは、受信する予定のLCRを受信しない可能性があります。クライアント・アプリケーションは、受信する予定でないLCRを受信する可能性もあります。

ルールベースの変換ではLCRのコンテンツを変更します。このため、想定された変更データがクライアント・アプリケーションに到達していない場合、ルールベースの変換で、データが変更されたりデータが削除されたことが原因である可能性があります。たとえば、DELETE_COLUMN宣言ルールベースの変換は、LCRから列を削除します。

解決策2

問題2を修正する手順:

  • 取得プロセスからクライアント・アプリケーションへのストリームで、各コンポーネントに対して構成されているルールおよびルール・ベースの変換を確認して、問題を修正してください。

問題3: LCRがストリームでブロックされている

取得プロセスが遅れておらず、ルールおよびルールベースの変換で問題が発生していない場合、LCRは他のなんらかの理由でストリームでブロックされている可能性があります。たとえば、伝播またはアウトバウンド・サーバーが無効化されている、データベース・リンクが壊れている、または別の問題がある可能性があります。

ストリームでLCRを追跡するには、次のいずれかの方法を使用します。

  • message_tracking_frequency取得プロセス・パラメータを1または他の比較的低い値に設定する

    この方法を使用してLCRの追跡を無効にするには、message_tracking_frequency取得プロセス・パラメータをNULLに設定するか、セッションを終了してください。

  • DBMS_XSTREAM_ADMパッケージのSET_MESSAGE_TRACKINGプロシージャを実行する

    この方法を使用してLCRの追跡を無効にするには、SET_MESSAGE_TRACKINGプロシージャのtracking_labelパラメータをNULLに設定するか、セッションを終了してください。

これらの方法のいずれかを使用した後は、V$XSTREAM_MESSAGE_TRACKINGビューを使用して、ストリームでLCRの進捗を監視します。ストリームでLCRを追跡することによって、LCRがブロックされている場所を判断できます。

また、伝播を使用して構成のLCRを送信する場合は、次の問合せを実行して、伝播送信者の現在の状態を確認できます。

SELECT STATE FROM V$PROPAGATION_SENDER;

次の問合せを実行して、アウトバウンド・サーバーの現在の状態を確認できます。

SELECT SERVER_NAME, STATE FROM V$XSTREAM_OUTBOUND_SERVER;

次の問合せを実行して、クライアント・アプリケーションがアウトバウンド・サーバーに接続されていることを確認できます。

COLUMN SERVER_NAME HEADING 'Capture|Name' FORMAT A30
COLUMN STATUS HEADING 'Status' FORMAT A8

SELECT SERVER_NAME, STATUS FROM ALL_XSTREAM_OUTBOUND;

クライアント・アプリケーションがアウトバウンド・サーバーに接続されている場合、STATUS列にATTACHEDが表示されます。

解決策3

問題3を修正する手順:

  • LCRがブロックされた原因に応じた適切な処置を行います。たとえば、伝播が無効になっている場合、有効にしてください。

関連項目:

7.2.3 取得プロセスで必須のREDOログ・ファイルが存在しない

取得プロセスの起動時または停止および再起動時には、必須チェックポイントSCNに対応するSCNを含むログ・ファイルよりも前に生成されたREDOログ・ファイルをスキャンする必要がある場合があり、これらのファイルが削除された可能性があります。

取得プロセスの必須チェックポイントSCNを確認するには、ALL_CAPTUREデータ・ディクショナリ・ビューを問い合せます。また、V$XSTREAM_CAPTUREを問い合せ、STATE列を確認することも役立ちます。取得プロセスの状態は、取得プロセスが現在行っている処理を示します。この場合、取得プロセスでREDOログ・ファイルが欠落している、またはREDOログ・ファイルを待機している理由に関して、詳しく理解できます。

COLUMN CAPTURE_NAME HEADING 'Capture Name' FORMAT A30
COLUMN STATE HEADING 'State' FORMAT A30

SELECT CAPTURE_NAME, STATE FROM V$XSTREAM_CAPTURE;

CAPTURE_NAME            STATE
------------------      -----------------
XOUT_SRC_CAPTURE        WAITING FOR REDO

V$XSTREAM_CAPTUREビューを問い合せると、状態の情報とともに追加情報が表示されることがあります。追加情報は、取得プロセスがREDOを待機している理由を判別するのに役立ちます。たとえば、ビューを問い合せると、次のような文がSTATE列に対して表示される場合があります。

WAITING FOR REDO: LAST SCN MINED 6700345

この場合、取得プロセスによってスキャンされた最後のシステム変更番号(SCN)が出力に表示されます。場合によっては、REDOログ・ファイル名が明示的に出力に表示されることもあります。いずれにしても、追加情報は取得プロセスが待機しているREDOログを識別するのに役立ちます。問題を修正するには、欠落している任意のREDOログ・ファイルを取得プロセスに対して使用可能にします。

問題: 必要なREDOログ・ファイルが削除された

必要なREDOログ・ファイルを取得プロセスでスキャンする前に削除すると、取得プロセスが異常終了し、取得プロセスのトレース・ファイルで次のエラーが発生します。

ORA-01291: missing logfile

解決策: 欠落しているREDOログ・ファイルのリストアおよび将来の問題の防止

このエラーが表示された場合は、欠落しているREDOファイルをリストアした後、取得プロセスを再起動してみてください。V$LOGMNR_LOGS動的パフォーマンス・ビューをチェックして欠落しているSCNの範囲を特定し、該当するREDOログ・ファイルを追加できます。取得プロセスには、必須チェックポイントSCNを含むREDOログ・ファイルと、後続のすべてのREDOログ・ファイルが必要です。ALL_CAPTUREデータ・ディクショナリ・ビューのREQUIRED_CHECKPOINT_SCN列を問い合せると、取得プロセスの必須チェックポイントSCNを判別できます。

取得プロセスがCONTROL_FILE_RECORD_KEEP_TIME初期化パラメータで指定された時間よりも長い間無効である場合、欠落しているREDOログ・ファイルの情報が制御ファイルで置き換えられる可能性があります。V$ARCHIVE_LOGビューを問い合せて、ログ・ファイル名がリストされているかどうかを確認できます。リストされていない場合、ALTER DATABASE REGISTER OR REPLACE LOGFILE SQL文を使用して登録できます。

XStream環境内のソース・データベースでRecovery Manager (RMAN)の高速リカバリ領域機能を使用している場合、取得プロセスに必要なアーカイブREDOログ・ファイルがRMANによって削除されることがあります。リカバリ関連ファイルで使用されているディスク領域が、高速リカバリ領域で指定されたディスク割当て制限に近づくと、RMANによってこれらのファイルが削除される場合があります。将来この問題が発生するのを防止するには、次のアクションを1つ以上実行します。

  • 高速リカバリ領域のディスク割当て制限を引き上げます。ディスク割当て制限を引き上げると、必要なアーカイブREDOログ・ファイルがRMANによって削除される可能性が低減しますが、必ずしも問題を回避できるわけではありません。

  • アーカイブREDOログ・ファイルが高速リカバリ領域以外の場所に格納されるようにソース・データベースを構成します。ローカル取得プロセスでは、必要なログ・ファイルが高速リカバリ領域に見つからない場合に、別の場所にあるログ・ファイルを使用できます。この場合、別の場所にあるログ・ファイルをデータベース管理者が手動で管理する必要があります。

RMANでは、アーカイブREDOログ・ファイルを削除する前に、それらがバックアップされていることを常に確認します。取得プロセスに必要なアーカイブREDOログ・ファイルがRMANによって削除されると、このアクションがRMANによってアラート・ログに記録されます。

7.2.4 アウトバウンド・サーバーからのLCRストリーミングで追加属性が欠落している

アウトバウンド・サーバーからストリームされるLCRには追加の属性が含まれることが想定されますが、これらの属性がLCRに含まれていません。

LCRには、データベースの変更に関連する次の追加の属性を含めることができます。

  • row_id

  • serial#

  • session#

  • thread#

  • tx_name

  • username

デフォルトでは、取得プロセスは、これらの追加の属性を取得しません。アウトバウンド・サーバーからXStreamクライアント・アプリケーションにストリームされたLCRに追加の属性を含める必要があるが、LCRで追加の属性に値が格納されていない合、アウトバウンド・サーバーの変更を取得する取得プロセスが、追加の属性の値を取得するように構成されていることを確認してください。

次の項では、考えられる問題とその解決策について説明します。

問題: 取得プロセスが追加の属性を取得するように構成されていない

取得プロセスが必要な追加の属性を取得するように構成されていません。

データベースの取得プロセスによって現在取得されている追加の属性を表示する手順:

  1. 取得プロセスが実行されているデータベースにXStream管理者として接続します。

    SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。

  2. 次の問合せを実行します。

    COLUMN CAPTURE_NAME HEADING 'Capture Process' FORMAT A30
    COLUMN ATTRIBUTE_NAME HEADING 'Attribute Name' FORMAT A30
     
    SELECT CAPTURE_NAME, ATTRIBUTE_NAME
      FROM ALL_CAPTURE_EXTRA_ATTRIBUTES
      WHERE INCLUDE = 'YES'
      ORDER BY CAPTURE_NAME;
    

    この問合せで追加属性が表示されない場合は、取得されていません。

解決策

この問題を解決するには、必要な追加の属性を取得するように取得プロセスを構成します。

  1. アウトバウンド・サーバー・データベースにXStream管理者として接続します。

    SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。

  2. DBMS_CAPTURE_ADMパッケージのINCLUDE_EXTRA_ATTRIBUTEプロシージャを実行します。

例7-1 取得プロセスxcaptureにtx_name属性を含める

BEGIN
  DBMS_CAPTURE_ADM.INCLUDE_EXTRA_ATTRIBUTE(
    capture_name   => 'xcapture',
    attribute_name => 'tx_name',
    include        => TRUE);
END;
/

7.2.5 XStream Outクライアント・アプリケーションが応答しない

XStream Out構成のXStreamクライアント・アプリケーションが応答しません。

次の項では、考えられる問題とその解決策について説明します。

問題1: Streamsプールのサイズが小さすぎる

Streamsプールのサイズが小さすぎる可能性があります。

Streamsプールのサイズが小さすぎるかどうかを確認する手順:

  1. アウトバウンド・サーバー・データベースにXStream管理者として接続します。

    SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。

  2. アウトバウンド・サーバーを含むデータベースで次の問合せを実行します。

    • V$PROPAGATION_RECEIVERビューを問い合せます。

      SELECT STATE FROM V$PROPAGATION_RECEIVER;
      

      状態がWAITING FOR MEMORYである場合、Streamsプールのサイズを大きくすることを検討してください。

    • V$STREAMS_POOL_STATISTICSビューを問い合せます。

      SELECT TOTAL_MEMORY_ALLOCATED/CURRENT_SIZE FROM V$STREAMS_POOL_STATISTICS;
      

      戻り値が90以上である場合、Streamsプールのサイズを大きくすることを検討してください。

解決策1

問題1を修正する手順:

  • STREAMS_POOL_SIZE初期化パラメータを変更するか、メモリーに関連する他の初期化パラメータを変更して、Streamsプールのサイズを増やします。

関連項目:

問題2: 取得プロセスの最大SGAサイズが小さすぎる

max_sga_size取得プロセス・パラメータは、取得プロセスに具体的に割り当てられたシステム・グローバル領域(SGA)メモリーの量をMB単位で制御します。

取得プロセスの最大SGAサイズが小さすぎるかどうかを確認する手順:

  1. XStreamコンポーネントが実行されているデータベースにXStream管理者として接続します。

    SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。

  2. データベースで次の問合せを実行します。

    • V$XSTREAM_CAPTUREビューを問い合せます。

      SELECT CAPTURE_NAME AS CAP,
              SGA_USED/(1024*1024) AS USED, 
              SGA_ALLOCATED/(1024*1024) AS ALLOCATED, 
              TOTAL_MESSAGES_CAPTURED AS CAPTURED, 
              TOTAL_MESSAGES_ENQUEUED AS ENQUEUED 
        FROM V$XSTREAM_CAPTURE;
      

      出力のUSEDフィールドがALLOCATEDフィールドとほぼ同じ場合は、取得プロセスの最大SGAサイズを拡大する必要が生じる場合があります。

    • V$LOGMNR_SESSIONビューを問い合せます。

      SELECT SESSION_NAME AS CAP, 
              MAX_MEMORY_SIZE/(1024*1024) AS LMMAX, 
              USED_MEMORY_SIZE/(1024*1024) AS LMUSED, 
              USED_MEMORY_SIZE/MAX_MEMORY_SIZE AS PCT 
        FROM V$LOGMNR_SESSION;
      

      出力のPCTフィールドが1とほぼ同じ場合は、取得プロセスの最大SGAサイズを拡大する必要が生じる場合があります。

解決策2

問題2を修正する手順:

  • max_sga_size取得プロセス・パラメータを変更することによって、取得プロセスの最大SGAサイズを増やします。

問題3: プログラム・エラー

Streamsプールのメモリーが十分にあり、MAX_SGA_SIZE取得プロセス・パラメータおよび適用パラメータが正しく設定されている場合は、クライアント・アプリケーションのプログラミング・エラーについて確認してください。

解決策3

問題3を修正する手順:

  • プログラミング・エラーを修正します。

7.3 XStream Outの詳細なヘルプを求める方法

Oracle SupportではXStream Outの詳細なヘルプ情報を提供できます。

問題に対するその他の解決策は、http://support.oracle.comのMy Oracle Supportで確認できます。

Oracleサポートの詳細は、http://www.oracle.com/support/contact.htmlを参照してください。