Di seguito è riportato un paragrafo da Microsoft Docs :
Le nuove pagine allocate in un heap come parte delle operazioni DML non utilizzeranno la compressione PAGE fino a quando l'heap non viene ricostruito. Ricostruire l'heap rimuovendo e riapplicando la compressione o creando e rimuovendo un indice cluster.
Non riesco a capire perché sia così. Se ho un heap con un'impostazione di compressione specificata, perché non dovrebbe essere applicato a una pagina che appartiene alla tabella?
Grazie
Risposte:
Sebbene non conosca i meccanismi interni specifici che sono responsabili delle differenze, posso dire che gli heap sono gestiti (internamente) in modo leggermente diverso rispetto agli indici cluster (e forse anche agli indici non cluster):
L'eliminazione di righe da un heap in modo tale che una o più pagine di dati siano vuote (nessuna riga allocata) non libera necessariamente tale spazio. Probabilmente dovrai creare, quindi rilasciare, un indice cluster sulla tabella o chiamare ALTER TABLE [TableName] REBUILD;(a partire da SQL Server 2014?). Per ulteriori dettagli e opzioni, consultare la pagina Microsoft Documenti per ELIMINA .
L'inserimento di singole righe (ovvero non basate su set INSERT) in un heap non riempie le pagine di dati in modo completo come con gli indici cluster. Gli indici cluster si adatteranno alle righe purché vi sia spazio per la riga (dati e righe generali) più l'overhead a 2 byte dell'array di slot. Le pagine di dati in Heaps, tuttavia, non usano il numero di byte rimasti sulla pagina, ma usano invece un indicatore molto generalizzato di quanto è piena la pagina e non ci sono molti livelli che vengono riportati. I livelli sono qualcosa del tipo: 0%, 20%, 50%, 80% e 100% pieno. E passerà al 100% mentre c'è ancora spazio per un'altra riga (e in effetti, se lo stesso numero di righe fosse stato inserito in un'operazione basata su set, avrebbe riempito la pagina il più possibile). Certo, proprio come con ilDELETE operazioni, la ricostruzione dell'heap comprimerà tutte le righe che rientrano nella pagina di dati.
Considerare ora le seguenti informazioni, tratte dalla sezione "Quando si verifica la compressione della pagina" della pagina Microsoft Docs per l' implementazione della compressione della pagina :
... Man mano che i dati vengono aggiunti alla prima pagina di dati, i dati vengono compressi per riga. ... Quando la pagina è piena, la riga successiva da aggiungere avvia l'operazione di compressione della pagina. L'intera pagina viene rivista; ...
Quindi, sembra del tutto in linea con questo altro comportamento dell'heap che richiederebbero un ALTER TABLE REBUILD, CREATE / DROP di un indice cluster o una modifica delle impostazioni di compressione dei dati (che ricostruiscono l'heap) prima che vengano scritte le pagine di dati in modo ottimale. Se gli heap non sono pienamente consapevoli delle "pagine intere" (fino a quando l'heap non viene ricostruito) e non sanno quando la pagina è definitivamente piena, allora non saprebbero quando avviare l'operazione di compressione della pagina (quando si tratta di aggiornamenti e singoli inserti frontali).
Un altro tecnicismo che limiterebbe ulteriormente alcuni heap dall'applicazione automatica della compressione di pagina (anche se altrimenti potrebbero) è che l'applicazione della compressione richiederebbe la ricostruzione di tutti gli indici non cluster per tale heap (se presenti). Come quella pagina collegata per "Compressione dei dati" indica anche:
La modifica dell'impostazione di compressione di un heap richiede la ricostruzione di tutti gli indici non cluster sulla tabella in modo che abbiano puntatori alle nuove posizioni di riga nell'heap.
I "puntatori" a cui si fa riferimento sono gli ID riga (RID), che sono una combinazione di: FileID, PageID e slot / posizione sulla pagina. Questi RID vengono copiati in indici non cluster. Essendo una posizione fisica precisa, a volte sono ricerche più veloci rispetto all'attraversamento di un albero b con i tasti Indice cluster. Ma uno svantaggio di una posizione fisica è che può cambiare, e questo è il problema qui. Gli indici cluster, tuttavia, non soffrono di questo problema perché i loro valori chiave vengono copiati in indici non cluster come puntatore all'indice cluster. E i valori chiave rimangono gli stessi, anche quando cambia la loro posizione fisica.
Vedi anche:
la sezione "Gestione degli heap" della pagina di Microsoft Docs per gli heap (tabelle senza indici cluster) :
Per ricostruire un heap per recuperare spazio sprecato, creare un indice cluster sull'heap e quindi eliminare tale indice cluster.
la sezione "Considerazioni su quando si utilizza la compressione di righe e pagine" della pagina Microsoft Docs per la compressione dei dati :
Quando un heap è configurato per la compressione a livello di pagina, le pagine ricevono la compressione a livello di pagina solo nei seguenti modi:
- I dati vengono importati in blocco con le ottimizzazioni in blocco abilitate.
- I dati vengono inseriti utilizzando la sintassi INSERT INTO ... WITH (TABLOCK) e la tabella non ha un indice non cluster.
- Una tabella viene ricostruita eseguendo l'istruzione ALTER TABLE ... REBUILD con l'opzione di compressione PAGE.
E la dichiarazione citata nella domanda.
Non tutti i meccanismi di SQL Server sono come crediamo che dovrebbero essere.
Paul Randal ha fornito una forte raccomandazione sulla gestione del problema.
http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-2930-fixing-heap-fragmentation/