테스트로 사용하던 서버가 뻗었는데, 마침 실제 운영하던 서버가 죽어서
급한 대로 서비스에 실사용하고 있었던 터라 상황이 난감해졌습니다.
일단 관련 검색어로 검색해서 연락해보고 있는데, 상황이 썩 좋지 않네요..
혹시 관련한 일로 도움 주실 수 있는 업체, 또는 개인분 알고 계시면 답변 부탁드립니다...ㅠㅠ
테스트로 사용하던 서버가 뻗었는데, 마침 실제 운영하던 서버가 죽어서
급한 대로 서비스에 실사용하고 있었던 터라 상황이 난감해졌습니다.
일단 관련 검색어로 검색해서 연락해보고 있는데, 상황이 썩 좋지 않네요..
혹시 관련한 일로 도움 주실 수 있는 업체, 또는 개인분 알고 계시면 답변 부탁드립니다...ㅠㅠ
원인이야 다양한데
대략, 어떤식으로 장애라는게 나와야 되지않을까요....
복구관련 업체를 부르면, 아마도 비용은 좀 나오실듯하네요
그런데, 최악의 상황에서 파일이 깨지거나, 복원해야되는 상황이라면, 백업이 없다면 대략 난감한 상황일수있더군요
일단 오라클이 올라오질 않는 상황이어서 복구도 어렵구요..
(그나마 수월하게 할수도 있지만, 어렵게 갈수도 있고...OS에 따라서 약간 달라질수도 있고)
더불어서, 백업이 작년 10월이면...그동안 ARCHIVE LOG도 없을거 같고....
아마도 그냥 당시 시점으로 백업만 하신거 같은데....
현재 시점에서 깨진 데이터는 포기하고 서비스올리는게 최선일듯한데....음....
그냥...업체 부르시는게 좋으실듯하네요
그런데, 평소 장애 관련 계약이 되지않은 업체라면...음....그것도 주말에 긴급이면 금액은 좀 나오지않을까하네요
금액은...이렇게 공개적으로 언급하기는 좀....
말씀대로 일단 서비스 복구만 좀 하고 싶어요..
근데 계약한 업체도 없고.. 일단 검색해서 연락을 해보긴 했는데,
한 곳은 복구 불가능하다고 하고, 한 곳은 실무자들이 다 출장중이고 ㅠㅠ
마지막은 담당자분이 저녁에 연락주시기로 하셨는데, 만약 이 분도 포기하시면.. lllOrz
아, 금액은 제가 생각이 짧았네요..
사실 금액 부담도 걱정이 많아져서.. 으.. 생각이 많아지네요
ORA-01110: data file 7: 'C:\APP\ORACLE\PRODUCT\12.1.0\DBHOME_1\DATABASE\****.DBF'
실제 사용하던 테이블 스페이스가 깨졌다고 뜨더라구요.
처음 문제 생겼을 땐 잠깐 접속 되길래 사소한 문제라고 생각했는데, 점점 일이 커지네요..
exp 해놓은 파일도 없고.. 미치겠네요 ㅠㅠ..
사용자 데이터용 TABLESPACE 라면...아마도 어렵지않나 하네요
dbv 라는 유틸리티를 사용해보세요
혹시, 오라클이 그냥 죽어버린건가요?
아니면 서버가 다운되어서 오라클이 깨진건가요?
후자라면, 위험한 방법이 하나 있긴한데...좀 위험하긴한데
C: 드라이브의 디스크검사를 해서 OS에서 파일이 깨졌다면 OS에서 파일을 복구해서 올라오는경우도 있긴한데
이건, 위험한 방법이라서....
정말 파일이 이상하게 꼬인다면, 현상황보다 더 나빠질수는 있어요
그래서, 추천은 못하겠네요
--
2227074 페이지가 유입 - 매체 손상이 있음직합니다
Corrupt block relative dba: 0x0021fb82 (file 1024, block 2227074)
Fractured block found during dbv:
Data in bad block:
type: 6 format: 2 rdba: 0x0021fb82
last change scn: 0x0000.0f445f1a seq: 0x9 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x85070604
check value in block header: 0x1867
computed block checksum: 0xcb01
2247746 페이지가 유입 - 매체 손상이 있음직합니다
Corrupt block relative dba: 0x00224c42 (file 1024, block 2247746)
Fractured block found during dbv:
Data in bad block:
type: 6 format: 2 rdba: 0x00224c42
last change scn: 0x0000.0f32eea4 seq: 0x1 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x891f0605
check value in block header: 0x6786
computed block checksum: 0x67bf
DBVERIFY - 검증 완성
전체 페이지가 검색되었습니다 : 7616000
전체 페이지가 프로세스됨 (데이터) : 3344616
전체 페이지가 실패됨 (데이터) : 0
전체 페이지가 프로세스됨 (인덱스): 1887711
전체 페이지가 실패됨 (인덱스): 0
처리된 페이지 합계(LOB) : 127738
실패한 페이지 합계(LOB) : 0
전체 페이지가 처리되었습니다 (다른 것): 350416
처리된 총 페이지 수(Seg): 0
실패한 총 페이지 수(Seg): 0
전체 페이지가 비었습니다 : 1905517
전체 페이지에 손상한 것 표시 : 2
전체 페이지 유입 : 2
암호화된 페이지 합계 : 0
최대 블록 SCN : 256150867(0.256150867)
--
materialized view를 생성하던 도중에 랙 이전 작업으로 전원을 내린게 문제가 된 것 같습니다.
그래서, 아마 끽해야 MV 재생성정도로만 끝날 줄 알았는데 일이 점점 커지네요..;
Corruption Block skip 하고 싶어도 DB가 계속 죽으니 설정도 안되고..
일단 서비스가 올라가던지, 좀 손상되었더라도 exp만 되면 괜찮을 것 같은데.. 으으..
비용은 얼마나 나올까요?
일단 열심히 찾아보고는 있는데, 이게 꿈이었으면 좋겠습니다..
MSSQL도 복구해주는건 500부터 시작입니다. 오라클은 더 따블로 부르겠죠 머.
디스크 저장소단 즉 스토리지나 레이드 어레이 단에서 먼저 셧다운 되어버리면 DB계층 파일들은 깨지기가 쉽습니다. 위에 김상진님 답변이 최후의 수단이긴 한데 그 방법은 리스크가 따라가는거죠. MSSQL도 오라클과 마찬가지로 위와 같은 상황이 있었습니다. 복구는 할수 있었지만 시간은 엄청 오래걸렸었습니다.
일단,
Oracle 유지 보수 업체 (유지 보수 계약X) 를 통해 해결하였습니다.
완전 복구는 불가능했구요.. 다만, 서비스를 유지할 만큼 충분히 올라와 준 것 같아 너무 기쁩니다!!