INF: Microsoft SQL Server 성능 최적화

기술 자료 번역 기술 자료 번역
기술 자료: 110352 - 이 문서가 적용되는 제품 보기.
모두 확대 | 모두 축소

이 페이지에서

요약

가장 효과적으로 Microsoft SQL Server 성능을 최적화하려면 최대한 다양한 상황에서 통해 가장 큰 성능이 향상되는 yield 및 이러한 영역에 대한 분석에 초점을 영역을 확인해야 합니다. 그렇지 않은 경우에는 상당한 시간과 노력을 크기 조정 가능한 개선 얻을 수 있는 항목에 대한 낭비하게 수 있습니다.

대부분의 경우 다음 정보를 통해 다중 사용자 동시성 형태소 분석 성능 문제를 해결할 수 없습니다. 이 문서의 "최대화하기 데이터베이스 일관성 및 SQL Server 버전 4.2"프로그래머 참조 C,"x 에 동시성," 다룬 있는 별도의 복잡한 항목입니다 부록 E 및 기타 기술 자료 문서에서 또한. 버전 6.0 설명서에서 것은 아니지만 해당 제목 아래의 MSDN Microsoft 개발자 네트워크 CD의 찾을 수 있습니다.

이론적인 토론 대신 실제 상황에서 실용적인 값의 수 년간 Microsoft SQL Server 지원 팀에서 보여주었습니다 영역을 주로 이 문서에서는 중점적으로 다룹니다.

경험에 논리 데이터베이스 디자인, 인덱스 디자인, 쿼리 디자인 및 응용 프로그램 디자인 일반 영역을 SQL Server 성능에 가장 큰 이익을 얻을 수 있습니다. 반대로, 가장 큰 성능 문제가 자주 같은 영역에서 부족이 인해 발생합니다. 성능이 걱정되는 경우 매우 큰 성능 향상을 종종 함께 비교적 적은 시간 투자 얻을 수 있으므로 이러한 영역을 먼저 집중할 합니다.

메모리, 캐시 버퍼, 하드웨어 등, 확실히 연구 후보가 같은 다른 시스템 수준 성능 문제가 동안 환경을 이러한 영역의 성능 향상 종종 증분 있음을 보여 줍니다. SQL Server (필요성과 따라서 이점은) 광범위한 시스템 수준 손 튜닝 줄이는 자동으로, 대부분의 경우 사용 가능한 하드웨어 리소스를 관리합니다.

Microsoft SQL Server 6.0 성능 향상을, 대용량 메모리, 대칭적 다중 프로세싱, 병렬 데이터 스캔, 최적화 향상 및 디스크 스트라이프는 플랫폼 레이어에 대한 새로운 기회를 제공합니다. 그러나 크게 이 향상된 것으로, 이들이 범위에서 유한 있습니다. 빠른 컴퓨터 비효율적인 쿼리 또는 잘못 설계된 응용 프로그램 bogged 수 있습니다. 따라서 SQL Server 6.0 허용하는 경우에도 해당 추가 성능 향상은 함께, 매우 중요한 데이터베이스, 인덱스, 쿼리 및 응용 프로그램 디자인을 최적화할 수 있습니다.

서버 쪽 포커스가 있는 경우에만 성공적으로 대부분의 성능 문제는 확인할 수 없습니다. 기본적으로 한 "꼭두각시들이군만" 어떤 쿼리를 보내는 제어하는 클라이언트의 서버인 어떤 잠금을 얻은 및 릴리스된 있으므로. 일부 조정 서버 쪽에서 있지만 성공적인 해상도를 성능 문제의 주요 역할을 클라이언트 문제를 합니다 승인하는 및 클라이언트 응용 프로그램 동작을 분석할 일반적으로 달라집니다.

추가 정보

발생할 상당한 성능 향상을 양보한 기준으로 몇 가지 제안 사항은 다음과 같습니다.

논리 데이터베이스 디자인 정규화

논리 데이터베이스 디자인 합리적인 정규화 최상의 성능을 얻을 수 있습니다. 좁은 테이블 더 많은 수의 정규화된 데이터베이스의 특징입니다. 하급 넓은 테이블 수가 정규화되지 않은 데이터베이스의 특징입니다. 고도로 정규화된 데이터베이스 성능이 저하될 수 있으며 복잡한 관계 조인을 사용하여, 정기적으로 연결됩니다. 그러나 효과적인 인덱스를 사용할 수 있는 한 SQL Server 최적화 프로그램은 매우 효율적인 신속한, 효율적인 조인 선택 시 있습니다.

