ORA-16198: LGWR received timedout error from KSR

简介:
ORA-16198: LGWR received timedout error from KSR
ORA-16198 意味着主库上的LOG_ARCHIVE_DEST_2的NET_TIMEOUT设置的太小,导致LNS不能在设置的时间内将日志传输到备库。
解决方法是提高NET_TIMEOUT的值到15-20 秒,
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);
但是查看数据库中的NET_TIMEOUT 值的设置。
09:33:47 ops$admin@rac1>select DEST_NAME,NET_TIMEOUT FROM V$ARCHIVE_DEST;
DEST_NAME                 NET_TIMEOUT
------------------------- -----------
LOG_ARCHIVE_DEST_1                  0
LOG_ARCHIVE_DEST_2                 30
LOG_ARCHIVE_DEST_3                 30

NET_TIMEOUT 为30 秒。查看metalink :
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).
不过也有可能是bug
Bug 9259587  Multiple LGWR reconnect attempts in Data Guard MAXIMUM_AVAILABILITY
 This note gives a brief overview bug 9259587. 
Affects:
Product (Component) Oracle Server (Rdbms)
Range of versions believed to be affected Versions BELOW 12.1
Versions confirmed as being affected 11.2.0.1 10.2.0.4
Platforms affected Generic (all / most platforms affected)
Fixed:
This issue is fixed in 12.1 (Future Release) 11.2.0.2 (Server Patch Set)
Symptoms:
Related To:
Hang (Process Spins)
Active Dataguard (ADG)
Physical Standby Database / Dataguard
Description

In a Data Guard configuration using LGWR SYNC transport on one or more LOG_ARCHIVE_DEST_n parameters, and using a protection mode of MAXIMUM_AVAILABILITY, then if the primary database becomes disconnected from the standby database, LGWR continues to attempt to reconnect to the standby database. It should instead avoid attempts to reconnect until an ARCH process has re-established communication with the standby database.
 
Rediscovery Notes:
 Alert log contains messages like:
  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
  Errors in file 
  /app/oracle/diag/rdbms/ora11g_dga/ora11g/trace/ora11g_lgwr_290838.trc:
  ORA-16198: Timeout incurred on internal channel during remote archival
  LGWR: Network asynch I/O wait error 16198 log 2 service 'ora11g_DGb'
  LGWR: Error 16198 disconnecting from destination LOG_ARCHIVE_DEST_2 standby 
  host 'ora11g_DGb'
  Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
  LGWR: Failed to archive log 2 thread 1 sequence 1422 (16198)
相关文章
|
Oracle 关系型数据库 数据库
实战篇:Oracle 数据坏块的 N 种修复方式
实战篇:Oracle 数据坏块的 N 种修复方式
实战篇:Oracle 数据坏块的 N 种修复方式
|
Oracle 关系型数据库 Linux
redhat kmod
ASMLib Downloads for Red Hat Enterprise Linux
5811 4
|
8月前
|
Oracle 关系型数据库 Java
【YashanDB知识库】Flink CDC实时同步Oracle数据到崖山
本文介绍通过Flink CDC实现Oracle数据实时同步至崖山数据库(YashanDB)的方法,支持全量与增量同步,并涵盖新增、修改和删除的DML操作。内容包括环境准备(如JDK、Flink版本等)、Oracle日志归档启用、用户权限配置、增量日志记录设置、元数据迁移、Flink安装与配置、生成Flink SQL文件、Streampark部署,以及创建和启动实时同步任务的具体步骤。适合需要跨数据库实时同步方案的技术人员参考。
【YashanDB知识库】Flink CDC实时同步Oracle数据到崖山
|
存储 关系型数据库 MySQL
MySQL - 聚簇索引和非聚簇索引
MySQL - 聚簇索引和非聚簇索引
543 0
|
关系型数据库 MySQL
mysqldump unknown variable ‘set-gtid-purged=off‘ workbench
mysqldump unknown variable ‘set-gtid-purged=off‘ workbench
586 1
|
SQL 关系型数据库 Shell
pgbench 的使用命令
pgbench 是 PostgreSQL 的一个基准测试工具,用于评估数据库的性能。以下是一些常用的 pgbench 命令和选项: 初始化测试环境: bash Copy code pgbench -i -s [scale] [database_name] 其中 -i 用于初始化数据库,-s 指定比例因子,[database_name] 是要测试的数据库名。比例因子决定了数据的总量,例如 -s 10。 执行基准测试: bash Copy code pgbench -c [clients] -j [jobs] -t [transactions] [database_name] 其中 -
300 0
|
前端开发 关系型数据库 MySQL
OceanBase数据库常见问题之bootstrap时报错如何解决
OceanBase 是一款由阿里巴巴集团研发的企业级分布式关系型数据库,它具有高可用、高性能、可水平扩展等特点。以下是OceanBase 数据库使用过程中可能遇到的一些常见问题及其解答的汇总,以帮助用户更好地理解和使用这款数据库产品。
|
存储 Linux
|
Linux
clockdiff-检测两台linux主机的时间差
clockdiff-检测两台linux主机的时间差
496 0
|
SQL 安全 数据库
SQL Server附加数据库的方法,及出现错误的解决办法(错误:5123)
SQL Server附加数据库的方法,及出现错误的解决办法(错误:5123)

热门文章

最新文章