Re: RMAN - Best Practices

If you copy a database (i.e. copy the underlying datafiles, edit control file and init.ora) and bring it up under another name, then the dbID is the same and you can't register it in the same catalog as the first database.

So you have to create another catalog, and register the clone there.

Since that is how many of the databases in this environment were created (whether that was a good or bad idea, feel free to comment, I wasn't there at the time), I'm going to have to build a bunch of catalogs. So, I figured I might as well standardize on 1 database 1 catalog (for the time being till I have to recreate these databases for one reason or another).

I don't know why you say "Version names... absolutely not", the catalogs are different between versions, so why not name them as such.

please comment
Jay

--
Jake
"Howard J. Rogers" <howardjr_at_www.com> wrote in message
news:39f727af_at_news.iprimus.com.au...


> I'm obviously missing the point here, but you only ever need to register

 the


> thing once.  After that it is regularly re-synched (either manually, or as

> part of doing a backup or restore operation).  And if you ever do a

> resetlogs on the target, then a reset operation on the catalogue would

 need


> to be performed.

>

> As for having a different schema for each target, absolutely not.

>

> Version names... absolutely not.

>

> Sizing: If your RMAN tablespace is around 20Mb per target per year, you'll

> be in the right ball park.

>

> Where to write the backup sets etc : Anywhere that won't cause i/o

 conflict


> and slow the thing down.  Personally, I'd have a separate hard disk for

 the


> outputs, but then I have shares in Seagate.

>

> Can you trust RMAN and use 'delete input'?  Can you trust anything these

> days??!  The answer is yes, it is reliable as far as checking that there

 are


> no corruptions in the files it is backing up.  But it is only a piece of

> software, and even Larry (praise be to He) is not capable (yet) of writing

> software that has no bugs or imperfections.  Do I ever delete archives

> therefore?  No, I don't compress them or whip 'em off onto tape at the

> earliest possible moment... I keep a week's worth on disk, before ageing

> them off onto another disk... before finally writing them onto tape.  And

> yes, I have shares in Seagate.

>

> Don't make RMAN harder for yourself than it actually (and already) is.

 Set


> it up as it was intended to be set up: one RMAN User, one RMAN tablespace,

> one catalogue per several databases.  It's a tool.  When the tool needs to

> be upgraded, deal with the issues then (and what you describe below isn't

> going to help you any when that time comes).

>

> Regards

> HJR

> --

> --------------------------------------------------------------------------

> Opinions expressed are my own, and not those of Oracle Corporation

> Oracle DBA Resources:               http://www.geocities.com/howardjr2000

> --------------------------------------------------------------------------

>

> "Jake" <jjstrauss_at_yahoo.com> wrote in message

> news:tGAJ5.3886$vy5.280927_at_e420r-sjo3.usenetserver.com...

> > While that may let me register the other database (2).  I want to

 register


> > all of the databases.  Won't I run into the same problem?  i.e. I

 unregister


> > database (1), register database (2), then try to register database (1)

> > again.

> >

> > Thanks

> > Jake

> >

> > "roosterjax" <roosterjax_at_earthlink.net> wrote in message

> > news:QXtJ5.22200$rD3.1459597_at_newsread2.prod.itd.earthlink.net...

> > > Hi Jake,

> > >

> > > Perhaps the easiest thing to do here is to unregister the databases

 and
 then


> > > re-register. This is done by first listing  the databases that are

 already


> > > registered in the catalog. To do this connect to the schema in the

 catalog


> > > ( rman805 ) using SQL*Plus then :

> > >

> > > select db_name,a.db_key,db_id,dbinc_key

> > > from db a, dbinc b

> > > where a.db_key = b.db_key

> > >

> > >

> > > This will tell you the databases registered and their db_key and db_id

 which


> > > can then be used

> > > to unregister them.

> > >

> > > to do this use

> > >

> > > EXECUTE dbms_rcvcat.unregisterdatabase(db_key, db_id);

> > >

> > > You can then register the databases that you wish.

> > >

> > >

> > > Nevin Hahn

> > > nhahn_at_evoke.com

> > >

> > >

> > >

> > > "Jake" <jjstrauss_at_yahoo.com> wrote in message

> > > news:e5rJ5.1609$vy5.99893_at_e420r-sjo3.usenetserver.com...

> > > > Hi,

> > > >

> > > > I'm just getting started with RMAN (v8.0.5).  I understand that the

> > > > structure of the catalog changes from release to release (i.e. 805

 is


> > > > different than 8.1.5, is different from 8.1.6...).

> > > >

> > > > So I named my schema rman805, with the intent to build another

 schema


> > > > rman816 when I finally upgrade.  I intended to register all my

 databases
 in


> > > > a single schema (prd, dev, tst...).

> > > >

> > > > But I'm running into a "database already registered" error.  The doc

 leads


> > > > me to believe its because the prior DBA copied the databases (i.e.

 copied


> > > > the files, edited the control file, and started the database under a

> > > > different name).

> > > >

> > > > So, How are you guys doing this:

> > > >

> > > > - For each target database, are you building a new schema and

 installing
 the


> > > > catalog?

> > > >

> > > > - For each database version are you naming the schema with that

 version
 in


> > > > the name?

> > > >

> > > > - If your building a separate schema for each database, how big

 should
 that


> > > > users default tablespace be: I've seen 10M, 50M, and 100M in

 different


> > > > oracle docs.

> > > >

> > > > - Where are you writing your rman files i.e.

 /u01/app/oracle/admin/SID/rman?


> > > >

> > > > - I'm afraid to use the "delete input" clause when I backup my

 archive
 logs.


> > > > Can I trust that the rman backup of the archives won't be corrupt?

> > > >

> > > > I appreciate your thoughts

> > > > Thanks

> > > > Jay

> > > >

> > > >

> > > >

> > > >

> > > >

> > > >

> > >

> > >

> > >

> >

> >

> >

> >

>

>