Well I will be covering some points which I believe should be part of post checklist for any cloned database environment. This might not be complete list as it contains point which I have encountered or heard of.
1) Change database Name and Database Id
You should try to change the database name/instance name for UAT/ Cloned environment. In case if there is specific requirement to have the same instance_name/db_name, then atleast you should try changing the database id. If you are using RMAN duplicate command, dbid will be changed automatically. But in case you do not use duplicate command, then dbid will remain same.
DBid change becomes very important if you are using rman catalog database. In case you connect to rman catalog database from new cloned DB (without changing DBID),it would resync the resetlog information in the rman catalog database. Next time you try to take RMAN database backup on production database, you will get following errors
RMAN-06004: ORACLE error from recovery catalog database:
RMAN-20011: target database incarnation is not current in recovery catalog
Following metalink notes discuss how to handle these issues
Note 1070453.6 : RMAN: Point-in-Time Recovery of a Backup From Before Last Resetlogs
Note 237232.1 : How to Recover Through a Resetlogs Command Using RMAN
As you see, you will be better off changing Dbid (Database Id) at first place. DBNEWID can be used to change the DB_NAME or DBId or Both
http://download.oracle.com/docs/cd/B19306_01/server.102/b14215/dbnewid.htm
2) Check for database link
Check for database link present in the cloned environment. Ensure that these are select only dblinks and will not perform any DML in production databases. If you find any ,then you can either drop these or recreate them to point to any UAT or simply remove/hash out tnsnames entry corresponding to these hosts. Also check for any hard coded IP address in host column in DBA_DB_LINKS.
3)Remove or hash out any entries in tnsnames.ora pointing to production database and recovery catalog database
This again is to avoid any issues with dblink or RMAN catalog issues. Also note that when you hash the tnsnames.ora you need to place # in front of each line.
| Incorrect |
Correct |
#TESTDB10G =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = test10g)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = testdb10g)
)
) |
#TESTDB10G =
#(DESCRIPTION =
# (ADDRESS_LIST =
# (ADDRESS = (PROTOCOL = TCP)(HOST = test10g)(PORT = 1521))
# )
# (CONNECT_DATA =
# (SERVICE_NAME = testdb10g)
# )
#) |
4) Check cronjobs for oracle database user
If you have copied cron entries for server from production ( as part of database migration activity) , then crosscheck which all jobs need to be enabled for this cloned environment. e.g You can easily disable any cron for RMAN database, archivelog backup.
5)Modify listener.ora file
Modify listener.ora file to include new host entry and port number. This is also quite important as in case you copied it from production server, you could turn off production listener by mistake. Check following metalink note for details
Note 460666.1 – How To Remotely Administer a Listener
6) Check for local_listener and remote_listener parameter
Check for local_listener and remote_listener parameter and modify accordingly. Note that not changing remote_listener parameter can also lead to issues where in your UAT/Test database can get registered with Listener running on Production server.
7)Modify /etc/hosts entries
Modify /etc/hosts entries to remove entries for production database. Also try to use /etc/hosts for resolving host instead of DNS.
8) Add tempfiles to Temporary tablespace
After you clone the environment, tempfiles need to be added to the database.
9) Check for Archivelog mode
Generally archivelog mode is disabled for UAT/Cloned databases. In case your production database is in archivelog mode, ensure that you disable the archiving.
10) Verify Initialization Parameters
Verify all initialization parameter’s like *_dump_dest locations,utl_file_dir ,sga_max_size , etc.
Recent Comments