제4장 시스템관리

개요

이 장에서는 마이크로소프트 SQL 서버 2000환경에서 매일,매주, 매월 수행해야 하는 시스템 관리를 위한 최선의 작업에 대해 소개한다. 또한 인덱스 생성과 유지관리에 대해서도 자세히 설명되어 있다. 백업과 복원은 다양한 방법으로 데이터를 이동하는 것과 더불어 소개되었다. 이 장 끝에서 소개된 고급화된 관리는 메모리관리,로그 전달, 클러스터링을 포함한다. 데이터베이스 관리자는 이장을 통해 SQL 서버 2000 데이터베이스 환경에서 사용할 수 있는 적절한 도구와 기술 및 관리 작업을 위한 대부분의 유지관리 일정을 결정할 수 있을 것이다.

소개

마이크로소프트 SQL 서버 2000 환경에서 시스템 관리를 하는 것은 데이터베이스관리자(DBA)의 주요 책임이라 할 수 있다. 마이크로소프트 SQL 서버 2000 은 DBA가 시스템을 유지하고 최적화하는 데에 있어 도움을 주기 위한 여러 가지 기능을 제공한다.

DBA가 최적화된 서버 환경을 구축하기 위해 다양한 자원을 사용할 수 있더라도, 사실상 많은 DBA가 이러한 리소스를 사용할 수 있는 기술과 지식이 부족하다.

이 장은 공통적인 시스템관리 영역에서 DBA가 교육받아야 하는 내용에 중점을 두고 있다.

충분히 기능적이고 최적화된 환경은 다음과 같은 몇 가지 정의된 특징을 가진다.

데이터베이스 시스템의 관리는 여러 가지 관리자적인 업무와 최적화 업무,문제발생 시 문제해결을 위한 업무로 구성되어 있다. 이 가이드는 성능 튜닝(5장 참조)과 문제해결(7장 참조)에 대하여 별개의 장으로 구성되어 있으며, 이들 주제는 이 장에서 간략히 소개하고 다음 내용을 중점적으로 다룰 것이다.

DBA 팀

DBA 및 데이터베이스 시스템 엔지니어의 역할은 시간이 지나면서 바뀌어 왔다. 데이터베이스가 점점 복잡해 짐에 따라, 자동 튜닝과 자동화된 관리기능이 점점 더 보편화되었고, 결과적으로, DBA는 일상화된 여러 작업으로부터 해방되었다. 가령 데이터베이스 시스템의 성능 향상을 위해 주기적으로 수행하는 사용량 추이 분석 및 회사 내 또는 회사외부 간의 정보 흐름관리 같이 좀 더 전략적인 업무에 중점을 둘 수 있게 되었다.

데이터베이스 시스템의 성공적인 관리는 전략적 접근방법과 데이터베이스 관리수행에 있어 수준 높은 책임을 요구한다. 이 개념(이 문서에서는 데이터베이스 전문 팀이 운영중인 데이터 센터를 대상으로 한다)은 데이터베이스의 다양한 환경에 적용될 수 있도록 구성되었다.

효과적인 관리를 위해서는, DBA팀이 회사 내에서 다른 팀과 업무를 어떻게 수행할 것인가에 대하여 명확히 정의해 놓아야 한다. 이것을 위해서는 팀 내의 모든 DBA가 하나의 구성 단위로서 일하는 것이 반드시 필요하다. 팀워크와 협동을 독려하기 위해서, 모든 데이터베이스 서버에 대한 책임을 전체 그룹으로 공유하는 것이 우선이다. 팀원내의 신뢰를 만들려면 격려하고 정직과 책임에 대한 보상을 제공하여야 한다. 각 팀원의 성공은 다른 팀원의 성공에 달려 있다는 점을 인식해야 한다.

많은 시스템을 지원하는 환경에서 책임의 한계를 명확히 하기 위하여, DBA는 업무시간과 업무시간 외에도 서비스 수준 유지(SLA: service level agreements)를 충족시킬 수 있도록 팀간 협력이 필요하다.

만일 한 사람이 운영하는 시스템이라면, 그 시스템은 단일 실패 요인(single point of failure)에 노출된다. 이것은 DBA팀이 통합된 구성단위로서 일하는 것이 얼마나 중요한 것인가를 나타내는 것이다. 다음 몇 가지 사항이 이것을 이루기 위해 도움이 될 것이다.

임무교대

각 시스템에 담당 DBA와 보조 DBA를 할당 지정한다. 그렇게 하려면 시스템 당 적어도 두 사람의 DBA가 있어야 된다. 또한, 직원을 프로젝트 간에, 서버 종류별로, 실제 운영 환경과 개발 환경 간에 임무를 교대 시켜야 한다. 임무교대는 교차된 훈련을 활성화시키며, 폭 넓은 경험과 공통적인 업무 수행능력을 제공하며, 좀 더 나은 문서화를 할 수 있도록 한다. 임무교대 기간은 반드시 DBA가 해당 시스템과 친숙할 수 있도록 충분히 긴 시간을 제공해야 한다.

효율적인 유휴 시간 활용

친숙하지 않은 프로젝트나 시스템 또는 팀원이 사용했던 신기술을 활성화시키려면 유휴 시간을 이용하여 교육 기회를 제공한다. 만일 유휴 시간이 없다면, DBA 팀을 위한 별도의 시간을 만들어야 한다. 한 시간 반에서 두 시간 정도 점심을 먹으면서 간단하게 자료를 발표할 수 있는 시간을 갖는 것도 하나 넘지 않고 주간단위로 개최하며 업무 교육에 많은 내용들이 이런 식으로 전달될 수 있도록 한다.

점심시간을 이용한 발표의 다른 부가적인 이점은 각 개인이 중요한 사항을 체계화하고, 쟁점에 올라온 시스템을 문서화하고, 그룹에 발표하는 연습을 할 수 있다는 것이다.

의사소통

팀원간에 서로 의사소통을 잘할 수 있도록 고무해야 한다. DBA의 역할은 서버 환경 구성보다는 회사의 지식을 관리하는데 중점을 두도록 바뀌어가고 있다. 기업은 DBA가 데이터 센터에서 리더가 될 때 최대의 이점을 얻을 수 있다.

또한, 높은 수준의 의??할 필요가 없어지며, 그 것은 서버를 사용할 수 없을 때와 같은 아주 귀중한 시간을 절약할 수 있을 것이다.

DBA 그룹이 IT 부서 내에서 존중 받는 것은 매우 중요하다. 다른 운영그룹이나 개발팀이 DBA 그룹을 전문적이며 숙련된 팀으로서 본다면, 시스템에 결정적인 위험을 초래할 어떤 의사 결정을 무효화할 수 있을 만큼 힘을 가지게 될 것이다.

경고 메시지

에스컬레이션 하거나 일정 시간을 투입하고도 문제를 해결하지 못하는 상황을 위해, 팀원 뿐 아니라 회사의 헬프 데스크에 경고 메시지를 보내는 것을 고려해야 한다. 헬프 데스크는 적당한 직원(비록 그들의 핸드폰이 꺼져있다고 할지라도)을 배치시킬 수 있어야 한다. 만일 DBA가 가용하지 않다면 특정 이슈는 문제가 해결될 때까지 단계적으로 수평 및 수직적으로 확대되어야 한다.

헬프 데스크를 통한 에스컬레이션은, 요청된 메시지 유형에 따라 어떻게 행동하고, DBA 그룹에서 어떻게 에스컬레이션 하며, DBA가 없을 경우 어떤 사람과 연락하고 어떤 (네트워크 및 보안 관리자가 승인한) 행동을 취할 것인지에 관한 치밀한 계획이 필요하다.

팀을 위한 웹사이트

전체 팀과은 각 서버에 대한 상태 정보를 신속하게 표시하는 팀 웹사이트를 구축하는 것이다. 이 경우에 있어, 팀 웹사이트를 지원하는 서버 또한 장애관리 범위에 포함되어야 한다. 모든 DBA는 경고 메시지를 보낼 수 있으며 발생되는 이벤트 및 중요 프로젝트 또는 시스템 특성에 대해 중앙집중적인 방식으로 의사소통을 할 수 있다. 이 팀 사이트는 DBA팀에게만 개방되어 있는 간단한 네트워크 공유로부터 시작될 수 있다.

세계 일류의 데이터베이스 관리 서비스를 만드는 것은 순환적이고 반복적이다. 계속해서 개선점이 나타나며, 노력을 통해서만이 기술 지원 인력의 기술 수준을 높이고 향상시킬 수 있다.

지속적인 학습

DBA는 데이터베이스 기술이 발전함에 따라 학습할 수 있는 시간이 필요하다.

팀을 이끌어 나갈 때, 팀원이 학습할 수 있는 시간을 반드시 만들어 주어야 한다. 팀원이 되면 항상 새로운 교육을 찾아야 하며 그 교육을 위한 정당성을 제공해야 한다.

모든 사람들이 단 기성 교육을 받는 것 보다는 계속해서(한 번에 한 장 또는 섹션) 반복적으로 학습할 수 있는 풍토를 조성해 주어야 한다. 매우 큰 목표를 한번에 이루는 것은 어렵지만, 대신 단일 주제에 대하여 유용한 교재를 가지고 교차 지식 학습 기회를 통한다면 소기의 목적을 달성할 수 있을 것이다. 예를 들어, 복제에 대하여 배우는 것을 목표로 한다면, 책, 정기간행물, 웹사이트, 유즈넷(Usenet)그룹 등과 같은 여러 자료를 활용하여 원하는 목표를 달성할 수 있다. 필요에 따라 주제를 새로 바꾸거나 관심을 변화시켜나간다. 다양한 자료를 발표하는 것은 팀원 및 팀 전체의 기술력을 향상시킬 수 있을 것이다.

회사는 구성원에 대한 교육 투자를 통해 실익을 얻을 수 있다. 시스템을 가장 잘 아는 사람, 그리고 신기술의 이해 수준이 깊은 사람을 확보했다면, 그 회사의 시스템은 높은 가용성을 유지하게 될 것이고, 시스템 구축 및 유지 수준 또한 높아질 것이다.

서비스 수준 유지(SLA: Service Level Agreement)

데이터베이스 시스템을 위한 서비스 수준 유지의 주요 목적은 시스템 관리와 사용자의 기대치를 정의하는 데 있다. 서비스 수준 유지의 자세한 내용은 8장을 참조하며, 이는 DBA 역할에도 영향을 준다.

관리자적인 측면

안정적이고 최적화된 SQL 서버 2000을 만들려면, SQL 서버 2000, 구성요소, 구성요소를 이용한 응용 프로그램의 기술적인 지식 뿐만 아니라 비즈니스 요구사항에 부합하는 솔루션을 어떻게 잘 구성할지도 고려해야 한다. 데이터를 항상 정확하고 안전하게 유지하며, 가용성을 확보하는 것이 DBA가 가장 신경 써야 할 부분이다.

문서화 및 표준화

DBA가 수행해야 하는 중요한 작업 항목으로는 SQL 서버 2000환경의 문서화와 표준화이다. DBA는 서비스 보장의 수준과 깊이를 결정하는 데에 있어 전적으로 책임을 져야 한다. 문서화에는 일반적으로 다음 사항이 포함된다.

시스템 환경 구성요소는 서버의 하드웨어와 소프트웨어 뿐 아니라 전용회선 같은 네트워크 하부구조(가령 T1 라인과 같은), 제품 및 서비스 공급자와 시스템 관계자에 관한 내용을 포함한다.

프로세스는 절차들을 담고 있다. 작업 절차에 포함되는 내용은 서버에 새로운 계정을 추가하는 것부터 장애 복구에 관한 것 등 이다.

프로토콜은 작업을 통제하는 규약이다. 규약은 모든 작업이 안정적이고 일관된 방법으로 수행될 수 있게 한다.

연락처 정보는 시스템과 관련된 조직 내외에 있는 모든 사람을 포함해야 한다. 조직 내에 있는 사람으로는 개별 담당자와 DBA 그룹, 개발자 그룹, 네트워크 운영자 그룹, 헬프 데스크 관계자, 운영 관리자 그룹이 포함된다. 기업 외부의 연락처 정보로는 하드웨어와 응용 프로그램 대변인(영업 사원 및 기술지원 요원)이 포함된다. 전화번호, 팩스번호, 핸드폰번호, 일정, 부재 시 연락할 수 있는 대변인에 대한 정보도 반드시 포함한다.

기존 장애이력일지는 예전에 발생된 문제와 문제 해결을 위해 포함된 모든 절차와 연락처를 포함하고 있다(7장 참조). 장애이력일지는 사용하기 쉽고 검색도 용이하도록 웹 기반으로 만들어 향후에 발생할 수 있는 문제를 신속히 처리할 수 있어야 한다.

표준화는 간편한 관리를 위해 중요하다. 서술할 수 있는 작업, 반드시 기술되어야 하는 작업은 문서화하고 유지관리 한다. 내용이 일반적이고 중요한 정보는 운영 매뉴얼에 기록하며, 모든 DBA가 검토할 수 있고 이해할 수 있어야 한다(운영 매뉴얼을 작성하는 추가적인 정보는 제 2장 참조).

모든 서버에 관한 서버 구성 표준화는 어느 환경에서나 유용하다. 서버 구성 표준화를 수행하려면 서버 설치시 기본적인 값을 가지고 있지 않는 서버의 모든 구성 정보를 문서화 한다.

새로운 서버 장비를 도입하여 설치할 때, 유용하게 활용하기 위하여 표준화된 서버 구성을 만들어야 한다. 많은 시스템들은 분명히 표 것을 처리하기 위해서, 표준 서버 구성 환경과해야 한다. 표준 서버와 그렇지 못한 서버 간의 사람이 쉽게 접근할 수 있는 곳에 읽기 전용으?움이 될 것이다.

