|
А что насчет shrink database?! | ☑ | ||
---|---|---|---|---|
0
triviumfan
25.06.18
✎
10:42
|
Доброго дня, коллеги.
Наткнулся на множество статей, что не нужно ничего "шринкать", т.к. может возникнуть множество проблем (к примеру, 1ая попавшаяся https://straightpathsql.com/archives/2009/01/dont-touch-that-shrink-button/) . Но у меня ситуация примитивная... очистка таблицы, либо удаление 90% записей в ней (средствами sql). Так вот, можно ли в этом случае освободить неиспользуемое место? При этом, если использовать truncate table, то придётся сжимать саму бд, а если delete table (where...), то ещё и сам журнал (т.к. в этом случае создаются дополнительные записи). |
|||
1
triviumfan
25.06.18
✎
10:49
|
многие пишут, что все равно раз она была толстая до сжатия, то и быстро наберёт этот объем
|
|||
2
Cool_Profi
25.06.18
✎
10:49
|
В обычном режиме - не надо. Если делаешь массовые удаления - то можно.
|
|||
3
triviumfan
25.06.18
✎
10:50
|
просто у меня одна таблица занимает 60% БД, я её почистил... вроде бы в чем проблема в сжатии.. не понимаю =\
|
|||
4
чегевара
25.06.18
✎
10:53
|
Увеличится фрагментация. Проверь скриптами че там с индексами стало после шринка. И что станет с размером если потом ребилдить фрагментированные индексы?
|
|||
5
pavig
25.06.18
✎
10:53
|
(2)
Или после того, как провели ТиИ с пересчетом итогов, реиндексацией и реструктуризацией. |
|||
6
чегевара
25.06.18
✎
10:54
|
(5) да ну на
|
|||
7
pavig
25.06.18
✎
10:55
|
(6)
Нет? |
|||
8
triviumfan
25.06.18
✎
10:56
|
(5) это займёт космическое время, никто не позволит
|
|||
9
чегевара
25.06.18
✎
10:56
|
насчет журнала...он же очищается если его бэкапить...шринковать не рекомендуют именно базу, но как в (2) отмечено, после массовых удалений это единственный способ уменьшить размер
|
|||
10
чегевара
25.06.18
✎
10:57
|
(7) нет
|
|||
11
pavig
25.06.18
✎
11:31
|
(10)
После крупной реструктуризации и пересчета итогов (в случае если имели место быть "нулевые итоги") Шринк освобождает место. |
|||
12
шринк
25.06.18
✎
11:35
|
И превращает базу в фрагментированную кашу
|
|||
13
pavig
25.06.18
✎
11:37
|
(12)
Какое лечение? Дефрагментация индексов? Что еще? |
|||
14
шринк
25.06.18
✎
11:38
|
Зачем что-то лечить если правильнее не создавать проблемы?
|
|||
15
pavig
25.06.18
✎
11:46
|
(14) Ну а как не создавать, если требуется реструктуризация, например?
|
|||
16
шринк
25.06.18
✎
11:50
|
(15) зачем после реструктуризации делать шринк?
|
|||
17
Aleksey
25.06.18
✎
11:52
|
Я просто оставлю это здесь https://habr.com/post/330492/
|
|||
18
pavig
25.06.18
✎
12:05
|
(17)
Спасибо. С интересом узнал много нового. |
|||
19
triviumfan
25.06.18
✎
14:10
|
(17) https://yadi.sk/i/f-oJye3o3YNHro
Регистр "Цены". Было 80кк записей. Был выполнен срез последних, скопирован в копию таблицы и "залит" назад. Кластерный индекс дефрагментирован (а как иначе?!). Но что с некластерным? Эта ли проблема описана в статье? Почему то падения производительности я не заметил, получение цены происходит мгновенно без каких-либо тормозов. Структура регистра: https://yadi.sk/i/lKiQU1Gd3YNJRr |
|||
20
triviumfan
25.06.18
✎
14:11
|
(19) А, там отбор только по кластерным)
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |