KR101547466B1 - 오라클 데이터베이스에서 데이터를 복원하는 방법 및 장치 - Google Patents

Abstract

오라클 데이터베이스에서 데이터를 복원하는 방법 및 장치에 관한 것으로서, 데이터 복원 장치가 데이터베이스로부터 시스템 파일을 입력받고, 시스템 파일에 포함된 시스템 테이블을 조회하여 시스템 파일 내의 하나 이상의 테이블들에 대한 스키마 정보를 도출하고, 스키마 정보에 기초하여 하나 이상의 테이블들 중 삭제된 테이블을 선별하고, 선별된 테이블의 오브젝트 ID를 통해 삭제된 레코드를 포함하는 데이터 블록을 검색하여 도출하며, 도출된 데이터 블록에서 삭제된 레코드를 식별하여 추출함으로써, 삭제된 레코드를 복구한다.

Description

오라클 데이터베이스에서 데이터를 복원하는 방법 및 장치{Apparatus and method for recovering data in oracle database}

본 발명은 오라클 데이터베이스에서 데이터를 복원하는 방법에 관한 것으로, 특히 트랜잭션 로그 파일에 비종속적으로 데이터베이스 파일에서 테이블 스키마 정보와 삭제된 레코드를 복원하는 방법에 관한 것이다.

일반적으로 조직은 방대한 양의 데이터를 통합적으로 관리하기 위해 데이터베이스를 이용하므로, 데이터베이스에는 업무데이터, 개인정보와 같은 중요한 정보가 저장되어 있는 경우가 많다. 이는 의미 있는 정보가 남아있을 가능성이 크다는 것을 뜻하므로 디지털포렌식 관점에서 데이터베이스가 중요한 조사대상임을 알 수 있다.

데이터베이스에서 정상적인 레코드를 추출하는 것도 중요하지만, 삭제된 레코드를 복구하는 것도 중요하다. 삭제된 레코드 복구를 통해 사용자의 행위를 재구성할 수 있고, 용의자의 고의적 증거 인멸 행위에 대응할 수 있으므로 수사에 큰 도움을 줄 수 있다.

테이블스페이스는 데이터베이스에서 실제 데이터를 물리적으로 저장하는 공간을 말한다. 이 테이블스페이스를 분석하면 데이터베이스의 테이블 데이터와 테이블 스키마 정보를 얻을 수 있다. IDC에 따르면 오라클 데이터베이스는 전 세계적으로 40.7%의 점유율을 기록하고 있으며 국내 데이터베이스 시장에서 오라클 데이터베이스는 60% 점유율을 기록하고 있다.

또한, 현재까지의 데이터베이스 포렌식에 대한 선행 연구는 트랜잭션 로그를 토대로 레코드를 복구하는 것에 집중되어 있다. P. Wright는 오라클 데이터베이스에서 리두로그(redolog)와 로그마이너(LogMiner)를 통해 데이터베이스의 변경사항을 추적하는 방안과 이전 시점의 데이터를 복원하는 방법에 대해서 설명하였다. 또한, Heloise Pieterse는 데이터베이스에서 암호화, 분할 저장 등을 이용하여 데이터 값이나 레코드, 테이블을 은닉하는 기법에 대해서 정리하였으며, 트랜잭션 로그의 중요성에 대해서 강조하였다. Oluwasola Mary는 데이터베이스에서 쿼리를 대수학으로 표현할 수 있음을 보였다. 그리고 쿼리를 역으로도 나타낼 수 있으며, 이 수식을 저장하는 Relational Algebra Log를 제안하였다. 이 로그를 통해 이전 시점의 데이터들을 복원하는 기법에 대해서 설명하였다. 일반적으로 오라클 데이터베이스의 삭제된 레코드를 복원할 때는 DBF파일과 트랜잭션 로그가 쌍으로 존재해야한다. 그리고 운용중인 오라클 데이터베이스에 로그마이너를 이용해 삭제된 레코드를 복원한다. 하지만, 이 방법은 트랜잭션 로그가 기록된 시점만 복구가 가능하며, 기록되지 않은 시점은 복구하지 못한다. 또한, 오라클 데이터베이스에서 트랜잭션 로그를 남기는 방법 중 노아카이브 모드(No Archive Mode)의 경우 미리 지정한 용량을 초과하게 되면 기존의 트랜잭션 로그에 덮어쓰기 때문에 오라클 데이터베이스 운용 환경이나 회사 정책에 따라 복구 여부가 결정될 수도 있다.

한편, 이하에서 인용되는 선행기술 문헌에는 데이터베이스의 논리적 오류 복구방법을 소개하고, 트랜잭션 로그를 통해 데이터를 복구하는 기술을 제안하고 있다. 하지만, 선행기술 문헌은 트랜잭션 로그를 통해서만 복구가 가능하다는 치명적인 단점이 존재한다.

이와 같은 관점에서, 트랜잭션 로그에 비종속적으로 데이터베이스에서 삭제된 레코드를 복구할 수 있는 기술적 수단이 필요하다는 사실을 알 수 있다.

공개특허공보 제 10-2010-0134355호 (2010.12.23)

따라서, 본 발명이 해결하고자 하는 첫 번째 과제는 데이터베이스에서 스키마 정보를 도출하며, 도출된 스키마 정보에 기초하여 삭제된 레코드를 추출함으로써, 트랜잭션 로그에 비종속적으로 데이터를 복원하는 방법을 제공하는 것이다.

본 발명이 해결하고자 하는 두 번째 과제는 데이터베이스에서 스키마 정보를 도출하며, 도출된 스키마 정보에 기초하여 삭제된 레코드를 추출함으로써, 트랜잭션 로그에 비종속적으로 데이터를 복원하는 장치를 제공하는 것이다.

또한, 상기된 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록 매체를 제공하는데 있다.

상기 첫 번째 과제를 해결하기 위하여, 본 발명의 일 실시예에 따른 데이터 복원 장치가 데이터베이스로부터 시스템 파일을 입력받는 단계; 상기 데이터 복원 장치가 상기 시스템 파일에 포함된 시스템 테이블을 조회하여 상기 시스템 파일 내의 하나 이상의 테이블들에 대한 스키마 정보를 도출하는 단계; 상기 데이터 복원 장치가 상기 스키마 정보에 기초하여 상기 하나 이상의 테이블들 중 삭제된 테이블을 선별하는 단계; 상기 데이터 복원 장치가 상기 선별된 테이블의 오브젝트 ID를 통해 삭제된 레코드를 포함하는 데이터 블록을 검색하여 도출하는 단계; 및 상기 데이터 복원 장치가 상기 도출된 데이터 블록에서 삭제된 레코드를 식별하여 추출함으로써, 삭제된 레코드를 복구하는 단계를 포함하는 데이터 복원 방법을 제공한다.

상기된 일 실시예에 따른 상기 데이터베이스는 오라클(oracle) 데이터베이스인 것을 특징으로 하는 데이터 복원 방법일 수 있다.

상기된 일 실시예에 따른 상기 스키마 정보를 도출하는 단계는, 상기 데이터 복원 장치가 상기 시스템 테이블에 포함된 테이블 명 OBJ$ 및 테이블 명 C_OBJ#를 검색하여 도출하는 단계; 및 상기 데이터 복원 장치가 상기 도출된 테이블 명 OBJ$ 및 테이블 명 C_OBJ#의 플래그 값에 따른 상기 스키마 정보를 도출하는 단계를 포함하는 데이터 복원 방법일 수 있다.

상기된 일 실시예에 따른 상기 테이블 명 OBJ$로부터 상기 스키마 정보 중 테이블 명, 오브젝트 ID, 및 테이블 생성 시간을 도출하는 것을 특징으로 하는 데이터 복원 방법일 수 있다.

상기된 일 실시예에 따른 상기 테이블 명 C_OBJ#으로부터 상기 스키마 정보 중 테이블의 오브젝트 ID, 컬럼 명, 컬럼 자료형 타입, 및 크기정보를 도출하는 것을 특징으로 하는 데이터 복원 방법일 수 있다.

상기된 일 실시예에 따른 상기 테이블은 상기 스키마 정보에 포함된 플래그 값이 0x6C일 경우 정상적인 테이블이고, 상기 스키마 정보에 포함된 플래그 값이 0x7C일 경우 삭제된 테이블인 것을 특징으로 하는 데이터 복원 방법일 수 있다.

상기된 일 실시예에 따른 상기 레코드의 플래그 값이 0x2C일 경우 삭제되지 않은 정상적인 레코드이고, 상기 레코드의 플래그 값이 0x3C일 경우 삭제된 레코드인 것을 특징으로 하는 데이터 복원 방법일 수 있다.

상기된 두 번째 과제를 해결하기 위하여, 본 발명의 일 실시예에 따른 데이터베이스로부터 시스템 파일을 입력받는 입력부; 상기 시스템 파일에 포함된 시스템 테이블을 조회하여 상기 시스템 파일 내의 하나 이상의 테이블들에 대한 스키마 정보를 도출하고, 상기 스키마 정보에 기초하여 상기 하나 이상의 테이블들 중 삭제된 레코드를 포함하는 테이블을 선별하며, 상기 선별된 테이블의 오브젝트 ID를 통해 삭제된 레코드를 포함하는 데이터 블록을 검색하여 도출하는 처리부; 및 상기 도출된 데이터 블록에서 삭제된 레코드를 식별하여 추출함으로써, 삭제된 레코드를 복구하는 추출부를 포함하는 데이터 복원 장치를 제공한다.

상기된 일 실시예에 따른 상기 데이터베이스는 오라클 데이터베이스인 것을 특징으로 하는 데이터 복원 장치일 수 있다.

상기된 일 실시예에 따른 상기 처리부는, 상기 시스템 테이블에 포함된 테이블 명 OBJ$ 및 테이블 명 C_OBJ#를 검색하여 도출하고, 상기 데이터 복원 시스템이 상기 도출된 테이블 명 OBJ$ 및 테이블 명 C_OBJ#의 플래그 값에 따른 상기 스키마 정보를 도출하되, 상기 테이블 명 OBJ$로부터 상기 스키마 정보 중 테이블 명, 오브젝트 ID, 및 테이블 생성 시간을 도출하며, 상기 테이블 명 C_OBJ#으로부터 상기 스키마 정보 중 테이블의 오브젝트 ID, 컬럼 명, 컬럼 자료형 타입, 및 크기정보를 도출하는 것을 특징으로 하는 데이터 복원 장치일 수 있다.

상기된 일 실시예에 따른 상기 테이블은 상기 스키마 정보에 포함된 플래그 값이 0x6C일 경우 정상적인 테이블이고, 상기 스키마 정보에 포함된 플래그 값이 0x7C일 경우 삭제된 테이블인 것을 특징으로 하는 데이터 복원 장치일 수 있다.

상기된 일 실시예에 따른 상기 레코드의 플래그 값이 0x2C일 경우 삭제되지 않은 정상적인 레코드이고, 상기 레코드의 플래그 값이 0x3C일 경우 삭제된 레코드인 것을 특징으로 하는 데이터 복원 장치일 수 있다.

상기된 다른 기술적 과제를 해결하기 위하여, 본 발명은 상기된 데이터 복원 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록 매체를 제공한다.

