SQL SHRINK, избегая снижения производительности

У нас есть SharePoint 2010, работающий на сервере SQL 2008R2 (не уверен, что это актуально). Существует очень много библиотек изображений, размер базы данных которых приближается к 120 ГБ. Я написал утилиту, которая изменит размер всех этих изображений примерно на 20% от их исходного размера, что освободит огромное количество места. В целях сокращения наших счетов за онлайн-резервное копирование я хотел бы освободить большую часть этого пространства, но я читал о затратах на производительность при сокращении базы данных.

Если я уменьшу большую часть пространства, но оставлю большой процент свободным, устранит ли это проблему фрагментации, связанную с этим? ... или, может быть, есть лучшая стратегия для моей проблемы?


person Michael Nelson    schedule 06.10.2013    source источник


Ответы (1)


Делать SHRINK часто нехорошо. но то, что слишком часто, от случая к случаю. после уменьшения места для изображений файлы базы данных станут доступными, и это должно быть нормально для восстановления, я думаю, один раз в неделю. у вас должен быть план обслуживания БД на выходные или в нерабочее время, верно? запуск базы данных/файлов SHRINK с проверенным интервалом времени не навредит. хотя я не понял, что вы имеете в виду под этой строкой «Если я уменьшу большую часть пространства, но оставлю большой процент свободным ......»

как вы выбираете, какую часть файла вы можете сжать, а какую нет. либо вы можете сделать ПОЛНУЮ БД, либо некоторые выбранные файлы данных/журналов, если у вас есть более одного файла БД на базу данных.

person Anup Shah    schedule 06.10.2013
comment
Возможно, я неправильно понимаю, для чего это нужно, но второй параметр DBCC SHRINKDATABASE определяется как процент свободного места, которое вы хотите оставить в файле базы данных после того, как база данных была сжата в соответствии с technet.microsoft.com/en-us/library/ - person Michael Nelson; 06.10.2013