Меню

Sql server сжатие базы данных ошибка

SQL Server 2008 R2 Datacenter SQL Server 2008 R2 Developer SQL Server 2008 R2 Enterprise SQL Server 2008 R2 Standard SQL Server 2008 R2 Standard Edition for Small Business SQL Server 2008 R2 Web SQL Server 2008 R2 Workgroup SQL Server 2012 Developer SQL Server 2012 Enterprise SQL Server 2012 Express SQL Server 2012 Standard SQL Server 2012 Web SQL Server 2012 Enterprise Core Еще…Меньше

Корпорация Майкрософт распространяет исправления Microsoft SQL Server 2008 R2 или Microsoft SQL Server 2012 как один файл для загрузки. Поскольку исправления являются кумулятивными, каждый новый выпуск содержит все исправления и исправления для системы безопасности, которые были включены в пакет исправлений для Microsoft SQL Server 2008 R2 или SQL Server 2012.

Проблемы

Рассмотрим следующий сценарий.

  • У вас есть база данных, в которой в Microsoft SQL Server 2012 или Microsoft SQL Server 2008 R2 используется один из указанных ниже элементов.

    • Параметр уровня изоляции SNAPSHOT

    • Изоляция моментальных снимков READ UNCOMMITTED (RCSI)

  • Вы удаляете одну или несколько переадресованных записей в таблице базы данных.

  • В таблице нет кластеризованного индекса.

  • Чтобы уменьшить размер файла базы данных, используйте команду DBCC SHRINKFILE.

В этом сценарии размер файла базы данных не уменьшается, хотя большая часть файла базы данных пуста.Примечание.Эта проблема обычно возникает при удалении переадресованной версии записи в куче.

Причина

Когда на странице удаляется запись с переадресованной версией, тип записи на странице изменяется на GHOST_VERSION_RECORD. Тем не менее, на странице «свободное место на странице (PFS)» не указывается, что на странице содержится Фантом-запись. Это приведет к тому, что страница не будет уменьшаться на размер файла базы данных.

Решение

Сведения о накопительном пакете обновления

Накопительное обновление 2 для SQL Server 2012 с пакетом обновления 1 (SP1)

Исправление для этой проблемы впервые выпущено в накопительном обновлении 2. Для получения дополнительных сведений о том, как получить этот накопительный пакет обновления для SQL Server 2012 с пакетом обновления 1 (SP1), щелкните следующий номер статьи базы знаний Майкрософт:

2790947 Накопительный пакет обновления 2 для SQL Server 2012 с пакетом обновления 1 (SP1)Примечание. Поскольку сборки являются кумулятивными, каждый новый набор исправлений содержит все исправления и все исправления системы безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2012 с пакетом обновления 1 (SP1). Рекомендуется установить последнюю версию исправления, которая включает это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:

2772858 Сборки SQL Server 2012, выпущенные после выпуска пакета обновления 1 (SP1) для SQL Server 2012

Накопительное обновление 5 для SQL Server 2012

Исправление для этой проблемы впервые выпущено в накопительном обновлении 5. Для получения дополнительных сведений о том, как получить этот накопительный пакет обновления для SQL Server 2012, щелкните следующий номер статьи базы знаний Майкрософт:

2777772 Накопительный пакет обновления 5 для SQL Server 2012 Примечание. Так как сборки являются кумулятивными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2012. Рекомендуется установить последнюю версию исправления, которая включает это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:

2692828 Сборки SQL Server 2012, выпущенные после выпуска SQL Server 2012

SQL Server 2008 R2 с пакетом обновления 2 (SP2)

Исправление для этой проблемы впервые выпущено в накопительном обновлении 1 для SQL Server 2008 R2 с пакетом обновления 2. Для получения дополнительных сведений о том, как получить этот накопительный пакет обновления, щелкните следующий номер статьи базы знаний Майкрософт:

2720425 Накопительный пакет обновления 1 для SQL Server 2008 R2 с пакетом обновления 2 (SP2)Примечание. Поскольку сборки являются кумулятивными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2008 R2. Рекомендуется установить последнюю версию исправления, которая включает это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:

2730301 Сборки SQL Server 2008 R2, выпущенные после выпуска SQL Server 2008 R2 с пакетом обновления 2 (SP2)

