|
12 / 13 / 5
Регистрация: 21.08.2012
Сообщений: 240
|
|
Экстремальное увеличение размера файла журнала при удалении записей18.05.2020, 08:19. Показов 6477. Ответов 28
Доброго времени суток.
При удалении записей из одной таблицы файл журнала очень сильно увеличивается в размерах, пока не займёт всё свободное место на диске. После этого операция удаления прекращается с ошибкой. Размер базы - 2.1 ГБ. В таблице, из которой удаляются записи, содержится 15 млн записей. Вместе с индексами она занимает примерно 1 ГБ (т.е. половину от общего размера базы). Удалить необходимо 13 млн записей. На диске, на котором расположена база и журнал свободно 17 ГБ. Файл журнала на момент возникновения ошибки имеет примерно такой же размер - 17 ГБ. Много раз делал подобную операцию, всегда проходила без проблем (на этом же ПК и с таким же размером свободного места). Пришлось удалять по частям. Вопрос - по каким причинам размер журнала может превысить размер базы в 8 раз? И что можно сделать в такой ситуации (кроме удаления меньшими порциями)?
0
|
|
| 18.05.2020, 08:19 | |
|
Ответы с готовыми решениями:
28
Как уменьшить увеличение размера журнала базы? При удалении учащихся из журнала удаляет все связанные записи с ним в остальных таблицах Увеличение размера файла |
|
12 / 13 / 5
Регистрация: 21.08.2012
Сообщений: 240
|
|||
| 18.05.2020, 09:49 [ТС] | |||
|
Или это нормально? Просто я раньше никогда не наблюдал за размером журнала при удалении данных.
0
|
|||
|
3614 / 2135 / 756
Регистрация: 02.06.2013
Сообщений: 5,169
|
||
| 18.05.2020, 10:12 | ||
|
Смотрите есть ли на таблице триггеры или может она задействована в индексированных представлениях. Если хотите выяснить что происходит, то можно удалить несколько строк и посмотреть, что пишется в ЖТ функцией sys.fn_dblog
0
|
||
|
12 / 13 / 5
Регистрация: 21.08.2012
Сообщений: 240
|
|||
| 18.05.2020, 11:16 [ТС] | |||
![]() Есть первичный ключ (Identity) и два индекса, один по полям типа int, другой - int + datettime. Дефрагментация обоих индексов - 95%. Удаление производилось по дате. Провёл следующие эксперименты: 1. Провёл точно такую же операцию на рабочем компе с большим количеством свободного места. Данные удалились, журнал достиг 17.5 ГБ; 2. Переиндексировал всю базу. Результат тот же; 3. Сделал удаление по Id. То же самое.
0
|
|||
|
3614 / 2135 / 756
Регистрация: 02.06.2013
Сообщений: 5,169
|
|
| 18.05.2020, 11:29 | |
|
СергейР, чудес не бывает.
При удалении в ЖТ пишется информация для undo, т.е. для обратной операции, т.е. для insert Поэтому этой информации не может быть много больше, чем объем удаляемых данных и индексов. И от критериев удаления это вообще не зависит.
1
|
|
|
12 / 13 / 5
Регистрация: 21.08.2012
Сообщений: 240
|
|
| 19.05.2020, 08:01 [ТС] | |
|
Удалил, посмотрел.
На каждую удалённую строку в журнал добавляется 3 строки: на каждый индекс и первичный ключ. Вроде всё логично. И ещё добавляется примерно 6% от общего количества записей с операцией LOP_SET_BITS. В итоге на 300 тыс удалённых записей получается примерно 318 тыс строк в журнале. Какие именно поля анализировать в журнале? P.S. Приложил файл в формате Excel (выгрузка из журнала после удаления 100 записей).
0
|
|
|
3614 / 2135 / 756
Регистрация: 02.06.2013
Сообщений: 5,169
|
|
| 19.05.2020, 09:44 | |
|
СергейР, у вас кластерная таблица. Соответственно, как и для всех индексов, строки не удаляются, а помечаются удаленными - LCX_MARK_AS_GHOST. Физически удаляются уже потом асинхронно системным процессом GHOST CLEANUP
Поэтому сразу вычислить насколько вырастет журнал не получится. Нужно с некоторой задержкой. LOP_SET_BITS - операция модификации страницы PFS. Это служебные страницы для отслеживания свободного места на страницах данных.
0
|
|
|
12 / 13 / 5
Регистрация: 21.08.2012
Сообщений: 240
|
|
| 19.05.2020, 10:24 [ТС] | |
|
Удалил 100 записей, подождал несколько минут и выгрузил данные (664 строки). Получается по 6+ строк на каждую удалённую запись. Что дальше с этим делать?
0
|
|
|
3614 / 2135 / 756
Регистрация: 02.06.2013
Сообщений: 5,169
|
|||||||||||
| 19.05.2020, 10:58 | |||||||||||
|
СергейР, анализировать записи ЖТ нужно было для поиска чего-либо, не относящегося именно к удалению строк. Такового не нашлось.
Посмотреть сколько транзакция съела в ЖТ можно так
ЗЫ: Реально ничего не удалится, просто выведется оценочный план выполнения.
0
|
|||||||||||
|
12 / 13 / 5
Регистрация: 21.08.2012
Сообщений: 240
|
|
| 19.05.2020, 15:18 [ТС] | |
|
invm, сделал всё, как Вы написали. План приложил.
Первый скрипт выдал следующее: (строк обработано: 12 901 826) (строк обработано: 1) Sum(dt.database_transaction_log_bytes_us ed), Sum(dt.database_transaction_log_bytes_us ed_system) 4 723 553 148, 0 Размер файла журнала - 17 592 896 КБ
0
|
|
|
3614 / 2135 / 756
Регистрация: 02.06.2013
Сообщений: 5,169
|
|||||||
| 19.05.2020, 16:08 | |||||||
|
СергейР, удаление отожрало в журнале всего 4 Гб. В плане ничего лишнего нет.
Если первое, то растет не из-за удаления. Если второе, то посмотрите, что вернет после возникновения ошибки запрос
0
|
|||||||
|
12 / 13 / 5
Регистрация: 21.08.2012
Сообщений: 240
|
|
| 20.05.2020, 09:00 [ТС] | |
|
invm, журнал растёт при удалении записей.
После восстановления из бекапа размер файла журнала 42 МБ. А после завершения удаления 17 ГБ. Никаких других операций с базой не делал. Ограничил своодное место на диске с базой и журналом до 10 ГБ и запустил скрипт на удаление записей. Когда файл журнала достиг 10 ГБ, а места на диске осталось 45 МБ скрипт прервался со следующей ошибкой: Сообщение 9002, уровень 17, состояние 4, строка 2 Журнал транзакций для базы данных переполнен. Причина: "ACTIVE_TRANSACTION". Ваш скрипт выдал выдал следующее: log_reuse_wait_desc ------------------------------------------------------------ NOTHING (строк обработано: 1) P.S. То же самое он выдавал и до начала удаления.
0
|
|
|
3614 / 2135 / 756
Регистрация: 02.06.2013
Сообщений: 5,169
|
||||||
| 20.05.2020, 13:17 | ||||||
|
СергейР, по вашим же данным обычная команда delete from where не может генерировать ЖТ на 17 Гб.
Можете скопировать таблицу + индексы в другую БД, запустить там удаление и посмотреть сколько ЖТ будет скушано. Добавлено через 42 минуты Кстати есть вариант, когда будет генерироваться большой объем ЖТ. Это когда данные (или подавляющее большинство данных) в таблицу заносились при выключенном READ_COMMITTED_SNAPSHOT, а потом эту опцию включили. Добавлено через 23 минуты Ну и пример вышесказанного
0
|
||||||
|
12 / 13 / 5
Регистрация: 21.08.2012
Сообщений: 240
|
|
| 21.05.2020, 15:19 [ТС] | |
|
Провёл 2 эксперимента:
1. В рабочей базе удалил из таблицы ссылки на внешние ключи (2 шт) и запустил скрипт на удаление с подсчётом размера транзакции. Результат с точностью до байта совпал с предыдущими результатами. 2. Перенёс таблицу в новую пустую базу (данные переместил с помощью мастера импорта, индексы создал скриптами). Ужал журнал транзакций до 1 МБ и запустил скрипт на удаление с подсчётом размера транзакции. Скрипт выдал размер транзакции 4 679 034 288. Изменение размеров файлов до и после удаления на скриншотах (слева - после сжатия ЖТ, справа - после удаления данных). Практически те же самые показатели, что и при удалении из рабочей базы. Опция READ_COMMITTED_SNAPSHOT в базе выключена. Принудительно я её точно не включал.
0
|
|
|
3614 / 2135 / 756
Регистрация: 02.06.2013
Сообщений: 5,169
|
||||||
| 21.05.2020, 16:19 | ||||||
|
СергейР, чудес не бывает. Что-то, раздувающее ЖТ да происходит в БД.
1. Подготовьте обе БД к удалению. Желательно их вообще перевести в монопольный режим. 2. Очистите и усеките ЖТ в обеих. 3. В обеих выполните
ЗЫ: Может выполняться долго из-за sys.fn_dblog
0
|
||||||
|
12 / 13 / 5
Регистрация: 21.08.2012
Сообщений: 240
|
||
| 22.05.2020, 13:11 [ТС] | ||
|
Суммарное значение (по 3-м индексам) в обоих случаях примерно равно тому, что выдавали скрипты раньше ~4.5 ГБ. Файлы журналов в обоих случаях достигли тех же размеров - 17.5 ГБ.
0
|
||
|
3614 / 2135 / 756
Регистрация: 02.06.2013
Сообщений: 5,169
|
|
| 22.05.2020, 13:25 | |
|
СергейР, смотрите в настройках БД размер приращения для файла журнала. Видимо стоит дефолтное 10%
Поставьте фиксированное значение, например 100 Мб или больше. Меньше не нужно - будет не очень хорошо.
0
|
|
|
12 / 13 / 5
Регистрация: 21.08.2012
Сообщений: 240
|
||
| 22.05.2020, 20:16 [ТС] | ||
|
Похоже, итоги поря подводить. В таблице 15 млн записей. Первичный ключ и 2 индекса. Размер таблицы 500 Мб, размер индексов 600 Мб. При удалении 13 млн записей (на каждую удаляемую запись создаётся 6 записей в ЖТ) размер транзакции, вычисленный скриптами, достигает 4.5 Гб. А размер файла ЖТ достигает 17.5 Гб. У данного эффекта высокая повторяемость: - в рабочей базе, в которой таблица заполнялась и в 2-х пустых базах, куда таблица импортировалась; - на 2-х разных серверах (SQL Server 2012 Expr & SQL Server 2017 Expr); - на 2-х ПК (Win 7 x32 & Win 10 x64); - с приращением журнала в % (10%) и в мегабайтах (100 Мб); Объяснить логически, как транзакция размером 4.5 Гб увеличивает размер файла ЖТ до 17.5 Гб (в 4 раза) я не могу. Но если эффект такой стабильный, может так и должно быть?
0
|
||
| 22.05.2020, 20:16 | |
|
Помогаю со студенческими работами здесь
20
Увеличение размера файла .exe ошибка при удалении записей из бд Упорядочить идентификаторы при удалении записей
Исключительная ситуация при удалении записей Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
http://iceja.net/ математические сервисы
iceja 20.01.2026
Обновила свой сайт http:/ / iceja. net/ , приделала Fast Fourier Transform экстраполяцию сигналов. Однако предсказывает далеко не каждый сигнал (см ограничения http:/ / iceja. net/ fourier/ docs ). Также. . .
|
http://iceja.net/ сервер решения полиномов
iceja 18.01.2026
Выкатила http:/ / iceja. net/ сервер решения полиномов (находит действительные корни полиномов методом Штурма).
На сайте документация по API, но скажу прямо VPS слабенький и 200 000 полиномов. . .
|
Расчёт переходных процессов в цепи постоянного тока
igorrr37 16.01.2026
/ *
Дана цепь постоянного тока с R, L, C, k(ключ), U, E, J. Программа составляет систему уравнений по 1 и 2 законам
Кирхгофа, решает её и находит переходные токи и напряжения на элементах схемы. . . .
|
Восстановить юзерскрипты Greasemonkey из бэкапа браузера
damix 15.01.2026
Если восстановить из бэкапа профиль Firefox после переустановки винды, то список юзерскриптов в Greasemonkey будет пустым.
Но восстановить их можно так.
Для этого понадобится консольная утилита. . .
|
|
Сукцессия микоризы: основная теория в виде двух уравнений.
anaschu 11.01.2026
https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/
|
WordPad для Windows 11
Jel 10.01.2026
WordPad для Windows 11
— это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .
|
Classic Notepad for Windows 11
Jel 10.01.2026
Old Classic Notepad for Windows 11
Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .
|
Почему дизайн решает?
Neotwalker 09.01.2026
В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .
|