Challenge Everything

백업 유형

전체 백업(FULL BACKUP)
전체 백업은 기본적으로 데이터베이스에 있는 모든 페이지들을 백업 장치로 복사한다.
SQL Server가 사용중일 때에도 전체 백업을 수행할 수 있다. 이것을 퍼지(fuzzy) 백업이라고 생각 할 수 있다.
특정 시점에 백업 데이터는 데이터베이스 상태의 정확한 이미지가 아니다. 백업 스레드는 익스텐트들을 복사하기만 하고, 백업이 진행중일 때 다른 프로세스들이 이 익스텐트들을 변경할 필요가 있으면 이것들을 변경할 수 있다.
SQL Server는 전체 백업이나 차등 백업에서 일관성을 유지하기 위해, 백업이 시작할 때 현재 로그 시퀀스 번호(LSN)를 기록하고 백업이 종료될 때 다시 기록한다. 이 방법을 사용하면 백업이 로그의 관련된 부분들을 잡아낼 수 있다. 관련 부분은 첫번째 기록된 LSN시에 가장 오랜된 열린 트랜잭션에서 시작하고, 두번째 기록된 LSN에서 끝난다.


참고 퍼지백업에 대해
Microsoft?? SQL Server™ 2000 및 SQL Server 버전 7.0은 산업 표준 퍼지 백업 알고리즘을 사용한다. 이 알고리즘은 다음과 같은 이점이 있다.

1. BACKUP 문이 더 빨리 실행되며 이 문이 처리되는 동안 수행되는 데이터 수정에 덜 영향을 준다.
2. RESTORE 문이 더 빨리 수행된다.

SQL Server 퍼지 백업 및 복원 작업은 다음과 같다.

1. 데이터가 들어 있는 익스텐트가 백업 시 수정하는 페이지의 동기화와 상관 없이 백업 세트에 기록된다.
따라서 백업 시 현재 사용자에게 미치는 영향이 상당히 줄어든다. 또한 백업 시 페이지를 순차적으로 복사할 수 있다. 임의 읽기를 제거하여, 많이 사용되는 시스템의 백업 처리 속도가 빠르다. 그러나 백업 시 페이지는 일관성이 없고 복구할 수 없는 상태로 저장된다.
2. 트랜잭션 로그는 백업의 일부로 복사된다.

RESTORE 문은 다음을 수행한다.

1. 데이터베이스를 새로 만들고 데이터베이스의 익스텐트를 초기화한다. RESTORE 문이 실행될 때 데이터베이스가 존재하면 이 단계를 수행하지 않는다.
2. 백업 세트에 있는 익스텐트에 복사한다. 모든 익스텐트가 나란히 있기 때문에 이 처리가 빨리 수행된다. 백업 세트에 없는 익스텐트는 무시되며 빈 익스텐트로 초기화되지 않는다.
3. 트랜잭션 로그를 사용하여 데이터베이스를 복구한다. 로그에 기록된 데이터베이스 수정 내용을 로그 끝까지 롤포워드한 다음 완료되지 않은 트랜잭션을 롤백한다. 그러면 BACKUP 문이 완료된 때의 일관성 있고 복구 가능한 데이터베이스 상태로 데이터베이스가 복원된다.


차등 백업(DIFFERENTIAL BACKUP)
차등 백업은 마지막 전체 백업 이후에 변경된 익스텐트들만을 복사한다. 익스텐트들은 지정된 백업 장치로 복사된다. SQL Server는 데이터베이스에 있는 각 데이터 파일들에 대해 DCM 페이지에 있는 비트들을 조사함으로써 어떤 익스텐트들이 백업될 필요가 있는지 빠르게 알 수 있다. 전체 백업이 수행될 때마다 모든 비트들이 0으로 된다. 익스텐트에서 변경된 페이지가 있다면 DCM 페이지에서 이 페이지에 대응하는 비트가 1로 바뀐다.

로그 백업(LOG BACKUP)
대부분의 경우에 로그 백업은 마지막 전체 백업이나 로그 백어버 이후에 트랜잭션 로그에 기록된 모든 로그 레코드들을 복사한다. 그러나 BACKUP LOG 명령어의 정확한 동작은 데이터베이스의 복구 모드 설정에 따라 달라진다.




