Имя: Пароль:
IT
 
Ошибка при попытке сжать базу
0 mzelensky
 
07.05.18
18:50
Доброго времени суток!

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

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

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

Тип файла = Данные
Операция сжатия = "Сжать файл ДО..."

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

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

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

Ситуация повторяется на всех трех тестовых базах. Пробовал уже раз 5. Вопрос - в чем косяк, как решить?
1 mzelensky
 
07.05.18
18:52
Вот скрин

http://yapx.ru/v/BVGZ4
2 mzelensky
 
07.05.18
18:53
3 mzelensky
 
08.05.18
07:55
ап
4 Симпатяга
 
08.05.18
08:08
попробуй ТИИ сделать средствами 1с
5 eratmanov
 
08.05.18
08:22
Все три тестовые базы разворачивались из одной копии или создавались независимо ?
6 assasu
 
08.05.18
08:35
(0)Ошибка при попытке сжечь базу
7 _alex1974
 
08.05.18
08:39
места на дисках хватает? проследи во время сжатия
8 mzelensky
 
08.05.18
08:41
(4) Я боюсь это не реально - большие объемы баз. А выполнять нужно монопольно
9 mzelensky
 
08.05.18
08:41
(5) Все три сделаны из боевой.
10 mzelensky
 
08.05.18
08:42
(7) на диске 600 Гб свободного пространства. Каждая база размером по 450 ГБ + лог на 5 гигов выростает
11 Мимохожий Однако
 
08.05.18
08:45
Мало места.ИМХО
12 mzelensky
 
08.05.18
08:48
(11) Сколько, по твоему, должно быть?
13 1Сергей
 
08.05.18
08:50
(12) х2 примерно
14 Cool_Profi
 
08.05.18
08:52
dbcc checkdb не пробовал?
15 _alex1974
 
08.05.18
08:54
Следи за лог-файлами, они быстро растут при сжатии и при других операциях, вроде реиндексации

Места маловато. Хорошим считается свободный объем до 70% от емкости диска, при значениях менее 30% пора задумываться об апгрейде.
16 mzelensky
 
08.05.18
09:03
(15) Логи на столько не выростают. Максимум на несколько десятков гигов увеличивался и все
17 mistеr
 
08.05.18
09:16
(0) А в чем цель сжатия? В большинстве случаев база быстро вырастет до своего нормального рабочего размера.
18 systemstopper
 
08.05.18
09:25
(0) чувак выпей галоперидолу, не надо так делать
19 xxTANATORxx
 
08.05.18
09:42
(18)а как надо?
20 systemstopper
 
08.05.18
09:49
21 mzelensky
 
08.05.18
09:51
(17) Цель освободить по 150 Гигов в каждой базе - это неиспользуемое место.
22 mzelensky
 
08.05.18
09:51
(18) Почему Не надо? А как надо?
23 systemstopper
 
08.05.18
09:52
(21) с чего ты взял что эти 150 Гб не используются?
24 mzelensky
 
08.05.18
09:52
(20) Можно конкретней, что ты хотел сказать это ссылкой???

Если ты предлагаешь сделать шринкование средствами T-SQL, т оя так уже пробовал - результат тот же.
25 mzelensky
 
08.05.18
09:53
(23) ТЫ скрин смотрел?
26 systemstopper
 
08.05.18
09:54
(25) ЛОЛ, ты про "доступное свободное место" в ssms?
27 mzelensky
 
08.05.18
09:55
(26) Именно
28 mzelensky
 
08.05.18
09:57
(26) в боевой базе есть большой справочник - используется под версионирование. Там куча данных.

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

Вот эти 150 гигов я и хочу сжать, чтобы база из 450 Гигов стала 300.
29 systemstopper
 
08.05.18
09:57
(27) всё это несколько сложнее чем тебе кажется снаружи...читаем (20), потом делаем (18)
30 systemstopper
 
08.05.18
10:01
То что ты хочешь сделать делается не шринком, а сжатием данных https://docs.microsoft.com/ru-ru/sql/relational-databases/data-compression/data-compression?view=sql-server-2017

Но доступно только на ентерпрайз версии
31 ptiz
 
08.05.18
10:07
(14) +1
Сначала попробовать dbcc.
Еще перед шринком можно сделать реиндекс.
32 1sanekmaloi1
 
08.05.18
10:09
(30)от 2016 sp1 все версии поддерживают сжатие. Но чет мне кажется не в ту сторону направляете ТС.
Он разово хочет сократить файл БД в котором 150 ГБ места удалили, а файл базы не уменьшился.
33 mzelensky
 
08.05.18
10:10
(30) Я не первый раз такую операцию делаю. И раньше проблем не было - размер базы уменьшался до нужного размера.

