I.背景説明
1、頻繁に非常にゆっくりと実行するために提出した小さなものが多数によるOSSのネットワークテストデータベース。/ I Oのボトルネック、待機イベントの多くは、性能が限られているプレゼンスDS3950ディスクストレージのための分析。また、同僚の開発が意識を最適化されていない、小さなものは、バッチの提出を行っていません。
図2は、DS3950、9つの600Gハードブロック（8 + 1スペアブロック）にRAID5アレイ、lun01、lun02、lun03、lun04はなかった 、 200G、OSSは、データベース・サーバにマッピングされます。
図3は、オペレーティング・システム、lun01、lun02 vg_ossdbボリュームグループのみ次vg_ossdbのLVを構成- lvoradataは/ oradataの上に取り付けられています。ターンlun03、lun04 vgextendの方法で、急速な成長への最近のデータは、行くためにvg_ossdbボリューム・グループへの展開が、lvoradataを拡張しないように。
図4は、データベースに、ローカルディスク/オラクルにインストールされたOracleソフトウェアは、データベースが/ oradataの上に設置しました。
第二に、プロジェクト計画と手順の転換
1は、データベース、他のマシンのスペアPCへ/ oradataにディレクトリの完全バックアップを停止しました。
2、RAID5アレイレベルから変更することができるDS3950大ストレージ空き容量が、RAID10になるからです。
図3は、原因lun03、lun04はlun03、lun04にvg_ossdbのリーダーからそれを削除し、変更を容易にするために、ストレージ・アレイ・レベル上でアンマップ、使用されません。
4、SQLを最適化するには、DBAによって、物事に小さなバッチ提出を作るしようとします。
第三に、システム環境とデータのリリースノート
[ルート@ ol64 /]＃のCATの/ etc /発行
のOracle Serverリリース6.4のLinux
AN \メートルONカーネル\ rを
[@ ol64ルート/]は、uname -a＃
Linuxのol64.com＃2.6.39-400.17.1.el6uek.x86_64 SMP金で2013年2月1日PST 22はx86_64のx86_64のGNU / Linuxのx86_64の午後六時16分18秒である
SQL>はVからSELECT *バージョン$;
BANNER
---------------------------------------------- ----------------------------------
Oracle Databaseの11グラムのEnterprise Editionリリース11.2.0.4.0 - 64ビット版の制作の
PL /リリース11.2.0.4.0 SQL -生産者
CORE 11.2.0.4.0生産の
Linux用のTNS：バージョン11.2.0.4.0 -生産者の
NLSRTLバージョン11.2.0.4.0 -生産者の
第四に、変換プロセスは、誤用vgremoveボリュームグループがvg_ossdbますされています削除、およびその意図はは/ dev / SDDとvgreduceは、/ dev / SDEの削除することです。
[ルート@ ol64 /]＃アンマウント / oradataに/＃ アンマウントファイルシステム
[ルート@ ol64 /]＃ます。vgchange -anは/ dev / vg_ossdb＃ 非活性化されたボリュームグループ
今、ボリューム・グループ"vg_ossdb"で0論理ボリューム（S）アクティブ
[ルート@ ol64 /]＃vgremove vg_ossdbは/ dev / sdbとは/ dev / sdcのは/ dev / SDDは/ dev / SDE＃误用vgremove命令删除了vg_ossdb
本当にやります1つの論理ボリュームを含むボリューム・グループ「vg_ossdb」を削除したいですか？[Y / N]：yは
あなたが本当にアクティブな論理ボリュームlvoradataを削除しますか？[Y / N]：yの
論理ボリューム「lvoradata」正常に削除
ボリュームグループ「vg_ossdb」正常に削除
ボリュームグループ「SDB」見つからない
ボリュームグループ「SDC」見つからない
ボリュームグループが見つかりません「SDD」
ボリュームグループ「SDE」を
除去"の/ dev / SDD"ボリュームグループ"vg_ossdb"から
[ルート@ ol64 /]＃vgreduce vg_ossdbの/ dev / SDE
除去"の/ dev / SDE"ボリュームグループ"vg_ossdb"から
########### ################################################## ####
再用pvremove命令移除は/ dev / SDD和の/ dev / SDE
[ルート@ ol64〜]＃pvremoveは/ dev / SDD
物理ボリュームのラベル"の/ dev / SDD"に成功拭い
[ルート@ ol64〜]＃ pvremoveは/ dev / SDE
物理ボリュームのラベル"の/ dev / SDE"に成功拭い
[ルート@ ol64〜]＃pvdisplay＃发现は/ dev / sdbの和は/ dev / sdcの所在VG名为空、冒汗ING。
---物理ボリューム---
PV名は/ dev / SDA2
VG名vg_ol64
PVサイズ199.51ジブ/ていない使用可能な3.00のMIB
割付けはい
PEサイズ4。
無料PE 33660
割り当てられたPE 17414
PV UUID 0dyB8L-p7ZM-Mkcw-76ae-DXPh-U6zg-9kIQ8z
"は/ dev / sdbと" "200.00ジブ"の新しい物理ボリュームがある
--- NEW物理ボリューム---
PV名は/ dev / sdbの
VG名
PVサイズ200.00ジブ
割付けNO
PEサイズ0
合計PE 0
無料PE 0
割り当てられたPE 0
PV UUID Ui9wea-II1q-KOx0-96pA-4epf-9hlc-4NFDJF
"は/ dev / sdcの"」の新しい物理ボリュームです200.00ジブ」
--- NEW物理ボリューム---
PV名は/ dev / sdcの
VG名
PVサイズ200.00ジブ
割付けNO
PEサイズ0
合計PE 0
無料PE 0
割り当てられたPE 0
UUID-G6kL-4VKCJ9 PV-TITF QJgg-UNA8-d3QZ-ZTES3P
[ルートol64 @〜] ING。発汗#vgscan vg_ossdb情報、心拍数、時に＃が見つからないvgscanを
読み取り、すべての物理ボリューム。このAにはしばらく時間がかかる場合があります。 ..
見つかりボリュームグループ"vg_ol64"メタデータの種類LVM2使用して
、[@ ol64ルート〜]の情報を見つけることができません＃lvoradata lvscan #lvscan、脳の空白、ほとんど気絶。
ACTIVE 'の/ dev / vg_ol64 / lvopt' [10.01ジブ]継承
ACTIVE 'の/ dev / vg_ol64 / lvroot' [40.01ジブ]継承
ACTIVE 'の/ dev / vg_ol64 / lvswap' [8.00ジブ]継承
ACTIVE 'の/ dev / vg_ol64 / lvhome' [10.01ジブ]継承
私はvgremoveコマンドを使用する方法？？完成！！！vg_ossdbは、私が誤って削除しました。迅速に削除された後に回復するためにどのようにGoogleと百度VGを検索、彼らは適切な情報を見つけることができませんです。下の/ etc / lvmの/ディレクトリの穏やかなダウン、各ファイルの使用についてのスタート思考。
五、VG回復アイデア
LVM、アーカイブ、バックアップや他の情報とは/ etc / lvmの/ストレージ構成では1、。
[ol64ルート@〜] -l LS＃の/ etc / LVM
合計52のIS
------ drwx。2ルート18、ルート11月4096午前8時30分アーカイブある
drwx ------。2ルート18、ルート11月4096午前8時30分バックアップである
drwx ------。2ルート2月24日4096のルートキャッシュ、2013
-rw-R＆LT - 。37554 r--の1 2013年2月24日にルートのlvm.confルート。
2、バックアップ情報の下に格納されているの/ etc / lvmの/バックアップ/ VGで、私は運転vg_ossdb前に戻って自分の情報をバックアップしません別のディレクトリに移動します。
[ol64ルートLVM @] LS＃の/ etc / LVM /バックアップ/
合計4
-rw -------。2575年、11月1日ルート12は、ルートvg_ol64午前9時09分である
。3、下の/ etc / LVM /アーカイブ/維持しました変更VGまたはLVの変更があなたの現在の情報をバックアップする前に、あるVGとLV調整前のアーカイブされた情報、。
[ルートol64 @〜] -l LS＃の/ etc / LVM /アーカイブ/
合計32
-rw -------。2576 - 11月1日ルート12、ルートで午前9時09 vg_ol64_00000-1722993391.vg
-rw ----- - 883 - 11月1日ルート18ルート8：03 vg_ossdb_00000-2033719300.vgある。
-rw ------- 883-11月1日ルート18は、8時04 vg_ossdb_00001-1635801039.vgルートです。
------- -rw。1122、11月1日ルート18は、8：05 vg_ossdb_00002-1283186973.vgルートで
-rw -------。883 - 11月1日ルート18がルートである午前8時05 vg_ossdb_00003-1708919759.vg
-rw -------。1139年、11月1日ルート18はルート8：05 vg_ossdb_00004-18964421.vgある
。-rw -------。1728年、11月1日ルート18がルートである午前8時30 vg_ossdb_00005-533258090.vg
-rw-- ----- 1ルートルート1131年11月18日8時30 vg_ossdb_00006-1987723911.vg。
注：使用vgcreate、vgreduce、vgremove、lvcreateの、lvreduce、 lvremove コマンドは新しいアーカイブ情報が生成されます
restoreコマンドのvgcfgrestoreを使用して、4偶然のVGを削除し
、[@ ol64ルートアーカイブ] -f＃/etc/lvm/archive/vg_ossdb_00001-1635801039.vg vg_ossdb vgcfgrestore
ボリュームグループvg_ossdbを復元
[@ ol64ルートアーカイブ]＃pvdisplay
--- ---物理ボリューム
PV名/ DEV / sdbの
VG名vg_ossdb
PVサイズ200.00ジブ/いない使用可能な4.00のMIB
割付けはい
PEサイズ4.00 MiBの
合計PE 51199
無料PE 51199
割り当てられたPE 0
PV UUID Ui9wea-II1q-KOx0-96pA-4epf-9hlc-4NFDJF
---物理ボリューム---
PV名/ DEV / sda2は
VG名vg_ol64
PVサイズ199.51ジブ/使用できない3.00のMIB
割付けはい
PEサイズ4.00 MiBの
合計PE 51074
無料PE 33660
割り当てられたPE 17414
PV UUID 0dyB8L-p7ZM-Mkcw-76ae-DXPh-U6zg-9kIQ8z
「は/ dev / sdcの200.00ジブ『"の新しい物理ボリュームが』
---新しい物理ボリューム---
PV名は/ dev / SDC
VG名
PVサイズ200.00ジブ
割付けNO
PEサイズ0
総PE 0
無料としてPE 0
PE 0割り当て
PV UUID 4VKCJ9-G6kL-QJgg-TITF-UNA8-d3QZ-ZTES3P
まだしばらくの/ dev / SDCの動作は、vg_ossdbボリュームグループのみの/ dev / sdbと見つからないvg_ossdbボリュームグループ。この番組/etc/lvm/archive/vg_ossdb_00001-1635801039.vgアーカイブ古い、vg_ossdbボリュームグループには/ dev / sdcの含まれていない、は/ dev / sdbとは/ dev /まで次のアーカイブ回復を続け SDC 彼らはvg_ossdbボリュームグループだった、とLVのボリューム番号が正しくグループに含まれています。
[@ ol64ルートアーカイブ] -f＃/etc/lvm/archive/vg_ossdb_00005-533258090.vg vg_ossdb vgcfgrestore
ボリュームグループvg_ossdbを復元
[@ ol64ルートアーカイブ]＃-ayます。vgchangeは/ dev / vg_ossdb
ボリュームグループインチ1つの論理ボリューム（S） "vg_ossdb"今のActive
[ルート@ ol64アーカイブ]＃lvscan
ACTIVE 'の/ dev / vg_ossdb / lvoradata' [200.00ジブ]継承
ACTIVE 'の/ dev / vg_ol64 / lvopt' [10.01ジブ]継承
ACTIVE 'の/ dev / vg_ol64 / lvroot' [40。
ACTIVE 'の/ dev / vg_ol64 / lvswap' [8.00ジブ]継承
ACTIVE 'の/ dev / vg_ol64 / lvhome' [10.01ジブ]継承
[ルート@ ol64アーカイブ]＃マウントは/ dev / vg_ossdb / lvoradata / oradataに/
[ルート@ ol64アーカイブ]＃LS -l / oradataに/ ossdb /
総1698340
-rwxrwxr-X。1 Oracleの11月18日午前8時29 control01.ctlとの9748480 oinstallを
-rwxrwxr-X。1オラクル1073742336 oinstallを11月18日午前8時11 REDO01.LOG
-rwxrwxr-X。1オラクル1073742336 oinstallを11月18日午前8時11 redo02.log
-rwxrwxr-X。1オラクル08:29 redo03.log 11月18 1073742336 oinstallを
-rwxrwxr-X。2147516416 11月18日午前8時29分SYSAUX01.DBFのoinstallを1オラクル
-rwxrwxr-X。2147516416 11月18日午前8時29分SYSTEM01.DBFのoinstallを1オラクル
-rwxrwxr-X。1オラクルてoinstall 8388640768 11月18日午前6時38 temp01.dbf
X --- rwxrwxr。1 17179901952 11月18日8時29 UNDOTBS01.DBFにoinstall Oracleの
-rwxrwxr-X-。1オラクル17179901952 oinstallを11月18日午前8時29分にはUSERS01.DBF
// ....省略し
、すべてが正常である、データベースを起動します。
概要：VGの変更を行うと、事故を避けるために、vgcfgbackupをVGとの最初の情報をバックアップすることを忘れないでください。
[ルート@ ol64 /]＃vgcfgbackupを -f /home/vg_ossdb.backup vg_ossdb
この操作は、損傷の原因となりますが、私は目が覚めませんでしたが。システム管理者として、各ステップは、よく考えなければなりません。、より高い操作権限を覚えて、より大きな責任！
