Skip to content

Goldengate

恢复被删除(损坏、丢失)的goldengate trailfile

恢复被删除(损坏、丢失)的goldengate trailfile

1.1恢复目标被删除(损坏、丢失)的trailfile

原理：根据目标端trailfile最后应用的scn来去源端找到准确位置后重传数据

测试方法:手动删除目标端的最后一个trail file后进行测试(并不是完全恢复这个文件,只是将删除文件中未应用的数据找出,产生包含丢失数据的文件而已)
关于trailfile存在源、目标方式:
1、源端、目标拥有独立的trailfile.extract抽取后经过datapump传输到目标端
2、源端、目标共享trailfile.extract抽取被replicat进程直接读取.这种不需要配置datapump,这种情形使用不如第一种情形多.

测试场景:
采用第一种,源端和目标端都是拥有独立的trailfile.是否想过源、目的trailfile文件大小或文件个数能否对应上,恢复直接从源端复制过来就可以使用?

具体如下.
Ex开头是源端,dp是目标端.初步对比来看个数以及文件大小都存在差异，初步设想不成功.

操作步骤:
1、先停止目标端的replicat进程.
2、源端：对一个空表插入100条数据.然后手动rename目标端未应用的trailfile一个.
验证源端数据:

SQL> select count(*) from leo_rows;
COUNT(*)
----------
100

验证目标端数据:

SQL> select count(*) from leo_rows;
COUNT(*)
----------
0

通过这个信息对比,发现2边数据不同步.
3、rename目标端未应用的trailfile。例如dp000014变成dp000014.old
mv dp000014 dp000014.old
4、根据目标端分析上次成功checkpoint信息位置找出目标端实际应用位置.
从checkpoint信息中查出实际应用到位置是extseqno=14、extrba=8751283.
但是此时dp000014文件已经丢失(只是rename而已).10g以后版本trailfile记录csn信息，不需要通过@genenv(“ORATRANSACTION”,”SCN”)强制写个token到trailfile.SCN是指Oracle transaction id的对应数值.可以通过Oracle v$transaction视图查询.查看进程的checkpoint里面记录了

CSN stateinformation:
CRC: 55-A2-8E-E4
Latest CSN: 1963641—这个就是对应Oraclescn.
Latest TXN: 10.23.846 –这个是transactionid
Latest CSN of finished TXNs: 1963641:这里面提示已经完成.不如此事务是不完整的,需要从重新同步这个事物.
Completed TXNs: 10.23.846
GGSCI (ludatou) 4> inforepleo showch
REPLICAT REPLEO Last Started 2014-04-22 20:27 Status STOPPED
Checkpoint Lag 00:00:00 (updated 00:09:17 ago)
Log Read Checkpoint File ./dirdat/dp000014
2014-04-22 20:32:05.801351 RBA 8751283
Current Checkpoint Detail:
Read Checkpoint #1
GGS Log Trail
Startup Checkpoint (starting position in thedata source):
Sequence #: 14
RBA: 8748614
Timestamp: 2014-04-22 13:01:47.962664
Extract Trail: ./dirdat/dp
Current Checkpoint (position of last recordread in the data source):
Sequence #: 14
RBA: 8751283
Timestamp: 2014-04-22 20:32:05.801351
Extract Trail: ./dirdat/dp
CSN state information:
CRC: 55-A2-8E-E4
Latest CSN: 1963641
Latest TXN: 10.23.846
Latest CSN of finished TXNs: 1963641
Completed TXNs: 10.23.846
Header:
Version = 2
Record Source = A
Type = 1
# Input Checkpoints = 1
# Output Checkpoints = 0
File Information:
Block Size = 2048
Max Blocks = 100
Record Length = 2048
Current Offset = 0
Configuration:
Data Source = 0
Transaction Integrity = -1
Task Type = 0
Database Checkpoint:
Checkpoint table = goldengate.ogg_checkpoint
Key = 296275922 (0x11a8cfd2)
Create Time = 2014-04-22 07:56:50
Status:
Start Time = 2014-04-22 20:27:58
Last Update Time = 2014-04-22 20:37:41
Stop Status = G
Last Result = 400

