За съжаление понастоящем няма начин да принудите събирането на отпадъци (GC) на данни от файловия поток. Обработва се от асинхронна фонова задача, която се извиква много често и има ограничение в броя на файловете, които може да обработва в едно извикване. Други хора вече се оплакаха от това и Microsoft обеща да се справи с този проблем в бъдещи версии.
Като се има предвид това, има някои неща, които можете да направите проактивно, за да сте сигурни, че всички изтрити файлове отговарят на условията за събиране на боклук. Файлът не става автоматично допустим за събиране на отпадъци в момента, в който бъде изтрит от базата данни – трябва да бъдат изпълнени определени допълнителни условия.
Условията зависят от модела за възстановяване на базата данни, затова е важно да знаете в какъв модел за възстановяване е вашата база данни. Имайте предвид, че дори ако моделът за възстановяване (както е посочен от sys.databases) е пълен, но не сте взели архивиране на db/log след активирането на модела за пълно възстановяване (или след създаването на db), базата данни ще се държи в много аспекти, сякаш все още е в прост модел на възстановяване.
При прост модел на възстановяване всичко, което е необходимо, за да може файлът да отговаря на условията за изтриване, е текущият LSN на контролна точка (LSN на последната контролна точка) да е по-голям от LSN на операцията за изтриване, която е премахнала файла. Следователно всичко, което можете да направите, след като изтриете 40 000 реда, е да издадете един оператор CHECKPOINT и да изчакате.
Нещата стават по-сложни, когато базата данни е в "наистина пълен" модел на възстановяване. Ако случаят е такъв, тогава в допълнение към LSN на контролна точка, резервният LSN (LSN на последното архивиране на регистрационен файл) трябва да бъде след LSN за изтриване. Освен това GC работи на 2 фази:при първото преминаване той само маркира файл за изтриване, но не го изтрива физически. Само когато GC обработи файла за втори път, този файл ще бъде физически изтрит от диска. За да направи нещата още по-интересни, първото преминаване на GC "нулира" LSN за изтриване, така че второто преминаване може да обработи файла само когато LSN на контролна точка и резервен LSN са по-големи от LSN на първото преминаване на GC.
Ако искате да знаете точно какво се случва в системата, можете да следите текущия напредък на GC, като гледате специална вътрешна таблица "надгробни камъни". Всеки път, когато стойност на файлов поток се изтрие от базата данни, в тази таблица се вмъква надгробен камък. Надгробната плоча се премахва само след като файлът бъде изтрит от диска. Името на таблицата с надгробна плоча е sys.filestream_tombstone_, където е някакво число. Можете да получите точното име, като използвате следната заявка:
select name from sys.internal_tables where name like '%tombstone%'
Тъй като това е вътрешна таблица, за да я направите заявка, трябва да влезете с помощта на DAC (специална администраторска връзка).
Например, да кажем, че съм изтрил ред с една стойност на файлов поток. Сега мога да видя състоянието на надгробната плоча, като издам следната заявка (от DAC):
select * from sys.filestream_tombstone_2073058421
Първите 3 полета обозначават LSN на операцията за изтриване, но най-важното за наблюдение е състоянието. След като издадох резервно копие на журнала + контролна точка и го оставих да работи за няколко секунди, отправям запитване към таблицата надгробна плоча отново и получавам:
Обърнете внимание, че състоянието е променено (последните 2 бита се променят от 1 на 2), което показва, че файлът е обработен от първото преминаване на GC. Освен това LSN е актуализиран с LSN на първото GC преминаване, така че за да може второто GC преминаване да може окончателно да изтрие файла, трябва да поставим LSN на контролна точка и резервен LSN над новия LSN. Издавам друга контролна точка + резервно копие на регистрационния файл, изчаквам няколко секунди и повторно запитвам таблицата с надгробни плочи. Вече е празен и файлът е изчезнал от диска.
Имайте предвид, че има други неща (напр. репликация, други транзакции, когато версията е активирана), които могат да попречат на определени файлове да бъдат събирани за боклук, но в повечето случаи контролната точка и архивирането на регистрационния файл са 2-те основни.
Ами сега, предполагам, че навлязох твърде дълбоко в подробностите, но може би това ще помогне по някакъв начин за разбирането на поведението на GC.
