Re: Blog a Day

  • From: Chris Taylor <christopherdtaylor1994@xxxxxxxxx>
  • To: jkstill@xxxxxxxxx
  • Date: Sat, 20 Jan 2018 21:22:23 -0600

Well, the restore completed successfully, and then promptly dropped the 2
datafiles for the 2 tablespaces I told it to skip (facepalm).

Attemping to recovery those before recreating the standby controlfile....

Chris


On Sat, Jan 20, 2018 at 8:45 PM, Chris Taylor <
christopherdtaylor1994@xxxxxxxxx> wrote:

I've got one for you....

Scenario:
- Need to recover Standby Database using Incremental Backup of Primary -
(a 50TB primary db mind you) - Following Doc ID: 836986.1
- While recovery is running on Standby, kill the RMAN sessions so you can
reconfigure the rman channels and add more channels ( but only do this
after 1 or more datafiles have successfully recovered while others remain
to be recovered)
- Restart the recovery
- Immediately get this error on the new recovery session (in 12.1.0.2)
(instead of it telling you that datafile is already recovered, it throws an
ORA-19639 - which Oracle support doesn't have any knowledge base articles
on.


RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 01/20/2018 21:12:39
ORA-19870: error while restoring backup piece
/orabackup-xfs/db_name/backup/ForStandby_s3sp2kak_1_1
ORA-19639: file /oradata/db_name/system/undo_tbs1_01.dbf is more current
than this incremental backup
ORA-19642: start SCN of incremental backup is 908522280723
ORA-19641: backup datafile checkpoint is SCN 909723281357 time 01/19/2018
12:40:54
ORA-19640: datafile checkpoint is SCN 909723281357 time 01/19/2018 12:40:54


Figured out from looking at the alert log the datafile it was complaining
about had already been fully recovered.  So I restarted the recovery with
SKIP TABLESPACE UNDOTBS.

Seems to be working but won't find out fully until I get through the
entire recovery process which is taking hours.  Standby had gotten 2 days
behind because of a failed monitoring configuration in our Grid setup.

Chris


On Sat, Jan 20, 2018 at 5:04 PM, Jared Still <jkstill@xxxxxxxxx> wrote:

Thank you Kellyn!

Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
Principal Consultant at Pythian
Pythian Blog http://www.pythian.com/blog/author/still/
Github: https://github.com/jkstill



On Fri, Jan 19, 2018 at 2:02 PM, Kellyn Pot'Vin-Gorman <
dbakevlar@xxxxxxxxx> wrote:

I was able to keep 3 per week for a good year, but it isn't easy when
you have a day job and want to keep the content technical.  Sometimes the
writing isn't the issue, but the technical testing or builds... :)

Good luck, Jared!

Kellyn



[image: Kellyn Pot'Vin on about.me]

Kellyn Pot'Vin-Gorman
about.me/dbakevlar
  <http://about.me/dbakevlar>

On Fri, Jan 19, 2018 at 2:50 PM, Michael D O'Shea/Woodward Informatics
Ltd <woodwardinformatics@xxxxxxxxxxxxxxxx> wrote:

Pick a good charity and you have a sponsor.
Mike

Am 19.01.2018 um 22:41 schrieb Jared Still <jkstill@xxxxxxxxx>:


Doing a blog a day, Monday - Friday.  Limited to what I can do in 30-45
minutes per day.
( ok, sometimes 60 minutes...)

How long can I keep this up?  Until I run out of time or ideas, which
ever comes first.  :)

Start here:  https://blog.pythian.com/author/still/


Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
Principal Consultant at Pythian
Pythian Blog http://www.pythian.com/blog/author/still/
Github: https://github.com/jkstill







Other related posts: