首页 » ORACLE 9i-23c » ORA-12592: TNS:bad packet issue on Dataguard primary site
ORA-12592: TNS:bad packet issue on Dataguard primary site
今天刚搭建的一个Data guard环境，一开始在日志传输时遇到ora-12592错误，下面记录一下解决过程
oracle database 11.2.0.4 on OEL 5.8 single instance test environment
sys@PORA92>SELECT DEST_ID,STATUS,ERROR FROM V$ARCHIVE_DEST_STATUS;
DEST_ID STATUS ERROR
-------------------- --------- -----------------------------------------------------------------
1 VALID
2 ERROR ORA-12592: TNS:bad packet
primary database 检查归档状态时起初发现这个错误时而出报时而好，后再检查只有在重传某个日志时发现才会出现此问题.
查看alert log
ARC3: Standby redo logfile selected for thread 1 sequence 8 for destination LOG_ARCHIVE_DEST_2 LNS: Standby redo logfile selected for thread 1 sequence 9 for destination LOG_ARCHIVE_DEST_2 2014-02-19 13:56:08.402000 +08:00 ARC0: Standby redo logfile selected for thread 1 sequence 7 for destination LOG_ARCHIVE_DEST_2 2014-02-19 13:56:11.157000 +08:00 FAL[server, ARC0]: FAL archival, error 12592 closing archivelog file 'standbydb' FAL[server, ARC0]: FAL archive failed, see trace file. ARCH: FAL archive failed. Archiver continuing ORACLE Instance pora92 - Archival Error. Archiver continuing. 2014-02-19 13:56:57.239000 +08:00 ARC0: Standby redo logfile selected for thread 1 sequence 7 for destination LOG_ARCHIVE_DEST_2 2014-02-19 13:58:44.716000 +08:00 FAL[server, ARC0]: FAL archival, error 12592 closing archivelog file 'standbydb' FAL[server, ARC0]: FAL archive failed, see trace file. ARCH: FAL archive failed. Archiver continuing ORACLE Instance pora92 - Archival Error. Archiver continuing. 2014-02-19 14:02:13.864000 +08:00 ARC3: Standby redo logfile selected for thread 1 sequence 7 for destination LOG_ARCHIVE_DEST_2 FAL[server, ARC3]: FAL archival, error 12592 closing archivelog file 'standbydb' FAL[server, ARC3]: FAL archive failed, see trace file. ARCH: FAL archive failed. Archiver continuing ORACLE Instance pora92 - Archival Error. Archiver continuing. [oracle@dbserver92 pora92]$ ll total 29868 -rw-r----- 1 oracle oinstall 28686336 Feb 19 13:50 1_5_839935020.dbf -rw-r----- 1 oracle oinstall 112640 Feb 19 13:50 1_6_839935020.dbf -rw-r----- 1 oracle oinstall 376832 Feb 19 13:55 1_7_839935020.dbf -rw-r----- 1 oracle oinstall 48128 Feb 19 13:56 1_8_839935020.dbf -rw-r----- 1 oracle oinstall 1309696 Feb 19 14:07 1_9_839935020.dbf sys@PORA92>select name,dest_id,sequence# from v$archived_log order by 2,3; NAME DEST_ID SEQUENCE# --------------------------------------------- -------------------- -------------------- /backup/archlog/pora92/1_5_839935020.dbf 1 5 /backup/archlog/pora92/1_6_839935020.dbf 1 6 /backup/archlog/pora92/1_7_839935020.dbf 1 7 /backup/archlog/pora92/1_8_839935020.dbf 1 8 /backup/archlog/pora92/1_9_839935020.dbf 1 9 /backup/archlog/pora92/1_10_839935020.dbf 1 10 standbydb 2 5 standbydb 2 6 standbydb 2 8 standbydb 2 9 standbydb 2 10
NOTE:
看到确实是只有log sequence#7 传送时出现了此问题，通常日志传送失败如果没有设置MAX_FAILURE 或reopen 默认会无限制的尝试重传，如果当前重传失败跳过此日志文件继续传送下一下，等待几分钟再次重传，注意这里跳过日志传送的日志不会apply，因为考虑到事务的顺序会一直等到中间跳过的日志传送成功并应用后再apply.
那先检查一下standby site 日志7号文件是否真的未传
[oracle@dbserver58 archivelogs]$ ll
total 30252
-rw-r----- 1 oracle oinstall 770048 Feb 19 14:34 1_10_839935020.dbf
-rw-r----- 1 oracle oinstall 28686336 Feb 19 14:06 1_5_839935020.dbf
-rw-r----- 1 oracle oinstall 112640 Feb 19 14:06 1_6_839935020.dbf
-rw-r----- 1 oracle oinstall 48128 Feb 19 14:11 1_8_839935020.dbf
-rw-r----- 1 oracle oinstall 1309696 Feb 19 14:23 1_9_839935020.dbf
sys@PORA92>select process,status from v$managed_standby;
PROCESS STATUS
--------- ------------
ARCH CLOSING
ARCH CLOSING
ARCH CONNECTED
ARCH CLOSING
RFS IDLE
MRP0 APPLYING_LOG
sys@PORA92>select * from v$archive_gap;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
-------------------- -------------------- --------------------
1 7 7
sys@PORA92>select dest_id,thread#,sequence#,archived,applied,deleted,status from v$archived_log;
DEST_ID THREAD# SEQUENCE# ARC APPLIED DEL S
-------------------- -------------------- -------------------- --- --------- --- -
1 1 6 YES YES NO A
1 1 5 YES YES NO A
1 1 8 YES NO NO A
1 1 9 YES NO NO A
1 1 10 YES NO NO A
发现gap 就是7号文件，那我们可以手动把log 7# 从primary site 传到standby site，再register时数据库。
[oracle@dbserver92 ~]$ scp /backup/archlog/pora92/1_7_839935020.dbf 192.168.217.245:/flrvarea/SORA245/archivelogs/
oracle@192.168.217.245's password:
1_7_839935020.dbf 100% 368KB 368.0KB/s 00:00
SQL> alter database register logfile '/flrvarea/SORA245/archivelogs/1_7_839935020.dbf';
Database altered.
SQL> select * from v$archive_gap;
no rows selected
SQL> select dest_id,thread#,sequence#,archived,applied,deleted,status from v$archived_log;
DEST_ID THREAD# SEQUENCE# ARC APPLIED DEL S
---------- ---------- ---------- --- --------- --- -
1 1 6 YES YES NO A
1 1 5 YES YES NO A
1 1 8 YES YES NO A
1 1 9 YES YES NO A
1 1 10 YES IN-MEMORY NO A
0 1 7 YES YES NO A
Note:
手动注册后发现日志都已applited, 并且主库的日志传输也未再出现刚才的ora-12592。最后有个小技巧如果注册时的log文件较多，可以使用rman catalog 命令来批量注册节约我们的时间。
— end —
微信扫一扫，打赏作者吧～
对不起，这篇文章暂时关闭评论。