저장 시스템을. 표 4.1은 드라이브 문자 지정에 대한 예를 보여 주고 있다.

논리적 드라이브 문자	설명
C	운영체제, SQL 실행파일
D	CD-ROM 드라이브
E	필요하다면, 다른 시스템 드라이브
F 부터 H	임시파일
I 부터 P	데이터 파일
Q	쿼럼(quorum)드라이브
R, S	SQL 실행파일과 시스템 데이터베이스
T부터 V	트랜잭션 로그 파일
X, Y, Z	백업 또는bulk loading와 같은 입력을 위한 데이터
\SQLAdmin	로그와 trace 결과,sqldiag.exe결과 등의 리포트를 저장하기 위한 표준화된 관리 디렉터리

네트워크 드라이브를 사용하는 응용 프로그램 코드의 유연성을 확보하기 위하여 UNC(universal naming conventions)를 사용한다.

표준화에 신경을 쓰더라도 예외는 존재하므로 예외 사항에 대한 내용을 간략히 표현한다. 목표는 90%라도 표준화를 하는 것이며 나머지 10%는 기억하기 쉽도록 만드는 것이다.

도구, 기능과 기술

완벽한 SQL 서버 2000 관리를 위한 솔루션으로 SQL 서버 2000, 윈도우2000 플랫폼 및 기타 마이크로소프트 제품과 여러 3rd 파티 도구 및 기술이 통합되어 제공될 수 있다. 사용된 도구 및 유틸리티와 이들의 사용 방법은 다음과 같은 몇몇 요소에 달려 있다.

간단하고 효율적인 예는 엔터프라이즈 관리 스냅인과 기타 관리 기능을 포함하고 있는 마이크로소프트 관리 콘솔을 이용하는 것이다. Microsoft.com(SQL 웹사이트,TechNet, MSDN)과 다른 유용한 웹사이트에 링크하는 것은 또한 동적 관리 도구를 쉽게 구축하기 위하여 MMC로 통합될 수 있다.

스크립팅

Transact-SQL

일반적으로,모든 반복적인 작업은 스크립트와 저장 프로시저를 이용하는 것이 바람직하다. 스크립트는 사용자 오류 발생 빈도를 줄여준다. 스크립트는 반드시 스크립트 내에 줄 사이와 블록 단위로 코멘트를 사용하고 스크립트 바깥에서는 readme.txt나 doc 파일을?을 위하여 스크립트는 반드시 보안상 안전한 디렉터리 구조 또는 마이크로소프트 비주얼 소스세이프(Visual SourceSafe) 같은 라이브러리 버전관리 도구를 이용하여 중앙 집중적으로 유지관리 하는 것이 바람직하다. 즉, 최신 버전이 무엇인지 알 수 있어야 한다. 스크립트는 GUI 또는 마법사의 옵션을 이용하여 작업 담당자의 수준에 따른 권한 관리를 할 수 있다. GUI환경과 마법사를 이용하여 수행한 작업은 실제 SQL문으로 캡쳐되어 저장가능하며 다시 SQL 프로필러(Profiler)를 이용하여 재현 할 수 있다. 추가적으로, 엔터프라이즈 관리자에서 "변경 스크립트 저장"과 같은 스크립트 버튼은 테이블과 같은 오브젝트 내에서 변경이 생길 시에 쉽게 스크립트로 변경될 수 있음을 의미한다. 이것은 엔터프라이즈 관리자를 실행하여 관리 업무를 수행하면서 내부적으로 어떤 일이 일어나는지 알지 못하는 경험이 적은 DBA에게 매우 유용하다. 고객의 요구에 맞게 변경되었거나 3rd 파티에서 만든 응용 프로그램을 통하여 일어나는 작업 또한 SQL 프로필러를 사용하여 캡쳐할 수 있다. 그렇게 하는 것은 모든 DBA가 응용 프로그램의 기능과 성능 문제를 해결하는 데에 있어 도움이 된다.

새로운 스크립트는 실제 운영 운영서버에 적용하기에 앞서 품질 평가(QA: quality assurance)환경에서 철저히 테스트되어야 한다. 롤백을 위한 스크립트는 반드시 생성됨과 동시에 유지되어야 한다. 비슷한 스크립트를 생성하는 간단하고 효율적인 방법은 쿼리 분석기에서 개체 브라우저의 스크립트 템플릿을 사용하여 생성하는 것이다. 템플릿은 DBA가 템플릿의 파라미터를 다른 새로운 값으로 변경함에 따라 코드와 로직을 재사용 할 수 있도록 한다. 그런 다음 이 스크립트는 적당한 폴더에 저장한다.

자동화, 일관성, 보안과 작업내역을 확실히 하기 위하여, DBA는 스크립트를 저장 프로시저 내에 캡슐화된 형태로 저장해야 한다. 저장 프로시저는 DBA가 작업을 좀 더 효율적으로 관리할 수 있도록 추가적인 로직을 가질 수가 있다. 또한, 사용자 테이블에 정보를 기록하기 위한 추가적인 코드를 가질 수가 있다. 추가적인 코드로는 요구사항을 좀더 충족시키기 위한 트리거(trigger)와 전자메일에 관한 내용이 포함될 수 있다. 보다 나은 처리를 하기 위해, DBA는 개발자와 협업을 통하여 시스템 환경내의 여러 서버에서 사용 가능한 프론트-엔드 웹 인터페이스를 구축 가능하다.

WSH(Windows Scripting Host)

윈도우 스크립트 호스트는 VBScript나 Jscript와 같이 윈도우2000환경에서 ActiveX 스크립트를 직접 실? .vbs파일을 실행할 수 있다. WSH은 메모리를 적게 사용하며 MS-DOS 명령보다도 더?? 연락하지 않고도 스크립트를 쉽게 사용할 수 있다. 그러므로 WSH는 DBA가 사용할 수 이상적인 기능을 갖는다.

예를 들어, 만일 DBA가 SQL 서버 2000 보안 환경을 재 생성할 필요가 있다면, DBA는 도메인 사용자와 그룹 계정을 생성하기 위하여 VBScript, 데이터베이스 로그인, 역할과 사용자를 생성하기 위하여 또 다른 T-SQL 스크립트를 생성할 수 있다.

인덱스와 통계

인덱스는 개발자들이 테이블에서 레코드를 유일하게 구별하고 (엔터티 무결성이라고 함) DBA가 성능을 향상시킬 수 있게 하는 SQL 서버 2000내의 저장 구조이다. 인덱스 튜닝 마법사는 관리자가 실제 운영되는 쿼리에 기초하여 인덱스의 생성과 삭제를 쉽게 할 수 있도록 한다.

추가적인 정보를 위하여 SQL 서버 온라인 설명서의 인덱스 튜닝 마법사를 참조하면 된다.

클러스터(Clustered) 대 넌클러스터(Non-clustered)
인덱스인덱스에는 클러스터 인덱스와 넌클러스터 인덱스가 있다.

클러스터 인덱스는 B 트리구조 형태로 잎수준(leaf level)에 실제 데이터 페이지를 저장한다. 레코드는 물리적으로 클러스터 인덱스 키에 따라 정렬되며 저장된다. 이러한 이유로, 테이블에는 하나의 클러스터 인덱스만 존재한다.

넌클러스터 인덱스는 데이터의 포인터만 저장한다. 선택된 포인터는 테이블을 위하여 클러스터 인덱스가 있느냐 없느냐에 따라 좌우된다. 레코드는 선택된 넌클러스터 키에 기초하여 논리적으로 저장된다. 하나의 테이블을 위하여 249개의 넌클러스터 인덱스가 있을 수가 있다.

테이블이 클러스터 인덱스를 가지고 있다는 시나리오에서, 넌클러스트 인덱스는 데이터에 대한 포인터로서 클러스터 인덱스를 사용할 수 있다. 이러한 이유로 클러스터 인덱스 키 값은 최소 길이로 유지되어야 한다. 키가 클수록, 열이 클수록, 한 페이지로 구성할 수 있는 열의 개수가 작아지며, 좀 더 많은 페이지가 필요하고, 페이지를 읽기 위해 보다 많은 I/O를 발생시킨다. 그리고 새로운 페이지가 발생되기 때문에 두 번째에는 캐시에서 발견되는 계획과 페이지는 보다 적을 것이다. 이 모든 것들은 사용되는 SQL 서버와 시스템 리소스차원에서 큰 영향을 주며, 성능 저하의 주요 요소이다.

하나의 테이블은 오직 하나의 클러스터 인덱스만 가질 수 있으므로 인덱스를 위한 컬럼 선택에 신중을 기해야 한다. 일반적으로 클러스터 인덱스를 생성하는 가장 이상적인 방법은 다음 중 하나일 것이다.

클러스터 인덱스는 자동 증가 컬럼(가령, identity 컬럼)에서도 고려될 수가 있다. 이 것은 페이지 분할을 최소화하고 성능향상을 위해 버퍼 캐시에 입력된 페이지를 유지하기 위한 것이다. 클러스터 인덱스를 여러 컬럼으로 구성할 때, 컬럼 선택에 주의해야 한다. 통계는 오직 복합(다중) 인덱스의 첫 번째 컬럼을 위해 생성될 것이다. 쿼리 최적화에 다른 컬럼 값의 배포에 대한 정보를 제공하기 위하여, Transact-SQL 문의 CREATE STATITICS문을 사용하여 다른 컬럼의 통계정보를 만드는 것을 고려해야 한다.

쓰기작업이 자주 일어나는 운영 서버에서는 생성되는 넌클러스터 인덱스의 수를 제한해야 한다. 이 이유는 넌클러스터 인덱스는 데이터에 대한 포인터를 가지고 있다는 것이다. 테이블에 데이터 추가와 삭제 시, SQL 서버는 작업을 수행하고 로그를 남길 뿐만 아니라, 연관된 넌클러스트 인덱스를 변경해야 한다. 이것은 성능에 부작용으로 나타난다.

복합(Composite) 인덱스와 커버링(Covering) 인덱스

DBA는 사용자의 요구에 맞는 검색 범위를 수용할 수 있도록 인덱스를 생성해야 한다. 사용되지 않는 인 덱스는 무용지물이며, 사실, 인덱스를 유지하기 위한 처리 작업에 의해서도 성능이 감소될 수 있다. 가능한 여러 요구사항을 충족시키기 위하여 복합(다중) 인덱스를 생성해야 한다. DBA는 커버링 인덱스를 이용하여 성능 향상을 꾀할 수 있다.

커버링 인덱스는 인덱스의 잎수준(키와 포인터를 포함하여)에서 사용자가 요구하는 모든 정보를 포함하는 넌클러스터 인덱스이다. DBA는 인덱스 키에 너무 많은 컬럼을 추가하여 테이블을 재 생성하면 안 된다. 커버링 인덱스는 성능을 극적으로 향상 시킬 수 있다. 넌클러스터 인덱스는 특정한 레코드를 찾는 검색 시 유리하다. 테이블 조인 성능을 향상시키기 위하여 키 칼럼을 외래키(foreign key)로 하는 것처럼, 자주 집계화되는 칼럼은 인덱스로 구성한다.

분리된 컨트롤러를 가진 분리된 디스크에 존재하는?tempdb?데이터베이스가 존재하는 상황에서는 인덱스 생성을 빠르게 하기 위해서 SORT_IN_TEMPDB문을 사용한다. 이 문장은 SQL 서버에게 중간 정렬 결과를?tempdb?데이터베이스에 저장하려고 알려 주는 것이다. 이 작업은?tempdb?데이터베이스와 최종결과를 저장할 파일그룹 사이에서 읽기와 쓰기 작업을 분리하는 것이며, 그것은 좀 더 빠른 드라이브에?tempdb가 위치할 때 성능이 향상된다. 인덱스가 인접한 익스텐트를 사용하게 될 가능성이 커지게 된다.

인덱스를 위한 공간 채우기 설정

인덱스 생성시에 인덱스 페이지를 어떻게 채울까 하는 것을 정의하는 것은 매우 중요하다. 이 채우기는 FILLFACTOR와 PAD_INDEX를 가지고 통제할 수 있다. FILLFACTOR는 각 페이지의 빈 공간 비율을 정의함에 의하여 B 트리 인덱스의 잎 수준을 위하여 채우기 정도를 결정할 수가 있다. 클러스터 인덱스에서 잎수준 페이지가 실제 데이터 페이지이다. 잎 수준 페이지를 완전히 채우는 것은 기본 설정으로 가능하다. FILLFACTOR가 높을수록 읽기 작업은 빠르게 수행할 수 있으나, 쓰기 작업은 느리게 수행된다. 읽기 작업 중심의 환경에서 높은 FILLFACTOR는 페이지 마다 좀 더 많은 레코드가 기록되어 있음을 의미하고 이로 인하여 적은 페이지와 적은 I/O가 발생되어 성능 향상을 기대할 수 있다. 역으로 쓰기 작업 중심의 환경에서 동일한 수준의 높은 FILLFACTOR는 과도한 페이지 분할(page split)을 일으키게 된다. 그리고 테이블에 할당된 페이지를 넘어서는 데이터의 조각화를 일으키게 되어 결과적으로 I/O 발생이 높아지며, 메모리 및 CPU의 자원 사용률이 높아져 성능이 저하된다. 일반적으로 인덱스 생성시에 적당한 FILLFACTOR 값을 설정 하는 것은 중요하다. 선택된 FILLFACTOR 환경에 따라, 각 데이터베이스 내에 존재하는 각 테이블에 대하여 고려할 사항이 매우 다양하지만 일반적으로 고려할 내용은 다음과 같다.

