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 トレース・ファイルとアラート・ログでの問題のチェック

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

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

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

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

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

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

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

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

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

関連項目:

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

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

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

関連項目:

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

7.1.2.2 LogMinerのトレース・ファイル

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

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

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

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

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

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

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

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

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

7.2 XStream Outの問題と解決策

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

一般的には、Oracle適用プロセスをトラブルシューティングするのと同じ方法で、XStreamアウトバウンド・サーバーをトラブルシューティングできます。また、XStream Out環境には、取得プロセスとキューが含まれており、伝播、ルール、ルールベースの変換などの他のコンポーネントが含まれる場合もあります。

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

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

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

問題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を修正するには:

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

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がブロックされた原因に応じた適切な処置を行います。たとえば、伝播が無効になっている場合、有効にします。

関連項目:

message_tracking_frequency取得プロセス・パラメータの詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照

7.2.3 取得プロセスで必要なREDOログ・ファイルがない

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

取得プロセスの必須チェックポイントSCNを判別するには、ALL_CAPTUREデータ・ディクショナリ・ビューを問い合せます。また、V$XSTREAM_CAPTUREを問い合せ、STATE列を確認するのも役立ちます。取得プロセスの状態は、取得プロセスが現在行っている処理を示します。この場合、取得プロセスで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かほぼ1である場合は、取得プロセスの最大SGAサイズを大きくする必要が生じることがあります。

解決策2

問題2を修正するには:

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

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

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

解決策3

問題3を修正するには:

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

7.3 XStream Outに関する追加ヘルプを取得する方法

Oracleサポートでは、XStream Outに関する追加ヘルプを提供できます。

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

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