# Moving spfile & controlfile to ASM Using OMF

It is a bit tricky to strictly maintain [OMF](https://docs.oracle.com/database/121/ADMIN/omf.htm#ADMIN003) because the filename depends on asm client instance db\_unique\_name, rather than on what’s written in the files being moved.

It would generally make sense to move spfile first and controlfile after that as this is the order rdbms instance will access them. However, we intentionally won’t start with spfile as it is only possible to move spfile in OMF fashion if rdbms instance has already established connectivity with asm instance (rdbms instance is registered as rdbms client in asm instance).

### controlfile

```plaintext
RMAN> restore controlfile to '+SSD' from '/oradata/ssd/ORCL/controlfile/o1_mf_f1f8q9j1_.ctl';
SQL> alter system set control_files='+SSD/ORCL/CONTROLFILE/current.260.960811081' scope=spfile;
```

So, we start with controlfile. First obvious thing here is to specify '+DG' location without full [target](https://docs.oracle.com/database/121/ADMIN/omf.htm#ADMIN003) filename. Note that you can specify *current* contolfile in from clause (provided that your instance is mounted). If you specify backup location instead of current controlfile then your restored controlfile will be flagged as *backup* control file and thus you would need resetlogs to open the database (or recreate controlfile from source). You can use asmcmd to obtain the actual filename to which controlfile was restored to.

### spfile

```plaintext
RMAN> backup as copy spfile format '/home/oracle/orcl.spfile';
RMAN> restore spfile to '+HDD' from '/home/oracle/orcl.spfile';

$ rm $ORACLE_HOME/dbs/spfileorcl.ora
$ echo "SPFILE='+HDD/ORCL/PARAMETERFILE/spfile.257.960812067'" > $ORACLE_HOME/dbs/initorcl.ora
```

This procedure seems to only work if ASM instance knows which database it is talking to. Specifically, if your rdbms instance is listed in v$asm\_client (on asm instance). We achieved this by moving controlfile into ASM before attempting to move spfile. If this would not be the case, then your spfile would be created in +DG/DB\_UNKNOWN/ folder.

While created asm *alias* may be correct, the actual path is determined by the asm client instance. So, when you put spfile or controlfile into asm, it does not matter what is stored in them (for example, spfile has db\_unique\_name written in itself). What does matter is db\_unique\_name of asm client which restored (copied) the spfile or controlfile to asm.