2010-01-13 4 views
2

저는보고를 위해 사용 된 약 75 개의 저장 프로 시저 (다른 누군가가 작성한)의 성능을 향상시켜야하는 상황에 처해 있습니다. 내 솔루션의 첫 번째 부분은 대량의보고에 사용될 약 6 개의 비정규 화 테이블을 작성하는 것이 었습니다. 이제 테이블을 만들었으므로 저장된 procs의 성능을 최대로 향상시키기 위해 Indexes를 결정해야하는 다소 어려운 작업이 있습니다.어떤 색인을 작성해야하는지 식별하기위한 제안 사항은 무엇입니까?

인덱스에 어떤 열을 포함시키는 것이 바람직한 지 알고 싶다면 궁금한 점이 있습니까? 프로필러/DTA를 사용하거나 인기있는 열을 알아 내기 위해 아래와 같은 쿼리를 사용하는 것을 고려했습니다.

SELECT name, Count(so.name) as hits, so.xtype 
from syscomments as sc 
INNER JOIN sysobjects so ON sc.id=so.id 
WHERE sc.text like '%ColumnNamme%' 
AND xtype = 'P' 
Group by name,so.xtype 
ORDER BY hits desc 

이 75 개의 procs을 수동으로 조사 할 필요가없는 아이디어가 있으면 알려주십시오.

또한 삽입은이 DB에서만 하루에 한 번 수행되므로 삽입 성능은 큰 문제가되지 않습니다.

답변

1

SSMS에서 SQL Server 프로파일 러를 사용하여 테이블이 호출되는 대상과 방법을 확인한 다음 프로파일 러의 Database Tuning Tool을 사용하여 올바른 경로를 시작하도록 할 수 있습니다. 나는 대부분의 DBA가 아마도이 점에 대해 비명을 질렀다는 것을 알지만, 나 자신과 같은 비 DBA 유형은 적어도 우리에게 출발점을 제공합니다.

+1

그래, 내가 생각하고있는 옵션 중 하나이다. 나는 많은 사람들로부터이 방법으로 인덱스를 생성해서는 안된다는 말을 들었다. –

+0

나는 꽤 많은 양의 튜닝을했는데 이것은 큰 성공을 거두었 다. 프로파일 러에서 모든 종류의 유용한 정보, 특히 CPU 및 디스크 IO 용도를 얻을 수 있습니다. 그러면 어떤 SP가 가장 느린 지 (또는 적어도 튜닝에서 가장 많은 이점을 얻을 수있는 SP) 표시됩니다. 그런 다음 열어 놓은 쿼리를 열어보고 쿼리 계획을 살펴볼 수 있습니다. 그러나 SQL 쿼리 계획을 실제로 이해하는 사람이 있습니까? – MrTelly

+0

대부분의 사람들은 profiler/dta를 사용하여 내가 필요한 색인을 얻는 것이 좋다고 생각하는 것 같습니다. 몇 시간 동안 프로덕션 서버에서 프로파일 러를 실행하면 어떤 문제가 발생할 수 있습니까? –

2

모든 활동이 75 개의 저장 프로 시저에서 비롯된 것이라면 프로파일 러를 사용하여 가장 길게 걸리는 저장 프로 시저를 추적하고 가장 많이 호출됩니다. 어떤 항목인지 알고 있으면 해당 항목을보고 Where 절과 JOIN ON 섹션에서 가장 많이 사용되는 열을 확인하십시오. 대부분 클러스터되지 않은 인덱스를 넣을 열입니다. 일련의 열이 함께 사용되는 경우 그룹에 클러스터되지 않은 인덱스를 1 개 만들려는 경우가 많습니다. 테이블에 많은 비 클러스터형 인덱스를 가질 수는 있지만 (250), 소수 이상을 넣고 싶지는 않을 것입니다. 데이터가 검색되고 동일한 열에서 반복적으로 검색된다는 것을 알게 될 것입니다. 80/20 규칙을 기억하십시오. 자신이하는 일의 처음 20 %에서 속도 증가의 80 %를 얻게 될 것입니다. 추가 된 인덱스에 대한 속도 증가가 거의 없기 때문에 즉, 중지하려는 시점이 있습니다.

3

어떤 색인을 생성해야하는지 식별하기위한 제안 사항은 무엇입니까?

예!Sql Server에 문의하십시오.

Sql Server는 성능 향상을 위해 사용할 수있는 인덱스에 대한 통계를 자동으로 보관합니다. 이것은 이미 백그라운드에서 진행되고 있습니다.

SELECT mig.*, statement AS table_name, 
    column_id, column_name, column_usage 
FROM sys.dm_db_missing_index_details AS mid 
CROSS APPLY sys.dm_db_missing_index_columns (mid.index_handle) 
INNER JOIN sys.dm_db_missing_index_groups AS mig ON mig.index_handle = mid.index_handle 
ORDER BY mig.index_group_handle, mig.index_handle, column_id; 

하는 것은 물론, 당신은 실제 실행을 프로파일 링해야합니다 정보의 실시간, 정확한 활용하기 :
http://msdn.microsoft.com/en-us/library/ms345417.aspx

(오른쪽 MSDN에서 촬영)이 같은 쿼리를 실행 해보십시오 :이 링크를 참조하십시오 변경 전과 후에 키 절차의 시간.

2

bechbd와 동의합니다. 실제 업무 시간 동안 프로덕션 시스템에서 서버 추적을 실행하여 최상의 스냅 샷을 얻고 데이터베이스 트래픽의 좋은 샘플을 사용하고 데이터베이스 튜닝 관리자가 해당 샘플링을 분석하도록하십시오.

동의하지 않습니다. 맹목적으로은 데이터베이스 튜닝 어드바이저가 지시 한 모든 것에 의존합니다. 단지 권장 사항 일 뿐이지 만 DTA는 모든 것을 고려할 수 없습니다. 물론 - 인덱스를 추가하면 쿼리 속도를 높일 수 있지만 동시에 삽입 및 업데이트 속도를 늦출 수 있습니다.

또한 실제로 도움이되는지 알아 보려면 구현하고, 다시 측정하고, 비교해야합니다. 실제로 신뢰할 수있는 유일한 방법입니다. 너무 많은 변수와 알려지지 않은 변수가 있습니다.

물론 DTA를 사용하여 단일 쿼리를 미세 조정하여 터무니없이 잘 수행 할 수 있지만이 쿼리는 일주일에 한 번만 호출되거나이 쿼리를 조정하여 인덱스를 추가하면 다른 쿼리가 손상 될 수 있습니다.

인덱스 튜닝은 항상 균형, 트레이드 오프 및 시행 착오 게임입니다. 정확한식이 요법과 요리 책으로 엄격하게 결정합니다.

0

이 데이터베이스가 완전히보고 데이터베이스이며 성능이 필요한 경우 데이터웨어 하우스 디자인으로 이동하는 것이 좋습니다. 별 또는 눈송이 스키마는보고와 관련하여 비정규 관계형 디자인을 능가합니다.

관련 문제