Oracle RMAN 11g Backup and Recovery (128 page)

372
Part III: Using RMAN Effectively

to platforms with different endian byte formats. We finish with a discussion of using RMAN to move databases between different platforms with the same endian byte format.

Introduction to Cross-Platform Transportable Tablespaces

On several occasions, we, as DBAs, really wanted to be able to move our tablespaces between our development NT Oracle database and our production Sun Oracle database. We have had cases where we really wanted to move them between a Sun platform and an AIX platform. Until Oracle Database 10
g,
this was just a dream.

Now, Oracle supports transporting tablespaces across almost all platforms of the Oracle database family. This has a number of benefits, including:

■ Efficient publication of data between different content providers

■ Easy movement of data between data warehouses, data marts, and OLTP systems

■ Easy migration of databases across platforms

NOTE

Not all platforms are currently supported for this functionality. Check
your platform-specific documentation to determine if your platform is
eligible.

There are a few other issues to mention. To move a tablespace between platforms,
compatible
must be set to 10.0.0 or higher. When this occurs, tablespace datafiles will be made platform-aware upon the next startup operation. Note that read-only and offline datafiles become cross-platform compatible only after they have been made read-write or brought online.

Byte Ordering and Datafile Conversion

In this section, first, we introduce you to the concept of byte ordering in Oracle database datafiles and how this impacts transporting your tablespace between different platforms. Then, we will look at how to convert these datafiles, if that is required.

Datafile Byte Ordering

Oracle platforms generally use two different byte-ordering schemes (known as the endian formats).

If the platforms use the same byte-ordering scheme, then you can transport tablespaces as you always have in the past, no problem…. Go ahead and try it. We will wait for you!

If the byte-ordering scheme is different, then you will need to use the
convert
command in RMAN to convert the tablespace to the format that it will need to be in on the target platform.

You can determine the endian format via a join of the dynamic view V$DATABASE and the new V$TRANSPORTABLE_PLATFORM view, as shown in this example:

SQL> Select endian format

2 From v$transportable platform tp, v$database d

3 Where tp.platform name d.platform name;

ENDIAN FORMAT

--------------

Little

Chapter 14: RMAN Advanced Recovery Topics
373

In this case, the system we are on is using the little endian format. Thus, if the query returns the same result on both systems, you have a compatible datafile format; if it does not, you need to use RMAN and the
compatible
parameter to transport the tablespaces.

Converting the Tablespace Endian Format with RMAN

If you need to convert a tablespace for another platform, RMAN is the tool you use. First, create the directory that the converted file will be copied to. In our example, we will use the directory path c:\oracle\oradata\betatwo. Next, make the tablespace that you wish to convert read-only.

Then, simply start RMAN and use the new
convert tablespace
command, as shown in this example: Rman target /

RMAN> convert tablespace users

to platform ' AIX-Based Systems (64-bit)'

db file name convert 'c:\oracle\oradata\betatwo',

'c:\oracle\admin\transport aix';

You can also convert datafiles at the destination site:

Rman target /

RMAN> convert datafile c:\oracle\oradata\betatwo\*'

from platform ' AIX-Based Systems (64-bit)'

db file name convert 'c:\oracle\oradata\betatwo',

'c:\oracle\admin\transport aix';

The platform name that we use comes from the PLATFORM_NAME column of the V$TRANSPORTABLE_PLATFORM view. Oracle is very picky about putting the name in just right.

Once you have completed the conversion, you may complete the move by manually moving the datafiles/tablespaces using transportable tablespaces. Note that in cases where the endian format is different, RMAN will not be able to help you. If the endian format is the same, read the next section to see if you can use RMAN’s new feature that moves your database across platforms for you!

We Like to Move It! Move It!

RMAN in Oracle Database 10
g
offers a brand-new feature to assist you in moving your databases across platforms of the same endian byte format. The
convert database
command, in combination with the DBMS_TDP package, can help reduce the overall workload of moving your database between platforms. The process consists of the following steps:

1.
Open the database as read only:

startup mount;

alter database open read only;

2.
Use the
dbms_tdb.check_db
procedure to check the database state. You should have already determined your platform name (from the PLATFORM_NAME column of the V$TRANSPORTABLE_PLATFORM view). This program should be run with
serveroutput
turned on, as in this example:

set serveroutput on

declare

db ready boolean;

begin

db ready : dbms tdb.check db

374
Part III: Using RMAN Effectively

('Microsoft Windows IA (32-bit)',dbms tdb.skip readonly);

end;

/

3.
Use the
dbms_tdb.check_external
procedure to identify external objects: set serveroutput on

Declare

external boolean;

begin

external : dbms tdb.check external;

end;

/

4.
When the database is ready for transport, use the RMAN
convert database
command.

RMAN creates scripts that are required for the database move. RMAN does not actually do the move, but creates only the files that are used for the move.

CONVERT DATABASE NEW DATABASE 'copydb'

transport script 'c:\oracle\copydb\copyscripts'

to platform 'Microsoft Windows IA (32-bit)';

The optional
db_file_name_convert
parameter allows you to define the directory filenames for datafiles that need to be converted. Here is an example:

CONVERT DATABASE NEW DATABASE 'copydb'

transport script 'c:\oracle\copydb\copyscripts'

to platform 'Microsoft Windows IA (32-bit)'

db file name convert

'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ROB10R2','C:\ORACLE\NEWDBDEST';

Once the command completes, simply follow the directions that RMAN will give you to complete the conversion process on the target database.

Sometimes Things Just Go Wrong

Sometimes you just cannot get a break. On some rare occasions, RMAN just will not work like it’s supposed to. So, what do you do? Here are some suggestions we suggest you try if your RMAN

restore/recover is not quite going the way you want it to.

If the restore is not working successfully, execute the
crosscheck
command, and make sure that all the backup sets that RMAN thinks are available are actually available. The
crosscheck
command is used to make sure that the RMAN catalog and control file are in synch with what is actually on disk. We discuss the
crosscheck
command in detail in Chapter 17. In the case where a
restore
command is not working, or is picking up a wrong backup set, run these commands: crosscheck backup of database;

crosscheck backup of archivelog all;

crosscheck archivelog all;

If any of the backup sets show up with a status of EXPIRED, then you may be missing backup sets that are needed to perform the restore. This can be due to many reasons—loss of a disk drive, or perhaps a well-meaning system administrator has backed them up to tape for you.

Chapter 14: RMAN Advanced Recovery Topics
375

If the backup sets are all okay, and the restore is still not running correctly, then make sure you check things such as how you have set the UNTIL TIME parameter if you are doing a pointin-time restore. True story: In one case, we had a DBA (a really smart one, by the way) who was trying to restore from a backup taken on 04/01/09. Unfortunately, it took something like four hours for him to realize that his restore string read 03/01/09 instead. It is small syntax errors like this that can drive you mad.

Oftentimes the error messages can give you some clue as to the problem. For example, they may indicate that the media management layer is not properly configured. This is a common problem, particularly if you are restoring a backup to a database server other than the one where the backup originally occurred.

If the
restore
command works great but the
recover
command is failing, check for syntax errors again. This is another place where you can get your dates wrong. Also make sure that all the needed archived redo logs are available. One problem we see from time to time is that some of the needed redo ends up not having been archived. Sometimes we have to go to the online redo logs to replay that redo. In cases like this, we will actually need to go into SQL*Plus and complete the recover process manually.