Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
можно ли делать SHRINKFILE во время работы пользователей? DBCC SHRINKFILE (N'base_log' , 0, TRUNCATEONLY) (а потом сразу full бэкап) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2019, 10:35 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
trewможно ли делать SHRINKFILE во время работы пользователей?Да. Но лучше его никогда не делать, а тем более автоматически по расписанию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2019, 10:50 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
alexeyvg, Спасибо, понятно. Место на диске мало. Вот и хочу привести файлы логов в маленькие размеры. (бэкап лога делается) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2019, 10:57 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
alexeyvg, Сейчас и базы и бэкапы на одном диске)) Временно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2019, 10:58 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
trew, как Вам поможет шринкфайл, если размер базы завтра снова увеличится? Или оптимизируйте зранение путем нормализации данных или докупайте диски. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2019, 11:26 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
trew, ... Единственное прямое назначение SHRINKFILE - это подготовка базы к резервному копированию с целью долговременного хранения или транспортировки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2019, 11:28 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
Владислав Колосовtrew, ... Единственное прямое назначение SHRINKFILE - это подготовка базы к резервному копированию с целью долговременного хранения или транспортировки. Это прям очень смелое заявление. А как же такое? Код: sql 1. Это какое-то кривое назначение? Ну и еще есть рекомендации сжатия журнала транзакций для снижения фрагментации VLF'ов, например, здесь: https://www.sqlskills.com/blogs/kimberly/8-steps-to-better-transaction-log-throughput/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2019, 12:07 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
trew, Конечно, если совсем приперло, и другой опции нет - то да, можно шринкать файлы в фоне обычной работы пользователей с базой. Но, надо учесть, что: - Могут быть сильные просадки в подсистеме I/O - экстенты грузятся с диска в память, ожидания типа PAGEIOLATCH_SH - низкоуровневые лэтчи на объекты БД - Задача DBCC SHRINK%object% - это прибрать по максимуму все пустые области, размеченные внутри файлов логов/данных, - поэтому он не заботится о всем том, что происходит наверху, на уровне логики, и что старательно причёсывает процесс работы с индексами, посему физический порядок страниц может быть хаотичен, как следствие - замедленные операции чтения/вставки в этом хаосе - индексные последовательности могут оказаться физически разбросаны по диску, со всеми понятными вытекающими. Желательно сразу же сделать ребилд индексом после шринка А вообще - лучше делать шринк, взяв БД в монопольный доступ - ALTER DATABASE SET SINGLE USER Так же учесть, что если БД состоит из нескольких файлов, и есть желание шринкануть их всех - то эта операция последовательная, а не параллельная ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2019, 14:41 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
Minamoto, А миграцию в файлах в каких случаях производят? По-моему как раз в случае переезда на новый носитель. Вторая же рассмотренная ситуация - это удачное применение побочного эффекта. Устраивать же регулярный "баян", который любят рекомендовать не особо понимающие не особо понимающим на просторах инета - гораздо хуже, чем не знать о полезных качествах сжатия в _особых_ ситуациях. Просто моё мнение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2019, 15:07 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовЕдинственное прямое назначение SHRINKFILE - это подготовка базы к резервному копированию с целью долговременного хранения или транспортировки. неверно, например, есть база 24/7 в несколько Тб, в результате чего-то-там (например, изменение архитектуры) реально оттуда используется, скажем, всего 1-2 Тб... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2019, 15:55 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
ну и при резервном копировании это неиспользуемое пространство не влияет на объем бэкапа ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2019, 15:57 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
Критик, то есть для изменения архитектуры специально единовременно расширяют хранилище? А если второй раз придется изменить архитектуру, что делать с существующими файлами на дисках, перемещать? Не слишком ли накладно, если крупные релизы происходят раз в 2-3 месяца? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2019, 16:32 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
Критикну и при резервном копировании это неиспользуемое пространство не влияет на объем бэкапа Влияет. Страница пишется в бякап целиком, независимо от заполнения. Не пишутся только свободные страницы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2019, 16:42 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
Критикну и при резервном копировании это неиспользуемое пространство не влияет на объем бэкапа зато оно влияет на размер файлов данных/лога при восстановлении а отсюда возникает как минимум две проблемы 1. Если нужно развернуть на каком-то другом железе, требования по свободному месту выше 2. При ресторе FULL бекапа, файл лога нужно "забить нулями", ну т.е. физически перезаписать. Следовательно, чем больше файл лога, тем дольше время восстановления. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2019, 16:46 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
aleks222Влияет. Страница пишется в бякап целиком, независимо от заполнения. Не пишутся только свободные страницы. шринк не меняет заполненность страниц, в худшем (или лучшем) случае перемешает страницы и "хвоста" файла в начало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2019, 16:49 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовКритик, то есть для изменения архитектуры специально единовременно расширяют хранилище? А если второй раз придется изменить архитектуру, что делать с существующими файлами на дисках, перемещать? Не слишком ли накладно, если крупные релизы происходят раз в 2-3 месяца? Зачем что-то расширять? Например, часть функционала уехала в совсем другую базу. Или перешли от подневных остатков к хранению проводок и т.д. В результате неиспользованное пространство занимает столько, насколько база не вырастет за несколько лет. И эта база периодически восстанавливается на дев/тест. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2019, 18:38 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
Критикну и при резервном копировании это неиспользуемое пространство не влияет на объем бэкапа во-первых, автор шринкает лог. а во-вторых, может быть интересен не размер бэкапа, а размер отресторенной базы, и если у базы терабайтный лог, как у Гавриленко, отресторенная база, мягко говоря, не везде влезет. а может ее несут девелоперам на сервер с небольшим диском, да и ждать зануление терабайта не всем хочется. ------- файлы данных тоже, бывает, надо шринкать. на новом месте товарищи хранили файлы как на диске, так и в таблице, т.е. было дублирование. приняли решение хранить файлы только на диске. в таблицу вместо файлов занесли налл. места высвободилось 9/10 всего объема базы. и да, шринканули базу, ибо таскать за собой на девелоперский сервер тучу пустого места никому не надо. а ресторим часто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2019, 14:20 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
Владислав Колосовtrew, ... Единственное прямое назначение SHRINKFILE - это подготовка базы к резервному копированию с целью долговременного хранения или транспортировки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.08.2019, 22:30 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
Да тупо разработчики понаменяли в таблицах всякого, так что от таблиц - только названия остались. Тогда Alter table rebuild по всей базе + DBCC SHRINKFILE. У меня так один раз база из 2,5 Тб в 400 Гб превратилась. ... влезла целиком на ССД и новый сервер из плана по закупкам плавно переместился в светлое будущее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2019, 09:36 |
|
||
|
можно ли делать SHRINKFILE во время работы пользователей
|
|||
|---|---|---|---|
|
#18+
uaggster... влезла целиком на ССД и новый сервер из плана по закупкам плавно переместился в светлое будущее. вот неумные люди, нужно было сначала закупить, а потом оптимизировать :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2019, 18:07 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39848149&tid=1687409]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
125ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
31ms |
get tp. blocked users: |
1ms |
| others: | 223ms |
| total: | 406ms |

| 0 / 0 |
