일반적으로 mdf파일이 정상적으로 분리됐을때의 DB복구방법은

-EM(Enterprise Manager)를 이용한 데이터베이스 연결

1. 우선 연결할 대상이 되는 *.mdf, *.ldf 파일을 특정한 디렉토리에 위치를 시킵니다. 예로 test.mdf, test_log.ldf 파일을 E:\Data 폴더에 있다고 가정합니다.

2. "데이터베이스" 위에서 마우스 오른쪽 버튼을 눌러 단축메뉴를 표시하면 [모든작업(K)] - [ 데이터베이스 연결(A)]을 선택할 수 있습니다.

3. 데이터베이스 연결을 위한 대화창이 표시됩니다.

4. 찾기 버튼 [...] 을 누르면 연결할 데이터베이스 파일의 위치를 쉽게 찾을 수 있는 탐색창이 뜹니다. 이 화면에서 연결하고자 하는 데이터베이스 파일 *.mdf 을 선택하면 됩니다.

5. 데이터베이스 파일을 선택한 후의 화면입니다. 원하는 경우 "다음 이름으로 연결(A)" 부분에 다른 이름을 주어 기존의 데이터베이스와는 다른 이름을 갖는 데이터베이스로 연결을 할 수 있습니다.

6. [확인] 버튼을 누르면 데이터베이스 연결이 완료됩니다.


-sp_attach_db 또는 sp_attach_single_file_db 시스템 저장프로시져를 이용한 데이터베이스 연결

USE master
GO
EXEC sp_attach_db 'test', 'E:\Data\test.mdf', 'E:\Data\test_log.ldf'

또는 MDF파일만 있을때

EXEC sp_attach_single_file_db @dbname = 'test',
@physname = 'E:\Data\test.mdf'

등의 방법을 사용합니다.

하지만 정상적으로 분리되지않은 MDF파일은 복구시에 자신이 가지고있던 LDF파일만을 찾습니다.

위의 정상적인방법으론 계속되는 에러뿐입니다.

MDF파일을 복구하기위한 방법은

1.MDF파일의 DB명으로 빈 디비생성
2.DB정지후 생성한디비의 MDF파일과 가지고있는 MDF파일 교체
3.DB시작을 하면 suspect모드로 빠짐
이후부터는 suspect모드에서의 복구문서 참조->http://ntadmin.inet.co.kr/managed/dbsuspect.mht

이렇게 복구가 된다해도 DB의 자료는 거의 복구가되지만 여러 키값, 인덱스까지 제대로 잡히진 않습니다.
DB관리시 철저히 준비를 하여야 하며 제대로된 백업 및 복구방법을 사용하여야 할것입니다.

1. 쿼리분석기에서 backup log db_name with no_log 로 사용할 수 있는 로그 공간을 확보합니다.

2. 엔터프라이즈 관리자 - 보기 - 작업창으로 해당 데이터베이스의 트랜잭션 로그 공간의 사용중인 공간을 확인합니
다.

3. 아래 예제를 참고하여 dbcc shrinkfile 명령을 이용하여 사용중인 공간보다 조금 크게
ldf 파일의 크기를 줄입니다.

다음은 UserDB 사용자 데이터베이스에서 DataFil1이라는 파일의 크기를 7MB로
줄이는 예제 입니다.
USE UserDB
GO
DBCC SHRINKFILE (로그 파일의 논리적 이름, 7)
GO

로그 파일의 논리적 이름은 sp_helpfile 명령으로 확인하실 수 있습니다.
<예제>
use db_name
go
sp_helpfile

SQL Server의 보안을 개선하기 위해 수행할 수 있는 조치사항