从上述看已经最后被应用的事务信息包括如下:
1、 csn=1963641
2、 TXN=10.23.846
根据如上信息登陆源端系统找到对应trailfile的rba信息.然后根据这个位置，重新修改datapump从这个位置传输trailfile到目标端.

开始恢复数据:
登陆源端主机:

[ludatou ~]$ cd $OGG
[ludatou112101]$cd dirdat
[ludatoudirdat]$ ls -lrt
total 126000
-rw-rw-rw- 1oracle oinstall 15198 Apr 27 12:24ex000000
-rw-rw-rw- 1oracle oinstall 9999850 Apr 27 12:28 ex000001
-rw-rw-rw- 1oracle oinstall 9999928 Apr 27 12:28 ex000002
-rw-rw-rw- 1oracle oinstall 9999824 Apr 27 12:33 ex000003
-rw-rw-rw- 1oracle oinstall 9999838 Apr 27 12:33 ex000005
-rw-rw-rw- 1oracle oinstall 9999495 Apr 27 12:33 ex000004
-rw-rw-rw- 1oracle oinstall 9999904 Apr 27 12:33 ex000007
-rw-rw-rw- 1oracle oinstall 9999928 Apr 27 12:33 ex000006
-rw-rw-rw- 1oracle oinstall 9999863 Apr 27 12:41 ex000010
-rw-rw-rw- 1oracle oinstall 9999714 Apr 27 12:41 ex000009
-rw-rw-rw- 1oracle oinstall 9999792 Apr 27 12:41 ex000008
-rw-rw-rw- 1oracle oinstall 9999867 Apr 27 12:44 ex000012
-rw-rw-rw- 1oracle oinstall 9999804 Apr 27 12:44 ex000011
-rw-rw-rw- 1oracle oinstall 8762807 Apr 27 21:01 ex000013

从根据目标段的时间来源端寻找时机最靠近的trailfile.即ex000013是第一选择,如果对应csn信息不在000013,则相前反向推找.

[ludatou dirdat]$ cd $OGG
[ludatou 112101]$./logdump –使用logdump对trailfile进行操作
Logdump 236>open ./dirdat/ex000013
Current LogTrailis /goldengate/112101/dirdat/ex000013
Logdump 237>ghdr on
Logdump 238>detail data
Logdump 239>usertoken detail
Logdump 240>ggstoken detail
Logdump 241>filter include csn = 1963641 --来自目标端的csn
Logdump 242>n --查看满足条件的数据
Scanned 10000 records, RBA 3160036, 2014/04/27 12:44:51.000.000
Scanned 20000 records, RBA 6320505, 2014/04/27 12:44:51.000.000
___________________________________________________________________
Hdr-Ind : E (x45) Partition : . (x00)
UndoFlag : . (x00) BeforeAfter: A (x41)
RecLength : 1204 (x04b4) IO Time : 2014/04/27 20:53:21.000.000
IOType : 160 (xa0) OrigNode : 0 (x00)
TransInd : . (x03) FormatType : R (x52)
SyskeyLen : 0 (x00) Incomplete : . (x00)
AuditRBA : 0 AuditPos : 0
Continued : N (x00) RecCount : 1 (x01)
2014/04/2720:53:21.000.000 DDLOP Len 1204 RBA 8749251
Name:
After Image: Partition 0 G s
2c43 353d 2732 3533 3127 2c2c 4237 3d27 32353331 | ,C5='2531',,B7='2531
272c 2c42 323d 2727 2c2c 4233 3d27 4c45 4f272c2c | ',,B2='',,B3='LEO',,
4234 3d27 4c45 4f5f 524f 5753 272c 2c43 31323d27 | B4='LEO_ROWS',,C12='
272c 2c43 3133 3d27 272c 2c42 353d 2754 41424c45 | ',,C13='',,B5='TABLE
272c 2c42 363d 2743 5245 4154 4527 2c2c 42383d27 | ',,B6='CREATE',,B8='
474f 4c44 454e 4741 5445 2e47 4753 5f44 444c5f48 | GOLDENGATE.GGS_DDL_H
4953 5427 2c2c 4239 3d27 4c45 4f27 2c2c 43373d27 | IST',,B9='LEO',,C7='
GGS tokens:
TokenID x52 'R'ORAROWID Info x00 Length 20
4141 4156 5849 4141 4541 4141 4146 6741 41460001 | AAAVXIAAEAAAAFgAAF..
TokenID x44 'D'DDL Info x00 Length 36
4c45 4f00 4c45 4f5f 524f 5753 0031 312e 322e302e | LEO.LEO_ROWS.11.2.0.
342e 3000 3131 2e32 2e30 2e34 2e30 004e | 4.0.11.2.0.4.0.N
TokenID x4c 'L'LOGCSN Info x00 Length 7
3139 3633 3634 31 | 1963641 –与目标csn符合
TokenID x36 '6'TRANID Info x00 Length 9
3130 2e32 332e 3834 36 | 10.23.846 –与目标tranid符合
Filteringsuppressed 27661 records

