Esiste un modo affidabile per determinare quando eseguire DBCC CLEANTABLE per recuperare spazio?


11

Ultimamente, invece di far crescere solo i file quando si avvicinano all'80% di utilizzo dei file, sono stato più proattivo nel recuperare spazio tramite i soliti trucchi come deframmentare cumuli, aggiungere e rilasciare indici cluster, implementare la compressione di righe o pagine, ecc.

Tuttavia, ci sono alcuni casi in cui sono stato in grado di recuperare ancora più spazio eseguendo DBCC CLEANTABLE . Con centinaia di database nel mio ambiente, non è possibile sapere cosa fanno gli utenti in ognuno di essi ed è del tutto accettabile che ci saranno cambiamenti che coinvolgono il rilascio di colonne a lunghezza fissa. In genere ho trovato queste opportunità osservando i conteggi delle righe rispetto ai conteggi delle pagine in alcuni script di utilizzo dello spazio oggetti che ho scritto. Mi piacerebbe fare un ulteriore passo in avanti cercando di automatizzare il rilevamento di questo tipo di scenari.

Quello che mi piacerebbe sapere è se qualcuno là fuori sta monitorando attivamente questo tipo di opportunità e, in caso affermativo, cosa cerchi specificamente?

Il mio pensiero era quello di scrivere qualcosa sulla falsariga di raccogliere la dimensione massima e minima di una riga, il numero di righe nella tabella, il numero di pagine allocate e il numero di pagine utilizzate, quindi fare un po 'di matematica di base per registrare i risultati che sono ben al di fuori di ciò che sarebbe "previsto".


Consiglio vivamente di utilizzare il parametro batch_size su tabelle di grandi dimensioni. Ciò comporterà l'esecuzione del comando in una serie di transazioni anziché in una transazione gigante.
datagod

Risposte:


11

La soluzione che mi viene in mente per questo problema è eseguire settimanalmente un lavoro che eseguirà sp_spaceused per tutte le tabelle in un database e salverà questi dati in una tabella. Se ci sono differenze nelle dimensioni per ogni tabella maggiore di ... diciamo ... 10%, eseguirò il dbcc cleantable.

Il mio codice per scorrere tra le dimensioni della tabella è simile al seguente:

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;

Ora devi solo costruire la logica che verificherà quale sarebbe la modifica delle dimensioni nel corso della settimana e pianificarla.


Ora, se ci sono motivi per sospettare imprecisioni nei rapporti sulle dimensioni della tabella, dovresti scegliere DBCC UPDATEUSAGE (questo risolverà il conteggio delle righe e delle pagine). Felice di essere di aiuto!
Marian,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.