Database Reference
In-Depth Information
Although strictly speaking you do not need an initialization file when starting the database for the restore of the
spfile, you still may have to create one. Many Oracle parameters are calculated on-the-fly, and cpu_count is one of
those many others are based on. With today's multi-core CPUs you can run into ORA-4031 errors if you are not setting
the cpu_count to a low value as the default SGA size used by the dummy instance is too low for those servers. If you
want to be on the safe side set the SGA and PGA parameters as well.
Armed with this file you can start the database. After the database instance has been started in nomount mode,
you can restore the spfile:
RMAN> restore spfile from autobackup;
Starting restore at 22.09.2013 19:56
recovery area destination: +RECO
database name (or database unique name) used for search: CDB1
channel c1: AUTOBACKUP +RECO/CDB1/AUTOBACKUP/2013_09_22/s_826832795.297.826832795
found in the recovery area
channel c1: looking for AUTOBACKUP on day: 20130922
channel c1: restoring spfile from AUTOBACKUP
+RECO/CDB1/AUTOBACKUP/2013_09_22/s_826832795.297.826832795
channel c1: SPFILE restore from AUTOBACKUP complete
Finished restore at 22.09.2013 19:56
The file found by RMAN is indeed the latest spfile autobackup in the FRA. Be careful though the spfile could
be restored in $ORACLE_HOME/dbs and not in ASM. If you are not using the Fast Recovery Area it is mandatory
to set the dbid at the RMAN prompt, and you may have to specify the autobackup location as well in a run {} block.
Such a block groups instructions together that are executed in the same context. The most common example is the
incomplete recovery using a point in time. If the commands were not surrounded in the run {} block setting the time
to recover up to would not have any effect. Restart the instance to make use of the restored spfile.
The easiest scenario for restoring the server parameter file is to use a recovery catalog. Since the database has
not accessed the controlfile when in nomount mode it does not know about the backup information recorded in it.
The recovery catalog however stores this information independently from the controlfile and is of great help. Start the
database in nomount mode while connected to the target database and catalog. A stub-parameter file is not used in
this example to show the alternative output:
[oracle@server1 ~]$ rman catalog rco@rcat_pdb target sys@cdb1
Recovery Manager: Release 12.1.0.1.0 - Production on Sun Sep 22 21:01:01 2013
Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved.
target database Password:
connected to target database (not started)
recovery catalog database Password:
connected to recovery catalog database
RMAN> startup nomount
startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file
'/u01/app/oracle/product/12.1.0.1/dbhome_1/dbs/initCDB1.ora'
Search WWH ::
Custom Search