Newsgroups: comp.databases.oracle.server From: JEDIDIAH Subject: Re: Backup trends (2): HOT or COLD References: <406e65bd$0$4543$afc38c87@news.optusnet.com.au> Message-ID: User-Agent: slrn/0.9.8.0 (Linux) NNTP-Posting-Host: 64.123.34.33 Date: 9 Apr 2004 14:29:28 -0400 X-Trace: news.athenanews.com 1081535368 64.123.34.33 (9 Apr 2004 14:29:28 -0400) Lines: 57 X-Complaints-To: abuse@athenanews.com Path: newssvr20.news.prodigy.com!newsmst01a.news.prodigy.com!prodigy.com!newsfeed.telusplanet.net!newsfeed.telus.net!news3.optonline.net!feed4.newsreader.com!newsreader.com!news.athenanews.com!not-for-mail Xref: newssvr20.news.prodigy.com comp.databases.oracle.server:259277 On 2004-04-03, Howard J. Rogers wrote: > > > "Bob Jones" wrote in message > news:LDnbc.23629$He5.450838@bgtnsc04-news.ops.worldnet.att.net... >> >> "Sybrand Bakker" wrote in message >> news:iu7r60pn591202gj49596rvg82s32qr7gq@4ax.com... >> > On Fri, 2 Apr 2004 07:37:30 +0000 (UTC), Lucyna Witkowska >> > wrote: [deletia] > It is true. RMAN does an intelligent read of Oracle blocks and then an > intelligent write. That's good because it understands the concept of an > Oracle block, so yes it skips any that are empty. It does that > automatically. Optionally, it also does something which no O/S script has a > hope in hell of pulling off: namely, comparing the age of an Oracle block > with the age of the same block in a prior backup, and if the two are the > same, skipping the block. That, of course, is the basis for an incremental > backup. At the Oracle block level. And in 9i, RMAN can recover at the block > level too. > > So yes, it has lots of nice features. But those are merely incidental to the > real reason why you should use RMAN in preference to O/S scripts: > performance. RMAN doesn't cause the database to generate 20 or 30 times the > amount of redo per transaction that O/S hot backups do. RMAN doesn't hammer Certainly a valid point. > one data file to death before moving on to another, but instead multiplexes > across many datafiles, little bits being taken from each one in turn. RMAN This is a just a simple coding and configuration issue. If you take our korn coding as seriously as the rest of your DBA duties, this should never be a problem. > parallelises in a way no O/S script never could. And you can throttle the > I/O rate up or down for RMAN to minimise the impact on the production > database or to maximise the speed at which the backup is done. Any of this can be crudely estimated using less complicated tools. > > RMAN doesn't require maintenance if datafiles are added, either, so I'm not > sure what the point of mentioning that was. The original comparison was likely to some really shoddy scripts. [deletia] -- The public has a right to free music. It's part of the bargain that was originally made with musicians and publishers. It's time that the ||| debate was shifted to reflect that. Robber Barons and their Toadies / | \ are distracting us from the original facts of the situation.