首页 » ORACLE » 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 —

打赏

,

对不起,这篇文章暂时关闭评论。