Shulou(Shulou.com)05/31 Report--

Editor to share with you what are the new features of Oracle11g backup and recovery, I believe most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's learn about it!

Flash log first aid

Remember the flashback logging introduced in Oracle Database 10g? If the flashback feature is enabled in the database, the flashback log records the optimized version of the previous image of the change block in the flashback log generated in the flashback recovery area. These logs can help you flash the database back to a point in time without having to perform a point-in-time recovery from the backup.

So, since these flashback logs contain previous images of blocks, why not use them for recovery as well? That's exactly what Oracle Database 11g does. When you restore a specific block, Oracle looks for a good copy of the previous image of the block in the flashback log (not the data file), and then applies the archive log to scroll forward. Since there is no need for backup, this method can save a lot of time, especially when the backup is on tape.

ZLIB compression

RMAN provides backup segment compression in Oracle Database 10g to save network bandwidth, but many people do not use it easily. Why? Because third-party compression tools provide methods that are faster than RMAN's own. However, RMAN 10g compression has some useful features that third-party compression tools do not have. For example, when RMAN 10g restores data files, you do not need to unzip them first (if they have been compressed before). This method can significantly save bandwidth during the restore period.

In Oracle Database 11g, RMAN provides another algorithm, ZLIB, which previously used BZIP2. The ZLIB algorithm is much faster, but it doesn't compress too much content. On the other hand, it also saves CPU. Therefore, if you don't have much CPU, it's best to use ZLIB compression. (note that the default option in version 11.1 is BZIP2;. You need to purchase a new option, Advanced Compression Option, to use ZLIB. )

To use ZLIB compression, simply set the RMAN configuration parameter to:

RMAN > configure compression algorithm 'ZLIB'

If you have changed this parameter before, you need to issue the above command. To change it to BZIP2, issue the following command:

RMAN > configure compression algorithm 'bzip2'

Now, all compressed backups will use the new algorithm.

Parallel backup of the same data file

You probably already know that you can back up in parallel by declaring multiple channels so that each channel becomes a RMAN session. However, few people realize that each channel can only back up one data file at a time. Therefore, even if there are multiple channels, each data file is backed up through only one channel, which is somewhat contrary to the concept of true parallelism of backup.

In Oracle Database 11g RMAN, channels can split data files into blocks, which are called "segments". You can specify the size of each segment. Here is an example:

RMAN > run {2 > allocate channel C1 type disk format'/ backup1/%U';3 > allocate channel c2 type disk format'/ backup2/%U';4 > backup 5 > section size 500m 6 > datafile 6 countries 7 >}

The RMAN command allocates two channels and backs up the user's tablespaces on both channels in parallel. Each channel occupies a 500MB segment of the data file and backs up the file in parallel. This speeds up the backup of large files.

When backing up in this way, the contents of the backup are also displayed as segments.

RMAN > list backup of datafile 6... List of Backup Pieces for backup set 901 Copy # 1 BP Key Pc# Status Piece Name-2007 1 AVAILABLE / backup1/9dhk7os1_1_1 2008 2 AVAILABLE / backup2/9dhk7os1_1_1 2009 3 AVAILABLE / backup1/9dhk7os1_1_3 2009 3 AVAILABLE / backup2/9dhk7os1_1_4

Notice how the backup segment is displayed as a file segment. Because each segment goes to a different channel, you can define them as different mount points (such as / backup1 and / backup2), and you can back them up to tape in parallel.

However, if No. 6 large files are located on only one disk, there is no advantage in using parallel backups. If you segment the file, the head needs to be constantly moved to handle different segments of the file, and its disadvantages outweigh the advantages of segmentation.

Undo the submitted backup? Why?

You already know the purpose of undoing data. When a transaction changes a block, the previous image of the block is saved in the undo segment. Even if the transaction has been committed, the data is still there, because a longer-running query started before the block is changed may request a changed and committed block. The query should get the previous image of the block, that is, the previously committed image instead of the current image. Therefore, even after the submission, the undo data is still saved in the undo segment. Over time, the data is washed out of the undo segment to make room for newly inserted undo data.

