| Oracle® Streams Concepts and Administration 11g Release 2 (11.2) Part Number E10704-02 |
|
|
View PDF |
| Oracle® Streams Concepts and Administration 11g Release 2 (11.2) Part Number E10704-02 |
|
|
View PDF |
The Oracle Streams Performance Advisor consists of the DBMS_STREAMS_ADVISOR_ADM PL/SQL package and a collection of data dictionary views. The Oracle Streams Performance Advisor enables you to monitor the topology and performance of an Oracle Streams environment. The Oracle Streams topology includes information about the components in an Oracle Streams environment, the links between the components, and the way information flows from capture to consumption. The Oracle Streams Performance Advisor also provides information about how Oracle Streams components are performing.
The following topics contain information about the Oracle Streams Performance Advisor:
About the Information Gathered by the Oracle Streams Performance Advisor
Gathering Information About the Oracle Streams Topology and Performance
Viewing the Oracle Streams Topology and Analyzing Oracle Streams Performance
Oracle Streams enables you to send messages between multiple databases. An Oracle Streams environment can send the following types of messages:
Logical change records (LCRs) that contain database changes
User messages that contain custom information based on user-defined types
The Oracle Streams topology is a representation of the databases in an Oracle Streams environment, the Oracle Streams components configured in these databases, and the flow of messages between these components.
The messages in the environment flow in separate stream paths. A stream path begins where a capture process, a synchronous capture, or an application generates messages and enqueues them. The messages can flow through one or more propagations and queues in its stream path. The stream path ends where the messages are dequeued by an apply process, a messaging client, or an application.
Currently, the Oracle Streams topology only gathers information about a stream path if the stream path ends with an apply process. The Oracle Streams topology does not track stream paths that end when a messaging client or an application dequeues messages.
The Oracle Streams Performance Advisor consists of the DBMS_STREAMS_ADVISOR_ADM PL/SQL package and a collection of data dictionary views. You can use the ANALYZE_CURRENT_PERFORMANCE procedure in the DBMS_STREAMS_ADVISOR_ADM package to gather information about the Oracle Streams topology and about the performance of the Oracle Streams components in the topology.
This section contains the following topics:
After information is gathered by the Oracle Streams Performance Advisor, you can view it by querying the following data dictionary views:
DBA_STREAMS_TP_COMPONENT contains information about each Oracle Streams component at each database.
DBA_STREAMS_TP_COMPONENT_LINK contains information about how messages flow between Oracle Streams components.
DBA_STREAMS_TP_COMPONENT_STAT contains temporary performance statistics and session statistics about each Oracle Streams component.
DBA_STREAMS_TP_DATABASE contains information about each database that contains Oracle Streams components.
DBA_STREAMS_TP_PATH_BOTTLENECK contains temporary information about Oracle Streams components that might be slowing down the flow of messages in a stream path.
DBA_STREAMS_TP_PATH_STAT contains temporary performance statistics about each stream path that exists in the Oracle Streams topology.
The topology information is stored permanently in the following data dictionary views: DBA_STREAMS_TP_DATABASE, DBA_STREAMS_TP_COMPONENT, and DBA_STREAMS_TP_COMPONENT_LINK.
The following views contain temporary information: DBA_STREAMS_TP_COMPONENT_STAT, DBA_STREAMS_TP_PATH_BOTTLENECK, and DBA_STREAMS_TP_PATH_STAT. Some of the data in these views is retained only for the user session that runs the ANALYZE_CURRENT_PERFORMANCE procedure. When this user session ends, this temporary information is purged.
The DBMS_STREAMS_ADVISOR_ADM package gathers information about the following Oracle Streams components:
A QUEUE stores messages. The package gathers the following component-level statistics for queues:
ENQUEUE RATE
SPILL RATE
CURRENT QUEUE SIZE
A CAPTURE is a capture process. A capture process captures database changes in the redo log and enqueues the changes as logical change records (LCRs). Each capture process has the following subcomponents:
LOGMINER BUILDER is a builder server.
LOGMINER PREPARER is a preparer server.
LOGMINER READER is a reader server.
CAPTURE SESSION is the capture process session.
The package gathers the following component-level statistics for each capture process (CAPTURE):
CAPTURE RATE
ENQUEUE RATE
LATENCY
The package also gathers session-level statistics for capture process subcomponents.
A PROPAGATION SENDER sends messages from a source queue to a destination queue. The package gathers the following component-level statistics for propagation senders:
SEND RATE
BANDWIDTH
LATENCY
The package also gathers session-level statistics for propagation senders.
A PROPAGATION RECEIVER enqueues messages sent by propagation senders into a destination queue. The package gathers session-level statistics for propagation receivers.
An APPLY is an apply process. These components either apply messages directly or send messages to apply handlers. This type of component has the following subcomponents:
APPLY READER is a reader server.
APPLY COORDINATOR is a coordinator process.
APPLY SERVER is an apply server.
The package gathers the following component-level statistics for this component (APPLY):
MESSAGE APPLY RATE
TRANSACTION APPLY RATE
LATENCY
The package also gathers session-level statistics for the subcomponents.
When the package gathers session-level statistics for a component or subcomponent, the session-level statistics include the following:
IDLE percentage
FLOW CONTROL percentage
EVENT percentage for wait events
Note:
Currently, the
DBMS_STREAMS_ADVISOR_ADM package does not gather information about synchronous captures or messaging clients.See Also:
"Viewing Component-Level Statistics" for detailed information about component-level statistics
"Viewing Session-Level Statistics" for detailed information about session-level statistics
In the Oracle Streams topology, a stream path is a flow of messages from a source to a destination. A stream path begins where a capture process, synchronous capture, or application enqueues messages into a queue. A stream path ends where an apply process dequeues the messages. The stream path might flow through multiple queues and propagations before it reaches an apply process. Therefore, a single stream path can consist of multiple source/destination component pairs before it reaches last component.
The Oracle Streams topology assigns a number to each stream path so that you can monitor each one easily. The Oracle Streams topology also assigns a number to each link between two components in a stream path. The number specifies the position of the link in the overall stream path.
Table 23-1 shows the position of each link in a sample stream path.
Table 23-1 Position of Each Link in a Sample Stream Path
| Start Component | End Component | Position |
|---|---|---|
|
Capture process |
Queue |
1 |
|
Queue |
Propagation sender |
2 |
|
Propagation sender |
Propagation receiver |
3 |
|
Propagation receiver |
Queue |
4 |
|
Queue |
Apply process |
5 |
When the Oracle Streams Performance Advisor gathers information about an Oracle Streams environment, it tracks stream paths by starting with each apply process and working backward to its source. When a capture process is the source, the Oracle Streams Performance Advisor tracks the path from the apply process back to the capture process. When a synchronous capture or an application that enqueues messages is the source, the Oracle Streams Performance Advisor tracks the path from the apply process back to the queue into which the messages are enqueued.
The following sections describe sample replication environments and the stream paths in each one:
See Also:
Oracle Streams Replication Administrator's Guide for information about best practices for Oracle Streams replication environmentsConsider an Oracle Streams environment with two databases. Each database captures changes made to the replicated database objects with a capture process and sends the changes to the other database, where they are applied by an apply process. The stream paths in this environment are completely separate.
Figure 23-1 shows an example of this type of Oracle Streams replication environment.
Figure 23-1 Oracle Streams Topology with Two Separate Stream Paths
Notice that the Oracle Streams Performance Advisor assigns a component ID to each Oracle Streams component and a path ID to each path. The Oracle Streams topology in Figure 23-1 shows the following information:
There are twelve Oracle Streams components in the Oracle Streams environment.
There are two stream paths in the Oracle Streams environment.
Stream path 1 starts with component 1 and ends with component 6.
Stream path 2 starts with component 7 and ends with component 12.
When there are multiple apply processes that apply changes generated by a single source, a stream path splits into multiple stream paths. In this case, part of a stream path is shared, but the path splits into two or more distinct stream paths.
Figure 23-2 shows this type of Oracle Streams environment.
Figure 23-2 Oracle Streams Topology with Multiple Apply Processes for a Single Source
The Oracle Streams topology in Figure 23-2 shows the following information:
There are ten Oracle Streams components in the Oracle Streams environment.
There are two stream paths in the Oracle Streams environment.
Stream path 1 starts with component 1 and ends with component 7.
Stream path 2 starts with component 1 and ends with component 10.
The messages flowing between component 1 and component 2 are in both path 1 and path2.
See Also:
"Message Propagation Between Queues"The ANALYZE_CURRENT_PERFORMANCE procedure in the DBMS_STREAMS_ADVISOR_ADM package gathers information about the Oracle Streams topology and the performance of Oracle Streams components. The procedure stores the information in a collection of data dictionary views. To use the Oracle Streams Performance Advisor effectively, it is important to understand how the procedure gathers information and calculates statistics.
The procedure takes snapshots of the Oracle Streams environment to gather information and calculate statistics. For some statistics, the information in a single snapshot is sufficient. For example, only one snapshot is needed to determine the current number of messages in a queue. However, to calculate other statistics, the procedure must compare two snapshots. These statistics include the rate, bandwidth, event, and flow control statistics. The first time the procedure is run in a user session, it takes two snapshots to calculate these statistics. In each subsequent run in the same user session, the procedure takes one snapshot and compares it with the snapshot taken during the previous run.
Table 23-2 illustrates how the procedure gathers information in each advisor run in a single user session.
Table 23-2 How the Oracle Streams Performance Advisor Gathers Information in a Session
| Advisor Run | Information Gathered |
|---|---|
|
1 |
|
|
2 |
|
|
3 |
|
For the best results in an advisor run, meet the following criteria:
Ensure that as many Oracle Streams components as possible are enabled during the time period between the two snapshots used in the advisor run. Specifically, capture processes, propagations, apply processes should be enabled, queues should be started, and database links should be active.
If data is replicated in the Oracle Streams environment, then ensure that the replicated database objects are experiencing an average, or near average, number of changes during the time period between the two snapshots used in the advisor run. The Oracle Streams Performance Advisor gathers more accurate statistics if it is run when the Oracle Streams replication environment is experiencing typical replication activity.
If messages are sent by applications in the Oracle Streams environment, then ensure that the applications are sending an average, or near average, number of messages during the time period between the two snapshots used in the advisor run. The Oracle Streams Performance Advisor gathers more accurate statistics if it is run when the Oracle Streams messaging environment is sending a typical number of messages.
To gather information about the Oracle Streams topology and Oracle Streams performance, complete the following steps:
Identify the database that you will use to gather the information. An administrative user at this database must meet the following requirements:
The user must have access to a database link to each database that contains Oracle Streams components.
The user must have been granted privileges using the DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE procedure, and each database link must connect to a user at the remote database that has been granted privileges using the DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE procedure.
If you configure an Oracle Streams administrator at each database with Oracle Streams components, then the Oracle Streams administrator has the necessary privileges. See Oracle Streams Replication Administrator's Guide for information about creating an Oracle Streams administrator.
If no database in your environment meets these requirements, then choose a database, configure the necessary database links, and grant the necessary privileges to the users before proceeding.
The Oracle Streams Performance Advisor running on an Oracle Database 11g Release 2 (11.2) database can monitor Oracle Database 10g Release 2 (10.2) and later databases. It cannot monitor databases prior to release 10.2.
In SQL*Plus, connect to the database you identified in Step 1 as a user that meets the requirements listed in Step 1.
For example, connect to the hub.example.com database as the Oracle Streams administrator.
See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.
Run the ANALYZE_CURRENT_PERFORMANCE procedure in the DBMS_STREAMS_ADVISOR_ADM package:
exec DBMS_STREAMS_ADVISOR_ADM.ANALYZE_CURRENT_PERFORMANCE;
Optionally, rerun the ANALYZE_CURRENT_PERFORMANCE procedure one or more times in same session that ran the procedure in Step 3:
exec DBMS_STREAMS_ADVISOR_ADM.ANALYZE_CURRENT_PERFORMANCE;
Run the following query to identify the advisor run ID for the information gathered in Step 4:
SELECT DISTINCT ADVISOR_RUN_ID FROM DBA_STREAMS_TP_COMPONENT_STAT ORDER BY ADVISOR_RUN_ID;
Your output is similar to the following:
ADVISOR_RUN_ID
--------------
1
2
The Oracle Streams Performance Advisor assigns an advisor run ID to the statistics for each run. Use the last value in the output for the advisor run ID in the queries in "Viewing Performance Statistics for Oracle Streams Components". In this example, use 2 for the advisor run ID in the queries.
Remember that the Oracle Streams Performance Advisor purges some of the performance statistics that it gathered when a user session ends. Therefore, run the performance statistics queries in the same session that ran the ANALYZE_CURRENT_PERFORMANCE procedure.
Complete these steps whenever you want to monitor the current performance of your Oracle Streams environment.
You should also run the ANALYZE_CURRENT_PERFORMANCE procedure when new Oracle Streams components are added to any database in the Oracle Streams environment. Running the procedure updates the Oracle Streams topology with information about any new components.
See Also:
Oracle Database PL/SQL Packages and Types Reference for information about the DBMS_STREAMS_ADVISOR_ADM package
This section contains several queries that you can use to view your Oracle Streams topology and monitor the performance of your Oracle Streams components. The queries specify the views described in "About the Oracle Streams Topology".
The queries in this section can be run in any Oracle Stream environment. However, the output shown for these queries is based on the sample Oracle Streams replication environment shown in Figure 23-3.
Figure 23-3 Sample Oracle Streams Replication Environment
The Oracle Database 2 Day + Data Replication and Integration Guide contains instructions for configuring the Oracle Streams replication environment shown in Figure 23-3. This environment contains both of the following types of stream paths:
Separate stream paths flow from the spoke1.example.com database to the hub.example.com database and from the spoke2.example.com database to the hub.example.com database. This type of stream path is described in "Separate Stream Paths in an Oracle Streams Environment".
Two stream paths that share a portion of the path flow from the hub.example.com database to the spoke1.example.com and spoke2.example.com databases. This type of stream path is described in "Shared Stream Paths in an Oracle Streams Replication Environment".
This section contains the following topics:
To view the Oracle Streams topology, you must first gather information about the Oracle Streams environment using the DBMS_STREAMS_ADVISOR_ADM package. See "Gathering Information About the Oracle Streams Topology and Performance".
The following sections explain how to view different types of information in an Oracle Streams topology:
You can view the following information about the databases in an Oracle Streams environment:
The global name of each database
The last time the Oracle Streams Performance Advisor was run at each database
The version number of each database
The compatibility level of each database
Whether each database has access to the Oracle Diagnostics Pack and Oracle Tuning Pack
To display this information, run the following query:
COLUMN GLOBAL_NAME HEADING 'Global Name' FORMAT A15 COLUMN LAST_QUERIED HEADING 'Last|Queried' COLUMN VERSION HEADING 'Version' FORMAT A15 COLUMN COMPATIBILITY HEADING 'Compatibility' FORMAT A15 COLUMN MANAGEMENT_PACK_ACCESS HEADING 'Management Pack' FORMAT A20 SELECT GLOBAL_NAME, LAST_QUERIED, VERSION, COMPATIBILITY, MANAGEMENT_PACK_ACCESS FROM DBA_STREAMS_TP_DATABASE;
The following output shows the databases in the Oracle Streams replication environment described in "Viewing the Oracle Streams Topology and Analyzing Oracle Streams Performance":
Last Global Name Queried Version Compatibility Management Pack --------------- --------- --------------- --------------- -------------------- HUB.EXAMPLE.COM 08-APR-08 11.1.0.7.0 11.1.0 DIAGNOSTIC+TUNING SPOKE1.EXAMPLE. 08-APR-08 11.1.0.7.0 11.1.0 DIAGNOSTIC+TUNING COM SPOKE2.EXAMPLE. 08-APR-08 11.1.0.7.0 11.1.0 DIAGNOSTIC+TUNING COM
This output shows the following information about the databases in the Oracle Streams environment:
The Global Name column shows that the global names of the databases are hub.example.com, spoke1.example.com, and spoke2.example.com.
The Last Queried column shows that the Oracle Streams Performance Advisor was last run on April 8, 2008 at each database.
The Version column shows that version of each database is 11.1.0.7.0.
The Compatibility column shows that the compatibility level of each database is 11.1.0.
The Management Pack column shows that each database has access to the Oracle Diagnostics Pack and Oracle Tuning Pack.
See Also:
Oracle Database Upgrade Guide for information about database compatibilityYou can view the following information about the components in an Oracle Streams environment:
The component ID for each Oracle Streams component. The Oracle Streams topology assigns an ID number to each component and uses the number to track information about the component and about the stream path that flows through the component.
The name of the Oracle Streams component. For capture processes and apply processes, the query lists the name of each process. For queues, the query lists the name of each queue. For propagations, two Oracle Streams components are tracked in the Oracle Streams topology:
The name of a propagation sender is the source queue of the propagation and the destination queue and database to which the propagation sends messages. For example, a propagation sender with the strmadmin.source_hns source queue that sends messages to the strmadmin.destination_spoke1 destination queue at the spoke1.example.com database is shown in the following way:
"STRMADMIN"."SOURCE_HNS"=>"STRMADMIN"."DESTINATION_SPOKE1" @SPOKE1.EXAMPLE.COM
The name of a propagation receiver is the source queue and database from which the messages are sent and the destination queue for the propagation. For example, a propagation receiver that gets messages from the strmadmin.source_hns source queue at the hub.example.com database and enqueues them into the strmadmin.destination_spoke1 destination queue is shown in the following way:
"STRMADMIN"."SOURCE_HNS"@HUB.EXAMPLE.COM=>"STRMADMIN". "DESTINATION_SPOKE1"
The type of the Oracle Streams component. The following types are possible:
CAPTURE for capture processes
QUEUE for queues
PROPAGATION SENDER for propagation senders
PROPAGATION RECEIVER for propagation receivers
APPLY for apply processes
The database that contains the component
To display this information, run the following query:
COLUMN COMPONENT_ID HEADING 'ID' FORMAT 999 COLUMN COMPONENT_NAME HEADING 'Name' FORMAT A43 COLUMN COMPONENT_TYPE HEADING 'Type' FORMAT A20 COLUMN COMPONENT_DB HEADING 'Database' FORMAT A10 SELECT COMPONENT_ID, COMPONENT_NAME, COMPONENT_TYPE, COMPONENT_DB FROM DBA_STREAMS_TP_COMPONENT ORDER BY COMPONENT_ID;
The following output shows the components in the Oracle Streams replication environment described in "Viewing the Oracle Streams Topology and Analyzing Oracle Streams Performance":
ID Name Type Database
---- ------------------------------------------- -------------------- ----------
1 "STRMADMIN"."DESTINATION_SPOKE1" QUEUE HUB.EXAMPL
E.COM
2 "STRMADMIN"."DESTINATION_SPOKE2" QUEUE HUB.EXAMPL
E.COM
3 "STRMADMIN"."SOURCE_HNS" QUEUE HUB.EXAMPL
E.COM
4 "STRMADMIN"."SOURCE_HNS"=>"STRMADMIN"."DEST PROPAGATION SENDER HUB.EXAMPL
INATION_SPOKE1"@SPOKE1.EXAMPLE.COM E.COM
5 "STRMADMIN"."SOURCE_HNS"=>"STRMADMIN"."DEST PROPAGATION SENDER HUB.EXAMPL
INATION_SPOKE2"@SPOKE2.EXAMPLE.COM E.COM
6 "STRMADMIN"."SOURCE_HNS"@SPOKE1.EXAMPLE.COM PROPAGATION RECEIVER HUB.EXAMPL
=>"STRMADMIN"."DESTINATION_SPOKE1" E.COM
7 "STRMADMIN"."SOURCE_HNS"@SPOKE2.EXAMPLE.COM PROPAGATION RECEIVER HUB.EXAMPL
=>"STRMADMIN"."DESTINATION_SPOKE2" E.COM
8 APPLY_SPOKE1 APPLY HUB.EXAMPL
E.COM
9 APPLY_SPOKE2 APPLY HUB.EXAMPL
E.COM
10 CAPTURE_HNS CAPTURE HUB.EXAMPL
E.COM
11 "STRMADMIN"."DESTINATION_SPOKE1" QUEUE SPOKE1.EXA
MPLE.COM
12 "STRMADMIN"."SOURCE_HNS" QUEUE SPOKE1.EXA
MPLE.COM
13 "STRMADMIN"."SOURCE_HNS"=>"STRMADMIN"."DEST PROPAGATION SENDER SPOKE1.EXA
INATION_SPOKE1"@HUB.EXAMPLE.COM MPLE.COM
14 "STRMADMIN"."SOURCE_HNS"@HUB.EXAMPLE.COM=>" PROPAGATION RECEIVER SPOKE1.EXA
STRMADMIN"."DESTINATION_SPOKE1" MPLE.COM
15 APPLY_SPOKE1 APPLY SPOKE1.EXA
MPLE.COM
16 CAPTURE_HNS CAPTURE SPOKE1.EXA
MPLE.COM
17 "STRMADMIN"."DESTINATION_SPOKE2" QUEUE SPOKE2.EXA
MPLE.COM
18 "STRMADMIN"."SOURCE_HNS" QUEUE SPOKE2.EXA
MPLE.COM
19 "STRMADMIN"."SOURCE_HNS"=>"STRMADMIN"."DEST PROPAGATION SENDER SPOKE2.EXA
INATION_SPOKE2"@HUB.EXAMPLE.COM MPLE.COM
20 "STRMADMIN"."SOURCE_HNS"@HUB.EXAMPLE.COM=>" PROPAGATION RECEIVER SPOKE2.EXA
STRMADMIN"."DESTINATION_SPOKE2" MPLE.COM
21 APPLY_SPOKE2 APPLY SPOKE2.EXA
MPLE.COM
22 CAPTURE_HNS CAPTURE SPOKE2.EXA
MPLE.COM
See Also:
"Viewing Component-Level Statistics" for a query that shows performance statistics for each Oracle Streams component
Oracle Streams Extended Examples for information about the n-way replication environment shown in the output
You can view the following information about the stream paths in an Oracle Streams topology:
The path ID. The Oracle Streams topology assigns an ID number to each stream path it identifies. The path ID is associated with each link in the path. For example, a single path ID can be associated with the following component links:
Capture process to queue
Queue to propagation sender
Propagation sender to propagation receiver
Propagation receiver to queue
Queue to apply process
The source component ID. A source component is a component from which messages flow to another component.
The name of the source component. See "Viewing the Oracle Streams Components at Each Database" for information about how components are named in the query output.
The destination component ID. A destination component receives messages from another component.
The name of the destination component.
The position in the stream path shows the location of a particular link in a path. For example, a position might be the first link in a path, the second link in a path, and so on.
To display this information, run the following query:
COLUMN PATH_ID HEADING 'Path|ID' FORMAT 9999
COLUMN SOURCE_COMPONENT_ID HEADING 'Source|Component|ID' FORMAT 9999
COLUMN SOURCE_COMPONENT_NAME HEADING 'Source|Component|Name' FORMAT A20
COLUMN DESTINATION_COMPONENT_ID HEADING 'Dest|Component|ID' FORMAT 9999
COLUMN DESTINATION_COMPONENT_NAME HEADING 'Dest|Component|Name' FORMAT A15
COLUMN POSITION HEADING 'Position' FORMAT 9999
SELECT PATH_ID,
SOURCE_COMPONENT_ID,
SOURCE_COMPONENT_NAME,
DESTINATION_COMPONENT_ID,
DESTINATION_COMPONENT_NAME,
POSITION
FROM DBA_STREAMS_TP_COMPONENT_LINK
ORDER BY PATH_ID, POSITION;
The following output shows the paths in the Oracle Streams topology for the components listed in "Viewing the Oracle Streams Components at Each Database":
Source Source Dest Dest
Path Component Component Component Component
ID ID Name ID Name Position
----- --------- -------------------- --------- --------------- --------
1 16 CAPTURE_HNS 12 "STRMADMIN"."SO 1
URCE_HNS"
1 12 "STRMADMIN"."SOURCE_ 13 "STRMADMIN"."SO 2
HNS" URCE_HNS"=>"STR
MADMIN"."DESTIN
ATION_SPOKE1"@H
UB.EXAMPLE.COM
1 13 "STRMADMIN"."SOURCE_ 6 "STRMADMIN"."SO 3
HNS"=>"STRMADMIN"."D URCE_HNS"@SPOKE
ESTINATION_SPOKE1"@H 1.EXAMPLE.COM=>
UB.EXAMPLE.COM "STRMADMIN"."DES
TINATION_SPOKE1"
1 6 "STRMADMIN"."SOURCE_ 1 "STRMADMIN"."DE 4
HNS"@SPOKE1.EXAMPLE. STINATION_SPOKE
COM=>"STRMADMIN"."DE 1"
STINATION_SPOKE1"
1 1 "STRMADMIN"."DESTINA 8 APPLY_SPOKE1 5
TION_SPOKE1"
2 22 CAPTURE_HNS 18 "STRMADMIN"."SO 1
URCE_HNS"
2 18 "STRMADMIN"."SOURCE_ 19 "STRMADMIN"."SO 2
HNS" URCE_HNS"=>"STR
MADMIN"."DESTIN
ATION_SPOKE2"@H
UB.EXAMPLE.COM
2 19 "STRMADMIN"."SOURCE_ 7 "STRMADMIN"."SO 3
HNS"=>"STRMADMIN"."D URCE_HNS"@SPOKE
ESTINATION_SPOKE2"@H 2.EXAMPLE.COM=>
UB.EXAMPLE.COM "STRMADMIN"."DES
TINATION_SPOKE2"
2 7 "STRMADMIN"."SOURCE_ 2 "STRMADMIN"."DE 4
HNS"@SPOKE2.EXAMPLE. STINATION_SPOKE
COM=>"STRMADMIN"."DE 2"
STINATION_SPOKE2"
2 2 "STRMADMIN"."DESTINA 9 APPLY_SPOKE2 5
TION_SPOKE2"
3 10 CAPTURE_HNS 3 "STRMADMIN"."SO 1
URCE_HNS"
3 3 "STRMADMIN"."SOURCE_ 4 "STRMADMIN"."SO 2
HNS" URCE_HNS"=>"STR
MADMIN"."DESTIN
ATION_SPOKE1"@S
POKE1.EXAMPLE.CO
M
3 4 "STRMADMIN"."SOURCE_ 14 "STRMADMIN"."SO 3
HNS"=>"STRMADMIN"."D URCE_HNS"@HUB.N
ESTINATION_SPOKE1"@S ET=>"STRMADMIN"
POKE1.EXAMPLE.COM ."DESTINATION_S
POKE1"
3 14 "STRMADMIN"."SOURCE_ 11 "STRMADMIN"."DE 4
HNS"@HUB.EXAMPLE.COM STINATION_SPOKE
=>"STRMADMIN"."DESTI 1"
NATION_SPOKE1"
3 11 "STRMADMIN"."DESTINA 15 APPLY_SPOKE1 5
TION_SPOKE1"
4 10 CAPTURE_HNS 3 "STRMADMIN"."SO 1
URCE_HNS"
4 3 "STRMADMIN"."SOURCE_ 5 "STRMADMIN"."SO 2
HNS" URCE_HNS"=>"STR
MADMIN"."DESTIN
ATION_SPOKE2"@S
POKE2.EXAMPLE.C
OM
4 5 "STRMADMIN"."SOURCE_ 20 "STRMADMIN"."SO 3
HNS"=>"STRMADMIN"."D URCE_HNS"@HUB.N
ESTINATION_SPOKE2"@S ET=>"STRMADMIN"
POKE2.EXAMPLE.COM ."DESTINATION_S
POKE2"
4 20 "STRMADMIN"."SOURCE_ 17 "STRMADMIN"."DE 4
HNS"@HUB.EXAMPLE.COM STINATION_SPOKE
=>"STRMADMIN"."DESTI 2"
NATION_SPOKE2"
4 17 "STRMADMIN"."DESTINA 21 APPLY_SPOKE2 5
TION_SPOKE2"
The DBMS_STREAMS_ADVISOR_ADM package and the Oracle Streams topology views comprise the Oracle Streams Performance Advisor. The Oracle Streams topology views enable you to display and analyze performance statistics for the Oracle Streams components in your environment.
To view performance statistics for Oracle Streams components, you must first gather information about the Oracle Streams environment using the DBMS_STREAMS_ADVISOR_ADM package. See "Gathering Information About the Oracle Streams Topology and Performance".
The following sections explain how to view performance statistics for Oracle Streams components:
Checking for Bottleneck Components in the Oracle Streams Topology
Viewing Statistics for the Stream Paths in an Oracle Streams Environment
Note:
The performance of Oracle Streams components depends on several factors, including the computer equipment used in the environment and the speed of the network.A bottleneck component is the busiest component or the component with the least amount of idle time. You can view the following information about the bottleneck components in an Oracle Streams environment:
The path ID of the path that includes the component.
The component ID for each Oracle Streams component. The Oracle Streams topology assigns an ID number to each component and uses the number to track information about the component and about the stream path that flows through the component.
The name of the Oracle Streams component. See "Viewing the Oracle Streams Components at Each Database" for information about how components are named in the query output.
The type of the Oracle Streams component. The following types are possible:
CAPTURE for capture processes
QUEUE for queues
PROPAGATION SENDER for propagation senders
PROPAGATION RECEIVER for propagation receivers
APPLY for apply processes
The database that contains the component
Run the following query to check for bottleneck components in your Oracle Streams environment:
COLUMN PATH_ID HEADING 'Path ID' FORMAT 999
COLUMN COMPONENT_ID HEADING 'Component ID' FORMAT 999
COLUMN COMPONENT_NAME HEADING 'Name' FORMAT A20
COLUMN COMPONENT_TYPE HEADING 'Type' FORMAT A20
COLUMN COMPONENT_DB HEADING 'Database' FORMAT A15
SELECT PATH_ID,
COMPONENT_ID,
COMPONENT_NAME,
COMPONENT_TYPE,
COMPONENT_DB
FROM DBA_STREAMS_TP_PATH_BOTTLENECK
WHERE BOTTLENECK_IDENTIFIED='YES' AND
ADVISOR_RUN_ID=2
ORDER BY PATH_ID, COMPONENT_ID;
This example uses 2 for the ADVISOR_RUN_ID in the WHERE clause. Substitute the advisor run ID for the advisor run you want to query. See "Gathering Information About the Oracle Streams Topology and Performance" for information about determining the ADVISOR_RUN_ID.
The following output shows the bottleneck components for the components listed in "Viewing the Oracle Streams Components at Each Database":
Path ID Component ID Name Type Database
------- ------------ -------------------- -------------------- ---------------
1 6 "STRMADMIN"."SOURCE_ PROPAGATION RECEIVER HUB.EXAMPLE.COM
HNS"@SPOKE1.EXAMPLE.
COM=>"STRMADMIN"."DE
STINATION_SPOKE1"
3 10 CAPTURE_HNS CAPTURE HUB.EXAMPLE.COM
4 10 CAPTURE_HNS CAPTURE HUB.EXAMPLE.COM
If this query returns no results, then the Oracle Streams Performance Advisor did not identify any bottleneck components in your environment. However, if this query returns one or more bottleneck components, then check the status of these components. If they are disabled, then you can enable them. If the components are enabled, then you can examine the components to see if they can be modified to perform better.
In some cases, the Oracle Streams Performance Advisor cannot determine whether a component is a bottleneck component. To view these components, set BOTTLENECK_IDENTIFIED to 'NO' when you query the DBA_STREAMS_TP_PATH_BOTTLENECK view. The output for the ADVISOR_RUN_REASON column shows why the Oracle Streams Performance Advisor could not determine whether the component is a bottleneck component. The following reasons can be specified in the ADVISOR_RUN_REASON column output:
PRE-11.1 DATABASE EXISTS means that the component is in a stream path that includes a database prior to Oracle Database 11g Release 1. Bottleneck analysis is not performed on these components.
DIAGNOSTIC PACK REQUIRED means that the component is in a stream path that includes a database that does not have the Oracle Diagnostics Pack. Bottleneck analysis is not performed on these components.
NO BOTTLENECK IDENTIFIED means that either no bottleneck was identified in a stream path or that there might be more than one bottleneck component in the stream path.
You can view statistics for the Oracle Streams components in the Oracle Streams topology. The query in this section displays the following information for each component:
The ID of the path to which the component belongs
The name of the Oracle Streams component
The type of the Oracle Streams component. The following types are possible:
CAPTURE for capture processes
QUEUE for queues
PROPAGATION SENDER for propagation senders
PROPAGATION RECEIVER for propagation receivers
APPLY for apply processes
The statistic that was gathered for the component
The value and unit of the statistic. For example, a LATENCY statistic shows a number for the value and SECONDS for the unit. A TRANSACTION APPLY RATE statistic shows a number for the value and TRANSACTIONS PER SECOND for the unit.
The ANALYZE_CURRENT_PERFORMANCE procedure in the DBMS_STREAMS_ADVISOR_ADM package gathers the statistics returned by the query in this section. Therefore, the statistics returned by the query were the current statistics when the procedure was run. The statistics are not updated automatically.
Table 23-3 describes each of the statistics that can be returned by the query in this section:
Table 23-3 Component-Level Statistics for Oracle Streams Components
| Component Type | Statistic | Unit | Description |
|---|---|---|---|
|
|
|
|
The average number of database changes in the redo log scanned by the capture process each second. A capture process captures and enqueues the scanned changes that satisfy its rule sets. |
|
|
|
|
The average number of logical change records (LCRs) enqueued by the capture process each second. |
|
|
|
|
The amount of time between when the last redo entry became available for the capture process and the time when the last redo entry scanned by the capture process was recorded in the redo log. The purpose of the statistic is to show the amount of time between when a change is recorded in the redo log and when the redo record is scanned by the capture process. The capture process might or might not enqueue a scanned change. A capture process only enqueues a change if the change satisfies its rule sets. |
|
|
|
|
The average number of messages sent each second by the propagation sender. |
|
|
|
|
The average number of bytes sent each second by the propagation sender. |
|
|
|
|
The amount of time between when a message was created at the source database and when the message was sent to the destination queue by the propagation sender. The value shown is for a single message that was sent from the source queue to the destination queue by the propagation sender. This message was the last message sent by the propagation sender when the Depending on the type of message sent by the propagation, message creation time is one of the following:
|
|
|
|
|
The average number of messages applied each second by the apply process. A captured LCR or persistent LCR can be applied in one of the following ways:
A persistent user message can be applied in one of the following ways:
|
|
|
|
|
The average number of transactions applied by the apply process each second. Transactions typically include multiple messages. A transaction that includes captured LCRs or persistent LCRs can be applied in one of the following ways:
A transaction that includes persistent user messages can be applied in one of the following ways:
|
|
|
|
|
For apply processes, the amount of time between when the message was created at a source database and when the message was applied by the apply process at the destination database. The value shown is for a single message that was applied by the apply process. This message was the last message applied when the Depending on the type of message applied, message creation time is one of the following:
|
|
|
|
|
The average number of messages enqueued into the queue each second. |
|
|
|
|
The average number of messages that spilled from the buffered queue to the queue table each second. |
|
|
|
|
The number of messages in the queue when the |
|
|
|
|
The percentage of time that the Oracle Streams component spent waiting because of a wait event. The Oracle Streams Performance Advisor only gathers information about the top three events for each component. For example, a capture process might wait for a redo log file to become available. |
The following are general considerations for these performance statistics:
Regarding rate, bandwidth, and event statistics, the time period is calculated as the time difference between the two snapshots used by the ANALYZE_CURRENT_PERFORMANCE procedure in the same user session. See "About the Information Gathered by the Oracle Streams Performance Advisor" for information about the snapshots. When a user session ends, the rate, bandwidth, and event statistics are purged.
When a latency statistic is -1 seconds, the ANALYZE_CURRENT_PERFORMANCE procedure could not gather statistics for the component when it was run. In most cases, this result indicates that the component was disabled when the procedure was run. For example, if the LATENCY statistic for an apply process is -1, then the component was probably disabled when the ANALYZE_CURRENT_PERFORMANCE procedure was run.
To display performance statistics for the components in an Oracle Streams topology, run the following query:
COLUMN PATH_ID HEADING 'Path|ID' FORMAT 999
COLUMN COMPONENT_ID HEADING 'Component|ID' FORMAT 999
COLUMN COMPONENT_NAME HEADING 'Name' FORMAT A20
COLUMN COMPONENT_TYPE HEADING 'Type' FORMAT A12
COLUMN STATISTIC_NAME HEADING 'Statistic' FORMAT A15
COLUMN STATISTIC_VALUE HEADING 'Value' FORMAT 99999999999.99
COLUMN STATISTIC_UNIT HEADING 'Unit' FORMAT A15
SELECT DISTINCT
cp.PATH_ID,
cs.COMPONENT_ID,
cs.COMPONENT_NAME,
cs.COMPONENT_TYPE,
cs.STATISTIC_NAME,
cs.STATISTIC_VALUE,
cs.STATISTIC_UNIT
FROM DBA_STREAMS_TP_COMPONENT_STAT cs,
(SELECT PATH_ID, SOURCE_COMPONENT_ID AS COMPONENT_ID
FROM DBA_STREAMS_TP_COMPONENT_LINK
UNION
SELECT PATH_ID, DESTINATION_COMPONENT_ID AS COMPONENT_ID
FROM DBA_STREAMS_TP_COMPONENT_LINK) cp
WHERE cs.ADVISOR_RUN_ID = 2 AND
cs.SESSION_ID IS NULL AND
cs.SESSION_SERIAL# IS NULL AND
cs.COMPONENT_ID = cp.COMPONENT_ID
ORDER BY PATH_ID, COMPONENT_ID, COMPONENT_NAME, COMPONENT_TYPE, STATISTIC_NAME;
This example uses 2 for the ADVISOR_RUN_ID in the WHERE clause. Substitute the advisor run ID for the advisor run you want to query. See "Gathering Information About the Oracle Streams Topology and Performance" for information about determining the ADVISOR_RUN_ID.
The following output shows a partial list of the performance statistics for the components listed in "Viewing the Oracle Streams Components at Each Database". Specifically, the following output shows performance statistics for the components in stream path 1 and stream path 3:
Path Component
ID ID Name Type Statistic Value Unit
---- ---------- -------------------- ------------ --------------- --------------- ---------------
1 1 "STRMADMIN"."DESTINA QUEUE CURRENT QUEUE S .00 NUMBER OF MESSA
TION_SPOKE1" IZE GES
1 1 "STRMADMIN"."DESTINA QUEUE ENQUEUE RATE 2573.21 MESSAGES PER SE
TION_SPOKE1" COND
1 1 "STRMADMIN"."DESTINA QUEUE SPILL RATE .00 MESSAGES PER SE
TION_SPOKE1" COND
1 6 "STRMADMIN"."SOURCE_ PROPAGATION EVENT: CPU + Wa 32.55 PERCENT
HNS"@SPOKE1.EXAMPLE. RECEIVER it for CPU
COM=>"STRMADMIN"."DE
STINATION_SPOKE1"
1 6 "STRMADMIN"."SOURCE_ PROPAGATION EVENT: SQL*Net 23.62 PERCENT
HNS"@SPOKE1.EXAMPLE. RECEIVER more data from
COM=>"STRMADMIN"."DE client
STINATION_SPOKE1"
1 6 "STRMADMIN"."SOURCE_ PROPAGATION EVENT: latch: r 2.10 PERCENT
HNS"@SPOKE1.EXAMPLE. RECEIVER ow cache object
COM=>"STRMADMIN"."DE s
STINATION_SPOKE1"
1 8 APPLY_SPOKE1 APPLY EVENT: CPU + Wa 23.10 PERCENT
it for CPU
1 8 APPLY_SPOKE1 APPLY EVENT: latch: r 1.31 PERCENT
ow cache object
s
1 8 APPLY_SPOKE1 APPLY EVENT: latch: s 1.57 PERCENT
hared pool
1 8 APPLY_SPOKE1 APPLY LATENCY 2.13 SECONDS
1 8 APPLY_SPOKE1 APPLY MESSAGE APPLY R 10004.00 MESSAGES PER SE
ATE COND
1 8 APPLY_SPOKE1 APPLY TRANSACTION APP 100.00 TRANSACTIONS PE
LY RATE R SECOND
1 12 "STRMADMIN"."SOURCE_ QUEUE CURRENT QUEUE S .00 NUMBER OF MESSA
HNS" IZE GES
1 12 "STRMADMIN"."SOURCE_ QUEUE ENQUEUE RATE 9932.00 MESSAGES PER SE
HNS" COND
1 12 "STRMADMIN"."SOURCE_ QUEUE SPILL RATE .00 MESSAGES PER SE
HNS" COND
1 13 "STRMADMIN"."SOURCE_ PROPAGATION BANDWIDTH 32992.96 BYTES PER SECON
HNS"=>"STRMADMIN"."D SENDER D
ESTINATION_SPOKE1"@H
UB.EXAMPLE.COM
1 13 "STRMADMIN"."SOURCE_ PROPAGATION EVENT: CPU + Wa 35.96 PERCENT
HNS"=>"STRMADMIN"."D SENDER it for CPU
ESTINATION_SPOKE1"@H
UB.EXAMPLE.COM
1 13 "STRMADMIN"."SOURCE_ PROPAGATION EVENT: SQL*Net .26 PERCENT
HNS"=>"STRMADMIN"."D SENDER message to dbli
ESTINATION_SPOKE1"@H nk
UB.EXAMPLE.COM
1 13 "STRMADMIN"."SOURCE_ PROPAGATION EVENT: latch: r .26 PERCENT
HNS"=>"STRMADMIN"."D SENDER ow cache object
ESTINATION_SPOKE1"@H s
UB.EXAMPLE.COM
1 13 "STRMADMIN"."SOURCE_ PROPAGATION LATENCY 4.00 SECONDS
HNS"=>"STRMADMIN"."D SENDER
ESTINATION_SPOKE1"@H
UB.EXAMPLE.COM
1 13 "STRMADMIN"."SOURCE_ PROPAGATION SEND RATE 2568.00 MESSAGES PER SE
HNS"=>"STRMADMIN"."D SENDER COND
ESTINATION_SPOKE1"@H
UB.EXAMPLE.COM
1 16 CAPTURE_HNS CAPTURE CAPTURE RATE 10464.00 MESSAGES PER SE
COND
1 16 CAPTURE_HNS CAPTURE ENQUEUE RATE 10002.00 MESSAGES PER SE
COND
1 16 CAPTURE_HNS CAPTURE EVENT: CPU + Wa 11.02 PERCENT
it for CPU
1 16 CAPTURE_HNS CAPTURE EVENT: CPU + Wa 35.96 PERCENT
it for CPU
1 16 CAPTURE_HNS CAPTURE EVENT: SQL*Net 5.51 PERCENT
message from db
link
1 16 CAPTURE_HNS CAPTURE LATENCY 2.65 SECONDS
.
.
.
Note:
This output is for illustrative purposes only. Actual performance characteristics vary depending on individual configurations and conditions.You can analyze this output along with the output for the queries in "Viewing the Oracle Streams Components at Each Database" and "Viewing Each Stream Path in an Oracle Streams Topology".
See Also:
"Gathering Information About the Oracle Streams Topology and Performance" for information about running the ANALYZE_CURRENT_PERFORMANCE procedure to gather statistics
"Message Processing Options for an Apply Process" for information about apply handlers
You can view session-level statistics for the Oracle Streams components. The query in this section displays the following information for each session-level statistic:
The name of the Oracle Streams component
The type of the Oracle Streams component. The following types are possible:
CAPTURE for capture processes
PROPAGATION SENDER for propagation senders
PROPAGATION RECEIVER for propagation receivers
APPLY for apply processes
The type of the subcomponent. Only capture processes, apply processes have subcomponents.
The following subcomponent types are possible for capture processes:
LOGMINER READER for a builder server of a capture process
LOGMINER PREPARER for a preparer server of a capture process
LOGMINER BUILDER for a reader server of a capture process
CAPTURE SESSION for a capture process session
The following subcomponent types are possible for apply processes:
PROPAGATION SENDER+RECEIVER for sending LCRs from a capture process directly to an apply process in a combined capture and apply optimization
APPLY READER for a reader server
APPLY COORDINATOR for a coordinator process
APPLY SERVER for a reader server
The statistic that was gathered for the component
The value and unit of the statistic. Session-level statistics show PERCENT for the unit. The value is the percentage of time spent either IDLE, paused for FLOW CONTROL, or waiting for an EVENT.
The ANALYZE_CURRENT_PERFORMANCE procedure in the DBMS_STREAMS_ADVISOR_ADM package gathers the statistics returned by the query in this section. Therefore, the statistics returned by the query were the current statistics when the procedure was run. The statistics are not updated automatically.
Table 23-4 describes each of the statistics that can be returned by the query in this section:
Table 23-4 Session-Level Statistics for Oracle Streams Components
| Statistic | Unit | Description |
|---|---|---|
|
|
|
The percentage of time that the session spent idle. When a session is idle, it is not performing any work. |
|
|
|
The percentage of time that the session was paused for flow control. See "Capture Process States" for information about flow control. |
|
|
|
The percentage of time that the session spent waiting because of a wait event. The Oracle Streams Performance Advisor only gathers information about the top three events for each session. For example, an apply server might wait for a dependent transaction to be applied before applying its transaction. |
Regarding flow control and event statistics, the time period is calculated as the time difference between the two snapshots used by the ANALYZE_CURRENT_PERFORMANCE procedure in the same user session. See "About the Information Gathered by the Oracle Streams Performance Advisor" for information about the snapshots. When a user session ends, the flow control and event statistics are purged.
To display session-level performance statistics for the components in an Oracle Streams topology, run the following query:
COLUMN PATH_ID HEADING 'Path|ID' FORMAT 999
COLUMN COMPONENT_ID HEADING 'Component|ID' FORMAT 999
COLUMN COMPONENT_NAME HEADING 'Component|Name' FORMAT A20
COLUMN COMPONENT_TYPE HEADING 'Component|Type' FORMAT A10
COLUMN SUB_COMPONENT_TYPE HEADING 'Subcomponent|Type' FORMAT A17
COLUMN STATISTIC_NAME HEADING 'Statistic' FORMAT A15
COLUMN STATISTIC_VALUE HEADING 'Value' FORMAT 999.99
COLUMN STATISTIC_UNIT HEADING 'Unit' FORMAT A7
SELECT DISTINCT
cp.PATH_ID,
cs.COMPONENT_ID,
cs.COMPONENT_NAME,
cs.COMPONENT_TYPE,
cs.SUB_COMPONENT_TYPE,
cs.STATISTIC_NAME,
cs.STATISTIC_VALUE,
cs.STATISTIC_UNIT
FROM DBA_STREAMS_TP_COMPONENT_STAT cs,
(SELECT PATH_ID, SOURCE_COMPONENT_ID AS COMPONENT_ID
FROM DBA_STREAMS_TP_COMPONENT_LINK
UNION
SELECT PATH_ID, DESTINATION_COMPONENT_ID AS COMPONENT_ID
FROM DBA_STREAMS_TP_COMPONENT_LINK) cp
WHERE cs.ADVISOR_RUN_ID=2 AND
cs.SESSION_ID IS NOT NULL AND
cs.SESSION_SERIAL# IS NOT NULL AND
cs.COMPONENT_ID = cp.COMPONENT_ID
ORDER BY PATH_ID, COMPONENT_ID, COMPONENT_NAME, COMPONENT_TYPE, STATISTIC_NAME;
This example uses 2 for the ADVISOR_RUN_ID in the WHERE clause. Substitute the advisor run ID for the advisor run you want to query. See "Gathering Information About the Oracle Streams Topology and Performance" for information about determining the ADVISOR_RUN_ID.
The following output shows a partial list of the session-level performance statistics for the components listed in "Viewing the Oracle Streams Components at Each Database". Specifically, the following output shows session-level performance statistics for the components in stream path 1 and stream path 3:
Path Component Component Component Subcomponent
ID ID Name Type Type Statistic Value Unit
---- --------- -------------------- ---------- ----------------- --------------- ------- -------
1 6 "STRMADMIN"."SOURCE_ PROPAGATIO EVENT: CPU + Wa 32.55 PERCENT
HNS"@SPOKE1.EXAMPLE. N RECEIVER it for CPU
COM=>"STRMADMIN"."DE
STINATIO N_SPOKE1"
1 6 "STRMADMIN"."SOURCE_ PROPAGATIO EVENT: SQL*Net 23.62 PERCENT
HNS"@SPOKE1.EXAMPLE. N RECEIVER more data from
COM=>"STRMADMIN"."DE client
STINATION_SPOKE1"
1 6 "STRMADMIN"."SOURCE_ PROPAGATIO EVENT: latch: r 2.10 PERCENT
HNS"@SPOKE1.EXAMPLE. N RECEIVER ow cache object
COM=>"STRMADMIN"."DE s
STINATION_SPOKE1"
1 6 "STRMADMIN"."SOURCE_ PROPAGATIO FLOW CONTROL .89 PERCENT
HNS"@SPOKE1.EXAMPLE. N RECEIVER
COM=>"STRMADMIN"."DE
STINATION_SPOKE1"
1 6 "STRMADMIN"."SOURCE_ PROPAGATIO IDLE 36.61 PERCENT
HNS"@SPOKE1.EXAMPLE. N RECEIVER
COM=>"STRMADMIN"."DE
STINATION_SPOKE1"
1 8 APPLY_SPOKE1 APPLY APPLY READER EVENT: CPU + Wa .26 PERCENT
it for CPU
1 8 APPLY_SPOKE1 APPLY APPLY SERVER EVENT: CPU + Wa 23.10 PERCENT
it for CPU
1 8 APPLY_SPOKE1 APPLY APPLY SERVER EVENT: latch: r 1.31 PERCENT
ow cache object
s
1 8 APPLY_SPOKE1 APPLY APPLY READER EVENT: latch: s .26 PERCENT
hared pool
1 8 APPLY_SPOKE1 APPLY APPLY SERVER EVENT: latch: s 1.57 PERCENT
hared pool
1 8 APPLY_SPOKE1 APPLY APPLY COORDINATOR FLOW CONTROL .00 PERCENT
1 8 APPLY_SPOKE1 APPLY APPLY READER FLOW CONTROL 10.76 PERCENT
1 8 APPLY_SPOKE1 APPLY APPLY SERVER FLOW CONTROL .00 PERCENT
1 8 APPLY_SPOKE1 APPLY APPLY COORDINATOR IDLE 6.21 PERCENT
1 8 APPLY_SPOKE1 APPLY APPLY READER IDLE 9.24 PERCENT
1 8 APPLY_SPOKE1 APPLY APPLY SERVER IDLE 8.53 PERCENT
1 13 "STRMADMIN"."SOURCE_ PROPAGATIO EVENT: CPU + Wa 21.65 PERCENT
HNS"=>"STRMADMIN"."D N SENDER it for CPU
ESTINATION_SPOKE1"@H
UB.EXAMPLE.COM
1 13 "STRMADMIN"."SOURCE_ PROPAGATIO EVENT: SQL*Net .26 PERCENT
HNS"=>"STRMADMIN"."D N SENDER message to dbli
ESTINATION_SPOKE1"@H nk
UB.EXAMPLE.COM
1 13 "STRMADMIN"."SOURCE_ PROPAGATIO EVENT: latch: r .26 PERCENT
HNS"=>"STRMADMIN"."D N SENDER ow cache object
ESTINATION_SPOKE1"@H s
UB.EXAMPLE.COM
1 13 "STRMADMIN"."SOURCE_ PROPAGATIO EVENT: latch: s .26 PERCENT
HNS"=>"STRMADMIN"."D N SENDER hared pool
ESTINATION_SPOKE1"@H
UB.EXAMPLE.COM
1 13 "STRMADMIN"."SOURCE_ PROPAGATIO FLOW CONTROL 7.37 PERCENT
HNS"=>"STRMADMIN"."D N SENDER
ESTINATION_SPOKE1"@H
UB.EXAMPLE.COM
1 13 "STRMADMIN"."SOURCE_ PROPAGATIO IDLE 67.41 PERCENT
HNS"=>"STRMADMIN"."D N SENDER
ESTINATION_SPOKE1"@H
UB.EXAMPLE.COM
1 16 CAPTURE_HNS CAPTURE LOGMINER READER EVENT: ARCH wai .26 PERCENT
t on c/f tx acq
uire 2
1 16 CAPTURE_HNS CAPTURE CAPTURE SESSION EVENT: CPU + Wa 35.96 PERCENT
it for CPU
1 16 CAPTURE_HNS CAPTURE LOGMINER BUILDER EVENT: CPU + Wa .26 PERCENT
it for CPU
1 16 CAPTURE_HNS CAPTURE LOGMINER PREPARER EVENT: CPU + Wa 11.02 PERCENT
it for CPU
1 16 CAPTURE_HNS CAPTURE LOGMINER READER EVENT: CPU + Wa .26 PERCENT
it for CPU
1 16 CAPTURE_HNS CAPTURE CAPTURE SESSION EVENT: SQL*Net 5.51 PERCENT
message from db
link
1 16 CAPTURE_HNS CAPTURE CAPTURE SESSION EVENT: SQL*Net .26 PERCENT
message to dbli
nk
1 16 CAPTURE_HNS CAPTURE CAPTURE SESSION EVENT: latch: r .26 PERCENT
ow cache object
s
1 16 CAPTURE_HNS CAPTURE LOGMINER BUILDER EVENT: latch: r 1.84 PERCENT
ow cache object
s
1 16 CAPTURE_HNS CAPTURE LOGMINER PREPARER EVENT: latch: r .79 PERCENT
ow cache object
s
1 16 CAPTURE_HNS CAPTURE CAPTURE SESSION EVENT: latch: s .26 PERCENT
hared pool
1 16 CAPTURE_HNS CAPTURE LOGMINER READER EVENT: latch: s .79 PERCENT
hared pool
1 16 CAPTURE_HNS CAPTURE CAPTURE SESSION FLOW CONTROL 16.27 PERCENT
1 16 CAPTURE_HNS CAPTURE LOGMINER BUILDER FLOW CONTROL .00 PERCENT
1 16 CAPTURE_HNS CAPTURE LOGMINER PREPARER FLOW CONTROL .00 PERCENT
1 16 CAPTURE_HNS CAPTURE LOGMINER READER FLOW CONTROL .00 PERCENT
1 16 CAPTURE_HNS CAPTURE CAPTURE SESSION IDLE 41.47 PERCENT
1 16 CAPTURE_HNS CAPTURE LOGMINER BUILDER IDLE 97.90 PERCENT
1 16 CAPTURE_HNS CAPTURE LOGMINER PREPARER IDLE 88.19 PERCENT
1 16 CAPTURE_HNS CAPTURE LOGMINER READER IDLE 98.69 PERCENT
.
.
.
3 4 "STRMADMIN"."SOURCE_ PROPAGATIO FLOW CONTROL 6.50 PERCENT
HNS"=>"STRMADMIN"."D N SENDER
ESTINATION_SPOKE1"@S
POKE1.EXAMPLE.COM
3 4 "STRMADMIN"."SOURCE_ PROPAGATIO IDLE 70.50 PERCENT
HNS"=>"STRMADMIN"."D N SENDER
ESTINATION_SPOKE1"@S
POKE1.EXAMPLE.COM
3 10 CAPTURE_HNS CAPTURE CAPTURE SESSION EVENT: ARCH wai 52.23 PERCENT
t for archivelo
g lock
3 10 CAPTURE_HNS CAPTURE CAPTURE SESSION EVENT: CPU + Wa 7.35 PERCENT
it for CPU
3 10 CAPTURE_HNS CAPTURE CAPTURE SESSION EVENT: control .52 PERCENT
file sequential
read
3 10 CAPTURE_HNS CAPTURE CAPTURE SESSION FLOW CONTROL 4.24 PERCENT
3 10 CAPTURE_HNS CAPTURE CAPTURE SESSION IDLE 2.23 PERCENT
3 14 "STRMADMIN"."SOURCE_ PROPAGATIO EVENT: CPU + Wa 6.92 PERCENT
HNS"@HUB.EXAMPLE.COM N RECEIVER it for CPU
=>"STRMADMIN"."DESTI
NATION_SPOKE1"
3 14 "STRMADMIN"."SOURCE_ PROPAGATIO EVENT: latch: r 2.23 PERCENT
HNS"@HUB.EXAMPLE.COM N RECEIVER ow cache object
=>"STRMADMIN"."DESTI s
NATION_SPOKE1"
3 14 "STRMADMIN"."SOURCE_ PROPAGATIO EVENT: library 3.79 PERCENT
HNS"@HUB.EXAMPLE.COM N RECEIVER cache: mutex X
=>"STRMADMIN"."DESTI
NATION_SPOKE1"
3 14 "STRMADMIN"."SOURCE_ PROPAGATIO FLOW CONTROL .67 PERCENT
HNS"@HUB.EXAMPLE.COM N RECEIVER
=>"STRMADMIN"."DESTI
NATION_SPOKE1"
3 14 "STRMADMIN"."SOURCE_ PROPAGATIO IDLE 85.04 PERCENT
HNS"@HUB.EXAMPLE.COM N RECEIVER
=>"STRMADMIN"."DESTI
NATION_SPOKE1"
3 15 APPLY_SPOKE1 APPLY APPLY COORDINATOR EVENT: latch: r 4.20 PERCENT
ow cache object
s
3 15 APPLY_SPOKE1 APPLY APPLY COORDINATOR EVENT: latch: s .52 PERCENT
hared pool
3 15 APPLY_SPOKE1 APPLY APPLY READER EVENT: latch: s .26 PERCENT
hared pool
3 15 APPLY_SPOKE1 APPLY APPLY COORDINATOR FLOW CONTROL .00 PERCENT
3 15 APPLY_SPOKE1 APPLY APPLY READER FLOW CONTROL 1.56 PERCENT
3 15 APPLY_SPOKE1 APPLY APPLY SERVER FLOW CONTROL .00 PERCENT
3 15 APPLY_SPOKE1 APPLY APPLY COORDINATOR IDLE 87.28 PERCENT
3 15 APPLY_SPOKE1 APPLY APPLY READER IDLE 96.88 PERCENT
3 15 APPLY_SPOKE1 APPLY APPLY SERVER IDLE 91.29 PERCENT
Note:
This output is for illustrative purposes only. Actual performance characteristics vary depending on individual configurations and conditions.
You can view the session ID and serial number for each session by adding the SESSION_ID and SESSION_SERIAL# columns to the query on the DBA_STREAMS_TP_COMPONENT_STAT view.
See Also:
"Capture Process Components" for more information about capture process subcomponents
"Apply Process Components" for more information about apply process subcomponents
The query in this section shows the following information for each stream path in the Oracle Streams topology:
Whether optimization mode for Oracle Streams is used for the path. When the OPTIMIZATION_MODE statistic is greater than 0 (zero) for a path, the path uses the combined capture and apply optimization. When the OPTIMIZATION_MODE statistic is 0 (zero) for a path, the path does not use the combined capture and apply optimization.
The MESSAGE RATE value is the average number of messages sent each second from the start of the path to the end of the path.
The TRANSACTION RATE value is the average number of transactions sent each second from the start of the path to the end of the path.
The time period for these statistics is calculated as the time difference between the two snapshots used by the ANALYZE_CURRENT_PERFORMANCE procedure in the same user session. See "About the Information Gathered by the Oracle Streams Performance Advisor" for information about the snapshots. When a user session ends, these statistics are purged.
To display this information, run the following query:
COLUMN PATH_ID HEADING 'Path ID' FORMAT 999
COLUMN STATISTIC_NAME HEADING 'Statistic' FORMAT A25
COLUMN STATISTIC_VALUE HEADING 'Value' FORMAT 99999999.99
COLUMN STATISTIC_UNIT HEADING 'Unit' FORMAT A25
SELECT PATH_ID,
STATISTIC_NAME,
STATISTIC_VALUE,
STATISTIC_UNIT
FROM DBA_STREAMS_TP_PATH_STAT
WHERE ADVISOR_RUN_ID=2
ORDER BY PATH_ID, STATISTIC_NAME;
This example uses 2 for the ADVISOR_RUN_ID in the WHERE clause. Substitute the advisor run ID for the advisor run you want to query. See "Gathering Information About the Oracle Streams Topology and Performance" for information about determining the ADVISOR_RUN_ID.
The following output shows the path statistics for the stream paths listed in "Viewing Each Stream Path in an Oracle Streams Topology":
Path ID Statistic Value Unit
------- ------------------------- ------------ -------------------------
1 OPTIMIZATION_MODE 1.00 NUMBER
1 MESSAGE RATE 10004.00 MESSAGES PER SECOND
1 TRANSACTION RATE 100.00 TRANSACTIONS PER SECOND
2 OPTIMIZATION_MODE 1.00 NUMBER
2 MESSAGE RATE 10028.25 MESSAGES PER SECOND
2 TRANSACTION RATE 100.37 TRANSACTIONS PER SECOND
3 OPTIMIZATION_MODE 1.00 NUMBER
3 MESSAGE RATE 9623.20 MESSAGES PER SECOND
3 TRANSACTION RATE 97.10 TRANSACTIONS PER SECOND
4 OPTIMIZATION_MODE 1.00 NUMBER
4 MESSAGE RATE 10180.05 MESSAGES PER SECOND
4 TRANSACTION RATE 102.68 TRANSACTIONS PER SECOND
Note:
This output is for illustrative purposes only. Actual performance characteristics vary depending on individual configurations and conditions.The UTL_SPADV package provides subprograms to collect and analyze statistics for the Oracle Streams components in a distributed database environment. The package uses the Oracle Streams Performance Advisor to gather statistics.
The COLLECT_STATS and START_MONITORING procedures use the Oracle Streams Performance Advisor to gather statistics about the Oracle Streams components and subcomponents in a distributed database environment. The SHOW_STATS procedure generates output that includes the statistics. The output is formatted so that it can be imported into a spreadsheet easily and analyzed.
You can use the COLLECT_STATS procedure to collect statistics each time the procedure is called. The comp_stat_table and path_stat_table parameters specify the tables that store the performance statistics. By default, these tables are STREAMS$_ADVISOR_COMP_STAT and STREAMS$_ADVISOR_PATH_STAT, respectively.
You can also use the START_MONITORING procedure to create a monitoring job that monitors Oracle Streams performance continually at specified intervals. The monitoring job uses the COLLECT_STATS procedure to collect statistics. The START_MONITORING procedure populates the STREAMS$_PA_MONITORING table, and the SHOW_STATS_TABLE column in this table specifies the table that contains the performance statistics. You can use the ALTER_MONITORING procedure to modify a monitoring job, and you can use the STOP_MONITORING procedure to stop a monitoring job.
These procedures collect the same statistics as the Oracle Streams Performance Advisor. These statistics are described in Table 23-3, "Component-Level Statistics for Oracle Streams Components" and Table 23-4, "Session-Level Statistics for Oracle Streams Components".
This section contains these topics:
Collecting Oracle Streams Statistics Using the UTL_SPADV Package
Checking Whether an Oracle Streams Monitoring Job Is Currently Running
Showing Oracle Streams Statistics Using the UTL_SPADV Package
See Also:
Oracle Database PL/SQL Packages and Types Reference for more information about theUTL_SPADV packageTo collect statistics using the UTL_SPADV package, complete the following steps:
Identify the database that you will use to gather the information. An administrative user at this database must meet the following requirements:
The user must have access to a database link to each database that contains Oracle Streams components that you want to monitor.
The user must have been granted privileges using the DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE procedure, and each database link must connect to a user at the remote database that has been granted privileges using the DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE procedure.
If you configure an Oracle Streams administrator at each database with Oracle Streams components, then the Oracle Streams administrator has the necessary privileges. See Oracle Streams Replication Administrator's Guide for information about creating an Oracle Streams administrator.
If no database in your environment meets these requirements, then choose a database, configure the necessary database links, and grant the necessary privileges to the users before proceeding.
In SQL*Plus, connect to the database you identified in Step 1 as a user that meets the requirements listed in Step 1.
See Oracle Database Administrator's Guide for information about connecting to a database in SQL*Plus.
Run the utlspadv.sql script in the rdbms/admin directory in ORACLE_HOME to load the UTL_SPADV package. For example:
@utlspadv.sql
Either collect the current Oracle Streams performance statistics once, or create a job that continually monitors Oracle Streams performance:
To collect the current Oracle Streams performance statistics once, run the COLLECT_STATS procedure:
exec UTL_SPADV.COLLECT_STATS
This example uses the default values for the parameters in the COLLECT_STATS procedure. Therefore, this example runs the Performance Advisor 10 times with 60 seconds between each run. These values correspond with the default values for the num_runs and interval parameters, respectively, in the COLLECT_STATS procedure.
To create a job that continually monitors Oracle Streams performance:
exec UTL_SPADV.START_MONITORING
This example creates a monitoring job, and the monitoring job gathers performance statistics continually at set intervals. This example uses the default values for the parameters in the START_MONITORING procedure. Therefore, this example runs the Performance Advisor every 60 seconds. This value corresponds with the default value for the interval parameter in the START_MONITORING procedure. If an interval is specified in the START_MONITORING procedure, then the specified interval is used for the interval parameter in the COLLECT_STATS procedure.
These procedures include several parameters that you can use to adjust the way performance statistics are gathered. See Oracle Database PL/SQL Packages and Types Reference for more information.
You can show the statistics by running the SHOW_STATS procedure. See "Showing Oracle Streams Statistics Using the UTL_SPADV Package".
See Also:
Oracle Database PL/SQL Packages and Types Reference for more information about theUTL_SPADV packageTo check whether a monitoring job is running using the UTL_SPADV package, complete the following steps:
Connect to the database as the user who submitted the monitoring job.
Run the IS_MONITORING function. For example, to determine whether a monitoring job submitted the current user with the full monitoring job name of STREAM$_MONITORING_JOB is running, enter the following:
SET SERVEROUTPUT ON
DECLARE
is_mon BOOLEAN;
BEGIN
is_mon := UTL_SPADV.IS_MONITORING(
job_name => 'STREAMS$_MONITORING_JOB',
client_name => NULL);
IF is_mon=TRUE THEN
DBMS_OUTPUT.PUT_LINE('The monitoring job is running.');
ELSE
DBMS_OUTPUT.PUT_LINE('No monitoring job was found.');
END IF;
END;
/
The output displays the following text if a monitoring job with the specified full monitoring job name is currently running:
The monitoring job is running.
The output displays the following text if no monitoring job with the specified full monitoring job name is currently running:
No monitoring job was found.
Note:
When you submit a monitoring job, the client name and job name are concatenated to form the full monitoring job name. The client name for a monitoring job submitted by Oracle Enterprise Manager is alwaysEM.To alter a monitoring job using the UTL_SPADV package, complete the following steps:
Create a monitoring job if you have not done so already by completing the steps described in "Collecting Oracle Streams Statistics Using the UTL_SPADV Package". Ensure that you run the START_MONITORING procedure in Step 4.
Connect to the database as the user who submitted the monitoring job. Only the user who submitted a monitoring job can alter the monitoring job, and each user can submit only one monitoring job at a time.
Run the ALTER_MONITORING procedure. The following example sets the interval for the monitoring job to 120 seconds:
BEGIN
UTL_SPADV.ALTER_MONITORING(
interval => 120);
END;
/
After running this procedure, the monitoring job gathers statistics every 120 seconds.
To stop a monitoring job using the UTL_SPADV package, complete the following steps:
Connect to the database as the user who submitted the monitoring job. Only the user who submitted a monitoring job can stop the monitoring job, and each user can submit only one monitoring job at a time.
Run the STOP_MONITORING procedure:
exec UTL_SPADV.STOP_MONITORING
The STOP_MONITORING procedure includes a purge parameter that you can use to purge the statistics gathered by the monitoring job from the result tables. By default, the purge parameter is set to FALSE, and the results are retained. Set the purge parameter to TRUE to purge the results.
See Also:
See Oracle Database PL/SQL Packages and Types Reference for more information.The SHOW_STATS procedure displays the statistics that the Performance Advisor gathered and stored. Use the path_stat_table parameter to specify the table that contains the statistics.
When you gather statistics using the COLLECT_STATS procedure, this table is specified in the path_stat_table parameter in the COLLECT_STATS procedure. By default, the table name is STREAMS$_ADVISOR_PATH_STAT.
When you gather statistics using the START_MONITORING procedure, you can determine the name for this table by querying the SHOW_STATS_TABLE column in the STREAMS$_PA_MONITORING view. The default table for a monitoring job is STREAMS$_PA_SHOW_PATH_STAT.
To show statistics collected using the UTL_SPADV package and stored in the STREAMS$_ADVISOR_PATH_STAT table, complete the following steps:
Collect statistics by completing the steps described in "Collecting Oracle Streams Statistics Using the UTL_SPADV Package".
Connect to the database as the user who collected the statistics.
If you are using a monitoring job, then query the SHOW_STATS_TABLE column in the STREAMS$_PA_MONITORING view to determine the name of this table that stores the statistics:
SELECT SHOW_STATS_TABLE FROM STREAMS$_PA_MONITORING;
Run the SHOW_STATS procedure.
For example, if you are using a monitoring job and the default storage table, then run the following procedure:
SET SERVEROUTPUT ON SIZE 50000
BEGIN
UTL_SPADV.SHOW_STATS(
path_stat_table => 'STREAMS$_PA_SHOW_PATH_STAT');
END;
/
The output includes the following legend:
LEGEND
<statistics>= <capture> [ <queue> <psender> <preceiver> <queue> ] <apply>
<bottleneck>
<capture> = '|<C>' <name> <msgs captured/sec> <msgs enqueued/sec> <latency>
'LMR' <idl%> <flwctrl%> <topevt%> <topevt>
'LMP' (<parallelism>) <idl%> <flwctrl%> <topevt%> <topevt>
'LMB' <idl%> <flwctrl%> <topevt%> <topevt>
'CAP' <idl%> <flwctrl%> <topevt%> <topevt>
'CAP+PS' <msgs sent/sec> <bytes sent/sec> <latency> <idl%>
<flwctrl%> <topevt%> <topevt>
<apply> = '|<A>' <name> <msgs applied/sec> <txns applied/sec> <latency>
'PS+PR' <idl%> <flwctrl%> <topevt%> <topevt>
'APR' <idl%> <flwctrl%> <topevt%> <topevt>
'APC' <idl%> <flwctrl%> <topevt%> <topevt>
'APS' (<parallelism>) <idl%> <flwctrl%> <topevt%> <topevt>
<queue> = '|<Q>' <name> <msgs enqueued/sec> <msgs spilled/sec> <msgs in
queue>
<psender> = '|<PS>' <name> <msgs sent/sec> <bytes sent/sec> <latency> <idl%>
<flwctrl%> <topevt%> <topevt>
<preceiver> = '|<PR>' <name> <idl%> <flwctrl%> <topevt%> <topevt>
<bottleneck>= '|<B>' <name> <sub_name> <sessionid> <serial#> <topevt%> <topevt>
The following table describes the abbreviations used in the legend:
| Abbreviation | Description |
|---|---|
A |
Apply process |
APC |
Coordinator process used by an apply process |
APR |
Reader server used by an apply process |
APS |
Apply server used by an apply process |
B |
Bottleneck |
C or CAP |
Capture process |
CAP+PS |
Capture process session and propagation sender in a combined capture and apply optimization |
CCA |
Combined capture and apply (Y indicates that it is used for the path; N indicates that it is not used for the path.) |
flwctrl |
Flow control |
idl |
Idle |
LMB |
Builder server used by a capture process (LogMiner builder) |
LMP |
Preparer server used by a capture process (LogMiner preparer) |
LMR |
Reader server used by a capture process (LogMiner reader) |
msgs |
Messages |
preceiver or PR |
Propagation receiver |
psender or PS |
Propagation sender |
PS+PR |
Propagation sender and propagation receiver in a combined capture and apply optimization in which the capture process and apply process are running on the same database instance |
Q |
Queue |
serial# |
Session serial number |
sec |
Second |
sid |
Session identifier |
sub_name |
Subcomponent name |
topevt |
Top event |
The following is sample output for when an apply process is the last component in a path:
OUTPUT PATH 1 RUN_ID 3 RUN_TIME 2009-JUL-02 05:59:38 CCA Y |<C> DB2$CAP 10267 10040 3 LMR 95% 0% 3.3% "" LMP (1) 86.7% 0% 11.7% "" LMB 86.7% 0% 11.7% "" CAP 71.7% 16.7% 11.7% "" |<Q> "STRMADMIN"."DB2$CAPQ" 2540.45 0 30 |<PS> =>DB1.EXAMPLE.COM 2152.03 32992.96 4 59.2% 9.8% 0% "" |<PR> DB2.EXAMPLE.COM=> 98.5% 0% 0.6% "" |<Q> "STRMADMIN"."DB2$APPQ" 3657.03 0.01 460 |<A> APPLY$_DB2_2 10042 100 4 APR 93.3% 0% 6.7% "" APC 98.1% 0% 1.8% "" APS (4) 370% 0% 6.1% "" |<B> NO BOTTLENECK IDENTIFIED PATH 1 RUN_ID 4 RUN_TIME 2009-JUL-02 06:01:39 CCA Y |<C> DB2$CAP 10464 10002 3 LMR 95% 0% 1.7% "" LMP (1) 83.3% 0% 16.7% "" LMB 85% 0% 15% "" CAP 62.9% 0% 35.7% "" |<Q> "STRMADMIN"."DB2$CAPQ" 2677.03 0.01 45 |<PS> =>DB1.EXAMPLE.COM 2491.08 47883.46 4 65.5% 10.7% 0% "" |<PR> DB2.EXAMPLE.COM=> 0% 83.3% 13.3% "" |<Q> "STRMADMIN"."DB2$APPQ" 2444.03 0.01 0 |<A> APPLY$_DB2_2 10004 100 3 APR 42.9% 57.1% 0% "" APC 90% 0% 10% "" APS (4) 346% 0% 10.3% "" |<B> NO BOTTLENECK IDENTIFIED . . .
Note:
This output is for illustrative purposes only. Actual performance characteristics vary depending on individual configurations and conditions.Use the legend and the abbreviations to determine the statistics in the output. For example, the following output is for the db2$cap capture process in path 1, run ID 3:
|<C> DB2$CAP 10267 10040 3 LMR 95% 0% 3.3% "" LMP (1) 86.7% 0% 11.7% "" LMB 86.7% 0% 11.7% "" CAP 71.7% 16.7% 11.7% ""
This output shows the following statistics:
The capture process captured an average of 10267 database changes each second.
The capture process enqueued an average of 10040 messages each second.
The capture process latency was 3 seconds.
The reader server (LMR) used by the capture process spent 95% of its time idle.
The reader server used by the capture process spent 0% of its time in flow control mode.
The reader server used by the capture process spent 3.3% of its time on the top wait event.
The preparer server (LMP) parallelism was 1.
The preparer server used by the capture process spent 86.7% of its time idle.
The preparer server used by the capture process spent 0% of its time in flow control mode.
The preparer server used by the capture process spent 11.7% of its time on the top wait event.
The builder server (LMB) used by the capture process spent 86.7% of its time idle.
The builder server used by the capture process spent 0% of its time in flow control mode.
The builder server used by the capture process spent 11.7% of its time on the top wait event.
The capture process session spent 71.7% of its time idle.
The capture process session spent 16.7% of its time in flow control mode.
The capture process session spent 11.7% of its time on the top wait event.
|
 Copyright © 2002, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|