주어진 테이블의 읽기와 쓰기 작업 수는 FILLFACTOR 설정을 결정하기 위하여 사용된다. 높은 FILLFACTOR는 주로 데이터가 분석 환경에 적절하다. 낮은 FILLFACTOR는 자주 변경되는 환경에 적절하다. 높은 FILLFACTOR를 가진 테이블을 변경하면 성능이 떨어진다는 것을 기억해야 한다. 다음과 같은 사항을 고려해야 할 것이다. 대량(bulk) 변경은 정확히 언제 일어날까? 일주일에 한번, 하루에 한번, 24시간 동안 계속해서, 특정 시간 동안만? 낮은 FILLFACTOR는 좀 더 많은 페이지I/O를 요구하며 디스크 공간을 많이 요구하여 성능을 감소 시킬 수가 있다. 그러면 FILLFACTOR를 어떻게 설정해야 할까? 이 것과 많은 다른 성능 문제에 대한 답은 불행히도 "상황에 따라 다르다"라는 것이다. 일반적인 가이드라인은 위에서 제시되었으며, 역량 있는 DBA가 인덱스를 생성할 때 각종 인자를 적당히 설정함으로써 시스템의 성능을 향상시킬 수 있다. DBA는 조각화 모니터링을 하기 위하여 DBCC SHOWCONTIG 문을 사용할 수 있다. 만일 기존의 값이 너무 높거나 낮으면, 인덱스 재구축을 쉽게 결정할 수 있고 테스팅 작업을 계속 한다.

변경이 자주 발생되는 테이블에서, 잎이 아닌 인덱스의 중간 수준 페이지에 FILLFACCTOR를 적용하기 위해서 PAD_INDEX를 사용한다.

인덱스 조각화

FILLFACTOR와 PAD_INDEX 설정은 고정적이며, 시간이 지날수록 인덱스는 데이터 변경에 의하여 조각화 될 것이다. 몇몇 페이지는 다른 페이지 보다 더 채워져 있을 것이다. 몇몇 페이지는 분할 되어 새로운 페이지에 할당되고 체인으로 연결되어 새로운 페이지에 옮겨진 데이터를 가질 것이다. 이 과정은 비용이 많이 소요되고 많은 경우 새로운 페이지들은 연속적이지 못하다. 즉 같은 익스텐트에 조차 있지 못해서 다른 디스크의 다른 익스텐트에 할당되게 된다. 조각화는 두 가지 방법중의 하나로 통제 가능하다. 두 가지 방법은 인덱스를 재구축하거나 인덱스 조각모음(defragmentation)을 하는 것이다.

인덱스 재구축(rebuild)은 반드시 DROP_EXISTING 아규먼트를 가지고 CREATE INDEX 문을 사용한다. 클러스터 인덱스를 재구축할 때, 클러스터 인덱스 키 컬럼이 인덱스 재 구축전과 동일 하다면, 클러스터 인덱스를 삭제하거나 재 생성할 때 넌클러스터 인덱스를 재구축 할 필요도 없고, 데이터를 재정렬할 필요도 없다.

DBCC INDEXDEFRAG문은 인덱스의 잎?지의 재정렬을 수행하여 페이지의 논리적인 정렬을 페이지의 물리적인 정렬과 맞출 수 있다. DBCC INDEXDEFRAG는 또한 페이지에 존재하는 레코드를 완전히 채우기 위하여 기존의 FILLFACTOR를 적용하는 것을 시도할 수가 있다. 다른 프로세스와 비교하여, 이 명령을 사용하는 주요 장점은 온라인 작업이 가능하다는 것이며, 작업을 진행하는 동안에도 사용자가 인덱스를 사용할 수 있다는 것이다.

통계

통계는 컬럼에 있는 키 값에 대한 배포 정보를 저장한다. 쿼리 프로세서는 주어진 쿼리를 어떻게 처리할 것인가를 결정할 때 통계 정보를 사용한다. 기본적으로, 통계는 데이터를 가지고 있는 테이블에 인덱스가 생성될 때 인덱스 키의 첫 번째 컬럼에 자동적으로 생성된다. 통계는 다른 컬럼의 키와 인덱스와 연관이 없는 컬럼에도 생성이 될 수 있다. 이 과정은 SQL 서버가 데이터 분포에 대한 좀 더 많은 정보를 제공한다. 그리하여 좀 더 효율적인 실행 계획이 선택되고 생성되게 된다. 이런 형태의 통계는 ALTER DATABASE문의 옵션을 설정하거나 sp_dboption을 이용하여 자동으로 설정하거나, 또는 CREATE STATISTICS문을 사용하여 수동으로 생성할 수 있다. 통계는 sysindexes 테이블의 바이너리 statblob 컬럼에서 찾을 수가 있으며 DBCC SHOW_STATISTICS문을 사용하여 볼 수 있다. 기본적으로 SQL 서버는 통계를 자동적으로 생성한다.

통계의 유용성은 정확도에 달려 있다. 기간이 지난 통계는 비 효율적인 계획이 산출될 수 있게 한다. 그리고 이것은 성능에 영향을 줄 것이다. SQL 서버 2000은 성능에 영향을 미치지 않도록 하기 위해서 자동적으로 모든 통계 정보를 업데이트 한다.

인덱스와 통계 추천사항

인덱스는 성능을 향상시키고 레코드의 유일성을 유지하기 위하여 생성한다. 시간이 지날수록, DBA는 데이터베이스 운영 과정을 분석함으로써 인덱스를 재구축하거나 조각모음을 할 최상의 시점을 결정할 수 있게 된다. 이 작업은 반드시 시스템환경에 의존적이며, 반복적으로 수행되므로 스크립트화하고 저장하여 관리한다. 이 작업은 가능한 한 시스템 성능에 영향을 주지 않도록 피크 시간을 피해 스케줄 작업으로 수행한다. SQL 서버가 대부분의 환경에서 자동적으로 통계정보를 업데이트하는 것을 허용하는 반면에, 모든 환경에서 잘 작동하는 것은 아니다. 만일 환경에 대한 통계정보 업데이트가 응용 프로그램이 요구하는 만큼 잘 되지 않는다면, 그 것은 성능과 잠재적인 가용성에 영향을 줄 것이다. 통계를 수동?야 하며, auto update stats 파라미터는 반드시 데이터베이스를 위하여 비활성화 되어있음.

백업과 복구

모든 데이터 복구계획을 가지고 있어야 한다. 백업과 복구 계획은 실제 운영 서버를 백업하여 실제와 동일한 상태로 철저히 테스트하고 문서화해야 한요소를 포함한, 전체 시스템을 기록해야 한다. 가능한 모든 장애 시나리오를 고려하고, 기록한다. 테스트는 반드시 규칙적으로 수행되어야 한다. 계획의 상세 정도는 시스템 환경에 따라 다르다. 다음은 DBA가 계획을 수립할 때 고려할 사항이다.

가용성 요구사항은 서비스 수준 유지에 기술되어 있다(8장 참조). 가용성의 목표와 지시사항을 충족 시키기 위하여 서비스 수준 유지를 검토해야 한다.

비용과 리소스는 중요하다. 시스템이 얼마나 다운될까? 어느 정도의 데이터가 유실되어도 되는가? 기업은 DBA를 가지고 있는가? DBA는 적절히 교육을 받았는가? 복구작업을 수행하기 위해 교육된 별도의 DBA가 있는가? DBA가 얼마의 비용을 장비 및 소프트웨어와 교육을 위해 할당할 수가 있는가?

시스템환경을 통하여 그 환경에 속한 사람들, 처리절차, 프로토콜과 수행된 백업 타입, 백업 스케줄, 사용된 복구 모델에 대한 정보를 얻을 수 있다.

데이터 보장 정책의 구성으로서 백업과 복구에 대해 생각해야 한다.

SQL 서버 2000은 시스템과 사용자 데이터베이스를 백업하고 복구하는데 필요한 도구를 제공한다. 이 도구는 엔터프라이즈 관리자,데이터베이스 유지 계획 마법사 그리고 BACKUP 과 RESTORE Transact-SQL 커맨드이다.

뜻밖의 실수를 막거나 허가되지 않은 접근을 막기 위하여 보안수준을 설정하기 위하여, DBA는 백업 셋 패스워드와 미디어 셋 패스워드를 사용하는 것을 고려해야 한다. 백업 셋 패스워드는 백업 셋을 허가되지 않은 자가 복구하는 것을 방지한다. 미디어 셋은 미디구를 막는다. 패스워드는 또한 미디어 자체에 대한 보안을 강화한다.

백업의 타입

백업의 종류에는 전체(full), 차등(differential), 트랜잭션(transaction) 로그, 그리고 파일/파일그룹(file/filegroup)과 같이 여러 가지 방법이 있다. 또한 복구 모델에도 단순(Simple), 대량로그(bulk-logged), 그리고 전체(full)와 같은 여러 가지 방법이 있다.

전체 백업

디폴트 설정은 전체백업이며 모든 다른 백업의 시작점이다. 전체 백업은 파일에서 할당되지 않은 익스텐트를 제외하고 트랜잭션 로그에 있는 모든 엔트리를 포함한 전체 데이터베이스를 포함한다. 페이지 수행 속도를 증가시키기 위하여 디스크로부터 직접 읽는다.

전체 데이터베이스 백업은 시스템과 사용자 정의 데이터베이스에서 주기적으로(이 장 끝 부분의 관리 계획 일정) 수행되어야 한다. Master와 msdb 데이터베이스는 데이터베이스에 변경이 발생되는 모든 시점에서 백업되어야 한다. 데이터베이스가 생성/변경되거나, 로그인 변경, 연결된 서버 변경, 구성변경 등의 작업이 이루어지면 master 데이터베이스는 백업이 되어야 한다. 작업, 경고, 작업자, 스케줄 등이 생성되거나 변경될 때에는 msdb를 백업 받아야 한다. 만일 서버가 배포 역할을 하게 될 때, distribution 데이터베이스를 백업해야 한다. model데이터베이스는 model 데이터베이스에 큰 변화가 생길 시에 역시 백업 받아야 한다.

데이터베이스 생성 시에 사용자 데이터베이스의 전체 백업은 복구작업의 시작점이 된다?? 동작시킨다. 스케줄은 시스템 환경에 달려있다.(이 장의 관리자 스케줄을 참조)

차등 백업

차등백업은 마지막 전체 백업 후에 변경된 모든 데이터를 포함한다. 차등 백업은 백업 뿐만 아니라 복구 속도를 향상시킨다. 오직 변경되거나 새로 할당된 익스텐트(bitmap tracking)만 캡쳐되기 때문에, 차등 백업은 전체 백업 보다 빠르며 크기도 작다. 또한 복구과정에서 마지막 차등 백업은 개개의 트랜잭션 로그백업 또는 마지막 전체 백업과 마지막 차등 백업 사이에 발생된 이전의 차등 백업이 없이 복구될 수 있다.

트랜잭션 로그 백업

트랜잭션 로그 백업은 데이터베이스 변경 내역을 저장한다. 트랜잭션 로그는 연속적으로 변경 내역을 저장한다. 트랜잭션 로그 백업은 데이터베이스 내에서 발생되는 트랜잭션의 기록을 제공한다. 트랜잭션 로그 백업은 데이터베이스를 최대한 복구하기 위하여STOPAT과 STOPATMARK 또는 STOPBEFOREMARK를 사용하여 복구과정에 사용한다. 트랜잭션 로그 백업은 데이터베이스에는 반영되지 않았으나 변경을 커밋하기 위한 롤 포워드(redo)와 커밋되지 않은 트랜잭션을 롤백(undo)함으로써 데이터를 복구할 수 있다. 로그 백업은 전체백업과 차등백업 보다 더 작으며 더 자주 수행되어야 한다.

데이터베이스 복구

사용자 또는 응용 프로그램 에러를 바로잡기 위하여 데이터베이스 가지 방법이 있다. 차등 또는 트랜잭션 로그 백업한 데이터베?로 돌리기 위해서 WITH RECOVERY 옵션을 사용할 수 있다. 트랜잭션 로그 백업으로 작업을 할 때, 데이터베이스는 지정 시점(point-in-time) 또는 표시된 트랜잭션(marked transaction) 까지 복구가 가능하다.

지정 시간 복구

지정 시간 복구는 오직 트랜잭션 로그 백업 상태에서만 가능하다. DBA는 데이터베이스를 복구하기 위해 날짜와 시간을 정하여 RESTORE 의 STOPAT 아규먼트로 사용할 수 있다. 많은 데이터베이스는 서로 다른 표준시간 대에서 운영이 된다. DBA가 사용자로부터 에러를 발생한 정확한 날짜와 시간을 알아내는 것은 필수적이다. STOPAT옵션은 정확하지 않은 데이터를 테스트하기 위하여 NORECOVERY 옵션과 함께 사용할 수가 없다. 그러므로 정확한 시간이 필요하다. RESTORE 문에 기술된 날짜와 시간 이전에 커밋되지 않은 트랜잭션은 롤백될 것이며 이는 데이터의 손실을 초래한다.

표시된 트랜잭션은 DBA에게 잘못된 트랜잭션이 발생될 때를 결정하는 데에 있어 유있다. 트랜잭션은 BEGIN TRAN문에 이름을 가지고 그 이름은 WITH MARK 아규먼트를 이용하여 로그에 저장이 된다. 만일 DBA가 잘못된 문장으로부터 복구할 필요가 있으면, DBA는 데이터베이스에 문장을 적용하거나 적용하지 않기를 위하여 STOPBEFOREMARK 또는 STOPAFTERMARK을 이용할 수가 있다. STOPBEFOREMARK 아규먼트는 복구 시에 표시된 트랜잭션을 포함하지는 않는다. STOPAFTERMARK는 복구 시에 표시된 트랜잭션을 포함한다. 전에 커밋되지 않은 트랜잭션 또는 다음의 표시된 마크는(옵션 선택 여부에 따라) 데이터베이스에 반영되지 않는다.

