Database Reference
In-Depth Information
List of Backup Pieces for backup set 105 Copy #1
BP Key Pc# Status Piece Name
------- --- ----------- ----------
111 1 AVAILABLE +RECO/CDB1/BACKUPSET/2013_09_23/nnndn0_tag201...46_0.345.826878287
113 2 AVAILABLE +RECO/CDB1/BACKUPSET/2013_09_23/nnndn0_tag20130...6_0.346.826878291
114 3 AVAILABLE +RECO/CDB1/BACKUPSET/2013_09_23/nnndn0_tag201...446_0.267.826878291
112 4 AVAILABLE +RECO/CDB1/BACKUPSET/2013_09_23/nnndn0_tag20130...6_0.296.826878293
The output shown here is the result from a multi-section backup of the data file. Four channels were allocated
to back up a 700 MB data file, resulting in 4 backup pieces generated under backup set 105. You can also see from the
listing that the backup was an incremental level 0 backup and various other items of interest.
Refreshing an environment
Refreshing databases is part of the routine work database administrators have to go through. Once it is understood
and a process is put into place a database refresh is not too exciting and a good candidate for a scripted approach. In
recent years it has become more and more important to ensure that confidential information in the database-credit
card data for example-is masked before a test environment is handed over. A scripted approach should make use of
scrambling technology that has been developed with the business units. The effort in time this takes is proportional
to the number of applications making use of the database to be duplicated. This fact will play a role when defining
service level agreements with the business.
The RMAN “duplicate database” command has been available for a long time now and can be used for
duplicating environments. The command can be employed for full database refreshes—test or UAT environments for
example—or standby databases. The “from active database” option has been mentioned before in the introduction
and the Data Guard Chapters 9 and 10. It allows the database administrator to duplicate a database even if RMAN
does not have direct access to the source database backups on the destination host. Instead, the database will be
copied over the network, or—new with 12c—remote backup sets can be transferred. This active database duplication
is not always allowed on all sites as it poses an additional burden for the network. If possible, dedicated infrastructure
should be used for active database duplication.
As you would expect, the RMAN duplicate command has been enhanced for Pluggable Databases as well. You
can duplicate PDBs as well as CDBs. The use case for duplicating PDBs is interesting when it comes to cloning PDBs
across hosts. You should be able to clone PDBs locally anyway, see chapter 7 for more information on how to do so.
The RMAN duplicate command is one of the most complex RMAN commands, and the mastery of it requires training
and experience. The learning curve is smoothed somewhat by keeping a log file of the RMAN activities. The command
line parameter “log” can be used or a simple tail after output redirection. For interactive sessions the tee command
can be very useful, unlike the “log” option it displays the commands on screen. Consider these two examples:
[oracle@server1 ~]$ rman @test.rman checksyntax log=rman.log
RMAN> 2> 3> 4> 5> 6> 7>
[oracle@server1 ~]$
Compared to using the output redirection and tee:
[oracle@server1 ~]$ rman @test.rman checksyntax 2>&1 | tee rman.log
Recovery Manager: Release 12.1.0.1.0 - Production on Mon Sep 23 07:23:21 2013
Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved.
 
Search WWH ::




Custom Search