赞
踩
配置adg casscade如下日志报错:原因是log_file_name_convert配置不对引起。
配置参考:http://blog.sina.com.cn/s/blog_14d5a51a90102w27o.html
Sat Jul 13 11:49:23 2019
Errors in file /oracle/diag/rdbms/pri/pri/trace/pri_lgwr_3457.trc:
ORA-00314: log 3 of thread 1, expected sequence# 18 doesn't match 0
ORA-00312: online log 3 thread 1: '/oracle/oradata/pri/redo03.log'
Errors in file /oracle/diag/rdbms/pri/pri/trace/pri_lgwr_3457.trc:
ORA-00314: log 3 of thread 1, expected sequence# 18 doesn't match 0
ORA-00312: online log 3 thread 1: '/oracle/oradata/pri/redo03.log'
LGWR (ospid: 3457): terminating the instance due to error 314
Sat Jul 13 11:49:24 2019
System state dump requested by (instance=1, osid=3457 (LGWR)), summary=[abnormal instance termination].
System State dumped to trace file /oracle/diag/rdbms/pri/pri/trace/pri_diag_3447_20190713114924.trc
Dumping diagnostic data in directory=[cdmp_20190713114924], requested by (instance=1, osid=3457 (LGWR)), summary=[abnormal instance termination].
Instance terminated by LGWR, pid = 3457
Trace file /u01/app/oracle/diag/rdbms/orac/orac/trace/orac_arc0_4507.trc
Oracle Database 11g Release 11.2.0.4.0 - 64bit Production
ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_2
System name: Linux
Node name: rsb
Release: 2.6.32-754.el6.x86_64
Version: #1 SMP Tue Jun 19 21:26:04 UTC 2018
Machine: x86_64
VM name: VMWare Version: 6
Instance name: orac
Redo thread mounted by this instance: 1
Oracle process number: 21
Unix process pid: 4507, image: oracle@rsb (ARC0)
*** 2019-07-12 01:18:49.214
*** SESSION ID:(63.5) 2019-07-12 01:18:49.214
*** CLIENT ID:() 2019-07-12 01:18:49.214
*** SERVICE NAME:(SYS$BACKGROUND) 2019-07-12 01:18:49.214
*** MODULE NAME:() 2019-07-12 01:18:49.214
*** ACTION NAME:() 2019-07-12 01:18:49.214
Initial buffer sizes: read 1024K, overflow 832K, change 805K
Log read is SYNCHRONOUS though disk_asynch_io is enabled!
krsu_upi_atc: attempt to attach to non-AvM remote destination when Managed
*** 2019-07-12 01:25:47.631
Standby feature tag has not been enabled
Error 439 attaching to destination LOG_ARCHIVE_DEST_2 standby host 'stb1'
*** 2019-07-12 01:25:47.631 2917 krsi.c
krsi_dst_fail: dest:2 err:439 force:0 blast:1
kcrrwkx: unknown error:439
[rsb@oracle:/u01/app/oracle/diag/rdbms/orac/orac/trace]$
Error 16058 attaching RFS server to standby instance at host 'stb1'
Error 16058 attaching to destination LOG_ARCHIVE_DEST_2 standby host 'stb1'
*** 2019-07-12 01:11:59.035 4329 krsh.c
PING[ARC2]: Heartbeat failed to connect to standby 'stb1'. Error is 16058.
*** 2019-07-12 01:11:59.035 2917 krsi.c
krsi_dst_fail: dest:2 err:16058 force:0 blast:1
*** 2019-07-12 01:17:47.473
krsu_upi_atc: attempt to attach to non-AvM remote destination when Managed
Standby feature tag has not been enabled
Error 439 attaching to destination LOG_ARCHIVE_DEST_2 standby host 'stb1'
*** 2019-07-12 01:17:47.473 4329 krsh.c
PING[ARC2]: Heartbeat failed to connect to standby 'stb1'. Error is 439.
*** 2019-07-12 01:17:47.473 2917 krsi.c
krsi_dst_fail: dest:2 err:439 force:0 blast:1
krsu_upi_atc: attempt to attach to non-AvM remote destination when Managed
*** 2019-07-12 01:24:47.592
Standby feature tag has not been enabled
Error 439 attaching to destination LOG_ARCHIVE_DEST_2 standby host 'stb1'
*** 2019-07-12 01:24:47.592 4329 krsh.c
PING[ARC2]: Heartbeat failed to connect to standby 'stb1'. Error is 439.
*** 2019-07-12 01:24:47.592 2917 krsi.c
krsi_dst_fail: dest:2 err:439 force:0 blast:1
--------------------------------------------------------------
突然想起来数据库是标准版的,不支持dataguard哦。折腾了一天,哎!
SQL> select * from v$version;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE 11.2.0.4.0 Production
TNS for Linux: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.0 - Production
企业版的显示会有:Enterprise 这个字眼。
另外核查选项:
SQL> select * from v$option;
PARAMETER VALUE
---------------------------------------------------------------- ----------------------------------------------------------------
Partitioning FALSE
Objects TRUE
Real Application Clusters FALSE
Advanced replication FALSE
Bit-mapped indexes FALSE
Connection multiplexing TRUE
Connection pooling TRUE
Database queuing TRUE
Incremental backup and recovery TRUE
Instead-of triggers TRUE
Parallel backup and recovery FALSE
PARAMETER VALUE
---------------------------------------------------------------- ----------------------------------------------------------------
Parallel execution FALSE
Parallel load TRUE
Point-in-time tablespace recovery FALSE
Fine-grained access control FALSE
Proxy authentication/authorization TRUE
Change Data Capture FALSE
Plan Stability TRUE
Online Index Build FALSE
Coalesce Index TRUE
Managed Standby FALSE
Materialized view rewrite FALSE
PARAMETER VALUE
---------------------------------------------------------------- ----------------------------------------------------------------
Database resource manager FALSE
Spatial FALSE
Automatic Storage Management FALSE
Export transportable tablespaces FALSE
Transparent Application Failover TRUE
Fast-Start Fault Recovery FALSE
Sample Scan TRUE
Duplexed backups FALSE
Java TRUE
OLAP Window Functions TRUE
Block Media Recovery FALSE
PARAMETER VALUE
---------------------------------------------------------------- ----------------------------------------------------------------
Fine-grained Auditing FALSE
Application Role FALSE
Enterprise User Security FALSE
Oracle Data Guard FALSE
Oracle Label Security FALSE
OLAP FALSE
Basic Compression FALSE
Join index FALSE
Trial Recovery FALSE
Data Mining FALSE
Online Redefinition FALSE
PARAMETER VALUE
---------------------------------------------------------------- ----------------------------------------------------------------
Streams Capture FALSE
File Mapping FALSE
Block Change Tracking FALSE
Flashback Table FALSE
Flashback Database FALSE
Transparent Data Encryption FALSE
Backup Encryption FALSE
Unused Block Compression FALSE
Oracle Database Vault FALSE
Result Cache FALSE
SQL Plan Management FALSE
PARAMETER VALUE
---------------------------------------------------------------- ----------------------------------------------------------------
SecureFiles Encryption FALSE
Real Application Testing FALSE
Flashback Data Archive TRUE
DICOM TRUE
Active Data Guard FALSE
Server Flash Cache FALSE
Advanced Compression FALSE
XStream TRUE
Deferred Segment Creation FALSE
Data Redaction FALSE
65 rows selected.
------------------------------以下参考未解决---------------------
Oracle Database - Enterprise Edition - Version 9.2.0.1 to 12.1.0.2 [Release 9.2 to 12.1]
Information in this document applies to any platform.
***Checked for relevance on 20-Aug-2013***
***Checked for relevance on 26-OCT-2016***
The Purpose of this Document is to troubleshoot the generic Error
Heartbeat failed to connect to standby
in the Primary ALERT.LOG. It shows most common and possible Causes along with Solutions to get rid of this Problem.
The Errors in general look like this:
PING[ARCn]: Heartbeat failed to connect to standby '<Standby>'. Error is xxxxx
ORA-16191/ORA-1017
ORA-3135 :The Communication between the ARCn and the RFS-Process died unexpectedly
ORA-12514 : The Standby Database is down or the specified Service you want to connect to is not registered with Listener on the Standby Site
Many more Common errors described in this document.
Introduction
Once Log Transport Services from a Primary to a Standby Database are setup correctly and the Archive Destination is enabled and active, there will be a Heartbeat-Ping between the Primary and Standby Database. This Ping is being performed by a dedicated ARCn-Process on the Primary Database to an associated RFS-Process on the Standby. You can find out about this Process if you have a Look into the ALERT.LOG of the Primary Database and search for an Entry like this:
ARC1 started with pid=21, OS id=6585
...
ARC1: Becoming the heartbeat ARCH
-> In this Case we can find that ARC1 with pid 21 (OS-pid 6585) is the current Heartbeat ARCn-Process.
This Process tries to ping an associated RFS-Process on the Standby Database. If you look into the Standby ALERT.LOG you can find Entries like this:
RFS[2]: Assigned to RFS process 6621
RFS[2]: Identified database type as 'physical standby': Client is ARCH pid 6585
-> So here RFS-Process with OS-pid 6621 is the corresponding RFS-Process for the Heartbeat Ping
Note that this can be quite dynamic since RFS-Processes are created and terminated on Need.
If the Primary ARCn-Process is not able to reach a corresponding RFS-Process this Error is raised in the Primary ALERT.LOG together with the corresponding Reason.
Diagnosing Problems:
If the Heartbeat Ping fails you typically get an Error along with this Message in the following Section we discuss common Errors and how to solve them.
The Errors in general look like this:
PING[ARCn]: Heartbeat failed to connect to standby '<Standby>'. Error is xxxxx
General Points to verify first:
SQL> connect sys/<Password>@<Standby> as sysdba
-> if this succeeds then it's a Problem specific on the Database where if you get the same Error here there is a general (mostly Setup or Configuration) Problem
Here are common Errors and Solutions:
The Standby Database is down or the specified Service you want to connect to is not registered with Listener on the Standby Site.
- Verify the Standby Database is at least in mount-Status
- Ensure the Service used to connect by Log Transport Services is registered with the correct Listener
- Review the TNSNAMES.ORA and ensure the Connection Details (Host, Protocol and Port) are correct
The Log Transport Services cannot detect a Listener on the Destination
- Ensure the Listener is running
- Review the TNSNAMES.ORA and ensure the Connection Details (Host, Protocol and Port) are correct
- Verify in /etc/hosts-File the IP-Address given for the local Node where the Listener is running is defined with it's real IP-Address rather than the localhost Address (127.0.0.1) and it matches with the Listener IP-Address or Hostname Resolution
The given Connect Descriptor used for Log Transport Services cannot be resolved
- Ensure the TNS-Alias setup with log_archive_dest_n exists in the TNSNAMES.ORA and is valid (Spelling, Brackets,...)
- Try to manually connect to the Standby Database using the same TNS-Alias
- Verify if you modified the TNSNAMES.ORA since the Database ARCn and LNS-Processes started; they may not be aware of the Change. So you may have to kill those so that they get respawned again
The Communication between the ARCn and the RFS-Process died unexpectedly.
- Typical Cause are active Firewalls or Routers in the Network Connection between the Primary and Standby Database. Ensure there are no Features enabled on this Equipment which are able to modify TCP-Packets
- The Network is overloaded; ensure there is always sufficient Bandwith available to cope with the current Redo Generation Rate - also see
How To Calculate The Required Network Bandwidth Transfer Of Archivelogs In Dataguard Environments ( Note 736755.1)
for Calculation
The Log Transport Services cannot authenticate on the Standby Database
- Ensure Passwordfile has been transfered to the Standby Site correctly
- REMOTE_LOGIN_PASSWORDFILE is setup correct
- Review
Troubleshooting ORA-16191 and ORA-1017 in Data Guard Log Transport Services ( Note 1368170.1)
for further Troubleshooting
NOTE:799353.1 - How to Resolve Error in Remote Archiving
NOTE:1130523.1 - Logs are not shipped to the physical standby database
NOTE:1269749.1 - RFS-process on physical standby database fails with Ora-00600:[Kcrrrfswda.9], [4], [368], [], [], [], [], []
NOTE:736755.1 - How To Calculate The Required Network Bandwidth Transfer Of Redo In Data Guard Environments
NOTE:1368170.1 - Troubleshooting ORA-16191 and ORA-1017/ORA-1031 in Data Guard Log Transport Services or Data Guard Broker
-------------------------------------
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。