On a similar track, has anyone experience of using staging disk (not DSSU)
with lifecycle policies with RMAN?
The question I'm trying to answer (about to test) is that if the backup
phase of the SLP is to a disk STU, the backint will report to RMAN where
the backup has landed on disk.
The duplication stage then puts that onto a tape, but RMAN will not be
told (I assume) what the media ID is.
If a restore was requested from the agent, that I suspect is fine as
NetBackup will look in the catalog for where the primary copy is, and then
pop up an operator request for the tape (that assumes that [a] we expired
the disk image and [b] the tape is offsite).
Our current practice is not to submit the restore request until we know
the media are loaded, and the list of media to request to be brought back
to site comes from the RMAN catalog.
We suspect that is going to stop working. Has anyone seen this problem,
solved this problem, or found a way to avoid it?
William D L Brown
veritas-bu-bounces AT mailman.eng.auburn DOT edu wrote on 23/09/2009 17:49:34:
> Well you could use bpimmedia to extract the backup ID for the tape
> and then use that to find all tapes with that ID but that would be
> even more of a kluge. Also it would have the downside of not
> working if the primary copy had already expired while the offsite
> was still valid.
>
> If you?re saying RMAN isn?t that good at keeping track of things I?d
> have to say I agree but that?s something the Oracle folks should
address.
>
>
> From: Jared Still [mailto:jkstill AT gmail DOT com]
> Sent: Wednesday, September 23, 2009 12:30 PM
> To: Jeff Lightner
> Cc: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] RMAN, Veritas - Correlating Media ID after
> tape vaulted
>
> That's what we're doing now, but it seems rather kludgy to me.
>
> It should be possible to exactly correlate the Media ID's.
>
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist
> Oracle Blog: http://jkstill.blogspot.com
> Home Page: http://jaredstill.com
>
> On Wed, Sep 23, 2009 at 5:43 AM, Jeff Lightner <jlightner AT water DOT com>
wrote:
> Since you know the completion time and elapsed time from the RMAN
> output you could figure it out by doing:
>
> bpimmedia -L -policy <policy> -d 06/14/2009 017:00:00 -e 04/27/2008
18:30:00
>
> The end time (-e) is the one shown for completion (padded a little)
> and the start time (-d) is subtracting the hour and three minutes
> from that end time (and padding a little). This will show you the
> backup IDs and the image 1 and image 2 data. The image 2 data is
> the vaulted tapes. This would show you only the image 2 tapes if
> the image 1 tapes had already expired. Some people keep a longer
> retention on offsite than on site.
>
>
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu [mailto:veritas-bu-
> bounces AT mailman.eng.auburn DOT edu] On Behalf Of Jared Still
> Sent: Tuesday, September 22, 2009 7:12 PM
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: [Veritas-bu] RMAN, Veritas - Correlating Media ID after tape
vaulted
>
> When determining which tapes to recall from offsite, RMAN provides the
> RESTORE DATABASE PREVIEW RECALL syntax to identify the needed tapes.
>
> Here's an example:
>
> RMAN> RUN
> 2> {
> 3> set until time "to_date('06/17/2009 08:00:00','mm/dd/yyyy
hh24:mi:ss')";
> 4> restore database preview recall;
> 5> }
> executing command: SET until clause
>
> Starting restore at 09/22/2009 11:15:21
> ...
> List of Backup Sets
> ===================
>
> BS Key Type LV Size Device Type Elapsed Time Completion Time
> ------- ---- -- ---------- ----------- ------------ -------------------
> 2070190 Incr 0 89.78G SBT_TAPE 01:03:42 06/14/2009 18:20:43
> BP Key: 2070201 Status: AVAILABLE Compressed: NO Tag:
> TAG20090614T180051
> Handle: PRD_T20090614_db_s21827_p1_t689536853 Media: 002774
> List of Datafiles in backup set 2070190
> File LV Type Ckp SCN Ckp Time Name
> ---- -- ---- ---------- ------------------- ----
> 24 0 Incr 7113842263 06/14/2009 18:00:59 S:
> \ORACLE\PRD\SAPDATA10\BTABD_60\BTABD.DATA60
> 37 0 Incr 7113842263 06/14/2009 18:00:59 S:
> \ORACLE\PRD\SAPDATA2\SOURCED_1\SOURCED.DATA1
> 48 0 Incr 7113842263 06/14/2009 18:00:59 S:
> \ORACLE\PRD\SAPDATA13\ES700I_1\ES700I.DATA1
>
> Notice the Media ID of 002774. So far, so good.
>
> The problem occurs when working with media that has been vaulted.
>
> What occurs then is the the images on 002774 are copied to a new
> tape with a different Media ID.
> Let's say in this case the vaulted tape has a Media ID of 003500
>
> So tape 003500 goes offsite, and tape 002774 is put back in the
> scratch pool and reused.
>
> At this point the RECALL PREVIEW is reporting the incorrect Media ID,
because
> RMAN has no knowledge of the tape vaulting.
>
> This brings up some questions I have not been able to find answers to.
>
> 1) What NBU command can be used to correlate the old Media ID to the
> new Media ID?
> I have examined and tried bpimmedia, bpimagelist and vmquery. No joy.
>
> 2) I believe the (unpublished) RMAN SBT API has routines to allow the
media
> ID to be updated in the catalog in the event a tape is copied to a
> new one which
> is moved offsite. Does anyone know where the docs are regarding
> this ( I have
> looked), and if Veritas makes use of it. I have looked at the CROSSCHECK
and
> CHANGE RMAN commands, but didn't see anything relevant.
>
> That doesn't mean it wasn't there however, I just could have missed it.
>
> The whole point of this post is to learn how to use the information
> provided by
> RMAN to request the correct tapes to be returned from offsite, given a
date
> and time to restore to.
>
> Please don't suggest requesting a date range of tapes. We are already
doing
> that, and it is crude and time consuming.
>
> Thanks,
>
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist
> Oracle Blog: http://jkstill.blogspot.com
> Home Page: http://jaredstill.com
>
> Please consider our environment before printing this e-mail or
attachments.
> ----------------------------------
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or
> confidential information and is for the sole use of the intended
> recipient(s). If you are not the intended recipient, any disclosure,
> copying, distribution, or use of the contents of this information is
> prohibited and may be unlawful. If you have received this electronic
> transmission in error, please reply immediately to the sender that
> you have received the message in error, and delete it. Thank you.
> ----------------------------------
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
-----------------------------------------------------------
This e-mail was sent by GlaxoSmithKline Services Unlimited
(registered in England and Wales No. 1047315), which is a
member of the GlaxoSmithKline group of companies. The
registered address of GlaxoSmithKline Services Unlimited
is 980 Great West Road, Brentford, Middlesex TW8 9GS.
-----------------------------------------------------------
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
