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, 데이터베이스, 로컬 디스크 / 오라클에 설치된 오라클 소프트웨어, 데이터베이스는 / ORADATA에 설치되어 있어야합니다.
둘째, 프로젝트 계획 단계의 변화
(1), 데이터베이스, 다른 시스템 예비 PC에 / ORADATA 디렉토리 전체 백업을 중단했다.
도 2를 참조하면, RAID 5 어레이 레벨에서 수정할 수있는 큰 스토리지 DS3950 여유 공간, RAID10가되기 때문에.
3 인해 lun03, lun04는 lun03, lun04에 vg_ossdb의 선두에서 제거하고, 변경을 용이하게하기 위해 저장 어레이 레벨상에서 매핑 해제 사용하지.
4, SQL을 최적화 할 수있는 DBA에 의해, 물건을 작은 일괄 제출을 만들기 위해 노력할 것입니다.
셋째, 시스템 환경 및 데이터 릴리스 노트
[루트 @ ol64 /] # 고양이의 / etc / 실행
오라클 서버 릴리스 6.4 리눅스
ON 커널 \ 연구를 \ m
[@ ol64 루트 /]은 uname -a #
리눅스 ol64.com # 2.6.39-400.17.1.el6uek.x86_64는, SMP (금)에 2013년 2월 1일 태평양 표준시 (22)는 x86_64에 x86_64의는 GNU / 리눅스 x86_64에 18시 16분 18초이다
는 SQL은> V에서 SELECT * 버전 $,
배너
---------------------------------------------- ----------------------------------
오라클 데이터베이스 11g 엔터프라이즈 에디션 출시 11.2.0.4.0 - 64 비트 생산의
PL / 릴리스 11.2.0.4.0 SQL - 생산의
핵심 11.2.0.4.0 생산의
리눅스에 대한 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 #의 볼륨 그룹이 비활성화
0 논리 볼륨 "vg_ossdb"볼륨 그룹 (들) 지금 활성
[루트 @ ol64 /] #은 vgremove를 vg_ossdb는 / dev / SDB는 / dev / SDC는 / dev / SDD는 / dev / SDE #误用vgremove를命令删除了vg_ossdb은
정말 당신을 수행 한 논리 볼륨을 포함하는 볼륨 그룹 "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 이름为空,冒汗보내고.
--- 물리 볼륨 ---
PV 이름은 / dev / sda2와
VG 이름 vg_ol64
PV 크기 199.51 지브 / 사용할 수 없음 3.00 MiB 크기
할당 가능 예
PE 크기 4.
무료 PE 33,660
할당 된 PE 17,414
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 태양 광-TITF QJgg-UNA8-d3QZ - ZTES3P
[루트 ol64 @ ~] ING. 땀 #vgscan vg_ossdb 정보, 심장 박동,시 #이 발견되지 vgscan을
읽기 모든 물리적 볼륨.이 켜짐은 시간이 걸릴 수 있습니다. ..
찾을 볼륨 그룹 "vg_ol64"메타 데이터 유형 LVM2은 Using
[@ ol64 루트 ~] 정보를 찾을 수 없습니다 # lvoradata lvscan #lvscan, 뇌 빈, 거의 기절.
활성 '는 / dev / vg_ol64 / lvopt'[10.01 지브] 상속
활성 '는 / dev / vg_ol64 / lvroot'[40.01 지브] 상속
활성 '는 / dev / vg_ol64 / lvswap'[8.00 지브] 상속
활성 '는 / dev / vg_ol64 / lvhome'[10.01 지브] 상속
내가 vgremove를 명령을 사용하는 방법? ? 완료! ! ! vg_ossdb 내가 실수로 삭제했다. 빠르게 구글과 바이두 VG 삭제 후 복구하는 방법에 대한 검색, 그들은 관련 정보를 찾을 수 있습니다. 아래의 / etc / LVM / 디렉토리 진정 아래로 각 파일의 사용에 대한 시작 생각.
다섯, VG 복구 아이디어
LVM, 보관, 백업 및 기타 정보를 사용하여 / etc / lvm / 스토리지 구성에서 1,.
[루트 ol64 @ ~] -l LS #은 / etc / LVM
총 52입니다
------ ¹ 록 drwx. 2 루트 18 루트 11 월 4096 8시 반 아카이브입니다
은 drwx ------. 2 루트 18 루트 11 월 4096 8시 반 백업입니다
------ ¹ 록 drwx.이 루트는 4096 년 2 월 24 일 루트 캐시 2013
-rw-R & LT -.. 37,554 r-- 사용 2월 1일 (24) 2013 년의 루트하여 루트있어 스캔하여
백업 정보에 저장하여 / etc / lvm / backup / VG 2,하지만 작동 vg_ossdb 전에하지 다시 자신의 정보를 백업 할 다른 디렉토리로 이동합니다.
[루트 LVM ol64 @] LS 번호은 / etc / LVM / 백업 /
총. (4)는
루트 (12)가 루트 vg_ol64 9시 9분이다 -------. 2575 11 월. 1 -rw
. 3 미만은 / etc / LVM / 아카이브 /가 보관 VG 또는 LV 변경 사항이 현재 정보를 백업합니다 변경하기 전에이며, VG와 LV 조정하기 전에 보관 된 정보를 제공합니다.
[루트 ol64 @ ~] -l LS #은 / etc / LVM / 보관 /
총 32
-rw -------. 2576 11 월. 1 루트 (12)는 루트입니다 9시 9분 vg_ol64_00000-1722993391.vg
-rw ----- -.. 883 11 월 1 루트 (18)는 루트 8시 3분 vg_ossdb_00000-2033719300.vg입니다
. 루트 18 루트 vg_ossdb_00001-1635801039.vg 8시 4분입니다 -rw ------- 883 11 월 1이다.
------- -rw. 1122 11 월. 1 루트 18 8시 5분 vg_ossdb_00002-1283186973.vg 루트이다
-rw -------. 883 11 월. 1 루트 (18)는 루트 8시 5분 vg_ossdb_00003-1708919759.vg
-rw -------. 1139 11 월. 1 루트 (18)가 루트 8시 5분 vg_ossdb_00004-18964421.vg이다
. -rw -------. 1728 11 월 1 루트 (18)는 루트 8시 반 vg_ossdb_00005-533258090.vg
-rw-- ----- 1 개 루트 루트 1131 11 월 18 일 08:30 vg_ossdb_00006-1987723911.vg.
참고 : 사용하는 경우 vgcreate이, 대해 vgreduce, vgremove를이은 lvcreate가에서 lvreduce가 하려면 lvremove 명령은 새 아카이브 정보를 생성합니다
(가) 명령하고 vgcfgrestore를 복원하여, (4) 실수의 VG를 삭제
[@ ol64 루트 아카이브] -f # /etc/lvm/archive/vg_ossdb_00001-1635801039.vg vg_ossdb하고 vgcfgrestore
볼륨 그룹 vg_ossdb을 복원
[@ ol64 루트 아카이브] #의 pvdisplay
--- --- 물리적 볼륨
태양 광 이름 / DEV / SDB
VG 이름 vg_ossdb
PV 크기 200.00 지브 / 사용할 수 없음 4.00 MiB 크기
할당 가능 예
PE 크기 4.00 MiB 크기
총 PE 51199
무료 PE 51,199
할당 된 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 33,660
할당 된 PE 17,414
PV UUID 0dyB8L-p7ZM-Mkcw-76ae-DXPh-U6zg-9kIQ8z
"는 / dev / SDC 200.00 지브 ""의 새로운 물리적 볼륨은 "
--- NEW 물리 볼륨 ---
PV 이름은 / dev / SDC
VG 이름
PV 크기 200.00 지브
할당 가능 NO
PE 크기 0
총 체육 0
무료로 PE 0
체육 0 할당 된
UUID를 4VKCJ9-G6kL-QJgg-TITF-UNA8-d3QZ-ZTES3P 태양 광
작업의 발견 단지는 / dev / SDB에서 vg_ossdb 볼륨 그룹은 / dev / SDC 아직 vg_ossdb 볼륨 그룹 동안 . 오래된 보관 /etc/lvm/archive/vg_ossdb_00001-1635801039.vg이 프로그램은,는 / dev / SDC에서 vg_ossdb 볼륨 그룹을 포함은 / 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 / 디바이스 / vg_ossdb
볼륨 그룹 인치 1 논리 볼륨 (S) "vg_ossdb"지금 활성
[루트 @ ol64 아카이브] 중 # lvscan
활성 '는 / dev / vg_ossdb / lvoradata'[200.00 지브] 상속
활성 '는 / dev / vg_ol64 / lvopt'[10.01 지브] 상속
활성 '는 / 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 /
총 1,698,340
-rwxrwxr-X. 1 오라클 11월 18일 8시 29분 control01.ctl의 9,748,480 oinstall
-rwxrwxr-X. 1 오라클 1,073,742,336 oinstall 십일 18 8시 11분 redo01.log
-rwxrwxr-X. 1 오라클 1,073,742,336 oinstall 십일 18 8시 11분 redo02.log
-rwxrwxr-X. 1 오라클 1,073,742,336 oinstall 십일 18 8시 29분 redo03.log
-rwxrwxr-X. 2,147,516,416 십일 18 8시 29분 sysaux01.dbf의 oinstall 1 오라클
-rwxrwxr-X. 2,147,516,416 십일 18 8시 29분 system01.dbf의 oinstall 1 오라클
-rwxrwxr-X. 1 오라클 oinstall 8,388,640,768 십일 18 6시 38분 temp01.dbf
는 X --- rwxrwxr. 1 17179901952 11월 18일 8시 29분 UNDOTBS01.DBF의 oinstall 오라클
-rwxrwxr-X 축. 1 오라클 17179901952 oinstall 11월 18일 8시 29분는 users01.dbf
// ... 생략
모든 것이 정상입니다, 데이터베이스를 시작합니다.
요약 : VG의 변경 작업을 수행 할 때, 피하기 사고, VG vgcfgbackup을 먼저 정보를 백업해야합니다.
[루트 @ ol64 /] # vgcfgbackup을 -f /home/vg_ossdb.backup vg_ossdb
이 작업이 손상이 발생하지 않았다, 그러나 나를 깨웠다 있지만. 시스템 관리자, 각 단계는 잘 생각해야합니다. 큰에게 운영 권한, 더 큰 책임을 기억하십시오!