1. 가장 최신의 서비스 팩을 설치합니다.
서버 보안 개선을 위한 가장 효과적인 조치는 SQL Server 2000 서비스 팩 3(SP3)로 업그레이드하는 것입니다. SP3는 SQL Server 2000 SP3 페이지에서 다운로드할 수 있습니다.
또한 공개되는 모든 보안 패치를 설치해야 합니다.
2. Microsoft Baseline Security Analyzer(MBSA)로 서버의 보안을 평가합니다.
MBSA는 SQL Server 및 Microsoft SQL Server 2000 Desktop Engine(MSDE 2000)을 비롯한 여러 Microsoft 제품에서 자주 볼 수 있는 보안상 취약한 구성을 검사해 주는 도구입니다. 이 도구는 로컬 또는 네트워크에서 실행할 수 있습니다. 이 도구는 SQL Server 시스템에 다음과 같은 문제가 없는지 테스트합니다.
§ 지나치게 많은 sysadmin 구성원이 서버 역할을 수정한 경우
§ sysadmin 이외의 역할에 CmdExec 작업 작성 권한이 부여된 경우
§ 암호가 비어 있거나 지나치게 평범한 경우
§ 인증 모드가 허술한 경우
§ 관리자 그룹에 너무 많은 권한이 부여된 경우.
§ SQL Server 데이터 디렉터리의 액세스 제어 목록(ACLs)이 정확하지 않은 경우
§ 설정 파일에 일반 텍스트 암호 sa가 있는 경우
§ guest 계정에 너무 많은 권한이 부여된 경우
§ 도메인 컨트롤러 역할도 하는 시스템에 SQL Server가 실행되는 경우
§ Everyone 그룹의 구성이 잘못되어 특정 레지스트리 키에 대한 액세스가 허용되는 경우
§ SQL Server 서비스 계정 구성이 잘못된 경우
§ 서비스 팩 및 보안 업데이트가 없는 경우
3. Windows 인증 모드를 사용합니다.
되도록이면 항상 SQL Server 연결에 Windows 인증 모드를 요구해야 합니다. 이 조치는 Microsoft Windows 사용자 및 도메인 사용자 계정으로 연결을 제한하여 SQL Server 시스템을 대부분의 인터넷 기반 공격으로부터 보호해 줍니다. 또한 서버는 인증 프로토콜 강화와 복잡한 암호 사용 및 정기적 갱신 강제 등과 같은 Windows 보안 강화 메커니즘 등의 이익도 얻게 됩니다. 또한 자격 증명 위임(여러 서버에 자격 증명을 연결하는 기능)은 Windows 인증 모드에서만 사용할 수 있습니다. 클라이언트 측의 경우 Windows 인증 모드를 사용하면 암호를 저장할 필요가 없습니다. 암호를 저장하는 것은 표준 SQL Server 로그인 방식을 사용하는 응용 프로그램의 주된 취약점입니다.
SQL Server의 Enterprise Manager로 Windows 인증 모드 보안을 설정하려면
1. 서버 그룹을 확장합니다.
2. 서버를 오른쪽 단추로 클릭하고 속성을 클릭합니다.
3. 보안 탭의 인증에서 Windows만을 클릭합니다.

4. 정기적으로 서버를 분리해서 백업합니다.
물리적 및 논리적 분리는 SQL Server 보안의 토대를 형성합니다. 데이터베이스를 호스팅하는 시스템은 물리적 보호 장치가 있는 곳에 있어야 하며 화재 감지 및 화재 감지/억제 모니터 기능과 함께 잠금 장치가 있는 시스템실이 가장 이상적입니다. 데이터베이스는 회사 인트라넷의 안전 구역에 설치되어야 하며 인터넷에 직접 연결되면 안 됩니다. 모든 데이터를 정기적으로 백업하고 복사본을 안전한 오프 사이트 장소에 보관하십시오.

5. 까다로운 sa 암호를 지정합니다.
Windows 인증을 요구하도록 구성된 서버에서도 sa 계정은 항상 까다로운 암호를 사용해야 합니다. 그러면 그 서버가 나중에 혼합 모드 인증으로 구성되는 경우에 빈 암호 또는 허술한 sa 암호가 노출될 염려가 없기 때문입니다.
sa 암호를 지정하려면
1. 서버 그룹을 확장하고 서버를 확장합니다.
2. 보안을 확장하고 로그인을 클릭합니다.
3. 상세 내용 창에서 SA를 오른쪽 단추로 클릭하고 속성을 클릭합니다.
4. 암호 입력란에 새 암호를 입력합니다.

6. SQL 서버 서비스의 권한 수준을 제한합니다.
SQL Server 2000 및 SQL Server Agent는 Windows 서비스로 실행됩니다. 각 서비스는 Windows 계정에 연결되어 그로부터 그 보안 컨텍스트를 도출해야 합니다. SQL Server에서는 sa 암호로 로그인하는 사용자, 그리고 일부 경우 다른 사용자들에게 운영 체제 기능 액세스를 허용합니다. 이 운영 체제 호출은 서버 프로세스를 소유하는 계정의 보안 컨텍스트에 따라 이루어집니다. 서버가 공격 당하면 이 운영 체제 호출은 소유 프로세스(SQL Server 서비스 계정)가 액세스를 갖고 있는 다른 자원으로 공격을 확대하는 데 사용될 수 있습니다. 따라서 SQL Server 서비스에는 필요한 권한만을 부여하는 것이 중요합니다.
권장 설정은 다음과 같습니다.
§ SQL Server Engine/MSSQLServer
인스턴스에 이름이 있는 경우, 그 이름은 'MSSQL$인스턴스이름'으로 지정됩니다. 정식 사용자 권한이 있는 Windows 도메인 사용자 계정으로 실행합니다. 로컬 시스템, 로컬 관리자 또는 도메인 관리자 계정으로 실행하지 마십시오.
§ SQL Server Agent Service/SQLServerAgent
자기 환경에 필요하지 않으면 사용하지 마십시오. 그렇지 않으면 정식 사용자 권한이 있는 Windows 도메인 사용자 계정으로 실행하십시오. 로컬 시스템, 로컬 관리자 또는 도메인 관리자 계정으로 실행하지 마십시오.
중요: 아래와 같은 조건에서는 SQL Server Agent에 로컬 Windows 관리자 권한이 필요할 것입니다.
§ SQL Server Agent가 SQL Server에 표준 SQL Server 인증을 사용하여 연결하는 경우(권장하지 않음)
§ SQL Server Agent가 표준 SQL Server 인증을 사용하여 연결하는 다중 서버 관리 마스터 서버(MSX) 계정을 사용하는 경우
§ SQL Server Agent가 sysadmin 고정 서버 역할의 구성원이 아닌 사용자가 소유한 Microsoft ActiveX 스크립트 또는 CmdExec 작업을 실행하는 경우
SQL Server 서비스와 연결된 계정을 변경해야 하는 경우에는 SQL Server Enterprise Manager를 사용하십시오. Enterprise Manager는 SQL Server가 사용하는 파일 및 레지스트리 키에 적절한 권한을 설정할 것입니다. 이 계정을 변경하기 위해 제어판에 있는 Microsoft 관리 콘솔의 서비스 애플릿을 사용하지 마십시오. 이를 위해서는 수십 개의 레지스트리와 NTFS 파일 시스템 권한 및 Microsoft Windows 사용자 권한을 수작업으로 조정해야 하기 때문입니다.
계정 정보에 대한 변경 사항은 다음에 서비스를 시작했을 때 적용됩니다. SQL Server 및 SQL Server Agent에 연결된 계정을 변경하려면 Enterprise Manager를 사용하여 그 변경 사항을 두 서비스에 개별적으로 적용해야 합니다