根据上述信息已经找到目标端应用的数据信息.
Datapump需要从满足条件下一条记录开始传输.所以继续输入N捕获下一条数据信息的rba
但是输入N却发现没有任何数据返回,是到达文件结尾了吗?根据判断这个属于中间数据.经过分析发现，原来是filter include csn = 1963641搞的鬼.现在清楚这个过滤条件.根据下面输出可以获得正确rba信息是:

Logdump 243 >n
Filteringsuppressed 100 records
Logdump 244>filter clear
Logdump 246>pos 8749251 –来自上面的rba信息,是目标端已经应用的数据.
Reading forwardfrom RBA 8749251
Logdump 247>n –表示输出这个数据的详细信息.下n才是我们需要的数据
___________________________________________________________________
Hdr-Ind : E (x45) Partition : . (x00)
UndoFlag : . (x00) BeforeAfter: A (x41)
RecLength : 1204 (x04b4) IO Time : 2014/04/27 20:53:21.000.000
IOType : 160 (xa0) OrigNode : 0 (x00)
TransInd : . (x03) FormatType : R (x52)
SyskeyLen : 0 (x00) Incomplete : . (x00)
AuditRBA : 0 AuditPos : 0
Continued : N (x00) RecCount : 1 (x01)
2014/04/2720:53:21.000.000 DDLOP Len 1204 RBA 8749251
Name:
After Image: Partition 0 G s
2c43 353d 2732 3533 3127 2c2c 4237 3d27 32353331 | ,C5='2531',,B7='2531
272c 2c42 323d 2727 2c2c 4233 3d27 4c45 4f272c2c | ',,B2='',,B3='LEO',,
4234 3d27 4c45 4f5f 524f 5753 272c 2c43 31323d27 | B4='LEO_ROWS',,C12='
272c 2c43 3133 3d27 272c 2c42 353d 2754 41424c45 | ',,C13='',,B5='TABLE
272c 2c42 363d 2743 5245 4154 4527 2c2c 4238 3d27| ',,B6='CREATE',,B8='
474f 4c44 454e 4741 5445 2e47 4753 5f44 444c5f48 | GOLDENGATE.GGS_DDL_H
4953 5427 2c2c 4239 3d27 4c45 4f27 2c2c 43373d27 | IST',,B9='LEO',,C7='
GGS tokens:
TokenID x52 'R'ORAROWID Info x00 Length 20
4141 4156 5849 4141 4541 4141 4146 6741 41460001 | AAAVXIAAEAAAAFgAAF..
TokenID x44 'D'DDL Info x00 Length 36
4c45 4f00 4c45 4f5f 524f 5753 0031 312e 322e302e | LEO.LEO_ROWS.11.2.0.
342e 3000 3131 2e32 2e30 2e34 2e30 004e | 4.0.11.2.0.4.0.N
TokenID x4c 'L'LOGCSN Info x00 Length 7
3139 3633 3634 31 | 1963641
TokenID x36 '6'TRANID Info x00 Length 9
3130 2e32 332e 3834 36 | 10.23.846

