This chapter describes common problems you might encounter while using XStream and explains how to solve them.
This chapter contains the following topics:
See Also:
To diagnose problems with XStream In, use the techniques described in this section.
This section contains these topics:
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:
Oracle Database 2 Day + Performance Tuning Guide for information about managing alerts and metric thresholds
Oracle Database Administrator's Guide for information about alerts and for information about subscribing to the ALERT_QUE
queue to receive notifications when new alerts are generated
Oracle Database PL/SQL Packages and Types Reference for more information about the DBMS_SERVER_ALERT
package
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 AP
nn
, 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 AS
nn
, 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:
Oracle Database Administrator's Guide for more information about trace files and the alert log, and for more information about their names and locations
Oracle Database PL/SQL Packages and Types Reference for more information about setting the trace_level
apply parameter
Your operating system specific Oracle documentation for more information about the names and locations of trace files
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:
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:
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.
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.
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.
See Also:
Chapter 4, "Configuring XStream Out"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.
To correct the problem:
Restart the XStream client application.
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.