본 발명에 따르면, 시스템 테이블로부터 하나 이상의 테이블들에 대한 스키마 정보를 도출하여 삭제된 레코드를 포함하는 테이블을 선별하고, 선별된 테이블의 오브젝트 ID를 통해 데이터 블록에 접근하여 삭제된 레코드를 복구함으로써, 데이터베이스의 포렌식 조사를 진행함에 있어 트랜잭션 로그파일이 존재하지 않거나 트랜잭션 로그파일이 기록하지 않은 시점의 레코드들을 복구할 수 있는 효과가 있다.

도 1은 본 발명의 일 실시예들이 채택하고 있는 데이터 복원 방법을 도시한 흐름도이다.
도 2a는 본 발명의 일 실시예에 따른 OBJ$의 로우 데이터 영역 레코드를 도시한 도면이다.
도 2b는 본 발명의 일 실시예에 따른 데이터 저장 방식을 도시한 도면이다.
도 2c는 본 발명의 일 실시예에 따른 DATE 자료형 저장 방식을 도시한 도면이다.
도 2d는 본 발명의 일 실시예에 따른 OBJ$에서 획득한 레코드 정보를 도시한 도면이다.
도 3은 본 발명의 일 실시예에 따른 C_OBJ#의 클러스터를 도시한 도면이다.
도 4a는 본 발명의 일 실시예에 따른 테이블 삭제 시 OBJ$의 변화를 도시한 도면이다.
도 4b는 본 발명의 일 실시예에 따른 테이블 삭제 시 C_OBJ#의 변화를 도시한 도면이다.
도 5는 본 발명의 일 실시예에 따른 alert_데이터베이스명.log 파일을 도시한 도면이다.
도 6a는 본 발명의 일 실시예에 따른 데이터 블록 구조를 도시한 도면이다.
도 6b는 본 발명의 일 실시예에 따른 데이터 블록 헤더를 도시한 도면이다.
도 6c는 본 발명의 일 실시예에 따른 로우 디렉터리를 도시한 도면이다.
도 6d는 본 발명의 일 실시예에 따른 로우 디렉터리에서 레코드 데이터를 추적하는 과정을 도시한 도면이다.
도 7은 본 발명의 일 실시예에 따른 레코드 삭제 후 로우 데이터의 변화를 도시한 도면이다.
도 8은 본 발명의 일 실시예에 따른 OBJ$, C_OBJ#, 사용자테이블의 관계를 도시한 도면이다.
도 9는 본 발명의 일 실시예에 따른 데이터 복원 방법을 또 다른 흐름도로 도시한 도면이다.
도 10은 본 발명의 일 실시예에 따른 레코드 삽입 실험 결과를 도시한 도면이다.
도 11은 본 발명의 일 실시예들이 채택하고 있는 데이터 복원 장치를 도시한 블럭도이다.
도 12는 본 발명의 일 실시예에 따른 삭제된 레코드 복구 실험 결과를 도시한 도면이다.

본 발명의 실시예들을 설명하기에 앞서, 기존의 데이터 복원 방법에서 발생하는 문제점들을 검토한 후, 이들 문제점을 해결하기 위해 본 발명의 실시예들이 채택하고 있는 기술적 수단을 개괄적으로 소개하도록 한다.

데이터베이스에는 중요한 정보가 저장되어 있어 디지털 포렌식 관점에서 의미 있는 정보가 있을 확률이 높다. 데이터베이스에서 정상적인 레코드를 추출하는 것도 중요하지만 삭제된 레코드를 복구하는 것도 중요하다. 현재 데이터베이스 데이터 복원에 대한 연구는 트랜잭션 로그를 기반으로 복원한다. 하지만, 이 방법은 트랜잭션 로그가 존재하지 않거나 트랜잭션 로그가 기록한 이전시점의 데이터를 복원하고 싶은 경우에는 사용할 수 없다는 치명적인 단점이 존재한다.

따라서, 본 발명의 실시예들은 트랜잭션 로그의 비종속적으로 데이터베이스의 삭제된 레코드들을 복원할 수 있는 기술적 수단을 제안하고자 한다.

이하에서는 도면을 참조하여 본 발명의 실시예들을 구체적으로 설명하도록 한다. 다만, 하기의 설명 및 첨부된 도면에서 본 발명의 요지를 흐릴 수 있는 공지 기능 또는 구성에 대한 상세한 설명은 생략한다. 또한, 도면 전체에 걸쳐 동일한 구성 요소들은 가능한 한 동일한 도면 부호로 나타내고 있음에 유의하여야 한다.

도 1은 본 발명의 일 실시예들이 채택하고 있는 데이터 복원 방법을 도시한 흐름도로서, 데이터 복원 장치가 데이터베이스로부터 시스템 파일을 입력받고, 상기 시스템 파일에 포함된 시스템 테이블을 조회하여 상기 시스템 파일 내의 하나 이상의 테이블들에 대한 스키마 정보를 도출하고, 상기 스키마 정보에 기초하여 상기 하나 이상의 테이블들 중 삭제된 테이블을 선별하고, 상기 선별된 테이블의 오브젝트 ID를 통해 삭제된 레코드를 포함하는 데이터 블록을 검색하여 도출하며, 상기 도출된 데이터 블록에서 삭제된 레코드를 식별하여 추출함으로써, 삭제된 레코드를 복구한다.

보다 구체적으로, S110 단계에서 데이터 복원 장치가 데이터베이스로부터 시스템 파일을 입력받는다.

다시 말해, 오라클 데이터베이스에서 삭제된 레코드를 복구하기 위해서는 테이블스페이스 파일 구조에 대해서 알아야 한다. 오라클 테이블스페이스는 TEMP, USER, SYSAUX, SYSTEM, EXAMPLE, UNDOTBS가 있으며, 각 테이블스페이스의 역할은 이하의 표 1과 같다.

