2

지형 공간 내에있는 모든 레코드 ("geography")를 반환하는 저장 프로 시저가 있습니다. CTE (with), 일부 공용체, 일부 내부 조인을 사용하고 데이터를 XML로 반환합니다. 논쟁이나 최첨단은 아니지만 사소한 것도 아닙니다.Sql Server 2008에서 Sql Server 2016으로 업그레이드 한 후 속도가 느린 저장 프로 시저의 속도가 느림니다.

이 저장 프로 시저는 SQL Server 2008에서 수년 동안 잘 작동 해 왔습니다. 상대적으로 느린 서버에서 1 초 이내에 실행되었습니다. Microsoft는 많은 메모리와 초고속 SDD를 갖춘 초고속 서버에서 SQL Server 2016으로 마이그레이션했습니다.

전체 데이터베이스 및 관련 응용 프로그램은이 새로운 서버에서 이라는 매우 빠르며 매우 만족합니다. 그러나이 저장 프로 시저는 정확히 동일한 매개 변수와 정확히 동일한 데이터 집합에 대해 1 초가 아닌 16 초로 실행됩니다.

이 데이터베이스의 색인 및 통계를 업데이트했습니다. 또한 데이터베이스의 호환성 수준을 100에서 130으로 변경했습니다.

흥미로운 점은 임시 테이블을 사용하고 CTE를 사용하는 대신 '삽입'하는 저장 프로 시저를 다시 작성했기 때문입니다. 이로 인해 시간이 16 초에서 4 초로 줄어 들었습니다.

실행 계획은 병목 현상이 어디에서 발생하는지 명백한 통찰력을 제공하지 않습니다.

우리는 약간의 아이디어를 고집하고 있습니다. 우리는 다음에 무엇을해야합니까? 미리 감사드립니다.

- 나는 지금 내가 인정하는 걱정보다이 문제에 더 많은 시간을 보냈습니다

. 저장 프로 시저를 다음 쿼리로 압축하여 문제를 보여줍니다. 저장 프로 시저와

drop table #T 

declare @viewport sys.geography=convert(sys.geography,0xE610000001041700000000CE08C22D7740C002370B7670F4624000CE08C22D7740C002378B5976F4624000CE08C22D7740C003370B3D7CF4624000CE08C22D7740C003378B2082F4624000CE08C22D7740C003370B0488F4624000CE08C22D7740C004378BE78DF4624000CE08C22D7740C004370BCB93F4624000CE08C22D7740C004378BAE99F4624000CE08C22D7740C005370B929FF4624000CE08C22D7740C005378B75A5F4624000CE08C22D7740C005370B59ABF462406F22B7698E7640C005370B59ABF462406F22B7698E7640C005378B75A5F462406F22B7698E7640C005370B929FF462406F22B7698E7640C004378BAE99F462406F22B7698E7640C004370BCB93F462406F22B7698E7640C004378BE78DF462406F22B7698E7640C003370B0488F462406F22B7698E7640C003378B2082F462406F22B7698E7640C003370B3D7CF462406F22B7698E7640C002378B5976F462406F22B7698E7640C002370B7670F4624000CE08C22D7740C002370B7670F4624001000000020000000001000000FFFFFFFF0000000003) 

declare @outputControlParameter nvarchar(max) = 'a value passed in through a parameter to the stored that controls the nature of data to return. This is not the solution you are looking for' 

create table #T 
    (value int) 

insert into #T 
select 136561 union 
select 16482 -- These values are sourced from parameters into the stored proc 

