Alejandro Vargas' Blog

This post describes the procedure required to migrate a database from Windows to Linux using the RMAN Convert Database command.

Both Windows and Linux platforms have the same endian format, which makes possible to transfer the whole database, making the migration process very straightforward and simple.

To migrate between platforms that have a different endian format, Cross Platform Transportable Tablespaces (XTTS) needs to be used instead.

List of Steps Needed to Complete the Migration

The migration process is simple, but as it has several steps it is convenient to be familiar with them before running it.

1. Check platform compatibility between source and target OS
2. Start the database in read only mode
3. Check database readiness for transport from Windows to Linux using DBMS_TDB.CHECK_DB
4. Check if there are any external objects
5. Execute the Rman Convert database command
6. Copy converted datafiles, generated Transport Script and Parameter File to Linux
7. Edit the init.ora for the new database
8. Edit the Transport Script and Parameter File changing the windows paths to Linux Paths
9. Execute the Transport Script
10.Change the Database ID
11.Check database integrity

For a detailed step by step guide please check this document : Database Migration From Windows to Linux Using RMAN

On Wednesday, July 16 we will have our 3rd RAC and ASM on Linux Forum at the Sheraton Hotel in Tel Aviv, this time dedicated to Performance and Maximum Availability Architecture (MAA).

We have several invited speakers from Oracle Israel: Oded Ilan, Gadi Chen and myself will speak about ASM performance; Eyal Druskin and Nickita Chernovsky will explain the concept of MAA, I'll present a short demo of Active Data Guard.

Then we have two special invited speakers:

Saar Maoz, from Oracle Corporation, Racpack Team will speak about performance tuning of RAC using AWR reports.

Husnu Sensoy, from Turkcell, the main cellphone services provider in Turkey will speak about his experience implementing a 50TB database based on ASM.

The presentations can be downloaded here: Rac on Linux Forum Presentations, If you are based on Israel and didn't register yet please go to this link to see the program and register: Oracle RAC on Linux Forum

See you there!

A couple of times I've removed ASM disks from a diskgroup and found that the rebalance operation will take too long.

This is not a problem when you don't want to disturb online users, the rebalance process only locks for writes 1mb of data at a time, so letting the rebalance to run slowly has no performance impact.

My problem was that I needed to free the disks as fast as possible in order to finish some IO tests within a limited timeframe.

The procedure to change the rebalance power of an ongoing operation is very simple:

alter diskgroup DATADG rebalance power 6;

After that the rebalance operation will restart with the new set rebalance power.

For a complete example check this document:

Changing the rebalance power of an ongoing rebalance operation

Change Control is one of the most important aspects of managing a production database environment, the back port of this functionality is a major breakthrough, that will make easier to migrate 9i production environments to 10g and 11g.

SQL Performance Analyzer permits to identify SQL
performance issues caused by system changes, the performance analyzer assess the impact of that changes and provide a report that highlight any  differences between the before and after situations.

Database Replay permits to
perform comprehensive change control testing, using workloads taken from production environments. Problems can
be identified and solved on the test stage before implementing the changes on
production.

Whole details of the process can be obtained from Metalink Note: 560977.1

This functionality for 11g has been ported to
Oracle Server - Enterprise Edition - Versions 9.0.1.0  to  11.1.0.6

• 9.2.0.8.0 + one off
  patch 6973309.
• 10.2.0.3.0 + one off patch 6974999

Oracle Recovery Manager, RMAN, is at the same time simple and complex, it's sintax can be as direct as 'backup database' to make a whole database backup, and as complex as it can be to make possible the most sophisticated and complex backup and recovery tasks.

This post covers a series of tests I did prepare to show how Rman works, the tar of the scripts contained on the guide can be downloaded here.

This RMAN Hands-On guide, once you have configured the environment, can be followed in about 3 hours, it covers the basics of Backup, Restore and Recovery of Oracle Databases using RMAN.

This hands on practice is organized into 4 chapters

• CATALOG
• ADMINISTRATION    
• BACKUP  
• RESTORE AND RECOVERY

• Build and administer an Rman Catalog
• Use different techniques for backing up a Database
• And the most important: How to restore and recover the database in different crisis scenarios

Bigfile Tablespaces may become a standard implementation on databases using high end storage and Oracle Automatic Storage Management.

In order to avoid potential performance issues Bigfile Tablespaces must being built on top of a file system that can grow up dynamically and that support file striping, both characteristics are native to ASM.

<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"><title></title><meta name="GENERATOR" content="OpenOffice.org 2.3 (Linux)">This feature not only address the need of very large databases enabling datafile sizes of up to 4G blocks per tablespace of storage, the maximum database size using Bigfile tablespaces is 8 exabytes whith 32K blocksize.

Combined with Oracle Managed Files (OMF), Bigfile tablespaces makes datafile management completely transparent to the DBA, thus greatly simplifying small - medium and very large databases storage management.

The DBA will need to be aware and only check that enough free space is always available at the level of ASM DiskGroup, to support the natural growth pace of its applications.