로그 공간은 자동적으로 증가되도록 설정되어야 하며 사용된 로그 공간의 양은 계속하여 스크립트나 감사 테이블 또는 Object - SQL Server: Databases Counter: Percent Log Used 의 성능 상태 경고를 모니터링 해야 한다. 만일 트랜잭션 로그가 꽉 차게 되면, 데이터베이스의 모든 행위는 로그가 삭제되거나 로그사이즈가 커질 때 까지 중단된다. 로그 파일이 꽉 차게 되면, BACKUP LOG문을 이용하여 로그를 삭제하거나 ALTER DATABASE 문을 이용하여 로그 파일의 사이즈를 증가시켜야 한다 (로그파일을 추가할 수도 있다). 필요하다면 로그 파일을 추후에 축소 시킬 수도 있다. 만일 다른 작업이 용이하지 않다면, 로그를 BACKUP LOG문을 NO_LOG 또는 TRUNCATE_LOG 아규먼트fmf 사용하여 지워야 한다. 전체 데이터베이스 백업은 로그를 삭제한 후에 데이터 손실을 최소화하기 위하여 즉시 이루어 져야 한다. 왜냐하면, 로그는 더 이상 커밋된 트랜잭션을 포함하고 있지 않기 때문이다.

트랜잭션 로그는 실제 데이터와 별개로 구분된 내결함성 드라이브에 위치시켜 성능을 향상시킬 수 있다. 왜냐하면 로그파일에 쓰는 작업은 연속적으로 이루어 지며 데이터 파일에 쓰는 작업은 보통 파일의 전 페이지를 통하여 불규칙하게 이루어 지기 때문이다. 게다가 데이터 파일로부터 로그 파일을 분리하는 것은 데이터 파일이 손실된 상황에서도 여전히 로그는 저장될 수 있기 때문에 데이터 손실을 줄여 준다.

트랜잭션 로그 백업을 자주하여 데이터 손실을 줄일 수 있다. 뿐만 아니라 차등 백업은 복구시간을 줄이고 데이터 손실을 줄이기 위해 사용할 수 있다.

손상된 데이터베이스를 복구하는 첫 번째 스텝은 고아(orphaned) 트랜잭션 로그 부분을 저장하는 것이다. 이것은 데이터 파일이 손상되고 master와 데이터베이스 로그가 아직 손상되지 않았을 때 가능하다. 비록 데이터베이스가 suspect상태 일지라도, DBA는 마지막 트랜잭션 로그 백업의 시점부터 데이터베이스 파일이 손상 되었을 시점까지 전체 트랜잭션 로그를 BACKUP LOG문의 NO_TRUNCATE 아규먼트 사용하여 백업할 수 있다.

복구 과정에서 복구되는 마지막 백업은 고아(orphaned) 트랜잭션 로그 백업(저장이 가능했다면)이거나 마지막 로그 백업이며, 사용 가능한 트랜잭션 로그 백업이어야 한다. 마지막 백업에 앞서 복구된 모든 백업을 위해, DBA는 NORECOVERY 아규먼트를 사용해야 한다. 제일 마지막 백업을 복구하기 위해서는, DBA는 RECOVERY사용해야 한다. NORECOVERY 아규먼트는 복구되었던 백업이 복구되는 것을 방지하여 다음의 백업이 복구 될 수 있도록 한다. 만일 트랜잭션이 한 개의 트랜잭션 로그 백업의 한 부분으로 BEGIN TRAN 문을 가지고 있고 다른 백업에 커밋 TRAN를 가지고 있다면(트랜잭션이 두 개의 로그 백업 셋에 존재한다면) , 맨 마지막에 의해 복원된 백업셋(WITH RECOVERY) 바로 전의 백업셋 복구(WITH NORECOVERY)에서는 트랜잭션이 롤 포워드되고 다음 복구 시에 반영되도록 한다.

일반적인 백업 과정은 다음과 같다.

일반적인 복구 과정은 다음과 같다.

백업 전략

전체 데이터베이스 백업은 항상 수행되어야 한다. 일반적으로 트랜잭션 로그 백업은 대부분의 경우 수행해야 한다. 이 것에 대한 예외는 변경에 대한 추적이 바람직하지 않은, 즉, 데이터의 변경이 드물거나 테스팅 환경에서이다. 전체 데이터베이스 백업 환경은 단순 복구 모델(이 장의 끝에서 기술된)을 사용한다. 차등 백업은 반드시 많은 트랜잭션을 가지고 로그 백업 또는 큰 로그 백업을 가지는 환경에서 사용된다. 파일과 파일그룹 백업 전략은 대량의 데이터를 가지고 있는 환경에서 수행될 수 있다. 엔터프라이즈 관리자를 사용하여 백업 정보를 보거나, 다양한 백업 정보를 제공하는 RESTORE 문을 사용하거나 또는 backupset 시스템 테이블을 쿼리할 수 있다. 복구에 관한 상세한 정보를 보려면 엔터프라이즈 관리자 사용하거나 restorehistory 시스템 테이블을 쿼리한다. 보안 목적을 위하여, 백업은 오프사이트에서 보관하고, 보안상 안전한 장소 또는 온사이트에 유사한 보안 구조를 구현하여 데이터를 보관한다.

복구 모델

복구모델은 트랜잭션 로그에 무엇이 저장되었나를 가리키는 것이다. 복구 모델에는 전체(full), 대량로그(bulk-logged), 단순(simple) 모델이 있다. SQL 서버 스탠다드 에디션과 엔터프라이즈 에디션의 디폴트 복구 모델은 전체 백업 모드이다. 디폴트는 model 데이터베이스에 설정된 값에 의하여 결정되며 ALTER DATABASE 문의 RECOVERY 아규먼트를 사용하여 해당 데이터베이스의 복구 모델을 변경 할 수 있으며, 이로 인해 model 데이터베이스에 변경 값이 기록된다.

전체 복구 모델

전체 복구 모델은 모든 로그 내용을 트랜잭션 로그에 기록한다. 복구는 지정 시간 또는 표시된 로그까지 가능하다. 대부분의 가동 시스템은 전체 복구 모델을 사용하다가 때때로 특정한 작업에 대한 로그의 양을 최소화하기 위하여 대량 로그 복구 모델로 바꾸어 가며 사용할 수 있다.

대량 로그 복구 모델

대량 로그 복구 모델(bulk-logged recovery model)은 대량 로드 작업과 같은 모든 대량 로그의 작업이 기록된다는 점에서 전체 복구 모델과 비슷하다. 차이점은 대량 로그 복구 모델은 특정 작업을 위해 개개의 열이 아닌 할당된 페이지만을 로그하고 유지한다는 점이다. 이것은 CREATE INDEX, SELECT INTO, BCP.EXE, BULK INSERT 그리고 text/image 작업이다. 이 들 작업 결과로 로깅되는 값은 얼마 안되며 로그파일 또한 작다. 만일 데이터 파일을 대량 로그 복구 모델로 사용하는 도중에 유??든 트랜잭션을 복구할 수 없다. 왜냐하라 데이터를 포함하는 데이터 페이지에 대한 포인터를 가지고 있기 때문이다. 이것은 대량 로그 복구 모델에서는 지정된 시점 복구를 불가능하게 하는 것이다.

대량 로그 복구 모델에서 대량 복사 (bulk-copy) 작업을 할 때 발생되는 최소 로깅을 위하여 대체될 필요가 있는 몇 가지 조건이 있다. 대상 테이블은 다음 조건을 만족시켜야 한다.

인덱스를 가지고 있는 테이블에 매우 많은 량의 데이터를 삽입할 때는 데이터를 삽입하기 전에 인덱스를 삭제하는 것이 더 효율적이다. 그리고 인덱스는 데이터를 로드한 다음 다시 생성시키면 된다. 이 방법은 데이터 로드시점에 대량의 로그가 발생되지 않도록 한다. 만약 대상테이블이 인덱스를 가지고 있고, 로드되는 데이터가 대상 테이블의 데이터 량 보다 적다면 인덱스를 유지하는 것이 더 효과적이다. 인덱스를 삭제하였다면 데이터 로드 후에 다시 인덱스를 만드는 시간이 더 걸릴 수가 있기 때문이다.

단순 복구 모델

단순 복구 모델은 전체 데이터베이스 백업과 선택적인 차등백업을 사용할 수 있다.. 그러나 트랜잭션 로그를 사용할 수 없으므로 지정 시간 복구 및 표시된 트랜잭션을 위한 복구는 사용할 수 없다. 데이터베이스는 마지막 전체 백업 또는 차등 백업 시점까지만 복원할 수 있다. 그러나 단순 복구 모델은 관리자에게 가장 쉬운 백업 방법이며 대량의 로그를 감소시켜주고, 자동적으로 로그 공간을 재사용할 수 있게 해주어 특정 대량 작업과 다른 작업의 성능을 증진시킨다. 이 모델은 응용 프로그램을 테스트하거나 사용하는 데이터가 중요하지 않은 테스트 환경에서 아주 적당하다.

복구 모델 사이의 전환

엔터프라이즈 관리자를 이용하거나 ALTER DATABASE 문을 통하여 복구 모델을 변경할 수 있다. 전체 복구 모델에서 대량 복구 모델로 변경하거나 그 반대로 하는 것은 매우 일반적인 방법이다. 이러한 전환 방법은 현재 스케줄 되어 있는 백업에 어떤 변화도 일으키지 않는다. 대량 복구 모델에서 단순 복구 모델로 전환하기 전에, DBA는 트랜잭션 로그를 백업해야 한다. 트랜잭션 로그를 백업하는 것은 장애가 일어나는 경우 트랜잭션 로그 백업 시점까지 데이터를 복구할 수 있게 만든다. 그러나, 단순 복구 모델에서 트랜잭션 로그를 백업할 수가 없으므로 DBA는 반드시 복구 모델을 변경하자마자 전체 또는 차등백업을 하고 난 후에 로그 백업을 비활성화 시킨다(단순복구 모델로 전환 시 로그 백업은 비활성화 된다). DBA는 단순 복구 모델에서 전체 백업 모델 혹은 대량 복구 모델로 전환한 후에 반드시 전체 혹은 차등 데이터베이스 백업을 수행하며 그 후에 비활성화된 로그 백업이 활성화 된다. 좀 더 추가적인 정보는 표4.2를 참조하기 바란다.

표 4.2 복구 모델 전환 시 백업 전략

에서	로	작업	설명
전체 복구	대량 복구	없음	백업 전략의 변화는 없다. 주기적인 데이터베이스, 로그 그리고 (선택적이지만) 차등 백업을 계속한다.
전체 복구	단순 복구	변경하기 전에 선택적으로 트랜잭션 로그를 백업한다.	변경 시점까지 복원을 위해 변경 전에 즉시 로그 백업을 해야 한다. 단순 복구 모델로 전환 한 후에는, 실행되고 있는 로그 백업을 중지한다.
대량 복구	전체 복구	없음	백업 전략의 변화는 없다. 특정 시점으로의 복원은 로그 백업 후에 가능하다. 만일 특정 시점에서의 복원이 중요하다면, 전환 후에 즉시 로그 백업을 수행한다
대량 복구	단순 복구	변경하기 전에 트랜잭션 로그를 선택적으로 백업한다.	변경 작업 전에 즉시 로그 백업을 하는 것으로 특정 시점까지 복원하는 것이 가능하다. 단순 복구 모델로 변경 후에 실행되는 로그 백업을 중지한다.
단순 복구	전체 복구	변경 후에 데이터베이스 백업을 한다.	전체 복구 모델로 전환된 후 전체 데이터베이스 백업 또는 차등 백업을 수행한다. 주기적인 데이터베이스, 로그 그리고 (선택적이지만) 차등 백업 수행을 시작한다.
단순 복구	대량 복구	변경 후에 데이터베이스 백업을 한다.	대량 복구 모델로 전환 후 전체 데이터베이스 백업 또는 차등 백업을 수행한다. 주기적인 데이터베이스, 로그, (선택적이지만) 차등 백업 수행을 시작한다.

백업 성능

백업과 복원 작업의 성능을 향상시킬 수 있는 특정한 방법이 있다.

데이터베이스 파일을 디스크 I/O를 병렬로 증가시킬 수 있도록 여러 디스크로 분산한다. 그런 다음 다중 백업 디바이스를 이용 백업 수행 속도를 증가시키기 위하여 다중 드라이브에 또는 테이프 드라이브로 확장할 수 있다. 스트라이프된 백업 셋이 생성될 때에는, 모든 백업 디바이스를 위해서 동일한 미디어 타입이 사용되어야 한다. 디스크 드라이브는 테이프보다 훨씬 빠르며 테이프 백업은 SQL 서버에 물리적으로 장착이 되어야만 가능하다. 많은 DBA는 속도를 증가시키기 위하여 직접 디스크에 백업을 생성한다. 그런 다음 3rd 파티 도구를 사용하여 백업 파일을 오프사이트로 저장하기 위해 테이프로 복사한다. 백업 데이터의 크기와 시간을 최소화하기 위하여 요즘 출시되는 새로운 테이프 드라이브는 자체적으로 하드웨어에 데이터 압축기능을 가지고 있다.

DBA는 반드시 최적의 데이터베이스 백업 성능을 구성할 수 있도록 다양한 하드웨어 구성 테스트를 철저히 수행한다. 동일한 스카시 컨트롤러로 디스크와 테이프를 공유하지 않는 것이 최선이다. 또한, 테이프 드라이브에 연결된 스카시 채널의 용량을 넘지 않도록 주의해야 한다.

분할미러(Split-mirror)와 스냅샷(snapshot)백업은 백업과 복원 작업 속도를 증진시킬 수 있는 또 다른 방법이다. 좀 더 자세한 설명을 보기 위해, 이 장 끝의 고급 관리 섹션을 참조한다.

