|
Ошибка при попытке сжать базу | ☑ | ||
---|---|---|---|---|
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
|
||||
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
|
||||
67
eratmanov
08.05.18
✎
14:33
|
(66) а у тебя жесткий диск не начал ли сыпаться ?
|
|||
68
mzelensky
08.05.18
✎
14:38
|
(67) Не, по другому было - на выходных словили шифровальщик на сервере. Все жесткие были зашифрованы. Удалось через стороннюю контору снять с зашифрованных дисков часть информации, в том числе актуальную боевую базу 1С.
Тестовые делались с нее. Вот думаю последствия шифрования все-таки сказываются |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |