공간을 확보하기 위해 DBCC CLEANTABLE을 실행할시기를 결정하는 신뢰할 수있는 방법이 있습니까?


11

최근 파일 사용률이 80 %에 가까워지면 파일을 늘리는 대신 힙 조각 모음, 클러스터 된 인덱스 추가 및 삭제, 행 또는 페이지 압축 구현 등과 같은 일반적인 트릭을 통해 공간을 확보하는 데 더 적극적이었습니다.

그러나 DBCC CLEANTABLE 을 실행하여 더 많은 공간을 확보 할 수있는 경우가 있습니다. 내 환경에 수백 개의 데이터베이스가 있으면 각 사용자가 수행하는 작업을 알 수 없으며 고정 길이 열 삭제와 관련된 변경 사항이 있음을 완전히 수용 할 수 있습니다. 필자는 필자가 작성한 일부 객체 공간 활용 스크립트에서 행 수와 페이지 수를 살펴보면서 이러한 기회를 발견했습니다. 이러한 종류의 시나리오 감지를 자동화하여 한 단계 더 나아가고 싶습니다.

내가 알고 싶은 것은 외부의 누군가가 이러한 종류의 기회를 적극적으로 모니터링하고 있다면 그렇다면 무엇을 구체적으로 찾으십니까?

내 생각은 행의 최대 및 최소 크기, 테이블의 행 수, 할당 된 페이지 수 및 사용 된 페이지 수를 수집 한 다음 기본적인 수학을 수행하여 결과를 기록하는 줄을 따라 무언가를 작성하는 것이 었습니다. "예상되는 것"밖에 있습니다.


큰 테이블에는 batch_size 매개 변수를 사용하는 것이 좋습니다. 이로 인해 하나의 거대한 트랜잭션과 달리 일련의 트랜잭션에서 명령이 실행됩니다.
datagod

답변:


11

이 문제에 대한 해결책은 데이터베이스의 모든 테이블에 대해 sp_spaceused 를 실행 하고이 데이터를 테이블에 저장 하는 작업을 매주 실행하는 것 입니다. 각 테이블의 크기가 ..let..10 %보다 크면 dbcc 정리 테이블을 실행합니다.

테이블 크기를 반복하는 코드는 다음과 같습니다.

if OBJECT_ID ('tempdb.dbo.#temp') is not null
    drop table #temp;

if OBJECT_ID ('dbo.BigTables') is not null
    drop table dbo.BigTables;
go

CREATE TABLE [dbo].[BigTables] (
    [table_name] [sysname] NOT NULL,
    [row_count] [int] NULL,
    [col_count] [int] NULL,
    [data_size] [varchar](50) NULL,
    [Date] [datetime] NOT NULL,
    [DBName] [nvarchar](128) NULL
);
GO

CREATE TABLE #temp (
    table_name sysname ,
    row_count int,
    reserved_size varchar(50),
    data_size varchar(50),
    index_size varchar(50),
    unused_size varchar(50)
);
go

INSERT     #temp
EXEC       sp_msforeachtable 'sp_spaceused ''?'''

insert into dbo.BigTables
SELECT     a.table_name,
           a.row_count,
           count(*) as col_count,
           a.data_size,
           getdate() as [Date],
    'MY DB' as DBName
FROM       #temp a
INNER JOIN information_schema.columns b
           ON a.table_name collate database_default
                = b.table_name collate database_default
GROUP BY   a.table_name, a.row_count, a.data_size
ORDER BY   CAST(Replace(a.data_size, ' KB', '') as integer) desc

DROP TABLE #temp;

Select * from dbo.BigTables;

이제 일주일 동안의 크기 변화를 확인하고 예약하는 논리 만 작성하면됩니다.


이제 테이블 크기 보고서에 부정확성이 의심되는 경우 DBCC UPDATEUSAGE로 이동해야합니다 (행 및 페이지 수를 수정합니다). 도움이되어 기쁘다!
Marian
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.