마이크로소프트는 백업과 복원 소프트웨어를 제공하는 다양한 3rd 파티 업체들과 긴밀히 일하고 있다. 3rd 파티 도구는 DBA가 여러 제품과 운영 환경을 고려해 중앙화 집중화된 백업 계획을 수립할 수 있도록 한다. 게다가, 백업을 위한 VDI(Virtual Device Interface)는 데이터를 복사할 때 발생하는 부하를 감소시키고 수행 속도를 빠르게 하기 위해 공유 메모리 구조를 사용하면서 3rd 파티 백업 소프트웨어 제품으로 전송되고 전송 받을 수 있게 한다. 웹사이트에서 이 것과 관련된 업체에 대한 링크 정보를 얻으려면 이 장 끝에 추가된 링크 정보를 참조하기 바란다.

백업 검증

백업 프로세스와 백업 데이터에 대한 신뢰성을 테스트 할 수 있는 몇 가지 방법이 있다.

일반적인 방법은 대기서버(standby)를 이용하는 것이다. 백업은 운영 서버에서 이루어진 후에 대기 서버에 적용되어야 한다. 대기서버에서 데이터에 대한 검사를 하기 위해 DBCC 커맨드(가령 DBCC CHECKDB와 같은)를 사용할 수 있다. DBA는 백업이 제대로 수행되었는지, 백업 미디어가 손상되지 않았는지 그리고 백업에 포함된 데이터가 손상(corruption) 되지 않았는지를 확인할 수 있다.

DBA는 백업 자체를 테스트 하기 위하여 RESTORE VERIFYONLY를 수행하여 모든 파일이 존재하고 읽을 수 있는 상태인지 확인하기 위해 백업 디바이스를 검사한다.

자동화

SQL 서버 2000 환경에서의 자동화는 DBA가 매일의 유지 관리 활동에 대해 걱정하는 대신, 비즈니스 요구에 시간과 에너지를 집중시키고 새로운 기술을 비즈니스 모델로 접목시킬 수 있게 한다.

자동화 프로세스의 주요 구성요소는 SQL 서버 에이전트이다. 이 에이전트는 SQL 서버 2000의 스케줄링 구성요소이다. 에이전트를 사용하여, DBA는 다음과 같은 자동화되고 프로액티브한 환경을 구축하기 위해 작업(job), 경고(alert), 운영자(operator)를 생성할 수 있다.

DBA에게 SQL 서버 에이전트의 구성요소, 스크립트,저장 프로시저, 트리거 그리고 테이블을 연계하여 사용하는 것은 시스템환경을 유지 관리하는 데 있어 강력한 도구이다.

작업

작업은 모든 운영관리를 위해 생성되고 스케줄 되어야 한다. 알림은 작업 프로세스의 한 부분이다. 너무 많은 전자메일을 보내는 것을 막기 위하여, 알림 작업이 실패되었을 때로 제한 되어야 한다. 전자메일과 호출기 알림에 더불어, net send 알림도 전자메일이 실패되는 경우를 대비하여 설정해야 한다. 작업이 여러 번 수행될 때는 하나의 작업을 만들고 해당 작업을 위해 여러 스케줄을 만드는 것이 좋다.

DBA가 여러 SQL 서버를 책임지고 있는 상황이라면 마스터 서버와 다중 대상 서버로 구성된 멀티 서버 관리 모델을 생성하는 것을 고려해야 한다. 마스터용된다. 나열된 대상 서버는 주기적으로 마스터 서버에 연결되고 해당 서버에 지정된 작업을 다운로드 한다. 대상 서버는 지정된 스케줄에 기초해 작업을 수행하고 마스터 서버로 상태 보고를 한다. 다중 서버 작업은 오직 마스터 서버 정의와 단계만을 볼 수 있다. 이것은 다른 관리자가 작업 단계와 스케줄을 수정하거나 작업을 비활성화 시키는 것을 방지한다.

경고

경고는 이벤트에 응답하기 위해 생성되거나 SQL 서버의 임계값을 사용하여 설정될 수 있다. 이들 경고는 발생하거나 감지될 수 있는 이벤트를 다루기 위해 사용된다. 경고는 일반적으로 시스템 교정 작업을 수행하기 위한 목적으로 디자인 되었다. 그리고 DBA에게 이벤트가 발생되었고 이벤트를 처리하기 위해 교정 작업이 수행되었음을 알리기 위한 목적도 가지고 있다.

경고에는 두 가지 타입이 있다. 하나는 이벤트로 인한 것이고 다른 하나는 임계 값(threshold)을 정의한 것이다. 이벤트 경고는 윈도우2000 응용 프로그램 이벤트 로그에 쓰여지는 이벤트를 요구한다. 임계값 경고는 DBA가 특정한 시스템 모니터 카운터와 인스턴스를 위한 임계값을 정의할 수 있도록 한다.

심각도19에서 25를 가진 이벤트는 심각한 이벤트로 고려되며 경우에 따라서는 SQL 서버를 재 시작해야 한다. 마이크로소프트는 모든 데이터베이스에 사용할 수 있는 각 이벤트 수준에 대한 샘플 경고를 제공한다. 이것은 최소한 DBA가 필요한 운영자에게 경고 정의시의 한 부분인 알림 정보를 제공하는 것을 추천한다. 모든 경고는 반드시 적당한 포맷과 반환되는 메시지로 표준화 되어야 한다. 운영자에게 알려질 때, 단독 운영자 대신에 그룹 운영자에게 알릴 수 있도록 SQL 서버를 구성해야 한다. DBA가 운영자에게 연결 실패 시를 고려하여 또 다른 운영자를 생성하는 것도 추천된다. DBA는 우선순위가 높은 이벤트 발생시 적절한 알림을 확실히 하기 위해 전자메일 응용 프로그램에서도 적당한 규칙을 설정해야 한다. DBA는 또한 추가적인 정보를 테이블에 저장하고 싶을 지도 모른다. 그런 다음 추가적인 정보를 운영자나 그룹에 제공하기 위하여 트리거가 xp_sendmail을 실행하도록 한다.

DBA가 다중 서버로 구성된 SQL 서버를 운영하고 있는 경우, DBA는 운영되는 모든 SQL 서버에서 발생되는 이벤트에 응답하기 위해서 중앙화 집중적인 이벤트 처리 서버를 생성하는 것을 신중히 고려해야 한다.

설치와 사전 대응책에 대한 추가적인 정보를 위하여, SQL 서버 온라인 설명서의 "이벤트 관리" 부분을 참조한다.

데이터 이동

이 섹션은 데이터를 이동하기 위한 여러 가지 최선의 방법을 설명하고 있다.

데이터 변환 서비스(Data Transformation Services)

DTS는 DBA가 관계형과 비관계형 데이터 모두를 가져오기(import), 내보내기(export)하고 변경할 수 있는 SQL 서버 2000 구성요소 중 하나이다. DTS의 두 가지 주요 구성요소는 DTS 데이터 펌프(Data Pump)와 OLE-DB이다. DTS 데이터 펌프는 데이터의 연결과 변경을 가능하게 하는 인터페이스와 방법을 제공하는 엔진이다. OLE-DB는 마이크로소프트의 유니버셜 데이터 액세스 구성요소(Universal Data Access component)이다. 그리고 이것은 DBA가 OLE-DB 프로바이더를 통하여 다양한 형태에 데이터 접근 및 작업을 가능하다.

DTS는 시스템 사이에서 데이터를 이동하기 위하여 강력한 추출, 변환과 통합 도구 셋을 제공한다. 이 도구는 파일에서 테이블로 데이터를 쉽게 이동시키는 방법부터, 새로운 비즈니스 레코드, 데이터, 테이블 그리고 분석 서비스에서 큐브의 증가되는 업데이트를 수행하는 것을 포함하여 좀 더 복잡하고 자동화된 데이터웨어하우징 변환에 이르기 까지 많은 DBA와 관련된 기능을 위해 사용된다.

DTS 마법사는 간단한 변환을 생성하기 위해 사용된다. 그리고 DTS 디자이너는 좀 더 복잡한 변환을 위해 사용되어야 한다. 변환 프로세스의 마지막 결과는 DTS 패키지이다. DTS 패키지는 연결, 작업, 변환 그리고 워크플로우로 구성되어 있다.

패키지는 여러 형태로 저장될 수 있다. 데이터 계보(data lineage, 데이터 흐름에 대한 기록)를 요구하거나 다른 응용 프로그램과 메타 데이터를 공유하는 변환에 있어서, 패키지는 SQL 서버 2000내에 마이크로소프트 메타 데이터 서비스에 저장 되어야 한다. 다중 서버에서 운영되는 변형을 위해서는, 패키지는 COM(Component Object Model) 구조 저장 파일(.dts)로 저장되어야 한다. 패키지는 개발자들이 DTS 코드를 응용 프로그램에서 사용할 수 있도록 하기 위해서는 비쥬얼베이직 파일(.bas)로 저장한다.

DTS 연결 작업

DTS는 DBA가 여러 가지 연결 작업을 가능하게 한다. DBA는 ODBC (Open Data Base Connectivity) 또는OLE-DB(Object Linking and Embedding Data Base ) 소스로부터 데이터를 옮기거나 변형시킬 수 있다. DBA에 의하여 사용되는 좀 더 일반적인 DTS 작업은 다음과 같다.

데이터 변환 작업은 데이터를 이동하고 다루는데 있어 아주 효과적이다. 다음은 몇 가지 장점이다.

SQL 실행 작업은 DBA가 패키지의 로직에 Transact-SQL scripts를 포함할 수 있다. 예를 들어, DBA는 쉽게 DTS 패키지를 생성할 수가 있으며 스케줄이 가능하다. 그래서 비즈니스 테이블로부터 특정 일수보다 오래된 레코드를 옮기는 작업, 이 들 데이터를 이력 테이블로 삽입하는 작업 그리고 감사 테이블에 프로세스에 대한 상세한 정보를 포함시키는 작업을 수행할 수가 있다. 모든 작업이 완벽하게 하나의 단위로서 수행되었다는 것을 보장하기 위해서, DBA 는 패키지 내에 SQL 작업을 하나의 트랜잭션 로직으로 동작하게 구성할 수 있다.

대량 삽입 작업은 DBA가 SQL 서버 테이블에 아주 많은 양의 file (.txt, .csv, etc..) 데이터를 빠르게 가져올(import) 수 있다. 그 작업은 Transact-SQL bulk insert 문으로 캡슐화 되어 있다. DBA는 작업속도를 향상시키기 위해 작업 전에 SQL 서버에 있는 디렉터리로 텍스트 파일을 반드시 복사해야 한다.

SQL 서버 개체 복사 작업은 DBA가 하나의 SQL 서버 데이터베이스에서 다른 데이터베이스로 개체를 쉽게 이전할 수 있도록 한다. 스크립트는 전체 작업을 위해 디스크에 쓰여진다. DBA는 에러를 추적하기 위해 원본과 대상 서버에 있는 .log파일을 검사해야 한다.

데이터베이스 전송 작업은 DBA가 한 서버에서 다른 서버로 데이터베이스를 쉽게 이전하게 해준다. 데이터베이스는 이동될 수도 있고 복사될 수도 있으며 목적지 데이터베이스 파일의 위치도 변경할 수 있다.

로그인 전송 작업은 DBA가 하나의SQL 서버로부터 다른 서버로 로그인을 쉽게 이전하게 해준다. 전송작업을 위하여 필요한 원본과 목적지 버전정보를 확인하기 위해서는 SQL 서버 온라인 설명서를 참조한다.

복제

복제는 데이터를 이동하기 위해 사용되는 또 다른 기술이다. 데이터를 배포하기 위하여 자주 사용하는 복제의 두 가지 타입은 스냅샷(snapshot) 복제와 트랜잭션 복제이다. 이러한 복제 방법의 선택은 시스템 환경의 요구 및 제약 사항에 따라 달라진다.

스냅샷 복제는 주기적으로 대량 데이터를 동기화하는 것이다. 게시 부분으로 변경된 데이터가 아니라 모든 데이터가 구독자에게 이전된다. 스냅샷 복제는 다음 상황에서 사용될 때 가장 좋은 방법이다.

트랜잭션 복제는 구독자에게 변경 사항만 전송한다. 복제가 처음 실행될 때 데이터의 스냅샷이 구독자에게 보내진다. 게시자에서 변경되었을 때, 복제를 위해 표시하고, 저장소에 복사하며, 기본적으로 distribution 데이터베이스에 보내지고 구독자에게 적용된다.

트랜잭션 복제는 다음과 같은 환경에서 사용하는 것이 가장 좋다.

복제 지연을 초래하는 주요인

규칙적으로 다른 서버에 최신 데이터 복사 본을 배포하기 위해서는 스냅샷 복제를 사용한다. 변경 사항이 발생될 때에(약간의 지연은 허용) 다른 서버에 배포된 데이터에 수정을 하기 위한 경우라면, 트랜잭션 복제를 사용한다. 다른 서버(지연이 허용 안됨)에 즉시 모든 변경이 반영되어야 하는 상황에서는, DTC(distributed transaction coordinator )과 분산 트랜잭션을 함께 사용해야 한다.

BCP 와BULK INSERT

복사 프로그램(BCP)와 BULK INSERT T-SQL 문은 파일과 테이블에서 또는 파일과 테이블로 대용량의 데이터를 이전하기 위해 사용된다. BCP는 .cmd와 .bat 파일로 통합되기 쉬운 명령어이다.

