왜 갑자기 인덱스가 필요하거나 쿼리를 변경해야하는지에 대한 답변 방법

3 년 경력의 주니어 DBA입니다. 우리의 임무는 쿼리를 미세 조정하거나 개발자에게 특정 코드를 다시 작성하거나 인덱스가 필요하다는 것을 알리는 것입니다.

개발자 팀이 자주 묻는 한 가지 간단한 질문은 "어제 잘 작동했습니다. 갑자기 무엇이 바뀌 었습니까?" 인프라 측면을 확인하라는 메시지가 표시됩니다. 모든 문제에 대한 첫 번째 반응은 항상 첫 번째로 확인되는 인프라에 최대의 책임을 부여하는 것으로 보입니다.

개발 팀의 "변경된"질문에 어떻게 대답해야합니까? 너희도 같은 상황에 처한 적이 있습니까? 그렇다면 경험을 공유하십시오.

dev에 의해 변경된 질문에 대답하는 방법은 무엇입니까?

이것은 DEV뿐만 아니라 IT 및 비즈니스의 모든 팀에 적용되는 매우 일반적인 질문입니다.

무엇이 바뀌 었습니까? ==>는 사실과 수치로 대답 할 수 있습니다.

사실은 예를 들어 참조

• 데이터베이스에 액세스하는 사용자 수를 늘리십시오.
• 서버 구성 매개 변수가 변경 되었습니까?
• 데이터베이스 유지 관리-통계 업데이트, 인덱스 재구성 / 재 구축이 수행되지 않습니까? 이로 인해 계획이 잘못 생성되었습니다!
• 데이터 양이 증가 했습니까?
• 응용 프로그램 비즈니스 사이클에 대한 완전한 회귀 테스트를 수행하지 않고 네트워크 쪽에서 변경하고 OS를 패치하거나 SQL Server를위한 새로운 서비스 팩 또는 CU를 배포했습니다 .
• 기본 SAN이 갑자기 느려졌습니까?

표시 할 데이터가있는 경우 그림을 파생시킬 수 있습니다. 예를 들면 다음과 같습니다.

• 이 상황에서는 서버 기준을 세우는 것이 중요합니다. 탄탄한 인물로 사실을 뒷받침 할 수 있기 때문에 이것은 비난 게임 을 완화시킵니다 .
• SQL 서버를 재부팅 한 후 데이터가 유지되도록 DMV 또는 sp_whoisactive를 사용하여 데이터 수집을 시작하십시오.

(환경 및 요구 사항, 데이터 수집 빈도 / 수집 할 데이터 및 보유 기간에 따라 운동을 수행해야 함) 또는 (sqlsentry 또는 idera의 진단 관리자와 같은 타사 소프트웨어에 투자 할 수 있음) 위의 작업을 수행합니다) .

다음과 같은 이유로 다른 계획을 세울 수 있습니다.

• 다음과 같은 이유로 계획이 캐시에서 제거 될 수 있습니다.
  • 서비스 재시작
  • 계획 캐시 수동 지우기
  • 서비스 재시작 또는 장애 조치
  • 부주의 한 변경, 예를 들어 특정 sp_configure변경으로 인해 캐시가 플러시 될 수 있음
  • 기본 개체, 인덱스, 통계 또는 기타 종속성에 대한 일부 변경으로 인해 재 컴파일이 트리거되었습니다.
• 다음과 같은 이유로 다른 사용자 또는 이전 호출과 다른 계획을 얻을 수 있습니다.
  • 쿼리 텍스트가 동일하지 않을 수 있습니다 ( 대소 문자 구분 및 공백 포함, 다른 열, 결합 기준, 필터 등은 신경 쓰지 마십시오)
  • (계획에서 어떤 객체가 완전한 이름이없는 경우, 또는 다른 기본 스키마 쿼리는 다른 설정 옵션을 다른 사용자들에 의해 실행될 수 스키마 포함 )
