# Oracle RMAN 11g Backup and Recovery- P14

Chia sẻ: Thanh Cong | Ngày: | Loại File: PDF | Số trang:39

0
93
lượt xem
18

## Oracle RMAN 11g Backup and Recovery- P14

Mô tả tài liệu

Oracle RMAN 11g Backup and Recovery- P14: Oracle, yet another edition of our RMAN backup and recovery book has hit the shelves! Oracle Database 11g has proven to be quite the release to be sure. RMAN has new functionality and whizbang new features that improve an already awesome product. RMAN has certainly evolved over the years, as anyone who started working with it in Oracle version 8 can attest to.

Chủ đề:

Bình luận(0)

Lưu

## Nội dung Text: Oracle RMAN 11g Backup and Recovery- P14

1. 618 Part V: Appendixes recordSpec This subclause defines which objects that commands such as change, crosscheck, delete, and list will work on. Syntax Diagram , ’ filename ’ ARCHIVELOG , primaryKey , BACKUPSET primaryKey , ’ media_handle ’ , BACKUPPIECE primaryKey PROXY ’ ’ TAG tag_name , ’ filename ’ , primaryKey CONTROLFILECOPY , DATAFILECOPY ’ ’ NODUPLICATES TAG tag_name ALL NODUPLICATES DATAFILECOPY LIKE ’ string_pattern ’ tempfileSpec This subclause is used to define tempfiles by name or file number that should be operated on by the parent command. Syntax Diagram ’ filename ’ integer Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
2. Appendix A: RMAN Syntax Reference Guide 619 toDestSpec This subclause is used to specify a directory or an Automatic Storage Management disk group for disk backups for the RMAN operation that the subclause is used in. Syntax Diagram ’ toDest_string ’ untilClause This subclause defines a limit based on time, SCN, restore point, or log sequence number that is referenced by the parent RMAN command. Syntax Diagram UNTIL SCN integer THREAD integer UNTIL SEQUENCE integer UNTIL TIME ’ date_string ’ Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
4. APPENDIX B RMAN Scripting Examples Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
5. 622 Part V: Appendixes e have gotten a number of requests for scripts related to RMAN. The nice thing about RMAN is that scripting it is a pretty straightforward process. In this chapter, we provide you with some basic scripts for both Windows and Linux to get you started. These scripts assume that you are using the Oracle flash recovery area (FRA), which will manage disk space and backup retention for you. If you are not using the FRA, perhaps you might want to customize these scripts for your own needs. We will leave that to your ingenuity and skill! RMAN Scripts for Windows These scripts were written and tested using Windows XP. First, we give you an example batch script that will call RMAN for a backup of the database and the archived redo logs. We will then show you a method of scheduling these scripts from the operating system. Note that this is just one method of scheduling automated backups. You might also choose to use Oracle Enterprise Manager (OEM) to schedule and manage your backups. Using Oracle Enterprise Manager is covered in Chapter 13, so you can reference that chapter for information on scheduling backups in OEM. Creating a Windows Script to Schedule Backups This is a pretty basic script; you might want to augment it for incremental backups, backup validation, or other operations. Note that the script will return an error message if the backup fails. To create this script, you might use Notepad, or some other text editor, and might call this script something like backup.bat. rem ******************************************************************** rem * Script Name: backup.bat rem * Script Purpose: This script will call RMAN and execute the command rem * file specified on the command line. rem * Usage backup.bat @echo off rem rem RMAN BACKUP SCRIPT rem For WIN XP rem echo %1 set oracle sid %1 if "%2" "backup" rman target / cmdfile c:\oracle\scripts\backup.scr if not ERRORLEVEL 0 echo "WARNING - FAILURE OCCURRED" if "%2" "arch" rman target / cmdfile c:\oracle\scripts\arch.scr if not ERRORLEVEL 0 echo "WARNING - FAILURE OCCURRED" Note that this script calls two command files, backup.scr and arch.scr, which in this case are located in the c:\oracle\scripts directory. Here is the backup.scr script: Backup as compressed backupset database plus archivelog delete input; This is the arch.scr script: Backup as compressed backupset archivelog all delete input; Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
6. Appendix B: RMAN Scripting Examples 623 Again, each of these scripts would be created using a text editor and placed in the c:\oracle\ scripts directory. If you put them somewhere else, you will need to edit the backup.bat script to point to the correct location of these scripts. Scheduling the Backup Now, we want to schedule the backup. We will use the Windows schtasks utility to perform this operation. In our experience, schtasks is a rarely used but powerful scheduling utility. In this example, we are scheduling a daily database backup using the backup.bat file. We also have an example of scheduling the archived redo log backup and an example of how to remove a scheduled task: schtasks /create /tn "database backup" /sc weekly /d SUN /st 14:50:00 /tr "c:\bc\rman\backup.bat rob10r2 backup>\>c:\bc\rman\backup.output" rem schtasks /delete /tn "database backup" schtasks /create /tn "archivelog backup" /sc daily /st 14:50:00 /tr "c:\bc\rman\backup.bat rob10r2 arch>\>c:\bc\rman\backup.output" You have a number of scheduling options when using the schtasks scheduler. The schtasks scheduler will request the login ID of the user that will be running the job. RMAN Scripts for Unix These scripts were written and tested on Red Hat Linux Version 5. In this section, we have a backup script (backup.ksh) and the related command-line files that will be used to execute the actual backup. You can use Cron or at to schedule this script in Unix. First, here is our example shell script for our Unix backup: #/bin/ksh # Script name: backup.ksh # Usage: backup.ksh # Note: We assume the oracle environment is already setup except for # ORACLE HOME. If not, you will need to setup your environment correctly. set ORACLE SID $1 if [ "$2" "backup" ]; then rman target / cmdfile /home/oracle/scripts/backup.scr fi if [ "$2" "arch" ]; then rman target / cmdfile /home/oracle/scripts/arch.scr fi The backup.scr script is the same as you saw earlier: Backup as compressed backupset database plus archivelog delete input; As is the arch.scr script: Backup as compressed backupset archivelog all delete input; Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 7. This page intentionally left blank Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 8. APPENDIX C Setting Up an RMAN Test Environment Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 9. 626 Part V: Appendixes s the complexity of production enterprise environments grows with each passing A year, we DBAs are finding the same complexity creeping into our test environments. For example, in Oracle9i RMAN Backup & Recovery, the test environment was seemingly complex for us: a Windows laptop for minor tweaks and screen shots, another Windows server for more robust testing, and a Sun Blade 150 for multi-OS interaction and Unix commands. Among these three machines, we were able to do all technical reviews (combined with years of actual experience in the workplace, of course). For the 10g RMAN book, the test environment included two Linux boxes with a shared FireWire disk drive (running RAC, of course), Matthew’s trusty Windows laptop, that old Sun Blade, and a stand-alone Linux box. And Matthew still went hunting with his colleagues looking for other RAC clusters, tape storage jukeboxes, and Oracle Enterprise Manager repositories. That being said, things have taken an interesting turn since the last book. We authors had to travel significantly during the production of this book, so the needs changed dramatically, from a tactical standpoint. Because of the up and down, thrashed and trashed nature of B&R testing, testing from a remote location can be difficult. And you can’t connect to your datacenter from a plane yet. Yet. In addition, this was the first time that we wrote against Beta code (long story), so there are plenty of hiccups that simply prevented traditional solutions. So, what did our test environment look like this time? One late-model Apple MacBook Pro, running VMWare Fusion, and an external hard drive. That’s it. (Okay, Matthew still relied on those RAC clusters in the datacenter.) He installed RHEL 5, copied the VMWare slice, and had a multiserver environment running from his laptop— love modern times. Now, Matthew had gotta a completely mobile lab environment, with plenty of hard-drive space and a built-in way to trash everything and start over using his virtual snapshots. The only limit was that his late-model Mac had 3GB of memory, so he had to pick and choose environments carefully when running them simultaneously. With new models running up to 8GB, Matthew’s looking forward to having that problem solved soon as well. Granted, as discussed later in this appendix, this does not, in any way, come close to looking like a true production environment. Therefore, he can’t do any performance benchmarking on his laptop, or expect that he has ensured that scripts are free of bugs in production. But, with the exact OS running (RHEL) and exact database version, he has gone a long way toward assurance that he knows what he’s doing and how it will behave. As stated back in Oracle9i RMAN Backup & Recovery, test environments can be tricky to describe or to provide advice about. Every shop has its own concept of what testing is required, and at what level, for application design, quality assurance, version control, and so forth. And with RMAN playing a more integral role in a wider array of DBA activities, it’s increasingly difficult to separate an RMAN test environment from other test environments. But, you are looking at this book now, and we have opinions on testing backup strategies. As we like to say, everyone has a backup strategy. Few have a recovery strategy. Testing backups is only a fraction of the work. If you do not test your recovery strategies, then you don’t have backups, no matter how many files you’ve written to how many thousands of dollars’ worth of equipment. A test environment for backup and recovery is different from other testing environments. First of all, you have to be able to remove datafiles, or even the entire database, on a whim, without having to clear it with other users. In other words, you need your own database. Or two. If you begin testing RMAN functionality on a shared database, pretty soon you’ll either start getting angry phone calls from other users, or find yourself locked out of the machine by the SA. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 10. Appendix C: Setting Up an RMAN Test Environment 627 A backup and recovery test environment is simply too volatile to share. Think about it from the other end: you’re busy testing a backup yourself, when suddenly the backup aborts because someone started removing datafiles in order to test their own restore and recovery. On the other hand, you need to test your strategies in an environment that most closely matches that of your production databases. Therefore, you can’t always run in isolation, because you might need to tune your backup on a large, production-grade server that has the same kind of load as production. What we suggest, then, is that you approach RMAN backup and recovery testing as a two- tiered investigation: First, get comfortable with functionality and behavior in the isolation of a small test server. Second, take the lessons you’ve learned, and schedule time to test on a larger, production-grade database server. That way, you can schedule time on a test box for a backup/ recovery test outage, and avoid spending that valuable time trying to learn lessons that you could have figured out on your workstation. So, what does this approach look like more specifically? The answer is provided in this appendix. The Test Box The first-level test machine for RMAN functionality doesn’t need to be a supercomputer. In fact, you should think of the first level of testing as just a rehearsal— you’re reading through your lines, getting the placement right, and talking through the steps with the other actors and the director. Match Your Production Environment If possible, your RMAN testing should take place on the same operating system that you run in production. This is a rather humorous thing to say, we know: who has a single OS in their environment anymore? Anyway, if you will be backing up only Solaris servers, it makes sense to invest a little money in a Sun workstation. That way, you can begin production environment matching as soon as possible. Go Cheap It’s not that critical to have your first wave of testing take place on the same OS as your production environment. RMAN acts the same on all platforms, and the exercises in this book work on all platforms. So, if you’re in the market for an RMAN test box, we have only two words: go cheap. Buy a commodity-priced computer that runs Windows or Linux. I’ve grown quite fond of my cut-rate Linux cluster that Scott Jesse outlined in the Oracle Press book Oracle Database 10g High Availability with RAC, Flashback, and Data Guard (2004). It is a two-node RAC tester for under$1,500, bought refurbished from Dell’s Outlet. As far as what to look for in a cheap test environment, we provide the following advice: ■ Processor speed Don’t worry about processor speed at the RMAN proof-of-concept level. RMAN simply does not rely on CPUs that heavily. As you move into heavy parallelization in production, CPU speeds might grow in testing importance. Even if you monitor for performance at this level, the data is meaningless when compared with your production environment. Instead, spend money on other resources, mainly disk space and memory. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
11. 628 Part V: Appendixes ■ Memory You need enough memory to run three Oracle instances simultaneously, along with your media management software. If you will be testing with OEM or some other management software package, factor that in as well. This means that you need 2GB minimum. Don’t cut corners on memory, or you will get sucked down into time- consuming swap rat holes from which there is no escape. ■ Disk space Disks are cheap, and you don’t need some SCSI disk or anything, just space. Speed, again, is not important at this level. A 200GB hard drive should be sufficient. You’re doing concept testing at this level, so you can limit the size of databases to keep things under control. But keep in mind that you’re going to have more than one database, and you will also be backing up to disk (most likely), so you need space for RMAN backup pieces, as well. So load up on disk space if you can. If you decide to do a RAC tester, you need an external SCSI or FireWire drive in addition to whatever you load internally into your box. Again, consult Oracle Database 10g High Availability with RAC, Flashback, and Data Guard for a blow-by-blow description of RAC home clusters. The Oracle Configuration After you get your test box up and running, you need to think about your Oracle installation and configuration. This step depends on what you need to test: Will you be backing up multiple versions of Oracle? Will you be using OEM? Multiple Homes If you will be testing multiple versions of Oracle, be sure to install them in chronological order from oldest to newest; for example, install version 9.2.0 before 10.1.0, and 10.1.0 before 10.2.0. Before you get very far, patch Oracle to the latest patch level. There are always RMAN bugs getting fixed, so it makes sense to be at the most recent patch level. Creating Databases Obviously, you need at least one database created in each ORACLE_HOME that you have installed. These databases may be default databases created during Oracle installation, but an even better scenario would be to use databases that are configured somewhat like production databases. From a size perspective, that may not be possible, but you can scale datafile sizes down while keeping the same number of datafiles and tablespaces. In addition, try scaling down the memory utilization of these test boxes to be as low as possible. You won’t actually be doing that much processing, so you don’t need a lot of buffer cache available. The smaller you keep the System Global Area (SGA), the better off your little test box will be. You also need a recovery catalog database that is separate from the target databases that you are using for testing. We always recommend that your recovery catalog database be the most recent version, so put this in a 11.2 home. In a pinch, this can also be used as a target database, but try to keep your recovery catalog database out of the mix of databases that you blow away and rebuild. It just makes life easier. If at all possible, put your recovery catalog database on a different server. Put it on a Windows workstation or an old Linux box. Keep it out of the crash- and-burn destruction path. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
16. Index A performing RMAN backup using alter database create standby TDPO, 199–203 controlfile command, 252 ACO (Advanced Compression recovering control file from alter database datafile end backup Option), 116 autobackup not using command, 267 active online redo log FRA, 273 alter database datafile offline loss of, 296 recovering SPFILE from specific command, 292 overview of, 17–18 backup set, 272 alter database disable block change recovering from loss of, 294 storing S3 as default SBT tracking, 256 Active Session History (ASH), channel, 149 alter database drop logfile command, V$ACTIVE_SESSION_HISTORY syntax details, 564–565 70, 295 view, 457 testing tape channels, 107 alter database enable block change admin class, OSB rights, 122 troubleshooting TSM tracking, 255 admin user, OSB installation, 120, backups, 206 alter database open command 125–126 allocate channel for maintenance ARCHIVELOG mode full Administration Center, TSM, 194 command, 565 recovery, 29 administrative data, OSB, 119–120 allocOperandList command, loss of current online redo log administrative domain, OSB, 612–613 group, 296 117–118 alter database activate standby offline RMAN backups using Advanced Compression Option database command, 493 default settings, 230–231 (ACO), 116 alter database add logfile command, point-of-failure database advise failure command, Data 70, 294–295 recoveries, 290 Recovery Advisor, 297, alter database add standby logfile alter database open resetlogs 299–300, 564 command, 70 command alert log messages alter database begin backup ARCHIVELOG point-in-time defined, 6 command, 28 recoveries, 30 managing space in FRA, alter database checkpoint completing repair failure 64, 67 command, 296 command with, 297 in new Fault Diagnosability alter database clear logfile recovery from complete Infrastructure, 74 command, 296 database loss online redo logs, 17 alter database clear logfile group (NOARCHIVELOG) with restore command failover, 271 command, 295–296 recovery catalog, 536 split mirror backups of alter database clear unarchived restoring database in datafiles, 522 logfile command, 296 NOARCHIVELOG mode, 282 allocate channel command, 85 alter database command alter database rename file command, maxpiecesize parameter, 240 managing online redo logs, 70, 256 offline RMAN backups without 19–20 alter system archive log current configured defaults, 233–235 referencing datafiles, 293 command, 247–248, 363 passing environment syntax details, 566 variable, 107 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 17. 634 Oracle RMAN 11g: Backup and Recovery alter system checkpoint command, backups, modifying with change physical backups in, 27–28 294–296 command, 409 point-in-time recoveries in, 30–31 alter system command, 68 backups up with encryption, 96 recovering control file, 278 alter system set command, 56 creating image copies of, 255 restore and recovery of database alter system switch logfile command, crosschecking backups, 402 in, 29, 287–291 27, 62 as database physical RMAN requiring, 46 alter tablespace begin backup component, 15 tablespace and datafile recovery command, 27–28 defined, 7–8 in, 29–30 alter tablespace offline command, 29 full database recovery in taking datafile offline in, 14 alter tablespace online command, 29 ARCHIVELOG mode, 29 ARCHIVELOG mode, configuring alter tablespace tablespace_name listing backups of, 432–433 database in, 62–73 offline for recover command, 364 listing copies of, 436–437 destination directories, 62–64 alter tablespace users offline log sequence-based recovery FRA, 64–67 command, 292 of, 349 FRA and ASM, 70 alter tablespace users online log sequence number of, 9, 19 FRA benefits, 71 command, 292 online backups, 250–251 FRA views, 67–69 Amazon Web Services. See AWS recovery catalog views for, if you created database with (Amazon Web Services) 217, 219 ODBCA, 71–72 ANS errors, TSM, 205–206 recovery from complete database other FRA features, 70 ANU errors, TSM, 205–206 loss with recovery catalog, 541 overview of, 62 Apache web server backup daemon, recovery, troubleshooting, switching between OSB, 119 375–376 NOARCHIVELOG mode and, Application Backup Schedule, restoring from backup using 71–73 163–164, 167 RAC, 509 archivelog parameter, copy ARCH processes, 12–13, 18–20 restoring records to control file, command, 255 architectures 277–278 archivelogRecordSpecifier subclause, backup challenges of RAC, restoring specific, 350 613–614 502–503 restoring with recover archiving tables, Flashback Data Database Control, 313–314 command, 281 Archive, 397–398 duplication, 468–470 restoring with restore archlogRange parameter syntax Grid Control, 312–313 command, 280 diagram, 614 NetBackup, 159 RMAN duplication process, 472 as backupset parameter, backup Oracle and Data Protector sync and split technology for, command, 237 integration, 175 522–523 as compressed backupset Oracle backup and recovery. archivelog destination to parameter, set parameter, 237 See backup and recovery command, 350 ASH (Active Session History), architecture ARCHIVELOG mode V$ACTIVE_SESSION_HISTORY RMAN. See RMAN architecture archived redo logs in, 7–8 view, 457 archival backups, 240–241 case studies in recovery, 537– ASM (Automatic Storage Management) archive copy group, TSM, 192 542, 550–551 archive log backups in RAC, archive log deletion policies committing data change, 25 506–507 configuring RMAN default creating image copy of archived FRA and, 56, 70 settings, 97 redo log, 255 overview of, 16 OEM limitations, 321 database recoveries in, 287–291 restore operations in RAC, overview of, 242–243 database recovery after restoring 507–508 archived redo logs control file, 277 sharing files across multiple backup sets, modifying retention disk-only Oracle-suggested computers, 502 policy for, 240 backups in, 328 storing block change tracking file backups from standby database, full recovery in, 29 in, 256 499–500 incremental backups in, 255 testing Oracle installation/ backups in ARCHIVELOG mode, NOARCHIVELOG mode vs., configuration, 629 27–28 20–21 asynchronous backup I/O, 447, backups in RAC, 504–507 online backups in, 247 457–459 lease purchase PDF Split-Merge on www.verypdf.com to remove this watermark.