12 Troubleshooting XStream In

This chapter describes common problems you might encounter while using XStream and explains how to solve them.

This chapter contains the following topics:

Diagnosing Problems with XStream In

To diagnose problems with XStream In, use the techniques described in this section.

This section contains these topics:

Viewing Alerts

An alert is a warning about a potential problem or an indication that a critical threshold has been crossed. There are two types of alerts:

  • Stateless: Alerts that indicate single events that are not necessarily tied to the system state. For example, an alert that indicates that a capture aborted with a specific error is a stateless alert.

  • Stateful: Alerts that are associated with a specific system state. Stateful alerts are usually based on a numeric value, with thresholds defined at warning and critical levels. For example, an alert on the current Streams pool memory usage percentage, with the warning level at 85% and the critical level at 95%, is a stateful alert.

An Oracle database generates a stateless alert when an inbound server aborts.

An Oracle database generates a stateful XStream alert when the Streams pool memory usage exceeds the percentage specified by the STREAMS_POOL_USED_PCT metric. You can manage this metric with the SET_THRESHOLD procedure in the DBMS_SERVER_ALERT package.

You can view alerts in Oracle Enterprise Manager Cloud Control, or you can query the following data dictionary views:

  • The DBA_OUTSTANDING_ALERTS view records current stateful alerts. The DBA_ALERT_HISTORY view records stateless alerts and stateful alerts that have been cleared. For example, if the memory usage in the Streams pool exceeds the specified threshold, then a stateful alert is recorded in the DBA_OUTSTANDING_ALERTS view.

  • The DBA_ALERT_HISTORY data dictionary view shows alerts that have been cleared from the DBA_OUTSTANDING_ALERTS view. For example, if the memory usage in the Streams pool falls below the specified threshold, then the alert recorded in the DBA_OUTSTANDING_ALERTS view is cleared and moved to the DBA_ALERT_HISTORY view.

For example, to list the current stateful alerts, run the following query on the DBA_OUTSTANDING_ALERTS view:

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%';

To list the stateless alerts and cleared XStream stateful alerts, run the following query on the DBA_ALERT_HISTORY view:

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%';

See Also:

Checking the Trace File and Alert Log for Problems

Messages about inbound server are recorded in trace files for the database in which the process is running. These trace file messages can help you to identify and resolve problems in an XStream In configuration.

All trace files for background processes are written to the Automatic Diagnostic Repository. The names of trace files are operating system specific, but each file usually includes the name of the process writing the file.

For example, on some operating systems, the trace file name for a process is sid_xxxx_iiiii.trc, where:

  • sid is the system identifier for the database

  • xxxx is the name of the process

  • iiiii is the operating system process number

Also, you can set the write_alert_log parameter to y for both a capture process and an outbound server. When this parameter is set to y, which is the default setting, the alert log for the database contains messages about why the capture process or outbound server stopped.

You can control the information in the trace files by setting the trace_level inbound server apply parameter using the SET_PARAMETER procedure in the DBMS_XSTREAM_ADM package.

An inbound server is an Oracle background process named APnn, where nn can include letters and numbers. For example, on some operating systems, if the system identifier for a database running an inbound server is hqdb and the inbound server number is 01, then the trace file for the inbound server starts with hqdb_AP01.

An inbound server also uses other processes. Information about an inbound server might be recorded in the trace file for one or more of these processes. The process name of the reader server and apply servers is ASnn, where nn can include letters and numbers. So, on some operating systems, if the system identifier for a database running an inbound server is hqdb and the process number is 01, then the trace file that contains information about a process used by an inbound server starts with hqdb_AS01.

See Also:

Problems and Solutions for XStream In

In general, you can troubleshoot XStream inbound servers in the same way that you troubleshoot Oracle Streams apply processes. For information, see Oracle Streams Concepts and Administration.

This section describes common problems and solutions specifically for XStream In.

This section contains the following topics:

XStream In Cannot Identify an Inbound Server

If an XStream In configuration cannot identify an inbound server, then the following error is returned:

ORA-26840: STREAMS unable to identify an apply for the source database "%s"

The following sections describe the possible problem and its solution.

Problem: Multiple Subscribers to the Inbound Server's Queue

The ORA-26840 error indicates that there are multiple subscribers to the queue used by the inbound server. Subscribers can include inbound servers, outbound servers, apply processes, and propagations.

To determine whether there are multiple subscribers to the inbound server's queue: 

  1. Connect to the inbound server database as the XStream administrator.

    See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.

  2. Run the following query:

    SELECT OWNER, QUEUE_NAME, CONSUMER_NAME, ADDRESS 
      FROM DBA_QUEUE_SUBSCRIBERS;
    

    You can add a WHERE clause to the query to limit the output to the inbound server's queue.

Solution

To correct the problem: 

  • If the query returns multiple subscribers to the inbound server's queue, then reconfigure the subscribers so that the inbound server is the only subscriber.

Inbound Server Encounters an ORA-03135 Error

An inbound server encounters the following error:

ORA-03135: connection lost contact

Problem: Connection Broken Between the Inbound Server and the Client Application

The ORA-03135 error indicates that the connection between the inbound server and the XStream client application was broken.

Solution

To correct the problem: 

  • Restart the XStream client application.

How to Get More Help with XStream In

You can check My Oracle Support at http://support.oracle.com for more solutions to your problem.

You can visit http://www.oracle.com/support/contact.html for more information about Oracle Support.