When RMAN backup runs, it backs up all data in the undo tablespace. During recovery, undo data related to committed transactions will no longer be needed because they are already in the redo log stream or are still in the data file (if used blocks have been cleared from the buffer and written to disk). Can be recovered from there. So why back up the submitted undo data?

In Oracle Database 11g, RMAN is smart: it does not back up committed revocation data that is not needed for recovery. The uncommitted revocation data, which is critical to recovery, is backed up as usual. This reduces the size and time of backups (and restores).

In many databases, especially in OLTP databases with more frequent transaction commits and longer revocation data in the undo segment, most of the undo data has actually been committed. Therefore, RMAN only needs to back up a few blocks in the undo tablespace.

Best of all, you don't need to do anything to achieve this optimization, and Oracle will do it on its own.

Virtual private directory

You may use a catalog database as the RMAN repository. If not, you should seriously consider using a catalog database. This has many advantages, such as reporting, simplifying recovery when control files are damaged, and so on.

Now, another question arises: how many directories are appropriate? In general, it makes sense to create only one catalog database as an information base for all databases. However, this may not be a good approach for security reasons. The directory owner will be able to view all repositories of all databases. Since each database you want to back up may have a separate DBA, you should not make this directory visible.

So, is there any other way? Of course, you can create a separate catalog database for each target database, but given the cost, this may not be practical. Another approach is to still create only one catalog database, but create a virtual directory for each target database. Virtual directories are a new feature in Oracle Database 11g. Let's look at how to create a virtual directory.

First, you need to create a base directory that contains all the target databases. Suppose the owner is "RMAN". From the target database, connect to the catalog database as the base user and create the directory.

$rman target=/ rcvcat rman/rman@catdb

Recovery Manager: Release 11.1.0.6.0-Production on Sun Sep 9 21:04:14 2007 Copyright (c) 1982, 2007, Oracle. All rights reserved.

Connected to target database: ODEL11 (DBID=2836429497)

Connected to recovery catalog database

RMAN > create catalog

Recovery catalog created

RMAN > register database

Database registered in recovery catalog

Starting full resync of recovery catalog

Full resync complete

This is called the base directory and is owned by the user "RMAN". Now, let's create two more users who will have their own virtual directories. For simplicity, let's make the names of these two users the same as the target database. Remain connected as the base directory owner (RMAN) and issue the following statement:

RMAN > grant catalog for database odel11 to odel11; Grant succeeded.

Now connect using the identity of the virtual directory owner (odel11) and issue the create virtual catalog statement:

$rman target=/ rcvcat odel11/odel11@catdbRMAN > create virtual catalog; found eligible base catalog owned by RMANcreated virtual catalog against base catalog owned by RMAN

Now register another database (PRONE3) in the same RMAN repository and create a virtual directory owner "prone3" for its database of the same name.

RMAN > grant catalog for database prone3 to prone3; Grant succeeded.$ rman target=/ rcvcat prone3/prone3@catdbRMAN > create virtual catalog; found eligible base catalog owned by RMANcreated virtual catalog against base catalog owned by RMAN

Now, if you want to view the registered database and connect as the base directory owner (RMAN), you will see:

$rman target=/ rcvcat=rman/rman@catdbRMAN > list db_unique_name all List of DatabasesDB Key DB Name DB ID Database Role Db_unique_name--285 PRONE3 1596130080 PRIMARY PRONE3 1 ODEL11 2836429497 PRIMARY ODEL11

As expected, it shows two registered databases. Now connect as ODEL11 and issue the same command:

$rman target=/ rcvcat odel11/odel11@catdb RMAN > list db_unique_name all List of DatabasesDB Key DB Name DB ID Database Role Db_unique_name--1 ODEL11 2836429497 PRIMARY ODEL11

Notice how to list only one database, not both. The user (odel11) is allowed to view only one database (ODEL11), that is, the database shown above. You can verify this by connecting to the directory as another owner, PRONE3:

$rman target=/ rcvcat prone3/prone3@catdb RMAN > list db_unique_name all List of DatabasesDB Key DB Name DB ID Database Role Db_unique_name--285 PRONE3 1596130080 PRIMARY PRONE3

