Re: Changing DBID

From: Mark D Powell <Mark.Powell_at_eds.com>
Date: Sat, 12 Jul 2008 08:25:05 -0700 (PDT)
Message-ID: <6e855f93-6102-45d5-9659-982ede15b1bd@m36g2000hse.googlegroups.com>


On Jul 11, 2:13 pm, Chuck <chuckh1958_nos..._at_gmail.com> wrote:
> joel garry wrote:
>
> > I'm wondering if this may answer your delete question, at least for
> > the catalog:  http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmcat...
> > Also see unregister:
> >http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmcat...
>
> I may be wrong but I don't believe after a duplication the auxiliary
> db's backups done under the old dbid have a status of "DELETED". I think
> they are still "AVAILABLE". At least that's what "list backup" reports
> (after jumping through a few hoops to get it to even be able to list
> them). And I want them hanging around for a while in case I have to fall
> back to one of them. After all isn't that point of taking a backup in
> the first place?
>
> Also I don't want to unregister the database. That would delete all of
> the backups for the old dbid. I want them kept until they are older than
> 30 days (which is my configured retention period).
>
> These are exactly the reasons why I *want* to be able to reset the dbid
> to the original one. To simplify administrations of backups on a test
> db, in noarchivelog mode, who's backups will always be done offline, and
> where I want to use a simple "delete obsolete" to manage the old backups.

If these are test/development databases that are regularly overlaid from another source why are you backing them up with rman to begin with. Wouldn't an export taken in the middle of the night provide the necessary backup that you could keep for N time? Using rman to do the backup in this case seems like an unnecessary complication.

  • Mark D Powell --
Received on Sat Jul 12 2008 - 10:25:05 CDT

Original text of this message