복구 모델

전체(FULL) 복구 모델
1. 커밋된 트랜잭션을 모두 복원할 수 있다.
2. 모든 동작들이 로그에 완전하게 기록된다.
3. 오류 지점이나 특정 지정 시간의 상태로 데이터베이스를 복구할 수 있다.
4. CREATE INDEX 동작도 로그에 기록된다. 인덱스 생성을 포함한 트랜잭션 로그로부터 복원할 때 인덱스가 만들어질 필요가 없기 때문에 속도가 빠르다.
5. 로그가 커질 수 있다.
6. 로그를 백업할 때 시간이 많이 걸릴 수 있다.


대량로그(BULK_LOGGED) 복구 모델
1. 매체가 고장났을 경우에 데이터베이스를 완전하게 복원 할 수 있다.
2. 벌크 동작에 대해 최소의 로그(벌크동작이 발생했다는 사실만 기록)를 사용한다.(BULK INSERT, BCP, CREATE INDEX, SELECT INTO, WRITETEXT, UPDATETEXT)
3. 최소의 로그를 사용하기 때문에 FULL 모드에서보다 빠른 수행 속도를 낸다.
4. 데이터 손실 노출은 전체 복구 모델에서보다 크다.
5. 일반적인 지정 시간 복구는 지원하지 않는다.

단순(SIMPLE) 복구 모드
1. 데이터베이스를 마지막 백업 지점으로 복구할 수 있다.
2. 오류 지점이나 특정 지정 시간의 상태로 복원할 수는 없다.
3. 트랜잭션 로그 백업을 받을 수 없다.

복구 모델을 비교하면 다음과 같다.

복구 모델	이점	작업 손실 노출	정해진 시간에 복구 가능 여부
단순 복구	고성능 대량 복사 작업을 허용함. 로그 공간에서 공간 요구 사항을 적게 유지하도록 요청함.	가장 최근의 데이터베이스나 차등 백업을 실행한 후에 변경된 사항을 다시 실행해야 함.	백업의 끝으로 복구할 수 있음. 그런 다음 변경 사항을 다시 실행해야 함.
전체 복구	데이터 파일이 손실되거나 손상되어서 작업이 손실되지 않음. 아무 시간이나 지정하여 복구 가능(예를 들어 응용 프로그램이나 사용자 오류가 발생하기 이전).	일반적으로는 없음. 로그가 손상된 경우 가장 최근에 로그를 백업한 후에 변경된 사항을 다시 실행해야 함.	아무 시간이나 지정하여 복구할 수 있음.
대량 로그 복구	고성능 대량 복사 작업을 허용함 최소의 로그 공간은 대량 작업에서 사용됨.	로그가 손상되었거나 최근의 로그 백업 이래로 대량 작업을 했으면 지난 백업 이후의 변경을 다시 해야 함. 그렇지 않으면 작업이 손실되지 않음.	백업의 끝으로 복구할 수 있음. 그런 다음 변경 사항을 다시 실행해야

트랜잭션 로그백업시 실패

다음 사용자로 실행되었습니다. NT AUTHORITY\SYSTEM sqlmaint.exe가 실패했습니다. 

[SQLSTATE 42000] (오류 22029).  단계가 실패했습니다 

 아래처럼 해당 DB 속성에서 복구 모델이 단순 일 경우 트랜잭션 로그 백업 실패가 나온다.

웹 관리자를 위한 응급처치법
SQL Injection 해킹 보안

 

박상옥│호스트웨이코리아

 

몇 해 전부터 중국 해커들로부터 한국의 서버들이 해킹당하는 사례가 급격히 증가하고 있다. 이 같은 해킹 피해 사례가 외부로 알려지지 않은 경우가 많지만, 윈도우 환경에서 서버를 운영하는 국내 유수의 사이트들은 드러난 수치보다 훨씬 빈번하게 SQL Injection으로 인한 피해를 입어왔다.

필자의 실제 경험으로도 그렇다. 필자와 상담한 어느 고객의 경우 SQL Injection의 침입으로 참담한 피해를 감수해야 했다. 이 고객은 MS SQL의 시스템 관리자 계정으로 웹 사이트의 DB 연동을 수행했는데 이 과정에서 SQL Injection의 공격을 받아 시스템은 물론이고, 디스크에 저장된 데이터 모두를 잃고 말았다.