select 
     [GeoServices_Location].[GeographicServicesGatewayId], 
     [GeoServices_Location].[Coordinate].Lat, 
     [GeoServices_Location].[Coordinate].Long 

     from GeoServices_Location 

     inner join GeoServices_GeographicServicesGateway 
      on GeoServices_Location.GeographicServicesGatewayId = GeoServices_GeographicServicesGateway.GeographicServicesGatewayId 

     where 
     (
      (len(@outputControlParameter) > 0 and GeoServices_Location.GeographicServicesGatewayId in (select value from #T)) 
      or (len(@outputControlParameter) = 0 and GeoServices_Location.Coordinate.STIntersects(@viewport) = 1) 
     ) 
     and GeoServices_GeographicServicesGateway.PrimarilyFoundOnLayerId IN (3,8,9,5) 

GO 

는 2016

http://www.filedropper.com/newserver-slowexecutionplan

http://www.filedropper.com/oldserver-fastexecutionplan

윈도우 서버 2016은 SQL Server 2008의 0 초와 SQL 서버에 5 초에서 실행이 아래로 삶은 Geospatial Intersects에서 걸린 시간의 94 %는 질식 공간에서 발생합니다. Sql Server 2008은 해시 매칭 (Hash Matching) 및 병렬 처리 (Parallelism) 및 기타 표준 작업을 비롯한 여러 단계로 시간을 보냅니다.

동일한 데이터베이스임을 기억하십시오. 하나는 SQL Server 2016 컴퓨터로 복사되었으며 호환성 수준이 높아졌습니다.

문제를 해결하기 위해 실제로 SQL Server 2016이 질식하지 않도록 저장 프로 시저를 다시 작성했습니다. 나는 250msec에서 달리고있다. 그러나 이것은 처음부터 발생해서는 안되며 이전에는 효율적으로 실행되지 않는 다른 미리 정의 된 쿼리 나 저장 프로 시저가 있다는 점을 우려하고 있습니다.

미리 감사드립니다.

-

또한, 나는 서비스의 매개 변수를 시작 TRACEFLAG -T6534를 추가하는 제안을했다. 그것은 질의 시간과 아무런 차이가 없었다. 또한 쿼리 끝 부분에 옵션 (QUERYTRACEON 6534)을 추가하려고 시도했지만 아무런 차이가 없었습니다.데이터의 성장/이전 서버 (데시벨) 구성 대 새 서버 (데시벨)에 로그 파일을

+0

, 그것은 말하기 어렵다 계획 또는 스키마를 보지 않고 .... –

+2

저장 프로 시저가 SQL 서버에 도입 된 새로운 카디널리티 추정의 피해자가 될 수있다 2014 (QUERYTRACEON은'옵션을 사용해보십시오 9481)'추적 플래그. 이렇게하면 이전 추정기가 사용됩니다. SP가 정상적으로 실행되면 새로운 카디널리티 평가 기가 문제를 만듭니다. –

+0

큰 제안에 감사드립니다. 나는 그것에 대해 몰랐다. 불행하게도 그것은 아무런 차이를 만들지 않았습니다. – DJA

답변

0
  1. 검사는 다음 DB 쿼리는 + tempdb에
  2. 체크에 I/O 버퍼의 로그를 실행 오류
  3. DB의 확인 복구 모델 - 단순 대 전체/대량
  4. 이것은 일관된 동작입니까? 실행 중에 프로세스가 실행 중일 수 있습니까?
  5. 통계/색인 관련 - 정확한 데이터 샘플에서 실행되고 있습니까? (계획을보세요)

더 많은 것들을 점검/완료 할 수 있습니다. 그러나이 질문에는 충분한 정보가 없습니다.

4

제공 한 쿼리 계획에서 더 새로운 서버 버전에서는 공간 인덱스가 사용되지 않습니다. 내가 힌트와 함께 문제가 너무 힌트와 함께 나의 제안은 실제로에 도움이되지 않습니다이다 OR 쿼리 조건에서 동작을 볼

select 
    [GeoServices_Location].[GeographicServicesGatewayId], 
    [GeoServices_Location].[Coordinate].Lat, 
    [GeoServices_Location].[Coordinate].Long 
from GeoServices_Location with (index ([spatial_index_name]))... 

: 사용 공간 인덱스 힌트 확인 쿼리 최적화 공간 인덱스 계획을 선택하게합니다 이 경우. 그러나이 술어는 @outputControlParameter에 의존하므로이 두 사례를 구분하여 쿼리를 다시 작성하면 도움이 될 수 있습니다 (아래 제안 참조). 또한 쿼리 계획에서 SQL 2016이 직렬 인 동안 SQL 2008의 쿼리 계획이 병렬이라는 것을 알 수 있습니다. 옵션 (recompile, querytraceon 8649)을 사용하여 병렬 계획을 강제 실행하십시오 (새로운 초고속 서버에 이전 코어보다 많은 코어가있는 경우 도움이됩니다). 잘

if (len(@outputControlParameter) > 0) 
    select 
    [GeoServices_Location].[GeographicServicesGatewayId], 
    [GeoServices_Location].[Coordinate].Lat, 
    [GeoServices_Location].[Coordinate].Long 

    from GeoServices_Location 

    inner join GeoServices_GeographicServicesGateway 
    on GeoServices_Location.GeographicServicesGatewayId = GeoServices_GeographicServicesGateway.GeographicServicesGatewayId 

    where 
    GeoServices_Location.GeographicServicesGatewayId in (select value from #T)) 
    and GeoServices_GeographicServicesGateway.PrimarilyFoundOnLayerId IN(3,8,9,5) 
    option (recompile, querytraceon 8649) 
else 
    select 
    [GeoServices_Location].[GeographicServicesGatewayId], 
    [GeoServices_Location].[Coordinate].Lat, 
    [GeoServices_Location].[Coordinate].Long 

    from GeoServices_Location with (index ([SPATIAL_GeoServices_Location])) 

    inner join GeoServices_GeographicServicesGateway 
    on GeoServices_Location.GeographicServicesGatewayId = GeoServices_GeographicServicesGateway.GeographicServicesGatewayId 

    where 
    GeoServices_Location.Coordinate.STIntersects(@viewport) = 1 
    and GeoServices_GeographicServicesGateway.PrimarilyFoundOnLayerId IN (3,8,9,5) 
    option (recompile, querytraceon 8649) 
+0

두산, 이것은 큰 제안이었습니다. 그래서 내가 이것을 할 때 '쿼리 프로세서는이 쿼리에 정의 된 힌트 때문에 쿼리 계획을 생성 할 수 없습니다. 힌트를 지정하지 않고 SET FORCEPLAN을 사용하지 않고 쿼리를 다시 제출하십시오. ' 이것은 매우 이상하지만이 게시물에 나를 이끌; https://blogs.msdn.microsoft.com/psssql/2013/12/09/spatial-index-is-not-used-when-subquery-used/ 3 가지 포인트 중 어느 것도이 상황을 다루지 않지만 3 번은 가깝고 우리의 상황을 설명합니다. 어쩌면 여기서 뭔가를 할 수 있을까요? 말씀 드렸더니,이 게시물은 SQL Server 2008이 어디에서 왔는지를 나타냅니다. – DJA

+0

"with (index ([SPATIAL_GeoServices_Location]))")을 추가하고 Sql Server 2008 결과와 동일한 'Query processor could not produce ... ...'오류가 발생합니다. – DJA

+0

지금보고있는 내용을 확인합니다. 나는 새로운 제안으로 대답을 편집했다 – Dusan