ADSM-L

Re: [ADSM-L] Nervous Nellies and TDPO -- feasible?

2007-11-22 06:47:44
Subject: Re: [ADSM-L] Nervous Nellies and TDPO -- feasible?
From: CAYE PIERRE <Pierre.Caye AT ALCATEL-LUCENT DOT FR>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 22 Nov 2007 12:47:06 +0100
Hi,

There are other technicals approach, with for example split backup technics.

Split backup work with a dedicated machine, acting as backup client.
This machine is connected with a set of disk which are a snapshot of the 
database to backup.
After the snapshot, the database is mounted then backed up.
Interruption, or penalty, of service on the original database is reduced to the 
snapshot time.
The backup, performed from a machine which is out of production uptime needs 
can be performed at a low speed.
RMAN manage on it side the consistency of datas, because it know the primary db 
and it can check if the split db data's are consistent and so.

Pierre

> -----Message d'origine-----
> De : ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] De 
> la part de David McClelland
> Envoyé : mercredi 21 novembre 2007 17:42
> À : ADSM-L AT VM.MARIST DOT EDU
> Objet : Re: [ADSM-L] Nervous Nellies and TDPO -- feasible?
> 
> Pierre, great answers.
> 
> I'd add that, depending upon your business recovery 
> requirements, you may wish to embrace disk/array/snapshot 
> based backup and recovery tools _as well_ as RMAN. If you've, 
> for example, a 5TB database and a business-stated 4 hour 
> recovery time objective for your service/database then you're 
> going to have to drive disk/tape very hard indeed to meet 
> your service recovery requirements with RMAN alone. 
> 
> For larger databases with tight recovery times, RMAN > TSM 
> can be used as a complement to disk/nearline based recovery 
> methods (e.g. BCV, Clone or Snap on EMC storage hardware), 
> providing for longer-term retention (e.g. for regulatory 
> requirements) and more granular recoveries (e.g.
> table level rather than the whole database). If the majority 
> of recovery scenarios to get a service back online are within 
> 24 hours from the point of backup, a daily BCV/Snap whatever 
> might meet this very ably, regardless of whether you're also 
> backing up to offline media via RMAN or BA client backups.
> 
> In terms of responding to a recovery point requirement (e.g. 
> the business can afford to lose no more than x 
> days/hours/minutes' worth of data in a disaster), RMAN can 
> make sure your archived redo logs are shipped out very 
> efficiently, and what's more make a pretty easy job of 
> recovering them too. Another thing to consider is an RMAN 
> Recovery Catalog - I'll not go into detail here, but do look 
> this up if you aren't already familiar with the concept.
> 
> In a nutshell, as well as looking at the backup technology, 
> take pains to look at what your _recovery_ requirements are - 
> regardless of how much more efficient RMAN may or may not be 
> than BA client backups, if either alone won't help you to 
> meet your service RPO/RTO SLAs then you may in addition need 
> to look elsewhere, for example disk array/nearline backups.
> 
> HTH,
> 
> David McClelland
> London, UK
> 
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] 
> On Behalf Of CAYE PIERRE
> Sent: 21 November 2007 15:56
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Nervous Nellies and TDPO -- feasible?
> 
> >     1) RMAN doesn't deal with non-transactional DB data loads well.
> >        (i.e. data loaded not through the usual INSERT/UPDATE
> >        methods, but done via sqlldr. This doesn't generate redo
> logs.)
> > 
> >        True or false?
> 
> RMAN back-up data's which are in all tables, whatever they 
> had been loaded or inserted.
> 
> >     2) RMAN requires a recovery database be created to do recoveries
> to
> >        (instead of recovering to original database/tablespaces
> in-place).
> > 
> >        True or false? I thought RMAN didn't need an intermediate
> temp
> >        database and could restore directly 'in-place'.
> 
> False. Rman is able to restore databases on original place, 
> or anywhere you wish. It only requier a large enough database.
> 
> >     3) Will RMAN guarantee a good point-in-time view of DB data?
> 
> It depend of the regularity and disponibility of redo logs, 
> which need to backed-up too...
> 
> >     4) Same as #3 above, but what if the DB is currently processing
> >        a large series of INSERTs or UPDATEs or sqlldr run, will RMAN
> >        only send data that was present at the moment of backup
> start?
> 
> Rman perform backup wwhich will be consistent; whatever 
> happend on the db as insert delete, update and so. RMAN is a 
> part of oracle product, not an external actor, and act at a 
> logical level of data's. At the end of the rman backup, 
> data's are consistent and could be restored in a consistent state.
> 
> >     5) Does RMAN/TDPO use scale to really large DB setups? Say, tens
> >        or hundreds of terabytes? Or even sub-10 TB?
> > 
> >        Anybody using TDPO well with terabytes of Oracle data? (I
> >        think they're hoping for assurances that it really does work
> >        in the real world at that scale.)
> 
> I'd only experienced db of 2/3 Terabytes and it work fine, 
> whithout any particular configuration on Oracle side.
> See Oracle guides for best practices concerning very large databases.
> 
> >     6) How does Oracle RMAN know what rows to send for an
> >        incremental backup? Does Oracle maintain a bitmap of some
> kind
> >        or time-based logging of changed blocks or something? Any
> >        pointers to whitepapers or information on how it works behind
> >        the scenes?
> 
> On Oracle 10g, Oracle maintain a bitmap of changed block.
> So incremental backup are faster than full backup on 10g. 
> On Oracle 9i, Oracle scan all filespaces for changed block.
> So incremental backups can be slower that full but, from my 
> experience, it is almost the same.
> 
> >     They would prefer to utilize Veritas DB Edition (DBED)
> checkpoint 
> > feature which is where a script runs to put all tablespaces 
> in backup 
> > mode, brings DB-based filesystems to a consistent state, generate a 
> > checkpoint (snapshot-like) of the filesystem, then brings all 
> > tablespaces back to online mode. The TSM BA client then mounts the 
> > most recent checkpoint R/O then backs it up at the file level.
> > 
> >     The problem with the above approach is this essentially results
> in 
> > what amounts to a full backup every single time it kicks 
> off. That's 
> > just not practical in terms of tape cost as well as the length of 
> > backups.
> > 
> >     I see TDPO as the only practical choice for much faster and more
> 
> > frequent backups (and restores) and is guaranteed for consistent 
> > point-in-time views of DB data. The BA client was also not meant to 
> > back up databases (though it *could* do so if properly quiescied).
> 
> Nothing more to said. You're right. TDPO act only as a 
> library manager for RMAN. It is RMAN which is the principal 
> actor on back-up.
> RMAN is an integrated Oracle solution to backup Oracle databases.
> Integrated mean that it work fine at logical level of the 
> data's. The use of RMAN, for offline (full) or online 
> (incremental) backup is a guarantee for consistencies of 
> backed-up data's. 
> You work with Oracle 10g, so incremental back-up will be fast 
> and you will save storage and time.
> 
> >     My issue? I don't have enough meaty information yet to put
> concerns 
> > to rest, and I'd really like to make use of TDPO after paying out 
> > $16,000. Any info would be much welcome.
> 
> Search on IBM/redbooks. There are redbooks about RMAN and 
> TDPO (sorry I don't remind reference number...).
> 
> Pierre
> 
> 
> This email was sent to you by Reuters, the global news and 
> information company. 
> To find out more about Reuters visit www.about.reuters.com
> 
> Any views expressed in this message are those of the 
> individual sender, except where the sender specifically 
> states them to be the views of Reuters Limited.
> 
> Reuters Limited is part of the Reuters Group of companies, of 
> which Reuters Group PLC is the ultimate parent company.
> Reuters Group PLC - Registered office address: The Reuters 
> Building, South Colonnade, Canary Wharf, London E14 5EP, 
> United Kingdom Registered No: 3296375 Registered in England and Wales
>