저장 프로 시저 끝에서 임시 테이블을 잘라내어 tempdb 공간을 더 빨리 확보하는 이유는 무엇입니까?


12

SQL Server는 저장 프로 시저 내에서 생성 된 임시 테이블을 캐시하고 프로 시저가 끝나고 이후에 실행될 때 이름을 바꿉니다. 내 질문은 tempdb 공간이 해제 될 때 관련이 있습니다. 절차가 끝날 때 테이블이 잘린다 는 것을 읽었습니다 . 세션별로 처리 되며 MSDN에서 정리가 필요한지 여부에 대한 질문을 읽었습니다 . 그러나 같은 세션에서 두 번 실행되지 않으면 어떻게 될까요?

또한 테이블이 범위를 벗어나면 해당 공간을 비우는 백그라운드 가비지 수집 프로세스가 있다고 들었습니다.

저장 프로 시저가 끝날 때 임시 테이블을 잘라 내면 테이블이 tempdb에서 사용하는 공간이 잘림 명령문이 사용되지 않는 경우보다 테이블이 더 빨리 해제되도록하는 데 반해 예상됩니다. 왜?

그러한 잘림 명령문을 사용하거나 사용하지 않을 때의 성능에 미치는 영향은 무엇입니까? SNAPSHOT 격리를 사용할 때 tempdb가 종종 스트레스를받으며 가능한 한 빨리 큰 temp 테이블에서 tempdb에 사용 된 공간을 해제하면 불필요한 tempdb의 성장을 막을 수 있다고 생각합니다. 이 잠재적 인 공간 절약이 성능 비용으로 발생합니까?

문제를 재현하는 코드는 다음과 같습니다 (대부분 @TheGameiswar에서 약간 변경됨).

SET NOCOUNT ON;
GO
ALTER PROC usp_test
AS
BEGIN
    IF object_id('tempdb..#temp') IS NOT NULL
        DROP TABLE #temp

    SELECT *
    INTO #temp
    FROM [dbo].[Event_28] -- This is a table with 15313 rows, using 35648 KB according to sp_spaceused

    --SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
    --  ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
    --  ,getdate() AS BeforeTruncate
    --FROM tempdb.sys.dm_db_file_space_usage;
 --   TRUNCATE TABLE #temp
    --SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
    --  ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
    --  ,getdate() AS AfterTruncate
    --FROM tempdb.sys.dm_db_file_space_usage;

END
GO

SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
    ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
    ,getdate() AS 'before'
FROM tempdb.sys.dm_db_file_space_usage;

EXEC usp_test
GO

SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
    ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
    ,getdate() AS 'final'
FROM tempdb.sys.dm_db_file_space_usage;
GO 40

주석 처리 된 행은 일부 실행에 대해서는 주석 처리되고 나머지는 주석 처리되지 않습니다. 이 때 TRUNCATE주석하고,이 결과 전에 2.25 사이에 4.5 초 걸렸 tempdb.sys.dm_db_file_space_usage프로 시저가 실행되기 전에 결과를 일치하는 쿼리 (4472 이상의 페이지 및 34.9375 MB 이상). TRUNCATE주석 처리되지 않은 행을 사용하면 약 0.11-0.9 초 밖에 걸리지 않습니다. 이 결과는 실제 시스템에서 얻은 것이며이 실험 동안 소스 테이블에서 약간의 데이터 증가가있었습니다.

코드가 주석 처리 된 샘플 출력 (처음 "마지막"항목에서 2.69 초) :

user object pages used user object space in MB                 before
---------------------- --------------------------------------- -----------------------
1536                   12.000000                               2017-10-04 21:03:42.197

Beginning execution loop
user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.423

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.533

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.643

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.883

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.990

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.100

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.450

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.650

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.767

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.993

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.103

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.213

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.437

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.553

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.663

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.887

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:45.003

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
1536                   12.000000                               2017-10-04 21:03:45.113

주석 처리되지 않은 코드가있는 샘플 결과 (첫 번째에서 마지막 "최종"항목까지 0.11 초) :

user object pages used user object space in MB                 before
---------------------- --------------------------------------- -----------------------
1536                   12.000000                               2017-10-04 21:07:39.807

user object pages used user object space in MB                 BeforeTruncate
---------------------- --------------------------------------- -----------------------
6016                   47.000000                               2017-10-04 21:07:39.923

user object pages used user object space in MB                 AfterTruncate
---------------------- --------------------------------------- -----------------------
6016                   47.000000                               2017-10-04 21:07:39.923

Beginning execution loop
user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6016                   47.000000                               2017-10-04 21:07:40.160

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
1536                   12.000000                               2017-10-04 21:07:40.270

답변:


12

저장 프로 시저가 끝날 때 임시 테이블을 잘라 내면 테이블이 tempdb에서 사용하는 공간이 잘림 명령문이 사용되지 않는 경우보다 테이블이 더 빨리 해제되도록하는 데 반해 예상됩니다. 왜?

임시 테이블이 충분히 큰 경우 (128 개가 넘는 익스텐트 ) 실제 페이지 할당 해제가 지연되고 백그라운드 시스템 태스크에 의해 수행됩니다. 이는 명시 적 해당됩니다 TRUNCATE TABLE사용되거나되지 않습니다.

유일한 차이점은 작은 구현 세부 사항입니다. 임시 테이블 정리에 의해 생성 된 지연 삭제 작업 보다 타이머더 짧은TRUNCATE TABLE 작업을 생성하면 명시 적으로 발생합니다 .

사람들이 좋아하기 때문에 전화 스택

우연이든 의도적 인 것인지는 누구나 추측 할 수 있습니다. 이 세부 수준은 지원되는 제품 표면적을 넘어서므로 언제든지 변경 될 수 있습니다.

(대부분) 문서화되지 않은 추적 플래그를 사용하여 지연된 삭제를 전체적으로 비활성화하는 경우 :

DBCC TRACEON (671, -1);

할당 해제는 두 경우 모두 동 기적으로 수행되며 타이밍에 차이가 없습니다.

그러한 잘림 명령문을 사용하거나 사용하지 않을 때의 성능에 미치는 영향은 무엇입니까? SNAPSHOT 격리를 사용할 때 tempdb가 종종 스트레스를받으며 가능한 한 빨리 큰 temp 테이블에서 tempdb에 사용 된 공간을 해제하면 불필요한 tempdb의 성장을 막을 수 있다고 생각합니다. 이 잠재적 인 공간 절약이 성능 비용으로 발생합니까?

나는 이것이 어느 쪽이든 큰 변화를 가져올 것이라고 진지하게 의심한다. tempdb 가 워크로드의 최대 요구 사항에 맞게 적절한 크기로 조정 된 경우 1 초 또는 3 초 후에 지연된 드롭이 발생하는지 여부는 중요하지 않습니다. 동일한 작업이 수행됩니다. 타이밍의 작은 차이 일뿐입니다.

반면에 : TRUNCATE TABLE저장 프로 시저가 끝날 때 임시 테이블을 사용 하는 것이 더 편안하다고 생각되면 그와 함께하십시오. 나는 이것을하는 데 특별한 단점을 알지 못한다.

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