Re: Changing DBID
From: Chuck <chuckh1958_nospam_at_gmail.com>
Date: Mon, 14 Jul 2008 17:40:30 GMT
Message-ID: <icMek.220$6O4.124@trnddc06>
>> 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.
Date: Mon, 14 Jul 2008 17:40:30 GMT
Message-ID: <icMek.220$6O4.124@trnddc06>
Mark D Powell wrote:
> 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 -- > >
They are too big for export to finish in a timely manner and there's plenty of development time and work that transpires between the refreshes so I dont want to risk losing it. Hence I do backups after refreshing, while work is going on. Eventually that work will be extracted and migrated to production. Then it will be time for another refresh (eventually). There may be 20+ backups taken before then though. Received on Mon Jul 14 2008 - 12:40:30 CDT