Data Guard与nid

使用nid可以修改一个库的db_name和dbid。当然,如果dbid变更,则需要resetlogs才能打开数据库,因为oracle在内部其实是通过dbid来区分一个数据库的,而只修改db_name的话,则可以noresetlogs。

对于Data Guard环境来说,如果变更了主库的db_name,备库怎么处理?因为db_name不但存在于控制文件中,在每个数据文件的头部也有标识,而备库是不允许执行nid来更名的:

$ nid TARGET=/ DBNAME=test SETNAME=Y
DBNEWID: Release 10.2.0.4.0 - Production on Mon Aug 18 13:25:50 2008
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
Connected to database TEST (DBID=47959353)
NID-00131: Control file is not current

Change of database name failed during validation - database is intact.
DBNEWID - Completed with validation errors.

但如果主库只是要变更db_name的话,备库是不必重做的,只要从主库重新生成备库控制文件即可。此时备库可以继续恢复主库传过来的归档,但是数据文件头部的某个位置还是会保留原来的db_name,只有在备库切换成主库的时候,才会根据控制文件去更新数据文件头。

主库从test更名为test2后,即使重建备库控制文件,备库的数据文件头中的db_name还是保持不变:

$ strings system.dbf | head -n 5
}|{z
TEST
SYSTEM
_SYSSMU1$
_SYSSMU2$

备库在切换成主库以后,文件头中的db_name更新成新的test2:

$ strings system.dbf | head -n 5
}|{z
TEST2
SYSTEM
_SYSSMU1$
_SYSSMU2$

这样虽然看起来不会有什么太大的问题,只是一个标识字段不一样,甚至主库的某个datafile损坏,一样可以复制备库的datafile过来替代。但主备库的数据文件的文件头中存在这么一个不一致,总是一个潜在的风险点,谁知道哪天又触发到oracle的什么bug了。

另外,原备库的临时文件需要重建,因为切换新的主库以后,tempfile的文件头不会根据控制文件修改成新的db_name。

最后附上使用nid修改db_name而不修改dbid的操作步骤(摘自Note:224266.1):

1. Backup the database
2. SHUTDOWN IMMEDIATE of the database
3. STARTUP MOUNT
4. Open one session and run NID with sysdba privileges
% nid TARGET=SYS/password@test_db DBNAME=test_db2 SETNAME=Y
– the value of DBNAME is the new dbname of the database
– SETNAME must be set to Y. The default is N and causes the DBID to be changed also.
5. shutdown IMMEDIATE of the database
6. Set the DB_NAME initialization parameter in the initialization parameter
file to the new database name
7. Create a new password file
8. Startup of the database(without resetlogs)

DBA备忘录:Data Guard之添加数据文件

一般情况下,如果数据文件采用的是裸设备,为了便于管理,会在裸设备上创建soft link,这样在data guard环境中就有个问题,必须在主备库同时执行创建相同的link,否则备库是auto standby file management的话,会导致数据文件创建失败(前提是去掉了文件系统的写权限,否则会加到文件系统中去,这样麻烦更麻烦了)。

加入在主库创建了soft link,添加了datafile,而备库没有创建对应的link多话,则会遇到以下错误:

Errors in file /u01/oracle/admin/comm/bdump/comm_mrp0_2380526.trc:
ORA-01274: cannot add datafile ‘/u01/oracle/oradata/comm/test.dbf’ – file could not be created
ORA-01119: error in creating database file ‘/u01/oracle/oradata/comm/test_66.dbf’
ORA-27040: skgfrcre: create error, unable to create file
IBM AIX RISC System/6000 Error: 13: Permission denied
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
MRP0: Background Media Recovery process shutdown

Read more of this post

Oracle11g Data Guard Redo Tranport Services安全性增强

Oracle11g的Data Guard相对Oracle10g来说有不少改进,最引人注目的自然是physical standby可以在恢复的同时读取数据,这个被Oracle称为Active Data Guard的选件是需要单独购买license的。另外10g已经有的可以暂时将physical standby打开为读写模式的特性,在11g进行了加强,使得在读写模式的同时可以继续接收primary传过来的日志,并且换了个新的名字,叫做snapshot standby,作为data guard的第三种standby推出。

我们知道,data guard需要在主备库之间通过redo transport services传递日志,那么就需要redo transport services能够有足够的权限访问备库。在10g之前,这是通过remote passwordfile以sys用户权限实现的,这就需要在主备库使用相同的sys密码。在Oracle11g对于redo transport services的安全性有所增强,可以使用SSL或者passwordfile的方式进行安全验证。

SSL是网络间进行安全连接的工业标准,本文不打算涉及具体的SSL配置,详细的配置方法请参考官方文档:《Oracle Database Advanced Security Administrator’s Guide》。

这里要说一下Oracle11g对于redo transport services在remote passwordfile认证上的一点改进。在Oracle11g中引入了一个新的初始化参数redo_transport_user,该参数可以重新指定redo transport services连接备库的用户,而不一定要使用sys用户,当然,该用户需要有sysoper或者sysdba权限,并且该用户在主备库passwordfile中的密码需要一致。

使用remote passwordfile认证,所有的physical standby都需要使用和主库一样的passwordfile,并且,如果在主库对于sysoper/sysdba权限有变动或者拥有sysdba/sysoper的用户密码变更,都需要重新复制passwordfile到standby中,否则可能导致redo transport services工作不正常。

Oracle11g Data Guard新增加Snapshot Standby模式

Oracle11g文档上看到,Oracle11g的data guard除了原有的physical standby和logical standby,又增加了一种新的snapshot standby模式。

该模式从physical standby转化而来,转化成snapshot standby以后,standby可以继续接收primary传过来的日志,但是不会应用,snapshot standby是可以进行读写操作的。在需要的时候,再将snapshot standby转换回physical standby,然后继续从前面转换成snapshot standby的那一刻开始应用日志。

从上述的描述可以发现,这个实际上跟我以前一篇文章中提到的Oracle10g physical standby也可以进行读写操作是一样的,Oracle11g将这一旧功能重新打包以一个新的名字推出了而已,当然,在读写操作的同时还可以接受主库传过来的日志算是一点改进。不过估计在操作方面会有所简化,比如应该不会再需要手工创建restore point和flashback了,通过一条转换状态的命令ALTER DATABASE CONVERT TO SNAPSHOT STANDBY或ALTER DATABASE CONVERT TO PHYSICAL STANDBY就可以自动完成这些繁琐的步骤了。

已经下载了oracle11g for linux版本,但手头没有linux环境,更多实际测试,估计要等下周从广东回来以后了^_^

无觅相关文章插件,快速提升流量