정규화의 장점은 다음과 같습니다.
  • 테이블이 좁게 없기 때문에 정렬 및 인덱스 생성을 가속화합니다.
  • 테이블을 더 있으므로 클러스터된 인덱스를 더 있습니다.
  • 인덱스를 좁은 경향이 및 이상의 압축합니다.
  • UPDATE 성능 돕는 테이블 당 더 적은 수의 인덱스입니다.
  • NULL을 줄이고 늘리면 덜 중복 데이터 compactness 데이터베이스.
  • 필요한 테이블 잠금을 데이터를 적게 미치므로 DBCC 진단 동시성 미치는 영향이 줄어듭니다.
SQL Server와 함께 적절한 정규화는 자주 대신 hurts 성능에 도움이 됩니다. 정규화 증가하면 수는 있으므로 작업 및 데이터를 검색하는 데 필요한 조인 복잡성. 한 대략적인 경험에 따라, 이로 인해 많은 쿼리가 4방향 이상의 조인을 않으면 정규화 프로세스를 수행하는 구성하는 것이 좋습니다.

고정되어 총 논리적 데이터베이스 디자인이 이미 있습니다 재설계, 이 테이블에 대한 병목 현상이 분석을 보여 경우 큰 테이블을 선택적으로 정규화할 수 있습니다 적절하지 않습니다. 데이터베이스에 액세스할 수 있는 저장된 프로시저를 통해 수행된 경우 이 스키마 변경 적절한 응용 프로그램에 영향을 주지 않고 수행할 수 있습니다. 그렇지 않은 경우 단일 테이블처럼 보이는 보기를 만들어 변경 숨길 수 있습니다.

효율적인 인덱스 설계 사용

많은 비관계형 시스템과 달리 관계형 인덱스 논리적 데이터베이스 디자인은 일부로 간주되지 않습니다. 인덱스는 삭제할 추가하고 성능 이외의 어떤 식으로든 데이터베이스 스키마 또는 응용 프로그램 디자인에 영향을 주지 않고 변경할 수 있습니다. 효율적인 인덱스 디자인이 가장 좋은 SQL Server 성능을 달성하는 중요합니다. 이러한 이유로 사용자가 다른 인덱스를 사용해 주저하지 합니다지 않습니다.

최적화 프로그램이 안정적으로 대부분의 경우에 가장 효율적인 인덱스를 선택합니다. 전체 인덱스 디자인 전략을 최적화 프로그램에 좋은 인덱스 선택 제공하고 올바른 결정을 내릴 수 있도록 신뢰할 수 있어야 합니다. 이 분석 시간이 줄어들고 다양한 상황을 통해 좋은 성능을 제공합니다.