BULK INSERT 문은 스크립트와 저장 프로시저로 쉽게 통합되어 사용할 수 있다. BULK INSERT 문은 단 방향 데이터 이동(오직 import만) 제약조건을 가진다. 데이터 이동 속도를 증가시키고 서버 리소스를 최소화하기 위하여, 큰 배치 사이즈를 가진 작업 시에는 최소로 로깅된 작업을 사용하는 것을 고려해야 한다.

좀 더 자세한 정보를 위해서는, SQL 서버 온라인 설명서의 "로깅되거나 최소로 로깅된 대량 복사 작업"과 "대량 복사 성능 최적화"를 참조한다.

연결된 서버

연결된 서버(Linked severs)는 DBA가 다른 시스템에 있는 데이터를 검색하고 취급할 수 있는 능력을 제공한다. 관계형과 비관계형 소스 데이터 모두가 사용 가능하다. SELECT INTO, INSERT SELECT, INSERT EXEC를 사용하여, DBA는 매우 쉽게 조인을 사용하고 여러 소스로부터 데이터를 목적 SQL 서버 테이블로 옮길 수 있다.

로그 전달

이 것에 대한 자세한 사항은, 이 장

데이터를 이동하기 위해 백업과 복원을 사용

SQL 서버 백업과 복원 프로세스는 서버 사이의 데이터를 이동하기 위해 사용될 수 있다. 하나의SQL 서버에서 백업한 데이터베이스를 다른 SQL 서버에서 복원할 수 있다.

데이터베이스 분리 및 연결

하나의 SQL 서버에서 다른 서버로 데이터베이스를 복사하거나 옮기는 다른 방법은 분리/연결(detach/attach) 프로세스를 쓰는 것이다. 엔터프라이즈 관리자의 복사 데이터베이스 관리자, DTS 전송 데이터베이스 작업, 또는 저장 프로시저 sp_detach_db와 sp_attach_db를 사용하여, DBA는 쉽고 빠르게 서버 사이에서 데이터베이스를 이동할 수 있다.

데이터 이동 전략 비교

SQL 서버 2000에서 데이터를 이동시키는 많은 기술 중 하나를 선택할 때, DBA는 반드시 운영관리 요구사항과 시스템 환경을 고려해야 한다.

데이터베이스 이동

전체의 데이터베이스를 이동하기 위하여, DBA가 전체 백업과 복원하는 것을 추천한다. 그러나 몇 가지 경우에선 분리/연결(detach/attach) 작업을 하는 것이 더 빠르고 적절할 수도 있다. 엔터프라이즈 관리자는 연결 및 분리 프로세스를 위해 쉽게 사용 가능한 GUI 인터페이스를 제공한다. 또한 데이터 및 구조와 더불어 로그인을 전송할 수 있는 복사 데이터베이스 마법사를 사용할 수 있다.

로그인 동기화 유지

데이터베이스 이동 후에, 로그인은 반드시 원본(source )서버에서 대상(destination) 서버로 이전되어야 한다. 로그인은 스크립트화되거나 DTS 로그인 전송 작업이 사용될 수 있다. 대상 서버에서 서버 계정과 데이터베이스 사용자 계정을 동기화 시키기 위하여 sp_change_users_login와 sp_resolve_logins를 사용한다.

추가적인 정보를 위해서, 3장의 로그인계정과 다른 SQL서버로부터 복원한 사용자에 대한 섹션을 참조한다.

작거나 많은 량의 데이터 이동/가져오기/내보내기

텍스트 파일로부터 많은 양의 데이터를 가져오기 위해서, T-SQL Bulk Insert 문 또는DTS 대량 삽입 작업을 사용한다. 잦은 조인과 다중 소스로부터 작은 양의 데이터를 가져오기 위해서, 연결된 서버를 사용하고 적당한 T-SQL문을 사용한다. 테이블로부터 대량의 데이터를 내보내기 위해서, bcp.exe CmdExec 유틸리티를 사용한다. 변형될 데이터가 적당히 작은 양이라면, DTS 데이터 변환 작업을 사용한다.

서비스의 시작과 정지

윈도우 2000에서, SQL 서버와 다른 몇 가지 관련된 구성요소는 서비스로서 수행된다. 몇 가지 서비스는 다음과 같다.

서비스에 의거하여, 이들 서비스는 다양한 도구를 가지고 시작 및 정지 될 수 있다. 다양한 도구는 다음과 같다.

SQL 서버 서비스 시작은 사용자가 데이터베이스에 쿼리문을 실행할 수 있도록 한다. SQL 서버 서비스 일시 중지는 서버에 새로운 연결을 막지만 수행중인 문장을 끝마칠 수 있도록 기존 연결은 가능하게 한다. SQL 서버 서비스 중단은 서버에 로그인 하는 것을 불가능하게 하며, 현재 수행되는 트랜잭션을 마치도록 한다. 그리고 하드 드라이브 캐시를 동기화함으로써(서비스 시작 시에 데이터베이스를 복원하는 데 필요한 작업과 시간의 양을 최소화 하기 위해) 모든 데이터베이스에 있는 체크포인트를 수행한다.

SQL 서버 서비스의 시작,일시 중지와 정지는 가능할 때 마다 엔터프라이즈 관리자를 통하여 수행할 수 있다. 엔터프라이즈 관리자가 응답이 없거나 서비스 계정을 위한 도메인 패스워드 또는 계정이 변경되었을 경우에는, 서비스 정보는 반드시 수정되어야 하며 서비스 애플릿을 이용하여 시작되어야 한다. 그런 다음 엔터프라이즈 관리자에서도 변경 된다.

셧다운 되기 전에 현재 연결이 되어 있나를 체크하기 위해서는, sp_who나 엔터프라이즈 관리자에서 현재 동작을 이용한다. 연결될 수 없는 사용자를 위해 또는 블록킹이 발생되는 아주 부하가 큰 시스템에서, DBA는 KILL 문을 사용하여 블록킹된 사용장은 취소되고 롤백 될 것이다. DBA는 DBCC INPUTBUFFER와 관련된 연결정보를 사용자 연결 서비스 프로세스 ID(service process ID: SPID)를 제거하기 전에 테이블에 저장하는 것이 필요할 수도 이다. 이것은 DBA가 작업이 재수행 될 필요가 있는 경우에 취소된 문장에 대한 좀 더 많은 정보를 배울 수 있도록 한다.

DBCC

데이터베이스 콘솔 명령어(DBCC: Database Console Commands)는 DBA가 다양한 관리를 하도록 하고 안정적인 SQL 서버 2000운영을 위한 작업을 하도록 도와 준다. DBCC문의 결과는 분석을 위하여 저장되어야 한다. 텍스트 파일로 결과를 저장하여, 불필요한 데이터는 삭제 후에 별도의 테이블에 저장을 하는 것이 좋다. 트리거, 스크립트, 경고, 작업과 전자메일은 프로액티브 환경을 만들기 위한 정보로 사용할 수 있다.

DBA가 수행하는 일반적인 DBCC 문은 다음과 같다.

DBCC CHECKDB는 데이터베이스 내에 있는 모든 오브젝트의 할당과 구조적 일관성을 점검하기 위하여 사용된다. 그리고 이것은 데이터베이스의 손상이 있을 때 사용되기도 한다.

DBCC SHOWCONTIG는 인덱스의 조각화 정도를 알기 위해 수행된다. 조각화는 페이지가 채워지고 분할(비효율적인 I/O의 원인)되고 수정 시에 다른 페이지들이 채워 지지 않은 상태로(좀 더 많은 I/O를 발생) 남겨질 때 성능에 나쁜 영향을 줄 수 있다.

DBCC DBREINDEX은 테이블을 위한 모든장은 또한 프라이머리 키(primary key)와 유니크 제약조건(unique constraint)에 의해 사용된 인덱스를 재구축 할 수가 있다.

DBCC INDEXDEFRAG 은 인덱스의 잎 수준의 조각모음을 위해 사용된다. 이 문장은 인덱스가 조각화되었을 때 아주 유용하다. 이것은 온라인 작업을 통해 진행 될 수 있으며 인덱스를 재 생성하는 것 보다 더 효율적으로 사용 가능하다.

DBCC SHRINKDATABASE 는 데이터베이스의 사이즈를 줄이는 데 사용된다. 이 문장은 요구되는 공간보다 데이터베이스 공간이 더 많이 할당되었을 때 유용하게 사용될 수 있다. 이와 관련된 DBCC SHRINKFILE 문은 각 파일 사이즈를 줄이는 데 사용될 수 있다. 또한 트랜잭션 로그에서도 사용 가능하다.

관리 계획 일정

기업은 데이터 환경을 관리할 때 문의하는 질문에 대하여 "상황에 따라 다르다"라는 대답을 자주 하게 된다. 어떤 도구를 사용해야 하는지? 관리자로서 어떤 작업을 해야 하는지? 운영관리 작업을 얼마나 자주 해야 하는지? 이 들과 다른 관리에 대한 문의에 대한 답이 항상 같을 수는 없다. 여기에는 많은 요인이 고려되어야 한다. 가령, 서버가 몇 대나 되는지? 응용 프로그램의 수는 몇 개인지? 데이터베이스의 수는 몇 개인지? 트랜잭션은 주어?스템에서 읽기와 쓰기 작업의 비율은 얼마인지?

DBA는 데이터 센터와 IT환경, 모든 운영관리 활동, 지원되는 응용 프로그램과 서버 시스템의 성능과 가용성 변화로 인한 문제점을 완전히 이해해야 한다.

가능할 때 마다, 유지 활동은 표준화, 스크립트화, 자동화 및 문서화 한다. 유지 활동과 DBCC 작업은 실제 운영시스템의 성능에 최령 옵션과 아규먼트는 수행하기 전에 다시 한번 평가되고 고려되어야 한다. 이 작업들은 시스템이 한가한 시간에만 이루어지도록 조치해야 한다.

일반적으로 유지관리 작업은 매일, 매주, 매월 수행하는 일로 분류될 수 있다.?시스템 상황에 따라, 추가적인 관리작업이 필요할 수도 있으며 종종 다른 작업들이 일어날수도 있고, 그렇지 않을 수도 있다.

매일 작업

다음은 매일 수행되어야 할 작업이다.

주간 작업

다음은 매주 수행되어야 하는 작업이다.

월간 작업

다음은 한 달에 한 번 수행해야 할 작업이다.

데이터베이스 유지관리 마법사

주기적인 유지관리 활동은 SQL 서버의 유지관리 계획 마법사를 사용하여 쉽게 수행할 수 있다.

유지관리 계획 마법사는 DBA가 대부분의 데이터베이스 관리 작업을 수행함에 있어 계획과 관련된 작업을 신속하게 생성할 수 있게 한다. 계획은 다중 데이터베이스 또는 단일 데이터베이스를 위하여 만들 수 있다.

다음은 수행될 수 있는 작업 목록이다.

관리 계획 일정

가용성과 성능

가용성이란 종종 사람들마다 다른 의미로 해석된다. 일반적으로 가용성 정의는 사용자가 속한 비즈니스 조직에 달려 있다. 몇몇 사람들에게는 서비스 수준 유지에 의해 쓰여진 성능이 99.999 퍼센트 가용을 의미하기도 하는 반면에 다른 사람들은 서버가 비록 느릴지라도,대부분의 시간 동안에 사용가능하고 사용자들이 큰 장애 없이 작업을 수행할 수 있는 것을 의미하기도 한다.

성능 또한 여러 가지 해석이 가능하다. 모든 응용 프로그램은 SQL 서버 파라미터 설정, 메모리 설정, 서버 하드웨어구성과 올바른 인덱스를 포함하여 실제 운영환경에 적용되기 전에 SQL 서버 최적화 작업이 필요하다.

응용 프로그램이 SQL 서버에 접근할 때 얼마나 잘 수행되는가는 사용자 그룹과 협의한 내용이 응용 프로그램 디자인 맥락과 부합되는 정도에 달려있다. 예를 들?는 것은 추천되지 않는다. 왜냐하면, 튜닝된 인덱스를 사용하지 않기 때문에, 일관된 성능을 나타낼 수 없다.

SQL 서버가 원하는 가용성과 성능을 나타내려면, DBA는 각 데이터베이스, 서버, 응용 프로그램과 시스템 환경에 대한 정해진 숫자와 퍼센트를 가지고 요구되는 가용성과 성능을 확립할 필요가 있다. 이 문서는 DBA가 모든 유지관리 작업을 향상시키고 프로액티브 하게 잠재적인 문제를 예측할 수 있는 서비스 수준 유지 정보를 생성하는데 도움이 될 것이다.

DBA는 응용 프로그램을 위한 서비스 수준 유지와 더불어서 모든 데이터베이스가 가용 하다는 것을 확신해야 한다. 가용성은 인력, 프로세스, 적절한 데이터베이스 유지관리, 여분의 하드웨어 그리고 기술 조합으로 가능해진다. SQL 2000가 높은 가용성을 유지하는 주요 기술은 로그 전달과 장애 조치(failover) 클러스터링이다.

높은 가용성 기술

이 섹션은 높은 가용성을 제공하기 위한 방법에 대하여 논할 것이다.

로그 전달(log shipping)

로그 전달은 SQL 서버 2000 엔터프라이즈 에디션의 높은 가용성을 제공한다. DBA는 주 서버와 더불어 짧은 변경 시간에 대기서버를 유지하는 과정을 자동화 할 수 있다. 이 처리과정은 SQL 서버 데이터베이스 유지관리 계획 마법사를 사용하여 구성할 수 있다. 대기 서버를 생성하는 것은 주 서버에서 트랜잭션 로그를 백업하고 난 다음 자동적으로 대기서버에 전달(복사)되어 복구된다. DBA는 백업이 얼마나 자주 일어나게 할 지와 백업과 복구 사이의 시간을 결정하면 된다. 계정 또한 대상 서버로 전송되어야 한다. 그렇지 않으면 데이터베이스는 온라인상태를 유지할 수 없다.

