Как эффективно использовать CHECKPOINT в приложении, использующем FILESTREAM

Я использую FILESTREAM для хранения больших двоичных объектов в своем клиент-серверном приложении.

В прошлом мне приходилось время от времени очищать все BLOBS, выполняя команду вроде:

UPDATE BLOBTABLE set BLOBFIELD = NULL

Это очищает большие двоичные объекты, я сделал это, чтобы уменьшить размер резервной копии БД.

Но чтобы капли «исчезли с диска», мне нужно запустить

CHECKPOINT

Примечание: это было сделано как действие администратора баз данных, а не как часть программного обеспечения.

Теперь я понимаю, что в своем приложении я никогда не вызываю CHECKPOINT.

Может быть, я должен каждый раз удалять блоб, не так ли?

Просто чтобы лучше себя проявить, я привожу пример из моего реального случая:

Мое приложение позволяет хранить файлы (например, документы в формате PDF).

эти PDF-файлы сохраняются в виде больших двоичных объектов в поле файлового потока.

Когда пользователь удаляет их (из пользовательского интерфейса), я запускаю команду DELETE.

Я не вызываю CEHCKPOINT после него, поэтому сборка мусора не запускается.

Размышляя над этим, я понимаю, что у меня не все под контролем.

Итак, мой вопрос прост: мне нужно запускать CHECKPOINT каждый раз, когда я удаляю один из этих файлов? есть ли недостаток в этом?

Спасибо!


sql-server blobstorage sql-server-2008-r2 checkpoint
person LaBracca    schedule 06.10.2014    source источник
comment
Данные FILESTREAM хранятся в папке (согласно дизайну сервера sql). Если я добавлю большой двоичный объект в свое приложение, я увижу, что количество файлов в папке увеличивается на значение 3. Если я удалю файл, я ожидаю вернуться к -3.   -  person LaBracca    schedule 06.10.2014
comment
Если это умеренно активная база данных, она в любом случае должна автоматически устанавливать контрольные точки довольно часто. И если вы не нуждаетесь в дисковом пространстве (в этом случае вместо того, чтобы тратить время на обдумывание этого, пойдите и получите больше дискового пространства), вы должны просто доверить системе в конечном счете удаление ненужных файлов. Попытка форсировать его обычно приводит к ухудшению общей производительности.   -  person Damien_The_Unbeliever    schedule 06.10.2014
comment
@Damien_The_Unbeliever, вы имеете в виду, что сборщик мусора все равно запускается время от времени, даже если он не вызывается вручную с помощью CHECKPOINT?   -  person LaBracca    schedule 07.10.2014
comment
в соответствии с этим: stackoverflow.com/questions/865659/sql-server-checkpoints кажется, что контрольные точки возникают при остановке сервера или резервном копировании базы данных, поэтому для ежедневной резервной копии базы данных создание резервной копии похоже на выполнение контрольной точки. Я прав?   -  person LaBracca    schedule 07.10.2014
comment
Целый раздел документации MSDN посвящен контрольным точкам базы данных.   -  person Damien_The_Unbeliever    schedule 07.10.2014
comment
Да, резервные копии запускают контрольную точку. если вы ответите на мой вопрос, я приму его. Спасибо за ссылку.   -  person LaBracca    schedule 07.10.2014

Ответы (1)


arrow_upward
1
arrow_downward

База данных выполняет контрольные точки в разные моменты, один из них — при выполнении резервного копирования.

Поскольку контрольная точка запускает сборку мусора, нет необходимости (исключения могут быть огромными или сложными сценариями) вызывать CHECKPOINT в приложении, поскольку риск заключается в снижении производительности.

Лучше решить использовать CHECKPOINT в качестве действия по обслуживанию, если это необходимо, но с учетом того, что резервное копирование базы данных (или даже остановка службы sql) как следствие имеет контрольную точку.

person LaBracca    schedule 08.10.2014