1. IOUG Collaborate -- April 16, 2008 1 Part 1 -- RMAN in the Trenches: To Go Forward, We Must Backup Philip Rice Univ. of California Santa Cruz Session #315 UCSC mascot: Banana Slug

2. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 2 Background/Overview  Using RMAN since 8.1  Parts 1 & 2 presented in 2007 (nocoug.org) [Reviewed for accuracy]  Q1 2008 SELECT Journal article (combo of 1&2)  Part 1 focus: Beginner, some Intermediate

3. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 3 Backup Types: Basics  Cold backups simple, not worth doing w/ RMAN  Two formats, both check for corruption and capture completion info for recovery: Backupset: several types of compression Backupset: several types of compression Image Copy: same as OS copy, no compression, more suited to fast recovery Image Copy: same as OS copy, no compression, more suited to fast recovery

4. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 4 Incremental Level 0 & 1  Incrementals (vs. Full): space saver Level 0: for RESTORE – datafile content Level 0: for RESTORE – datafile content Level 1: for RECOVER – block changes Level 1: for RECOVER – block changes  If most blocks change daily, Incremental may not be best, unless used for rolling forward Image Copy in 10g

5. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 5 Example: Incremental Level 0 & 1 Level 0 every 7 days (50 GB), Level 1 other days (10 GB)

6. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 6 Retention: Redundancy  Retention Policy based on either: REDUNDANCY -- number of backup copies at any time -OR- REDUNDANCY -- number of backup copies at any time -OR- a RECOVERY WINDOW – time span for PIT a RECOVERY WINDOW – time span for PIT  REDUNDANCY 1 is default

7. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 7 Retention: Redundancy  For REDUNDANCY 1: When new Level 0 is done, previous incrementals are OBSOLETE, i.e. not needed for retention requirement  Maybe good for Dev DB, PIT of 0-6 in our example, effectively no PIT guaranteed

8. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 8 Cumulative sizing: Redundancy 1 example

9. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 9 Retention: Window 7 Days  For guaranteed PIT, specify number of days in RECOVERY WINDOW Window is PIT to any time in past days: RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 days;  Not sliding window with deletes after 7 days! After Level 0 on Day 8, prior Level 0 still needed. Max of three Level 0s at one time, normally two. In our example, max size is 270 GB.

10. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 10 Cumulative sizing: Window 7 Days example

11. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 11 Retention Window: Best Use of Space  For any DB where Level 1 is moderate size, best use of space is one day less than multiple of Level 0 frequency. With a Level 0 every 7 days: 6 or 13 or 20 day Recovery Window

12. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 12 Retention Window: Use of Space Example: 6,7,13 day retention, Level 0 every week

13. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 13 DELETE placement in script  Now consider a half dozen DBs of the same size in one backup script...

14. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 14 DELETE placement in script  Pseudocode for backup script: for ORACLE_SID in [DBs to be backed up] RMAN> BACKUP level = 0 CHECK LOGICAL tag LVL0 database; RMAN> DELETE NOPROMPT OBSOLETE; [End loop] DELETE at end needs extra 50 GB temporarily each time through loop DELETE in front is two Level 0s until next day: (50X6) = 300GB extra required  FRA clears automatically, when space exceeds quota

15. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 15 Naming Convention: setting FORMAT  CONFIGURE persistently sets value once per DB, can simplify scripting: RMAN> CONFIGURE CHANNEL DEVICE TYPE disk FORMAT = '/orabackup/%d/%d_%s_%p_%t'; RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON; RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE disk TO '/orabackup/%d/%d_%F'; RMAN> SHOW ALL;

16. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 16 Compression  9i: NULL compression: blocks never used 10g: binary compression 10.2.0.2: empty blocks, used or not  Oracle recommends not mixing RMAN vs 3 rd party methods  We have hardware tape compression -- OK (?) Benefit is disk savings (longer PIT Window), quicker to tape  Flash Recovery Area: ideas valid also – less space allocation required with combo of Compression and DELETE placement in script

17. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 17 On the Space/Time Continuum: Example  Old Sun box (CPU speeds circa 2001): 9.2 Level 0 non-compressed: ~29 minutes => 39.2 GB 9.2 Level 0 non-compressed: ~29 minutes => 39.2 GB 10.2 Level 0 compressed parallel 1: ~4 hours => 6.2 GB 10.2 Level 0 compressed parallel 1: ~4 hours => 6.2 GB That's better than a 6:1 ratio for space, but 8 times as long to run That's better than a 6:1 ratio for space, but 8 times as long to run  Sun V490 (2006, faster CPU): w/ parallel 2, 41 minutes

18. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 18 On the Space/Time Continuum  OTN tuning paper advises 1 channel per tape drive or physical disk. Do not necessarily assume faster with more channels. Do not necessarily assume faster with more channels. But higher parallel gives more CPU, which helps compression time. But higher parallel gives more CPU, which helps compression time.  RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 2 backup type to COMPRESSED BACKUPSET;

19. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 19 Restore optimization  Restore optimization, 9i+: file not restored from backup if already in correct location and expected info is found No action required, always “turned on” No action required, always “turned on” Helpful for interruption, e.g. power failure Helpful for interruption, e.g. power failure Especially helpful with tape (slow) Especially helpful with tape (slow)

20. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 20 Backup Optimization  CONFIGURE BACKUP OPTIMIZATION ON; RMAN job must use channel of only one device type

21. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 21 Backup Optimization  Applies to: BACKUP DATABASE BACKUP DATABASE BACKUP ARCHIVELOG with ALL or LIKE options BACKUP ARCHIVELOG with ALL or LIKE options BACKUP BACKUPSET ALL BACKUP BACKUPSET ALL BACKUP RECOVERY AREA BACKUP RECOVERY AREA BACKUP RECOVERY FILES BACKUP RECOVERY FILES BACKUP DATAFILECOPY BACKUP DATAFILECOPY

22. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 22 Backup Optimization  When to use? Read-only tablespace Read-only tablespace Off-line tablespace Off-line tablespace Archives in original location multiple days Archives in original location multiple days BACKUP BACKUPSET: If not turned ON, you’ll have copy of Level 0 every day! BACKUP BACKUPSET: If not turned ON, you’ll have copy of Level 0 every day!

23. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 23 Backup Optimization  Scenario: Multiplex archives to two locations, backup each day, but keep archives on the original disk location for 3 days: RMAN> BACKUP archivelog all; RMAN> DELETE archivelog until time 'sysdate-3‘;

24. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 24 Backup Optimization  Optimization OFF: rc_backup_redolog shows one backup copy for each distinct redo log sequence number (multiplex ignored), but one backup copy for each day that archive remains on disk True for BACKUP BACKUPSET too: multiple Level 0s go to tape, can make a huge difference  Optimization ON: just one backup copy

25. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 25 Have Ops write to tape, instead of RMAN?  Simplicity makes it appealing  Catalog only knows disk metadata, no awareness of tape content  Only one RMAN retention period per DB. Simplest is if same PIT requirement for disk and tape; can let tape system age out backups, because tape is not used directly for recovery, can be copied to disk, metadata for disk is used.  10g can register backup piece in catalog, not 9i

26. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 26 RMAN write to tape, not Ops  SysAdmin install, symlink from Oracle Home  Vendor MML msgs, diagnostic limitation  Licensing issues – central vs. each client  Godot, or Agnostic Dial-A-Prayer

27. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 27 RMAN writes from disk to tape  BACKUP BACKUPSET Avoids need to read from source again Avoids need to read from source again Metadata known for both destinations: If backup disk area dies, tape is automatically used for recovery Metadata known for both destinations: If backup disk area dies, tape is automatically used for recovery Can go disk to disk, disk to tape, but not tape to tape (VTL implication) Can go disk to disk, disk to tape, but not tape to tape (VTL implication)

28. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 28 Clearing Out Old Entries in Tape Index: Do you have delete privileges?  Yes – RMAN is the driver: Use KEEP clause, plus DELETE OBSOLETE Use KEEP clause, plus DELETE OBSOLETE KEEP is not in CONFIGURE, must be in script KEEP is not in CONFIGURE, must be in script Alternate: set tape retention policy, do delete obsolete for tape, separately for disk w/ shorter span, e.g. RMAN> DELETE OBSOLETE DEVICE TYPE DISK RECOVERY WINDOW OF 7 DAYS; Alternate: set tape retention policy, do delete obsolete for tape, separately for disk w/ shorter span, e.g. RMAN> DELETE OBSOLETE DEVICE TYPE DISK RECOVERY WINDOW OF 7 DAYS;

29. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 29 Clearing Out Old Entries in Tape Index: Do you have delete privileges?  No – tape system controls maintenance: Must do CROSSCHECK plus DELETE EXPIRED Must do CROSSCHECK plus DELETE EXPIRED Variation: different tape profiles, different periods Variation: different tape profiles, different periods

30. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 30 Specifying Device in Scripts  Script 1: BACKUP to disk Do not specify device in BACKUP command: let it use disk default Do not specify device in BACKUP command: let it use disk default DELETE OBSOLETE: catalog knows about tape too – have delete privilege from tape? DELETE OBSOLETE: catalog knows about tape too – have delete privilege from tape? NO: specify DEVICE DISK so RMAN does not try communicate with tapeNO: specify DEVICE DISK so RMAN does not try communicate with tape YES: you can leave out device type referenceYES: you can leave out device type reference

31. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 31 Specifying Device in Scripts  Script 2: BACKUP BACKUPSET – disk to tape Must specify DEVICE TYPE SBT (acronym for System Backup to Tape) so it does not try use the default disk device Must specify DEVICE TYPE SBT (acronym for System Backup to Tape) so it does not try use the default disk device Catalog Maintenance: Device already specified above – have delete privilege from tape? Catalog Maintenance: Device already specified above – have delete privilege from tape? NO: use CROSSCHECKNO: use CROSSCHECK YES: you can use DELETE OBSOLETEYES: you can use DELETE OBSOLETE

32. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 32 Specifying Device in Scripts  Script 3: RESTORE/RECOVER With CONFIGURE to set up auto allocation, catalog knows everything to complete these tasks, no need to specify a device With CONFIGURE to set up auto allocation, catalog knows everything to complete these tasks, no need to specify a device Inside retention period, everything comes from disk, unless space pressure in FRA (insufficient allocation) requires transfer to tape, with auto delete from disk Inside retention period, everything comes from disk, unless space pressure in FRA (insufficient allocation) requires transfer to tape, with auto delete from disk Otherwise, one or more tape channels auto allocated, depending on PARALLELISM specified in CONFIGURE command Otherwise, one or more tape channels auto allocated, depending on PARALLELISM specified in CONFIGURE command

33. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 33 The Good, The Bad, The Ugly (a Sampling)  Many features well thought out, e.g. Complex rules for OPTIMIZATION, different for disk and tape Complex rules for OPTIMIZATION, different for disk and tape Use of features outside of script allows more generic script, e.g. binary compression with CONFIGURE, Block Change Tracking turned on from SQL Use of features outside of script allows more generic script, e.g. binary compression with CONFIGURE, Block Change Tracking turned on from SQL

34. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 34 The Good, The Bad, The Ugly (a Sampling)  Significant space savings from incrementals plus several types of compression; PIT is easier with more days on disk  Bonus from doing incrementals: covers for when object is created with NOLOGGING option  Plenty of detail to learn (unavoidable Bad)

35. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 35 The Good, The Bad, The Ugly (a Sampling)  For A Few Dollars More, can we fix the ugly?!?  LIST command is for basic reporting: VERBOSE or SUMMARY, nothing in between VERBOSE or SUMMARY, nothing in between What if we want to see backupset file names? Can’t use SUMMARY; VERBOSE shows a bit of what we want in lots of output What if we want to see backupset file names? Can’t use SUMMARY; VERBOSE shows a bit of what we want in lots of output Limiting based on device type not easy Limiting based on device type not easy RC* and V$* views offer more control RC* and V$* views offer more control

36. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 36 Cover Your Sixes...

37. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 37...so you don’t get caught by surprise!

38. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 38 Cover Your Sixes  CHECK LOGICAL is not default  The ALL keyword has somewhat different meaning, depending on context: BACKUP ARCHIVELOG ALL gives one copy of distinct log sequence from multiplexed archive locations BACKUP ARCHIVELOG ALL gives one copy of distinct log sequence from multiplexed archive locations DELETE ALL refers to every log, including multiplexed DELETE ALL refers to every log, including multiplexed

39. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 39 Cover Your Sixes  Similar commands below -- Be clear about what you are deleting, originals or backups: RMAN>DELETE FORCE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-30'; ------------------------------------------------------- RMAN>DELETE FORCE BACKUP OF ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-30';

40. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 40 Cover Your Sixes  PARALLELISM: Number of automatic channels, e.g. tape allocated for RESTORE Number of automatic channels, e.g. tape allocated for RESTORE Not number of server processes per channel as I originally assumed Not number of server processes per channel as I originally assumed OTN tuning paper advises 1 channel per tape drive or physical disk OTN tuning paper advises 1 channel per tape drive or physical disk But higher parallel gives more CPU, which helps compression time But higher parallel gives more CPU, which helps compression time

41. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 41 Conclusion -- Objectives  Show how simple choices affect use of space/time: Multiple of Level 0, minus 1 day Multiple of Level 0, minus 1 day Put “delete obsolete” at end of script Put “delete obsolete” at end of script  Choose good practices for features, e.g.: Compression – 3 types, allows longer retention Compression – 3 types, allows longer retention Optimization – esp. Level 0 to tape! Optimization – esp. Level 0 to tape! Disk/tape use: Ops vs. MML Disk/tape use: Ops vs. MML  Cover your sixes. Misunderstanding a feature could lead to a surprise.

42. IOUG Collaborate -- April 16, 2008RMAN in the Trenches 42 A & Q  Evaluations -- Session 315 : RMAN in the Trenches Philip Rice price [at] ucsc.edu  Acknowledgements: Timothy Chien, Oracle Principal Product Mgr. Bill Wagman, UC Davis  A & Q Answers: Wisdom to share?Questions?