Logdump 248>n --这里是正确的rba信息,同时判断这个条记录是否开始位置.根据transind后面数字x00表示是开始位置，同时也确认我们找的rba是正确的.否则就是错误的.
TransInd : . (x00) 表示记录开始位置
TransInd : . (x01) 表示记录中间位置
TransInd : . (x02) 表示记录结尾位置
TransInd : . (x03) 表示这个事务只有1条记录
___________________________________________________________________
Hdr-Ind : E (x45) Partition : . (x04)
UndoFlag : . (x00) BeforeAfter: A (x41)
RecLength : 31 (x001f) IO Time : 2014/04/27 21:01:11.000.000
IOType : 5 (x05) OrigNode : 255 (xff)
TransInd : . (x00) FormatType : R (x52)
SyskeyLen : 0 (x00) Incomplete : . (x00)
AuditRBA : 161 AuditPos : 11343376
Continued : N (x00) RecCount : 1 (x01)
2014/04/2721:01:11.000.000 Insert Len 31 RBA 8750598
NameEO.LEO_ROWS
After Image: Partition 4 G b
0000 0005 0000 0001 3100 0100 0700 0000 036c656f | ........1........leo
0002 0007 0000 0003 3130 30 | ........100
Column 0 (x0000), Len 5 (x0005)
0000 0001 31 | ....1
Column 1 (x0001), Len 7 (x0007)
0000 0003 6c65 6f | ....leo
Column 2(x0002), Len 7 (x0007)
0000 0003 3130 30 | ....100
GGS tokens:
TokenID x52 'R'ORAROWID Info x00 Length 20
4141 4156 5976 4141 4541 4141 4146 3141 41410001 | AAAVYvAAEAAAAF1AAA..
TokenID x4c 'L'LOGCSN Info x00 Length 7
3139 3635 3636 33 | 1965663
TokenID x36 '6'TRANID Info x00 Length 8
382e 342e 3130 3638 | 8.4.1068

停止源端的pump，修改配置

Logdump 249>exit
[ludatou112101]$ ./ggsci
OracleGoldenGate Command Interpreter for Oracle
Version11.2.1.0.1 OGGCORE_11.2.1.0.1_PLATFORMS_120423.0230_FBO
Linux, x64,64bit (optimized), Oracle 11g on Apr 23 2012 08:32:14
Copyright (C)1995, 2012, Oracle and/or its affiliates. All rights reserved.
GGSCI (ludatou)1> info all
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING
EXTRACT RUNNING DPLEO 00:00:00 00:00:06
EXTRACT RUNNING EXTLEO 00:00:03 00:00:02
GGSCI (cifpay02)2> stop DPLEO
Sending STOPrequest to EXTRACT DPLEO ...
Requestprocessed.
GGSCI (ludatou)3> alter extract dpleo,extrba 8750598
EXTRACT altered.
GGSCI (cifpay02)4> info all
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING
EXTRACT STOPPED DPLEO 00:00:00 00:00:01
EXTRACT RUNNING EXTLEO 00:00:02 00:00:07
GGSCI (cifpay02)5> start dpleo
Sending STARTrequest to MANAGER ...
EXTRACT DPLEOstarting
GGSCI (ludatou)14> info all
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING
EXTRACT ABENDED DPLEO 00:00:00 00:02:38
EXTRACT RUNNING EXTLEO 00:00:02 00:00:07

从上面看到dumpabend，主要目标端dp000014被手动删除，导致dump传输数据无法lock trailfile，当目标端达到设置大小时候才会切换到下一个或者我们手动切换到下一个.下面手动切换dump从新文件开始写,即dp000015.其实dump指定写目标端extseqno.

GGSCI (cifpay02)15> alter DPLEO,etrollover
2014-04-2803:43:52 INFO OGG-01520 Rollover performed. For eachaffected output trail of Version 10 or higher format, after starting the sourceextract, issue ALTER EXTSEQNO for that trail's reader (either pump EXTRACT orREPLICAT) to move the reader's scan to the new trail file; it will not happen automatically.
EXTRACT altered.

目标端确认配置

GGSCI (ludatou)1> info all
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING
REPLICAT STOPPED REPLEO 00:00:00 06:56:12

因为dp000014已经不存在了，修改从dp000015开始读取.