With virtual directories, you can maintain only one database for the RMAN repository directory, but establish security boundaries for individual database owners to manage their own virtual repositories. A general catalog database can simplify management, reduce costs, and reduce costs while improving database availability.

Merge catalog

It's still the subject of multiple directories, so let's consider another issue. Now that you know how to create a virtual directory on the same base directory, you may see the need to integrate all these separate repositories into one repository.

One option is to unregister the target databases in their respective directories and then re-register them to the new central directory. However, doing so means losing all valuable information stored in these repositories. Of course, you can synchronize the control file and then resynchronize it to the directory, but this makes the control file large and impractical.

Oracle Database 11g provides a new feature: merge directories. In fact, this function is to import directories from one database to another, or, in other words, to "move" directories.

Let's take a look at how it works. Suppose you want to move the directory from the database CATDB1 to another database called CATDB2. First, connect to the catalog database CATDB2 (target):

Rman target=/ rcvcat rman/rman@catdb2 Recovery Manager: Release 11.1.0.6.0-Production on Sun Sep 9 23:12:07 2007 Copyright (c) 1982, 2007, Oracle. All rights reserved. Connected to target database: ODEL11 (DBID=2836429497) connected to recovery catalog database

If the database already has a directory owned by user "RMAN", go to the next import step; otherwise, you will need to create the directory:

RMAN > create catalog; recovery catalog created

Now, import from the remote directory (catdb1):

RMAN > import catalog rman/rman@catdb1; Starting import catalog at 09-SEP-07connected to source recovery catalog databaseimport validation completedatabase unregistered from the source recovery catalogFinished import catalog at 09-SEP-07starting full resync of recovery catalogfull resync complete

The output above contains some important information. Notice how the target database is unregistered in its original catalog database. Now, if you check the database name in this new directory:

RMAN > list db_unique_name all List of DatabasesDB Key DB Name DB ID Database Role Db_unique_name--286 PRONE3 1596130080 PRIMARY PRONE3 2 ODEL11 2836429497 PRIMARY ODEL11

You will notice that the DB Key has changed. ODEL11 used to be 1, but now it is 2.

The above action imports the catalog of all registered target databases into the catalog database. Sometimes you may not want to do this, but only want to import one or two databases. To do this, issue the following command:

RMAN > import catalog rman/rman@catdb3 db_name = odel11

This will change the DB Key again.

What if you do not want to unregister the import database in the source database during import? In other words, you want the database to be registered in both catalog databases. You will need to use the "no unregister" clause:

RMAN > import catalog rman/rman@catdb1 db_name = odel11 no unregister

This will ensure that the database ODEL11 is not unregistered in the catalog database catdb1 and is also registered in the new directory.

Copy the database from the backup (version 2 only)

You need to replicate the database for a variety of reasons, such as setting up a Data Guard environment, building a tempdb or QA database based on a production database, or moving the database to a new platform. The DUPLICATE command in RMAN greatly simplifies this activity. But where does RMAN replicate the database?

The most obvious choice is to replicate from the master database itself. The master database is the latest version and has all the information needed to replicate the database. However, although this method is convenient, it still puts some pressure on the primary database. In addition, this method requires a dedicated connection to the primary database, which is not always possible.

Another source of the production database is the database backup. This will not affect the production database because we will back up separately. Although you can copy the database from a backup of the database starting with Oracle9i Database, there are still some difficulties in using it: although the source of the replication is a backup, this process still requires a connection to the primary database. Therefore, there are the following questions: what if the primary database is unavailable due to a maintainable shutdown? Or what if you copy the database from another server and the server cannot connect to the primary database for some security or other logical reasons?

Oracle Database 11g version 2 addresses this issue. In this version, you can perform replication database tasks without connecting to the primary database. You only need to back up the files. Let's take a look at how to copy a database through an example.

First, to illustrate the concept, we need to perform a backup from the primary database. Let's start by starting the RMAN job.

# $ORACLE_HOME/bin/rman target=/ rcvcat=rman_d112d1/rman_d112d1@d112d2

Recovery Manager: Release 11.2.0.1.0-Production on Sun Aug 8 10:55:05 2010 Copyright (c) 1982, 2009

