Steve - That was it. Thanks for the humor.
Dennis Williams DBA, 40%OCP Lifetouch, Inc. [EMAIL PROTECTED] -----Original Message----- Sent: Thursday, January 09, 2003 6:14 PM To: Multiple recipients of list ORACLE-L Never heard of the q29_6 parameter. :-) Looks like excess glue spilled during a cut and paste operation. -----Original Message----- <mailto:[EMAIL PROTECTED]> ] Sent: Thursday, January 09, 2003 3:24 PM To: Multiple recipients of list ORACLE-L Brian - You may want to be aware of the following parameter: q29_6There are several new features that are present in the Oracle8 control file, so that it is significantly changed from and larger than the Oracle7 control file. The Oracle8 control file stores information that is of use to RMAN. Some of this information is recycled, while other information is permanent. A new parameter called CONTROL_FILE_RECORD_KEEP_TIME allows the DBA to specify the period of time after which data in recyclable portions of the control file expire so that the space in the control file that the data occupied can be reused. If more of this RMAN information needs to be stored, and the old information has not expired, then the control file will expand to accommodate the new data as well as the old. The value for CONTROL_FILE_RECORD_KEEP_TIME is specified as an integer, representing the number of days recyclable data will be stored before it expires. When this parameter is set to 0, the control file will not expand, allowing Oracle to expire the recyclable data as needed, to make room for new data. Dennis Williams DBA, 40%OCP Lifetouch, Inc. [EMAIL PROTECTED] -----Original Message----- Sent: Thursday, January 09, 2003 3:54 PM To: Multiple recipients of list ORACLE-L I agree Steve, and thanks for the info. Do you have any procedures to cover backup logic holes if you have to rebuild the controlfile for some reason (Ie.. maximum files reached etc) Do you accept losing the backup history and cross fingers or ... have procedure to account for that? Brian -----Original Message----- Sent: Thursday, January 09, 2003 4:07 PM To: Multiple recipients of list ORACLE-L You can have a very large site and still do just fine without an RMAN repository. RE the "non-database solution," Oracle has already done that, it's called the controlfile. I tend to agree with Robert F. who "wrote the book" on RMAN where, in another post he wrote, "I actually find the repository of little use. If I have an enterprise with many databases then I will use it for reporting but that's about it. It just seems to complicate the overall administrative costs and thus, the burden/benefit ratio is not all that good." Use of the RMAN repository WAS "strongly recommended" by Oracle in the past but things have changed and that "truism" no longer holds. You can see this transition if you compare the recommended practices in the current Oracle documentation against recommended practices in the old docs (8.0 or even the 7.X EBU stuff). I'm not the least bit surprised that Oracle is working on eliminating this silly dependency on another database. The only dependencies should be, "Is the Oracle software installed on the machine you want to recover to and does it have access to the backup media?" IMHO, :-) Steve Orr -----Original Message----- < mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > ] Sent: Thursday, January 09, 2003 12:24 PM To: Multiple recipients of list ORACLE-L Steve - My theory is that if your site is sufficiently large to be worth considering an RMAN catalog configuration, then you can easily find a location for it. For us, that was easily solved. If Oracle had created a non-database solution, then that would have become a development project all its own. And people would have pointed out the contradiction of a database company creating a non-database solution. And we would have whined about having to learn a non-SQL interface. But where Larry is concerned I would never count out the profit motive. Dennis Williams DBA, 40%OCP Lifetouch, Inc. [EMAIL PROTECTED] -----Original Message----- Sent: Thursday, January 09, 2003 12:18 PM To: Multiple recipients of list ORACLE-L Yeah but do you have to pay for another Veritas NetBackup license and server to backup the catalog? If just have one database server and one database license why should I have to buy another license and install another 1-2GB of Oracle software on another server? The only answer I can think of is so Larry can spend more money on yachts, planes, and cars. Contrary to Oracle Corporate aspirations, not all data in the universe really needs to be stored in Oracle databases, especially backup information about Oracle databases I want to backup. If I need a database to backup a database then do I need another database to backup the database that backed up the original database? ;-) Seems the simple solution to this silliness is just to remove the requirement of having a database to backup a database. Steve Orr -----Original Message----- < mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> < mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > ] Sent: Thursday, January 09, 2003 10:50 AM To: [EMAIL PROTECTED] Cc: Orr, Steve Importance: High > The overhead of the repository database is more. With the initial releases of RMAN (EBU) Oracle was rightly > criticized for the fact that you had to backup the database that holds information about the database you want to backup. > Getting rid of this silliness seems reasonable to me. Why silly? It isn't any more silly than making a separate backup of the Veritas Netbackup catalog. It's just a different level of abstraction. Jared "Orr, Steve" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 01/09/2003 08:45 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> cc: Subject: RE: RE : RMAN Repository If you aren't using a repository all you have to do is make sure control file backups are part of the routine. There are 2 ways to backup the backup metadata: 1) the RMAN repository database; 2) backup controlfiles. Functionally and operationally they're pretty much the same. The only things you can't do with controlfile RMAN/database metadata is: 1) use previous "incarnations" of the database for recovery; 2) use database stored scripts. No big deal as far as I'm concerned. When RMAN first came out a separate repository database was a requirement. Subsequent releases added some functionality for using controlfiles. The vulnerability of losing the repository or losing the backup controlfile is about equivalent. The overhead of the repository database is more. With the initial releases of RMAN (EBU) Oracle was rightly criticized for the fact that you had to backup the database that holds information about the database you want to backup. Getting rid of this silliness seems reasonable to me. Steve Orr-man for RMAN, Bozeman, Montana -----Original Message----- < mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> < mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > ] Sent: Wednesday, January 08, 2003 2:14 PM To: Multiple recipients of list ORACLE-L Importance: High And how does one go about restoring a database when all control files are lost, and the only recovery data is stored in the control file? This doesn't sound very reasonable. Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
