Shulou(Shulou.com)05/31 Report--

This article mainly shows you "what to do when the main library receives the ORA-16198 error report in the Oracle DataGuard environment", the content is simple and clear, and I hope it can help you solve your doubts. Let the editor lead you to study and learn "how to do when the main library receives the ORA-16198 error message in the Oracle DataGuard environment".

In a customer's Oracle Active DataGuard environment, the main database receives the following error message during the peak period of each day:

Fri Apr 24 17:25:59 2015

ORA-16198: LGWR received timedout error from KSR

LGWR: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (16198)

LGWR: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned

Error 16198 for archive log file 1 to 'afabdg01'

Refer to the following MOS article:

Redo Transport Services fails with ORA-16198 when using SYNC (synchronous) mode (Doc ID 808469.1)

In this Document

Symptoms

Cause

Solution

ReferencesApplies to:

Oracle Database-Enterprise Edition-Version 10.2.0.1 and later

Information in this document applies to any platform.

* Checked for relevance on 26 color FebMel 2014 payment *

This will affect LGWR SYNC transport mode in 10.2.0.x databases and SYNC transport mode in 11.2.0.x databases

Symptoms

Redo Transport Services failed with ORA-16198 from primary database to either the physical standby database or logical standby database using LGWR SYNC mode.

The primary alert log file showed:

Fri Feb 6 21:22:26 2009

ORA-16198: LGWR received timedout error from KSR

LGWR: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (16198)

LGWR: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned

Fri Feb 6 21:22:26 2009

Errors in file / u01/app/oracle/admin/crthpd01/bdump/crthpd01_lgwr_2793488.trc:

ORA-16198: Timeout incurred on internal channel during remote archival

LGWR: Network asynch wait error 16198 log 2 service'(DESCRIPTION= (ADDRESS_LIST= (ADDRESS= (PROTOCOL=tcp) (HOST=abc) (PORT=1521) (CONNECT_DATA= (SERVICE_NAME=xyz_STANDBY_XPT.world) (INSTANCE_NAME=xyz) (SERVER=dedicated)'

Fri Feb 6 21:22:26 2009

Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED

LGWR: Failed to archive log 2 thread 1 sequence 628 (16198)

Fri Feb 6 21:22:27 2009

If you use Data Guard Broker, then the primary drc log showed:

DG 2009-04-12-12:11:08 0 2 678445059 Operation CTL_GET_STATUS cancelled during phase 2, error = ORA-16778

DG 2009-04-12-12:12:08 0 20 RSM detected log transport problem: log transport for database 'xyz_STANDBY' has the following error.

DG 2009-04-12-12:12:08 0 20 ORA-16198: Timeout incurred on internal channel during remote archival

DG 2009-04-12-12:12:08 0 20 RSM0: HEALTH CHECK ERROR: ORA-16737: the redo transport service for standby database "xyz_STANDBY" has an error

DG 2009-04-12-12:12:08 0 2 678445062 Operation CTL_GET_STATUS cancelled during phase 2, error = ORA-16778

DG 2009-04-12-12:12:08 0 2 678445062 Operation CTL_GET_STATUS cancelled during phase 2, error = ORA-16778

Cause

The NET_TIMEOUT attribute in the LOG_ARCHIVE_DEST_2 on the primary is set too low so that

LNS couldn't finish sending redo block in 10 seconds in this example.

Log_archive_dest_2 service= "(DESCRIPTION= (ADDRESS_LIST= (ADDRESS= (PR))

OTOCOL=tcp) (HOST=abc) (PORT=1521) (CONNECT

_ DATA= (SERVICE_NAME=xyz_STANDBY_XPT.world) (

INSTANCE_NAME=xyz) (SERVER=dedicated) "

LGWR SYNC AFFIRM delay=0 OPTIONAL max_failure=0

Max_connections=1 reopen=300 db_unique_name= "

Xyz_STANDBY "register net_timeout=10 valid

_ for= (online_logfile,primary_role)

Noticed that you used LGWR SYNC log transport mode and NET_TIMEOUT was set to 10.

Solution

You'll need to increase the NET_TIMEOUT value in the LOG_ARCHIVE_DEST_2 on the primary to at least 15 to 20 seconds depends on your network speed.

If you don't use Data Guard Broker, then you could change LOG_ARCHIVE_DEST_2 from SQL*Plus using ALTER SYSTEM command. For example

SQL > ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 SERVICE=xyz_STANDBY

LGWR SYNC DB_UNIQUE_NAME=xyz_STANDBY NET_TIMEOUT=30 VALID_FOR= (ONLINE_LOGFILES,PRIMARY_ROLE)

If you use Data Guard Broker, then you will need to modify NetTimeout property from DGMGRL or Grid Control.

For example, connect to the DGMGRL command-line interface from the primary machine

DGMGRL > connect sys/

DGMGRL > EDIT DATABASE''SET PROPERTY NetTimeout = 30

=

Note: If NET_TIMEOUT attribute has already been set to 30, and you still get ORA-16198, that means

LNS couldn't finish sending redo block in 30 seconds.

The slowness may caused by:

1. Operating System. Please keep track of OS usage (like iostat).

2. Network. Please keep track network flow (like tcpdump).

Note: Please don't use SYNC log transport mode across a wide area network (WAN) with latencies above 10ms.

The purpose here is to figure out if the slowness is caused by temporary OS glitch or temporary network glitch.

This error occurs because the LGWR process of the main database does not send the complete data to the slave database within the default NET_TIMEOUT time (10 seconds). You can set NET_TIMEOUT to 15 or 30 seconds to increase the time it takes for LGWR to send data to the slave database and reduce the chance of this problem. If this problem still exists when NET_TIMEOUT is set to 30 seconds, then you need to consider whether there is a performance problem or some failure in the network from master database to slave database. For Standby databases in WAN public network, it is best not to use LGWR SYNC for real-time synchronization. ARC NSYNC synchronization is more appropriate.

These are all the contents of the article "what to do if the main library receives an error report from ORA-16198 in the Oracle DataGuard environment". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.