인덱스 디자인 권장 사항은 다음과 같습니다.
  • 최적화 프로그램의 중점적으로 때문에 SQL 쿼리의 WHERE 절을 검사하십시오.

    WHERE 절에 나열된 각 열에 대한 인덱스 가능한 후보입니다. 대표적인 집합 또는 느린 링크뿐 아니라 검사할 너무 많은 쿼리가 있는 경우 선택하십시오. 개발 도구 투명하게 SQL 코드를 생성하는 경우 더 어렵습니다. 이러한 도구 대부분의 디버깅 목적으로 파일 또는 화면 생성된 SQL 구문의 로깅을 허용합니다. 이러한 기능을 사용할 수 있는 도구의 공급업체로부터 여부 확인 할 수 있습니다.
  • 좁은 인덱스를 사용하십시오.

    좁은 인덱스를 더 경우가 종종 여러 열 복합 인덱스를 것보다 효과적입니다. 좁은 인덱스 페이지 당 더 많은 행이 및 성능을 높이는 적은 수의 인덱스 수준에 있습니다.

    최적화, 수백 또는 수천 명의 인덱스와 조인 가능성 신속하고 효과적으로 분석할 수 있습니다. 좁은 인덱스 더 많은 수의 필요 일반적으로 성능 돕는 최적화 프로그램이 함께 선택할 수 있는 자세한 가능성 제공합니다. 적은 수의 넓은, 여러 열 인덱스를 사용하면 최적화 프로그램에서를 성능이 떨어질 수 있으며 선택할 수 있는 적은 수의 가능성 함께 제공합니다.

    최상의 완전히 포함된 쿼리 강조하는 전략을 채택할 수 있습니다. SELECT 절의 모든 열이 클러스터되지 않은 인덱스에 의해 변환되지 않으면 최적화 프로그램은 이 인식하고 수 매우 우수한 성능을 제공하는 것을 마찬가지입니다. 그러나 이 종종 지나치게 넓은 인덱스는 결과 및 최적화 프로그램이 이 전략을 사용할 가능성을 너무 많이 의존합니다. 일반적으로, 종종 광범위한 쿼리를 통해 보다 나은 성능을 제공하는 더 많은 좁은 인덱스를 사용해야 합니다.

    이러한 인덱스가 업데이트와 관련된 오버헤드를 인해 적절한 읽기 성능을 얻기 위해 필요한 것보다 더 많은 인덱스를 가질 수 없습니다. 그러나 대부분의 경우에도 업데이트 지향 작업 쓰는 것보다 훨씬 읽기가 필요합니다. 따라서 시도하려면 주저하지 수행할 않는 이가 생각되는 경우 새 인덱스를 도와; 항상 개체를 나중에 놓을 수도 있습니다.
  • 클러스터된 인덱스를 사용하십시오.

    클러스터된 인덱스의 적절한 사용의 성능을 크게 향상시킬 수 있습니다. 이러한 작업을 훨씬 읽기 필요하므로 경우에도 UPDATE 및 DELETE 작업은 클러스터된 인덱스는 사용하면 종종 가속 있습니다. 테이블 당 하나의 클러스터된 인덱스를 사용할 수, 있으므로 이 인덱스 현명하게 사용하십시오. 여러 행을 반환하는 쿼리 또는 값 범위를 포함하는 쿼리가 클러스터된 인덱스에 의해 가속 좋은 좋은 결과를 얻을 수 있습니다.

    예제:
          SELECT * FROM PHONEBOOK
          WHERE LASTNAME='SMITH'
    
          -or-
    
          SELECT * FROM MEMBERTABLE
          WHERE  MEMBER_NO > 5000
           AND MEMBER_NO < 6000
    
    						
    이러한 유형의 쿼리 일반적인 반대로 위에서 언급한 성 또는 MEMBER_NO 열이 클러스터되지 않은 인덱스의 좋은 후보가 경우 않을 가능성이 큽니다. 몇 개의 행이 반환됩니다 열에 대해 클러스터되지 않은 인덱스가 사용해 보십시오.
  • 열 고유성을 검사하십시오.

    이렇게 하면 어떤 열에 대해 클러스터된 인덱스, 클러스터되지 않은 인덱스 또는 인덱스가 후보입니다 결정할 수 있습니다.

    열 고유성을 검사합니다 예제 쿼리를 아래와 같습니다.
          SELECT COUNT (DISTINCT COLNAME)
          FROM TABLENAME
    
    						
    열에서 고유 값의 개수를 반환합니다. 이 테이블에 있는 행의 총 수와 비교하십시오. 10,000 행을 테이블에서 클러스터되지 않은 인덱스의 좋은 후보가 5,000 고유 값의 열을 만듭니다. 같은 테이블에 고유 값을 20 클러스터된 인덱스가 더 잘 맞게 됩니다. 세 가지 고유 값은 전혀 인덱싱되지 않을 합니다. 이러한 유일한 예제, 하드 및 빠른 규칙이 있습니다. 쿼리의 WHERE 절이 나열된 개별 열에 인덱스를 배치해야 합니다.
  • 인덱스된 열의 데이터를 배포를 검사하십시오.

    종종 장기 실행 쿼리를 몇 가지 고유한 값 가진 열이 인덱싱된, 또는 이러한 열에 조인을 수행할 때문에 발생합니다. 이 데이터와 쿼리 자체의 기본적인 문제가, 일반적으로 이러한 상황을 확인하지 않고도 해결할 수 없습니다. 예를 들어, 성을 알파벳순으로 정렬된 실제 전화 디렉터리 도시에 모든 사람들이 "Smith" 또는 "Jones" 라는 경우 위로 사람 찾기 신속하게 됩니다 없습니다. 열 고유성을 단일 그림 제공하는 위의 쿼리를 외에도 GROUP BY 쿼리의 인덱스 키 값의 데이터 배포 볼 수 있습니다. 데이터 최적화 방법을 보기 데이터와 더 나은 관점에서 더 높은 해상도 그림을 제공합니다.

    데이터 열이 두 개인 키 COL1, COL2 가정하여 인덱싱된 키 값 배포에 대한, 검사할 예제 쿼리를 아래와 같습니다.
          SELECT COL1, COL2, COUNT(*)
          FROM TABLENAME
          GROUP BY COL1, COL2
    
    						
    각 값의 인스턴스 수 각 키 값에 대해 한 행을 반환합니다. 반환된 행 수를 줄이려면 HAVING 절을 사용하여 일부 제외하는 데 유용할 수 있습니다. 예를 들어, 절
          HAVING COUNT(*) > 1
    
    						
    고유 키가 있는 행을 모두 제외됩니다.

    쿼리에서 반환된 행 수를 수도 있는 중요한 인덱스 선택 요소입니다. 최적화 프로그램이 반환된 행 당 하나 이상의 페이지 I/O 비용 클러스터되지 않은 인덱스를 고려합니다. 이 속도로 전체 테이블을 검색할 보다 효율적으로 신속하게 됩니다. 또 다른 이유는 결과 집합의 크기를 제한하는 또는 클러스터된 인덱스가 있는 큰 결과 찾을 수 있습니다.