이 중에서 테이블과 레코드들을 저장하고 있는 테이블스페이스는 SYSTEM이며, 테이블 정보나 테이블 컬럼 정보, 환경 설정 등을 저장하고 있는 테이블스페이스 역시 SYSTEM이다.

S120 단계에서, 상기 데이터 복원 장치가 상기 시스템 파일에 포함된 시스템 테이블을 조회하여 상기 시스템 파일 내의 하나 이상의 테이블들에 대한 스키마 정보를 도출한다.

다시 말해, 상기 데이터 복원 장치가 상기 시스템 테이블에 포함된 테이블 명 OBJ$ 및 테이블 명 C_OBJ#를 검색하여 도출하고, 상기 도출된 테이블 명 OBJ$ 및 테이블 명 C_OBJ#의 플래그 값에 따른 상기 스키마 정보를 도출할 수 있다. 여기서, 상기 테이블 명 OBJ$로부터 상기 스키마 정보 중 테이블 명, 오브젝트 ID, 및 테이블 생성 시간을 도출하고, 상기 테이블 명 C_OBJ#으로부터 상기 스키마 정보 중 테이블의 오브젝트 ID, 컬럼 명, 컬럼 자료형 타입, 및 크기정보를 도출할 수 있다.

보다 구체적으로, 오라클 데이터베이스에는 테이블 정보나 테이블 컬럼 정보, 환경 설정 등은 상기 시스템 테이블인 SYSTEM.DBF파일에 저장될 수 있다. 각 시스템 테이블은 고유한 오브젝트 ID를 가지고 있다. 따라서, 시스템 테이블의 오브젝트 ID를 알고 있으면 테이블의 이름과 테이블의 컬럼 명 등 스키마 정보를 획득할 수 있다. 여기서, 상기 시스템 테이블 중 테이블 명 OBJ$와 테이블 명 C_OBJ#은 테이블의 스키마 정보를 획득할 수 있다. 상기 OBJ$에서는 테이블 명을 얻을 수 있으며, 상기 C_OBJ#에서는 테이블 컬럼 명과 데이터형, 데이터 길이정보를 얻을 수 있다. 그리고 상기 OBJ$와 C_OBJ#은 고유한 오브젝트 ID를 포함할 수 있다. 상기 오브젝트 ID는 이하의 표 2와 같을 수 있다.

상기 OBJ$ 테이블의 스키마 정보는 오라클 공식홈페이지에서 찾을 수 있으며, 상기 OBJ$ 테이블에서는 테이블 명, 오브젝트 ID, 테이블 생성 시간을 알 수 있다. 여기서, 상기 OBJ$ 테이블로부터 스키마 정보를 획득하는 과정은 이하에서 도 2a 내지 도 2d를 통해 보다 구체적으로 설명하도록 한다.

도 2a는 본 발명의 일 실시예에 따른 OBJ$의 로우 데이터 영역 레코드를 도시한 도면으로서, 로우 데이터 영역을 예시하여 도시한 도면이다.

보다 구체적으로, OBJ$ 테이블의 스키마 정보는 오라클 공식홈페이지에서 찾을 수 있다. 이 테이블에서는 테이블 명, 오브젝트 ID, 테이블 생성 시간을 알 수 있다. 다시 말해, 로우 데이터의 레코드 정보영역에서 맨 앞 3 바이트는 레코드 정보(21)를 나타낼 수 있다. 첫 바이트는 레코드의 상태 플래그이며, 세 번째 바이트는 컬럼의 개수를 뜻할 수 있다. 따라서, 도 2a는 세 번째 바이트는 0x11이므로 17개의 컬럼을 가지고 있음을 알 수 있다.

또한, 레코드 데이터영역(22)에서는 실제 레코드 데이터들이 저장되어 있다. 오라클에서 지원하는 자료형마다 저장하는 방식이 상이할 수 있다. 기본적인 구조는 도 2b와 같이 맨 첫 번째 바이트가 해당 컬럼의 길이 정보(23)를 뜻한다. 도 2b는 첫 번째 바이트가 0x07이므로 7Bytes의 데이터를 저장하고 있다는 것을 알 수 있다.

또한, 오라클 자료형 중 DATE 자료형은 날짜와 시간을 고정 길이로 표현하는데 사용하며, 7Bytes를 사용할 수 있다. 상기 DATE 자료형은 세기, 년, 월, 일, 시, 분, 초를 1Byte로 저장할 수 있으며 도 2c와 같을 수 있다. 또한, NUMBER 자료형은 가변 길이의 숫자 데이터를 저장하는데 사용하며, 1Byte에 2자리가 저장되는 100진수를 사용할 수 있다.

이와 같은 방법으로 도 2a의 레코드 데이터(22)sms 맨 앞의 레코드 길이 정보(23)를 가지고 컬럼 정보를 획득할 수 있는데, 획득한 정보를 정리하면 이하에서 도 2d와 같을 수 있다.

도 2d는 본 발명의 일 실시예에 따른 OBJ$에서 획득한 레코드 정보를 도시한 도면으로서, OBJ$ 테이블에서 한 레코드를 분석해 테이블 명이 DFRC라는 것과 테이블 생성시간, 오브젝트 ID를 알 수 있다.

한편, 상기 C_OBJ#는 시스템 클러스터일 수 있다. 여기서, 클러스터란 테이블에서 쓰이는 컬럼 정보들을 하나의 그룹으로 묶어 저장하는 오라클 데이터베이스 객체이다, 이 클러스터에는 테이블의 오브젝트 ID와, 컬럼 명, 컬럼 자료형 타입, 크기정보 등의 스키마 정보를 획득할 수 있다. 여기서, 상기 C_OBJ#은 이하에서 도 3을 통해 보다 구체적으로 설명하도록 한다.

