1. 복구 사례 개요
SAS HDD 4개로 구성된 RAID5 서버에서 장애가 발생하여 Oracle 10g 데이터베이스에 접속할 수 없었던 사례입니다.
저장장치에는 약 100GB 규모의 데이터베이스가 저장되어 있었습니다. 먼저 RAID 구성과 디스크 상태를 분석하고 데이터를 확보한 후 Oracle 데이터베이스의 손상 여부를 확인해야 하는 상황이었습니다.
고객의 업무 복구가 시급했기 때문에 전체 데이터베이스 복구를 기다리기보다 긴급하게 필요한 테이블을 먼저 복구하는 방향으로 작업을 진행했습니다.
주요 작업 정보
- 데이터베이스: Oracle 10g
- 서버 저장장치: Fujitsu SAS HDD
- HDD 모델: Fujitsu MBA3147RC
- 디스크 구성: SAS 147GB HDD 4개
- RAID 구성: RAID5 및 Spare 디스크 1개
- 데이터베이스 용량: 약 100GB
- 긴급 우선 복구 데이터: 약 13GB
- RAID 복구 소요 시간: 약 1일
- 전체 테이블 복구 소요 시간: 약 2주
※ 위 내용은 해당 사례의 작업 기록을 바탕으로 작성했습니다. 실제 작업 조건에 따라 복구 시간과 결과는 달라질 수 있습니다.
2. 장애 발생 상황
고객은 Fujitsu MBA3147RC SAS HDD 4개를 사용하여 RAID5 스토리지를 구성하고 Oracle 10g 데이터베이스를 운영하고 있었습니다.
그러나 RAID 장애가 발생하면서 Oracle 데이터베이스에 접속할 수 없게 되었습니다.
데이터베이스 파일의 용량은 약 100GB였으며, 저장장치 장애를 해결하는 것뿐 아니라 데이터베이스 파일이 정상적으로 연결되고 필요한 테이블을 사용할 수 있는지도 확인해야 했습니다.
이와 같은 장애에서는 RAID 구성을 복구했다고 해서 Oracle 데이터베이스까지 반드시 정상화되는 것은 아닙니다. 저장장치 장애로 인한 데이터 손상과 데이터베이스 내부의 논리적 손상을 각각 확인해야 합니다.
3. RAID 디스크 상태 및 구성 분석
먼저 RAID를 구성하는 모든 HDD의 물리적 상태를 확인하고, 각 디스크의 데이터를 복제하는 작업을 진행했습니다.
디스크 상태를 확인하는 과정에서 4개 HDD 모두 배드섹터 증상이 확인되었습니다. 장비를 이용해 디스크 복제를 완료한 뒤 각 디스크의 데이터를 분석하여 기존 RAID 구성을 파악했습니다.
분석 결과, 4개 디스크 중 3개가 RAID5 구성에 사용되었고 나머지 1개는 Spare 디스크로 확인되었습니다.
이처럼 RAID 장애가 발생했을 때는 디스크 개수만으로 기존 구성을 추정해서는 안 됩니다. 실제 데이터와 RAID 구성 정보를 분석하여 디스크의 역할과 배열 방식을 확인해야 합니다.
4. RAID 복구 후 Oracle 데이터베이스 손상 확인
RAID 구성을 분석하고 데이터를 확보한 뒤 Oracle 데이터베이스 파일을 복구하여 Oracle 10g에 연결을 시도했습니다.
그러나 데이터베이스 연결 과정에서 오류가 발생했습니다.
저장장치의 물리적 장애를 처리한 이후에도 데이터베이스 내부의 손상이 남아 있었던 것입니다. 따라서 RAID 복구만으로 작업을 끝낼 수 없었으며, Oracle 데이터베이스 자체에 대한 추가 복구가 필요했습니다.
이 사례는 서버 RAID 장애와 데이터베이스 손상이 동시에 발생할 수 있으며, 저장장치 복구와 데이터베이스 복구를 구분하여 확인해야 한다는 점을 보여줍니다.
5. Oracle 데이터베이스 복구 및 긴급 데이터 우선 확보
전체 데이터베이스를 복구하는 데에는 상당한 시간이 필요할 것으로 예상되었습니다.
이에 고객과 협의하여 업무에 긴급하게 필요한 테이블을 먼저 확인하고, 약 13GB의 데이터를 우선 복구하기로 했습니다.
Oracle 데이터베이스 복구 작업을 진행한 결과, 손상된 정보를 수정한 후 Oracle 10g에 정상적으로 접속할 수 있었습니다. 우선 복구한 약 13GB의 데이터는 백업 파일로 전달하여 고객이 업무를 재개할 수 있도록 했습니다.
이후 나머지 테이블도 순차적으로 복구했습니다.
데이터베이스 복구 과정에서는 일부 손상된 레코드로 인해 작업이 중단되는 문제가 발생했습니다. 원인을 확인하고 해당 문제를 처리한 뒤 복구 작업을 다시 진행해야 했습니다.
특히 레코드 값, 한글 데이터, 날짜형 데이터 등의 상태에 따라 오류가 발생할 수 있어, 단순히 파일을 복사하는 방식만으로는 복구를 완료하기 어려운 상황이었습니다.
6. 복구 결과 및 소요 시간
이번 사례에서는 RAID 복구와 Oracle 데이터베이스 복구를 단계적으로 진행했습니다.
- RAID 복구: 약 1일
- 긴급 데이터 우선 복구: 약 13GB
- 전체 테이블 복구 완료까지: 약 2주
- 데이터베이스 접속: 복구 작업 후 정상 접속 확인
긴급하게 필요한 데이터를 먼저 확보한 뒤 나머지 테이블을 순차적으로 복구하여 고객의 업무 복구를 지원했습니다.
데이터베이스 전체 복구에는 손상된 레코드를 확인하고 오류 원인을 처리하는 추가 작업이 필요했습니다. 따라서 저장장치의 복구 시간과 데이터베이스 전체 복구 시간에는 차이가 있었습니다.
7. 이번 사례에서 중요한 점
RAID 복구와 데이터베이스 복구는 다릅니다.
RAID 구성이 복구되어 데이터베이스 파일을 확보하더라도 Oracle 데이터베이스 내부에 손상이 남아 있을 수 있습니다. 이 경우 데이터베이스 파일과 관련 정보를 추가로 분석해야 합니다.
긴급한 데이터부터 우선 복구할 수 있습니다.
전체 데이터베이스 복구에 시간이 필요한 상황에서는 고객에게 필요한 테이블과 업무 우선순위를 확인하여 일부 데이터를 먼저 확보하는 방안을 검토할 수 있습니다. 실제 가능 여부는 데이터 상태와 손상 범위에 따라 달라집니다.
손상된 레코드는 추가 분석이 필요할 수 있습니다.
데이터베이스 복구 과정에서 손상된 레코드로 인해 작업이 중단될 수 있습니다. 이 경우 오류 원인을 확인하고 데이터 상태를 분석한 뒤 작업을 이어가야 하므로 전체 작업 시간이 길어질 수 있습니다.
8. Oracle 데이터베이스 및 RAID 장애가 발생했다면
서버 RAID 장애로 Oracle 데이터베이스에 접속할 수 없거나, 데이터베이스 파일을 확보했는데도 연결 오류가 발생한다면 저장장치와 데이터베이스 상태를 함께 확인해야 합니다.
장애 발생 후 RAID를 임의로 재구성하거나 디스크를 초기화하면 기존 데이터와 구성 정보가 변경될 수 있습니다. 불필요한 쓰기 작업을 최소화하고, 가능하면 기존 디스크 구성과 오류 정보를 보존한 상태에서 분석하는 것이 좋습니다.
인젠은 장애 증상과 저장장치 구성, 데이터베이스 파일 상태를 확인하여 분석 방향과 복구 가능 범위를 검토합니다.
Oracle 데이터베이스 장애 상담
Oracle 버전, 서버 및 RAID 구성, 장애 발생 시점, 오류 메시지 등을 알려주시면 필요한 확인 사항과 상담 절차를 안내해 드립니다.