항상 좋은 성능 및 반대로 인덱스 사용이 대응되는지에 수행할지 않습니다. 최상의 성능을 항상 인덱스를 사용하여 생성된 경우 최적화 프로그램의 작업이 매우 단순 - 됩니다 항상 사용할 수 있는 인덱스를 사용합니다. 실제로, 인덱스된 검색 잘못 선택한 매우 불량 성능이 수 있습니다. 따라서 최적화 프로그램의 위치가 됩니다 성능, 도움말 및 인덱스된 검색을 방지할 인덱스된 검색을 선택하고 이를 성능이 저하될 것입니다 작업입니다.

효율적인 쿼리 디자인 사용

쿼리의 일부 형식은 근본적으로 리소스가 많이 있습니다. 이 기본적인 데이터베이스 및 대부분의 관계형 데이터베이스 관리 시스템 (RDBMS), SQL Server 위해 특별히 일반적인 인덱스 문제 관련이 있습니다. 가능한 가장 효율적인 방식으로 쿼리 최적화 프로그램은 구현할 때문에 비효율적인, 수 없습니다. 그러나 리소스가 많이, 그리고 집합 지향의 SQL 성격에 비효율적인 나타나게 할 수 있습니다. 최적화 프로그램은 인텔리전스 없음 정도를 이러한 구문 고유의 리소스 비용이 없앨 수 있습니다. 더 간단한 쿼리 비해 본질적으로 비용이 있습니다. SQL Server 최적의 액세스 계획을 사용하지만 이 근본적으로 가능한 여부를 기준으로 제한됩니다.

예를 들면:
  • 큰 결과 집합
  • IN, NOT IN을 OR 쿼리를
  • 고도로 고유하지 않은 WHERE 절
  • ! = (같지 않음) 비교 연산자를
  • SUM과 같은 특정 열 함수
  • WHERE 절의 식 또는 데이터 변환
  • WHERE 절의 지역 변수
  • 복잡한 뷰의 GROUP BY 함께
여러 가지 요인에 일부 이러한 쿼리 구문을 사용하면 스크롤해야 볼 수 있습니다. 최적화 프로그램이 쿼리 리소스 집중적인 부분을 적용하기 전에 결과 제한할 수 있는 경우 이러한 영향을 lessened 수 있습니다. 다음은 일부 예입니다.

리소스를 많이:
   SELECT SUM(SALARY) FROM TABLE
				

더 적은 리소스를 많이:
   SELECT SUM(SALARY) FROM TABLE WHERE
   ZIP='98052'
				

리소스를 많이:
   SELECT * FROM TABLE WHERE
   LNAME=@VAR
				

더 적은 리소스를 많이:
   SELECT * FROM TABLE
   WHERE LNAME=@VAR AND ZIP='98052'
				

첫 번째 예제에서는 SUM 작업은 인덱스와 가속 수 없습니다. 각 행은 읽고 합계될 수 합니다. 없는 것을 가정하고 인덱스를 ZIP 열에, 최적화 가능성이 이 처음에 결과 집합에 있는 SUM 적용하기 전에 제한할 수 있습니다. 훨씬 빠를 수 있습니다.

두 번째 예제에서는 지역 변수 런타임까지 확인되지 않습니다. 그러나, 최적화 프로그램이 액세스 계획 실행할 때까지 선택 지연시킬 수 없습니다. 그리고 컴파일 타임에 선택해야 합니다. 액세스 계획을 빌드할 때 아직 컴파일 타임에 @ VAR 값을 알 수 없는 및 결과적으로 인덱스 선택 입력으로 사용할 수 없습니다.

AND 절을 사용하여 결과 제한 일러스트레이션된 기술은 향상 위한 것입니다. 대체 기술을 같이 저장된 프로시저를 사용하고 값을 @ VAR 저장된 프로시저의 매개 변수로 전달하십시오.

일부 경우에 단일 매우 복잡한 쿼리를 사용하는 것보다 중간 결과를 저장할 임시 테이블을 사용하여 간단한 쿼리 그룹을 사용하는 것이 좋습니다.

큰 결과 집합을 대부분의 RDBMS를 비용이 많이 있습니다. 큰 결과 집합을 검색하여 마지막 데이터 선택 클라이언트에 반환하는 것이 좋습니다. 훨씬 더 효율적인 데이터베이스 시스템에 대해 의도된 기능을 수행할 수 있도록 결과 집합의 크기를 제한할 수 있습니다. 이 또한 네트워크 I/O 줄어들고 원격 통신을 느린 링크를 통해 응용 프로그램 배포 보다 편리한 있습니다. 응용 프로그램으로 동시성 관련 성능 또한 향상시킵니다 위쪽으로 더 많은 사용자를 배율을 조정합니다.

효율적인 응용 프로그램 디자인 사용

SQL Server 성능 응용 프로그램 디자인 수행하는 역할을 강조해도 수 없습니다. 주요 역할 서버 그림 대신 클라이언트 제어 엔터티 및 해당 서버로 클라이언트의 꼭두각시들이군만 같이 그림 데 더 정확합니다. SQL Server에서 이러한 제출될 때 쿼리 및 결과 처리 방법 종류 관련된 클라이언트 명령을 완전히 것입니다. 이 차례로 유형 및 기간 잠금의 양 I/O 및 CPU 부하, 서버의 주요 영향도 주지 및 그에 따른 성능 좋은 또는 잘못된 여부.

이 따라서, 응용 프로그램 디자인 단계에서 정확한 결정을 내리는 데 중요합니다. 그러나 클라이언트 응용 프로그램에 변경 불가능한 것처럼 보이는 턴키 응용 프로그램을 사용하여 성능 문제가 발생할 경우 이 성능에 영향을 주는 기본적인 요인을 변경할 - 즉 클라이언트가 주요 역할 및 많은 성능 문제가 재생되는 클라이언트 변경하지 않고 확인할 수 없습니다.

잘 디자인된 응용 프로그램과 SQL Server는 수천 명의 동시 사용자 지원할 수 있습니다. 잘못 설계된 응용 프로그램과 함께 가장 강력한 서버 플랫폼에서 몇 사용자와 격리할 수.

다음 방법을 사용하여 클라이언트 응용 프로그램 디자인 좋은 SQL Server 성능을 제공합니다.
  • 작은 결과 집합을 사용하십시오. 불필요하게 큰 결과 검색하는 클라이언트에서 검색 CPU 및 네트워크 I/O 로드, 응용 프로그램이 원격 사용을 덜 수 있습니다 추가하고 다중 사용자 확장성이 제한할 수 있습니다 (예: 수천 개의 행) 설정합니다. 적당한 결과 집합을 생성할 쿼리 수 있도록 충분한 입력 사용자에게 묻는 응용 프로그램이 제출한 디자인 더 좋습니다.

    이렇게 쉽게 응용 프로그램 디자인 기술이 쿼리를 쿼리 작성, 특정 입력된 필드 위임 및 prohibiting improvised 때 와일드카드 사용을 제한 등이 있습니다.
  • DB-Library 응용 dbcancel()를 제대로 사용하십시오. 모든 응용 프로그램에서 쿼리 취소 진행 허용해야 합니다. 쿼리를 취소하려면 클라이언트 컴퓨터를 다시 부팅할 수 없는 응용 프로그램을 강제로 수행해야 합니다. 다음 이 원칙을 확인할 수 없는 성능 문제가 발생할 수 있습니다. dbcancel() 사용할 때 적절한 주의는 관련하여 트랜잭션 수준은 사용될 수 합니다. 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
    117143: INF: 문서 및 dbcancel() 또는 sqlcancel() 사용 방법
    ODBC sqlcancel() 호출을 사용하면 ODBC 응용 프로그램은 동일한 문제가 적용됩니다.
  • 항상 완료될 때까지 모든 결과를 처리하십시오. 않은 응용 프로그램을 디자인할 또는 쿼리 취소 없이 결과 행 처리를 중지합니다 턴키 응용 프로그램을 사용하여. 이렇게 하면 대개 차단 및 느린 성능이 저하될 것입니다.
  • 쿼리 제한 시간을 항상 구현하십시오. 무기한으로 실행할 쿼리를 허용하지 않습니다. 적절한 DB-Library 또는 ODBC 쿼리 시간 제한을 설정하려면 호출을 확인하십시오. DB-Library이 dbsettime() 호출 및 ODBC SQLSetStmtOption() 함께 수행됩니다.
  • SQL 문 서버로 보낸 명시적인 제어가 허용되지 않는 응용 프로그램 개발 도구를 사용하지 마십시오. 쿼리 취소, 쿼리 시간 제한, 완벽한 트랜잭션 제어 등의 중요한 기능을 제공하지 않는 한 높은 수준의 개체를 기반으로 SQL 문을 투명하게 생성하는 도구를 사용하지 마십시오. 좋은 성능을 유지하는 데 또는 이 명시적인 제어가 트랜잭션 및 잠금 허용하지 않기 때문에 "투명 SQL," 모든 의해 응용 프로그램이 생성하는 경우 성능 문제가 중요한 성능 그림이 있는 문제를 해결하는 가능한 것은 종종 아닙니다.
  • 의사 결정 지원과 온라인 트랜잭션 처리 (OLTP) 쿼리가 혼합될 수행할지 않습니다.
  • 않은 응용 프로그램을 디자인할 또는 쿼리를 취소하려면 클라이언트 컴퓨터를 다시 부팅하라는 메시지를 강제로 턴키 응용 프로그램을 사용하여. 여러 가지 가능한 분리된 때문에 연결 해결하려면 어려운 성능 문제가 발생할 수 있습니다. 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
    137983: SQL Server에서 분리된 연결 문제를 해결하는 방법

느린 성능 분석 기법

시스템 수준 서버 성능 조정에 의해 전적으로 성능 문제를 해결하기 위해 비활성화될 수 있습니다. 예를 들어, 메모리, 파일 시스템 종류를, 수와 프로세서 등을 형식. Microsoft SQL Server 지원 환경을 이 방법은 대부분의 성능 문제를 해결할 수 없는 알 수 있습니다. 이러한 응용 프로그램을 분석하여 해결해야 하는, 쿼리, 데이터베이스 및 이러한 쿼리를 데이터베이스 스키마와 상호 작용하는 방법을 응용 프로그램에 전송하는.

첫째, 쿼리 또는 느린 쿼리를 분리할 수 있습니다. 종종 느린 SQL 쿼리 몇 가지 경우에만 전체 응용 프로그램의 속도가 있을 때 것을 나타납니다. 일반적으로 문제의 주요 및 느린 쿼리를 분리 않고 성능 문제를 해결할 수 없습니다. 투명하게 SQL 생성하는 개발 도구가 있는 경우 사용할 수 있는 진단 또는 디버그 모드에서 이 도구가 생성된 SQL 캡처할 수 있습니다. 대부분의 경우 추적 기능을 사용할 수 있지만 이들은 않습니다 개방적으로 문서화되어 있습니다. 응용 프로그램에 추적 기능을 응용 프로그램에서 생성한 SQL 문을 모니터링 있는지 확인하려면 기술 지원을 서비스에 문의하십시오.

포함된 SQL 사용하는 응용 프로그램 개발 도구에 대해 이 훨씬 쉽습니다 - SQL 공개적으로 볼 수 있습니다.

개발 도구 또는 최종 사용자 응용 프로그램에 추적 기능을 제공하지 않는 경우 몇 가지 대안:
  • 문제 해결 가이드 및 SQL Server 6 x SQL Server에서 4.2 지시 따라 4032 추적 플래그를 사용하여 "Transact-SQL 참조." 캡처 SQL 문의 SQL 오류 로그에서 서버로 보낼 수 있습니다.
  • Microsoft 네트워크 같은 네트워크 분석기를 통해 쿼리를 모니터링하여 모니터, SMS의 일부입니다.
  • ODBC 응용 프로그램은 ODBC 관리자 프로그램을 ODBC 호출 추적 선택할 수 있습니다. 자세한 내용은 ODBC 설명서를 참조하십시오.
  • DB-Library 또는 ODBC 계층에서 SQL 가로채고 타사 클라이언트 유틸리티를 사용하십시오. 이 파란색 Lagoon 소프트웨어에서 SQL 검사를 예입니다.
  • 예를 들어 Microsoft TechNet CD에서, 제공하는 SQLEye 분석 도구를 사용하십시오. 참고: Microsoft 기술 지원 SQLEye 지원되지 않습니다.
쿼리가 느리게 격리한 후 다음과 같이 하십시오.
  • ISQL, 같은 쿼리 도구를 사용하여 격리 의심되는 느린 쿼리를 실행하고 느린 있는지 확인하십시오. 서버 컴퓨터 자체에 쿼리를 실행하는 데 가장 좋은 경우가 ISQL 및 로컬 파이프를 사용하여 및 출력을 파일로 리디렉션합니다. 네트워크 및 I/O, 화면 및 응용 프로그램 결과 버퍼링 등의 복잡한 요인이 없앨 수 있습니다.
  • STATISTICS IO SET ON 사용하여 쿼리에 의해 소비되는 I/O 검사합니다. I/O 논리 페이지 수를 알 수 있습니다. 최적화 프로그램의 목적은 I/O 수를 최소화하는 것입니다. 논리 I/O 수가 레코드를 확인하십시오. 초기 계획을 향상을 측정할 형성합니다. ON SET SHOWPLAN 사용하는 것보다 더 효과적입니다 STATISTICS IO 출력 단독으로 강조하며 및 다른 쿼리를 사용해 인덱스 형식을 경우가 많습니다. 일부, 살펴보고 보다 효과적으로 경험 테스트에 소요되는 시간을 소비할 수 해석 및 SHOWPLAN 출력에 효과적으로 적용하는 요구할 수 있습니다. 다음 이러한 간단한 권장 사항은 성능 문제가 해결된 경우는 SHOWPLAN 보다 철저하게 최적화 문제를 조사할 수 있습니다.
  • 뷰 또는 저장된 프로시저를 사용하여 쿼리에 포함되어 있으면 쿼리를 뷰 또는 저장된 프로시저를 추출하여 별도로 실행하십시오. 이 액세스 계획을 다른 인덱스를 테스트할 때 변경할 수 있습니다. 최적화 프로그램이 뷰 또는 저장된 프로시저를 처리하는 방법을 비교 쿼리에 자체에 문제가 지역화할 수 있습니다. 문제가 쿼리에 자체를 있지만 경우에만 때 쿼리가 뷰 또는 저장된 프로시저의 일부로 실행될 있지 않으면 쿼리 자체를 실행하는 이 결정할 수 있습니다.
  • 가능한 트리거는 트리거가 실행될 때 투명하게 I/O 생성할 수 있는 관련된 테이블에 대해 잘 알고 있어야 합니다. 느린 쿼리에 관련된 모든 트리거 제거해야 합니다. 이 문제를 쿼리에서 자체를 트리거 또는 뷰, 따라서 도움이 사용자의 포커스를 직접 경우 확인할 수 있습니다.
  • 느린 쿼리에서 사용하는 테이블에 인덱스를 검사하십시오. 이러한 좋은 인덱스가 있는지 확인하려면 이전에 나열된 기술을 사용하고 필요한 경우 변경하십시오. 첫 번째 노력 WHERE 절의 각 열에 인덱싱을 보십시오. 인덱싱된, WHERE 절에 열을 단순히 필요 또는 유용한 인덱스가 이러한 열이 필요 종종 성능 문제가 발생됩니다.
  • 앞에서 설명한 쿼리를 사용하여 데이터 고유성 및 배포 WHERE 절에서 언급한 각 열에 대해, 특히 각 인덱스된 열의 검사하십시오. 대부분의 경우 쿼리, 테이블, 인덱스 및 데이터 중 간단한 검사 문제의 원인을 즉시 표시됩니다. 예를 들어, 성능 문제가 자주 인덱스 키 셋 또는 네 개의 고유한 값이 필요 또는 그러한 열에 대해 조인을 수행하는 또는 행 수가 너무 많으면 클라이언트로 반환하는 인해 발생합니다.
  • 이 연구에 따르면 응용 프로그램, 쿼리 또는 인덱스가 필요한 대로 변경하십시오. 변경을 마친 후 다시 쿼리를 실행하고 I/O 수가 변경에 관찰하십시오.
  • 개선 감안한 후 전체 성능이 더 나은 있는지 주 응용 프로그램을 실행하십시오.
