Oracle 10G new Features--rman__oracle

Oracle 10G New Features-- RMAN

Author: Fuyuncat

Source: WWW.HelloDBA.COM

The Rman incremental backup scheme, offline recovery of incremental backups, recovery previews, recovery from Resetlogs, file compression, and so on, become more powerful. Most people agree that Rman is the de facto database backup tool for Oracle. Although earlier versions of Rman are already strong, there is still much to expect from them. Many DBAs fret about features that they want to have but don't actually have. Fortunately, in the 10g to solve a lot of problems and add a lot of expected features, let's take a look at the following. Incremental Backups Rman has the ability to have an incremental backup. But in fact, do you often use it? Maybe once in a while, maybe never. This feature enables Rman to back up data blocks that have changed since the last incremental backup of the same level or lower level. For example, a full backup (LEVEL_0) was performed on the first day and two incremental backups (Level_1) were performed on the second to third day. The next two backups only back up the data blocks that changed between the first and second days, and the changes between the second and third days, instead of backing up the entire data. This strategy reduces the size of the backup data, requires less space, and makes the backup window smaller, reducing the amount of network traffic. The most important factor for using incremental backups is to associate with the Data Warehouse environment. Because many operations in the data warehouse are performed in nologging mode, and the data changes are not recorded in the archive log file, there is no media available to recover the data. Since the data warehouse is now very large, it is not considered to use full backups at all, nor is it feasible. Therefore, an incremental backup is an optional method. But why do so many DBAs rarely take incremental backups? One reason is that in Oracle 9i and later versions, Rman scans all blocks to locate which blocks need to be backed up. This operation creates a lot of pressure on the system, so incremental backups are not operational. The Oracle 10G Rman has improved the way incremental backups are made. It uses a file similar to a log file in the file system to track blocks of data that have changed since the last backup. Rman needs to read this file to determine which blocks need to be backed up. You can activate this tracking mechanism by executing the following command: Sql> ALTER DATABASE enable block change tracking using file '/rman_bkups/change.log '; You can determine whether the current tracking mechanism is active by using the following query statement: sql> select filename, status from V$block_change_tracking; Flashing Recovery Area The flashback function in 9i relies on the regression table space Flash back to an earlier state, which limits its flashback to its early state. Flashing recovery provides a new workaround by creating a flash-back log. The flashback log resembles the redo log, which restores the database to an earlier state. In summary, you can create a flashing recovery area for the database by using the following SQL statements, specifying its size, and setting the database to a flashing recovery mode: Sql> alter system set Db_recovery_file_dest = '/ora_flash_area '; Sql> alter system set db_recovery_file_dest_size = 2g; Sql> alter system set db_flashback_retention_target = 1440; Sql> ALTER DATABASE flashback on; In order for the Flashback feature to be activated, the database must be in the archive log mode. The above operation creates an Oracle management file (Oracle Managed files OMF) under the directory/ora_flash_area, with a total size of 2GB. Changes to the database are recorded in these files, allowing the database to quickly revert to a previous point. By default, Rman also uses the/ora_flash_area directory to store the reserve files. As a result, the Rman backup city is stored on disk, not on tape. In this way, you can set how many days to keep the backup data, and when the time is up, the files will be deleted automatically if more space is needed. However, the flashing recovery area may not require a file system or directory, it can be an automated storage management (Automatic Storage Management ASM) disk group. In this case, the flashing recovery area can be specified with the following statement: Sql> alter system set Db_recovery_file_dest = ' +DSKGRP1 '; Using the combination of ASM and Rman, you can build scalable, fault-tolerant storage systems by using inexpensive disks such as Serial ATA and SCSI disks. This is not a faster backup process, and you can do the same thing with a disk that is cheaper than tape. Another benefit is the avoidance of user errors. Yong Wei asm files are not actual file systems and they are less likely to be corrupted by DBAs and system administrators. Incremental Merge If you have the following backup schedule: Sunday do a full backup of level 0, identified as LEVEL_0, Monday Level 1 incremental backup, identified as Level_1_mon, Thursday to do level 1 incremental backup, identified as Level_1_tue. If the database was damaged in Saturday, you will have to restore level_0 before 10G and then implement all 6 incremental backups, which can take a long time. This is one of the reasons many DBAs avoid using incremental backups. The Oracle 10g Rman fundamentally changed this way, and now the incremental backup commands are as follows: Rman> Backup incremental Level_1 for recover of copy with tag Level_0 database; This allows Rman to do an incremental backup Level_1 backup with a full backup that is identified as LEVEL_0. After such a backup, LEVEL_0 becomes the full backup of the day. Therefore, in Thursday, the backup that was identified as Level_0 was actually merged with the incremental backup of Level_1 and became a full backup in Thursday. If the database is corrupted in Saturday, you will need to restore the LEVEL_0 backup together with some archive logs. You do not need to restore incremental backups. This approach greatly reduces recovery time, accelerates backups, and avoids making a new incremental backup. Compress Files In the Flash Recovery area feature of disk-based backup, you have a big limitation: disk capacity. Especially when implemented over the network--which is actually often used--it is highly recommended to create a backup as small as possible. In the 10G Rman, you can insert a compressed file command in the backup command: Rman> Backup as compressed backupset incremental level 1 database; Please note that this uses the Compress clause. Its compressed backup file has a very important feature: when recovering, Rman can read it directly without extracting the file. To confirm that compression is possible, you can detect in the output information whether the following content is available: Channel Ora_disk_1:starting compressed incremental level 1 datafile backupset You can also confirm that the backup is compressed by using the list output in Rman: rman> list output; BS Key Type LV Size Device Type Elapsed Time Completion time ------- ---- -- ---------- ----------- ------------ --------------- 3 INCR 1 2M DISK 00:00:00 26-feb-04 BP key:3 status:available compressed:yes Tag: tag20040226t100154 Piece Name: /ora_flash_area/smiley10/backupset/2004_02_26/o1_mf_ncsn1_tag20040226t100154_03w2m3lr_.bkp Controlfile INCLUDED:CKP scn:318556 CKP time:26-feb-04 SPFILE included:modification time:26-feb-04 As with all compression actions, this method increases the pressure on the CPU. But it also allows you to keep more backups on disk for recovery. In addition, you can use Rman to back up the physical backup database for use in restoring the primary database. This approach can offload backup resources from other hosts. Resume Preview Oracle 10g has become very advanced by providing the ability to preview the restore operation: rman> Restore Database preview; ... ... You can also preview specific recovery actions, such as: Rman>restore tablespace users preview; ... ... The preview feature allows you to make regular checks to confirm what you want to do with your recovery. resetlogs and Recovery If you lose the current online redo log file, you will have to do an incomplete database restore. The biggest problem when resetlogs. When you do not fully recover, you must use the RESETLOGS clause to open the data, it will set the log thread serial number 1, delete the early backup in Rman, make the recovery operation easier. In Oracle 9i and lower versions, if you need to restore the database from Resetlogs to an early state, you have to restore it to a different form. In Oracle 10G, you don't have to do this. Because the control file adds some structure, Rman can use all backups to recover the database before or after a resetlogs operation. Making backups makes it unnecessary to shut down the database. This new function means that the database can be quickly opened by the user after a resetlogs operation.