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)