M-am mai gândit puţin la informaţiile returnate de query-urile din mesajul anterior şi cred că am înţeles cam la ce se referă fiecare. De exemplu, dacă execut query-urile de mai sus (după un DBCC UPDATEUSAGE) pe o tabelă ceva mai mare, obţin următoarele rezultate:

name                             rows       reserved        data   index_size   unused
------------------------- ----------- -------------- ----------- ------------ --------
Inregistrari contabile         747026      256512 KB   101360 KB    153560 KB  1592 KB          

indid  name                                         dpages      reserved    used
------ -------------------------------------------- ----------- ----------- -----------
1      PK_Inregistrari contabile                    12670       32064       31865
2      ID_Nota                                      1121        1153        1128
3      CD                                           1784        1833        1795
4      CC                                           1672        1713        1683
5      ID_Detaliu cu TipDetaliu                     5193        5233        5220
9      CD cu ID_Nota cu Valoare                     3065        3105        3088
10     CC cu ID_Nota cu Valoare                     2965        3017        2987
11     TipDetaliu cu ID_Nota cu ID_Detaliu          3245        3289        3270

Din asta, eu înţeleg următorul lucru: index-ul ID_Nota are alocate 1153 de pagini, dintre care doar 1128 sunt folosite efectiv (iar restul de 25 de pagini sunt neutilizate). Dintre cele 1128 de pagini folosite, 1121 de pagini sunt "data pages" adică leaf-level în arborele respectiv, iar celelalte 7 pagini sunt de un nivel superior, conţinând pointer-i spre paginile leaf-level sau spre alte pagini de nivel intermediar (mai precis, probabil că este 1 pagină top-level, care are pointeri spre 6 pagini de nivel intermediar, care conţin pointeri către cele 1121 de pagini leaf-level; ar exista şi mai mult de 3 nivele dacă aş fi avut indecşi pe coloane mai mari, dar în acest caz au fost suficiente doar aceste 3 nivele).

Pentru index-ul clustered, informaţiile sunt afişate în alt mod: la coloana reserved sunt incluse toate paginile alocate acelei tabele (pentru toţi indecşii). Din cele 32064 pagini alocate acestei tabele, 19343 sunt alocate indecşilor non-clustered (dacă facem suma valorilor din coloana reserved pentru ceilalţi indecşi), iar restul de 12721 sunt alocaţi indexului clustered (inclusiv paginilor de date, care sunt stocate în leaf-level-ul indexului clustered. Dpdv al paginilor folosite, din cele 31865 pagini, 19171 sunt folosite pentru ceilalţi indecşi, iar restul de 12694 sunt folosiţi de indexul clustered. Din cele 12694 de pagini folosite de indexul clustered, 12670 sunt leaf-level (conţinând datele efective), iar restul de 24 de pagini sunt pagini de un nivel superior (probabil 1 pagină top-level şi 23 de pagini de nivel intermediar). Spaţiul neutilizat alocat pentru indexul clustered este de 27 de pagini (adică 12721 minus 12694).

În concluzie, spaţiul raportat de sp_spaceindex ca fiind utilizat de indecşi (153560 KB, adică 19195 pagini) este într-adevăr cel corect, fiind compus din 19171 de pagini pentru indecşii non-clustered şi 24 de pagini pentru indexul clustered (excluzând paginile de date, care au fost raportate pe coloana data: 101360 KB, adică 12670 pagini). Iar spaţiul unused (1592 KB, adică 199 pagini) este constituit din diferenţa dintre reserved şi used pentru indecşii non-clustered (în total 172 pagini) plus cel neutilizat la indexul clustered (27 de pagini).

Răzvan