Но мне кажется ты мне ссылку не по теме дал
34 mzelensky
 
08.05.18
10:12
(31) Вот сейчас читаю, как это сделать. Буду пробовать
35 Ёпрст
 
08.05.18
10:16
(0) выгрузи базу в dt, примени ЭТО решение.. долно быть всё норм
http://catalog.mista.ru/public/114634/
36 mzelensky
 
08.05.18
10:17
(35) Выгрузить в ДТ 450 гиговую базу???

Это ж сколько времен ипотребуется?
37 systemstopper
 
08.05.18
10:20
(32) а почему он должен уменьшиться?
38 systemstopper
 
08.05.18
10:21
(35) не надо так делать, советовать кривые скрипты от непоймикого
39 1sanekmaloi1
 
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) это решение работает годами.
44 systemstopper
 
08.05.18
10:28
(43) но оно же кривое
45 systemstopper
 
08.05.18
10:28
(39) написал что нужно чтобы уменьшился
46 Ёпрст
 
08.05.18
10:30
(44) чем ?
47 Галахад
 
гуру
08.05.18
10:33
(0) Размеры файлов не ограничены?

А так (41)+1. Грохнуть лишнее.
48 eratmanov
 
08.05.18
10:34
(9) на рабочей то-же самое ?
попробуй dbcc checkdb(имябазы)
сколько оперативки на сервере и сколько разрешено использовать скулю ?
49 1sanekmaloi1
 
08.05.18
10:48
(45)В каком посте я это написал? в (32) я вам попытался объяснить действия и ожидания ТС?

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

имхо места увеличить на серваке и все будет ок.
50 mzelensky
 
08.05.18
10:48
(47) размеры файлов не ограничены

(41) попробую позже, если  dbcc checkdb не поможет
51 systemstopper
 
08.05.18
11:27
(46) тем что триггер
52 xxTANATORxx
 
08.05.18
11:33
периодически шринкую копию для разработки после восстановления из бекапа, место уменьшается,
чяднт??? есичо MSSQL
53 systemstopper
 
08.05.18
11:36
(49) Можно сделать компрессию отдельных таблиц есичо.

All Я есичесна профакапил момент что речь идет о тестовой базе
54 Ёпрст
 
08.05.18
11:46
(51) и ? Чем триггер не устраивает ? Чего, при создании новой таблички в sql, будешь ручонками на неё сжатие делать ? Так, что ле ?
55 Cool_Profi
 
08.05.18
11:48
(54) Погодите, я потерял нить. Идёт речь о шринке или сжатии данных в таблицах?
56 systemstopper
 
08.05.18
11:48
(54) скрипт буду запускать по расписанию...который будет сжимать с учетом sp_estimate_data_compression_savings а не всё подряд
57 systemstopper
 
08.05.18
11:49
(55) у ТС идет речь о шринке...я прощелкал что речь идет о тестовой базе и попытался его отговорить от этого, и если нужно сжатие, применять сжатие...т.е. мы с Ёпрст говорим про сжатие
58 mzelensky
 
08.05.18
12:08
(55) у этих ребят просто свой междусобойчик :)
59 systemstopper
 
08.05.18
12:10
(58) в Errorlog какую ошибку пишет?
60 Ёпрст
 
08.05.18
12:13
(56) Не вижу смысла не сжимать все таблички в базе, а только избранные.
61 systemstopper
 
08.05.18
12:18
(60) конечно не видишь, ведь ты не знаешь того факта что после сжатия некоторые таблицы могут стать больше
62 Ёпрст
 
08.05.18
12:29
(61) хорошо, тогда всё равно проще переписать триггер, с учетом sp_estimate_data_compression_savings, чем делать это по расписанию для уже существующих таблиц
63 systemstopper
 
08.05.18
13:40
(62) "делать это" не нужно, оно по расписанию запускается само...и триггер это вмешательство в структуру базы кривыми руками, потенциально опасная вещь
64 Ёпрст
 
08.05.18
13:41
(63) ок. Покажите свой не кривой скрипт для сжатия бд.
65 systemstopper
 
08.05.18
13:45
66 mzelensky
 
08.05.18
14:17
Запустил ТиИ в одной из баз. В общем результаты плохие.

http://i.yapx.ru/BVQge.jpg
67 eratmanov
 
08.05.18
14:33
(66) а у тебя жесткий диск не начал ли сыпаться ?
68 mzelensky
 
08.05.18
14:38
(67) Не, по другому было - на выходных словили шифровальщик на сервере. Все жесткие были зашифрованы. Удалось через стороннюю контору снять с зашифрованных дисков часть информации, в том числе актуальную боевую базу 1С.

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

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