실제 운영서버의 실패 이벤트 발생 시, 대기 서버는 응용 프로그램이 정상적으로 운영되도록 온라인 상태를 수작업으로 설정할 수 있다. 대기 서버가 동작 한다면 운영서버가 정상화 된 후에 운영 서버로 전환할 필요가 없다. 오히려 전??할 변경에 따른 시간은 시스템환경에 달려있다. 손실될 수 있는 트랜잭션을 감소시키기 위해, DBA는 백업, 복사를 시도해야 하며 만일 운영서버에 여전히 연결 가능하다면 고아 로그(NO_TRUNCATE)를 백업받아야 한다.

로그 전달 설정

데이터베이스/서버 구성에 대한 초기 설정은 데이터베이스 유지관리 계획 마법사를 통해 이루어진다.

표 보상효과에 대한 설명이다.

파라미터	영향 받는 서버	값
유지 계획의 한 부분으로서 데이터 베이스를 백업	원본서버	디폴트로, 데이터베이스 백업 계획 다이얼로그 박스에서 선택이 된다. SQL 서버 Agent job에 다음과 같은 이름으로 생성될 것이다. "데이터베이스 유지관리 계획을 위한 데이터베이스 백업 작업 '구성된 계획 명'". 이 옵션을 선택하는 것은 데이터베이스 수도 있다.
원본 서버 이름		주 서버 이름
대상 서버 이름		로그 전달을 위한 대상 서버 이름
로그전달을 위한 데이터베이스 (주서버)	원본서버	트랜잭션 로그 파일이 만들어 질 데이터베이스
백업 파일을 저장할 디렉터리(반드시 확실한 UNC 명이어야 한다.)	원본서버 와 대상서버에 의해 접근 가능한 것
각각의 데이터베이스를 위하여 UNC 아래 서브디렉터리를 만들어야 한다.	N/A - UNC 파일 경로 '예'로 설정한다.	이것은 한 개 이상의 데이터베이스를 사용할 때 혼동을 막고 로그 전달을 위해 구성된 파일을 쉽게 찾을 수 있도록 할 것이다.
트랜잭션 로그를 삭제한다. 특정 기간 보다 오래된 파일	N/A - UNC 파일 경로
백업 파일 확장자(기본값은 TRN)	N/A	TRN 형태로 남기자.
백업 디렉터리를 위한 네트워크 공유 명	원본서버 와 대상서버에 의해 접근 가능한 것	"백업 파일을 저장할 디렉터리" 와 같게 한다. 그렇지 않으면 로그 전달은 제대로 작동하지 않을 것이다.
대상디렉터리에 트랜잭션 로그(부 서버에 반드시 확실한 UNC가 있어야 함.)	대상서버

파라미터	영향 받는 서버	값
서버에 반드시 확실한 UNC가 있어야 함.
새로운 데이터베이스를 생성하고 초기화.	대상서버	"아니오"를 선택하고 초기화된 백업,복사 그리고 복원을 수작업으로 한다.
데이터베이스 로드 상태	대상서버	만일 트랜잭션 로그가 높은 가용성을 위하여 적용되었다면 "복원 안 함"으로 설정한다. 또는 읽기 작업을 하는 서버를 만들고자 한다면 "대기모드"로 설정한다.
데이터베이스 사용자 종료.	대상서버	"예"로 설정한다. 만일 "아니오"가 선택되면, 작업은 연결을 종료하기 위하여 설정될 필요가 있다. 그렇지 않으면 로그는 결코 적용되지 않을 것이다. 문법은 다음과 같다. ALTER DATABASE databasename SET SINGLE_USER WITH TERMINATE 만??다면, 사용자가 트랜잭션 로그가 적용된 후에 접근 가능하도록 다음내용을 가지고 재설정한다. ALTER DATABASE databasename SET MULTI_USER
데이터베이스가 주 역할을 맡도록 허용	대상서버	이 것을 "예"로 설정하는 것은 대상서버가 원본 서버로 되는 것을 허용하는 것이다. "트랜잭션 로그 백업 디렉터리"를 "백업파일을 저장할 디렉터리"와 동일한 것으로 설정한다.
전체 백업을 실시한다.(만일 존재하는 데이터베이스를 사용하지 않는다면)	원본서버	아니오
최근의 백업 파일을 사용한다.(만일 존재하는파일이 있을경우)	원본서버	선택하지 말자. 수작업으로 백업파일을 복원한다.

