Решение проблемы для MS SQL Server.
В течение долгого времени сжатие было доступно только в Enterprise версиях MS SQL Server, но начиная с SQL2024 Service Pack 1 эта функциональность была включена во всех редакциях, в том числе, бесплатной Express (релиз от 16.11.2024 — https://blogs.msdn.microsoft.com/sqlreleaseservices/sql-server-2024-service-pack-1-sp1-released/).
Поймать момент создания новой таблицы или индекса возможно с помощью DDL-триггера, который вызывается сразу после выполнения CREATE TABLE/INDEX, но до начала переноса данных платформой 1С. Триггер данного типа можно создать как для конкретной ИБ, так и для всего сервера. Создание триггера для ИБ не вписывается в лицензионное соглашение 1С, поэтому лучше создавать для всего сервера, тем более что это позволит обслуживать сразу все базы на данном сервере.
Создание DDL-триггера для операции создания таблицы:
CREATE TRIGGER [data_compression]
ON ALL SERVER
AFTER CREATE_TABLE
AS
—Текст триггера
Создание DDL-триггера для операции создания индекса:
CREATE TRIGGER [index_compression]
ON ALL SERVER
AFTER CREATE_INDEX
AS
—Текст триггера
Для установки признака сжатия страниц для таблицы необходимо выполнить код:
ALTER TABLE [имя базы].[имя схемы].[имя таблицы] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)
Для установки признака сжатия страниц для индекса необходимо выполнить код:
ALTER INDEX [имя индекса] ON [имя базы].[имя схемы].[имя таблицы] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)
В общем-то, уже этого достаточно, чтобы создать работоспособный механизм, который не позволит платформе 1С создать новую таблицу или индекс без сжатия, но мне захотелось большей гибкости в настройках :).
Ниже приведу решение в том виде, как оно используется у нас. Это позволило автоматически применить сжатие для всех баз данных на сервере.
Создана служебная база CompressionSetting с двумя таблицами:
1) Databases — для хранения списка баз, которые сжимать НЕ требуется.
CREATE TABLE [dbo].[Databases](
[name] [nvarchar](100) NULL,
[active] [int] NULL
) ON [PRIMARY]
Из ~200 баз на сервере я внес в эту таблицу только одну – tempdb:
2) Trace – для мониторинга работы DDL-триггеров
CREATE TABLE [dbo].[trace](
[text] [nvarchar](max) NULL,
[DatabaseName] [nvarchar](max) NULL,
[DateTime] [datetime] NULL
) ON [PRIMARY]
Далее создал 2 DDL-триггера:
1) Для таблиц
CREATE TRIGGER [data_compression] ON ALL SERVER AFTER CREATE_TABLE AS DECLARE @SchemaName nvarchar(150), @ObjectName nvarchar(150), @DatabaseName nvarchar(150), @cmd nvarchar(500) --Получим имя схемы из выполняемой команды CREATE TABLE SET @SchemaName = EVENTDATA().value('(/EVENT_INSTANCE/SchemaName)[1]','nvarchar(150)') --Получим имя таблицы SET @ObjectName = EVENTDATA().value('(/EVENT_INSTANCE/ObjectName)[1]','nvarchar(150)') --Получим имя базы SET @DatabaseName = EVENTDATA().value('(/EVENT_INSTANCE/DatabaseName)[1]','nvarchar(150)') --Сформируем из полученных данных требуемую команду на установку признака сжатия для таблицы set @cmd = 'ALTER TABLE [' + @DatabaseName + '].[' + @SchemaName + '].[' + @ObjectName + '] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)' --Теперь проверяем настройки – если базы нет в таблице CompressionSetting.dbo.Databases с признаком Active = 1, то выполняем команду, иначе игнорируем IF NOT EXISTS (SELECT 1 AS Expr1 FROM CompressionSetting.dbo.Databases AS T WHERE (name = @DatabaseName) AND Active = 1) BEGIN INSERT INTO CompressionSetting.dbo.trace (text, DatabaseName, DateTime) SELECT @cmd, @DatabaseName, GETDATE() EXEC (@cmd) END ELSE BEGIN PRINT 'TEST' END
2) Для индексов
CREATE TRIGGER [index_compression] ON ALL SERVER AFTER CREATE_INDEX AS DECLARE @SchemaName nvarchar(150), @ObjectName nvarchar(150), @TargetObjectName nvarchar(150), @DatabaseName nvarchar(150), @cmd nvarchar(500) --Получим имя схемы из выполняемой команды CREATE INDEX SET @SchemaName = EVENTDATA().value('(/EVENT_INSTANCE/SchemaName)[1]','nvarchar(150)') --Получим имя индекса SET @ObjectName = EVENTDATA().value('(/EVENT_INSTANCE/ObjectName)[1]','nvarchar(150)') --Получим имя таблицы SET @TargetObjectName = EVENTDATA().value('(/EVENT_INSTANCE/TargetObjectName)[1]','nvarchar(150)') --Получим имя базы SET @DatabaseName = EVENTDATA().value('(/EVENT_INSTANCE/DatabaseName)[1]','nvarchar(150)') --Сформируем из полученных данных требуемую команду на установку признака сжатия для индекса set @cmd = 'ALTER INDEX [' + @ObjectName + '] ON [' + @DatabaseName + '].[' + @SchemaName + '].[' + @TargetObjectName + '] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)' --Теперь проверяем настройки – если базы нет в таблице CompressionSetting.dbo.Databases с признаком Active = 1, то выполняем команду, иначе игнорируем IF NOT EXISTS (SELECT 1 AS Expr1 FROM CompressionSetting.dbo.Databases AS T WHERE (name = @DatabaseName) AND Active = 1) BEGIN INSERT INTO CompressionSetting.dbo.trace (text, DatabaseName, DateTime) SELECT @cmd, @DatabaseName, GETDATE() EXEC (@cmd) END ELSE BEGIN PRINT 'TEST' END
Сразу после создания триггеров никаких изменений в размере баз, конечно, не произойдет. Для сжатия уже имеющихся баз можно воспользоваться следующими методами:
1) Написать скрипт для поочередного перебора таблиц и индексов и установки для них признака сжатия. Мне этот вариант не понравился, т.к. на сжатие больших таблиц требуется очень много времени, база при этом раздувается, а потом очень долго уменьшается через SHRINK DATABASE.
2) Выполнить полную реструктуризацию через «Тестирование и исправление» . По времени быстрее, но база также раздувается и ее потом придется уменьшать через SHRINK DATABASE.
3) Самый оптимальный вариант, на мой взгляд – пересоздать базу через dt-файл. При этом готовая база изначально будет минимального размера, а время загрузки базы со сжатием мало отличается от загрузки в обычном режиме.
Относительно допустимости применения подобного метода сжатия я задавал вопрос в партнерской конференции, на что был в итоге получен следующий комментарий Сергея Нуралиева:
«…Можно считать позицией то, что мы считаем, что использование этих возможностей должно быть или запрещено или разрешено, но с адекватной поддержкой (методологической или программной). Вариант использования их без надлежащей поддержки мы считаем неправильным, так как он приводит к проблемам в администрировании.»
Таким образом, не думаю, что предлагаемый мной подход должен использоваться массово.
Администратор, решившийся на это, должен четко понимать что он делает и какие последствия могут быть.
В
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Пытались на своих базах оценить, какой получался выигрыш в размере БД, и какова была цена — то есть проигрыш в производительности?
(1) БД уменьшались в размерах на 40-80% в зависимости от характера данных. Значимого увеличения нагрузки на процессоры не зафиксировали.
(3) Это сильно зависит от типа конфигурации и оборудования.
У меня на сервере разработки, например, выгрузка базы УТ 10.3 размером 60-70 Гб в dt занимает около часа.
В тоже время, Консолидация объемом ~250Гб выгружается около 2-х часов.
Нафига весь этот огород с триггерами, если можно повесить регламент который будет включать сжатие. И выполнять его с нужной периодичностью. Например раз в три дня или неделю. Зависит от интенсивности изменений рабочей базы.
(5) a.ivanov, Вы, видимо, не совсем внимательно прочитали. Регламент не спасет от декомпрессии базы при очередном обновлении, а триггеры позволят изначально создавать таблицы сжатыми.
В качестве апдейта — прошло 3 года, на разных серверах мы использовали данную методику для MS SQL 2008/2012/2014 — везде полет нормальный.
Один из наиболее нагруженных серверов: >300 сжатых баз разработчиков, несколько дисковых массивов суммарной емкостью 4Тб заполнены на 80%.
Без сжатия аналогичное количество информации занимало бы >10Тб. ИМХО, неплохая оптимизация :).
В дополнение — сводный коэффициент увеличения производительности 1.9 раза по сравнению с несжатыми базами. сводное уменьшение объема 2.3 раза. Результат получен в течении нескольких лет на 134 базах находящихся под мониторингом и проверкой качества.
P.S. Последние 2 года все базы вначале сжимаются — будь то MSSQL или Oracle. На такую же технологию перевели и PostgreSQL
использую возможности ddl триггеров для отмены пересоздания таблиц при реструктуризации.
эта возможность дает:
создание собственных индексов
подменять таблицы представлениями
секционирование
перенос таблиц в другие файловые группы
те набор стандартных действий по управлению производительностью субд.
ddl триггеры поддерживаются всеми субд работающими с 1с.
подобную тему не создавал тк явно противоречит лицензии.
Статья супер. Пробуем воспользоваться, посмотрим, что получится…
К данной статье считаю, что просто необходимо привести еще одну ссылку:
а так, же прилагаю скриптик для сжатия баз
EXEC sp_MSforeachtable ‘ALTER INDEX ALL ON ? REBUILD WITH (DATA_COMPRESSION = PAGE)’
GO
EXEC sp_MSforeachtable ‘ALTER TABLE ? REBUILD WITH (DATA_COMPRESSION = PAGE)’
GO
И еще на что из статьи обратил внимание:
Важное замечание — функция сжатия таблиц доступна только для обладателей версии Enterprise SQL Server
Применили сжатие для некоторых баз. Кроме того, что места стало вагон, так и производительность прилично возросла, так как исчезли ожидания PAGELACTH.
Так что спасибо Вам огромное.
Вопрос к знатокам:
Дано:
1. 1c82, postgresql, база с большим количеством файлов в реквизитах типа хранилище_значений (сканы, pdf и т.п.). Объем базы в PGAdmin ~60Gb.
2. Обработкой вычищаю из базы файлов ~ на 17Gb. Объем базы в PGAdmin не поменялся.
3. Делаю выгрузку/загрузку в/из dt. Объем базы в PGAdmin 30Gb.
Вопросы:
1. Как уменьшить размер базы (сжать базу) БЕЗ загрузки/выгрузки в dt?
(13) SuhoffGV,
Это должно помочь —
Для MS SQL 2012 подход аналогичный?
(15) vabue,
Да, этот подход работает во всех последующих версиях — 2012/2014/2016
Статья супер, огромное спасибо. SQL server 2014 ent УТ 10.3 с 96гиг ужалась до 8.5гиг!!!!!(10х))) Комплексная 2.0 с 180гиг до 60гиг.(3х)
поясните нубу, сжатие базы — описанное в этом топике — это опция в свойствах базы >параметры>автоматическое сжатие>true? Или это что-то другое? И автошринкует ли это файл лога транзакций, или я совсем не в ту степь ушёл?
(18) inomaratadeath,
нет, к автоматическому сокращению размера БД (shrink database / auto shrink) это отношения не имеет.
Тут речь идет именно о сжатии данные в таблицах.
(16)
Несколько вопросов, если позволите:
1. Если после запуска вашего скрипта что-то пошло через ж…, то какими командами всё вернуть в статус-кво?
2. Я правильно поняла, что эта фишка работает только на Enterprise версиях?
3. Если БД расположены на твердотельных накопителях(SSD), то все телодвижения по сжатию таблиц теряют смысловую нагрузку?
Спасибо.
(21)
1 — триггер работает в рамках транзакции 1С. Если что-то пойдет не так, то 1С откатит транзакцию и сообщит об ошибке, повреждений в базе при этом не будет. Для отката изменений необходимо отключить триггер и выполнить полную реструктуризацию или выгрузку/загрузки через dt-файл.
2 — это верно для SQL2005-2014. Начиная с SQL2014 SP1 (выпущена 16 ноября 2016) сжатие доступно во всех версиях, в том числе бесплатной Express редакции.
(в публикации также скорректировал это)
3 — в общем случае, сжатие позволяет снизить нагрузку на сеть/хранилище вне зависимости от типа хранилища.
Если процессор станет узким местом, то вместо увеличения производительности можно получить обратный эффект.
Исходя из своей практики — есть смысл сжимать большие таблицы даже для очень быстрых сетевых хранилищ с 100-500k IOPS.
судя по задаваемым вопросам скоро и бухгалтера начнут заниматься администрированием sql-серверов
повесил триггер на тестовую базу, изменил текст таким образом:
CREATE TRIGGER [data_compression]
ON DATABASE
AFTER CREATE_TABLE
AS
DECLARE
@SchemaName nvarchar(150),
@ObjectName nvarchar(150),
@DatabaseName nvarchar(150),
@cmd nvarchar(500)
—Получим имя схемы из выполняемой команды CRE ATE TABLE
SET @SchemaName = EVENTDATA().value(‘(/EVENT_INSTANCE/SchemaName)[1]’,’nvarchar(150)’)
—Получим имя таблицы
SET @ObjectName = EVENTDATA().value(‘(/EVENT_INSTANCE/ObjectName)[1]’,’nvarchar(150)’)
—Получим имя базы
SET @DatabaseName = EVENTDATA().value(‘(/EVENT_INSTANCE/DatabaseName)[1]’,’nvarchar(150)’)
—Сформируем из полученных данных требуемую команду на установку признака сжатия для таблицы
set @cmd = ‘ALT ER TABLE [‘ + @DatabaseName + ‘].[‘ + @SchemaName + ‘].[‘ + @ObjectName + ‘] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)’
—Теперь проверяем настройки – если базы нет в таблице CompressionSetting.dbo.Databases с признаком Active = 1, то выполняем команду, иначе игнорируем
INS ERT INTO CompressionSetting.dbo.trace (text, DatabaseName, DateTime) SELE CT @cmd, @DatabaseName, GETDATE()
EXEC (@cmd)
получил ошибку при реструктуризации:
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка СУБД:
Microsoft SQL Server Native Client 11.0: Cannot find the object «dbo._Node6782NG» because it does not exist or you do not have permissions.
HRESULT=80040E37, SQLSrvr: SQLSTATE=42S02, state=C, Severity=10, native=1088, line=1
(24) не могли бы вы снять трассировку SQL запросов и прислать? У меня нормально работает с триггером внутри базы (SQL2014 + 8.3.7)
Добрый День всем!
мы, в нашей компании, занимаемся переводом базы 1С77 ТиС(релиз27) из файлового формата .dbf в формат MSSQL 2000 сервера. Размер базы ~900Mb.
Для этого используется стандартная, описанная, процедура данного перевода: через выгрузку-загрузку файла переноса данных базы.
Но во время загрузки файла переноса в SQL, Конфигуратор1С стопится с ошибкой от SQLя, принтскрин которой я привожу.
На всякий случай вот:
———————————————————————————
SQL State: 23000
Native: 1505
Message: [Microsoft][ODBC SQL Server Driver][SQL Server]CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID2. Most significant primary key is ‘ 15N ‘.
SQL State: 01000
Native: 3621
Message: [Microsoft][ODBC SQL Server Driver][SQL Server] The statement has been terminated.
———————————————————————————
Телодвижение с пунктом Тестирование и Исправление базы из 1C Конфигуратора- никак на результат не влияет: ошибка не уходит.
Cам я не программист 1С и не SQL dba. Я специалист по сетям..
Что можно сделать с базой или ,возможно, с настройками в SQL2000 чтобы попытаться своими силами решить проблему данной ошибки ?
(22)
(в публикации также скорректировал это)
Начиная с SQL2014 SP1
Наверно все таки Начиная с SQL2016 SP1
После запуска ваших подготовительных скриптов, в таблице dbo.Databases должны появиться рабочие базы(которые на сервере) или как?
У меня эта таблица пустая.
Спасибо.
(26)Никакими настройками, танцами с бубном и прочими выкрутасами дублирование ключевых данных не устраняется. А нужно именно оно. Но для этого надо хоть немного быть с данными на «ты».
Надо найти таблицу/ы, у которой/ых есть индекс ID2, определить по каким полям он сделан, найти записи с содержанием этих полей равным упомянутому ‘ 15N ‘, подумать над возможностью удаления нужного количества этих записей, и, наконец-то, удалить таки удалить выбранные записи.
Может лучше позвать спеца по sql базам?
Имхо, для задачи сжатия базы, лучше ограничивать область действия триггера базой данных, а не сервером. То есть использовать аргумент «ON DATABASE», а не «ON ALL SERVER»
Ещё момент — при пересоздании базы через dt-файл структура таблиц в скуле будет очищена и использование, например, триггера
приведет к аварийному падению конфигуратора и разрушению БД так как таблицы в базе ещё не будет.
(31) Может всё-таки не DT’шить, а перебор таблиц и индексов и установки для них признака сжатия?
(22)
>триггер работает в рамках транзакции 1С
>Для отката изменений необходимо отключить триггер и выполнить полную реструктуризацию или выгрузку/загрузки через dt-файл.
Если модель восстановления не полная, а простая, то также ничего страшного?
И еще пара вопросов блондинского характера, если позволите…
1.Если компрессную базу выгрузить в *.bak, а потом загрузить в другую обычную базу, то что получим на выходе по объёму, карету или тыкву?
2.То же, что и в п. 1, но *.bak от компрессной базы поднимаем на другом обычном SQL-сервере
3. Если компрессную базу отсоеденить от скулы и потом копирнуть и поднять mdf/ldf на другом обычном SQL-серваке, то как такая база себя поведет?
Спасибо.
Всем привет.
Подскажите в чем может быть проблема все сделал как указано выше но при загрузки базы из .td через не продолжительно время выдает следующую ошибку:
(Ошибка обращения к серверу 1С:Предприятия. по причине: server_addr=tcp://serv-1ctest:1560 descr=10054(0x00002746): Удаленный хост принудительно разорвал существующее подключение. line=1574 file=srcDataExchangeTcpClientImpl.cpp)
Windows Server R2 2008 x64
MS SQL R2 2008
1C 8.3.10.2252
P.S. Отключение IPv6 вот по этой статье не помогло
Читаю комменты и не могу понять, откуда люди получают увеличение производительности после сжатия. Да,дисковый ввод-вывод стал быстрее, но по остальным параметрам — замедление.
В рабочих процессах (проведение документов,формирование отчетов) скорость работы упала незначительно (до 20 мс на проведении документов и до 2-4 секунд на формировании отчетов). Зато при административных процессах (реиндексация,проверка целостности базы, реструктуризация) производительность упала на часы!
Все тесты производились в однопользовательском режиме на разных ксеонах e5-2600 (от V2 до V4) и на разных серверах.
(25) моя ошибка. Не создал таблицу trace, из-за этого падал триггер и таблица *ng не создавалась. Почему-то 1с не выдавала на этом этапе ошибку, а пыталась в нее вставить данные и получала ошибку об отсутствии таблицы.
(33)
И еще пара вопросов блондинского характера, если позволите…
1.Если компрессную базу выгрузить в *.bak, а потом загрузить в другую обычную базу, то что получим на выходе по объёму, карету или тыкву?
2.То же, что и в п. 1, но *.bak от компрессной базы поднимаем на другом обычном SQL-сервере
3. Если компрессную базу отсоеденить от скулы и потом копирнуть и поднять mdf/ldf на другом обычном SQL-серваке, то как такая база себя поведет?
Спасибо.
Сжатие сохранится во всех случаях.
(21)
1. после срабатывания триггера и включения сжатия для таблиц можно «раскукожить обратно» с помощью , заменив DATA_COMPRESSION = PAGE на DATA_COMPRESSION = NONE
(35) У меня хуже: посыпались блокировки и меня юзверя заклевали, что невозможно проводить «тяжёлые» документы. Пришлось срочно разжимать базу.
(39) Что за конфигурация, режим управления блокировками?
(39) заклевали случайно не в момент сжатия?
(40) УПП 1.3, классика, родная, не дописаная
(41) Не, не в момент. На след. день. Вроде после сжатия статистики надо было обновить и freeproccache’ить… Не помню, обновила или нет. Всё равно сервак кривой(dt’шка в базу не грузится). Хочу переподнять на 2016й винде/скуле и еще раз попробовать сжатие запендорить.
(43) тогда не уверен, что проблема связана именно со сжатием.
Аналогичные ошибки видел:
1. из-за кривого релиза платформы,
2. из-за использование кластера серверов из двух и более машин,
3. из-за того, что сам скуль-сервер изображал неизвестно что.
4. И даже из-за того, что кто-то в этот момент перепроводит какой-нибудь расчет себестоимости.
Проблема усугубляется тем, что у родной недопиленной упп-ки режим совместимости стоит 8.2.13. Я бы перешел минимум на 8.2.16 — это не потребует никаких доработок.
(44) Напомните, плиз, после обновления БД на новый релиз совместимость слетит на дефолт(8.2.13) или остается на той, которую выставили? Спасибо.
(45) после обновления конфигурации?
Там процесс обновления немного поменяется. Будут показаны расхождения с конфигурацией поставщика с возможностью выбрать. В данном случае будет регуляция банально на уровне галочек.
(46) Не, я имею в виду, что если я сниму с поддержки, выставлю режим совместимости 16, создам из этой базы файл поставки 1cv8.cf, загружу его же в БД, тем самым встав на поддержку(замок). То при следующем обновлении что будет с режимом совместимости?
1. Всё будет чики-брики: режим совместимости останется 16м
2. Всё откатится на 13й
3. Обновление на автопилоте не скушает и нужно шаманить с крыжиками
4. другое…
Добавил скрипт для сжатия путем перебора таблиц и индексов:
(48) Да, спасибо. Шустренько так запросик отработал.
Сделал все по инструкции на SQL Express 2017
Платформа 8.3.10.2561
При ТИИ, а именно
Реструктуризация таблиц информационной базы
Равно как и при любой другой реструктуризации
выдается ошибка:
Microsoft SQL Server Native Client 11.0: Недопустимое имя объекта «CompressionSetting.dbo.Databases».
HRESULT=80040E37, SQLSrvr: SQLSTATE=42S02, state=1, Severity=10, native=208, line=23
Подскажите, пожалуйста, как поправить.
(47) все зависит от следующего файла обновления скорее всего.
(50) Надо почитать, SQL Express 2017 позволяет сжатие БД
Появилась проблема при включении триггера, если использовать конструкцию:
———-
Ошибка:
А также если используются разреженные столбцы в таблицах, то при изменении индекса произойдёт ошибка:
(53)
Сам себе отвечу, пожалуй.
С триггерами, которые даже потенциально могут вызвать исключительную ситуацию нужно быть крайне осторожными.
Чтобы минимизировать эти моменты, включая те, которые были описаны в (53), можно перенести включение режима сжатия для данных в некий регламент, выбрав таблицы с помощью следующего запроса:
join sys.partitions s_part on s_tab.object_id = s_part.object_id and s_part.data_compression = 0 —выбираем таблицы с режимом ‘NONE’
join sys.columns s_col on s_tab.object_id = s_col.object_id and s_col.is_sparse = 0 and s_col.is_column_set = 0 —…и без полей с признаком разреженных столбцов
ORDER BY 1
либо триггер может всё так же формировать таблицу для выполнения команд потаблично, без модификации данных, а регламентное задание их выполнять, удаляя выполненные.
подскажите есть процедура компрессии а процедура декомпрессии есть? понятно что в 1С все стандартно — выгрузка в DT и загрузка а у меня вопрос не по базам 1С у нас есть несколько баз но я хочу понять есть ли возможность откатить их в случае чего.
(55) нужно перестроить индексы по сжатым таблицам
er — index-transact-sql?view=sql-server-2017
(движку Инфостарта не нравится ALTER, поэтому не могу вставить рабочую ссылку)
подскажите, после тестирования и исправления, MS SQL база (файл данных) увеличилась на треть (база ЗУП 3.1), текущий размер 5 Гб, немного, при этом Доступное место в базе 1,7 гб, вопрос с объемом актуальный. Как считаете стоит если сделать шринк, будет больше пользы или вреда?