Se il database e' settato in recovery model FULL tutte le scritture legate ad un create index o a un rebuild verranno tracciate nel file di log. Pertanto il transaction log puo' aumentare le proprie dimensioni in modo molto elevato (pensate alle scritture legate ad un indice cluster) aumentando anche i tempi necessari al rebuild stesso.
Questo non accade se il recovery model e' settato a BULK_LOGGED: in tal caso viene tracciato solo il fatto che l'operazione e' stata compiuta oltre ad alcune altre informazioni (tipo gli extended modificati) che serviranno a garantire la corretta esecuzione di un eventuale restore. In tal modo anche la ricreazione degli indici risulta piu' veloce.
Per quello che mi riguarda, dopo aver costruito ed attivato un piano di manutenzione che ricreava un bel po' di indici e essermi trovato un file transaction "esploso" 
ho pensato bene di portare il recovery a BULK_LOGGED prima di iniziare l'attivita' e di riportarlo a FULL una volta terminata la manutenzione.
In tal modo le dimensioni del file di log non crescono (se non in minima parte) durante le operazioni di rebuild degli indici e sono anche un po' piu' veloci, ma...attenzione: quando viene effettuato il backup del transaction log Sql provvede a fare in modo che nel file di backup siano presenti tutte le infomazioni necessarie al restore. Pertanto recupera tutte le modifiche fatte alle pagine e le riporta nel file di backup.
Quindi il file di log rimane "snello", ma il suo backup si ingrossa fino ad assumere le dimensioni che avrebbe avuto il log in un recovery FULL ed il tempo di backup si allunga.
In tal modo e' garantito un restore completo sia con il modello FULL che con il BULK_LOGGED con tempi analoghi.
Oltre alla creazione degli indici anche diverse altre operazioni (bcp, BULK INSERT, SELECT INTO...) vengono loggate in modo differente nei due modelli di recovery e, questa, e' una buona ragione per approfondire e capire meglio le differenze tra FULL e BULK_LOGGED.
(Se lo faro' sara' argomento per un prossimo post)
Quanto detto vale per Sql2005, ho il sospetto che in Sql2000 le cose fossero un po' differenti, ma non ho avuto il modo di verificarlo (altro post in arrivo ?)
Buon backup a tutti !! 
Mi sono imbattuto in un comportamento di SqlServer che, di prima battuta, non mi aspettavo, anche se riflettendoci un momento e' assolutamente corretto e sensato (oltre che documentato). Comunque lo posto perche' potrebbe essere inaspettato anche per qualcun altro.
Se fate un "truncate table" di una tabella che contiene un campo identity il suo valore viene riazzerato e, al primo insert, lo trovate valorizzato al suo seed iniziale. In altre parole la truncate fa "perdere" a Sql il valore attuale del contatore,
Da questo luogo provero' anch'io a segnalare caratteristiche e situazioni Sql che mi hanno colpito o semplicemente interessato. Un modo per ricordarsele e, magari, in qualche caso, essere utile.
Ma sono solo uno sviluppista quindi non aspettatevi nulla di straordinario: in fondo unisco le incompentenze di entrambe le figure ... Pero', non si sa mai, come dice un vecchio saggio tosco-emiliano "ho visto a volte che anche un topo sa ruggire ed anche un' aquila precipitata".... per cui... stay tuned !!
Franco (aka OrsoCurioso)