Databases Reference
In-Depth Information
in this example, the control files already exist in the location specified by the control_files initialization
parameter. therefore, the reUSe parameter is used in the Create Control file statement.
Note
Open the database with open resetlogs :
9.
SQL> alter database open resetlogs;
If this is successful, you should have a database that is a copy of the original database. All of the data files,
control files, archive redo logs, and online redo logs are in the new locations, and the database has a
new name.
10.
As a last step, ensure that your temporary tablespace exists:
ALTER TABLESPACE TEMP ADD TEMPFILE '/ora01/dbfile/DEVDB/temp01.dbf'
SIZE 104857600 REUSE AUTOEXTEND OFF;
you can also use the niD utility to change the database name and DBiD. for additional information, see moS note
863800.1 for more details.
Tip
How It Works
Manually restoring and recovering a database to a different server is sometimes required. For example, the
network security may be such that manually copying an RMAN backup to a remote server is the only way to
replicate the database.
The steps covered in the solution section are also an excellent way to test your backup and recovery strategy. If
you can completely restore a production backup to a test server, you can be confident that you don't have any missing
pieces and that you know how to perform all required tasks. In some environments we schedule an activity like this
once every three months. If you understand each step, you'll be better prepared to deal with any type of backup and
recovery issue.
The steps covered in the solution section are fairly straightforward. Keep in mind that some of the steps won't be
necessary if you have the same directory structures between the two servers. For example, renaming the data files and
online redo logs isn't required when the directory structures are the same.
The last step of renaming the database is optional. If you make a copy of a production database, you'll probably
want to rename the restored database. This is because you don't ever want to get confused and think you're working
with a test database when it is the production database (or vice versa).
if you don't rename the database, then be careful about connect and resync operations to the same recovery
catalog used by the original/source database. this causes confusion in the recovery catalog as to which is the real source
database and may jeopardize your ability to recover and restore the real source database.
Note
 
 
Search WWH ::




Custom Search