SQL Server에서 발생하는 3 가지 성능 문제는 무엇입니까?


15

저는 아인트호벤의 Fontys University 학생이며 현재 SQL Server 도구 개발에 도움이되는 일련의 인터뷰를 진행하고 있으며 해당 분야의 전문가로부터 피드백을 받고 싶습니다.

내 질문 중 하나는 다음과 같습니다.

SQL Server 인스턴스에서 발생하는 3 가지 성능 문제는 무엇이며 이러한 문제를 어떻게 식별합니까?

특히 스크립트와이를 측정하는 데 사용되는 도구에 관심이 있습니다.

답변:


22

내 머리 위로-3 가지 쿼리 문제 :

  • 암시 적 변환
  • 잘못된 인덱싱 전략 (너무 많거나 충분하지 않거나 종류가 잘못됨)
  • 필요한 필드의 이름을 지정하는 대신 SELECT * 사용

서버 수준 구성 문제, 데이터베이스 스키마 문제, 하드웨어 문제 등이 훨씬 더 많습니다. 다음과 같은 종류의 문제를 찾는 서버를 빠르게 분석하는 스크립트를 작성했습니다.

http://www.brentozar.com/blitz/


15
  • 열악한 디자인 / 쿼리 / 인덱싱
  • 올바른 하드웨어를 구입할 수 없습니다
  • Braindead ORM (일명 "SQL이 죽었습니다")

14

상위 3 개는 아니지만 아직 언급되지 않은 것을 언급 할 것이라고 생각했습니다.

  1. SQL은 DBA에 제공되는 세부 정보 / 투명성이없는 가상 머신을 사용합니다. 호스트 서버는 게스트 머신 설정을 동적으로 변경하여 성능 저하를 유발하고 DBA를 실마리없이 남겨 둡니다. 하이 퍼트 레딩, 네트워크 팀 구성 및 메모리 벌룬 같은 기능은 성능 카운터를 모니터링 할 이동 대상으로 만듭니다.Tools: sysmon/perfmon, DMVs, maintaining a history of performance counters in tables.
  2. 마찬가지로 DBA에 제공된 SAN 설정의 투명성 / 확인 성이 없습니다. 읽기 / 쓰기 캐시 환경 설정이 다른 LUN을 설정했지만 모두 동일하다고 말했습니다.Tools: IO DMVs, SQLIO.
  3. 잘못된 DB 아키텍처 : 데이터 및 로그 파일의 크기 및 배치, tempdb 등 병렬 처리의 부적절한 사용. 동일한 물리 디스크에 여러 파일 그룹 생성Tools: experience.

내가 지금 확인하고있는 또 다른 도구는 Project Lucy 입니다. 깔끔한 것 같습니다.


10
  • 적절한 인덱스 부족
  • 누군가가 프로덕션 코드에서 nolock과 함께 사용하여 성능 문제를 해결하려고합니다. 코드가 테이블의 데이터를 수정하면 특히 나쁩니다.
  • 필요한 것보다 많은 시간에 필요한 것보다 더 많은 데이터를 선택하는 애플리케이션. Ex는 동일한 테이블의 텍스트 데이터 만 원할 때마다 이진을 반환합니다.

2
nolock 언급에 +1 내가 아는 모든 개발자는 "판독에 테이블을 고정시키지 않기"때문에 그것을 사용하는 것이 좋습니다.
tucaz

당신의 고객 중 한 고객이 멀티 머니를 위해 거대한 시스템을 구입했을 때 그것을 싫어하고 처음으로 그것을 볼 때 그들은 어디서나 nolock과 함께 사용합니까? 그리고 ... :-/
Martin Sjöberg

9

잘못 확장 된 쿼리 (합계 데이터 및 잘못 계산 된 기타 평균 데이터를 포함한 모든 주문을 포함하여 모든 고객 등을 위해 X 년 동안 모든 주문을받습니다)

한 번에 모든 것을 쿼리하기 만하면됩니다.

모든 쿼리를 통해 검색해야하는 '설명'varchar / text 필드가 포함 된 테이블입니다.


7
  • 부적절한 유지 관리, 즉 인덱스 재구성, 통계 없음, 로그 백업 없음
  • 누락 된 인덱스
  • 잘못 작성된 쿼리

7
  • 불쌍한 데이터베이스 및 응용 프로그램 디자인
  • 플랫폼 사용률이 낮음 (개발자는 플랫폼에 독립적 인 데이터베이스 액세스 코드를 갖고 싶어했습니다. SP, 기능 없음 등)
  • 물론 나쁜 색인 생성.

7
  • 자극 데이터에 대한 임시 쿼리-예, 개발자는 그것이 필요하며 일부는 액세스 권한이 있다고 생각합니다 :-)
  • 데이터베이스를 사용하는 앱의 잘못된 디자인-예 : 더 이상 필요하지 않더라도 너무 많은 데이터가 추가되고 제거되지 않음
  • 동일한 드라이브에서 동일한 RAID에있는 모든 데이터베이스 파일 (예 : 시스템 데이터베이스, tempdb, 사용자 데이터베이스가 모두 동일한 드라이브 / 레이드에 있음)

3
  • 불쌍한 데이터베이스 디자인
  • 열악한 인덱싱 전략 (너무 많은 인덱스, 누락 된 인덱스 및 인덱스 유지 관리 부족 포함)
  • 열악한 하드웨어 아키텍처 결정

2

인덱싱은 성능에 중요하지만 대부분의 DBA는이를 알고 있으므로 쿼리 최적화를 통해 가장 먼저 수정되는 경향이 있습니다. 종종 잘 알려지지 않은 영역 :

  1. DB 왕복이 너무 많습니다. Chattiness는 내가 본 주요 성능 문제 중 하나입니다.
  2. 올바른 거래 범위 확보 모든 INSERT / UPDATE / DELETE를 처리하는 것은 성능을 크게 저하시킬 수 있습니다.
  3. 하드웨어 측면을 최적화하지 못했습니다. 특히 DB 로그를 DB 데이터와 다른 볼륨에 배치합니다.

네 번째 항목을 목록에 추가 할 수 있으면 트리거 및 / 또는 커서가 과도하고 부적절하게 사용됩니다. 요즘 너무 많이 발생하지는 않지만 성능 측면에서 고통 스럽습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.