• 쿼리와 계획은 동일 할 수 있지만 다음과 같은 이유로 다른 성능을 얻을 수 있습니다 .
  • 계획은 다른 매개 변수를 사용하여 캐시되었으며 계획은 현재 매개 변수 세트에 적합하지 않습니다 (일반적으로 "매개 변수 스니핑"이라고 함).
  • 매개 변수를 기반으로하거나 그 동안의 데이터 변경으로 인한 데이터의 양은 크게 다릅니다.
  • 데이터에 액세스하는 가장 효율적인 방법을 변경하기에 충분하도록 데이터가 변경되었지만 통계 업데이트 또는 재 컴파일을 트리거 할 수는 없습니다 (오름차순 주요 문제 및 자동 통계 알고리즘 검색)
  • 버퍼 풀에서 데이터가 제거되었으며 이제 디스크에서 데이터를 읽어야합니다.
  • 쿼리를 충족시키는 데 필요한 리소스에 대한 동시성, 차단 또는 기타 부담이 있습니다.

나는 이것들에 대해 더 자세히 여기에서 간다 :

• "동일한"쿼리에 대한 여러 계획

이것들이 다른 환경에서 실행되고 있다면 여기에서 확인할 일련의 것들이 있습니다.

• "동일한"서버에 대한 다른 계획

또한 인덱스를 만들거나 쿼리를 변경하는 것이 쿼리가 갑자기 더 나은 성능을 발휘 하는 직접적인 이유는 아니라는 점을 명심해야 합니다. 때로는 이러한 변경으로 인해 실제로 새로운 계획이 생성되거나 이미 존재하는 계획이 무효화되기 때문입니다. .

평소 와 같이 Aaron Bertrand 와 Kin 은 훌륭한 답변을 제공했습니다. 그러나 두 답변 모두 공통 스레드를 포함합니다. 두 답변 중 하나를 분석하면 XYZ가 어제 효과가없는 것처럼 작동하는 이유는 귀하 / 그들 / 개인 X가 한 일 때문이 아니라는 것을 알 수 있습니다. 상황이 변경된 이유는 데이터베이스가 XYZ 이유 때문에 다르게 수행하기로 결정했기 때문입니다.

데이터베이스는 살아 숨쉬는 존재 입니다. 데이터베이스는 가정, 통계 및 기타 휴리스틱 도구의 조합으로 인해 결정을 내리고 생각을 바꿉니다. 이것은 대부분의 응용 프로그램 계층 프로그래밍과는 크게 다릅니다 (머신 러닝은 예외입니다).

_{나는 지금 더 나은 것을 생각할 수 없기 때문에 군사 참조를 사용할 것입니다. 더 일반적인 은유가 인정 될 것이다.}

대부분의 응용 프로그램에서 프로그래머는 드릴 강사 역할을합니다. 그들은 컴퓨터에게 정확히 무엇을, 어떤 순서로, 때로는 얼마나 오래하는지 알려줍니다. 데이터베이스 프로그래밍은 지휘관 역할을하는 것과 비슷합니다. 당신이 원하는 것을 높은 수준으로 말하고 필요한 곳에서 지침을 제공하십시오. 데이터베이스는 하급 장교 및 비 위임 장교와 같은 최신 정보를 기반으로 계획을 실행하는 가장 좋은 방법을 찾아 내야합니다.

다른 프로그래머들의 마음에서이 구별을 명확하게함으로써 그들은 당신이 그들의 환경을 지배하는 것과 같은 묘사적인 힘이 없다는 것을 알기 시작할 것입니다. 데이터베이스를 솔루션으로 안내하고 있으며 때로는 좋은 이유와 나쁜 이유로 데이터베이스가 제대로 작동하지 않습니다. 결국 데이터베이스가 왜 잘못 진행되었는지는 중요하지 않지만 데이터베이스를 복구하기 위해 할 수있는 일은 중요합니다.

_{* "이유"가 미래 예방, 학습 등에 매우 중요하다는 것을 알고 있지만 문제에 대해 배우거나 도움을주지 않는 사람들로부터 OP가 저항에 직면하고있는 것 같습니다.}