GGSCI (cifpay01)2> shell ls -lrt ./dirdat/*
-rw-rw-rw- 1oracle oinstall 13135 May 2 10:08 ./dirdat/dp000000
-rw-rw-rw- 1oracle oinstall 3120 May 2 12:03 ./dirdat/dp000001
-rw-rw-rw- 1oracle oinstall 9999708 May 2 12:07./dirdat/dp000002
-rw-rw-rw- 1oracle oinstall 9999967 May 2 12:07./dirdat/dp000003
-rw-rw-rw- 1oracle oinstall 9999491 May 2 12:13./dirdat/dp000005
-rw-rw-rw- 1oracle oinstall 9999677 May 2 12:13./dirdat/dp000004
-rw-rw-rw- 1oracle oinstall 9999879 May 2 12:13./dirdat/dp000006
-rw-rw-rw- 1oracle oinstall 9999975 May 2 12:13./dirdat/dp000007
-rw-rw-rw- 1oracle oinstall 9999943 May 2 12:13./dirdat/dp000008
-rw-rw-rw- 1oracle oinstall 9999749 May 2 12:21./dirdat/dp000009
-rw-rw-rw- 1oracle oinstall 9999908 May 2 12:21./dirdat/dp000011
-rw-rw-rw- 1oracle oinstall 9999743 May 2 12:21./dirdat/dp000010
-rw-rw-rw- 1oracle oinstall 9999841 May 2 12:24./dirdat/dp000012
-rw-rw-rw- 1oracle oinstall 9999908 May 2 12:24./dirdat/dp000013
-rw-rw-rw- 1 oracleoinstall 8763492 May 2 20:40./dirdat/dp000014.old
-rw-rw-rw- 1oracle oinstall 13269 May 3 03:23 ./dirdat/dp000015
GGSCI (ludatou)4> alter REPLEO,extseqno 15,extrba 0
REPLICATaltered.
GGSCI (ludatou)5> start repleo
Sending STARTrequest to MANAGER ...
REPLICAT REPLEOstarting
GGSCI (ludatou)6> info all
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING
REPLICAT RUNNING REPLEO 00:00:00 00:00:09

目标端验证数据是否同步
经过查看源端leo_rows表中100条数据已经成功同步到目标端.由此可以确认恢复被删除的trailfile成功.

GGSCI (ludatou)8> stats REPLEO
Sending STATSrequest to REPLICAT REPLEO ...
Start ofStatistics at 2014-05-03 03:36:13.
Replicating fromLEO.LEO_ROWS to LEO.LEO_ROWS:
*** Totalstatistics since 2014-05-03 03:35:23 ***
Total inserts 100.00
Total updates 0.00
Total deletes 0.00
Total discards 0.00
Total operations 100.00
*** Dailystatistics since 2014-05-03 03:35:23 ***
Total inserts 100.00
Total updates 0.00
Total deletes 0.00
Total discards 0.00
Total operations 100.00
*** Hourlystatistics since 2014-05-03 03:35:23 ***
Total inserts 100.00
Total updates 0.00
Total deletes 0.00
Total discards 0.00
Total operations 100.00
*** Lateststatistics since 2014-05-03 03:35:23 ***
Total inserts 100.00
Total updates 0.00
Total deletes 0.00
Total discards 0.00
Total operations 100.00
End ofStatistics.

至此目标端被删除的trailfile中数据已经恢复成功.

Goldengate Oracle Oracle 排障配置与调整 数据技术 | Guang Cai Li |

浅谈ORA-12545 / TNS-12545故障诊断思路

前一个刚经历rac安装完后遭遇的ORA-12545错误，这里就顺便把这个错误的诊断思路理出来，毕竟这个错误在10g后还是比较常见，本文只是对这个故障的处理诊断思路做一些经验上的讨论，纯为有趣。

12545的报错提示为如下：

ORA-12545 / TNS-12545 Connect failed because target host or object does not exist

先往下聊吧，这类错误通常是和hostname相关配置不正确有关，举个例子

[ora10g@ludatou ~]$ tnsping lu10g
TNS Ping Utility for Linux: Version 10.2.0.4.0 - Production on 15-APR-2014 12:08:27
Copyright (c) 1997,  2007, Oracle.  All rights reserved.
Used parameter files:

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = ludatou)(PORT = 1523)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = lu10g)))
OK (10 msec)

[ora10g@ludatou ~]$ sqlplus luda/luda@lu10g
SQL*Plus: Release 10.2.0.4.0 - Production on Tue Apr 15 12:12:15 2014
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

=====这里我的tnsnames配置的解析主机名是ludatou，而且采用网络验证方式登录成功
[ora10g@ludatou ~]$ cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1               localhost.localdomain localhost
192.168.102.128         ludatou   luda
=====在这边我把/etc/hosts文件的主机名ludatou变更为ludatouxx,变更结果如下
[ora10g@ludatou ~]$ cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1               localhost.localdomain localhost
192.168.102.128         ludatouxx   luda

再次在客户端（另外一个主机）远程登录，在响应了很久之后报错

[root@ludatou ~]# su - oracle
[oracle@ludatou ~]$ sqlplus luda/luda@lu10g
SQL*Plus: Release 11.1.0.7.0 - Production on Tue Apr 15 12:13:40 2014
Copyright (c) 1982, 2008, Oracle.  All rights reserved.

ERROR:
ORA-12545 Connect failed because target host or object does not exist

下来以分类场景的方式来描述这类故障的诊断：
场景1：
当连接数据库不通过listener的时候，而是使用BEQ协议来连接数据库，这个时候如果$ORACLE_HOME/bin目录下oracle文件丢失或者损坏，用户执行权限不足，以及Oracle_home（多个安装版本）的路径设置错误的情况下，使用beq协议连接oracle的用户就会遭遇ORA/TNS-12545的错误。
关于BEQ协议可以参考如下解释：

This is the bequeth oracle process. The bequeth process starts first. Later all the processes related to particular database are controlled by its bequeth process.

场景2：
这个场景就是上面我所做的测试场景，由客户端通过listner连接服务端oracle数据库，这个时候如果客户端的tnsnames解析文件中对应service name部分的hostname和服务端的hostname不匹配，就会报错ora-12545.
在这个场景中可以使用nslookup命令来搜索对应的主机，按照上面的例子，这里使用nslookup命令搜索ludatou主机时候则会出现以下情况：

$ nslookup ludatou
Server: 192.168.102.128
Address: 192.168.1.102#53
** server can't find ludatou: ==>Indicates ludatou is not resolvable on the machine

这个场景的解决办法就是把客户端的tnsnames中的hostname部分写为ip，避免服务端主机名变更导致配置不符的情况出现。

场景3：
参考 RAC实施完遭遇ORA-12545

Cause: One of the hostname (which corresponds to public IP or VIP) is not reachable from this client machine.
When the server side load balancing is enabled in the RAC setup, the listener will redirect the connection to the least loaded node.While doing so, the server sends the packet NSPTRD containing the hostname of the corresponding machine.

The Remote Service Handler value registered with the remote Listener process via the REMOTE_LISTENER parameter is built by the LOCAL_LISTENER value on the local server.So, its necessary to check whether the local_listener / remote listener information are reflected properly in the listener services output as well.

Diagnosis:
Enable the oracle sqlnet client tracing at support level, and reproduce the issue.In the generated client trace, you would see the below information:
After NSPTCN Connect to the listener , listener sends

场景4：
listerner.ora的hostname配置错误，导致监听无法找寻到正确的监听地址，也会产生ora/tns-12545的错误。具体监听日志报错如下：

Error listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=abc)(PORT=1522)))
TNS-12545: Connect failed because target host or object does not exist
TNS-12560: TNS:protocol adapter error
TNS-00515: Connect failed because target host or object does not exist

如果打开了sqlnet的trace跟踪，可以发现类似如下的报错：

nsc2addr: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=abc)(PORT=1522)))
nttbnd2addr: entry
snlinGetAddrInfo: entry
snlinGetAddrInfo: Invalid IP address string abc
snlinFreeAddrInfo: entry
snlinFreeAddrInfo: exit
snlinGetAddrInfo: exit
nttbnd2addr: looking up IP addr for host: abc
snlinGetAddrInfo: entry
snlinGetAddrInfo: Name resolution failed for abc
snlinFreeAddrInfo: entry
snlinFreeAddrInfo: exit
snlinGetAddrInfo: exit
nttbnd2addr: *** hostname lookup failure! ***
nttbnd2addr: exit
nserror: entry
nserror: nsres: id=0, op=78, ns=12545, ns2=12560; nt[0]=515, nt[1]=0, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0

这类问题解决办法就是检测监听的配置是否和主机的ip，hostname配置吻合，不吻合的情况下会造成12545的错误。

场景5：
操作系统或者硬件问题也会导致产生ora/tns-12545的产生。
5.1windows 2000 with Service Pack 3 会导致这个ora/tns-12545 的产生
http://support.microsoft.com/default.aspx?scid=kb;en-us;329405
5.2Solaris系统在配置不正确情况下也会导致ora/tns-12545的产生

以上的场景描述是对1254错误的故障做一些分类分析，大概的诊断思路也是这样。

当然以上只是针对12545，oracle网络的错误有很多，对于诊断oracle网络错误，我个人的习惯诊断流程是如下
1.check listener.log确认是否有报错信息
2.check syslog是否有设备或者系统的报错信息
3.check $ORACLE_HOME/bin/oracle文件是否存在以及权限正确与否
4.check tnsnames,sqlnet,listener的配置是否与主机对应
5.在rac环境下，我会优先检查节点和client的通信情况，网络配置文件是否配置正确，最后才是taf和ld的影响
6.必要时候开启trace进一步跟踪详细信息

Database Dataguard Goldengate Grid and Cluster Oracle Oracle 排障配置与调整 浅谈oracle技术系列 | Guang Cai Li | |   snlinFreeAddrInfo TNS-12545故障诊断

浅谈Goldengate关于进程Lag延时大的优化

最近临时接手一个ogg的项目，前面的兄弟没处理好，算是临危而上了。当时是这种情况，ogg的初始化完成了，但是发现复制进程的延时有100多个小时，而且越积越多，但是进程还是在正常允许没有hang住，根据这个情况根据数据库和ogg的角度提出和执行了一些优化上的处理事宜，具体如下：

首先延时是一个相对的代表当前数据同步处理情况，相对主库运行时间段的一种判断，也是OGG提供给我们当前进行的工作进度展示，影响Goldnenate进程lag的因素有哪些？

具体我统计如下：

1.OGG bug，不能正常显示lag信息，由于时区设置不正确，或者本身程序等造成

2.OGG 源端抽取进程延时大，这个时候主要是取决与当前主机CPU,IO，在硬件（上述任1）资源达到超负荷时候，对抽取进程的处理就会挂起乃至延时，造成lag过大或者是显示不正确，或者是抽取开始的scn距离当前的主库scn有时间的差距。

3.OGG 源端传送进程延时大，这个时候主要是取决于主机的CPU,IO,NETWORK，在除了与2中的硬件资源有关之外，还跟OGG传送的网卡，生产到目的端网络情况（包括网络通信长度，网络繁忙度， 网络有效负荷等），生产与目的端防火墙对发送包的限制情况。

举些例子，如果你的日志量很大，但是你的网卡为百M网卡，你传送需求是20M/s，传送速率只有理论的10/S，这时候延时显而易见就出来了，你每秒就有10m的延时，相当于1s就积累1s的延时。
比如传输长度，光纤输出平均1公里增加延时1ms，这个时候比如吉林长春到北京亦庄的光纤是经过了1000公里，那么这里1000*0.001=1s，这是理论的情况下最小的延时。
再接着是防火墙，还有无线网络的考虑情况，这些跟网络传输环境息息相关的方面都需要考虑进去。
4.OGG 目标端lag很大，跟目标端的cpu，io有关，这个时候目标端的cpu压力主要来自于3方面：系统运行，数据库运行，OGG运行；IO压力主要来自于OGG以及数据库的日志写和读，那么repliact进程延时大了主要是什么情况？

    4.1.io不够，cpu够，你数据库有能力1秒能写200M数据，但是你存储io只能写100M，这个时候就积累延时了
    4.2.io够了，cpu不够，这个时候你也会发现有延时，因为你处理速度远远低于源端传过来的数据的速度，这个时候延时也就积累了
    4.3.io够了，cpu够了，这个时候你硬件很ok，但是你的延时很大，这个就是进程积累的日志过多；

数据库性能问题，OGG性能问题就和看病一样，需要对症下药，如果诊断错了，你开的药就错了，出现的结果就是病没治好，有可能身体本身器官负载还更大了.在这个项目中的情况，和我上述描述的症状对比起来，在多次诊断中，我比较倾向4.1，4.2，4.3的综合类型，就是目标端replicat应用日志的速度无法追上（4.1，4.2），而且在初始化完成后本身在目标端积累了过多的日志（4.3）。

那又怎么处理？对症下药。优化资源使用，提高数据库的处理速度是我们要做的事情。那么怎么处理？根据情况可以考虑下面的2种方式来做

一：提高目标端Oracle处理速度

1.关闭备库的日志补全级别，关闭备库的强制日志模式，减少redo产生，降低io。
2.置备库为noarchive（非归档模式），减少archive过程产生的io。
3.提高备库服务器的内存大小，为Oracle设置更大的buffer cache，shared pool，减少VMM控制的整体的换页频率所带来的对cpu和io的额外负荷。
4.确认异步IO是否开启。未开启的过程请打开服务器的aio，aix确认如下lsdev -Cc aio
5.提高PGA的大小，为多个的repliacat进程们提供足够的缓存区域。
6.对目标端ogg的接收源端发来的data文件 和 oracle本身的数据文件错开到不同的（存储级别）vg上面，以避免disk hot的情况出现，进而提高io效率
7.对无查询，存插入更新（全表）的对象的索引进行删除

二：从业务逻辑上拆分繁忙的延时大复制进程

角度1：工作量最小，但是统计会有一定误差

在局部进程延时大的时候，可能是这种情况，业务处理的核心压力都集中在一些对象上面，而这些对象都被安排设置到一个进程中，这个时候大部分的日志都集中在这个进程中，出现了这个进程很忙，其他进程很闲，类似多点闲单点热的情况，如果这个时候硬件资源满足情况下，可以从业务逻辑上去拆分这个进程，比如这次宋经理根据应用开发商的提供的表的更改频率表按照等级来拆分进程，按照表的繁忙度把热点表们平摊到2个进程中。而周五我的建议是全部平摊出去，这样效果才会明显，而根据文档显示宋经理已经按照应用商提供的将热点表全部平摊到各个进程中。
在这方面，我方从数据库角度提出建议，应用从业务角度划分出来的表可以从数据库对应DML操作的频率记录上进行check对应。因为存在一种情况，应用提供商提供的是表的操作频率，比如查询，更新，插入，删除都是在一起统计的，从细化上我们需要的表的更新，插入，删除方面的统计信息，这类信息可以通过oracle 实例中的ALL_TAB_MODIFICATIONS表进程查询数据库中所有对象的delete，insert，update的频率，根据频率高的进行排序，再对频率高的前100，或者200的表进行拆分，这样的效果可能会更理想，具体语句如下：

select TABLE_OWNER,TABLE_NAME,INSERTS,UPDATES,DELETES from ALL_TAB_MODIFICATIONS ORDER BY 3,4,5;

或者

select TABLE_OWNER,TABLE_NAME，INSERTS+UPDATES+DELETES "ALL_DML_COUNTS" from ALL_TAB_MODIFICATIONS ORDER BY 3;

角度2：工作量较大，但是统计效果精准

表的DML频率并无法估算到具体产生的redo量，理论上redo的产生量越大，对应的操作涉及的数据（比如表的字段多，数据量大）就越多，所以从这个角度上讲，我们是要找到redo量产生多的那些表，这种情况下就需要用到logmnr工作，通过对归档日志的挖掘分析，开对ogg的部署进行决策支持，在当前项目，这个角度比较不倾向实际，但是可以作为一个参考方向。

Goldengate Oracle 排障配置与调整 浅谈oracle技术系列 | Guang Cai Li | |   goldengate lag