Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

2135

积分

502

好友

184

主题
1#
发表于 2012-6-1 22:50:30 | 查看: 7696| 回复: 1
Question   网友的邮件提问:


goldengate建在standby上的问题。下面总结一下我的具体过程。希望您能帮助看一下。谢谢。

Primary: 11.2.0.2 RAC(two nodes) on ASM
Physical standby: 11.2.0.2 单节点,非ASM, 采用standby redo log。
Goldengate: 11.1.1.1

Goldengate的extract是搭建在physical standby上的,原因是想尽可能少在主库上进行操作。其原始的参数文件如下:

extract e_ajiang
setenv (NLS_LANG=AMERICAN_AMERICA.ZHS16GBK)
userid ggs@racdb,password ggs     --racdb为standby上连接主库的tns连接符

tranlogoptions asmuser sys@+asm1, asmpassword oracle

REPORT AT 01:59
reportrollover at 02:00

exttrail ./dirdat/aj
discardfile ./dirrpt/e_ajiang.dsc, append, megabytes 10

table ajiang.*;

一切顺利,goldengate的目标端成功获得源端的变化数据。但是转念一想,如何能证明log信息是从
standby的standby redo log中抓获的而不是从源端主库中抓获的呢?为此,将源端主库的log_archive_dest_state_2设置为defer,
结果发现,源端主库数据发生变化时,虽然standby上的standby redo log中还没有收到这些变化, 但goldengate目标端却可以成功获取这些变化,说明这个配置实际上成功“穿越”了。这可不是我想要的。

于是将tranlogoptions asmuser sys@+asm1, asmpassword oracle这句话注释掉,因为既然想从standby上standby redo log中获取log信息,而standby又不在ASM下,所以这句话原本就不应该放上去。测试结果返回:
2012-05-17 05:49:29  ERROR   OGG-00446  No valid log files for current redo sequence 368, thread 1, error retrieving redo file name for sequence 368, archived = 0, use_alternate
= 0Not able to establish initial position for sequence 368, rba 8000016.

我的第一个想法是通过tranlogoptions的一些参数将log的位置指向standby redo log所在的路径上,但发现诸如[ALTLOGDEST <path>]和[LOGSOURCE <platform>, [PATHMAP <path to logs]]之类的都不适用。

于是我的第二个想法是完全只通过连接standby,试一下与源端主库完全不相关的配置,看行不行。
于是我将userid ggs@racdb,password ggs改为userid ggs,password ggs,不再去连接源端主库。结果报错如下:
OGG-00664  OCI Error beginning session (status = 1033-ORA-01033: ORACLE initialization or shutdown in progress).
这可以理解,因为standby不在open状态中,于是我将standby改为active DG状态,即READ ONLY WITH APPLY状态。然后重启extract, 报错如下:
OGG-00664  OCI Error creating temporary LOB to retrieve default LOB chunk size (status = 1157-ORA-01157: cannot identify/lock data file 201 - see DB
WR trace file
ORA-01110: data file 201: '/u01/oradata/tempfile/temp.260.771858605').

在metalink上查了一下,案例非常少,有一个OGG-00664的例子,是由TEMP tablespace was accidentally dropped引起的。
查了一下我的standby中也的确没有临时表空间。在standby备库上查了一下:
SQL> select * from dba_temp_files;
select * from dba_temp_files
              *
ERROR at line 1:
ORA-01157: cannot identify/lock data file 201 - see DBWR trace file
ORA-01110: data file 201: '/u01/oradata/tempfile/temp.260.771858605'

ls /u01/oradata/tempfile
结果也显示为空。

其实我对standby中的临时数据文件一直搞不清楚。有人说可以通过将standy置于read only状态下,便可以用alter tablespace temp add tempfile来实现了。那这个tempfile到底是建在主库上的OS上了,还是建在备库上的OS上了呢?
不管怎么样好歹试一把:在standby备库上操作SQL> alter tablespace temp add tempfile '/u01/oradata/tempfile/temp.260.771858605';
结果报错:
ERROR at line 1:
ORA-01537: cannot add file '/u01/oradata/tempfile/temp.260.771858605' - file already part of database  --说这个文件本来已是数据库的一部分了。奇怪?

这里再提一下,我的主库上的临时表空间的临时数据文件如下,可以看出主库和standby之间还存在着路径的转换。
SQL>  select * from dba_temp_files;
FILE_NAME                                      FILE_ID TABLESPACE_NAME      BYTES     BLOCKS STATUS  RELATIVE_FNO AUT   MAXBYTES  MAXBLOCKS INCREMENT_BY USER_BYTES USER_BLOCKS
------------------------------------------- ---------- --------------- ---------- ---------- ------- ------------ --- ---------- ---------- ------------ ---------- -----------
+DATADG/racdb/tempfile/temp.260.771858605            1 TEMP              37748736       4608 ONLINE             1 YES 3.4360E+10    4194302           80   36700160        4480

最终,由goldengate的配置又引出standby临时文件的问题,算是一箭双雕学两招吧。希望高手指点。
下载专业ORACLE数据库恢复工具PRM-DUL  For Oracle http://www.parnassusdata.com/zh-hans/emergency-services

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638  QQ: 47079569   
2#
发表于 2012-6-1 22:58:56
至少据我所知 Goldengate是不支持  physical standby作为downstream 的

Oracle® GoldenGate
Oracle Installation and Setup Guide
11g Release 2 (11.2.1.0.0)
E27278-01

但是 goldendate 是支持 downstream mining database 的

To use the downstream mining database to capture changes from multiple source
databases, you must make sure that no standby redo logs are present in the
downstream mining database. All Extract sessions that operate in integrated capture
mode will capture changes from the archived logs sent over from the various source
databases to the downstream mining database.

参考
http://docs.oracle.com/cd/E28323_01/doc.1121/e27278.pdf


  Thomas Zhang 同学 之前完成了goldengate 11.2.1 downstream for integrated capture测试  , 你可以找他问问 http://tomszrp.itpub.net/post/11835/526546

他在我的群里 qq_group.png

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-12-26 11:45 , Processed in 0.050422 second(s), 24 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569