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

Early this year I developed an ASM training that was implemented on Madrid and Tel Aviv.

The idea was to have a set of exercises that will provide lots of hands-on experience to the participants, in a few days.

On this and the following posts I will present the labs of the training.

The training was implemented using the student’s laptops. A Virtual Machine containing a Linux 5 environment setup with Oracle 10g and 11g, ready for implementing the labs, was distributed to the participants.

The requirements were :

· Laptop with a minimum of 30 GB free space on the hard disk or an external disk
· 2 / 4 GB Memory
· Sun Virtualbox 2.2 installed on the laptop

On the first lab included here : Lab1 Configuration of Devices for ASM. we created devices to be used by ASM in several different ways, the idea was to provide many examples and train the fingers on how to build ASM disks on top of them; that also provided some insights about how the discovery process works.

The whole program cover these subjects

ASM Hands-On Training Program

Training Program

DAY 1

· Getting around on the system
· ASM Architecture
· Preparing storage devices for ASM
· Preparing storage for ASM
· Loop devices,
· File system,
· Raw devices,
· Block devices
· ASMLib
· Install ASMLib,
· Create the ASM Instance
· Create the ASM instance,
· Managing diskgroups
· Kfed
· Using kfed to identify ASM Headers
· Using kfed to dump the headers of a physical device
· ORION
· Installing, configuring and running ORION simple test
· Using RMAN for Restoring a Database Into ASM
· Configure Diskgroups for restoring a database into ASM,
· Restore Database from Backup
· Normal Redundancy
· PST table
· 10g ASM Normal Redundancy Resilience test
· Drop database,
· Create Normal Redundancy Disk Group,
· Restore Database,
· Resilience test
· Additional Means for Managing ASM
· Configure XDB
· Using FTP with ASM
· Browsing ASM Directories with HTML
· Migrating Devices to ASMLib
· Migrate raw devices and block devices to ASMLib

DAY 2

· Migration to 11g
· 10g ASM migration to 11g
· Create an 11g Database in ASM
· ASM Backup, Crash, Restore and Recovery Scenarios
· Backup and Restore ASM Metadata
· ASM and Rman Crash, Restore and Recovery Scenarios Hands-On - Part I
· ASM and Rman Crash, Restore and Recovery Scenarios Hands On – Part II
· 11g ASM New Features
· Setting up 11g Compatibility Parameters
· Resilience Tests
· ASM Cloning
· Cloning a Disk group on the same server
· Bringing Up a copy of the databases on a cloned Disk Group
· Benchmarking, Monitoring and Troubleshooting
· Configure and Run Swingbench
· Configure and run OSWatcher
· Resilience Tests While Running a Benchmark Load

DAY 3

· ASM Storage Sizing
· Measuring throughput
· Defining Infrastructure requirements for Optimal Performance with ASM
· Hardware
· ASM on SAN, NAS
· ASM Metadata
· ASM Directories
· COD and ACD
· Block Dump,
· DbVerify,
· Header Dumps,
· dd
· Storage Consolidation
· Plugging ASM to a 2nd Node,
· Open the database on the 2nd Node,
· ASMCMD
· Using ASMCMD commands and options
· ASM on Extended Clusters
· Normal Redundancy
· Preferred Mirror Read
· Fast Mirror Resync
· DWDM
· Buffer Credits
· ASM on Exadata
· Frequent SR Issues on ASM

On this Lab we create the ASM instance on a single instance environment, and create ASM diskgroups in several different ways using different kind of devices. Note that these exercises provide some degree of confidence on managing devices but are valid only for training.

On a production environment we will use mostly a high end SAN or NAS storage, usually connected by fiber channel, and we will provision LUN's for ASM.

The lab can be accessed here : Lab3-Create-ASM-Instance-and-Managing-Diskgroups.pdf

Lab Index

