http://debop.egloos.com/2693391

원문 : 12 Essential Steps After Installing SQL Server

간단하게 요약해서 번역하겠습니다.

제목에도 나왔듯이 SQL Server 설치야 요즘 개나소나 다 하잖아요? 그럼 끝이 아니라 몇가지 더 작업을 해주면, 아주 쾌적하게 SQL Server를 운영할 수 있습니다.

그럼 체크리스트를 함 봐보죠.

  1. Service Pack, Hotfixes(공인된 것만), 누적 Updates 등을 확인 후 설치해라.

    당연히 버그 수정, 보안, 성능 문제로 ServicePack 등이 나왔으므로, 항상 최신 버전으로 유지해주는 게 좋겠죠?

  2. SQL Service들의 설정을 수행해라.

    인스톨 시 아마 서비스들의 환경 설정을 지정할 수 있습니다만... 괜히 (앞으로 사용될 예정이지만) 당장 사용하지 않는 서비스들은 시작모드를 "수동"으로 변경하세요. 한 예로 "SQL Server Browser" 서비스는 기본적으로 설치되지만, SQL Server가 Named Instance로 설치되지 않았거나, 한 머신에 Multiple 인스턴스를 설치하지 않을거라면, 필요없는 서비스입니다.
    또 하나 필요없는게 "SQL Server VSS Writer" 일겁니다. DB를 백업하기 위해 Volume Shadow Copy 기능을 사용하지 않는다면, 별 필요없습니다. (요놈은 Windows Service에서 "수동"으로 변경시키세요)

    반대로 SQL Agent는 항상 실행되도록 하세요. (로칼 개발 DB가 아니라면) SSIS, SSAS, Report Service는 각자 필요에 따라 "자동"/"수동"으로 설정하세요.

    또 한가지 SQL Server의 경우 꼭 실행되어야 하는데, 서비스가 어떤 이유로 실행되지 못했을 때, Windows가 삼세번의 기회를 줍니다. 이 기능을 활용하면, DB가 맛탱이 간 상태로 오래 있지 않을 수 있도록 할 수 있습니다.

    같은 기능이지만, SQL Server Agent의 속성페이지에서 SQL 과 Agent 서비스를 예상하지 못한 중지로부터 자동으로 복구가 가능해지도록 합니다.

  3. 기본 디렉토리를 설정합니다.

    SQL Server의 Database의 기본 디렉토리가 있습니다. 설치 폴더\Data 이죠? 당근 서버라면, HDD가 여러개일 거고, 성능을 따진다면, SQLServer가 설치된 HDD 말고, 다른 곳에 Data DB와 Log DB를 두는 것이 성능상 유리합니다. 더 나눈다면 Data DB, Log DB도 나누고, Partitioning을 고려한다면, 더 세분하면 좋겠죠? 물론 H/W가 받쳐줘야죠... 같은 HDD 논리적으로 두세개로 쪼개놓고, 분산해봤자 그건 쓸데없는 짓입니다. 꼭 물리적으로 다른 HDD에 분산해서 사용해야 효과를 봅니다.

    예를 들면, Data 는 D:\SQL2005\Data 에, Transaction Log는 E:\SQL2005\Logs 에 (물리적으로 다른 HDD) 생성/저장하는 것으로 설정하라는 얘기입니다.
    같은 원리로 백업 파일, 복제 파일, Full Text Index 파일, Job output 파일 등을 분산 저장하면 성능상 유리합니다.
    근데 문제는 Enterprise Manager에서 Data, Log 빼고는 다른 폴더를 기본으로 설정할 수 있는 UI가 없다는 겁니다.

    아래 코드를 사용하면 위의 백업, 복제 등도 설정이 가능합니다. (요놈들은 Registry를 건드리는 놈이라 조심해서 사용하세요)

    Configuring_Default_Directories.sql

    당근 레지스트리를 바꿨으니 SQL 서비스를 재시작해야 합니다.

  4. 기본 DB 설정 값을 변경합니다.

    잘 알다시피 model db는 새로운 db를 생성할 때, "template" 역할을 합니다. 사용자 DB들에 공통으로 적용되는 속성을 설정하고 싶을 때, model db의 속성 값을 설정하고 난 후 사용자 DB를 생성하면 됩니다. 이러한 방식을 적용할 때 좋은 점 몇가지를 소개합니다.

    a) Recovery Model : 
        여러개의 Data Mart 로 구성된 DW 용 DB에서는 굳이 완전복구 모델이 필요 없습니다. model db를 단순 복구 모델로 설정하시고, DW 용 DB를 생성하시면 되겠슴다.

    b) File Property : 
       기본적으로 DB 생성 시 1MB 크기와 10% 증분이라는 값이 설정되어 있습니다만, 업무용 DB가 이럴리가 없잖아요? 요딴식으로 구성하면, DB 증분하는데 시간 다 보내고, 파일도 조각나서 성능에 지장이 큽니다. 이 값을 적절히 좀 크게 50Mb / 10Mb (이건 상황에 따라 다르죠) 로 해버립니다. 그럼 증분하려는 횟수도 줄어들고, 파일 조각도 작아질겁니다.
    또한가지는 파일그룹을 Primary filegroup이 아닌 다른 것도 만들어버리면, 매 DB마다 설정할 필요가 없어서 좋습니다.

    c) Database Options :
       사용자가 원하는 기본 DB 옵션을 model db에 설정해 놓으면 편합니다.

    d) Custom Objects :
        Custom Objects들을 여러 DB마다 생성하는게 귀찮으면 model db에 만들어 놓으면, 좋다^^

  5. tempdb Database를 설정하자.

    tempdb는 아주 많이 사용되는 DB입니다. 최적의 성능을 내기 위해서는 tempdb를 독립적인 다른 disk 에 생성하는 것입니다. 그게 안된다면, tempdb의 파일을 여러개를 만드는 것입니다. 파일 갯수는 서버의 CPU 갯수 (logical or physical)에 맞추는 것입니다. 예를 들어 8 CPU 를 가진 서버라면 tempdb의 파일 갯수도 8개가 되도록 하는 것입니다.

    또한 database의 data file은 "proportional fill" 알고리즘이 사용됩니다. 만약 하나의 DB에는 두개의 data file이 있고,  각각 4G와 8G라면, 1:2 비율로 data를 분산시킨다는 겁니다. 즉 4GB 파일에 한번 쓴다면, 8GB 파일에는 두번 쓴다는 얘기지요.

    그렇다면, 복수의 CPU에 복수의 파일을 같은 크기로 해주는 것이 부하분산에 가장 좋겠죠. 다음 쿼리를 보시면 이해가 될 겁니다.

    Configuring_tempdb_Data_Files.sql

    tempdb에 대한 설정을 하고 나면, SQL Server를 재시작해야 설정이 적용됩니다.

  6. Configure Server Properties and Features

    SQL 2005라면 Surface Area Configuration tool을 이용해서 SQL Server 특성들을 활성화 시켜줘라. SQL 2008의 경우 서버 속성의 Surface Area Configuration Facet 에서 가능하다. 기본적으로 모두 비활성화되어있으니 필요한 것은 활성화 시켜라

    뭐 원하기에 따라 다르겠요.

    Configuring Parameter Values:

    메모리, FillFactor, Process, Network Connections, Security, Trace Flags 등을 알맞게 설정해라.

    Configuring SQL Server Network :

    사용할 network protocol과 사용하지 않을 protocol을 지정해라. 기본적으로 Shared Memory는 local에서만 사용하고, TCP/IP는 원격에서 접속하는 것을 허용할 때 사용한다. 경우에 따라 오래된 프로그램에서 named pipe를 사용할 때도 있다. 또한 보안상 기본 TCP 포트인 1433을 다른 것으로 변경하는 것이 좋다. Named Pipe에서는 동적할당이 되도록 하고.

  7. Configure Security

    SQL Server 보안문제에 대해서 기업은 두가지 부류로 나뉜다. - 첫번째는 엄격한 보안 규칙을 적용하는 것이고, 두번째는 시스템 기본 설정을 그대로 두는 것이다.(잠재적인 공격을 받는다). 첫번째 회사라면, 하는대로 하면 되고, 두번째 회사 스타일이라면, 어떻게든 만들어야 한다.

    가장 먼저 해야할 일은, 가능한한 작은 수의 구성원만 sysadmin 이란 서버역할에 할당되어야 한다는 것이다. 기본적으로 Windows의 Local Administrators 사용자 그룹은 sysadmin 역할의 구성원으로 할당된다. 만약 Windows의 관리자 계정을 sysadmin으로 놓고 싶지 않다면, 제거해야한다. 대신 정책상으로 새로운 database 관리자 계정을 생성하여, 사용하는 것이 좋다.

  8. Configure Error Logs

    SQL Server error log는 서버에 문제가 생겼을 때 DBA가 가장 먼저 봐야할 내용이다. 기본적으로 로그 파일은 6개의 보관용과 현재 로그를 담은 Current라는 파일이 있다. 서버가 시작할 때마다 Rolling File 형식으로 보관되고, 가장 오랜된 파일은 삭제된다.
    이러한 Rolling 파일 갯수(기본 6개) 를 설정을 통해 99개까지 늘릴 수 있다.

    또한 서버 시작시가 아닌 매일 로그 파일을 생성하고 싶다면 작업 스케쥴러에서 sp_cycle_errorlog 를 0시 수행하도록 하면 된다.



  9. Configuration Database Mail

    내가 이 기능은 잘 안 쓰므로 패스

  10. Configure SQL Agent & Operator

    SQL Agent의 속성 을 보면 몇가지 중요한 요소가 있다.

    a) Auto start Agent Service if stop unexpectedly 를 항목을 꼭 활성화하라.
    b) SQL Mail을 사용한다면, 요기능을 활용해라.
    c) job history log (msdb database에 있음) 크기를 키워라.

    많은 수의 작업이 수행되는 서버에서는 job history log 크기가 커야한다. (로그 찾고 싶어도 삭제되면 말짱 꽝)

    또한 작업 실패시 알림을 받을 수 있는 DBA를 지정해 놓으면, 맨날 신경 안써도 되고 좋을거다. (난 안해봤지만, 구축하러 간 회사의 SM들은 이 기능을 잘 사용하고 있더라)

  11. Configure Operating System

    OS 레벨의 변경이 SQL 서버 성능에 힘이 될 수 있다. 서버 관리자랑 친해야겠지... 글구 DB 단독 서버라면 더욱이 요청해야 하고.... 뭘? 다음과 같은 기능을...

    DB 서버가 연결된 다른 서버들과 분산 캐시에 참여한다면, Network DTC 를 활성화 시켜야 한다. (당연한거 아닌가?)

    Windows 2003의 DTC 설정 화면

    이건 첨 보는 건데...
    다음으로 Local Security Policy의 항목 중 "Lock page in memory" (메모리에 페이지 잠금) 항목에 대해 SQL Service account가 권한을 갖도록 한다. 이 넘이 하는 일은 메모리에 있는 SQL 페이지를 Disk의 page file로 내리는 것을 막는 역할을 한다. (메모리 확보를 위해 OS가 이런 일을 하는데 SQL Server가 소유한 메모리는 page 파일로 swap하지 못하게 하는 거다 - 오호 이러면 속도가 빠르겠네) 

    이렇게 하기 위해 로컬 보안 정책->로컬 정책->사용자 권한 할당->메모리에 페이지 잠금 의 속성에 SQL service의 계정을 추가해주면 된다.



    Lock Page in Memory 와 관련된 자료
        Managing Memory for Large Databases (서브에 관련 내용 있음)
        64bit Standard 에디션에서 "Lock Page in memory" 가능
        

  12. 시스템 데이타베이스를 위해 유지보수 계획을 설정하라.

    이제 상업용 DB로서 사용할 준비가 끝났다. 마지막으로 시스템 Database들의 유지 보수 계획을 생성할 시간을 가져라. 유지보수 계획에는 "인덱스 재구성", DBCC CHECKS, 통계 갱신 (update the statistics), 시스템 DB(master, model, msdb) 백업 계획을 수립해야 한다.
    가장 좋은 예는, 매일 시스템 DB를 백업하는 것이다. 
    유지 보수 계획을 생성했다면, 수동으로 실행해봐서, 제대로 수행되는지 확인해봐라.
결론
이 글이 모든 가능한 설치 시나리오를 설명하지는 않았지만, 모든 설치 작업의 기본적에 대해 논의했다. 필요하다면 위의 리스트를 변형해서 사용해라. 예를 들어 리포트 서비스에 대한 설정이라던가....

대략적으로 번역해 봤는데, 저도 모르는 것도 있고, 약간 부족한 부분도 있네요. 
시간 나면 더 추가하던가, LINK를 걸도록 하겠습니다.

+ Recent posts