Все технические форумы на одном сайте Удобный поиск информации с популярных форумов в одном месте
Вопрос: запрос переполняет tempdb

Коллеги, с наступающим!!!

Возникла проблема с запросом из прикладного ПО, tempdb позволяет одновременно выполнить только один. Запрос выполняется несколько часов, возвращает 40000000

Если одновременно запущено 2 запроса tempdb переполняется.

Как-то можно отследить, в автоматическом режиме что конкретный запрос запущен в 2-х экземплярах, ну и один убить?

Учетка не персонифицированная - сервисная.
Ответ:
tsdos
invm,

Причина - нажатие кнопки в прикладе без установки параметров поиска. 2 запроса - вероятно 2-ное нажатие.
Ну вообще если речь о поисковых запросах, параметры в которые вводит пользователь, в них обычно используют какое-то "сильное" ограничение по числу отбираемых записей типа top 100.

Потому, что больше пары десятков записей человек просматривать не должен в результатах поиска "среднепотолочном" бизнес-сценарии.
Вопрос: Почему tempdb начинает рости, когда в ней unallocated space около 20 Гб запас?

Доброе утро.

Скажите, почему tempdb начинает рости, когда в ней unallocated space около 20 Гб запас?

Стал мониторить рост tempdb, и записываю в табличку каждые 3 минуты значение



SELECT 
		(SELECT (SUM(unallocated_extent_page_count)*1.0/128) FROM sys.dm_db_file_space_usage) free_space_in_MB,
(SELECT SUM(size)*1.0/128 AS [size in MB]
FROM tempdb.sys.database_files) total_space_in_MB



Скрипт выше показывает свободного места столько же сколько и этот скрипт:
use tempdb
go
sp_spaceused @updateusage = 'TRUE' 



Однако заметил что рост tempdb начинается даже когда unallocated space около 20Гб (это 50% от общего объема tempdb).



Почему так?


Может быть я размер свободного места неправельно определяю?
Ответ: вот например был замечательный запрос с group by.
он полчаса сортировал,
затем отвалился с ожибкой переполнения.
но не за минуту ж он 100Гб переполнил

К сообщению приложен файл. Размер - 26Kb
Вопрос: насколько бэкап tempdb влияет на производительность СУБД в целом

Админы уверяют нас, что бэкап tempdb в рабочее время не будет сильно влиять на производительность работы самой СУБД с другими базами данных. Время бэкапа примерно 3 часа
Вопрос к опытным админам: так ли это? Понятно, что все зависит он нагрузки, кол-ва и качества запросов и т.д. Если упадет производительность, то примерно на сколько %.
Ответ:
abort
да там очень много много пакетов. 3 часа - это максимальное время. Если будет делаться диффер бэкап базы db1 с 9:00 до 13:00, насколько может упасть производительность СУБД в работе с другими базами данных на этом же инстансе. Одни говорят, что производительность упадет на 90%, другие что будет почти незаметно
Бакапы никак не конфликтуют с запросами любых типов к базе.

Однако, бакап потребляет ресурсы (дисковые). Если нагрузка на диски большая, то бакап отберёт часть пропускной способности дисков.
Посмотреть это можно по дисковой очереди, и следить за "временем отклика" во время бакапа. Это можно смотреть по счётчикам производительности, или в перфмониторе.
То есть если у вас к диску постояно очередь из ещё не обработанных команд, то понятно, что добавление дополнительных команд от бакапа к этой очереди не ускорит выполнение команд от рабочей нагрузки.
Поэтому и стараются делать бакапы в период наименьшей нагрузки.

Безусловно, на 90% снижения не будет, но оно может быть заметное. ИМХО я бы оценил так: от 0% до 30%.
Вопрос: Странное поведение tempdb

Доброй пятницы, товарищи!
С некоторых пор база tempdb стала себя очень странно вести, а именно, я не могу посмотреть ее свойства, мне выдается такая ошибка:

Cannot show requested dialog.
Property Size is not available for Database '[tempdb]'. This property may not exist for this object, or may not be retrievable due to insufficient access rights. (Microsoft.SqlServer.Smo)

@@VERSION:
Microsoft SQL Server 2008 (SP3) - 10.0.5500.0 (X64) Sep 21 2011 22:45:45 Copyright (c) 1988-2008 Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.0 <X64> (Build 6002: Service Pack 2)

Дело в том, что неделю назад этого не было, а DBArtisan начал показывать кучу локов на tempdb, фоновых процессов, которые затрагивают tempdb из dm_exec_requests нет, а рзмер самого tempdb.mdf увеличился на 40 гб за последние 2 дня.
sys.dm_os_waiting_tasks показывает несколько одинаковых сессий с ожиданием CXPACKET и описанием используемого ресурса exchangeEvent id=Pipe68a4df610 WaitType=e_waitPipeNewRow nodeId=18

