Вход | Регистрация



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

Ошибка при попытке сжать базу
Я
   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
Вот скрин

http://yapx.ru/v/BVGZ4
   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
То что ты хочешь сделать делается не шринком, а сжатием данных https://docs.microsoft.com/ru-ru/sql/relational-databases/data-compression/data-compression?view=sql-server-2017

Но доступно только на ентерпрайз версии
   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С.

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

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


Список тем форума
Рекламное место пустует  Рекламное место пустует
AdBlock убивает бесплатный контент. 1Сергей
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует