Periodo di conservazione in SQL Server 2008 Monitoraggio delle modifiche

Question

Sono un po 'preoccupato per il periodo di memorizzazione predefinito in SQL Server 2008 Rilevamento modifiche (che è di 2 giorni).

È consigliabile impostare questo periodo su es. 100 anni e disattivare la pulizia automatica o mi morderà in futuro con un uso eccessivo della memoria e/o un peggioramento delle prestazioni? Qualcuno ha esperienza in questa materia?

Answer 1

Se si disattiva la pulizia automatica, è preferibile passare periodicamente e rimuovere le informazioni sul rilevamento delle modifiche da soli, disattivando e riabilitando il rilevamento delle modifiche per ogni tabella. Altrimenti, sì, i dati di tracciamento continueranno a crescere e crescere.

Non è possibile interrogare direttamente le tabelle sottostanti, ma è possibile utilizzare i relativi metadati. La query seguente mostra relativi conteggi delle righe:

select 
    s.name as schema_name 
, t.name as table_name 
, (select sum(rows) from sys.partitions x where o.parent_object_id = x.object_id) as rows_in_base_table 
, o.name as tracking_table 
, p.rows as rows_in_tracking_table 
from sys.objects o 
join sys.tables t on o.parent_object_id = t.object_id 
join sys.schemas s on t.schema_id = s.schema_id 
join sys.partitions p on o.object_id = p.object_id 
where o.name like 'change[_]tracking%' 
    and o.schema_id = schema_id('sys') 
order by schema_name, table_name 

Run che nel database, e si dovrebbe ottenere un senso ruvido di overhead corrente.

Le tabelle di rilevamento delle modifiche seguono tutte uno schema standard. Ad esempio:

select 
    c.name, c.column_id 
, type_name(user_type_id) as type_name 
, c.max_length, c.precision, c.scale 
, c.is_nullable, c.is_identity 
from sys.columns c 
where object_id = (
    select top 1 object_id from sys.objects o 
    where o.name like 'change[_]tracking%' 
    and o.schema_id = schema_id('sys') 
) 

Le colonne k_% variano in base alla tabella e corrispondono alle chiavi primarie della tabella tracciata. Stai considerando un overhead minimo di base di 18 byte + (lunghezza della chiave primaria) per riga. Questo aggiunge!

Ad esempio, sto monitorando alcune tabelle base magre con larghezza di soli 15 byte, con una chiave composita di 7 byte. Ciò rende le tabelle di tracciamento 18 + 7 = 25 byte di larghezza!