Как поймать чекпойнт?

Hачну издалека. Счастливые обладатели SQL Server 2008 знают про атрибут filestream. Oн позволяет хранить varbinary(max) в файловой системе. Не в смысле файла БД, а когда под каждую такую ячейку заводится файл на диске. Проще стриминговый доступ плюс снимается ограничение на размер блоба в 2 гига. Многие до этого так и делали: контент хранили в файле, а в таблицу выносили атрибуты документа плюс линк на файл. В случае filestream оные файлы перестают быть посторонними по отношению к SQL Server. Они становится ему близкими и родными. SQL Server начинает их холить, лелеять, поддерживать над ними транзакционность, бэкап, полнотекст, репликацию, лог шиппинг, кластеризацию и все дела. Помните красивые слова WinFS, SQL Server File System и все такое? Filestream - это осколок Атлантиды. Но сейчас речь не об этом. В документации недостаточно явно отражен момент, что при операциях DELETE и непрямого UPDATE в файловой системе создается новый файл, между тем как файл со старым значением остается. Рано или поздно (чем больше гиг киношки, тем раньше), народ начинает искать, куда делось место на диске, находит и озабачивается вопросом, как бы старые версии того? Прибрать. Старые версии прибираются по чекпойнту. Скорее всего, по той же причине, почему на диск не скидываются по отдельности грязные записи после каждого изменения. Быстрее получается накопить их до кучи и записать разом, чем отвлекаться на каждую отдельно. Встала задача наглядно и красиво продемонстрировать данное поведение во время семинара. Вот смотрите - в базе наступает чекпойнт и старые файлы при этом автоматически удаляются. Кто подскажет, как отловить чекпойнт?