Oracle and/or its affiliates. All rights reserved. Connected to target database: D112D1 (DBID=1718629572)

Although the connection to the catalog database makes the operation easier, it is not absolutely necessary. First, I want to show you the steps to use a directory connection.

RMAN > backup database plus archivelog format'/ u01amp orabackamp% U.rmb'

Starting backup at 08/08/10 12:08:29 current log archived

Using target database control file instead of recovery catalog

Allocated channel: ORA_DISK_1

Channel ORA_DISK_1: SID=58 device type=DISK

Channel ORA_DISK_1: starting archived log backup set

Channel ORA_DISK_1: specifying archived log (s) in backup set

Input archived log thread=1 sequence=631 RECID=344 STAMP=726057709

Input archived log thread=1 sequence=632 RECID=345 STAMP=726058637

...

... Output truncated...

You also need to control file backups. If you configure automatic backup of control files, the backup also contains control files. If you want to ensure that backup control files are backed up, or if you have not configured automatic backup of control files, you can explicitly back up control files.

RMAN > backup current controlfile format'/ u01amp orabackamp% U.rmb'

The above command creates backup files in the directory / u01/oraback. Of course, if you have a backup in a location, you do not need to perform this step. Copy these backup files to the server on which you want to create duplicate copies.

# scp * .rmb oradba2: `pwd`

Before proceeding, you need to know one piece of information, which is the DBID of the source database. You can obtain this information in one of three ways:

Get from the data dictionary

SQL > select dbid from v$database

DBID

-

1718629572

Get from a RMAN repository (directory or control file)

RMAN > list db_unique_name all

List of Databases

DB Key DB Name DB ID Database Role Db_unique_name

--

2 D112D1 1718629572 PRIMARY D112D1

Obtained by querying the recovery catalog table on the catalog database.

In this case, the DBID is 1718629572; make a note of this value. DBID is not absolutely required in the operation, but you will see later why it is so important. )

There is another very important fact you need to know: the completion time of the backup. You can get this time from multiple sources, the most common of which is the RMAN log file. Otherwise, you only need to query the RMAN repository (directory or control file). Here are the steps:

# $ORACLE_HOME/bin/rman target=/ rcvcat=rman_d112d1/rman_d112d1@d112d2

Recovery Manager: Release 11.2.0.1.0-Production on Mon Aug 9 12:25:36 2010

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

Connected to target database: D112D1 (DBID=1718629572)

Connected to recovery catalog database

RMAN > list backup of database

List of Backup Sets

=

BS Key Type LV Size Device Type Elapsed Time Completion Time

716 Full 2.44G DISK 00:03:58 08/09/10 10:44:52

BP Key: 720 Status: AVAILABLE Compressed: NO Tag: TAG20100809T104053

Piece Name: / u01/oraback/22lktatm_1_1.rmb

List of Datafiles in backup set 716

File LV Type Ckp SCN Ckp Time Name

1 Full 13584379 08Compact 09Compact 10 10:40:55 + DATA/d112d1/datafile/system.256.696458617

... Output truncated...

We need to set the NLS variable because we need to know the specific time, not just the date. From the output, we know that the backup was performed at 10:44:53 on August 9.

The remaining steps are performed on the target host. Here, the primary database is called D112D1 and the replica database is called STG.

Add a line in the file / etc/oratab to reflect the database instance to be replicated:

STG:/opt/oracle/product/11.2.0/db1:N

Now, set Oracle SID to the SID of the replicated database:

#. Oraenv

ORACLE_SID = [STG]?

The Oracle base for ORACLE_HOME=/opt/oracle/product/11.2.0/db1 is / opt/oracle

Copy the initialization parameter file from the master database. Edit the file to reflect new locations that may be appropriate, such as audit dump targets, data file locations, and so on. Also create a password file.

# orapwd file=orapwSTG password=oracle entries=20

When the pfile file and password file are ready, use the nomount option to start the instance. It is important to start only the instance, because the replication process creates and mounts the control file.

SQL > startup nomount

ORACLE instance started.

Total System Global Area 744910848 bytes

Fixed Size 1339120 bytes

Variable Size 444596496 bytes

Database Buffers 293601280 bytes

Redo Buffers 5373952 bytes