당시 고객이 이용한 디스크는 73GB 용량의 SCSI 디스크였으나, 이것이 논리적으로 인식된 크기는 1TB에 달했다. 이를 로 레벨 포맷하고 나서야 정상적인 크기로 돌아왔지만, 이미 모든 데이터는 사라진 후였다. 이처럼 SQL Injection은 단순한 웹 변조 수준을 넘어 시스템과 디스크 장치까지 피해를 주고 있다.

 

웹서버 보안을 강화하자

 

지금부터는 자신이 관리하는 윈도우 시스템에 SQL Injection의 침입 흔적이 있는지를 확인하고, 웹서버의 보안을 강화하는 방법을 살펴보자.

사실 SQL Injection으로 인한 피해는 프로그래머의 부주의에서 비롯된다고 해도 지나치지 않다. 따라서 SQL Injection으로 인한 피해를 예방하려면 다음의 3가지를 우선적으로 지켜야 한다.

①Sysadmin 권한의 계정으로 DB Connection을 하지 말자.
②입력폼 등에서 특수문자나 예외문자에 대한 Replace를 수행한다.
③저장 프로시저(Stored Procedure)를 이용한다.

SQL Injection 방지와 관련한 프로그래밍 자료는 다음 사이트(KISA)에서 다운로드할 수 있다(http://www.kisa.or.kr/ news/2005/announce_20050427_submit.html).

 

SQL Injection의 3가지 기법

 

SQL Injection을 이용한 해킹은 시스템의 취약성에 따라 Authentication Bypass, OS call, Query manipulation 등을 조합해 이뤄진다.

 

■ Authentication Bypass
주로 로그인 창에 적용되는 기법으로 이용자 아이디와 패스워드를 몰라도 로그인할 수 있게 해준다. 테이블의 첫 번째 Row 값을 써서 로그인하고, 만약 그것이 관리자 페이지라면 웹사이트 관리자로 로그인할 수 있다.

<화면1>Authentication Bypass를 써서 보안이 취약한 웹사이트에 로그인 할수 있다.

 

■ OS Call
OS Call은 Sysadmin 권한 계정으로 DB 연동을 수행했을 때를 노린다. 마스터 DB의 확장 저장 프로시저에서 윈도우 시스템을 핸들링할 수 있는 확장 저장 프로시저들을 실행케 해주는 것이다.

OS Call을 방지하기 위해서는 아래의 확장 저장 프로시저들을 쓰지 못하도록 Disable하거나, 확장 프로시저에 해당하는 DLL 파일을 삭제해야 한다. 그러나 이 역시 완전한 대비책은 못 된다. 삭제된 DLL 파일은 해커에 의해 재생성되거나, 업로드돼 이용될 수 있기 때문이다. 그러므로 해킹을 염려한다면 Sysadmin 권한 계정으로 DB 연동을 절대 수행하지 말아야 한다.

 

<화면2> OS Call은 확장 프로시저를 이용해 Admin 권한 계정을 생성하는 원리다.

■ Query Manipulation
아래 URL 주소와 같이 예외 처리를 하지 않은 사이트는 SQL Query를 조작할 수 있다.

http://www.somecompany.com/notice.asp?no=5 ;EXEC master. dbo.xp_cmdshell’ cmd.exe dir c:

 

 

Injection 자료의 수집

 

SQL Injection을 위한 데이터는 주로 웹 랭킹 사이트에서 수집된다. 특히 구글 해킹을 통한 admin 페이지 수집이 빈번한 것으로 알려져 있다. 일반적으로 admin 페이지들은 http:// website.com/admin을 이용하는 경우가 많은데 이런 데이터 수집 과정을 감안하면 이는 결코 바람직하지 않다. 또한 해당 사이트나 제품의 취약점을 찾아내주는 SQL Injection Tool도 침입을 위한 자료 수집에 많이 이용되고 있다. 이 도구들은 주로 중국에서 제작돼, 심지어 상용화되기도 한다.

 

<화면3> Googledock을 이용한 정보 수집

 

 

SQL Injection의 피해 확인

 

일반적으로 웹사이트가 Injection 툴에 의해 침입을 받았다면 DB에 해당 툴을 암시하는 테이블이나, 이용자 계정 정보가 남아 있게 된다. 또한 IIS 웹로그에도 로그 기록이 남기 때문에 이를 통해서도 침입 흔적을 확인할 수 있다.

■ HDSI 툴에 의한 침입
HDSI 툴은 SQL Injection에 취약한 사이트의 DB를 조회하거나 시스템 명령어 등을 실행할 수 있게 해준다. DB에 T_Jiaozhu, jiaozhu, comd_list, xiaopan, Reg_Arrt 등의 테이블을 생성하므로, 이 테이블들의 존재를 확인함으로써 침입 여부를 알 수 있다.

 

■ D-SQL에 의한 침입
DB에 D99_Tmp라는 테이블이 존재한다면 D-SQL을 써서 시스템 명령어를 실행한 것으로 볼 수 있다. 아울러 D99_Reg 테이블은 레지스트리 수정, D99_Tmp는 디렉토리 탐색, D99_CMD는 명령어 수행이 이뤄졌음을 각각 나타낸다. D-SQL은 또한 IIS 웹로그도 생성한다.

 

 

<화면4> HDSI 툴은 T_Jiaozhu, jiaozhu, comd_list, xiaopen, Red_Arrt 등의 테이블을 생성한다.

 

<화면5> D-SQL의 실행 모습

 

 

웹로그에서 확인하기

 

웹로그에서도 테이블과 관련한 Create나 Select 구문이 없는지를 확인해야 한다. 아울러 확장 저장 프로시저에 대한 로그가 존재하는지도 살펴본다. 웹로그에서 검색해봐야 할 문자열에는 XP_CMDSHELL, Net, user, Update, Insert, drop table 등이 있다.

 

<화면6> D99_Tmp, D99_Reg, D99_Tmp 테이블은 D-SQL의 침입을 의미한다.

 

웹서버 보안을 위한 체크 리스트

 

지금부터는 웹서버 보안을 위한 주요 체크 리스트를 소개한다. 다음의 내용을 자세히 살펴본 후 자신의 웹서버에 해당되는 부분을 찾아 적용해보자. 이 체크 리스트는 대부분 윈도우 2000 환경을 전제로 하고 있다.

 

■ Patches and Updates
먼저 최신 패치나 서비스팩을 적용했는지 여부와 정기적으로 MBSA를 써서 운영체제 및 애플리케이션 보안을 체크하고 있는지를 확인한다. 현재 2.0 버전이 출시돼 있고, 패치 정보와 윈도우 보안에 대한 가이드도 제공하고 있다. 정기적으로 MS가 제공하는 최신 패치 정보(http://www.microsoft.com/ technet/security/bulletin/notify.asp)를 받아보는 것도 큰 도움이 된다.

 

■ IISLockdown
IISLockdown이 웹서버에 설치돼 운영되고 있는지를 살펴본다. IISLockdown은 웹서버 보호 과정을 대부분 자동화해주는 도구로 서버 용도나 유형에 따라 여러 보안기능을 해제하거나, 보호할 수 있는 이용자 템플릿을 제공한다. 또한 URLScan을 설치 및 구성했는지도 체크해야 한다. URLScan은 웹사이트 관리자가 서버에서 처리 가능한 웹 요청을 제한할 수 있는 ISAPI 필터로, 잠재적으로 유해할 수 있는 웹 요청을 서버에 도달하기 전에 차단해준다.

 

■ Services
불필요한 윈도우 서비스들을 disable로 설정했는지도 체크 포인트다. FTP, SMTP, NNTP 서비스 등이 필요치 않다면 설치하지 않는다. 특별한 경우가 아니라면 Telnet과 ASP .NET state service는 중지하는 것이 바람직하다.

 

■ Protocols
WebDAV를 이용하지 않는다면 중지하고, 필요하다면 반드시 보안 설정을 수행한다. 보안 설정과 관련된 내용은 http:// support.microsoft.com/default.aspx?scid=kb;en-us;Q323470을 참고한다. NetBIOS와 SMB 포트(137, 138, 139, 445 포트)의 Disable 설정도 고려할 만하고, 윈도우 2000이라면 DoS 공격을 대비한 TCP/IP Stack의 강화가 필요하다. 보다 자세한 내용은 http://support.microsoft.com/default. aspx?scid=kb;ko;315669를 참고한다.

 

■ Accounts
이용하지 않는 계정은 삭제하고, Guest 계정은 항상 disable로 설정한다. Administrator 계정은 암호 설정 규칙을 충실히 따른 후 Rename해 쓴다. 그러나 윈도우 2000의 경우 Administrator 계정을 Rename해도 완벽히 대비할 수 없다는 점을 유의해야 한다. 윈도우 2000의 관리자 계정은 500번 이하의 기본 SID 값을 가지는 탓에, 해커들이 액티브 디렉토리나 로컬 SAM을 이용해 이 SID 값을 아이디로 바꿔 계정을 공격할 수 있다. 이를 방지하기 위해서는 다음의 과정을 따른다.

?U AD 환경이라면 그룹 정책 가운데 하나인 기본 도메인 정책을 수정한다.
‘컴퓨터 구성\Windows 설정\보안 설정\로컬 정책\보안 옵션’에서 익명 연결의 추가적인 제한을 ‘SAM 계정 및 공유 열거 허용 안 함’으로 선택한다.
?V AD 환경이 아니라면 시작-실행-gpedit.msc을 입력해 그룹정책을 적용한다.

■ Files and Directories
NTFS 파일시스템을 선택하고, 웹사이트의 루트 디렉토리는 SystemRoot 드라이브 외의 디렉토리에 위치시킨다. 아울러 웹로그 디렉토리는 SystemRoot 드라이브 및 웹사이트 루트 디렉토리 외의 볼륨에 두도록 한다. Everyone 그룹을 제거하고, Website Root 디렉토리에 IUSR_Machine 계정의 쓰기 권한을 주지 않는다.
자료실 이용 등으로 익명의 계정이 업로드해야 한다면, 해당 웹서비스의 디렉토리 내에는 Script 실행 권한을 부여하지 않는다. 기본 웹사이트와 관리 웹사이트는 삭제하거나 중지한다.

 

■ Shares
불필요한 공유는 없애고, 파일 공유 생성 시 권한에 유의한다. Everyone Access는 되도록 쓰지 않는다.

 

■ Ports
SSL을 구성한다.

 

■ Registry
원격 레지스트리 연결을 제한하기 위해 Remote Registry Service를 중지한다. 198쪽에서 계속

정리 | 전도영 mir@imaso.co.kr

 

참고자료

ㆍ http://www.krcert.or.kr
ㆍ Microsoft - Checklist: Securing Your Web Server

 

툴 소개


웹 침입 차단을 위한 프레임 제공, Webknight

Webknight는 공개 소프트웨어의 하나로 SQL Injection을 비롯해 여러 형태의 웹 공격을 차단하는 프레임을 제공한다. 웹사이트(http://www. aqtronix.com)에서 다운로드 해 이용할 수 있지만, 실제 서버에 적용하기 전에는 반드시 테스트 서버를 통한 점검이 이뤄져야 한다.

① 사이트(http://www.aqtronix.com/downloads/WebKnight/ 2004.02.01/WebKnight.zip)에서 다운로드한다.
② 압축을 해제하고, Setup 폴더 하위의 WebKnight.Msi를 실행해 설치한다.
③ IIS 웹서버를 Restart 한다.
④ 정상적으로 설치가 완료되면, <화면 7>과 같이 ISAPI Filters에 Webknight가 추가된다.
⑤ 기본 설치 폴더에서 C:\Program Files\AQTRONIX Webknight\ Config.exe를 실행하면, 현재 설정을 볼 수 있다.

<화면 7> ISAPI Filters에 Webknight 추가



⑥ <화면 8>처럼 SQL Injection 관련 설정을 확인하고, 필요한 경우 수정한다.
⑦ <화면 8>처럼 해당 Query가 2번 이상 요청되면 블로킹 웹사이트를 보여준다.
⑧블로킹 페이지를 수정할 때는 C:\Program Files\AQTRONIX Webknight\nohack.htm을 이용한다.

한편 무료 웹사이트 점검을 이용해 웹사이트의 취약점을 파악할 수도 있다. 한국정보보호진흥원이 마련한 웹 취약점 원격 점검 서비스(webcheck.krcert.or.kr)가 대표적이다. 이 사이트에 접속해 서비스를 신청하면 운영하는 웹사이트가 지닌 위험 요소를 쉽게 파악할 수 있다. 이외에도 많은 인터넷 데이터센터(IDC)들이 SQL Injection 무료 점검 서비스를 제공하고 있다.

<화면 8> SQL Injection 관련 설정 확인

 

 

켄 핸더슨의 책에 나와 있는 것중 그중 몇가지 쓸만한 것만 모아 보았습니다. (bleujin 개인적 판단)

문서화 하지 않은 이유는 크게 2가지가 있습니다.

1) 위험하다

2) 지원을 보장하지 않는다.

 

아주 예전에 김정선님과 이와 관련하여 얘기한 적이 있는데

개인적 판단은 이러한 것은 굳이 숨기는 것보다 사용자에 달린 문제라고 생각합니다.

(사실 알지 못하더라도 약간 귀찮을 뿐입니다. 세상과 마찬가지로 대체물이라는 것이 존재하니까요. )

 

 

 

특정한 dbName이 없으면 Northwind Sample DB를 사용했습니다.

 

 

1. guid column

오라클의 경우 의사컬럼인 rowid가 있는데 PL/SQL 프로그래밍을 할때(특히 Clob 컬럼) 종종 유용하게 쓰입니다.

 

문법 : sp_MSaddguidcolumn @owner, @table

사용예 : sp_MSaddguidcolumn dbo, orders

 

해당 테이블에 rowguid 컬럼이 추가됩니다. 이 컬럼은 해당 row의 id 입니다. 8-4-4-4-12자리로 되어 있는데 해석이 안됩니다-_-

FileName, DbName, ObjectName, Row Location 등의 정보를 가지고 있으므로 해당 값은 최소한 해당 MSSQL 서버 내에서는 Unique 합니다.

그러나 오라클의 Clob 타입과 달리 MSSQL의 TSQL  프로그래밍을 할때 써먹어 볼려구 머리 굴려봤지만 써먹어 본적은 아직 없습니다-_-

 

참고 : sp_MSaddguidindex @owner

@owner, @table 해당 테이블 guid 컬럼에 인덱스를 만듭니다.

 

 

 

2. error log 보기

 

서버에 현재 있는 오류 로그 파일들의 목록을 보여줍니다.

문법 및 예제 : master..sp_enumerrorlogs

참고 : master..xp_enumerrorlogs 와 같다.

 

오류 로그의 내용을 보여준다. lognum을 지정하지 않으면 현재 오류 로그를 보여준다.

문법 : sp_readerrorlog [@lognum]

예제 : sp_readerrorlog

참고 : master..xp_readerrorlog [@lognum]와 같다.

 

 

 

3. 파일 관련

 

지정한 경로의 모든 하위의 서브 디렉토리를 해당 디렉터리의 노드레벨 정보와 함께 보여준다.

문법 : xp_dirtree 'rootpath'

예제 : master..xp_dirtree 'c:\' (좀 많이 느리다-_-)

 

지정한 경로의 바로 하위에 있는 서브 디렉토리의 이름을 반환한다.

문법 및 예제 : master..xp_subdirs 'c:\'

 

파일 존재 여부를 알려준다.

문법 : xp_fileexist 'filename'

예제 : master..xp_fileexist 'c:\winnt\odbc.ini'

 

현재 시스템의 고정 Drive를 보여준다.

문법 및 예제 : master..xp_fixeddrives

 

특정 파일에 대하여 자세한 정보를 알려준다.

문법 및 예제 : master..xp_getfiledetails 'c:\winnt\odbc.ini'

 

서버 컴퓨터의 네트워크 이름을 반환한다.

문법 및 예제 : master..xp_getnetname

 

레지스트리 키에 있는 값들을 보여준다.

문법 및 예제 : Exec master..xp_regenumvalues 'HKEY_LOCAL_MACHINE', 'SOFTWARE\Microsoft\MSSQLServer\MSSQLServer'

참고 : 레지스트리 키를 추가 / 수정 / 삭제 하는 xp_regaddmultistring, xp_regdeletekey, xp_regdeletevalue, xp_regread, xp_regremovemultistring, xp_regwrite 등도 있다.

 

 

 

4. 테이블 정보

오브젝트의 종속성을 보여준다.

문법 : sp_MSdependencies @objname, @objtype, @flags int, @objlist

사용예 : sp_MSdependencies 'orders'

 

테이블이 참조하는 오브젝트 또는 그 테이블을 참조하는 오브젝트를 보여준다.

문법 : sp_MStablerefs @tablename, @type, @direction, @reftable

예제 : sp_MStablerefs 'Orders'

 

테이블 공간 정보를 보여준다.

문법 : sp_MStablespace @tablename

예제 : sp_MStablespace 'Orders'

 

5. Batch

 

시스템 상의 모든 데이타베이스에 대하여 세개의 명령어를 실행한다.

문법 : sp_MSforeachdb @command1 @replacechar = '?' [, @command2] [, @command3] [, @precommand] [, @postcommand]

예제 : Exec sp_Msforeachdb @command1 = 'PRINT ''LISTING ?''', @command2 = 'USE ? Select DB_Name()'

 

배치 Script를 만들때 쓸만하다. @precommand와 @postcommand은 일종의 Junit의 setUp()과 tearDown() 역할을 한다.

 

참고 : 현재 DB의 모든 테이블에 대해서 세개의 명령어를 실행하는 것두 있다.

문법 : sp_MSforeachtable @command1 @replacechar = '?' [, @command2] [, @command3] [,@whereand] [, @precommand] [, @postcommand]

예제 : sp_Msforeachtable @command1 = 'Exec sp_help [?]' , @whereand = ' And name like ''%c%'''

@whereand는 테이블을 선택적으로 제한할 수 있다.

 

 

 

6. 기타

 

인덱스의 크기 정보를 보여준다. MS 가 통계 정보를 기초하여 지맘대-_-로 만든 _WA_Sys_columnanme.... 등의 인덱스도 보여준다.

문법 : sp_MSindexspace @tablename [, @indexname]

예제 : sp_MSindexspace 'Orders'

  

 

Tempdb db 에 대한 공간 사용정보를 반환한다.

문법 및 예제 : sp_tempdbspace

 

DB Control

문법 : DBCC DBControl(dbname, option)

예제 : DBCC DBControl ('Northwind', single)

single(single-user 모드로 지정한다. ), multi(multi-user 모드로 지정한다.), online, offline, readonly, readwrite 등의 옵션이 있다.

 

현재 Error log를 닫고 새로운 error log를 시작한다.

문법 및 예제 : DBCC Errorlog

 

데이타 베이스에 있는 모든 저장 프로시저를 재컴파일한다. (View나 테이블에 컬럼을 추가 하는 등의 변경이 일어났을 경우 유용하다. )

문법 : DBCC FlushProcInDB( @dbid )

예제 :

Declare @dbId int

Set @dbid = DB_ID('Northwind')

DBCC FlushProcInDB( @dbid )

 

DBCC 명령문의 사용법에 대한 정보를 보여준다. (명령어의 의미는 보여주지 않는다. )

문법 : DBCC Help(명령어)

예제 : DBCC Help(TraceOn)

 

해당 데이테베이스의 트랜잭션 로그 레코드 정보를 보여준다. (나름대로 꽤 유용)

문법 : DBCC LOG (@dbname)

예제 : DBCC Log('pubs')

 

SQL 서버 Memory 정보를 보여준다.

문법 및 예제 : DBCC MemoryStatus

 

그밖에 정원혁님의 SQL Server 2000 Internal 온라인 강의에 DBCC 명령어 몇개가 나온다.

 

 

 

앞에서도 말했듯이 켄 헨더슨의 책에 나와 있는 걸 굳이 옮긴 이유는

SQL Server로 할수 있는 프로그래밍 영역이 일반적으로 알려져 있는 것보다 넒다라는 얘기를 하기위해서..