I. Background Description
1, OSS network test database due to the large number of small things frequently submitted to run very slowly. / The analysis for the presence DS3950 disk storage where I O bottlenecks, a large number of wait events, performance is limited. In addition, the development of co-workers is not optimized consciousness, not the small things made a batch submission.
2, in the DS3950, 9 600G hard blocks (8 + 1 spare block) did RAID5 array, lun01, lun02, lun03, lun04 , are 200G, OSS mapped to the database server.
3, the operating system, lun01, lun02 vg_ossdb constitute the volume group, only a next vg_ossdb LV - lvoradata mounted on / oradata. Recent data due to rapid growth, in turn lun03, lun04 vgextend way to expand into vg_ossdb volume group to go, but not expand lvoradata.
4, in the database, Oracle software installed on the local disk / oracle, database installed on the / oradata.
Second, the project plan and the transformation of step
1, stopped the database, the / oradata directory full backup to another machine spare PC.
2, since the DS3950 large storage free space, which can be modified from a RAID5 array level becomes RAID10.
3, due lun03, lun04 not used, remove it from the leaders of vg_ossdb in lun03, lun04, and unmap out on storage array level to facilitate change.
4, by the DBA to optimize SQL, will try to make things small batch submission.
Third, the system environment and data release notes
[root @ ol64 /] # CAT / etc / Issue
the Oracle Server Release 6.4 Linux
Kernel \ r ON AN \ m
[@ ol64 the root /] -a # the uname
the Linux ol64.com # 2.6.39-400.17.1.el6uek.x86_64 the SMP Fri On Feb. 1, 2013 the PST 22 is 18:16:18 the x86_64 the x86_64 the x86_64 the GNU / the Linux
the SQL> SELECT * from V Version $;
BANNER
---------------------------------------------- ----------------------------------
the Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production's
PL / Release 11.2.0.4.0 SQL - Production's
CORE 11.2.0.4.0 Production's
TNS for Linux: Version 11.2.0.4.0 - Production's
NLSRTL Version 11.2.0.4.0 - Production's
Fourth, the transformation process has been misused vgremove volume group will vg_ossdb delete, and its intention is to remove / dev / sdd with vgreduce, / dev / sde of.
[root @ ol64 /] # umount / oradata / # unmount filesystems
[root @ ol64 /] # vgchange -an / dev / vg_ossdb # volume group made inactive
0 logical volume(s) in volume group "vg_ossdb" now active
[root@ol64 /]# vgremove vg_ossdb /dev/sdb /dev/sdc /dev/sdd /dev/sde #误用vgremove命令删除了vg_ossdb
Do you really want to remove volume group "vg_ossdb" containing 1 logical volumes? [y/n]: y
Do you really want to remove active logical volume lvoradata? [y/n]: y
Logical volume "lvoradata" successfully removed
Volume group "vg_ossdb" successfully removed
Volume group "sdb" not found
Volume group "sdc" not found
Volume group "sdd" not found
Volume group "sde"found not dev / sdd[root @ ol64 /] # vgreducecorrect action is to remove the / dev / sdd and / dev / sde from vg_ossdb in with vgreduce command
################################################ ##################
Removed "/dev/sdd" from volume group "vg_ossdb"
[root@ol64 /]# vgreduce vg_ossdb /dev/sde
Removed "/dev/sde" from volume group "vg_ossdb"
#################################################################
再用pvremove命令移除/dev/sdd和/dev/sde
[root@ol64 ~]# pvremove /dev/sdd
Labels on physical volume "/dev/sdd" successfully wiped
[root@ol64 ~]# pvremove /dev/sde
Labels on physical volume "/dev/sde" successfully wiped
[root@ol64 ~]# pvdisplay #发现/dev/sdb和/dev/sdc所在VG Name为空，冒汗ing.
--- Physical volume ---
PV Name /dev/sda2
VG Name vg_ol64
PV Size 199.51 GiB / not usable 3.00 MiB
Allocatable yes
PE Size 4.00 Sweet
Total PE 51074
Free PE 33660
Allocated PE 17414
PV UUID 0dyB8L-p7ZM-Mkcw-76ae-DXPh-U6zg-9kIQ8z
"/dev/sdb" is a new physical volume of "200.00 GiB"
--- NEW Physical volume ---
PV Name /dev/sdb
VG Name
PV Size 200.00 GiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID Ui9wea-II1q-KOx0-96pA-4epf-9hlc-4NFDJF
"/dev/sdc" is a new physical volume of "200.00 GiB"
--- NEW Physical volume ---
PV Name /dev/sdc
VG Name
PV Size 200.00 GiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
The UUID-G6kL-4VKCJ9 the PV-TITF QJgg-UNA8-d3QZ-ZTES3P
[ol64 the root @ ~] # vgscan not found when #vgscan vg_ossdb information, heart rate, sweating ING.
Reading All PHYSICAL Volumes. This A On May Take the while. ..
Found Volume Group "vg_ol64" Metadata type LVM2 the using
[@ ol64 the root ~] # can not find the information lvoradata lvscan #lvscan, brain blank, almost fainted.
the ACTIVE '/ dev / vg_ol64 / lvopt' [10.01 GiB] the inherit
the ACTIVE '/ dev / vg_ol64 / lvroot' [40.01 GiB] the inherit
the ACTIVE '/ dev / vg_ol64 / lvswap' [8.00 GiB] the inherit
the ACTIVE '/ dev / vg_ol64 / lvhome' [10.01 GiB] the inherit
how I would use vgremove command? ? Finished! ! ! vg_ossdb was I accidentally deleted. Quickly search on google and baidu vg how to recover after being deleted, are they can not find the relevant information. Start thinking about the use of each file under / etc / lvm / directory calm down.
Five, VG recovery ideas
1, in the / etc / lvm / storage configuration with LVM, archiving, backup and other information.
[ol64 the root @ ~] -l LS # / etc / LVM
Total 52 is
------ drwx. 2 the root 18 is the root-Nov 4096 08:30 Archive
drwx ------. 2 the root 18 is the root-Nov 4096 08:30 Backup
drwx ------. 2 the root the root On Feb 24 4096 Cache, 2013
-rw-R & lt -. 37554 r--. 1 the root on Feb 24, 2013 the lvm.conf the root
2, in the / etc / lvm / backup / vg stored under the backup information, but I do not back up their information before operation vg_ossdb to another directory.
[ol64 the root LVM @] LS # / etc / LVM / Backup /
Total. 4
-rw -------. 2575-Nov. 1 the root 12 is the root vg_ol64 09:09
. 3, the under / etc / lvm / archive / kept the archived information before VG and LV adjustment, that is, before the change VG or LV changes will back up your current information.
[ol64 the root @ ~] -l LS # / etc / LVM / Archive /
Total 32
-rw -------. 2576-Nov. 1 the root 12 is the root 09:09 vg_ol64_00000-1722993391.vg
-rw ----- -. 883-Nov. 1 the root 18 is the root 08:03 vg_ossdb_00000-2033719300.vg
-rw ------- 883-Nov. 1 the root 18 is the root vg_ossdb_00001-1635801039.vg 08:04.
------- -rw. 1122-Nov. 1 the root 18 is the root 08:05 vg_ossdb_00002-1283186973.vg
-rw -------. 883-Nov. 1 the root 18 is the root 08:05 vg_ossdb_00003-1708919759.vg
-rw -------. 1139-Nov. 1 the root 18 is the root 08:05 vg_ossdb_00004-18964421.vg
-rw -------. 1728-Nov. 1 the root 18 is the root 08:30 vg_ossdb_00005-533258090.vg
-rw-- ----- 1 root root 1131 Nov 18 08:30 vg_ossdb_00006-1987723911.vg.
Note: use vgcreate, when vgreduce, vgremove, lvcreate, lvreduce, lvremove commands will generate a new archive information
4, using the restore command vgcfgrestore accidentally deleted VG of
[@ ol64 the root Archive] -f # /etc/lvm/archive/vg_ossdb_00001-1635801039.vg vg_ossdb the vgcfgrestore
Restored the Volume Group vg_ossdb
[@ ol64 the root Archive] # the pvdisplay
--- --- the Physical Volume
the PV the Name / dev / sdb
VG the Name vg_ossdb
PV Size 200.00 GiB / not usable 4.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 51199
Free PE 51199
Allocated PE 0
PV UUID Ui9wea-II1q-KOx0-96pA-4epf-9hlc-4NFDJF
--- Physical volume ---
PV Name /dev/sda2
VG Name vg_ol64
PV Size 199.51 GiB / not usable 3.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 51074
Free PE 33660
Allocated PE 17414
PV UUID 0dyB8L-p7ZM-Mkcw-76ae-DXPh-U6zg-9kIQ8z
"/dev/sdc" is a new physical volume of "200.00 GiB"
--- NEW Physical volume ---
PV Name /dev/sdc
VG Name
PV Size 200.00 GiB
Allocatable NO
PE Size 0
The Total the PE 0
as Free the PE 0
Allocated the PE 0
the PV the UUID 4VKCJ9-G6kL-QJgg-TITF-UNA8-d3QZ-ZTES3P
of the operation found only / dev / sdb in vg_ossdb volume group, while the / dev / sdc still not vg_ossdb volume group . This shows /etc/lvm/archive/vg_ossdb_00001-1635801039.vg archive older, does not include / dev / sdc in vg_ossdb volume group, continue with the next archive recovery until the / dev / sdb, / dev / sdc They were vg_ossdb volume group, and LV volume number contained in the group correctly.
[@ ol64 the root Archive] -f # /etc/lvm/archive/vg_ossdb_00005-533258090.vg vg_ossdb the vgcfgrestore
Restored The Volume Group vg_ossdb
[@ ol64 the root Archive] # -ay the vgchange / dev / vg_ossdb
. 1 Logical Volume (S) in Volume Group "vg_ossdb" now Active
[the root @ ol64 Archive] # the lvscan
the ACTIVE '/ dev / vg_ossdb / lvoradata' [200.00 GiB] the inherit
the ACTIVE '/ dev / vg_ol64 / lvopt' [10.01 GiB] the inherit
the ACTIVE '/ dev / vg_ol64 / lvroot' [40.
ACTIVE '/dev/vg_ol64/lvswap' [8.00 GiB] inherit
ACTIVE '/dev/vg_ol64/lvhome' [10.01 GiB] inherit
[root@ol64 archive]# mount /dev/vg_ossdb/lvoradata /oradata/
[root@ol64 archive]# ls -l /oradata/ossdb/
total 1698340
-rwxrwxr-x. 1 Oracle oinstall 9748480 Nov 18 08:29 control01.ctl
-rwxrwxr-x. 1 oracle oinstall 1073742336 Nov 18 08:11 redo01.log
-rwxrwxr-x. 1 oracle oinstall 1073742336 Nov 18 08:11 redo02.log
-rwxrwxr-x. 1 oracle oinstall 1073742336 Nov 18 08:29 redo03.log
-rwxrwxr-x. 1 oracle oinstall 2147516416 Nov 18 08:29 sysaux01.dbf
-rwxrwxr-x. 1 oracle oinstall 2147516416 Nov 18 08:29 system01.dbf
-rwxrwxr-x. 1 oracle oinstall 8388640768 Nov 18 06:38 temp01.dbf
the X---rwxrwxr. 1 the Oracle oinstall 17,179,901,952 Nov 18 08:29 UNDOTBS01.DBF
-rwxrwxr-the X-. 1 the Oracle oinstall 17,179,901,952 Nov 18 08:29 users01.dbf
// .... omitted
start the database, everything is normal.
Summary: When do the changes of VG, remember to back up information first with vgcfgbackup VG, to avoid accidents.
[root @ ol64 /] # vgcfgbackup -f /home/vg_ossdb.backup vg_ossdb
Although this operation did not cause damage, but woke me. As a system administrator, each step must be well thought out. Remember, the greater the operating authority, greater responsibility!
Reprinted: http://www.linuxdiyf.com/view_416040.html
