Oracle Data Guard - Recover Standby Database Using Incremental Backup - Resolve Log Gap

[@AT-tc4vv]

thanks for clear explaination. nice work !

[@YouVolve]

Thanks for your feedback

[@Dancewithsaigite]

Very informative video keed uploading..

[@YouVolve]

Thank you, I will

[@PavanKumar-ft8eq]

Good explanation thanks for sharing video.I have one doubt here current scn is not same both primary standby difference is 1276.

[@YouVolve]

@PavanKumar-ft8eq - Thanks for your feedback and the question. Yes, your observation is correct. The difference in SCN may be sometimes above 1000. SCN can be incremented by many hundreds or thousands within a few seconds. It is not just the user activities that cause the SCN to get incremented but anything happening including the SYS/background activities. There was almost 50 seconds in between when I executed the statement in the standby and the primary and also in another session (not included in the video) I was extracting an AWR from the primary. That might have caused to increase. But at the end of the day, what we should be more concerned is the time lag between the primary and the standby. You can find that out using the function "scn_to_timestamp" as shown below. SQL> select scn_to_timestamp(250605041) from dual; Output: SCN_TO_TIMESTAMP(250605041) --------------------------------------------------------------------------- 06-NOV-23 09.05.58.000000000 AM I am using an example SCN of 250605041 here. Using the output from this statement executed against both the primary and standby SCN, you can find out by how much time the standby is lagging. For an ideal system in real time apply, there may be a few seconds which is expected. Hope this clears your doubt.

[@parvazcse]

Thanks a lot for your effort! log_archive_dest_state_2 was not enabled again after making it differ. Wouldn't that create a problem?

[@YouVolve]

@parvazcse - Thanks for your feedback. Yes, you must enable the log_archive_dest_state_2=ENABLE which I did at around 8:30 minute mark of the video. The setting DEFER is just temporarily done for demonstration purpose.

[@urso15]

Very good!

[@YouVolve]

Thanks for your feedback.

[@babavali1319]

Thanks a lot

[@YouVolve]

Most welcome

[@ChaitanyaKumbhalkar]

it was very nice explanation, thank you.

[@YouVolve]

Thanks for your feedback.

[@tariqueazmi514]

Nice practice

[@YouVolve]

Thanks for your feedback.

[@shashiranjan06cse04]

Hello , If i am not correct we need to catalog the backup pieces .. After restoring control file we need to catalog backup pieces then existing datafiles . then we need to recover database. Please confirm on this Recovery of Standby DB Command Sequence ======================================== SQL> shutdown immediate SQL> startup nomount RMAN> RESTORE STANDBY CONTROLFILE FROM '/tmp/bkp/standby_control.ctl'; alter database mount; catalog start with '/u001/app/oracle/oradata/TESTDG2/datafile'; SWITCH DATABASE TO COPY; RMAN> recover database noredo; Check the SCN’s in primary and standby:

[@YouVolve]

Hi Shashi, thanks for watching my video and the question. We need to catalog the backup pieces only if the backup location is different in the standby server. As I mentioned in the video, I am maintaining the same backup location in the primary and standby server so we don't have to catalog the backup pieces here. However, you must catalog the datafiles while using the standby control file that you copied from primary as the datafile location in the primary and standby server are different. Hope this explains your doubt.

[@shashiranjan06cse04]

@@YouVolve thanks for clarifying..

[@YouVolve]

@@shashiranjan06cse04 my pleasure