Kevin Kempf's Blog

August 9, 2016

How to Migrate an Oracle database host in R12.2 using LVM

Filed under: Oracle, Oracle Linux — kkempf @ 9:40 am

Painting the backdrop

I realize this post is somewhat specific to your setup, but I believe it may hold value to some folks out there so I thought I’d formalize it.  In my case, I have a rather large (1TB+) database residing on Oracle Linux (RHEL) 5 which serves as the back end for my EBS 12.2 environment.  We do not use ASM nor RAC, but do use Linux LVM (logical volume manager) to make growing disks easier.  The disk itself is on a SAN in the data center, so in my case this process involves some assistance from the systems/network folks.

I’m moving from OL5 to OL6 because support for OL5 is running down.  Let’s face it: the database works great on OL5, and I have no compelling reason to migrate it, but this is part of our lives: upgrades for the sake of upgrading.

For the purposes of this post, I’ll simply use oldhost as the OL5 hostname, and newhost as the OL6 hostname for the database, and appshost as the hostname for the applications tier.

In the olden days

Oracle used to have a bonafide methodology for migrating the database tier, in 11i it’s spelled out under DOC 338003.1.  It made sense; it said to use the tech stack on the front end to tell the application tier that there’s a new host for the database.

The R12.2 solution

I opened an SR to get the equivalent document for 12.2 and the analyst basically said “Follow Doc ID 1968231.1 to use logical hostnames, you can sort of use autoconfig but we don’t support it”.  I don’t know if that’s really the best answer, but it was all I had to go with.  I had been planning to use DNS as a safety net, not the primary vehicle of changing the database hostname.  But apparently it’s the only vehicle now, despite the fact that I enter hostname on the front end in the context file.  While I think this is a terrible answer, that’s not the point of my post so I’ll let it go.

LVM Setup (oldhost)

In my environment, I set up my lvm volume groups like this:

Data1 - product datafiles for EBS
Data2 - more product datafiles for EBS
Archivelogs - archivelog destination
Redo - online redo
System - system/sysaux datafiles
RDBMS - Oracle database installation (binaries)
As you can imagine, the files contained in these groups are pretty large; well over a terabyte.  In an ideal situation, I’d take the database down cold and simply rsync the files to the new host in the same location, then crank everything up.  But that would take hours I don’t have, so I went a different route.  It’s worth noting, that on OL5, my disks on oldhost are ext3, and OL6 delivers ext4.  Since I’m moving the disks “as is”, I’m getting ext3 filesystems on newhost, the OL6 server.  It’s compatible, and something I just have to live with.
I feel like I should mention at this point that probably the very first step was to build newhost as an OL6 environment with appropriate cpu and memory.

LVM Prep (oldhost)

  • The first step is to shut everything down, obviously, front and back end on oldhost and appshost.
  • Next, I unmount all the volumes pertaining to the environment (in this case, dev).  For my environment, each of these corresponds to an LVM volume group
    • umount /u01/appdev
    • umount /u03/appdev
    • umount /u04/appdev
    • umount /u05/appdev
    • umount /u06/appdev
    • umount /usr/local/oracle/archive
  • Set all the volume groups to inactive
    • vgchange -an Data2
    • vgchange -an Data1
    • vgchange -an Archivelogs
    • vgchange -an Redo
    • vgchange -an System
    • vgchange -an RDBMS
  • Export the volume groups
    • vgexport Data2
    • vgexport Data1
    • vgexport Archivelogs
    • vgexport Redo
    • vgexport System
    • vgexport RDBMS

Disk manipulation

At this point, the volumes can be safely manipulated by the disk admins.  What this entails will vary greatly based on  your datacenter, and is outside the scope of linux so I’m not going to detail it here.  The gist of it is that your admin needs to remove the disks/virtual disks from the old host and install them on the new one by whatever means is appropriate.  I apologize in advance if I’m not saying this part correctly.

Adding the disks (newhost)

The first thing to try (assuming your new host received the disks “hot”) is simply


They may just show up.  If not, you can try rescanning the scsi host:

ls /sys/class/scsi_host/ | whileread host ; do echo "- - -"> /sys/class/scsi_host/$host/scan ; done
-or this-
echo "- - -"> /sys/class/scsi_host/(host#, hit tab or guess)/scan
-for example this may turn into:

 echo “- – -” > /sys/class/scsi_host/host0/scan

echo “- – -” > /sys/class/scsi_host/host1/scan

echo “- – -” > /sys/class/scsi_host/host2/scan

Then issue
fdisk -l
and it’s worth noting you can watch /var/log/messages for the system to recognize new disks being added.  When all else fails, a reboot has never failed to get all disks recognized.
At this point, pvscan should show all your volume groups

Final steps (newhost)

It’s kind of the opposite of the prep steps:

  • Import the volume groups
    • vgimport Data2
    • vgimport Data1
    • vgimort Archivelogs
    • vgimport Redo
    • vgimport System
    • vgimport RDBMS
  • Active the volume groups
    • vgchange -ay Data2
    • vgchange -ay Data1
    • vgchange -ay Archivelogs
    • vgchange -ay Redo
    • vgchange -ay System
    • vgchange -ay RDBMS
  • Mount the disks (and put them in /etc/fstab so they survive a reboot!)
    • mount /dev/mapper/RDBMS-Dev /u01/appdev
    • mount /dev/mapper/System-Dev /u03/appdev
    • mount /dev/mapper/Redo-Dev /u04/appdev
    • mount /dev/mapper/Data1-Dev /u05/appdev
    • mount /dev/mapper/Data2-Dev /u06/appdev
    • mount /dev/mapper/Archivelogs-Logs /usr/local/oracle/archive

Final Steps

In my case, I had to do 3 final steps to comply with Oracle’s document and make everything work:

  • change /etc/hosts on appshost to explicitly refer to the newhost as oldhost… just in case
  • change listener.ora on newhost to be the new hostname on the database ($TNS_ADMIN)
  • add DNS record to change calls to old host to new one
  • Start up the database (newhost)

Parting Shots

This method took me about 30 minutes.  If the database were smaller, I’d simply rsync the ext3 filesytems to new disks built as ext4 on newhost.



Blog at