SQL Server 검사 목록


14

내 다른 질문에 이어 경고 측면에서 매일 / 매주 / 매월 기준으로 살펴 봐야 할 사항에 대해 생각하고 싶습니다. 문제가 발생하기 전에 오는 문제 (계획)를 볼 수 있기를 바랍니다.

지금까지 다음 순서로 스크립트를 수집하기 시작했습니다 (순서 없음).

매일

  • 시스템 가동 시간 확인 (DBA로 무엇이든 확인해야하는 경우)
  • 마지막 백업 확인
  • 트랜잭션 로그 백업 확인
  • SQL 작업 상태 확인
  • 지난 24 시간 (또는 1140 분) 동안 평균 CPU 사용량을 확인하십시오.

주간

  • MSDB 백업 기록 확인
  • CheckDB가 마지막으로 실행 된 시간을 확인하십시오.
  • 인덱스 조각화 확인
  • 인덱스 통계 확인 (읽기 vs 쓰기 등)
  • IO 병목 현상 확인

월간 간행물

  • 누락 된 인덱스 확인
  • 더 이상 사용되지 않는 인덱스 확인

다른 제안? (나는 DBA를 처음 사용하므로 언제든지 도움 / 조언을 환영합니다)

답변:


3
  1. 백업

    • 백업 이메일 확인
    • 백업 실행 시간 (데이터베이스 백업 기간)
    • 유지 관리 계획에 따라 모든 데이터베이스가 백업되고 있는지 확인
  2. 디스크 여유 공간. 이전 검사와 크게 다른 점에 유의하십시오. 월별 작업으로 인해 로그 파일이 크게 영향을받을 수 있음

  3. 작업 실패. 실패에 대한 작업 활동 필터링

  4. 시스템 점검. SQL 로그에서 중대한 오류가 있는지 확인하십시오.

    • 응용 프로그램 로그
  5. 공연

    • 모든 서버에서 성능 통계 확인
    • 모든 프로덕션 서버에서 카운터가 정상 범위인지 확인하십시오.
  6. 연결성

    • 고객 애플리케이션이 데이터베이스에서 데이터를 가져올 수 있는지 확인
    • 허용되는 액세스 데이터 속도 확인
  7. 복제. 각 게시 및 배포자가 각 구독에 대해 실행 중인지 확인

SQL Server DBA 체크리스트

브래드의 확실한 DBA 점검표

Oracle DBA 점검표 (유용 할 수 있음)

SQL Server DBA 데이터베이스 관리 점검 목록

DBA 아침 점검표

MS SQL Server DBA 점검 목록 (많은 점검 목록)

SQL Server DBA 체크리스트


4

체크리스트에서 제안하는 변형 만 BACKUP이라는 단어를 RESTORE로 바꾸는 것입니다. 백업이 완료되었는지 확인하는 것이 좋은 시작이며 실제로 중요한 것은 백업에서 복원 할 수 있는지 여부입니다. 백업 실패에 대해 경고하고 임의의 복원 샘플 샘플링을 자동화하여 백업이 양호하다는 것을 알 수 있습니다.

일별 / 주별 / 월별 점검 목록에서 다음 단계는 기록입니다. x / y / z 성능 카운터를 확인하는 것은 오늘과 어제 비교할 기준이 없으면 의미가 없습니다. 오늘과 어제를 이해하지 못하면 다음 달을 예측할 수 없습니다.


2

면책 조항 : SQL Server DBA가 아님

가능하면 매달 쿼리에서 사용하지 않는 인덱스가 있는지 점검하십시오. 이것은 당신이 확실히하고 싶은 것입니다

  • 매우 큰 테이블
  • 인덱스가 많은 테이블
  • 많은 열이있는 인덱스 (3 개 이상)

4
"사용하지 않음"이 전체 비즈니스주기를 반영하는지 확인하십시오. DBA가 몇 달 동안 사용되지 않은 인덱스를 삭제하기로 결정한 다음 사례에 대해 들었습니다. 다음 날 CFO의 분기 별 보고서는 몇 초가 아닌 몇 시간이 걸립니다 ... index_usage_stats DMV, 특히 서버가 주기적으로 다시 시작되는 경우 시간이 지남에 따라 자체 사용 통계를 유지하는 경우에만이 작업을 수행합니다 ...
Aaron Bertrand


2

그것을 달성하는 데 도움이되는 것 ... Idera는 몇 번 사용한 SQL Server 작업을 검토하는 무료 도구를 제공했습니다. 무료이기 때문에 몇 가지 제한 사항이 있지만 좋은 개요를 얻는 데 매우 좋습니다. 가치 확인 : http://www.idera.com/Products/Free-Tools/SQL-job-manager/

집안의 보안 측면을 위해 추가 할 내용 ... 사용자 계정의 로그온 활동을 캡처하기위한 추적 파일입니다. 이를 통해 비활성 계정을 쉽게 찾을 수 있습니다. 그런 다음 누군가가 고정 서버 / 데이터베이스 역할에 추가되는시기를 모니터링하는 스크립트입니다. 서버 / 인스턴스를 관리하는 유일한 사람이 아닌 경우 특히 sysadmin.


추적 파일이 가장 좋은 방법입니까?
토마스 스트링거

내가 정보를 얻는 가장 쉬운 방법입니다. 정보를 테이블 또는 로그에 캡처하기 위해 트리거를 설정하지 않으면 가능합니다. SQL 2008을 사용하는 경우이 목적으로 정책 관리를 사용할 수 있습니다.

@ShawnMelton이 가장 좋은 방법 일 것입니다. SQL Server가 모든 로그인 (성공 및 실패)을 감사하도록 레지스트리 ( sqlservercentral.com/articles/security/sqlserverauditingpart1/… ) 를 수정하는 방법이 있습니다 . 가장 좋은 방법이 무엇인지 잘 모르겠지만 추적을 무기한 실행하는 것에 대해 항상 걱정했습니다. 당신의 생각?
토마스 스트링거

추적 파일을 실행하는 데 아무런 문제가 없었으며 성능에 큰 영향을 미쳤습니다. C2 감사를 활성화했지만이를 활성화하는 것을 좋아하지 않습니다. 확장 이벤트는 대안을 제공하며 추적 파일을 사용하는 데 선호되는 방법으로 사용됩니다. 로그인 이벤트 옵션이 있는지 확인하기 위해 해당 정보를 확인할 수 있습니다. 내가 그들에 대해 이해 한 바에 따르면, 그들은 어떻게 든 성능에 타격을 입히는 것을 배제합니다.

좋은. 나는 당신에게 동의하는 경향이 있습니다. 그리고 그렇습니다. C2는 꼭 필요할 때만 사용해야하는 상황 중 하나입니다.
토마스 스트링거

0
  • SQL Server 및 SQL Server 에이전트 오류 로그 확인
  • 미러링 된 서버 (주 서버 및 미러)의 상태 확인
  • 작업 실행 시간 변경 확인
  • 클러스터 SQL 서버에서 활성 노드 확인
  • 디스크 공간 확인
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.