A
Так долго тип
Size: a a a
2020 December 25
DI
Привет! А если в одном запросе в нескольких местах (в селекте и where например) юзать at time zone, он каждый раз будет тратить время на преобразование?
Мое мнение 2 раза будет. Хотя я могу ошибаться и это надо проверить.
Посмотрите в плане, есть ли конвертация и где она происходит(на предикате или pushdown на таблице) и какого она типа(явная/неявная). И по идее вторая конвертация должна быть на output dataset, но она может не показываться в плане, но должна быть.
Посмотрите в плане, есть ли конвертация и где она происходит(на предикате или pushdown на таблице) и какого она типа(явная/неявная). И по идее вторая конвертация должна быть на output dataset, но она может не показываться в плане, но должна быть.
TT
Народ, подскажите, в чем может быть причина. Ну уменьшается размер файлов tempdb. Устанавливаем нужный размер файлов, делаем шринк и не ничего не уменьшается. Место в файлах есть
f
Перезапустите службу SQL Server.
AP
Tatiana Tal
Народ, подскажите, в чем может быть причина. Ну уменьшается размер файлов tempdb. Устанавливаем нужный размер файлов, делаем шринк и не ничего не уменьшается. Место в файлах есть
DBCC SHRINKFILE (N'temp4', NOTRUNCATE)
DBCC SHRINKFILE (N'temp4' , 0, TRUNCATEONLY)
DBCC SHRINKFILE (N'temp4' , 0, TRUNCATEONLY)
AP
Где temp4 - имя файла
AP
На свой страх и риск)
M
Tatiana Tal
Народ, подскажите, в чем может быть причина. Ну уменьшается размер файлов tempdb. Устанавливаем нужный размер файлов, делаем шринк и не ничего не уменьшается. Место в файлах есть
TT
Спасибо
2020 December 26
O
Из научного интереса спрошу: пробовали это? Помогло? Просто я со своей стороны не вижу предпосылок почему эти действия должны помочь. Причина неуменьшаемости бд в постоянной активности в ней и эти действия никак на это не влияют, на мой взгляд. Допускаю, что чего-то не понимаю.
Из личного опыта - я делал "напильник". Цикл, который шринкал по чуть чуть с множеством повторов. Так удавалось потихоньку шринкануть её, хоть и не всегда.
И в большинстве случаев после этого приходилось файлы выравнивать чтобы tempdb contention не случился
Из личного опыта - я делал "напильник". Цикл, который шринкал по чуть чуть с множеством повторов. Так удавалось потихоньку шринкануть её, хоть и не всегда.
И в большинстве случаев после этого приходилось файлы выравнивать чтобы tempdb contention не случился
AP
Из научного интереса спрошу: пробовали это? Помогло? Просто я со своей стороны не вижу предпосылок почему эти действия должны помочь. Причина неуменьшаемости бд в постоянной активности в ней и эти действия никак на это не влияют, на мой взгляд. Допускаю, что чего-то не понимаю.
Из личного опыта - я делал "напильник". Цикл, который шринкал по чуть чуть с множеством повторов. Так удавалось потихоньку шринкануть её, хоть и не всегда.
И в большинстве случаев после этого приходилось файлы выравнивать чтобы tempdb contention не случился
Из личного опыта - я делал "напильник". Цикл, который шринкал по чуть чуть с множеством повторов. Так удавалось потихоньку шринкануть её, хоть и не всегда.
И в большинстве случаев после этого приходилось файлы выравнивать чтобы tempdb contention не случился
Мне тоже интересно. Я не стал очищать вчера все кеши и проделал то, что я писал
DBCC SHRINKFILE (N'temp4', NOTRUNCATE)
DBCC SHRINKFILE (N'temp4' , 0, TRUNCATEONLY)
Первая команда переносит все данные в начало файла, вторая освобождает страницы. Нашел в комментах на пост Brent Ozara по поводу шринка темп бд. И да, при этом на сервере работали пользователи.
DBCC SHRINKFILE (N'temp4', NOTRUNCATE)
DBCC SHRINKFILE (N'temp4' , 0, TRUNCATEONLY)
Первая команда переносит все данные в начало файла, вторая освобождает страницы. Нашел в комментах на пост Brent Ozara по поводу шринка темп бд. И да, при этом на сервере работали пользователи.
DI
Из научного интереса спрошу: пробовали это? Помогло? Просто я со своей стороны не вижу предпосылок почему эти действия должны помочь. Причина неуменьшаемости бд в постоянной активности в ней и эти действия никак на это не влияют, на мой взгляд. Допускаю, что чего-то не понимаю.
Из личного опыта - я делал "напильник". Цикл, который шринкал по чуть чуть с множеством повторов. Так удавалось потихоньку шринкануть её, хоть и не всегда.
И в большинстве случаев после этого приходилось файлы выравнивать чтобы tempdb contention не случился
Из личного опыта - я делал "напильник". Цикл, который шринкал по чуть чуть с множеством повторов. Так удавалось потихоньку шринкануть её, хоть и не всегда.
И в большинстве случаев после этого приходилось файлы выравнивать чтобы tempdb contention не случился
О да коллега, именно так и делал. Шринк в цикле. Но при большой нагрузке это тоже не всегда рабочий сценарий.
TT
О да коллега, именно так и делал. Шринк в цикле. Но при большой нагрузке это тоже не всегда рабочий сценарий.
Шринк в цикле не помогал, при этом в цикле стопились и все джобы
ДЗ
Tatiana Tal
Шринк в цикле не помогал, при этом в цикле стопились и все джобы
Пробовали добавить checkpoint. У tempdb с ним бывают проблемы, приходится руками делать
DI
Tatiana Tal
Шринк в цикле не помогал, при этом в цикле стопились и все джобы
Я в этих случаях делаю шринк более маленькими блоками
DI
Пробовали добавить checkpoint. У tempdb с ним бывают проблемы, приходится руками делать
Какого рода проблемы, Дима? Я такое первый раз слышу.
ДЗ
При очень интенсивном использовании, лог мог расти очень сильно и даже при зафиксированных транзакциях, место внутри лога не освобождалось
ДЗ
С файлами данных не помню какой конкретно нюанс был
ДЗ
В моём случае это проявлялось на той нагрузке, где не справляются даже новые nvme диски для tempdb, только ramdrive
DI
Я думаю что ты как раз о том,что для записи используется механизм цикличной записи. И если отрытая транзакция начала писаться в последний vlf который физически находится в конце файла, то такой файл не освободить ни как. Для этого как раз и надо сделать перенос, но он закончится только при коммите транзакции. А комит происходит через 1 минуту или при достижении размера транзакшен лог буфера, 60кб если не изменяет память.