SQL Server 2008 R2 с пакетом обновления 1 (SP1)

Исправление для этой проблемы впервые выпущено в накопительном обновлении 7 для SQL Server 2008 R2 с пакетом обновления 1 (SP1). Для получения дополнительных сведений о том, как получить этот накопительный пакет обновления, щелкните следующий номер статьи базы знаний Майкрософт:

2703282 Накопительный пакет обновления 7 для SQL Server 2008 R2 с пакетом обновления 1 (SP1)Примечание. Поскольку сборки являются кумулятивными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2008 R2. Рекомендуется установить последнюю версию исправления, которая включает это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:

2567616 Сборки SQL Server 2008 R2, выпущенные после выпуска SQL Server 2008 R2 с пакетом обновления 1 (SP1)

SQL Server 2008 R2

Исправление для этой проблемы впервые выпущено в накопительном обновлении 13. Для получения дополнительных сведений о том, как получить этот накопительный пакет обновления для SQL Server 2008 R2, щелкните следующий номер статьи базы знаний Майкрософт:

2679366 Накопительный пакет обновления 13 для SQL Server 2008 R2Примечание. Поскольку сборки являются кумулятивными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2008 R2. Рекомендуется установить последнюю версию исправления, которая включает это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:

981356 Сборки SQL Server 2008 R2, выпущенные после выпуска SQL Server 2008 R2

Статус

Корпорация Майкрософт подтверждает наличие этой проблемы в своих продуктах, которые перечислены в разделе «Применяется к».

Нужна дополнительная помощь?

Ошибка при попытке сжать базу

Я
   mzelensky

07.05.18 — 18:50

Доброго времени суток!

Итак, имеется SQL server 2012 r2 и 3 подключенные базы 1С.

Модель восстановления базы у всех «Простая»

Запускаю SQL Server Management Studio, открываю список баз, далее «Задачи -> Сжать -> Файлы». В открывшемся окне выбираю:

Тип файла = Данные

Операция сжатия = «Сжать файл ДО…»

Указываю размер до которого нужно сжать и нажимаю «ОК».

