Re: Why can't an RMAN job be edited in 10G dbcontrol?

From: GS <gs_at_gs.com>
Date: Fri, 06 Feb 2009 05:39:03 GMT
Message-ID: <X1Qil.9939$PH1.6010_at_edtnps82>

joel garry wrote:

> On Feb 5, 8:36 am, GS <g..._at_gs.com> wrote:

>> Charles Hooper wrote:
>>> On Feb 4, 4:38 pm, GS <g..._at_gs.com> wrote:
>>>> Thanks JG and CH
>>>> I was so caught up trying to do it via the GUI I forgot the obvious. I
>>>> checked in RMAN prompt and my retention policy was the 3 days. I don't
>>>> know why it isnt deleting them though, I'll change it to two days and
>>>> see if it works tonight.
>>>> One thing I forgot to mention was that I also wanted to tweak the script
>>>> so that it didn't delete the archives after backing them up, I want to
>>>> keep them around for a day or so so I can use them to bring clones up to
>>>> date when I build clones from a user-managed online backup. I'll just do
>>>> this from the command line though, I need to brush up a bit on the RMAN
>>>> syntax anyway.

> 
> Yeah, I still don't quite get how to separate out redundancy of arcs
> from backups, but I have enough disk space for now to not really worry
> about it.
> 


>>>> btw, my opinion on dbcontrol is the same, I still think it stinks..

>>> Noons,

>>> Thanks for the assistance.

>>> GS,

>>> About 6 months ago I read the book "Oracle Database RMAN Backup &

>>> Recovery" by Matthew Hart and Robert Freeman.  While the book was good

>>> at explaining what makes RMAN tick, I personally found that the book

>>> is actually a bit difficult to use when trying to implement a change.

>>> The section on database cloning, for instance, is more difficult to

>>> follow than Oracle's own "Backup and Recovery Advanced User’s Guide"

>>> documentation on the same topic.  Maybe it is just me.  Recently I

>>> have been reading "RMAN Recipes for Oracle Database 11g: A Problem-

>>> Solution Approach" and have found that the book puts the necessary

>>> information in the right places for accomplishing a task, although

>>> there is a bit of over repeating in the book.  While the book states

>>> that it is designed for Oracle 11g, there are output captures which

>>> show that some of the sections of the book were written using Oracle

>>> 10.2.0.x.  You might want to take a peek at "RMAN Recipes for Oracle

>>> Database 11g: A Problem-Solution Approach":
>>> http://books.google.com/books?id=qISYkSBV2hgC&pg=PA144&vq=retention+p...

> 
> Thanks for that Charles, I've only poked around in the Freeman book
> for specific things, and generally think it's only me when I don't
> quite get something.  It _seems_ well written.  You might give him
> suggestions for improvement (he has a blog, contact info there I
> think, see oracle-l).
> 


>>> I believe that the above book states that, as space is needed in the

>>> flash recovery area, those backups which are marked as obsolete are

>>> removed automatically.  It may just come down to setting an

>>> appropriate value for the DB_RECOVERY_FILE_DEST_SIZE parameter for the

>>> backups marked as obsolete to be removed automatically (do not set

>>> this value too low, and only change it after implementing the
>>> suggestions offered by Noons).

> 
> And watch out if you have multiple instances sharing the space, an
> obvious thing I missed at first.
> 


>>> Check the above book to see if page 132 applies for you regarding the

>>> archived redo logs.  The solution on page 145 seems to be an 11g only

>>> solution.

>>> DBControl will grow on you after a while.  The Oracle 9i style Java

>>> based Enterprise Manager console is available on the 10g client CD,

>>> and that Java based Enterprise Manager will also work with Oracle

>>> 11.1.0.6 and 11.1.0.7.  But, there are some tasks which cannot be

>>> completed with the Java based version which may be accomplished with

>>> the web based DBControl (you will likely find those very quickly).

>>> One further note:  Be careful which user you use to log into DBControl

>>> when setting up the backups - make certain that you always use the

>>> same user name.  It is a bit challenging sorting out problems when two