Основная проблемы заключается в том, что я могу селектить из темповских системных таблиц типа tempdb.sys.objects, sys.partitions и т.д. только с использованием опции WITH (NOLOCK). Помогите, пожалуйста, разобраться, что не так
Ответ:
o-o
Александр52
странно это всё.

там же доступно описано.
студия со своим запросом лезет в sys.partitions,
оно -- вью поверх sysrowsets.
чтобы его читать, хотят наложить S на key,
а что-то орудующее в темпдб как раз наложило X на тот самый key.
вместо того, чтобы оттранслировать Lock request time out period exceed,
студия вываливает то, что вы видите.
отучая вас от использования GUI.

Это я понял. Спасибо еще раз.
Просто непривычно.
Вопрос: tempdb начальный размер

Подскажите пожалуйста, почему может расти начальный размер файла?
Вчера еще было tempdb.mdf\tempdb.ndf по 10 гиг, а сегодня утром ndf вырос до терабайта

причем
ALTER DATABASE tempdb MODIFY FILE (NAME = 'tempdev', SIZE = 10000)  
ALTER DATABASE tempdb MODIFY FILE (NAME = 'tempdev2', SIZE = 10000)  
ALTER DATABASE tempdb MODIFY FILE (NAME = 'templog', SIZE = 20000)

не помогает, размер не меняется

SHRINK дожимает до максимального и все. Руками пробовал изменять - тоже ничего. Ошибки не выдает, но цифры не меняются.




К сообщению приложен файл. Размер - 7Kb
Ответ:
Glory
И где скрины, подтверждающие, что это значение меняется ?

скринов, к сожалению, нет
есть только мое знание того что вчера база tempdb занимала меньше места и "Начальный размер" был совсем не таким


Glory
Вы в курсе, что на всех ваших скриншотах показано одно и тоже поле size из sys.database_files ?
И что это поле содержит текущий размер файла в страницах ?

и что?
как это ответит на мой вопрос?

я понимаю что ночью кто-то запустил запрос, из-за которого база tempdb увеличилась
я только не понимаю почему вместо с ростом базы увеличивается "начальный размер"?
Вопрос: Ошибка с tempdb

добрый день,
имеется MS SQL 2008 R2 Express, 1С сервер, 4 базы 1С (Альфа-Авто). Сервер Intel Xeon E5520 (2 процессора), 24 Гб ОЗУ, Windows Server 2008 R2 Standard.
Последнее время SQL начал чудить: когда сотрудник отдела сервиса создает заказ-наряд на ремонт авто - 1с зависает (не всегда). При этом на сервере видно, что в консоли 1С Servers растут цифры в колонках Соединение с СУБД и Захвачено СУБД, а в мониторе ресурсов идет бешеная запись/чтение файла tempdb.mdf. Пока лечится только перезапуском службы MS SQL Server, при этом если сначала не закрыть (пусть и аварийно) 1с на ПК где идет захват СУБД - перезапуск не помогает. Если удалить этот "захваченный" сеанс из консоли сервера - потом невозможно зайти в 1с, выдается ошибка сразу после ввода логина/пароля. Примечательно, что происходит это только в 1 базе и только у двух человек (которые непосредственно и создают заказ-наряды).
Что пробовал делать: 1) проверять жесткие диски с базами и логами - они в порядке; 2) переносить tempdb и сами базы на другие диски (разные), менять размер базы tempdb; 3) проверять базы 1с на ошибки; 4) чистить кэш 1С на тех двух ПК, удалять и добавлять базу в список с другим именем.
Осложняется дело тем, что ошибка плавающая, например, день-два работают нормально, на третий зависнет, хотя все делается одинаково. Помогите пожалуйста понять в чем причина такого поведения?

К сообщению приложен файл. Размер - 148Kb
Ответ:
aleks2
Не. Неправильно это. 10Гб - это ниочем.

Правильно:
1. Поймать запрос, который вешает, профайлером.
2. Накормить его индексами.


Ему надо сначала разобраться с профилактикой, а потом уже навешивать 1С индексы на таблицы, которые потом она срубит (подозреваю).

Ловить запрос профайлером нужны мало-мальские навыки...

Небось на той же машине работает сам 1С и операторы в терминальных сессиях...
Вопрос: Вопрос по tempDB

Здравствуйте.
Встал вопрос о модернизации сервера и установку pci ssd платы.
Сейчас лежит по умолчанию на C: и "весит" 30 Gb
Вопрос, стоит ли его перенести на быстрый диск, так как из него происходит быстрое рандомное чтение, а не последовательное.