Система начинает думать и примерно через 15-20 минут выдает ошибку — можно увидеть на скрине (там же видно более подробно настройки.

База тестовая, пользователей в базе нет, соединений ноль.

Ситуация повторяется на всех трех тестовых базах. Пробовал уже раз 5. Вопрос — в чем косяк, как решить?

   mzelensky

1 — 07.05.18 — 18:52

   mzelensky

2 — 07.05.18 — 18:53

   mzelensky

3 — 08.05.18 — 07:55

ап

   Симпатяга

4 — 08.05.18 — 08:08

попробуй ТИИ сделать средствами 1с

   eratmanov

5 — 08.05.18 — 08:22

Все три тестовые базы разворачивались из одной копии или создавались независимо ?

   assasu

6 — 08.05.18 — 08:35

(0)Ошибка при попытке сжечь базу

   _alex1974

7 — 08.05.18 — 08:39

места на дисках хватает? проследи во время сжатия

   mzelensky

8 — 08.05.18 — 08:41

(4) Я боюсь это не реально — большие объемы баз. А выполнять нужно монопольно

   mzelensky

9 — 08.05.18 — 08:41

(5) Все три сделаны из боевой.

   mzelensky

10 — 08.05.18 — 08:42

(7) на диске 600 Гб свободного пространства. Каждая база размером по 450 ГБ + лог на 5 гигов выростает

   МимохожийОднако

11 — 08.05.18 — 08:45

Мало места.ИМХО

   mzelensky

12 — 08.05.18 — 08:48

(11) Сколько, по твоему, должно быть?

   1Сергей

13 — 08.05.18 — 08:50

(12) х2 примерно

   Cool_Profi

14 — 08.05.18 — 08:52

dbcc checkdb не пробовал?

   _alex1974

15 — 08.05.18 — 08:54

Следи за лог-файлами, они быстро растут при сжатии и при других операциях, вроде реиндексации

Места маловато. Хорошим считается свободный объем до 70% от емкости диска, при значениях менее 30% пора задумываться об апгрейде.

   mzelensky

16 — 08.05.18 — 09:03

(15) Логи на столько не выростают. Максимум на несколько десятков гигов увеличивался и все

   mistеr

17 — 08.05.18 — 09:16

(0) А в чем цель сжатия? В большинстве случаев база быстро вырастет до своего нормального рабочего размера.

   systemstopper

18 — 08.05.18 — 09:25

(0) чувак выпей галоперидолу, не надо так делать

   xxTANATORxx

19 — 08.05.18 — 09:42

(18)а как надо?

   systemstopper

20 — 08.05.18 — 09:49

   mzelensky

21 — 08.05.18 — 09:51

(17) Цель освободить по 150 Гигов в каждой базе — это неиспользуемое место.

   mzelensky

22 — 08.05.18 — 09:51

(18) Почему Не надо? А как надо?

   systemstopper

23 — 08.05.18 — 09:52

(21) с чего ты взял что эти 150 Гб не используются?

   mzelensky

24 — 08.05.18 — 09:52

(20) Можно конкретней, что ты хотел сказать это ссылкой???

Если ты предлагаешь сделать шринкование средствами T-SQL, т оя так уже пробовал — результат тот же.

   mzelensky

25 — 08.05.18 — 09:53

(23) ТЫ скрин смотрел?

   systemstopper

26 — 08.05.18 — 09:54

(25) ЛОЛ, ты про «доступное свободное место» в ssms?

   mzelensky

27 — 08.05.18 — 09:55

(26) Именно

   mzelensky

28 — 08.05.18 — 09:57

(26) в боевой базе есть большой справочник — используется под версионирование. Там куча данных.

В разрабовских базах эти данные не нужны. Я их полностью зачищаю. В результате система выдает «доступное свободное место» в 40%…т.е. где-то 150 Гигов.

Вот эти 150 гигов я и хочу сжать, чтобы база из 450 Гигов стала 300.

   systemstopper

29 — 08.05.18 — 09:57

(27) всё это несколько сложнее чем тебе кажется снаружи…читаем (20), потом делаем (18)

   systemstopper

30 — 08.05.18 — 10:01

   ptiz

31 — 08.05.18 — 10:07

(14) +1

Сначала попробовать dbcc.

Еще перед шринком можно сделать реиндекс.

   1sanekmaloi1

32 — 08.05.18 — 10:09

(30)от 2016 sp1 все версии поддерживают сжатие. Но чет мне кажется не в ту сторону направляете ТС.

Он разово хочет сократить файл БД в котором 150 ГБ места удалили, а файл базы не уменьшился.

   mzelensky

33 — 08.05.18 — 10:10

(30) Я не первый раз такую операцию делаю. И раньше проблем не было — размер базы уменьшался до нужного размера.

Но мне кажется ты мне ссылку не по теме дал

   mzelensky

34 — 08.05.18 — 10:12

(31) Вот сейчас читаю, как это сделать. Буду пробовать

   Ёпрст

35 — 08.05.18 — 10:16

(0) выгрузи базу в dt, примени ЭТО решение.. долно быть всё норм

http://catalog.mista.ru/public/114634/

   mzelensky

36 — 08.05.18 — 10:17

(35) Выгрузить в ДТ 450 гиговую базу???

Это ж сколько времен ипотребуется?

   systemstopper

37 — 08.05.18 — 10:20

(32) а почему он должен уменьшиться?

   systemstopper

38 — 08.05.18 — 10:21

(35) не надо так делать, советовать кривые скрипты от непоймикого

   1sanekmaloi1

39 — 08.05.18 — 10:21

(37)Я разве написал что должен уменьшиться?

   Ёпрст

40 — 08.05.18 — 10:24

(36) да, не проблема. И побольше норм выгружается.

   Ёпрст

41 — 08.05.18 — 10:25

у тебя в ней мусора, больше половины, опосля решения в (35) размер будет гигов 40

   Ёпрст

42 — 08.05.18 — 10:26

А если еще и лишний мусор с базы убрать перед этим, типа мусора в рег сведений версионирование объектов каком нить, так и вообще, норм сожмётся.

Базопузомером посмотри, какие таблички скока весят в скуле

   Ёпрст

43 — 08.05.18 — 10:27

(38) это решение работает годами.

   systemstopper

44 — 08.05.18 — 10:28

(43) но оно же кривое

   systemstopper

45 — 08.05.18 — 10:28

(39) написал что нужно чтобы уменьшился

   Ёпрст

46 — 08.05.18 — 10:30

(44) чем ?

   Галахад

47 — 08.05.18 — 10:33

(0) Размеры файлов не ограничены?

А так (41)+1. Грохнуть лишнее.

   eratmanov

48 — 08.05.18 — 10:34

(9) на рабочей то-же самое ?

попробуй dbcc checkdb(имябазы)

сколько оперативки на сервере и сколько разрешено использовать скулю ?

   1sanekmaloi1

49 — 08.05.18 — 10:48

(45)В каком посте я это написал? в (32) я вам попытался объяснить действия и ожидания ТС?

в (0) метод для данной ситуации вполне рабочий, накой ему нужна компрессия всей базы которая будет делаться условно сто лет, потом через день разраб ее перезальет из бэкапа и снова компрессию?или перенастраивать настраивать скуль на компресси всех баз?Зачем?

имхо места увеличить на серваке и все будет ок.

   mzelensky

50 — 08.05.18 — 10:48

(47) размеры файлов не ограничены

(41) попробую позже, если  dbcc checkdb не поможет

   systemstopper

51 — 08.05.18 — 11:27

(46) тем что триггер

   xxTANATORxx

52 — 08.05.18 — 11:33

периодически шринкую копию для разработки после восстановления из бекапа, место уменьшается,

чяднт??? есичо MSSQL

   systemstopper

53 — 08.05.18 — 11:36

(49) Можно сделать компрессию отдельных таблиц есичо.

All Я есичесна профакапил момент что речь идет о тестовой базе

   Ёпрст

54 — 08.05.18 — 11:46

(51) и ? Чем триггер не устраивает ? Чего, при создании новой таблички в sql, будешь ручонками на неё сжатие делать ? Так, что ле ?

   Cool_Profi

55 — 08.05.18 — 11:48

(54) Погодите, я потерял нить. Идёт речь о шринке или сжатии данных в таблицах?

   systemstopper

56 — 08.05.18 — 11:48

(54) скрипт буду запускать по расписанию…который будет сжимать с учетом sp_estimate_data_compression_savings а не всё подряд

   systemstopper

57 — 08.05.18 — 11:49

(55) у ТС идет речь о шринке…я прощелкал что речь идет о тестовой базе и попытался его отговорить от этого, и если нужно сжатие, применять сжатие…т.е. мы с Ёпрст говорим про сжатие

   mzelensky

58 — 08.05.18 — 12:08

(55) у этих ребят просто свой междусобойчик 🙂

   systemstopper

59 — 08.05.18 — 12:10

(58) в Errorlog какую ошибку пишет?

   Ёпрст

60 — 08.05.18 — 12:13

(56) Не вижу смысла не сжимать все таблички в базе, а только избранные.

  

   systemstopper

61 — 08.05.18 — 12:18

(60) конечно не видишь, ведь ты не знаешь того факта что после сжатия некоторые таблицы могут стать больше

   Ёпрст

62 — 08.05.18 — 12:29

(61) хорошо, тогда всё равно проще переписать триггер, с учетом sp_estimate_data_compression_savings, чем делать это по расписанию для уже существующих таблиц

   systemstopper

63 — 08.05.18 — 13:40

(62) «делать это» не нужно, оно по расписанию запускается само…и триггер это вмешательство в структуру базы кривыми руками, потенциально опасная вещь

   Ёпрст

64 — 08.05.18 — 13:41

(63) ок. Покажите свой не кривой скрипт для сжатия бд.

   systemstopper

65 — 08.05.18 — 13:45

   mzelensky

66 — 08.05.18 — 14:17

Запустил ТиИ в одной из баз. В общем результаты плохие.

http://i.yapx.ru/BVQge.jpg

   eratmanov

67 — 08.05.18 — 14:33

(66) а у тебя жесткий диск не начал ли сыпаться ?

  

mzelensky

68 — 08.05.18 — 14:38

(67) Не, по другому было — на выходных словили шифровальщик на сервере. Все жесткие были зашифрованы. Удалось через стороннюю контору снять с зашифрованных дисков часть информации, в том числе актуальную боевую базу 1С.

Тестовые делались с нее.

Вот думаю последствия шифрования все-таки сказываются

  • Remove From My Forums
  • Question

  • Добрый день.

    MS SQL 2014 Standart with SP2 установлен на MS Win Server 2014r2 Standart.

    В связи с тем-что из софтового рэйда intel «выпал» диск и никак не хотел этим рэйдом подхватываться было решено перенести рэйд на другой контроллер(LSI 9240). Был остановлен SQL сервер, затем скопированы все файлы баз данных
    на резервный диск, затем пересобран рэйд и файлы бд скопированы обратно в те же директории. В связи с тем, что перед отключением SQL базы не были корректно отключены, начали возникать ошибки:

    Microsoft SQL Server Native Client 11.0: Операционная система возвратила ошибку 1(Неверная функция.) в SQL Server при запись в смещении 0x00000003aa0000
    файла «E:Datatempdb.mdf».

    Отключили базы, удалили целиком SQL сервер, установили с нуля, подключили обратно. Ошибка больше не появляется. Но теперь появляется ошибка при попытке сжатия базы или журнала. Резервное копирование этих баз и журналов проходит корректно, DBCC
    CHECKDB проходит без ошибок (если предварительно не сделать попытку сжатия).

    ЗАГОЛОВОК: Microsoft SQL Server Management Studio
    ——————————

    Действие Сжатие завершилось неудачно для объекта «База данных» «crm_demo».  (Microsoft.SqlServer.Smo)

    Чтобы получить справку, щелкните: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=12.0.5000.0+((SQL14_PCU_main).160617-1804)&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Сжатие+Database&LinkId=20476

    ——————————
    ДОПОЛНИТЕЛЬНЫЕ СВЕДЕНИЯ:

    При выполнении инструкции или пакета Transact-SQL возникло исключение. (Microsoft.SqlServer.ConnectionInfo)

    ——————————

    При выполнении текущей команды возникла серьезная ошибка.. При наличии результатов они должны быть аннулированы. (Microsoft SQL Server, ошибка: 0)

    Чтобы получить справку, щелкните: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&ProdVer=12.00.5000&EvtSrc=MSSQLServer&EvtID=0&LinkId=20476

    Перезапуск СУБД, естественно, пробовал. В логи ОС сыпется ошибка 9001, после отсоединения и присоединения базы ошибка в логах больше не появляется до следующей попытке сжатия базы.

    Подскажите как решить данную проблему.

Answers

  • Создайте новую базу и попытайтесь перенести в неё данные. Проще всего это сделать стандартным визардом по импорту/экспорту данных.

    Если ошибок не будет, вы получите живую беспроблемную базу
    Если ошибки будут, то вы поймёте какие именно данные пострадали и сможете подумать над тем, что теперь делать

    • Proposed as answer by

      Friday, May 26, 2017 7:25 AM

    • Marked as answer by
      Иван ПродановMicrosoft contingent staff, Moderator
      Friday, June 2, 2017 6:07 AM

  • Замена диска в рэйде не привела к желаемому результату. Обновил драйвер контроллера.

    Текущая версия: 6.707.7.0

    Предшествующая версия: 6.600.21.8.

    Неделя работы в штатном режиме. Никаких ошибок, сжатие всех бд проходит корректно. Всем спасибо за помощь. Тему можно закрыть.

    • Marked as answer by
      ИванТ
      Friday, June 9, 2017 5:38 AM

Hello,

I thought that running Shrinkfile truncate and  Shrinkfile datafile using the below scripts speed up the shrinking process, however what I achieved that the database cannot be shrinked anymore. 

Previously I used only DBCC Shrinkfile (N’prd_01_dat1′, @startsize) . This process reduces the file size by 10GB in batch.(see below)

Running the below process at first it reduced the size with couple gigabytes and shrunk it further.  However it generates an error, which is NOT visible and NOT reported as an error, although you can see that the shrinking process reaches 100% and start
a new cycle, however the database size remains what it was before. So it shows the work is finished, however it does nothing.

This happened with 2 my databases, so it looks general problem with SQL 2012.

Does anybody have any idea how to resolve this type of problem?

SQL 2012 Enterprise Edition

Thank you.

L17

USE f_data
Declare @startsize int
Declare @target int

Set @Startsize =2220000—whatever it is now (can be approximated)
Set @target = 2000000 —whatever you want, in MB

While @Startsize > @target
    Begin
        Set @Startsize = @startsize — 10000
        DBCC Shrinkfile (N’prd_01_dat1′, truncateonly)
DBCC Shrinkfile (N’prd_01_dat1′, @startsize)                 
        Print ‘Shrunk to ‘ + cast(@startsize as varchar(10))

    End

Hello,

I thought that running Shrinkfile truncate and  Shrinkfile datafile using the below scripts speed up the shrinking process, however what I achieved that the database cannot be shrinked anymore. 

Previously I used only DBCC Shrinkfile (N’prd_01_dat1′, @startsize) . This process reduces the file size by 10GB in batch.(see below)

Running the below process at first it reduced the size with couple gigabytes and shrunk it further.  However it generates an error, which is NOT visible and NOT reported as an error, although you can see that the shrinking process reaches 100% and start
a new cycle, however the database size remains what it was before. So it shows the work is finished, however it does nothing.

This happened with 2 my databases, so it looks general problem with SQL 2012.

Does anybody have any idea how to resolve this type of problem?

SQL 2012 Enterprise Edition

Thank you.

L17

USE f_data
Declare @startsize int
Declare @target int

Set @Startsize =2220000—whatever it is now (can be approximated)
Set @target = 2000000 —whatever you want, in MB

While @Startsize > @target
    Begin
        Set @Startsize = @startsize — 10000
        DBCC Shrinkfile (N’prd_01_dat1′, truncateonly)
DBCC Shrinkfile (N’prd_01_dat1′, @startsize)                 
        Print ‘Shrunk to ‘ + cast(@startsize as varchar(10))

    End

Многие администраторы Microsoft SQL Server сталкивались с проблемой значительного увеличения физического размера базы данных и файлов журнала транзакций и, конечно же, им хотелось бы каким-то образом уменьшить этот размер, для того чтобы не предпринимать какие-либо действия, связанные с увеличением свободного пространства на жестком диске. Способ уменьшить физический размер базы данных и файлов журнала транзакций в SQL сервере есть – это сжатие.

Сжатие базы данных и журнала транзакций

Содержание

  1. Что такое сжатие в Microsoft SQL Server?
  2. Как сжать базу данных в MS SQL Server?
  3. Сжимаем базу данных с помощью среды Management Studio
  4. Сжимаем базу данных с помощью инструкций SHRINKDATABASE и SHRINKFILE
  5. Рекомендации и важные моменты при сжатии базы данных

Сжатие — это процесс удаления неиспользуемого пространства в файлах базы данных и журнала транзакций.

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

Наибольший эффект от сжатия достигается тогда, когда операция сжатия выполняется после операции удаления таблиц из БД или удаления данных из таблиц.

Следует отличать процедуру сжатия журнала транзакций от процедуры усечения журнала транзакций. Сжатие — это уменьшение физического размера журнала за счет удаления неиспользуемого пространства, а усечение – это освобождение места в логическом журнале для повторного использования (т.е. образуется неиспользуемое пространство) журналом транзакций при этом размер физического файла не уменьшается.

Усечение журнала транзакций происходит автоматически:

  • В простой модели восстановления — после достижения контрольной точки, которая может возникнуть, например, после создания BACKUP базы данных, при явном выполнении инструкции CHECKPOINT, или тогда когда размер логического журнала транзакций заполняется на 70 процентов, во всех этих случаях происходит автоматическая очистка неактивной части журнала, т.е. его усечение;
  • В модели полного восстановления или в модели восстановления с неполным протоколированием — после создания резервной копии журнала при условии, что с момента создания последней резервной копии журнала была достигнута контрольная точка.

Если Вы используете модель полного восстановления или в модель восстановления с неполным протоколированием и у Вас файлы журнала транзакций слишком велики, то скорей всего Вы достаточно долго не делали BACKUP (резервную копию) журнала транзакций. В данном случае Вам необходимо сделать сначала BACKUP журнала транзакций, а затем выполнить сжатие журнала транзакций, которое мы как раз и рассмотрим чуть ниже.

Также возможно размер файлов журнала транзакций слишком большой (как при простой, так и при полной модели восстановления) за счет задержки процедуры усечения, т.е. размер журнала, состоит в основном из активной части журнала, а активную часть усечь нельзя, поэтому физический размер журнала растет. На задержку процедуры усечения влияют такие факторы как: активные длительные транзакции, некоторые сценарии отображения зеркальных баз данных и журнала транзакций, некоторые сценарии при репликации транзакций и журнала транзакций, а также усечение журнала невозможно во время операций резервного копирования и восстановления данных. В данном случае Вам нужно устранить причины задержки, затем сделать усечение (т.е. например, для полной модели восстановления BACKUP журнала), а затем сжатие до приемлемых размеров.

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

Как сжать базу данных в MS SQL Server?

Сжать файлы базы данных и журнала транзакций можно и с помощью графического интерфейса Management Studio и с помощью инструкций Transact-SQL: DBCC SHRINKDATABASE и DBCC SHRINKFILE. Также возможно настроить базу данных на автоматическое сжатие путем выставления параметра БД AUTO_SHRINK в значение ON.

Примечание! Сжатие базы данных я буду рассматривать на примере Microsoft SQL Server 2016 Express.

Сжимаем базу данных с помощью среды Management Studio

Запускаем Management Studio и в обозревателе объектов открываем объект «Базы данных». Затем щелкаем правой кнопкой мыши по БД, которую необходимо сжать, далее выбираем «Задачи ->Сжать -> База данных (или Файлы, если, например, нужно сжать только журнал транзакций)». Я для примера выбираю «База данных».

Скриншот 1

Курс по SQL для начинающих

В итоге у Вас откроется окно «Сжатие базы данных», в котором Вы, кстати, можете наблюдать размер базы данных, а также доступное свободное место, которое можно удалить (т.е. сжать). Нажимаем «ОК».

Скриншот 2

Через некоторое время, в зависимости от размера базы данных, сжатие будет завершено.

Сжимаем базу данных с помощью инструкций SHRINKDATABASE и SHRINKFILE

В MS SQL Server для выполнения сжатия файлов базы данных и журнала транзакций существуют две инструкции SHRINKDATABASE и SHRINKFILE.

  • DBCC SHRINKDATABASE – это команда для сжатия базы данных;
  • DBCC SHRINKFILE – с помощью данной команды можно выполнить сжатие некоторых файлов базы данных (например, только журнала транзакций).

Для того чтобы выполнить сжатие БД (например, TestBase) точно также как мы это сделали чуть ранее в Management Studio, выполните следующую инструкцию.

  
  DBCC SHRINKDATABASE(N'TestBase')

SHRINKDATABASE имеет следующие параметры:

  • database_name или database_id — имя или идентификатор базы данных, которую необходимо сжать. Если указать значение 0, то будет использоваться текущая база данных;
  • target_percent – свободное пространство в процентах, которое должно остаться в базе данных после сжатия;
  • NOTRUNCATE — сжимает данные в файлах с помощью перемещения распределенных страниц из конца файла на место нераспределенных страниц в начале файла. Если указан данный параметр, физический размер файла не изменяется;
  • TRUNCATEONLY — освобождает все свободное пространство в конце файла операционной системе, но не перемещает страницы внутри файла. Файл данных сокращается только до последнего выделенного экстента. Если указан данный параметр, то параметр target_percent не обрабатывается;
  • WITH NO_INFOMSGS — подавляет все информационные сообщения со степенями серьезности от 0 до 10.

Синтаксис SHRINKDATABASE

  
  DBCC SHRINKDATABASE   
  ( database_name | database_id | 0   
       [ , target_percent ]   
       [ , { NOTRUNCATE | TRUNCATEONLY } ]   
  )  
  [ WITH NO_INFOMSGS ]  

Для того чтобы сжать только журнал транзакций можно использовать инструкцию SHRINKFILE, например.

  
  DBCC SHRINKFILE (N'TestBase_log')

В данном случае мы осуществим сжатие файла журнала (TestBase_log – это название файла журнала транзакций), до его начального значения, т.е. до значения по умолчанию. Для того чтобы сжать файл до определенного размера, укажите вторым параметром размер в мегабайтах. Например, следующей инструкцией мы уменьшим размер файла журнала транзакций до 5 мегабайт.

  
  DBCC SHRINKFILE (N'TestBase_log' , 5)

Также необходимо учесть, что если Вы укажете размер меньше того, чем требуется для хранения данных в файле, то файл до этого размера сжат не будет. Например, допустим, если Вы указали 5 мегабайт, а для хранения данных в файле требуется 7 мегабайт, файл будет сжат только до 7 мегабайт.

SHRINKFILE также имеет параметры NOTRUNCATE и TRUNCATEONLY.

Синтаксис SHRINKFILE

  
  DBCC SHRINKFILE   
  (  
      { file_name | file_id }   
      { [ , EMPTYFILE ]   
      | [ [ , target_size ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ]  
      }  
  )  
  [ WITH NO_INFOMSGS ] 

Рекомендации и важные моменты при сжатии базы данных

  • Операция сжатия базы данных может вызвать фрагментацию индексов и замедлить работу БД. Поэтому слишком часто не рекомендуется выполнять сжатие базы данных;
  • Сжимать БД лучше до операции перестроения индексов, т.е. после сжатия запустите процедуру перестроения индексов;
  • Параметр базы данных AUTO_SHRINK (автоматическое сжатие) лучше не выставлять в значение ON, а оставлять по умолчанию, т.е. в OFF, если конечно у Вас нет на это достаточно серьезных оснований;
  • Инструкция SHRINKDATABASE не позволяет уменьшить размер базы данных до размера, который меньше начального, т.е. минимального. Однако инструкция SHRINKFILE сделать это может (вторым параметром указываем размер меньше минимального). Минимальный размер базы данных — это размер, который указан при создании базы данных или явно установленный операцией изменения размера БД, такой как DBCC SHRINKFILE или ALTER DATABASE. Например, если база данных была создана с размером 10 мегабайт, потом увеличилась до 100 мегабайт, ее можно сжать с помощью SHRINKDATABASE только до начальных 10 мегабайт, даже если все данные были удалены из базы данных;
  • Сжимать файлы базы данных и журнала транзакций нельзя, когда идет процесс их резервирования. И наоборот, создавать резервные копии базы и журнала транзакций нельзя пока идет процесс их сжатия;
  • Выполнение инструкции DBCC SHRINKDATABASE без указания параметра NOTRUNCATE или TRUNCATEONLY равносильно выполнению инструкции DBCC SHRINKDATABASE с параметром NOTRUNCATE после выполнения инструкции DBCC SHRINKDATABASE с параметром TRUNCATEONLY;
  • В процессе сжатия базы данных пользователи могут работать в ней (т.е. переводить БД в однопользовательский режим не нужно);
  • В любой момент времени Вы можете прервать процесс выполнения операций SHRINKDATABASE и SHRINKFILE, при этом вся выполненная работа сохраняется;
  • Перед запуском процедуры сжатия проверьте, есть ли свободное пространство для удаления в файлах базы данных, т.е. можно ли вообще сжать файлы, выполнив следующий запрос (он покажет в мегабайтах, на сколько Вы можете уменьшить файлы БД).
  •   
      SELECT Name AS NameFile,
               size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS AvailableSpaceInMB
      FROM sys.database_files;
    
    

    Скриншот 3

  • Для того чтобы выполнить процедуру сжатия БД необходимо быть членом группы роли сервера sysadmin или роли базы данных db_owner;
  • Сжатие файлов базы данных и журнала транзакций достаточно ресурсоемкий процесс, требующий определенного количества времени (в зависимости от размера файлов), поэтому данную процедуру необходимо планировать и вообще выполнять ее только в случае крайней необходимости (например, размер БД и журнала стал слишком велик и больше половины отдельно взятого файла занимает неиспользуемое пространство).

Заметка! Если Вас интересует SQL и T-SQL, рекомендую посмотреть мои видеокурсы по T-SQL, с помощью которых Вы «с нуля» научитесь работать с SQL и программировать с использованием языка T-SQL в Microsoft SQL Server.

На этом у меня все, надеюсь, статья была Вам полезна, удачи!

0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии

А вот еще интересные материалы:

  • Яшка сломя голову остановился исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного где ошибка
  • Sql server права учетной записи программы установки ошибка
  • Sql server ошибка 9694