파라미터	영향 받는 서버	값
데이터베이스를 사용하지 않는다면)
트랜잭션 로그 백업 스케줄(기본값은 매 15분이다.)	원본서버	보다 높은 볼륨 사이트와 작은 파일을 위하여 더 낮은 값으로 설정을 해야 한다. 만일 큰 값으로 설정되어 있다면, 파일은 커지고 대기서버는 원본서버와 동기화 될 수 없을 것이다.
복사/로드 주기(기본값은 매 15분이다.)	원본서버/대상서버	값이 작을수록, 로그 전달을 이루는 한 쌍의 데이터는 근접해 갈 것이다. 만일 리포팅 서버로서 대상서버가 사용된다면, 높은 값을 사용한다.
데이터베이스 사용자 종료.	대상서버	"예"로 설정한다. 만일 "아니오"가 선택되면, 작업은 연결을 종료하기 위하여 설정될 필요가 있다. 그렇지 않으면 로그는 결코 적용되지 않을 것이다. 문법은 다음과 같다. ALTER DATABASE databasename SET SINGLE_USER WITH TERMINATE 만??다면, 사용자가 트랜잭션 로그가 적용된 후에 접근 가능하도록 다음내용을 가지고 재설정한다. ALTER DATABASE databasename SET MULTI_USER
로드 지연(기본값은 0분이다.)	대상서버	값이 작을수록, 로그 전달을 이루는 한 쌍의 데이터는 근접해 갈 것이다. 그러나, 만일 트랜잭션 로그 파일이 커진다면, 파일을 복사할 수 있도록 하기 위해 조정을 해야 한다.
파일 보유 기간(기본값은 매 24시간이다.		만일 대상서버가 리포팅 서버로 사용된다면, 이 값을 더 높게 하여 로그 파일을 쌓아 사용자가 리포팅을 할 수 있도록 한다. 파일 보유 기간(기본값은 매 24시간이다.) 조직의 기록 정책에 맞게 끔 이 값을 조정한다.
백업 경고 임계 값		만일 백업이 커진다면, 잘못된 에러가 다시 나타나지 않도록 조정하기 위해 이 값을 조정한다.
비동기 경고 임계 값		위에서 제시한 가이드라인과 같다. 만일 파일을(3GB) 복사하는 데에 15분이 걸린다. 그리고 45분이 걸린다면 이 값은 비례해서 적용하면 된다.
로그전달 모니터 서버	없음	이 서버는 원본서버 또는 대상서버 보다 더 완벽하게 분리된 서버이어야 한다. 왜냐하면 만일 둘 중 하나의 서버가 손실되면, 발생된 기록은 서버를 위한 인증 모드 모니터 서버 가능한 "윈도우"로 설정한다. 만일 SQL 서버의 계정을 쓰는 환경에서 패스워드가 변경된다면, 로그전달을 위해

파라미터	영향 받는 서버	값
		정의된 모든 서버에서도 변경이 이루어져야 한다. 만일 SQL 서버가 선택되었다면, log_shipping_ monitor_probe 사용자가 생성될 것이다 그리고 계정을 위한 패스워드를 입력해야 한다.
생성할 보고서	원본서버 이것은 선택적이다.	DBA는 리포트가 위치할 디렉터리를 설정하고 리포트를 유지할 기간을 구성해야 하거나 SQL 메일을 사용하여 전자메일을 할 수도 있다.
sysdbmaintplan_history		테이블에 기록될 행 수 로그 전달은 장황하다. 이것은 만일 자주 트랜잭션 로그가 생긴다면 테이블 사이즈가 빨리 증가할 수 있다. 적절하게 조정해야 한다. 또한 마이크로소프트 데이터베이스가 자동증가로 설정되어 무제한으로 증가되었을 때를 확실히 한다. 기록되는 행을 지우기 위해서는, 저장 프로시저 sp_delete_backuphistory를 수행한다. 또한, 로그 전달은 기록을 응용 프로그램 이벤트 뷰어에도 로그한다. 그래서 때때로 백업을 하고 삭제하는 것이 필요할 것이다.

역할 변경과 계정 동기화하는 추가적인 정보를 위해서, "로그 전달 역할 변경을 설정하고 변경하는 방법"에 대한 SQL 서버 온라인 설명서를 참고하자.

장애 조치 클러스터링

장애 조치 클러스터링은 SQL 서버 2000 엔터프라이즈 에디션에서 고가용성 솔루션으로 추가된 내용이다. SQL 서버는 16개에 이르는 SQL 가상 서버를 설치하여 윈도우 클러스터로 이용할 수 있다. 가상서버는 SQL 서버 2000의 클러스터 인스턴스이다. 문제가 일어나면 작업을 수행하던 가상서버 노드는 제어권한을 포기하고, 다른 노드가 가상 서버를 운영한다. 장애 조치는 자동적이며, 별도의 수작업이 필요하지 않은 작업이다. 또한 트랜잭션 측면에서도 문제가않는 다면, 정상적인 시작 과정을 통하여 SQL 서버에 재 연결될 필요가 있다. 다른 클러스터 노드에서의 시작 시간은 얼마나 많은 트랜잭션이 롤 포워드 또는 롤백되는 가에 달려 있다.

DBA관점에서 SQL 서버 클러스터는 대부분의 경우에 정상적인 SQL 서버 인스턴스처럼 취급되어야 한다. 그러나 이것은 고가용성을 위한 것이므로, 서버의 가용성에 영향을 받지 않도록 아주 신중히 취급되어야 한다. 드물게 일어나는 경우를 제외하고, 서버를 관리하기 위하여 SQL 서버와 더불어 사용할 수 있는 도구를 이용해야 한다. 패스워드를 변경 하거나, 가상서버를 정지하고 시작하는 경우에 있어서 엔터프라이즈 관리자를 사용한다. 다른 노드로 리소스를 이동하거나 드라이브 종속 관계 같은 클러스터 시스템에 종속적인 작업을 수행하는 경우 클러스터 관리자를 사용한다.

성공적인 장애 조치 클러스터 구축을 위해 가장 중요한 점은 윈도우 클러스터링과 지원되는 하드웨어 시스템 구성에 달려있다. 또한 유지관리를 위한 계획 수립 시 모든 데이터베이스와 응용 프로그램을 가용성 측면에서 고려해야 한다.

장애 조치 클러스터링을 위한 좀 더 자세한 구성, 설치, 관리, 문제해결에 대한 정보는 "고가용성 데이터베이스 클러스터 구축" 백서를 참조하시오.

http://msdn.microsoft.com/library/default.asp?URL=/library/techart/d5clustering.htm

백업과 복구

클러스터 환경을 백업할 때 고려할 내용을 알아보자.

클러스터 환경에서 데이터베이스를 백업하는 것은 클러스터 환경으로 구축되지 않은 것 보다 다소 복잡하다. 그럼 클러스터 환경에서 백업은 어떻게 하는가? 클러스터 시스템은 크고 미션-크리티컬한 데이터베이스를 위해 사용된다. 데타바이트 규모의 데이터베이스를 백업하고 복구하는 것은 10MB 데이터베이스를 백업하고 복구하는 것처럼 할 수 없다. 다음은 최적의 백업/복구 작업을 실행하기 위하여 적용해야 할 내용들이다.

디스크와 테이프에 백업

일반적으로 디스크에 최초 백업은 아주 쉽다.

클러스터 디스크를 공유하도록 하여 모든 노드가 장애조치 이벤트 발생 시에 백업을 공유할 수 있도록 한다. 로컬 드라이브에 백업 파일을 저장하지 말자. 데이터베이스를 백업한 다음 다른 저장소로 복사해야 하거나 테이프와 같은 다른 매체에 백업을 한다. 그런 다음 백업 복원 테스트 작업을 수행하고 검증한 후에 안전한 장소단일 실패점을 제거하는 것이다. 만일 백업을 하고 구성한 레이드(RAID) 드라이브의 어디엔가 저장한 후, 어레이가 고장 난다면 어떤 일이 일어날까? 이런 일이 일어나지 않더라도, 최악의 시나리오는 항상 고려해야 한다.

사용할 수 있는 다른 방법은 백업 작업에서 두 단계를 제공하는 것이다. 테이프 드라이브와 공유 클러스터 디스크 백업 같은 두 가지 백업 방법을 설정하자. 유지관리 계획을 설정한 후에 백업 작업을 변경한다. 만일 백업이 첫 단계에서 성공을 한다면, 성공 시에 종료하도록 하고, 만일 어떠한 이유로 실패한다면, 두 번째 방법이 실행될 수 있게 한다. 이것은 백업 전략에서 단일 실패 점이 없다는 것을 확실히 하는 방법이다.

스냅샷 백업

SQL 클러스터 서버를 백업하고 복원하는 한 가지 방법은 스냅샷 백업을 사용하는 것이다. SQL 서버 2000은 스냅샷를 사용하여 디스크가 손상되었을 때, 이중화 디스크를 백업처럼 사용한다. 스냅샷 백업은 하드웨어를 통해 구현되며, 마이크로소프트는 스냅샷 API를 제공하며, SQL 서버에서 완벽하게 지원된다.

예를 들어, Terraserver (www.terraserver.com) 는 미국 지질학 연구소(the United States Geological Survey)가 항공 사진과 지도를 제공해주는 웹사이트 이다. 데이터베이스는 현재 거의 2 테라 바이트나 되며 N+1 시나리오를 가진 윈도우 2000 데이터센터 서버에 SQL 서버 2000 장애 조치 클러스터링을 사용한다. 초대용량데이터베이스(VLDB)를 백업할 때는 계획을 신중하게 세워야 한다.

Terra서버는 스냅샷 백업을 사용한다. 스냅샷 백업 본은 하드웨어적인 미러(mirror) 3개로 구성되어 있다. 즉, 데이터 세 카피가 하드웨어에 의해 동기화된다. 그러므로, 디스크 장애 시에 두 세트가 백업으로 사용할 수 있다. 3개의 미러 셋 중 하나가 손상되었을 때, 데이터베이스 라이브 스피닝 백업이 수행된다. 손상되었을 때, 손상된 디스크는 동기화도 되지 않고, SQL 서버에서 볼 수도 없다. SQL 서버는 디스크 손상을 인식하고 메모리 버퍼에서 적절하게 장애 상황을 처리한다. 테이프 솔루션으로 정상적인 디스크 정보를 백업하여, 손상된 디스크를 복원하면 다시 3개의 미러 셋이 정상적으로 돌아온다. 디스크 손상, 정상적인 디스크 내용 백업, 손상된 디스크 복원, 모든 스냅샷 디스크 복구 같은 작업이 순환적으로 일어난다.

전체 클러스터 시스템 백업

백업 솔루션으로 SQL 서버 2000 데이터베이스를 백업하는 것만으로 충분하지 않으므로 전체 시스템 백업이 반드시 수행되어야 한다. 윈도우 클러스터 시스템 정보를 백업하는 것 또한 중요하다. 그리고 만일 복원할 필요가 있다면, 장비에 운영것은 클러스터를 인지하는 백업 프로그램을 필요로 한다. 몇몇 3rd 파티 벤더는 클러스터 서비스를 제공할 수 있다.

다음은 클러스터 환경에서 백업/복원 작업을 효율적으로 관리하기 위하여 사용하는 도구 목록이다.

디스크와 테이프에 데이터를 백업하기 위해서는 반드시 미리 고려할 사항이 있다. 단일 실패점을 제거하고 동일한 방식으로 모든 클러스터 노드에서 동일한 장치에 접속할 수 있는지 확인해야 한다.

로그 전달과 클러스터링

장애 조치 클러스터링과 로그 전달을 결합한 상황에서 장애 조치 클러스터링을 주로 사용하고 로그 전달을 이용하여 두 번째 대처 방안으로 가용성을 제공한다면 단일 실패점을 제거할 수 있는 이상적인 방법이다. 로그 전달은 장애 조치 클러스터가 가지고 있는 거리 제한 문제를 극복할 수 있는 솔루션이다. 로그 전달 대상서버는 전원 문제와 같이 원본 서버와 대상 서버 모두를 못 쓰게 하는 경우를 대비하여 반드시 지리적으로 다른 곳에 위치시킨다.

메모리 관리

SQL 서버 2000은 기본적으로 메모리 풀을 동적으로 관리한다. 만일 SQL 서버 리소스가 증가 됨에 따라 좀 더 많은 메모리를 필요로 한다면, 윈도우2000에 추가적인 메모리를 요구할 것이다. 만일 다른 응용 프로그램을 시작하면서 SQL 서버 2000에 할당된 메모리를 요구할 것이고, SQL 서버 메모리 풀은 줄어들며 다른 응용 프로그램에게 메모리를 할당할 것이다. SQL 서버 시스템에 다른 응용 프로그램과 서비스를 함께 설치하지 않는 것을 강력히 추천한다. 이것은 시스템 성능과 가용성의 부족으로 야기되는 리소스 경쟁 문제와 그로 인해 발생되는 문제를 줄일 수 있다.

SQL 서버 2000은 기본적으로 메모리 풀을 동적으로 관리한다. 만일 SQL 서버 리소스가 증가 됨에 따라 좀 더 많은 메모리를 필요로 한다면, 윈도우2000에 추가적인 메모리를 요구할 것이다. 만일 다른 응용 프로그램을 시작하면서 SQL 서버 2000에 할당된 메모리를 요구할 것이고, SQL 서버 메모리 풀은 줄어들며 다른 응용 프로그램에게 메모리를 할당할 것이다. SQL 서버 시스템에 다른 응용 프로그램과 서비스를 함께 설치하지 않는 것을 강력히으로 야기되는 리소스 경쟁 문제와 그로 인해 발생되는 문제를 줄일 수 있다.

SQL 서버 2000의 최대 메모리 설정은 SQL 서버 2000이 가질 수 있는 최대 메모리 양을 말한다. 최대 메모리는 SQL 서버 시작 시에 할당되는 것보다, 시간이 감에 따라 요구하는 양 만큼 증가시켜 최대값에 이르도록 하는 것이 바람직하다. 최소 메모리양을 획득한 이 후에는 최소 메모리 값 이하로 할당 메모리가 줄지 않도록 하는 것이다. 최대 메모리 설정처럼, SQL 서버 2000은 시작과 동시에 최대 메모리 값을 요구하지 않는다. 그러나 메모리 최대값에 다다를 때까지 필요한 추가적인 메모리를 계속해서 요청할 것이다.

SQL 서버 성능을 최대화하려면 가용한 최소 메모리 값을 설정하여 운영체제크 페이지를 유발시키지 않도록 한다. SQL 서버가 운영체제로 메모리를 반환하기 위해 필요한 시간을 줄이면, 시작과 함께 메모리를 할당 받아야만 시스템에서 운영되는 다른 응용 프로그램의 기동 시간(startup time)을 줄여준다. 즉 SQL 서버 2000의 최대 메모리 값을 감소시키는 것을 고려할 수도 있다.

전 단락은 SQL 서버 2000의 디폴트 동적 메모리 동작에 대한 것을 살펴보았다. 윈도우 2000 AWE(Address Windowing Extensions)이 활성화 되면 메모리는 동적으로 관리되지 않고 SQL 서버 2000 서비스 시작과000 서비스가 종료될 때까지 윈도우2000으로 반환하지 않는다. 이러한 이유는 SQL 서버 2000이 윈도우2000의 넌페이지어블 풀로부터 메모리를 할당하기 때문에 페이지는 스왑(swap)을 할 수 없다. 이 와 같은 잠재적인 문제를 막기 위하여, 최대 메모리 설정을 사용한다.

메모리 고급 관리

AWE(Address Windowing Extension)와 PAE(Physical Addressing Extension) 메모리 할당?SQL 서버 2000 엔터프라이즈 에디션은 윈도우 2000 어드벤스트 서버 또는 윈도우 2000 데이터센터 서버 하에서 윈도우 2000 AWE(Address Windowing Extensions) API를 지원한다. 윈도우 2000 AWE는 SQL 서버 2000이 윈도우 2000 어드벤스트 서버 에서 8GB 의 물리적 메모리를 사용할 수? 물리적 메모리를 최대 64GB까지 사용할 수 있다.

SQL 서버 2000의 물리적 메모리를 64GB까지 사용할 수 있도록 정상적으로 설정하면 성능을 크게 향상 시킬 수 있다. 할당된 페이지는 버퍼 캐시에 존재하면서, SQL 서버 2000의 읽기/쓰기 데이터를 빨리 처리할 수 있게 한다. 데이터와 인덱스 페이지는 버퍼 캐시에 있고 상주하여 계속적인 물리적인 I/O 양을 줄인다. 임의 프로시저 계획은 프로시저 캐시에 머물러 있으면서, 옵티마이저가 새로운 실행 계획을 자주 만드는 작업을 감소시킨다.

AWE의 기능으로, 메모리를 많이 필요로 하는 응용 프로그램은 성능을 증가시키기 위하여 SQL 서버 2000 하에서 더욱 더 효율적으로 운영될 수 있다. 윈도우 2000 어드벤스트 서버와 윈도우 2000 데이터센터 서버는 확장된 AWE API를 사용할 수 있다. AWE를 사용하면 응용 프로그램이 많은 물리적 메모리를 접근 할 수 있다. 32 비트 메모리 어드레싱 제약으로 인하여, 윈도우 NT 4.0 과 AWE 가 활성화 안된 윈도우 2000은 4GB까지의 물리적인 메모리를 사용할 수 있다.

기본적으로, 2GB 메모리는 운영체제에 할당되며 2GB메모리는 응용 프로그램에 할당된다. 운영체제에 의해 사용되는 Boot.ini에서의 /3GB 스위치를 사용하면, SQL 서버와 같은 응용 프로그램은 3GB까지 메모리를 사용할 수 있다. 그리고 운영체제는 메모리를 1GB까지 사용할 수 있다. 즉, 서버가 8GB의 메모리를 쓸 수 있도록 구성하면, 실질적으로 4GB 메모리를 사용할 수 없다. AWE는 운영체제에서 Win32 기반 응용 프로그램에 확장된 메모리를 사용할 수 있는 방법을 지원한다.

AWE는 SQL 서버 2000 같이 AWE를 지원하도록 개발된 응용 프로그램에서 사용할 수 있다. SQL 서버 2000에서 AWE를 지원하는 것은 sp_configure에서 awe enabled 옵션을 사용하여 설정한다.

메모리 설정은 각 인스턴스 마다 한다. 기본적으로 awe enabled는 0으로 되어 있거나 오프상태이다. SQL 서버 2000에서 AWE를 지원하려면 운영체제에서 몇 가지 추가적인 설정이 필요하다. 좀 더 자세한 정보를 원하면, SQL 서버 온라인 설명서 "AWE 메모리 관리"를 참조한다.

대용량 메모리를 사용하기 위하여 이용하는 또 다른 옵션은 PAE(Physical Addressing Extension) 이다. PAE는 32 비트 운영체제가 4GB 이상의 메모리를 할당할 수 있도록 한다. PAE 에 대한 추가적인 정보와 설정하는 방법은 다음 기술 자료를 참조하기 바란다. Q268363 - Intel Physical Addressing Extensions (PAE) in Windows 2000.

하드웨어 솔루션(클러스터이든 아니든)을 선택하고 대용량 메모리 사용을 계획할 때, 대용량 메모리를 지원하는 하드웨어를 사용해야 한다. 하드웨어 호환 목록(Hardware Compatibility List)에서 "대용량 메모리"를 위한 모든 카테고리를 체크해야 한다.

표 4.4 는 설치된 대용량의 메모리에 기초하여 확장 메모리 설정을 어떻게 해야 하는지를 요약한 것이다.

표 4.4 확장 메모리 구성

4 GB 이하	4 GB 에서 16 GB	16GB 이상
/3GB switch	/3GB enabled	/3GB disabled
	AWE enabled	AWE enabled
	PAE enabled (Boot.ini)	PAE enabled (Boot.ini)

비록 AWE 메?지라도, DBA는 AEW 옵션을 사용한 후에 발생되는 문제

다중 인스턴스에서의 메모리와 프로세스 관리

SQL 서버 2000은 하나의 서버 또는 윈도우 클러스터링 환경에서 16개 인스턴스까지 지원한다. ( 한 개는 디폴트이고 15개는 새로 명명되거나, 16개가 명명됨에 의하여) 단일 인스턴스를 갖는 환경은 관리하기가 쉬우며, 두 서버의 클러스터 환경이 동일하다면 장애 조치 이벤트 시에 정상적으로 동작할 것이다. 장애 조치 클러스터 또는 하나의 서버에 하나 이상의 인스턴스가 있을 때, 동적 메모리로 구성할 수 없다. 왜냐하면, 각각의 SQL 서버 인스턴스는 같은 메모리 풀을 위해 경쟁 하기 때문이다. 단지 특정 인스턴스를 위해 필요한 것만을 설정해야 한다. 같은 서버에서 운영중인 운영체제와 다른 프로세스가 필요로 하는 자원도 고려하는 것을 잊지 말자. 예를 들어, 물 컵으로 두 노드로 구성된 장애 조치 클러스터를 생각해 보자. 두 개의 물 컵 용량은 최대 8온스이다.(8GB의 메모리). 물 컵 A와 물 컵 B는 각 컵마다 3온스의 물을 가지고 있다. 만일 물 컵 B의 물을 물 컵 A로 쏟으면, 물 컵 A는 물이 넘치지 않고 전체 양을 담을 수가 있다. SQL 서버 관점에서 보면, 이 예와 같다. AWE 메모리가 반드시 활성화되어야 하며, 각각의 인스턴스는 sp_configure 저장 프로시저 max server memory 옵션을 각각의 인스턴스 메모리를 위해 3GB로 설정해야 한다. 장애 이벤트 발생 시에, 운영체제와 다른 운영 위해 2GB의 메모리를 남기는 것이다.

다중 SQL 서버 인스턴스는 프로세스 자원과 같은 비슷한 문제를 가지고 있다. 추가적인 인스턴스가 생길수록, 프로세스 자원은 다른 프로세스와 인스턴스로부터 점점 더 사라진다. 하나의 서버 또는 윈도우 클러스터에 다중 SQL 서버 인스턴스를 배치하기 전에, 메모리 요구량을 뿐 아니라 프로세스 요구량도 벤치마크 해야 한다. 왜냐하면 자원을 필요로 하는 인스턴스로 인하여, 다른 프로세스 또는 응용 프로그램, 운영체제의 성능에 나쁜 영향을 줄 수 있다.

요약

이 장은 가장 이상적인 데이터베이스 관리 작업에 대한 내용이다. 인덱스관리,백업 및 복구, 데이터 이동 그리고 좀 더 발전된 주제인 대용량 메모리 관리, 로그전달, 클러스터링에 대한 내용을 다루었다. 매일,매주, 매월에 수행하는 작업을 포함하고 있다. DBA는 주어진 시스템 상황에서 수행할 작업과, 수행 빈도 및 적절한 도구 및 기술을 결정할 수 있어야 한다.