도 3은 본 발명의 일 실시예에 따른 C_OBJ#의 클러스터를 도시한 도면이다.

보다 구체적으로, 도 3은 C_OBJ#에서 한 클러스터를 예시하여 도시한 도면으로서, 각 레코드 시작 부분(31)을 표시해 두었으며, 제일 하단의 블록 부분을 보면 오브젝트 ID(32)를 알 수 있다. 또한, 한 클러스터에 있는 레코드들의 앞 부분을 보면 4번째 바이트가 똑같은 것을 볼 수 있는데 이는 클러스터의 번호를 뜻한다.

상기 C_OBJ# 주요 컬럼은 이하에서 표 3과 같을 수 있다.

여기서, C_OBJ#의 6번째 컬럼은 자료형 타입을 뜻하며, 각 자료형의 고유한 값은 이하에서 표 4와 같을 수 있다.

이제 다시 도 1로 돌아가 S120 단계 이후를 설명하도록 한다.

S130 단계에서, 상기 데이터 복원 장치가 상기 스키마 정보에 기초하여 상기 하나 이상의 테이블들 중 삭제된 테이블을 선별할 수 있다, 다시 말해, 상기 테이블은 상기 스키마 정보에 포함된 플래그 값이 0x6C일 경우 정상적인 테이블이고, 상기 스키마 정보에 포함된 플래그 값이 0x7C일 경우 삭제된 테이블일 수 있다.

보다 구체적으로, 오라클 데이터베이스에서 테이블을 삭제할 경우 OBJ$ 테이블에서 도 4a와 같이 플래그 값이 테이블 삭제 전 0x2C(41)이고, 테이블 삭제 후 0x3C(42)인 것을 알 수 있다.

또한, C_OBJ# 클러스터에는 도 4b와 같이 테이블을 삭제할 경우 클러스터들의 플래그 값이 테이블 삭제 전 0x6C(43)에서 테이블 삭제 후 0x7C(44)로 변경된 것을 알 수 있다.

따라서, 스키마 정보에 포함된 플래그 값을 비교함으로써, 삭제된 레코드를 포함하는 테이블을 선별할 수 있다.

이제 다시 도 1로 돌아가 S130 단계 이후를 설명하도록 한다.

S140 단계에서, 상기 데이터 복원 장치가 상기 선별된 테이블의 오브젝트 ID를 통해 삭제된 레코드를 포함하는 데이터 블록을 검색하여 도출한다.

보다 구체적으로, S140 단계를 설명하기 전, 상기 데이터 블록에 대해 구체적으로 알아보도록 하자. 테이블스페이스는 상기 데이터 블록으로 구성되어 있으며, 상기 데이터 블록은 데이터베이스가 사용하는 가장 작은 저장 단위로써 데이터베이스 안에 있는 데이터를 읽거나 쓸 때 사용되는 조작 단위일 수 있다. 상기 데이터 블로그이 크기는 오라클을 설치할 때 설정할 수 있으며, 사용 중에는 변경할 수 없다. 그리고 해당 시스템에서 블록 사이즈를 확인할 수 있는데, 이는 데이터베이스 생성 로그를 통해 확인가능할 수 있다. 기본 경로는 오라클 데이터베이스가 설치된 곳에서 \admin\[데이터베이스명]\bdump\alert_데이터베이스명.log에서 확인할 수 있다. 도 5는 상기 alert_데이터베이스명.log를 도시한 도면으로서, db_block_size(51) 항목을 보면 데이터 블록 크기가 8192라는 것을 알 수 있다. 이하에서는 도 6a 내지 도 6d를 통해 상기 데이터 블록의 구조를 더욱 상세하게 설명하도록 한다.

도 6a는 본 발명의 일 실시예에 따른 데이터 블록 구조를 도시한 도면으로서, Common and Variable Header(61), Table Directory(62), Row Directory(63), Free Space(64), Row Data(65)로 구성된다. 여기서, 상기 데이터 블록에서 레코드가 증가할수록 Row Directory(63)와 Row Data(65)도 같이 증가하고, 도 6a의 화살표와 같이 Row Directory(63)는 데이터 블록 위에서부터 데이터를 저장하며, Row Data(65)는 데이터 블록 아래에서부터 데이터를 저장할 수 있다. 또한, 각 구성요소별로 획득할 수 있는 정보는 표 5와 같을 수 있다.

도 6b는 본 발명의 일 실시예에 따른 데이터 블록 헤더를 도시한 도면으로서, common and Variable Header(61)와 Table Directory(62)의 화면이다. 여기서, common and Variable Header(61)의 크기는 20 바이트이며 오라클 버전 정보를 알 수 있다.

Table Directory(62)에서는 해당 데이터 블록의 타입(66)을 알 수 있는데 0x01이면 DATA, 0x02이면 INDEX를 저장하고 있다는 것을 알 수 있다. 또한, 오브젝트 ID(67)를 알 수 있는데 이는 오라클 테이블스페이스에서 객체마다 부여하는 것으로 테이블을 식별할 수 있다. 도 6b의 테이블은 0xCD5B의 값을 가지므로 오브젝트 ID가 52571이라는 것을 알 수 있다.