Although it is not important, it is easier to put commands into a script and execute the script from the RMAN command line instead of entering each command line by line. The following is the contents of the script file:

Connect auxiliary sys/oracle

Connect catalog rman_d112d1/rman_d112d1@d112d2

Duplicate database 'D112D1' DBID 1718629572 to' STG'

Until time "to_date ('08Compact 09 + 10-10-14-44-15-53-31-13-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-12-1-2-1-1-2-1-2-1-2-1-2-1-2-4-2-4-4-4-2-4-2-1-2-4-2-4-2-4-2-4-4-2-1-2-2-3-1-2-4

Db_file_name_convert = ("+ DATA/D112D1", "/ u01/oradata/stg")

Backup location'/ u01amp oraback'

The script is code-based and self-explanatory. The first two lines of code show the connection and directory connection to the secondary instance (the database we want to create as a copy of the primary database). The third line states that we want to copy the database D112D1 to STG. The timestamp of the time to which the database should be restored is also shown here. Because the location of the database file is different between hosts, it is explained by the fifth line. "on the primary database, the data files are on the ASM disk group DATA, while the tempdb is created in the directory / u01/oradata." This means that we must perform a naming convention change. The data file on the main database + DATA/somefile.dbf is called / u01/oradata/somefile.dbf. Finally, we provide the location of the backup files.

Here, we use a timestamp of 10:44:53 on August 9, which is only one second after the backup completed. Of course, we can use any other time here as long as the archive log is available. You can also provide a SCN number instead of a timestamp.

Let's name the script file duplicate.rman. Once created, call the script directly from RMAN:

# $ORACLE_HOME/bin/rman @ duplicate.rman

Here is the result output. If your operation is not going well, comparing this output with your situation may provide you with valuable clues.

That's it; the tempdb STG is now up and running. You can now connect to the database and select the table. During this process, you do not have to connect to the primary database. It only takes a few commands.

In summary, as you can see in the output, the command performs the following steps:

Create SPFILE

Close the instance and restart it with the new spfile

Restore control files from backup

Mount the database

Perform a data file restore. At this stage, it will create the file with the converted name.

Restore the data file to the specified time and open the database

If you want to view the DBID of the database you just created, execute the following command:

SQL > select dbid from vault database; DBID-844813198

