- 最后登录
- 2023-8-16
- 在线时间
- 1686 小时
- 威望
- 2135
- 金钱
- 50532
- 注册时间
- 2011-10-12
- 阅读权限
- 200
- 帖子
- 5207
- 精华
- 39
- 积分
- 2135
- UID
- 2
|
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临时文件的问题,算是一箭双雕学两招吧。希望高手指点。 |
|