Oracle DataGuard环境中主库收到ORA-16198报错怎么办

技术Oracle DataGuard环境中主库收到ORA-16198报错怎么办这篇文章主要为大家展示了“Oracle DataGuard环境中主库收到ORA-16198报错怎么办”,内容简而易懂,条理清晰,希望能够帮助大

这篇文章主要为大家展示了"甲骨文数据卫士环境中主库收到ORA-16198报错怎么办",内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让小编带领大家一起研究并学习一下"甲骨文数据卫士环境中主库收到ORA-16198报错怎么办"这篇文章吧。

客户的一套甲骨文活动数据卫士环境中,主库在每天的最高峰的时间段内都会收到如下的报错:Fri 4月24日17:25:59 2015 ora-16198: LGWR收到来自KSRLGWR:的timedout错误尝试目标日志_存档_DEST_2网络重新连接(16198)LGWR:目标日志_存档_DEST_2网络重新连接放弃将归档日志文件一的错误16198设置为“afabdg01”

参考如下的金属氧化物半导体(金属氧化物半导体)文章:Redo Transport Services fails with ORA-16198 when using SYNC (synchronous) mode (Doc ID 808469.1)

In this Document

症状原因解决方案参考

Applies to:

甲骨文数据库-企业版-版本10.2.0.1及更高版本

本文档中的信息适用于任何平台。

*** 2014年2月26日检查相关性* * *

这将影响10.2.0.x数据库中的LGWR同步传输模式和11.2.0.x数据库中的同步传输模式

Symptoms

重做传输服务失败,主数据库中出现ORA-16198

物理备用数据库或逻辑备用数据库

使用LGWR同步模式。

主警报日志文件显示:

2009年2月6日21:22:26

ORA-16198: LGWR收到来自键盘发送收系统(Keyboard Send/Receiver)的超时错误

LGWR:尝试目标日志_存档_DEST_2网络重新连接(16198)

LGWR:目标日志_存档_DEST_2网络重新连接被放弃

2009年2月6日21:22:26

文件/u01/app/Oracle/admin/crthpd 01/bdump/crthpd 01 _ lgwr _ 2793488。TRC :中的错误

ORA-16198:远程存档期间内部通道超时

网络异步输入/输出等待错误16198日志2服务

(描述=(地址列表=(地址=(协议=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 2 0 RSM detected log transport problem: log
transport for database 'xyz_STANDBY' has the following error.
DG 2009-04-12-12:12:08 0 2 0 ORA-16198: Timeout incurred on internal channel during remote archival
DG 2009-04-12-12:12:08 0 2 0 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/<sys password>

DGMGRL> EDIT DATABASE '<primary db_unique_name>' 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. 

    出现这个报错是由于在默认的NET_TIMEOUT时间(10秒)内主库LGWR进程没有将数据完整的发送到备库,可以将NET_TIMEOUT设置为15或者30秒来增加LGWR发送数据到备库的时间,减少出现这个问题的几率。如果NET_TIMEOUT设置为30秒仍然存在此问题,那么就需要考虑是否是主库到备库的网络存在性能问题或存在一定的故障,对于WAN外网的Standby数据库最好不要使用LGWR SYNC进行实时同步,使用ARC NSYNC同步更合适。

以上是“Oracle DataGuard环境中主库收到ORA-16198报错怎么办”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注行业资讯频道!

内容来源网络,如有侵权,联系删除,本文地址:https://www.230890.com/zhan/107936.html

(0)

相关推荐

  • 如何撤销fixed的效果(头部设置fixed后内容滚动)

    技术如何验证fixed关键字效果本篇文章为大家展示了如何验证fixed关键字效果,内容简明扼要并且容易理解,绝对能使你眼前一亮,通过这篇文章的详细介绍希望你能有所收获。之前谈到String连接操作的性能,其中会涉及到un

    攻略 2021年12月19日
  • 分析iOS中的实时远程配置全纪录

    技术分析iOS中的实时远程配置全纪录本篇内容介绍了“分析iOS中的实时远程配置全纪录”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够

    攻略 2021年11月4日
  • 5个常用的MySQL数据库管理工具是什么呢

    技术5个常用的MySQL数据库管理工具是什么呢这篇文章将为大家详细讲解有关5个常用的MySQL数据库管理工具是什么呢,文章内容质量较高,因此小编分享给大家做个参考,希望大家阅读完这篇文章后对相关知识有一定的了解。 MyS

    攻略 2021年12月1日
  • 如何理解MSSQL数据库后台进程

    技术如何理解MSSQL数据库后台进程本篇文章为大家展示了如何理解MSSQL数据库后台进程,内容简明扼要并且容易理解,绝对能使你眼前一亮,通过这篇文章的详细介绍希望你能有所收获。与Oracle数据库类似,微软数据库产品MS

    攻略 2021年11月29日
  • 怎么使用TFserving

    技术怎么使用TFserving这篇文章主要讲解了“怎么使用TFserving”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“怎么使用TFserving”吧!1.什么是TFs

    攻略 2021年11月13日
  • 如何用F#库天棚测试UI

    技术如何利用F#库canopy进行UI测试这篇文章将为大家详细讲解有关如何利用F#库canopy进行UI测试,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。InfoQ:你能否为我们介绍一

    攻略 2021年12月16日