>>> backup jobs with the same name are set to start at the same time

>>> because those backup jobs were created under two different user

>>> names.  Maybe that is only a mistake that I would make...  The

>>> following SQL statement might be helpful if it happens to you also:

>>> SELECT

>>>   MJ.JOB_OWNER,

>>>   JOB_NAME,

>>>   FREQUENCY_CODE,

>>>   TO_CHAR(START_TIME,'MM/DD/YYYY HH24:MI') START_TIME,

>>>   END_TIME,

>>>   EXECUTION_HOURS,

>>>   EXECUTION_MINUTES,

>>>   INTERVAL,

>>>   MONTHS,

>>>   DAYS

>>> FROM

>>>   SYSMAN.MGMT_JOB MJ,

>>>   SYSMAN.MGMT_JOB_SCHEDULE JS

>>> WHERE

>>>   EXPIRED=0

>>>   AND MJ.SCHEDULE_ID=JS.SCHEDULE_ID;

>>> Charles Hooper

>>> IT Manager/Oracle DBA
>>> K&M Machine-Fabricating, Inc.

> 
> That's good advice, I'm always forgetting about it due to arguments
> with manager who wants everything run under root (I don't, but wind up
> doing things "wrong") <sigh>.
> 

>> Thanks Noons & Charles
>>
>> good info, I'll keep a lookout for those books..
>>
>> I've been forcing myself to use RMAN for awhile now, my user managed
>> backups have served me well but the databases are getting big and
>> bloated enough now I thought RMAN was a better route.
>>
>> I usually install the java em when I do a 10G install, just because I
>> like it better for taking a quick look at tablespaces etc., but they did
>> cripple it like you said and move a lot of the functionality to
>> dbcontrol. I do have to give grid control another go one of these days,
>> I am getting a new desktop so that may be the time. I am tempted to go
>> back to DBartisan for a multi-database front end though.

> 
> I'm trying to drink the kool-aid, it keeps making me barf.
> 

>> As far as cloning with RMAN, I find it great via the GUI when you are
>> creating a clone on the same machine, but to go through the manual steps
>> from RMAN command line I just find it so much simpler to take a user
>> managed online backup, copy the datafiles over, recreate the control
>> file and apply whatever archives you want and open it. I have it down to
>> a batch file for some servers and its simple enough the (non-oracle)
>> developers can update their db's this way. When I get GC up and running
>> then I guess you can clone to other machines much the same as MSSQL can.
>>
>> Oracle could take a few lessons looking at MSSQL's gui for creating
>> backup strategies, I know it's sort of an apples/oranges comparison
>> since you are really only backing up a schema, but I find it far better
>> than the 10G gui, and you can tweak it from the gui easily as well.
>>
>> cheers!
>>
>> ps. noons - I am still hoping to snag another 914 one of these years.. (
>> I think it was you I had a discussion with about these some years ago)- Hide quoted text -

> 
> Just to make people wistful:
> http://www.flickr.com/photos/joel_garry/2914162684/sizes/m/in/set-72157607747372485/
> (sorry the camera seems to have electronic spherical aberation
> issues).
> 
> Noons wrote:
> 

>> Guys don't scare me, please: got to get it going soon and this is *not* what I
>> want to hear...

> 
> Imagine one of those movies that are taken on a handy-cam with spooky
> things in the forest... as produced by Bollywood...
> 
> jg
> --
> _at_home.com is bogus.
> Clash of the Titans:  AT&T v. SDGE
> http://www3.signonsandiego.com/stories/2009/feb/05/1n5sdge23824-chorus-grows-against-sdgampe-power-cu/?zIndex=48065

Dang thats nice.. Factory 6's must be a rare bird these days. The guy I bought my last 2.0 engine from just before I sold my '73 had just yanked it and put in a 2.7 out of an early Carrera into his 74 special edition (remember the black & gold ones?) He put the proper kit in that enabled the original 4's to put flat 6's in them.

I'll have to dig up some pics and post them somewhere.. Received on Thu Feb 05 2009 - 23:39:03 CST