Truncate table od strony dyskowej działa w bardzo ciekawy sposób
Robimy sobie tabelkę
USE tempdb
go
CREATE TABLE test (pole INT, tekst VARCHAR(20))
go
INSERT test SELECT 102,'test'
Sprawdzamy co jest na dysku, znajdujemy nr obiektu i bazy danych
select id AS obiectid, DB_ID() AS bazaid
from sys.sysobjects
where xtype ='U'
and name like 'test'
obiectid bazaid
----------- ------
1296892583 2
Wywołujemy dbcc żeby znaleźć adresy stron dla tabeli
DBCC IND (2,1296892583, 1) WITH NO_INFOMSGS
Interesuja nas strony typu 1, uruchamiamy flage pozwalająca na przeglądanie danych
DBCC TRACEON(3604) WITH NO_INFOMSGS
I oglądamy stronę
DBCC PAGE (2, 1,552360,3) WITH TABLERESULTS, NO_INFOMSGS
insertowane dane są na stronie, teraz robimy
TRUNCATE TABLE test
Uruchamiamy
DBCC IND (2,1296892583, 1) WITH NO_INFOMSGS
------
Command(s) completed successfully.
Brak adresów stron przyporządkowanych do tabeli, ale jeśli pamiętamy na których stronach były wcześniej
DBCC PAGE (2, 1,552360,3) WITH TABLERESULTS, NO_INFOMSGS
ups… dane nadal tu są do czasu aż serwer nie zamaże ich innymi danymi.
W przypadku delete lub drop table nie ma wcale sekcji SLOT
Czy jeśli przestrzeń dyskowa dla tabeli została zajęta, to czy w przypadku zapisywania (nadpisywania) nie odbędzie się ono szybciej (przynajmniej w kwestii IO przy dużej ilości danych) ? taka wolna myśl, nie sprawdzałem jeszcze tego :)
OdpowiedzUsuńjeżeli serwis sql nie ma granta na SE_MANAGE_VOLUME_NAME to w zasadzie zawsze dane są nadpisywane bo plik bazy jest wypełniany w czasie inicjalizacji zerami. W truncate chodzi o to że nie dotyka on stron danych kasuje tylko ich powiązania przez co jest o klasę szybszy
OdpowiedzUsuń