7. 방화벽에서 SQL Server 포트를 사용하지 않도록 하십시오.
SQL Server를 기본 설정으로 설치했다면 TCP 포트 1433 및 UDP 포트 1434를 모니터합니다. 이 포트로 향하는 패킷을 걸러내도록 방화벽을 구성하십시오. 이름이 지정된 인스턴스와 연결된 추가 포트들 역시 방화벽에서 차단되어야 합니다.

8. 가장 안전한 파일 시스템을 사용합니다.
NTFS는 SQL Server 설치에서 선호하는 파일 시스템입니다. 이 파일 시스템은 FAT 파일 시스템보다 안정적이고 복구 기능이 좋으며 파일 및 디렉터리 ACL과 및 파일 암호화(EFS) 등과 같은 보안 옵션을 사용할 수 있습니다. 설치 과정에서 NTFS를 감지하면 SQL Server는 레지스트리 키와 파일에 적절한 ACL을 설정합니다. 이 권한은 변경되지 않아야 합니다.
EFS에서는 SQL Server를 실행하는 계정의 ID 아래에 데이터베이스 파일이 암호화됩니다. 이 계정만이 파일의 암호를 풀 수 있습니다. SQL Server를 실행하는 계정을 변경하려면 먼저 기존 계정을 파일의 암호를 풀고 새 계정으로 파일을 다시 암호화해야 합니다.

9. 오래된 설정 파일을 삭제하거나 보안합니다.
SQL Server 설정 파일에는 일반 텍스트 또는 허술하게 암호화된 자격 증명 및 설치 중에 기록된 기타 민감한 구성 정보가 있습니다. 설치된 SQL Server의 버전에 따라 로그 파일의 위치가 다릅니다. SQL Server 2000에서 영향 받는 파일은 다음과 같습니다. 기본 설치의 경우 <시스템드라이브>:\Program Files\Microsoft SQL Server\MSSQL\Install 폴더, 그리고 명명된 인스턴스의 경우 <시스템드라이브>:\Program Files\Microsoft SQL Server\ MSSQL$<인스턴스이름>\Install 폴더에 있는 sqlstp.log, sqlsp.log 및 setup.iss 파일.
현재 시스템이 SQL Server 버전 7.0에서 업그레이드된 경우에는 다음 파일들도 확인해야 합니다: %Windir% 폴더의 setup.iss, Windows Temp 폴더의 sqlsp.log
Microsoft는 이 암호들을 시스템에서 찾아 제거해주는 Killpwd라는 무료 유틸리티를 배포하고 있습니다. 무료로 다운로드할 수 있는 이 유틸리티에 대한 자세한 내용은 서비스 팩 설치 과정에서 표준 보안 암호가 파일에 저장될 수 있습니다라는 제목의 Microsoft 기술 자료 문서를 참조하십시오.

10. SQL Server 연결에 대한 감사를 수행합니다.
SQL Server는 시스템 관리자의 검토를 위해 이벤트 정보를 기록할 수 있습니다. 최소한 SQL Server에 대한 연결 실패를 기록하여 이를 정기적으로 검토해야 합니다. 가능하면 이 로그는 데이터 파일이 저장되는 드라이브와 다른 하드 드라이브에 저장하십시오.
SQL Server의 Enterprise Manager로 연결 실패를 감사하려면
1. 서버 그룹을 확장합니다.
2. 서버를 오른쪽 단추로 클릭하고 속성을 클릭합니다.
3. 보안 탭의 감사 수준에서 실패를 클릭합니다.
이 설정이 적용되려면 서버를 종료했다가 다시 시작해야 합니다.