InterviewSolution
Saved Bookmarks
InterviewSolution
This section includes InterviewSolutions, each offering curated multiple-choice questions to sharpen your knowledge and support exam preparation. Choose a topic below to get started.
| 1. |
What All Files Can Not Be Backed Up By Rman? |
| Answer» | |
| 2. |
How To Check The Version Of Your Recovery Catalog? |
|
Answer» You can EASILY CHECK the version of your recovery catalog by issuing the following COMMAND from SQL*PLUS after logging in as the recovery catalog owner: RMAN@rmandb > select * from rcver; You can easily check the version of your recovery catalog by issuing the following command from SQL*Plus after logging in as the recovery catalog owner: RMAN@rmandb > select * from rcver; |
|
| 3. |
What Are The Most Important Recovery Catalog Views? |
|
Answer» Below are some of the frequently used views:
Below are some of the frequently used views: |
|
| 4. |
You Want To Move Your Recovery Catalog From One Database To Another. How You Can Do It? |
|
Answer» Moving Recovery CATALOG to another database is simple process
The import catalog command will import the source recovery catalog contents into the target recovery catalog. Moving Recovery catalog to another database is simple process The import catalog command will import the source recovery catalog contents into the target recovery catalog. |
|
| 5. |
What Is The Significance Of ‘resync Catalog’ Rman Command? |
|
Answer» The resync catalog command is used in order to update or resynchronize a recovery catalog from the target database control file. Since sync is done from Target database control file, so you must CONNECT to the recovery catalog as well as to the target database in order to perform the resynchronization. RMAN> resync catalog; When above command is executed, RMAN will first create a snapshot control file. It’ll then compare the contents of the recovery catalog to the contents of the snapshot control file and update the recovery catalog by ADDING the missing information and modifying the changed backup and schema related records. It means that we will keep PARAMETER control_file_record_keep_time longer than our backup interval, so that the DATA in the control file gets transferred to the recovery catalog before that data is overwritten. When you issue certain RMAN commands such as the backup command, RMAN AUTOMATICALLY performs a resynchronization. The resync catalog command is used in order to update or resynchronize a recovery catalog from the target database control file. Since sync is done from Target database control file, so you must connect to the recovery catalog as well as to the target database in order to perform the resynchronization. RMAN> resync catalog; When above command is executed, RMAN will first create a snapshot control file. It’ll then compare the contents of the recovery catalog to the contents of the snapshot control file and update the recovery catalog by adding the missing information and modifying the changed backup and schema related records. It means that we will keep parameter control_file_record_keep_time longer than our backup interval, so that the data in the control file gets transferred to the recovery catalog before that data is overwritten. When you issue certain RMAN commands such as the backup command, RMAN automatically performs a resynchronization. |
|
| 6. |
What Is The Benefit Of Using Recovery Catalog? |
Answer»
|
|
| 7. |
Does Using Recovery Catalog Means Rman Won’t Use The Control File To Store Information? |
|
Answer» No. EVEN when you CHOOSE to use a RECOVERY catalog, backup information will CONTINUE to be stored in the control FILE as well by default. No. Even when you choose to use a recovery catalog, backup information will continue to be stored in the control file as well by default. |
|
| 8. |
How To Check The Syntax Of Rman Commands? |
|
Answer» Start the RMAN CLIENT with the OPERATING system command-line argument checksyntax. $ rman checksyntax The command has no syntax errors The command has no syntax errors You can ALSO use the checksyntax argument to check the syntax of RMAN commands that are part of a command file. Example: Start the RMAN client with the operating system command-line argument checksyntax. $ rman checksyntax The command has no syntax errors The command has no syntax errors You can also use the checksyntax argument to check the syntax of RMAN commands that are part of a command file. Example: |
|
| 9. |
Can Recovery Catalog Database Also Be Shutdown From Rman Prompt Like Target Database Can Be Done? |
|
Answer» All the shutdown and startup commands APPLIES only to the target database. You can’t START and STOP the recovery catalog instance from RMAN. The only way to start up and shut down the recovery catalog instance is by CONNECTING to the recovery catalog database as the target database and by ISSUING the relevant commands to start or stop the instance. All the shutdown and startup commands applies only to the target database. You can’t start and stop the recovery catalog instance from RMAN. The only way to start up and shut down the recovery catalog instance is by connecting to the recovery catalog database as the target database and by issuing the relevant commands to start or stop the instance. |
|
| 10. |
How Can You Create Log Of Your Rman Activity? |
|
Answer» Two ways to do it A) WHILE STARTING RMAN Also If you are running RMAN interactively and you want to see output on your terminal screen as well as have it written to a log file, use TEE command: B) WHILE INSIDE RMAN Two ways to do it A) WHILE STARTING RMAN Also If you are running RMAN interactively and you want to see output on your terminal screen as well as have it written to a log file, use tee command: B) WHILE INSIDE RMAN |
|
| 11. |
How Can You Make Sure That Only One Of The Redo Log Member Is Created In Fra? |
|
Answer» If you want only one member of the GROUP in the flash recovery area and the other one in the regular database file location, you should define two parameters—the flash recovery area and db_create_file_dest. SQL> Show parameter db_recovery_file_dest GROUP# STATUS TYPE MEMBER IS_RECOVERY_DEST_FILE 3 ONLINE /u01/oracle/DB11G/oradata/brij/redo03.log NO If you want only one member of the group in the flash recovery area and the other one in the regular database file location, you should define two parameters—the flash recovery area and db_create_file_dest. SQL> Show parameter db_recovery_file_dest GROUP# STATUS TYPE MEMBER IS_RECOVERY_DEST_FILE 3 ONLINE /u01/oracle/DB11G/oradata/brij/redo03.log NO |
|
| 12. |
Is Putting Control File And Online Redo Logs In Flash Recovery Area (fra) Advisable? |
|
Answer» 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. |
|
| 13. |
Which Views Can Be Used For Checking Space Usage In The Fra? |
|
Answer» Check Below.. SQL> SELECT NAME,SPACE_LIMIT/1024/1024/1024 TOTAL_GB,SPACE_USED/1024/1024/1024 USED_GB,SPACE_RECLAIMABLE,NUMBER_OF_FILES from v$recovery_file_dest; NAME TOTAL_GB USED_GB SPACE_RECLAIMABLE NUMBER_OF_FILES /u01/oracle/DB11G/fast_recovery_area 16 1.13197899 0 3 FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES——————– —————— ————————- ————— CONTROL FILE 0 0 0 7 rows SELECTED. Check Below.. SQL> select NAME,SPACE_LIMIT/1024/1024/1024 TOTAL_GB,SPACE_USED/1024/1024/1024 USED_GB,SPACE_RECLAIMABLE,NUMBER_OF_FILES from v$recovery_file_dest; NAME TOTAL_GB USED_GB SPACE_RECLAIMABLE NUMBER_OF_FILES /u01/oracle/DB11G/fast_recovery_area 16 1.13197899 0 3 FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES——————– —————— ————————- ————— CONTROL FILE 0 0 0 7 rows selected. |
|
| 14. |
What All You Can Store In Flash Recovery Area(fra)? Can One Fra Directory Be Used For More Than One Database? |
|
Answer» Oracle can STORE different kind of files under FRA:
You can use the same flash recovery area for as many databases as you want. The RMAN backup process will create a subdirectory called <SID_NAME>, the same name as the database you are backing up. Oracle can store different kind of files under FRA: You can use the same flash recovery area for as many databases as you want. The RMAN backup process will create a subdirectory called <SID_NAME>, the same name as the database you are backing up. |
|
| 15. |
What Is The Benefit Of Making Automatic Control File Backup To On? |
|
Answer» Remember that CONTROL file is absolutely necessary during a RECOVERY. Below command can be used to have automatic control file backup to be TAKEN. This is highly recommended. RMAN> configure controlfile autobackup on Now at the end of every RMAN backup command, RMAN automatically backs up the control file. EVEN when you make some changes via SQL*Plus( say creating a new tablespace or adding or renaming a datafile or an online redo log member), the control file is automatically backed up. Also, you can restore RMAN’s backup and recovery information (called RMAN’s repository), when you lose all your control files and aren’t using the optional recovery catalog. Remember that control file is absolutely necessary during a recovery. Below command can be used to have automatic control file backup to be taken. This is highly recommended. RMAN> configure controlfile autobackup on Now at the end of every RMAN backup command, RMAN automatically backs up the control file. Even when you make some changes via SQL*Plus( say creating a new tablespace or adding or renaming a datafile or an online redo log member), the control file is automatically backed up. Also, you can restore RMAN’s backup and recovery information (called RMAN’s repository), when you lose all your control files and aren’t using the optional recovery catalog. |
|
| 16. |
How Important Is Database Redundancy Set And Where You Should Plan To Keep It? |
|
Answer» Database Redundancy SET is essential set of recovery-related files. As a DBA, you need to be well prepared for any kind of contingency situation. It should contain below:
Operating system mirroring is good, but you should do database level mirroring wherever possible. If you using ASM, TRY to have atleast Normal redundancy. When setting up production systems, use at least two disk drives(one for the redundancy set and the other for the datafiles). They should be completely separated by using different volumes, file systems, disk controllers, and RAID devices to hold the two sets of files You can set up FRA for keeping the redundancy set. Oracle RECOMMENDS the flash recovery area as a logical candidate to keep a copy of all the files belonging to the redundancy set (which includes the most recent database backup) on disk. Database Redundancy Set is essential set of recovery-related files. As a DBA, you need to be well prepared for any kind of contingency situation. It should contain below: Operating system mirroring is good, but you should do database level mirroring wherever possible. If you using ASM, try to have atleast Normal redundancy. When setting up production systems, use at least two disk drives(one for the redundancy set and the other for the datafiles). They should be completely separated by using different volumes, file systems, disk controllers, and RAID devices to hold the two sets of files You can set up FRA for keeping the redundancy set. Oracle recommends the flash recovery area as a logical candidate to keep a copy of all the files belonging to the redundancy set (which includes the most recent database backup) on disk. |
|
| 17. |
What Are The Benefits Of Rman Over User-managed Backup-recovery Process? |
|
Answer» powerful Data Recovery Advisor feature
With so many benefits, RMAN SHOLD be used as primary backup-recovery tool. powerful Data Recovery Advisor feature With so many benefits, RMAN shold be used as primary backup-recovery tool. |
|
| 18. |
There Was A Media Failure. How Can You Find Which Files You Must Recover? |
|
Answer» By querying the V$RECOVER_FILE view, which lists all FILES that NEED MEDIA RECOVERY. By querying the V$RECOVER_FILE view, which lists all files that need media recovery. |
|
| 19. |
What Is The Significance Of Fast_start_mttr_target Parameter? |
|
Answer» You USE the Oracle initialization parameter fast_start_mttr_target to specify the number of seconds you want the crash recovery to take. Oracle will try to recover the instance as close as possible to the time that you specify for the fast_start_mttr_target parameter. The maximum VALUE of this parameter is 3600 seconds (1 hour). During instance recovery, in the first roll forward operation, the database server MUST apply all TRANSACTIONS between the last checkpoint and the end of the redo log to the datafiles. Thus, in order to tune instance recovery, you control the gap between the checkpoint position and the end of the redo log. This is called Mean Time to Recover (MTTR). You use the Oracle initialization parameter fast_start_mttr_target to specify the number of seconds you want the crash recovery to take. Oracle will try to recover the instance as close as possible to the time that you specify for the fast_start_mttr_target parameter. The maximum value of this parameter is 3600 seconds (1 hour). During instance recovery, in the first roll forward operation, the database server must apply all transactions between the last checkpoint and the end of the redo log to the datafiles. Thus, in order to tune instance recovery, you control the gap between the checkpoint position and the end of the redo log. This is called Mean Time to Recover (MTTR). |
|
| 20. |
What Is Scn? |
|
Answer» The SCN is an Oracle server–assigned number that indicates a committed version of the database. It’s quite possible that different datafiles in the database might have a different SCN at any given point in time. At checkpoint, the server will makes all database file SCNs and control file SCN CONSISTENT with RESPECT to an identical SCN.The datafiles will not contain any database CHANGES beyond that common SCN. This synchronization of the SCNs will make sure we have a consistent backup of database. When you are doing hot backup, you may end up with backups of the VARIOUS datafiles at various time points and different SCNs and you can not open a database without synchronizing the SCN on all data files, so you will have to apply ARCHIVE logs to make the data current and synchronize the SCNs across the datafiles. The SCN is an Oracle server–assigned number that indicates a committed version of the database. It’s quite possible that different datafiles in the database might have a different SCN at any given point in time. At checkpoint, the server will makes all database file SCNs and control file SCN consistent with respect to an identical SCN.The datafiles will not contain any database changes beyond that common SCN. This synchronization of the SCNs will make sure we have a consistent backup of database. When you are doing hot backup, you may end up with backups of the various datafiles at various time points and different SCNs and you can not open a database without synchronizing the SCN on all data files, so you will have to apply archive logs to make the data current and synchronize the SCNs across the datafiles. |
|