Ошибка "Could not allocate space..." при установке обновления

Не удается обновить ЛЭРС. Скриншот и лог прилагается.
lersproblem.png
lers.UpdateService.rar (1010 KB)

Данная ошибка говорит о том, что серверу БД не хватает свободного места для полноценной работы. Более подробно смотрите в нашей статье При обращении к базе данных произошла ошибка “Could not allocate space…”

После удаления данных за 2012 и 2013 годы, и последующего сжатия базы данных с помощью прилагаемого в инструкции скрипта, база уменьшается с 9,99 Гб до 8,83 Гб. После этого запускаем обновление, но когда процесс доходит до “Обновление базы данных”, база снова вырастает до 9,99 Гб и появляется та же ошибка.

Больше всего в базе занимают старые журналы. Подскажите вы пробовали уменьшить срок хранения журналов, как это описано в вышеприведенной статье?

Да, с этого и начали.

В том и вопрос, почему в процессе обновления база вырастает с 8,5 до 10 гигов.

Покажите настройки хранения журналов в Системных параметрах.

Какие рекомендуемые значения?
222.png
hranenie.png

Очистка журналов после изменения настроек хранения журналов в Системных параметрах происходит поздно ночью. Подскажите, с момента внесения изменения настроек хранения журналов прошли сутки?

Так же попробуйте выполнить приложенный к сообщению скрипт. Вы можете выполнить его в Managment Studio, либо, если данный компонент SQL Server у вас не установлен, выполнить скрипт посредством запуска SQLcmd.bat. И BAT-файл и сам файл скрипта должны находится в одной папке. После выполнения BAT-файла в папке появится файл SQLResult.txt с результатами выполнения скрипта. Также хочу отметить, что данный BAT-файл выполнится только если у вас настроена Windows-аутентификация на SQL Server. Если у вас аутентификация по внутреннему пользователю и паролю, выполнение указанного BAT-файла невозможно.

Результат выполнения скрипта приложите пожалуйста в ответном сообщении.
SQL.zip (731 Bytes)

После внесения изменений в сроки хранения журналов прошло больше суток.
Результат выполнения скрипта на скриншоте.
sqlscript.png

Скрипт нужно выполнить для базы данных LERS.

Раз у вас есть доступ через SQL Management Studio, то раскройте узел “Базы данных”, щелкните правой кнопкой на базе данных LERS и в контекстном меню выберите “Отчеты” → “Место занимаемое таблицами” (точное название пункта меню не помню, но смысл должен быть такой). Сохраните отчет в файл и приложите его к данной теме.

Занято места на диске
отчет.txt (5.57 KB)
mesto.png

Нужен отчет “Использование дисковой памяти таблицей”.

Файл прикреплен
otchet.xls (65.6 KB)

У вас много места занимают нештатные ситуации (2 ГБ) и файлы по объектам учета (1.9 ГБ). Предлагаю удалить старые нештатные ситуации. Для этого выполните следующий запрос:

USE LERS


DELETE FROM dbo.Contingency WHERE EndDate < DATEADD(month, -24, GETDATE());

Сделал. Файл lERS.ldf уменьшился примерно до 500 Кб, а LERS.mdf до 8,5 Гб.
После чего запустил обновление, и снова та же проблема - когда процесс дошел до “Обновление базы данных”, файл LERS.ldf увеличился до 31 Гб, а LERS.mdf до предельных 10 Гб. Висит в таком положении уже час.
обновление2.png

В скрипте вы указали dbo.Contingency, это правильно? В таблице 2 гига занимает dbo.ContingencyLog

И как удалить файлы по объектам учета?

  1. Да, замените Contingecy на ContingencyLog.

Вы можете еще больше сократить размер базы данных, изменив в приведенном выше скрипте число месяцев, за которые следует оставить данные (24) на меньшее.

  1. Удалить файлы с помощью запроса можно, вопрос в том, какое взять условие для удаления? В условии можно использовать дату добавления файла в объект учета или дату изменения файла, размер файла.

Мы сейчас пытаемся найти решение проблемы увеличения базы данных при обновлении. Завтра постараемся его подготовить.

Не удается выполнить. В таблице нет столбца EndDate.
ошибка.png