This DBID is different from the DBID of the primary database, so it can also be backed up separately using the same directory. Speaking of DBID, remember when we used it in the replication process (even if it wasn't absolutely necessary)? This is because two databases may have the same name, but in the recovery directory, there may be two databases named D111D1 (the source). How does the replication process know which database to replicate? Therefore, use DBID to make a clear distinction.

Similarly, if you have multiple backups, RMAN automatically selects which backup to copy from based on the UNTIL TIME clause. Finally, we use the catalog database here; however, the database is not required. If you do not specify a directory, you must use the "until time" clause instead of "until SCN".

Undelete tablespaces (version 2 only)

For example, you want to clean up the garbage in the database, so you want to delete all small and large tablespaces created by users that may no longer exist. When you delete these tablespaces, you inadvertently delete a critical tablespace. What should I do?

In previous code versions, the option was to reduce the total number of tablespaces. Here are the steps to perform:

Create another instance named TEMPDB

Restore data files that have deleted tablespaces and other required tablespaces such as SYSTEM, SYSAUX, and UNDO

To restore it to the moment of failure, be careful not to mistakenly roll it forward to the moment before the deletion

Transfer tablespaces from TEMPDB and insert them into the main database

Delete TEMPDB instance

There is no doubt that these steps are complex for anyone except for the experienced DBA who is used to frequently deleting tablespaces. Don't you want a simple "undelete tablespace" function similar to the undelete table (flashback table) feature?

In Oracle Database 11g version 2, you will get what you want. Let's take a look at how it works. To illustrate, we need a tablespace and put one or two tables in it to observe the effect of undelete:

SQL > create tablespace testts

2 datafile'/ u01qoradata size 1m

Tablespace created.

SQL > conn arup/arup

Connected.

SQL > create table test_tab1 (col1 number) tablespace testts

2 /

Table created.

SQL > insert into test_tab1 values (1)

1 row created.

SQL > commit

Commit complete.

After the backup, we create another table in the tablespace

SQL > create table testtab2 tablespace testts as select * from testtab

Table created.

Before actually deleting the tablespace, let me introduce you to the view TS_PITR_OBJECTS_TO_BE_DROPPED, which shows the objects in the tablespace that will be deleted with the tablespace:

SQL > desc TS_PITR_OBJECTS_TO_BE_DROPPED

Name Null? Type

-

OWNER NOT NULL VARCHAR2 (30)

NAME NOT NULL VARCHAR2 (30)

CREATION_TIME NOT NULL DATE

TABLESPACE_NAME VARCHAR2 (30)

VARCHAR2 (30)

View the view:

Select owner, name, tablespace_name

To_char (creation_time, 'yyyy-mm-dd:hh34:mi:ss')

From ts_pitr_objects_to_be_dropped

Where creation_time > sysdate-1

Order by creation_time

/

OWNER NAME

TABLESPACE_NAME TO_CHAR (CREATION_TI

ARUP TEST_TAB1

TESTTS 2010-08-03 purl 15 purl 31 purl 16

ARUP TEST_TAB2

TESTTS 2010-08-03 1515 3309

This view shows the two tables we created earlier. Now, delete the tablespace using the including contents clause, which will also delete the tables in it.

SQL > drop tablespace testts including contents

Tablespace dropped.

If you want to view the above view, execute the following command:

Sql > select owner, name, tablespace_name

2 to_char (creation_time, 'yyyy-mm-dd:hh34:mi:ss')

3 from ts_pitr_objects_to_be_dropped

4 where creation_time > sysdate-1

5 * order by creation_time

Two tables will not exist.

Now you need to undelete the tablespace. To do this, you must know when to delete the tablespace. An easy way to do this is to check the alarm log. The following is an excerpt from the alert log:

Tue Aug 03 15:35:54 2010

Drop tablespace testts

ORA-1549 signalled during: drop tablespace testts...

Drop tablespace testts including contents

Completed: drop tablespace testts including contents

To restore the tablespace back to the database, we will use this timestamp, which happens to be the time to execute the drop tablespace command.

RMAN > recover tablespace testts

2 > until time "to_date ('08Accord03xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

3 > auxiliary destination'/ u01andoraux'

Where auxiliary destination is the location of the new database file that will be created. Here, you can use any space, even the bubble space planned for other content, because it is only needed temporarily. (here is the output of the RMAN command. )

That's it; now the tablespace is available again. Let's take a look at what the command actually does:

Create a database instance named Dvlf. The purpose of spelling instance names in this way is to avoid conflicts with existing instance names.

Identify all tablespaces that contain undo segments

Restore required tablespaces (including deleted, SYSTEM, SYSAUX, and UNDO tablespaces)

Transport tablespace testts (deleted tablespace)

Insert testts tablespaces back into the master database

When the testts tablespace is available, it is in offline mode. You must bring it online.

SQL > alter tablespace testts online

Tablespace altered.

Let's make sure we get the right data at the same time:

SQL > conn arup/arup

Connected.

SQL > select count (1) from test_tab1

COUNT (1)

-

one

Table TEST_TAB1; was restored as expected, but what about TEST_TAB2?

SQL > select count (1) from test_tab2

COUNT (1)

-

one

It has also been restored. How did it recover? The table is created after the backup. It should not be included in the recovery?

and be not so. The tablespace restore reverts to the last available redo entry. Restore the tablespace backup and apply the archived log (and redo log) to be exactly consistent with the moment before the failure, because this is not possible with the recovery clause.

Now, if you want to view the above view, execute the following command:

Select owner, name, tablespace_name

To_char (creation_time, 'yyyy-mm-dd:hh34:mi:ss')

From ts_pitr_objects_to_be_dropped

Where creation_time > sysdate-1

Order by creation_time

/

OWNER NAME

TABLESPACE_NAME TO_CHAR (CREATION_TI

ARUP TEST_TAB1

TESTTS 2010-08-03 purl 15 purl 31 purl 16

ARUP TEST_TAB2

TESTTS 2010-08-03 1515 3309

That's it; now the tablespace has been "undeleted" and all data is available. You only need a few lines of RMAN commands to do this without having to plan complex activities.

Another benefit of this approach is that you don't have to restore the tablespace to this particular moment. Suppose you want to restore the tablespace to a specific point in time in the past. You can do this by using a different time in the until clause; you can restore it to another point in time later. This can be repeated as many times as you want. In previous versions of the code, once a tablespace was restored to a point in time, it could not be restored to another point in time earlier than that point in time.

Remember that in previous versions of the code, when performing a tablespace point-in-time recovery, you had to use the AUXNAME parameter for the data file. This allows you to restore the tablespace, but the data file name is different; therefore, the tablespace must be inserted into the database. The current procedure does not require the AUXNAME parameter. Note, however, that AUXNAME is not always required. This parameter is required when the data file name is the same as the backup (usually in the case of an image copy).

Flexibility of Set NEWNAME commands (version 2 only)

Suppose you restore data files from a backup on the same server or on a different server, such as a temporary server. If the file system (or disk group) name is the same, no changes are necessary. But this is rarely the case. In a temp server, the file system may be different, or the ASM disk group to which you restored the production database is not the disk group you used to create the database in the first place. In this case, you must let RMAN know the new name of the data file. You can do this by using the SET NEWNAME command. The following is an example where the restored file is in / U02 instead of / U01, which is the previous version of the code.

Run

{

Set newname for datafile 1 to'/ u02Accord oradataUniverse system 01.dbf'

Set newname for datafile 2 to'/ u02qoradata Universe Sysauxtrees 01.dbf'

Restore database;...

}

There are only two data files here, but what if there are hundreds of data files? Entering all the information is not only a daunting task, but also error-prone. Instead of entering each data file by name, you can now use a set newname clause for the tablespace. Here is the code to do this:

Run

{

Set newname for tablespace examples to'/ u02amp examples% b.dbf'

...

... Rest of the commands come here...

}

If the tablespace contains multiple data files, all data files are created separately. You can also use this clause for the entire database:

Run

{

Set newname for database to'/ u02Accord oradata% b'

}

The b entry specifies the base file name without a path, for example, / u01/oradata/file1.dbf will be re-coded as file1.dbf in b. This is useful when you want to move files to another directory. You can also use this clause to create a copy of the image, where you will create a backup in another location with the same name as the parent file, which will be easy to identify.

Warning: Oracle managed files do not have a specific base name; therefore, this item cannot be used for these files. Here are some other examples of placeholders.

% f is the absolute file number

% U is the only name generated by the system, similar to% U in the backup format

I is the database ID

% N is the tablespace name

With these placeholders, you can use only one SET NEWNAME command for the entire database, which is not only simple, but also more accurate.

Automatic block repair (version 2 only)

What options do you have when blocks in the database are corrupted? The only option for Oracle9i code is to restore the entire data file. In Oracle9i, we can also use the block media recovery feature to repair specific blocks from backups instead of the entire data file, saving a lot of time.

Data Recovery Advisor can clearly show the blocks that may be damaged. However, prior to version 2, the block still needs to be repaired from the backup. What if the backup is on a slower drive, usually because you may not want to put the backup on the same type of expensive disk as the database itself? If you have a physical standby database, which is an exact copy of the data file, and is most likely to be in faster storage. If you can repair the block from this database, it will be much faster.

You can now repair the block from the physical standby database. If you have multiple physical standby databases, how do you know which standby databases to get blocks from? Obviously, you should choose an alternate database with the latest updates. RMAN can automatically suggest the code that best suits the target by examining all physical standby databases. Of course, in this case, the database must be opened for query, which means you must have the Active Data Guard option.

TO DESTINATION clause (version 2 only)

Are you familiar with Oracle managed files (OMF)? They are data files, log files, and control files managed by Oracle without your intervention. These files are neatly organized by name in their respective folders, and their names may not mean anything to you, but they mean everything to Oracle databases. You either like OMF or hate it; but it can't be somewhere in between. You have every reason to like it-you don't have to worry about file names, locations, and related issues, such as name conflicts. Because the location is defined by code, for example, using DATAFILES for data files, ONLINELOGS for redo log files, and so on, it is convenient for other tools to use. If you use ASM, use OMF-you may not know much about it.

You may want to extend the same structure to RMAN backups, where you simply define a location, put files in it, and everything is organized. In Oracle Database 11g version 2, you can use a new clause in the BACKUP command to specify the location. Here is how to use it:

RMAN > backup tablespace abcd_data to destination'/ u01amp oraback'

Note that there is no format string such as% U in the above command, which is different from the backup command we used previously. The output is as follows:

Starting backup at 08/09/10 16:42:15

Allocated channel: ORA_DISK_1

Channel ORA_DISK_1: SID=35 device type=DISK

Channel ORA_DISK_1: starting full datafile backup set

Channel ORA_DISK_1: specifying datafile (s) in backup set

Input datafile file number=00006 name=+DATA/d112d1/datafile/abcd_data.272.697114011

Channel ORA_DISK_1: starting piece 1 at 08/09/10 16:42:17

Channel ORA_DISK_1: finished piece 1 at 08/09/10 16:44:22

Piece

Handle=/u01/oraback/D112D1/backupset/2010_08_09/o1_mf_nnndf_TAG20100809T164216_660t194b_.

Bkp tag=TAG20100809T164216 comment=NONE

Channel ORA_DISK_1:

Backup set complete, elapsed time: 00:02:05

Finished backup at 08/09/10 16:44:22

This clause creates backup files in an organized manner. The above command creates a directory D112D1 (the name of the instance), a directory called backupset under that directory, and another directory under the backupset directory with the file creation date as its name. Finally, create the backup content using the system-generated tags. When you use this command to back up the archive log, the backup contents are located under the subdirectory archivelogs, and so on.

You can also use this clause in the ALLOCATE CHANNEL command:

RMAN > run {

2 > allocate channel C1 type disk to destination'/ u01amp oraback'

3 >}

More code compression options (version 2 only)

Code compression in RMAN is nothing new; it has been used for some time. The following shows how to create a code-compressed backup set for tablespace ABCD_DATA.

RMAN > backup as comcodessed backupset

2 > format'/ u01qqorabackhip% U.rmb'

3 > tablespace abcd_data

4 >

In Oracle Database 11g version 1, we saw the introduction of a new encryption algorithm called ZLIB, which is faster (using less CPU), but the code compression ratio is reduced. In Oracle Database 11g version 2, several code compression options are available.

The default code is compressed to the basic configuration, which does not require any additional overhead to purchase options. Using comcodession's advanced options, you can now specify different types of code compression levels: LOW, MEDIUM, and HIGH-code compression ratios from lowest to highest, and CPU usage (opposite RMAN throughput) from lowest to highest. Here is the command to configure the comcodession option to high:

Rman > configure comcodession algorithm 'high'

In the test, I used the HIGH level to get the backup set of code compression, and the number of bytes compressed was 118947840, compared with 1048952832 bytes without code compression, the space was about 1 inch 9. Of course, the compression ratio varies depending on the database.

The higher the setting of the comcodession option, the smaller the backup set is created, which makes sense for slower networks, but takes up CPU cycles.

Backup to the cloud (version 2 only)

At the end of this article, we will discuss one of the most exciting advanced features of the RMAN goal. In today's era of cloud computing, there is a superior feature, which is backup, so enterprises are turning to cloud-based service providers instead of investing in their own hardware. As defined by itself, backups should be off-site; the cloud is the best choice. Amazon provides Simple Storage Service (S3), which is essentially a large storage bubble that can store as much content as you want. As a customer, you only need to pay according to the actual use. Amazon is responsible for the reliability of storage.

Oracle Database 11g version 2 comes with a variety of tools (libraries and software) to back up Oracle databases to Amazon S3 through RMAN using a specially developed Media Management Library (MML). I will not introduce this service here, but I hope you will turn your attention to the step-by-step guide to the service, http://download.oracle.com/docs/cd/E11882_01/backup.112/e10643/web_services001.htm#RCMRF90490.

The guide is well written and contains code, and it is completely superfluous to introduce it here.

These are all the contents of the article "what are the new features of Oracle11g backup and recovery". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.