Control file is very important file for the database operation. Loosing a single control file will make the database unstable and will lead to interruption in service.

So we will always try to put control file in a SAFE and stable place.

Similarly online logs are equally important and loosing them can also cause database to crash, incomplete recovery and possible data loss.

CASE 1:

USUALLY the flash recovery area and the main database disks are located in such a WAY that the probability of both GOING down at the same time is very slim.

And If your flash recovery area is in a storage location as reliable as the main database storage, then you should put one control file and one redo member/log GROUP there.

It will surely help you in quick and complete recovery.

CASE 2:

If your flash recovery area is NOT as reliable as the main database storage, the chance of failure in the flash recovery area is greater compared to the main database disks. If the flash recovery area fails, then you lose one of the control files and the online redo log. You will be able to start database easily by removing that control file from the control file parameter in the initialization parameter file (copying online log from the secondary Non-FRA location) and restarting it but you will have an interruption of production service, which is very undesirable.

Scenario A: Besides FRA, we have multiplexed Control files to two other separate location, so risk of loosing control file (and fear of not able to do complete recovery) is minimized We won’t be putting even a single control file in the FRA.

Scenario B: Besides FRA, we have multiplexed Control files to only one other separate location, so risk of loosing control file and (and fear of not able to do complete recovery) is more. Complete recovery of database is of primary importance to you than the database interruption.

Here we can go and put the control file in FRA.

Control file is very important file for the database operation. Loosing a single control file will make the database unstable and will lead to interruption in service.

So we will always try to put control file in a safe and stable place.

Similarly online logs are equally important and loosing them can also cause database to crash, incomplete recovery and possible data loss.

CASE 1:

Usually the flash recovery area and the main database disks are located in such a way that the probability of both going down at the same time is very slim.

And If your flash recovery area is in a storage location as reliable as the main database storage, then you should put one control file and one redo member/log group there.

It will surely help you in quick and complete recovery.

CASE 2:

If your flash recovery area is NOT as reliable as the main database storage, the chance of failure in the flash recovery area is greater compared to the main database disks. If the flash recovery area fails, then you lose one of the control files and the online redo log. You will be able to start database easily by removing that control file from the control file parameter in the initialization parameter file (copying online log from the secondary Non-FRA location) and restarting it but you will have an interruption of production service, which is very undesirable.

Scenario A: Besides FRA, we have multiplexed Control files to two other separate location, so risk of loosing control file (and fear of not able to do complete recovery) is minimized We won’t be putting even a single control file in the FRA.

Scenario B: Besides FRA, we have multiplexed Control files to only one other separate location, so risk of loosing control file and (and fear of not able to do complete recovery) is more. Complete recovery of database is of primary importance to you than the database interruption.

Here we can go and put the control file in FRA.