Create The ASM Instance
Create the Cluster Synchronization Services Daemon
Configure and Start a Listener
Sizing the ASM Shared Pool
Setup a minimal ASM Pfile
Disk Discovery
Discovering Raw Devices
Discovering Block Devices
Discovering ASMLib Devices
Creating Disk Groups Using Loop Devices
KFED
Build the Kfed Utility
Kfed Help
Check Disk Headers Using Kfed
Creating Normal Redundancy Disk Groups Using Block Devices
Comparing External And Normal Redundancy Disk Using Kfed
Using File System Based Files As ASM Disks
Creating a diskgroup on ASM based on files
Check the diskgroups created on this Lab
Scripts

For Databases requiring normal redundancy I definitively recommend 11g instead of 10g, because the fast mirror resynchronization new feature that makes possible to reinstate a failed disk without requiring to rebuild it as is the case on 10g.

This Hands ON series move on a later lab the database to 11g to test this options. In this lab we still work with 10g.

Normal Redundancy on 10g provides protection against disk failures, but it does require for the failed disk to be reconfigured after failure.

On this lab we will simulate a disk failure and then we will restore the failed disk

Details on this document:
Normal Redundancy Resilience Test 10g

To work on the 11g part of the Labs we will start restoring an 11g database we have on a backup.
The backup consist of an incremental level 0 backupset, a controlfile and spfile backup and the archived logs required to recover the database.

The restore is done in 6 steps
· Re-create the ASM metada
· Restore the spfile
· Restore the controlfile
· Restore the datafiles
· Recover the database
· Open resetlogs

This is covered on this file:
Restoring a Lost Database From Backup

On the previous Labs we created ASM disks based on OS Files, before continuing with the next labs we need to clear them.

This is explained on this file:
Cleanup File based ASM Diskgroups

On this Lab we will review the following crash and recovery scenarios, and we will implement some of them:

• · System tablespace loss
• · Recover system tablespace
• · User datafile loss
• · Recover users tablespace
• · Online redo loss
• · Recover from redo loss
• · Controlfile loss
• · Recover from controlfile loss
• · Database loss
• · Recover from total loss

Details on this file
ASM and Rman Crash Restore and Recovery Scenarios

Sometimes it is required having several clones of the same database running on the same server. That was simple to do when the database was based on File System, and is still simple to do with the help of Rman.

But there are very large databases, which are usually cloned using storage tools like bcv, srdf or snapshots that cannot consider Rman as a viable possibility.

For these databases there is the possibility to implement the procedure we will test on this lab.

Note that the rename disk group script has not been made public.
The rename disk group functionality is available on 11g R2 that was made available to the general public on August 2009.

These are the steps required to complete the process:

1. Prepare a set of storage devices with enough space to hold a copy of the diskgroup to be copied
2. Shutdown the source database
3. Make a bit by bit copy of the source database on the target devices
4. Add kfed path to the path of user root
5. Execute the rename diskgroup script
6. Rename ASM disks of the cloned devices
7. Rescan ASM disks
8. Start the ASM instance and mount the new diskgroup
9. Recreate the controlfile and rename the database based on the cloned diskgroup
10.Open the clone with the resetlogs option

Details on this file:
Cloning Disk Group

On this lab we will review various utilities that provide further information for managing ASM.

Checksum Mismatch After Storage Crash, AMDU an 11g tool that can be used with 10g as well, Blockdumps, Asmiostats and asmdebug

Details on this file: ASM Metadata and Other Checkups

On this lab we will share our ASM disks with a second server and we will open the sati12 database on it.

To do that we copied the vm to another location, without including the ASM disks, that are located on a separate folder, this way the second vm is pointing to the same ASM disks as the first one.

Details on file: Storage Consolidation With ASM

On this lab we will review some of the useful set of commands provided by the ASM command line utility.

Some of the asmcmd commands display information, these information is based on v$asm views, other commands actually make changes to the structure like mkdir or rm.

Details on file: ASMCMD Use And Options