Bigfile tablespaces can be implemented at database creation.

Using DBCA, you will need to edit the definition of each tablespace and check the 'use Bigfile' checkbox.

 'bigfile-dbca'

To add a Bigfile tablespace using OMF enter this command:

SQL>  select TABLESPACE_NAME,BLOCK_SIZE,BIGFILE,SEGMENT_SPACE_MANAGEMENT from dba_tablespaces;

------------------------------ ---------- --- ------
SYSTEM                              16384 YES MANUAL
SYSAUX                              16384 YES AUTO
UNDOTBS1                            16384 YES MANUAL
TEMP                                16384 YES MANUAL
USERS                               16384 YES AUTO
DEV                                 16384 YES AUTO

6 rows selected.

SQL> select bytes,file_name from dba_data_files where tablespace_name='DEV'
     /
     BYTES 	FILE_NAME
---------- 	--------------------------------------------------
 104857600 	+DATADG/redpanda/datafile/dev.276.654704777

Extended RAC is a Tier 6 DRP technology that enable zero data loss in case of major disaster at a local site, and near 0 downtime if well configured and well managed.

It is an expensive technology because of the costs associated with the required infrastructure, dark fiber over long distances and redundant components on all hardware layers.

A strict change control procedure must be in place, with an identical test environment where all changes to the infrastructure and new code versions are carefully tested before implementation on the production site.

Oracle 11g provides new features that greatly help on implementing extended clusters, and makes it the version that best fit the challenge.

The syncronization between sites is obtained using ASM redundancy, reads are made locally at each site using ASM preferred mirror read feature, and in case of a local storage failure ASM fast mirrot resync make recovery much easier.
   
10g R2 and 11g Dataguard FSFO (Fast Start Failover) technology provide a similar level of protection at less cost and at greater distances, as it relays on TCP for communications, so it is convenient to consider it as an option when evaluating extended RAC for DRP.

This document: Extended RAC On Pure Oracle Stack Summary contains basic implementation guidelines.

More information can be found on these excellent documents:

Resizing the online redologs on a RAC environment is a simple task, that require a little more attention than that of a single instance.

Usually we do resize when redolog switches happen too frequently. Take care to add all the new larger groups, then switch over until the current redolog for each instance is on the new larger groups before starting to remove the old groups.

You can find a step by step description of the procedure on this document: How to Resize the Online Redologs on a RAC Environment

In some cases it may happen that you have only one instance of the RAC database up:

SQL> select inst_id,thread#,status,enabled,groups,instance,sequence# from gv$thread
/

   INST_ID    THREAD# STATUS ENABLED      GROUPS INSTANCE    SEQUENCE#
---------- ---------- ------ -------- ---------- ---------- ----------
         1          1 CLOSED PUBLIC            3 sati1              41
         1          2 OPEN   PUBLIC            3 sati2              58

You will still see that both threads have a current redolog with status active:

SQL> select inst_id,group#,thread#,sequence#,bytes,members,status from gv$log
  2  /

   INST_ID     GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS STATUS
---------- ---------- ---------- ---------- ---------- ---------- ----------------
         1          1          1          0   10485760          2 UNUSED
         1          2          1          0   10485760          2 UNUSED
         1          3          1          0   10485760          2 UNUSED
         1          4          2         59   10485760          2 CURRENT
         1          5          2          0   10485760          2 UNUSED
         1          6          2          0   10485760          2 UNUSED
         1         10          1         39   52428800          2 INACTIVE
         1         11          2         56   52428800          2 INACTIVE
         1         12          1         40   52428800          2 INACTIVE
         1         13          2         57   52428800          2 INACTIVE
         1         14          1         41   52428800          2 CURRENT
         1         15          2         58   52428800          2 INACTIVE

In this case you will not be able to remove the current group of the thread belonging to the instance that is down until you start the instance and switch over this thread to the new groups; if you try to remove the current group of a down instance you will get the following error:

SQL> alter database drop logfile group 14;
alter database drop logfile group 14
*
ERROR at line 1:
ORA-01623: log 14 is current log for instance sati1 (thread 1) - cannot drop
ORA-00312: online log 14 thread 1: '+DATADG/sati/onlinelog/group_14.303.648232897'
ORA-00312: online log 14 thread 1: '+DATADG/sati/onlinelog/group_14.289.648232903'

In the last weeks I had the opportunity to work on two cases of disaster recovery.
There are a couple of lessons learned from both cases:

1. Check your backups
2. Backup your archived logs
3. Make backups of the database structure (full export without data)
4. Make backups of your controlfiles (backup controlfile to trace)
   

To rename a database we set the new name recreating the controlfile, in the case of a RAC database the procedure is slightly more complex, as we need to recreate the controlfile in single instance mode using a modified pfile, and then recreate the spfile.

Once the new controlfile is ready we need to register the database with CRS in order to enable its management as a RAC database.

This document "How to Recreate the Controlfile on a RAC Environment" illustrate the steps required to accomplish that.