Так же вопрос по количеству tempDB, сейчас один файл. Холивар на тему сколько их должно быть, понимаю, нужно что-то вроде bestpractice. То есть от чего отталкиваться, от количество процессоров, ядер, количества баз и т.д.
Спасибо, буд рад помощи советом.
Ответ:
dezhnevo
invm,

Хорошо, спасибо. Но уже сейчас вижу что в пике нагрузка на tempdb более 100%. Надо собрать больше данных
Более 100% от чего? Может я чего не понимаю, но этот ваш тул показывает измерения в попугаях.
Вопрос: tempdb growing and virtual machine (vm) ?

собственно субж.

делается селект в временную таблицу 2млн записей, как результат tempdb ростёт более 99гигов

другой транзакции на сервере нету - только я :)

		CREATE TABLE #t (
			ColHeaderId INT,
			ColNumber INT,
			ColDate DATETIME,
			DepColId INT,
			ArrColId INT,
			ScheduledTDep DATET,
			ScheduledTArr DATET,
			SequenceNumber INT,
			TailNumber VARCHAR(4),
			DataRevisionTypeId TINYINT,
			UpdatedByUserId INT,
			UpdatedDateT DATET
		);


* в плане нету никаких споолов.

* параметры TempDb - по умолчанию

есть подозрение на VM (virtual machine), так как тоже самое но на другом сервере tempdb в разумных пределах 2-4 гига



еххх куда копать?
Ответ: Ради спортивного интереса:
Взял backup клиента, запустил процедуру локально - vсё "нормуль" - TempDB растёт до мах 4gb.
У клиента TempDb уходил в нирвану жрал весь диск (99gb) и накрывалсьа изза нехватки места.

версия MSSQL 2008 R? (уточню попозже) 64b
Вопрос: оптимальный размер tempdb

Всем добра. народ есть база 100 000 гигов стоит простая модель восстановления

Итак суть вопроса зашел на оф сайт мелкомягких нашел статью по оптимизации работы BD, так вот в ней написано, что если база больше 200 метров то желательно поставить автоувеличение tempdb на 10 процентов.

Из многих статей в инете нашел закономерность при связке 1с и SQl размеры ставятся 200 метров на базу увеличение и 50 метров на лог.


Так где же истина при моей базе в 100 000 гигов , так же интересует вопрос какими должны быть параметры автоувеличения при базах в 5 10 20 гигов.

Перерыл весь гугл не чего дельного показывающие закономерность не нашел.

Прошу помощи у гуру с небольшим описание что к чему и почему.


Спасибо!!!
Ответ:
o-o
alexeyvg
Если я делаю много операций в tempdb, то её перенос на софтварный РАМ-диск ничего не даст, по сравнению с простой отдачей этой памяти сиквелу?

я так понимаю, ГСА намекает, что памяти лишней не бывает.
когда на диске лежит много больше (Tb), чем памяти у сервера
(а у кого не так?)
да еще мы кусок отрежем под темпдб,
это ж PLE вообще в 0 уйдет
Это понятно, то есть когда сервер, например, делает сортировку в tempdb, то наверное выгоднее не держать tempdb в РАМ, а просто эту память отдать сиквелу.
Но вот если я сам делаю много временных таблиц, активно работаю с tempdb, то будет ли сиквел держать эти объекты в памяти, не насилуя диски, или он не сумеет всё это правильно распределить?
Вопрос: Где лучше разместить tempdb на не совсем хорошо сконфирурированном сервере?

Коллеги, приветствую!

Имеется не совсем хорошо сконфикурированный сервер.
RAID1 под систему, RAID1 под прочие, не особо загружающие диск надобности, RAID10 - под БД.
Места на дисках много, и tempdb - можно разместить в любом месте.
Куда ее поместить лучше всего, и будет ли выигрыш до такой степени значительным, чтобы заморачиваться выбором?
Т.е. не всё ли равно?
Ответ:
uaggster
почему то появляются PAGELATCH_(ХХ)

PAGELATCH_XX <> PAGEIOLATCH_XX.
Paul Randal

PAGELATCH_XX
This is contention for access to in-memory copies of pages.
The most well-known cases of these are the PFS and SGAM contention that can occur in tempdb under certain workloads.
To find out what page the contention is on, you’ll need to use the DMV sys.dm_os_waiting_tasks to figure out what page the latch is for.
For tempdb issues, Robert Davis (blog|twitter) has a .
Another common cause I’ve seen is an index hot-spot with concurrent inserts into an index with an identity value key.

т.е. вообще никаким местом к диску.
это обычно к тому, что надо увеличить число файлов в темпдб, если это его латчи.
или флаг 1118 выставлять.
но сперва смотрят, чье это все.
как смотреть, выше ссылка дана