I/O 또는 CPU 바인딩 동작을 위해 프로그램을 확인하십시오. 유용한 쿼리를 I/O 또는 CPU 바인딩되어 있는지 확인할 수 있습니다. 이 개선 노력을 true 병목 상태가 있는 데 도움이 됩니다. 쿼리를 CPU 바인딩된 경우 예를 들어, SQL Server 메모리를 성능이 향상됩니다 것 때문에 캐시에 더 많은 메모리를 경우에만 향상됩니다 추가 경우 이미 높은 수, 적중률.

I/O 및 CPU 바인딩된 쿼리 동작 검사 방법:
  • Windows NT 성능 모니터를 사용하여 CPU 작업이 대 조사식 I/O. 해당 LogicalDisk "% 디스크 시간 카운터의 모든 인스턴스를 시청할 개체입니다. 시청할 수도 있는 "합계 % Processor Time" 시스템에 대한 카운터 개체. 유효한 디스크 성능 정보를 보려면 사용자가 이전에 Windows NT DISKPERF 설정에 따라 실행하여 설정해 "diskperf -Y" 명령 프롬프트 및 다음 시스템을 다시 부팅하면. 자세한 내용은 Windows NT 설명서를 참조하십시오.
  • 쿼리를 실행하는 동안 CPU 그래프 (예를 들어, 70% 보다 큰), 지속적으로 높은 "% 디스크 시간 값이 일관되게 낮은 경우 이 CPU 바인딩 상태를 나타냅니다.
  • 쿼리를 실행하는 동안 CPU 그래프 (예를 들어, 50% 미만), 일관되게 낮은 "디스크 시간 %" 지속적으로 높은 경우 이 상태가 있는 I/O 바운드 나타냅니다.
  • STATISTICS IO 정보로 CPU 그래프를 비교하십시오.

결론

SQL Server 매우 높은 성능에 큰 데이터베이스 사용할 수 있습니다. 특히 SQL Server 6.0 마찬가지입니다. 잠재적인 이 성능을 얻기 위해서는 효율적인 데이터베이스, 인덱스, 쿼리 및 응용 프로그램 디자인을 사용해야 합니다. 이러한 영역에서 성능이 향상되는 얻기 위한 좋은 후보가 표시됩니다. 각 쿼리를 더 많은 사용자가 응용 프로그램을 확장하는 때 집합적 다중 사용자 로드를 지원 가능한 수 있도록 가능한 한 효율적으로 만들어 봅니다. 클라이언트 응용 프로그램 동작 인덱스가 이 문서의 지침을 사용하여 응용 프로그램 및 실험 제출한 쿼리 연구를 것을 적극 권장합니다. 성능 문제를 분석하는 조직적인 방법은 비교적 적은 시간 투자에 대한 중요한 개선 종종 yield 됩니다.

속성

기술 자료: 110352 - 마지막 검토: 2005년 2월 22일 화요일 - 수정: 3.1
본 문서의 정보는 다음의 제품에 적용됩니다.
  • Microsoft SQL Server 4.21a Standard Edition
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 6.5 Standard Edition
키워드:?
kbmt kbinfo kbother KB110352 KbMtko
기계 번역된 문서
중요: 본 문서는 전문 번역가가 번역한 것이 아니라 Microsoft 기계 번역 소프트웨어로 번역한 것입니다. Microsoft는 번역가가 번역한 문서 및 기계 번역된 문서를 모두 제공하므로 Microsoft 기술 자료에 있는 모든 문서를 한글로 접할 수 있습니다. 그러나 기계 번역 문서가 항상 완벽한 것은 아닙니다. 따라서 기계 번역 문서에는 마치 외국인이 한국어로 말할 때 실수를 하는 것처럼 어휘, 구문 또는 문법에 오류가 있을 수 있습니다. Microsoft는 내용상의 오역 또는 Microsoft 고객이 이러한 오역을 사용함으로써 발생하는 부 정확성, 오류 또는 손해에 대해 책임을 지지 않습니다. Microsoft는 이러한 문제를 해결하기 위해 기계 번역 소프트웨어를 자주 업데이트하고 있습니다.
더 이상 지원되지 않는 제품의 KB 내용에 대한 고지 사항
이 문서에서는 Microsoft에서 더 이상 지원하지 않는 제품에 대해 설명합니다. 따라서 이 문서는 "있는 그대로" 제공되며 업데이트되지 않습니다.

피드백 보내기

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com