Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Сжатие log файла при наличии MEMORY_OPTIMIZED таблиц
|
|||
|---|---|---|---|
|
#18+
Есть 2 одинаковых тестовых базы с 2мя тестовыми таблицами. отличие в том что на второй тестовой базе создана FILEGROUP под MEMORY_OPTIMIZED_DATA и создана одна таблица с директивой (MEMORY_OPTIMIZED=ON) Данные в эту таблицу даже не вставляются. (полный код скрипта на создание приложен ниже) Recovery model в обеих случаях FULL Делаем full database backup в тестовые таблицы записываются данные. После команды BACKUP LOG вижу что log_reuse_wait_desc = Nothing однако в dm_db_log_info вижу что в первой базе VLF файлы транкейтятся и vlf_active=0 , во второй где есть MEMORY_OPTIMIZED таблица куда данные даже не записываются эти VLF файлы начинают пожизненно оставаться vlf_active=1 вот пошаговое описание того что я делаю Код: sql 1. 2. Создаем 2 тестовые базы и тестовую table_1 Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. Делаем full backup Код: sql 1. 2. 3. для второй базы создаем MEMORY_OPTIMIZED таблицу (путь на диск впишите свой:) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Заполняем тестовые table_1 чтобы увеличился лог файл Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Видим что для того чтобы начали освобождаться VLF т.к у нас full recovery , нам нужно сделать бекап лога Код: sql 1. 2. 3. 4. 5. 6. ворнул для обеих баз log_reuse_wait_desc = LOG_BACKUP перед этим смотрим что нам возвращает Код: sql 1. 2. 3. видим что у нас создались vlf файлы и большинство из vlf_active=1. Пока все на обеих базах одинакого. Делаем бекап лога Код: sql 1. 2. 3. 4. 5. И далее смотрим что у нас получилось в Код: sql 1. 2. 3. И в случае первой базы мы видим что почти все VLF файлы почищены, можно ужимать лог файл (если требуется) а вот в случае второй бызы VLF файлы как были активны так и были, хотя якобы log_reuse_wait_desc = nothing. прилагаю 2 скриншота. (ps на всякий случай, уточню что с базами делается только то что выше описано кодом, DBCC OPENTRAN ествественно возвращает No active open transactions. в обоих случаях) т.е лог на второй базе будет расти и расти пока не выжрет все место(( я пока мало знаком с MEMORY_OPTIMIZED структурами, что я не учитываю, как мне освободить лог ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2019, 11:09 |
|
||
|
Сжатие log файла при наличии MEMORY_OPTIMIZED таблиц
|
|||
|---|---|---|---|
|
#18+
так и не понял как приложить jpg файл... choose file я делаю а дальше никакой реакции( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2019, 11:12 |
|
||
|
Сжатие log файла при наличии MEMORY_OPTIMIZED таблиц
|
|||
|---|---|---|---|
|
#18+
vadimman, почему Вас это беспокоит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2019, 11:19 |
|
||
|
Сжатие log файла при наличии MEMORY_OPTIMIZED таблиц
|
|||
|---|---|---|---|
|
#18+
Владислав Колосов, ды как, я ж написал, что VLF не освобождается, лог файл не может повторно использоваться и растет до опупения, на самом деле эта ситуация с которой столкнулись на реальной продакшн базе, просто тут я чтобы голову людям не забивать сделал 2 тестовых упрощенных базы... сейчас чтобы сжать такую базу ее приходится переводить в симпл рекавери , делать чекпоинт и потом обратно в фул рекавери но это изврат :) хочу разобраться в проблеме ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2019, 12:14 |
|
||
|
Сжатие log файла при наличии MEMORY_OPTIMIZED таблиц
|
|||
|---|---|---|---|
|
#18+
vadimman, А почему вы решили, что виновником этого является IN-MEMORY? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2019, 12:57 |
|
||
|
Сжатие log файла при наличии MEMORY_OPTIMIZED таблиц
|
|||
|---|---|---|---|
|
#18+
a_voronin, ну если посмотрите код выше, это единственное отличие ) предположил я об этом случайно, издевался над тестовой базой у которой не шринкался лог, и так и сяк... потом подумал ,а что если деатачнуть ее, удалить лог и заново прикрепить в восстановлением лога:) Но уперся в то что в базе уже была memory optimized file group , подумал что это может как-то влиять. Сделал для абсолютной чистоты 2 тестовые базы и похоже да, как-то оно влияет на освобождение виртуальных файлов лога, причем именно только в full recovery mode... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2019, 13:02 |
|
||
|
Сжатие log файла при наличии MEMORY_OPTIMIZED таблиц
|
|||
|---|---|---|---|
|
#18+
vadimman, Пишут про какие то ошибки с In-Memory в 2017 RTM, накатите какой нибудь CU поновее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2019, 14:11 |
|
||
|
Сжатие log файла при наличии MEMORY_OPTIMIZED таблиц
|
|||
|---|---|---|---|
|
#18+
alexeyvgvadimman, Пишут про какие то ошибки с In-Memory в 2017 RTM, накатите какой нибудь CU поновееНапример, https://dba.stackexchange.com/questions/216982/sql-server-2017-log-file-growth-with-memory-optimized-table ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2019, 14:12 |
|
||
|
Сжатие log файла при наличии MEMORY_OPTIMIZED таблиц
|
|||
|---|---|---|---|
|
#18+
vadimman, сильно подозреваю что нужен фулл после добавления файловой группы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2019, 14:12 |
|
||
|
Сжатие log файла при наличии MEMORY_OPTIMIZED таблиц
|
|||
|---|---|---|---|
|
#18+
а не, дело в CHECKPOINT для memory optimized. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2019, 14:27 |
|
||
|
Сжатие log файла при наличии MEMORY_OPTIMIZED таблиц
|
|||
|---|---|---|---|
|
#18+
так и пишут авторFor memory-optimized tables, an automatic checkpoint is taken when transaction log file becomes bigger than 1.5 GB since the last checkpoint. This 1.5 GB size includes transaction log records for both disk-based and memory-optimized tables. после этого лог попустит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2019, 14:28 |
|
||
|
Сжатие log файла при наличии MEMORY_OPTIMIZED таблиц
|
|||
|---|---|---|---|
|
#18+
TaPaK, а для memory optimized свой чекпоинт? на обычный в режиме full recovery он не реагирует ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2019, 14:36 |
|
||
|
Сжатие log файла при наличии MEMORY_OPTIMIZED таблиц
|
|||
|---|---|---|---|
|
#18+
vadimmanTaPaK, а для memory optimized свой чекпоинт? на обычный в режиме full recovery он не реагирует в смысле не реагирует? руками CHECKPOIN или как написано 1,5gb https://docs.microsoft.com/en-us/sql/relational-databases/in-memory-oltp/checkpoint-operation-for-memory-optimized-tables?view=sql-server-2017 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2019, 14:37 |
|
||
|
Сжатие log файла при наличии MEMORY_OPTIMIZED таблиц
|
|||
|---|---|---|---|
|
#18+
alexeyvg, интересно, спасибо! посмотрю и в эту сторону) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2019, 14:40 |
|
||
|
Сжатие log файла при наличии MEMORY_OPTIMIZED таблиц
|
|||
|---|---|---|---|
|
#18+
vadimmanalexeyvg, интересно, спасибо! посмотрю и в эту сторону) в общем по вашим же скриптам чек и бекап всё освободил ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2019, 14:43 |
|
||
|
Сжатие log файла при наличии MEMORY_OPTIMIZED таблиц
|
|||
|---|---|---|---|
|
#18+
vadimman, не думаю, что проблема имеет такие масштабы, какие Вы описали. Для кого-то и 1.5 Гб "большой лог". Журнал растет из-за отсутствия резервного копирования и из-за незавершенных транзакций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2019, 14:57 |
|
||
|
Сжатие log файла при наличии MEMORY_OPTIMIZED таблиц
|
|||
|---|---|---|---|
|
#18+
накатывание последних обновлений не помогло... причем такое же поведение замечено если объявлен пользовательский table type c memory_optimized и в какой-нибудь процедуре использована такая табличная переменная... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2019, 08:45 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39803363&tid=1687937]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
64ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
74ms |
get tp. blocked users: |
2ms |
| others: | 266ms |
| total: | 455ms |

| 0 / 0 |