도 6c는 본 발명의 일 실시예에 따른 로우 디렉터리를 도시한 도면으로서, 로우 디렉터리(63)에서는 해당 테이블이 가지고 있는 Free Space 시작 오프셋(68), Free Space 마지막 오프셋(69), Free Space 사용 가능 크기(70), 레코드의 오프셋 정보(71), 및 테이블이 가지고 있는 레코드 개수(72)를 얻을 수 있다. 다시 말해, 로우 디렉터리(63)에는 레코드 데이터 오프셋 정보가 있으며, 이는 로우 디렉터리(63) 시작 오프셋으로부터의 거리일 수 있다. 도 6c에서는 로우 디렉터리(63) 시작 오프셋은 0x1DC5405C가 되고, 첫 번째 값은 0x1F77이며, 이 둘을 더하게 되면 0xDC55FD3이므로, 이는 첫 번째 레코드의 시작 위치일 수 있다.

이와 같은 계산법으로 각 레코드의 위치를 계산할 수 있으며, 도 6d는 로우 디렉터리에서 세 개의 레코드의 위치를 추적하는 것을 예시한 도면이다.

따라서, S140 단계에서는 S130 단계에서 선별된 테이블의 오브젝트 ID를 도 6a 내지 도 6d를 통해 확인할 수 있는 각각의 데이터 블록의 오브젝트 ID와 비교함으로써, 상기 선별된 테이블의 오브젝트 ID와 동일한 데이터 블록을 검색하여 도출할 수 있다.

이제 다시 도 1로 돌아가 S140 단계 이후를 설명하도록 한다.

S150 단계에서, 상기 데이터 복원 장치가 상기 도출된 데이터 블록에서 삭제된 레코드를 식별하여 추출함으로써, 삭제된 레코드를 복구한다. 여기서, 상기 레코드의 플래그 값이 0x2C일 경우 삭제되지 않은 정상적인 레코드이고, 상기 레코드의 플래그 값이 0x3C일 경우 삭제된 레코드일 수 있다.

보다 구체적으로, 오라클 데이터베이스에서 레코드를 삭제할 경우 OBJ$ 테이블과 C_OBJ#에는 변화가 없으며, 해당 레코드를 저장하고 있는 데이터 블록에만 변화가 생긴다.

도 7은 본 발명의 일 실시예에 따른 레코드 삭제 후 로우 데이터의 변화를 도시한 도면으로서, 레코드 정보를 나타내는 부분이 레코드 삭제 전 0x2C(75)에서 삭제 후 0x3C(76)로 바뀐 것을 알 수 있다.

따라서, 상기 데이터 블록에서 도 7의 로우 데이터에서 레코드 정보를 나타내는 부분의 변화 여부를 확인하여 0x3C(75)로 변경된 레코드를 삭제된 레코드로 식별함으로써, 해당 레코드 부분을 추출하여 삭제된 레코드를 복구할 수 있다.

한편, 앞서 언급한 OBJ$ 테이블, C_OBJ# 클러스터, 및 테이블에는 모두 오브젝트 ID가 들어 있으며, 상기 오브젝트 ID를 통해 테이블 스키마 정보와 테이블 레코드를 얻을 수 있음을 설명하였다. 이들의 관계도는 이하에서 도 8과 같을 수 있다.

도 8은 본 발명의 일 실시예에 따른 OBJ$, C_OBJ#, 사용자테이블의 관계를 도시한 도면이다. 즉, OBJ$(81)를 통해 오라클 테이블스페이스 내의 모든 테이블에 대한 오브젝트 ID를 수집하고, 이 수집된 오브젝트 ID를 통해 C_OBJ# 클러스터(82)에서 컬럼 명을 수집하며, 이 과정을 통해 정상적인 테이블의 스키마 정보와 삭제된 테이블(83)의 스키마 정보를 알 수 있다.

또한, 도 9는 본 발명의 일 실시예에 따른 데이터 복원 방법을 또 다른 흐름도로 도시한 도면이다.

보다 구체적으로, S810 단계에서 삭제된 레코드를 복구하기 위해서는 먼저 테이블스페이스의 블록크기를 알아야 한다. 블록크기는 설치 로그파일에서 찾을 수 있다. 만약 로그파일이 없다면 해당 테이블스페이스에서 오라클 버전을 나타내는 오라클 타입을 보고 블록 크기를 찾아야 한다.

S820 단계에서, OBJ$ 테이블을 파싱한다. 이 과정에서 테이블 명과 오브젝트 ID를 알 수 있다. 이때 플래그 값이 0x2C일 경우 정상적인 테이블이며 0x3C일 경우 삭제된 테이블을 뜻한다.

S830 단계에서, C_OBJ# 클러스터를 파싱한다. 이 과정에서 테이블의 오브젝트 ID와 스키마 정보들을 알 수 있다. 이때, 플래그 값이 0x6C일 경우 정상적인 테이블의 스키마 정보이며 0x7C일 경우 삭제된 테이블의 스키마 정보이다.

S840 단계에서, S830 단계에서 획득한 스키마 정보에 기초하여 테이블 스키마를 정상테이블과 삭제테이블로 분류한다.

S850 단계에서, 획득한 스키마 정보를 바탕으로 오브젝트 ID를 비교하면서 블록들을 탐색을 시작한다.

S860 단계에서, 데이터 블록을 이동하며 순차적으로 탐색한다.

S870 단계에서, 현재 탐색중인 데이터 블록이 찾고자 하는 오브젝트 ID와 비교하여 일치할 경우 S880 단계로 진행되며, 불일치할 경우 S890단계로 진행된다.

S880 단계에서, 찾고자 하는 오브젝트 ID와 비교하여 일치할 경우 플래그 값이 0x3C인 레코드를 삭제된 레코드로 식별하여 해당 레코드를 추출한다.

S890 단계에서, 현재 탐색중인 데이터 블록이 파일의 끝일 경우 종료하며, 파일의 끝이 아닐 경우 S860 단계 내지 S890 단계를 반복한다.

한편, 한 테이블에서 레코드를 삭제했을 때 데이터 블록에는 레코드가 삭제된 영역이 생긴다. 예를 들어, 도 10과 같이 INSERT 쿼리문을 통해 새로운 레코드를 저장할 경우 삭제된 레코드 영역(102)에 저장되는 것이 아니라 Free Space 영역(101)에 저장되는 것을 알 수 있다. 이를 통해 본 발명이 제안하는 데이터 복원 방법은 레코드 삭제 후 새로운 레코드를 저장하여도 삭제된 레코드 복원이 가능한 것을 알 수 있다.

또한, 앞서 도 4a 및 도 4b를 통해 확인한 것과 같이 테이블을 삭제할 시 OBJ$와 C_OBJ#에서 삭제한 테이블 명과 스키마 정보를 할 수 있었으며, 데이터 블록이 덮어써져 있지 않으면 복구가 가능한 것을 알 수 있다.

도 11은 본 발명의 일 실시예들이 채택하고 있는 데이터 복원 장치를 도시한 블럭도로서, 데이터 복원 장치(111)는 앞서 기술한 도 1의 각 과정에 대응하는 구성을 포함한다. 따라서, 여기서는 설명의 중복을 피하기 위해 시스템의 세부구성을 중심으로 그 기능을 약술하도록 한다.

입력부(112)는 데이터베이스로부터 시스템 파일을 입력받는다.

처리부(113)는 상기 시스템 파일에 포함된 시스템 테이블을 조회하여 상기 시스템 파일 내의 하나 이상의 테이블들에 대한 스키마 정보를 도출하고, 상기 스키마 정보에 기초하여 상기 하나 이상의 테이블들 중 삭제된 테이블을 선별하며, 상기 선별된 테이블의 오브젝트 ID를 통해 삭제된 레코드를 포함하는 데이터 블록을 검색하여 도출한다.

추출부(114) 상기 도출된 데이터 블록에서 삭제된 레코드를 식별하여 추출함으로써, 삭제된 레코드를 복구한다.

또한, 처리부(113)는 상기 시스템 테이블에 포함된 테이블 명 OBJ$ 및 테이블 명 C_OBJ#를 검색하여 도출하고, 상기 데이터 복원 시스템이 상기 도출된 테이블 명 OBJ$ 및 테이블 명 C_OBJ#의 플래그 값에 따른 상기 스키마 정보를 도출하되, 상기 테이블 명 OBJ$로부터 상기 스키마 정보 중 테이블 명, 오브젝트 ID, 및 테이블 생성 시간을 도출하며, 상기 테이블 명 C_OBJ#으로부터 상기 스키마 정보 중 테이블의 오브젝트 ID, 컬럼 명, 컬럼 자료형 타입, 및 크기정보를 도출한다.

또한, 상기 테이블은 상기 스키마 정보에 포함된 플래그 값이 0x6C일 경우 정상적인 테이블이고, 상기 스키마 정보에 포함된 플래그 값이 0x7C일 경우 삭제된 테이블이다.

또한, 상기 레코드의 플래그 값이 0x2C일 경우 삭제되지 않은 정상적인 레코드이고, 상기 레코드의 플래그 값이 0x3C일 경우 삭제된 레코드이다.

도 12는 본 발명의 일 실시예에 따른 삭제된 레코드 복구 실험 결과를 도시한 도면으로서, 오라클 버전 중 9i, 10g, 11g를 대상으로 하였으며, Windows 환경에서 실험하였다.

보다 구체적으로, 본 발명이 제안하는 데이터 복원 방법을 토대로 삭제된 레코드를 복구하는 도구를 구현하였다. OBJ$를 통해 Oracle 테이블스페이스 내의 모든 테이블에 대한 오브젝트 ID를 수집하고 이 수집된 오브젝트 ID를 통해 C_OBJ# 클러스터에서 컬럼 명을 수집한다. 이 과정을 통해 정상적인 테이블의 스키마 정보와 삭제된 테이블의 스키마 정보를 알 수 있다. 그 다음 수집된 오브젝트 ID를 가지고 있는 블록에서 삭제된 레코드를 복구한다. 테이블의 스키마 정보(121)와 테이블의 삭제된 레코드 정보(122)는 CSV 파일로 저장하며 각각 다른 파일에 저장된다.

실험결과, 삭제된 테이블의 스키마 정보는 모두 복원할 수 있었지만 레코드들은 데이터 블록이 덮어써지지 않은 경우에만 레코드들을 복원할 수 있었다.

상기된 본 발명에 따르면, 전 세계적으로 많이 쓰이고 있는 Oracle 데이터베이스를 대상으로 테이블스페이스에서 OBJ$와 C_OBJ$를 통해 삭제된 테이블과 삭제된 레코드들을 복구하는 기법을 제안하였다. 또한, 실험을 통해 삭제된 테이블과 삭제된 레코드가 정상적으로 복구되는 것을 확인하였다. 이에 따라 데이터베이스의 포렌식 조사를 진행함에 있어 트랜잭션 로그파일이 존재하지 않거나 트랜잭션 로그파일이 기록하지 않은 시점의 레코드들을 복구할 경우 본 발명에서 제안한 방법이 의미 있는 정보를 추출하는데 많은 도움이 될 것이다.

한편, 본 발명은 실시예들은 컴퓨터로 읽을 수 있는 기록 매체에 컴퓨터가 읽을 수 있는 코드로 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록 매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록 장치를 포함한다.

컴퓨터가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한 캐리어 웨이브(예를 들어 인터넷을 통한 전송)의 형태로 구현하는 것을 포함한다. 또한, 컴퓨터가 읽을 수 있는 기록 매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산 방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다. 그리고 본 발명을 구현하기 위한 기능적인(functional) 프로그램, 코드 및 코드 세그먼트들은 본 발명이 속하는 기술 분야의 프로그래머들에 의하여 용이하게 추론될 수 있다.

이상에서 본 발명에 대하여 그 다양한 실시예들을 중심으로 살펴보았다. 본 발명에 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.

111 : 데이터 복원 장치
112 : 입력부
113 : 처리부
114 : 추출부

Claims (13)

1. 데이터 복원 장치가 데이터베이스로부터 시스템 파일을 입력받는 단계;
   상기 데이터 복원 장치가 상기 시스템 파일에 포함된 시스템 테이블을 조회하여 상기 시스템 파일 내의 하나 이상의 테이블들에 대한 스키마 정보를 도출하는 단계;
   상기 데이터 복원 장치가 상기 스키마 정보에 기초하여 상기 하나 이상의 테이블들 중 삭제된 테이블을 선별하는 단계;
   상기 데이터 복원 장치가 상기 선별된 테이블의 오브젝트 ID를 통해 삭제된 레코드를 포함하는 데이터 블록을 검색하여 도출하는 단계; 및
   상기 데이터 복원 장치가 상기 도출된 데이터 블록에서 삭제된 레코드를 식별하여 추출함으로써, 삭제된 레코드를 복구하는 단계를 포함하되,
   상기 스키마 정보를 도출하는 단계는,
   상기 데이터 복원 장치가 상기 시스템 테이블에 포함된 테이블 명 OBJ$ 및 테이블 명 C_OBJ#를 검색하여 도출하고, 상기 도출된 테이블 명 OBJ$ 및 테이블 명 C_OBJ#의 플래그 값을 포함하는 레코드 정보에 따른 상기 스키마 정보를 도출하는 단계를 포함하는 것을 특징으로 하는 데이터 복원 방법.
2. 제 1 항에 있어서,
   상기 데이터베이스는 오라클(oracle) 데이터베이스인 것을 특징으로 하는 데이터 복원 방법.
3. 삭제
4. 제 1 항에 있어서,
   상기 테이블 명 OBJ$로부터 상기 스키마 정보 중 테이블 명, 오브젝트 ID, 및 테이블 생성 시간을 도출하는 것을 특징으로 하는 데이터 복원 방법.
5. 제 1 항에 있어서,
   상기 테이블 명 C_OBJ#으로부터 상기 스키마 정보 중 테이블의 오브젝트 ID, 컬럼 명, 컬럼 자료형 타입, 및 크기정보를 도출하는 것을 특징으로 하는 데이터 복원 방법.
6. 제 1 항에 있어서,
   상기 테이블은 상기 스키마 정보에 포함된 플래그 값이 0x6C일 경우 정상적인 테이블이고, 상기 스키마 정보에 포함된 플래그 값이 0x7C일 경우 삭제된 테이블인 것을 특징으로 하는 데이터 복원 방법.
7. 제 1 항에 있어서,
   상기 레코드의 플래그 값이 0x2C일 경우 삭제되지 않은 정상적인 레코드이고, 상기 레코드의 플래그 값이 0x3C일 경우 삭제된 레코드인 것을 특징으로 하는 데이터 복원 방법.
8. 제 1 항 내지 제 2 항과 제 4 항 내지 제 7 항 중에 어느 한 항의 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체.
9. 데이터베이스로부터 시스템 파일을 입력받는 입력부;
   상기 시스템 파일에 포함된 시스템 테이블을 조회하여 상기 시스템 파일 내의 하나 이상의 테이블들에 대한 스키마 정보를 도출하고, 상기 스키마 정보에 기초하여 상기 하나 이상의 테이블들 중 삭제된 레코드를 포함하는 테이블을 선별하며, 상기 선별된 테이블의 오브젝트 ID를 통해 삭제된 레코드를 포함하는 데이터 블록을 검색하여 도출하는 처리부; 및
   상기 도출된 데이터 블록에서 삭제된 레코드를 식별하여 추출함으로써, 삭제된 레코드를 복구하는 추출부를 포함하되,
   상기 처리부는,
   상기 시스템 테이블에 포함된 테이블 명 OBJ$ 및 테이블 명 C_OBJ#를 검색하여 도출하고, 상기 도출된 테이블 명 OBJ$ 및 테이블 명 C_OBJ#의 플래그 값을 포함하는 레코드 정보에 따른 상기 스키마 정보를 도출하는 것을 특징으로 하는 데이터 복원 장치.
10. 제 9 항에 있어서,
    상기 데이터베이스는 오라클 데이터베이스인 것을 특징으로 하는 데이터 복원 장치.
11. 제 9 항에 있어서,
    상기 처리부는,
    상기 테이블 명 OBJ$로부터 상기 스키마 정보 중 테이블 명, 오브젝트 ID, 및 테이블 생성 시간을 도출하며, 상기 테이블 명 C_OBJ#으로부터 상기 스키마 정보 중 테이블의 오브젝트 ID, 컬럼 명, 컬럼 자료형 타입, 및 크기정보를 도출하는 것을 특징으로 하는 데이터 복원 장치.
12. 제 9 항에 있어서,
    상기 테이블은 상기 스키마 정보에 포함된 플래그 값이 0x6C일 경우 정상적인 테이블이고, 상기 스키마 정보에 포함된 플래그 값이 0x7C일 경우 삭제된 테이블인 것을 특징으로 하는 데이터 복원 장치.
13. 제 9 항에 있어서,
    상기 레코드의 플래그 값이 0x2C일 경우 삭제되지 않은 정상적인 레코드이고, 상기 레코드의 플래그 값이 0x3C일 경우 삭제된 레코드인 것을 특징으로 하는 데이터 복원 장치.
    
    
    

Images