Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Oracle 11G question



On 04/05/2013 09:49 AM, Edward Ned Harvey (blu) wrote:
>> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
>> bounces+blu=nedharvey.com at blu.org] On Behalf Of Jerry Feldman
>>
>> What I would like to do is:
>> 1. shutdown the listeners and console
>> 2. allocate a 1TB vdisk and mount it onto /oradata.new. I'm thinking of
>> using LVM so that I can add more space by adding another logical volume.
>> 3. copy all the bits from /oradata to /oradata.new
>> 4. unmount /oradata
>> 5. remount /oradata.new onto /oradata
>> 6. restart oracle
> LVM sometimes gives you freedom where you otherwise would have had none, but this is a VM, most likely you can expand your disk without LVM.
>
> 1.  Comment-out /ordata from /etc/fstab, and chkconfig the oracle services off.
> 2.  Reboot.  It should come up cleanly without that mountpoint.  The reboot isn't actually necessary, it just proves a point.  Guarantees you're able to dismount and guarantees nothing's using it.
> 3.  Log into the vm host, and snapshot.  It's always good to snapshot the volume before expanding it.
> And then expand the volume.
> 4.  As appropriate, fdisk to expand partitions inside the volume.
> 5.  resize2fs
> 6.  Re-enable fstab and chkconfig.  Reboot.  It should all come up cleanly.
>
>
>

On 04/05/2013 09:53 AM, Edward Ned Harvey (blu) wrote:
> If for any reason you can't just expand the volume, and you need to create a new volume, then definitely use LVM.  Don't partition the new volume - Use pvcreate directly on the new device /dev/sdb or whatever.
>
> When you mount your new volume and need to migrate, the smartest and most reliable way to do it is to dismount the old volume, and then dump -0af - /dev/olddisk | restore -rf -  (while you're in the mounted new volume.)  This is better than cp or tar or anything else, because dump & restore are written by the same people who write the ext2/3/4 filesystem code.  Natively, dump & restore support all properties that the filesystem supports.  No need to read crazy manuals to come up with a list of 90 arguments of rsync or tar to get everything just right.
>
We have a site shutdown next week. I was planning on bringing the system 
up in single-user mode to do the copy (or dump/restore). The current 
/oradata volume is on the boot vmdk. Normally when I set up an image it 
uses LVM, but in the cases where we migrated 8 physical systems to 
virtual systems, it was the data center people who set up the images for 
us. I very familiar with normal data trasnfers as we are planning a big 
one moving from our ReadyNAS 3100 (about 4.5TB). That has to be done 
while people are logged in. It not only involves the home directories 
which are not heavily used by most, but also many product directories. 
Doing it peacemeal would require selectively changing the automount 
mapson each of the hosts, but also stopping and starting autofs.

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org