Partager via


Компрессирование резервных копий в 2008-м

Ранее этот пост находился на форуме сообщества Russian SQL Server User Group по адресу https://sqlclub.ru/forum/viewtopic.php?f=6&t=1107, что позволяло во время демонстрации ссылаться на скрипт, чтобы слушатели могли не только посмотреть, но и впоследствии самостоятельно воспроизвести демку для закрепления материала. К сожалению, безответственный администратор по имени Сергей Заворуев положил сайт sqlclub.ru и ударился в бега, став недоступным ни по e-mail, ни по телефону, чем немало подставил сообщество. Хотелось бы предостеречь будущих возможных деловых партнеров Сергея Заворуева (https://1stat.ru/?show=whois\&person=Sergey V Zavoruev), разработка, продвижение и сопровождение сайтов, сетевые работы любой сложности, о риске, который они на себя берут, затевая с ним совместные проекты. Может внезапно кидануть и смыться.

----------------------------------------------------------------------------------------------------------------------

Компрессирование резервных копий в 2008

alexejs Вс апр 06, 2008 00:25

Означает то, что написано. Данные при архивировании сжимаются.
Это обычный бэкап:

backup database AdventureWorks to disk = 'C:\Program Files\Microsoft SQL Server\100\Tools\Samples\AdventureWorks1.bak'
with init, stats

Это со сжатием:

backup database AdventureWorks to disk = 'C:\Program Files\Microsoft SQL Server\100\Tools\Samples\AdventureWorks2.bak'
with init, stats, compression

Разница невооруженным глазом представлена на рис.1
Статистика:

select media_set_id, software_build_version, compatibility_level, recovery_model,
datediff(ss, backup_start_date, backup_finish_date) as [Длительность в сек],
backup_size / 1024 as [размер бэкапа в КБ],
compressed_backup_size / 1024 as [размер на диске в КБ],
backup_size / compressed_backup_size as [к-т компрессии]
from msdb..backupset where backup_set_id > 1

media_set_id software_build_version compatibility_level recovery_model Длительность в сек размер бэкапа в КБ размер на диске в КБ к-т компрессии
2 1300 100 SIMPLE 1 6221 6221 1
2 1300 100 SIMPLE 1 6220 6220 1
3 3054 90 FULL 1 4182 4182 1

4 1300 100 SIMPLE 45 176209 176209 1
5 1300 100 SIMPLE 12 176209 40656.98 4.334041

Незначительно вырастает CPU
Более точные замеры – PerfMon, счетчики SQLServer : Backup Device \ Device Throughput Bytes/sec, SQLServer : Databases \ Backup/Restore Throughput/sec, а также Physical Discовые счетчики Windows.
Компрессия по умолчанию:

sp_configure 'backup compression default'

= 0
Если поставить 1, будет компрессировать
Перебить поведение по умолчанию - WITH NO_COMPRESSION.

Факторы, влияющие на к-т компрессии.
The type of data
Character data compresses more that other types of data.
The consistency of the data among rows on a page
Typically, if a page contains several rows in which a field contains the same value, significant compression might occur for that value. In contrast, for a database that contains random data or that contains only one large row per page, a compressed backup would be almost as large as an uncompressed backup.
Whether the data is encrypted
Encrypted data compresses significantly less than equivalent unencrypted data.
Whether the database is compressed
If the database is compressed, compressing backups might not reduce their size by much, if at all.

Вложения

undefined

рис.1

alexejs Сб ноя 22, 2008 10:07

В Нижнем на TechDays прозвучал очень хороший вопрос: сжатие резервных копий доступно только в Enterprise Edition, правильно? Что будет, если сжатую в ней копию попытаться отресторить на какой-нибудь редакции?

Очевидно, не поднимется, ответил я неуверенно, а в перерыве решил проверить. Я взял полученный выше AdventureWorks2.bak, отнес его на виртуалку с SQL Express, в SSMS сказал Databases -> Restore Database, From Device = AdventureWorks2.bak, в опциях подправил путя, поставил галку Overwrite и нажал ОК в полной уверенности получить отсыл. Отсыла не произошло. Напротив, SQL Express радостно зашуршал, слева внизу в Progress появились циферки 20%, 40%, ..., 100% и база восстановилась. Я зашел в нее, посмотрел, что вроде все читается.

Может, бэкап был нескомпрессированный, подумал я и еще раз повторил всю цепочку, начиная от backup ... with compression на Enterprise и заканчивая рестором на Express. Удивительно, но все работает. Может, SQL Express умеет не только разжимать резервные копии, но и сжимать, подумал я, и сказал backup ... with compression на Express. Фиг, сказал Express. Мораль: сжатие резервных копий действительно доступно только в Enterprise Edition, однако сжатые таким образом резервные копии могут быть восстановлены на других редакциях, включая SQL Express.