Спасибо за отзыв. Много мыслей и разных наработок за это время, и очень мало времени, к сожалению. Канал был всегда для души, поэтому надо "поймать волну" :)
@@datainternalsru6025 накидал ещё в копилку) что интересного от вас хотелось бы послушать: партициорование, колоночные индексы, анализ и диагностика always on, всякие фишки и плюшки по ней как раз, очень интересного было бы послушать про новинки в 2019 и 2022 сервере, про диагностику интересного было бы посмотреть. Правда канал для души, смотрится очень интересно не скучно.
Александр, приветствую! Спасибо большое, за очередной интересный доклад. А что делать в большой, промышленной среде , хотя бы на 30+ инстансов(на разных хостах)? Дело в том, что эта утилита требует ручной настройки и судя по всему за ней нужно следить(с блокировками и профайлером шутки плохи). Есть ли какое-то решение/лучшие практики как построить автоматизированный мониторинг большого числа инстансов(с алертами)? Сам использую zabbix+TSQL, в принципе все работает. Но было бы очень интересное послушать Ваше мнение)
Виктор, приветствую! Хороший вопрос:) Ну... давайте начнем с того, что определимся хотим ли мы видеть платное или бесплатное решение:) Ну и предполагаю ответ, что хотелось бы конечно что-то, что не будет стоить, как "чугунный мост" . И вот тут наступает немая пауза, потому что все крутые мониторинги именно под SQL, подчеркну именно заточенные под SQL - они платные. Я говорю про те, которые могут и специализированно мониторить, т.е. понимают, чем latch от lock отличается и знают про клерк памяти, если нужно мониторить базовые показатели, жизнь сервиса, но не погружаться сильно глубоко, то мне тут нравится SCOM от Microsoft. Свою задачу он знает и решает, но "глубины" от него, к сожалению, ждать сильно не приходится, но алерты и т.д. там все это есть. Теперь про бесплатное и вот решение zabbix+tsql мне кажется, что самое крутое, если кто-то может предложить тут в комментах еще что-то велком! Я буду только ЗА! Есть еще вот такая штука sqlwatch.io/, она опенсорсная, построенная на tsql+powerbi, но алертить, кажется мне, не умеет. ну и лично у меня были некоторые проблемы с настройкой, но выглядит круто и знает про многие аспекты "жизни" SQL Server. Посмотрите, может быть понравится концепция :)
Спасибо за развернутый ответ! :) По поводу платных решений: Наверное, проще выбрать / сделать свое условно бесплатное решение. Заплатить ДБА который его напишет, внедрит, будет интерпретировать отчеты и оперативно реагировать на алерты. Нет толку от платного решения без ДБА, который может его разобрать и вылечить все issues (ИМХО). Однако, может быть вы знаете какие-нибудь платные решения с “killer features”, что даже коллектив высококвалифицированных MS SQL инженеров быстро и качественно их не сделает в разумный срок(пара месяцев)? Над покупкой такого прорывного решения можно и задуматься.. Глянул sqlWatch - здорово! Как минимум 38 неплохих issues + готовый TSQL + примеры визуализации... еще и в свободном доступе, это очень круто. Тут сразу вспоминается RAP от Microsoft :)) Вопрос: Есть ли где-то список issues которые потенциально может поймать RAP. Их изучение и анализ очень бы пригодилось при построении системы мониторинга многим специалистам по SQL Server?
@@viktorbekker1232 что-то из платного мне сложно советовать, потому что я его не использую. Однако, я сталкивался с правильными картинками из этого софта, по которым можно понять насколько детальная внутри информация. Вот тут нашлась линка на какой-то сайт: www.comparitech.com/net-admin/sql-server-monitoring-tools/ где в ТОП7 "сидят" как раз эти софтины. У них у всех есть триалки, поэтому можно поковырять, посмотреть. Однако, надо понимать, что все они "под капотом" используют одни и те же механизмы - DMV, xEvent, perfmon. Вот 3 основых источника информации у всех, поэтому сделать какую-то "вау фичу" не просто, так чтобы она не появилась у конкурентов через релиз (условно говоря), потому что источники информации ясны, более того запросы все трассируются на "раз два". Поэтому я думаю, что у всех примерно равные возможности будут. И еще момент, надо очень внимательно смотреть за тем, что они будут творить с вашим сервером, нагрузка от этих туловин может быть. Еще посмотрите в сторону скриптов от Брен Озара - www.brentozar.com/first-aid/ Тут довольно много чего есть интересного. RAP от Microsoft... там очень много проверок, этот софт с историей. Одних только вариантов issue там более 600-700 сотен, насколько я помню. Списком все эти "проблемы" я сомневаюсь, что можно найти где-то в открытом доступе, это было бы нарушением прав скорее всего.
Здравствуйте, извиняюсь если немнго не по теме, сталкивались ли вы с тем что события query_post_execution_showplan и query_post_execution_plan_profile не генерируют план для некоторых запросов?
Добрый день! Мне кажется, что я такое видел, но мне везло и нужные мне планы всегда ловились без проблем особых. Вот интересная статья, где собран список причин, по которым могут быть проблемы при решении проблем с планами запросов. www.dnsstuff.com/sql-server-query-plan-was-not-collected А какой тип кода вы трассируете и не видите плана? Хранимка, динамический sql,... ?
@@datainternalsru6025изначально проблема обнаружилась c parameterized query внутри хранимки. Но также повторяется и с ad hoc запросом полученным из него. Упрощал проблемный запрос, но не смог выявить прямой зависимости ни от числа джойнов, ни от набора результирующих полей, получателя данных, хэша текста запроса итд. При некоторых условиях даже изменение текста комментария могло повлиять на генерацию события. События query_post_execution_showplan и query_post_execution_plan_profile не генерируются, но например генерируется query_thread_profile. Из особенностей в запросе большое число результирующих полей (>100) и число джойнов (>20) но сам запрос простой, нет сложной логики.
@@Ренат-ц8ж, отключили и генерируется сейчас? Вообще, странно, я всегда думал, что post_execution_showplan является фактом выполнения запроса и отображение реального плана. Любая параметризация simple/forced - это оптимизация компиляционных издержек и памяти, opt. for adhoc параметр не кеширует первое исполнение adhoc запроса, но как это может влиять на появление actual plan, не понимаю, если честно. Просто если взять adhoc и выполнить и включить отображение актуального плана - вы его получите, как он там кешироваться будет или нет, это вас уже не волнует, план вы получите. Думаю, как и событие xevent тоже, должны получить, процесс кеширования по-идее тут не должен влиять. Вообще, интересно. А какая версия у вас sql server?
Не надо извиняться за долгое видео, видео очень полезное! Жаль, что перестали выпускать ещё обучающие видео, вас слушать одно удовольствие.
Спасибо за отзыв. Много мыслей и разных наработок за это время, и очень мало времени, к сожалению. Канал был всегда для души, поэтому надо "поймать волну" :)
@@datainternalsru6025 накидал ещё в копилку) что интересного от вас хотелось бы послушать: партициорование, колоночные индексы, анализ и диагностика always on, всякие фишки и плюшки по ней как раз, очень интересного было бы послушать про новинки в 2019 и 2022 сервере, про диагностику интересного было бы посмотреть. Правда канал для души, смотрится очень интересно не скучно.
Полезный материал. Хотелось бы узнать о расшифровке Wait Resourse о котором упоминается на отметке 50:09.
Константин, приветсвую!
Да, это можно , например, 'KEY: 5:72057598157127680 (92d211c2a131)'
KEY - это указательно на факт, что мы лочим ключ индекса
5 - это номер базы данных
72057598157127680 - это partition_id (см select * from sys.partitions where partition_id = ...)
92d211c2a131 - указатель на значение, которые блокируется.
Есть вот такой скрипт, к сожалению, я не знаю кто его автор, поэтому формирую как есть (если подскажете автора, обязательно укажу авторство)
declare @keyValue varchar(256);
SET @keyValue = 'KEY: 5:72057598157127680 (92d211c2a131)' --Output from deadlock graph: process-list/process[waitresource] -- CHANGE HERE !
------------------------------------------------------------------------
--Should not have to change anything below this line:
declare @lockres nvarchar(255), @hobbitID bigint, @dbid int, @databaseName sysname;
--.............................................
--PARSE @keyValue parts:
SELECT @dbid = LTRIM(SUBSTRING(@keyValue, CHARINDEX(':', @keyValue) + 1, CHARINDEX(':', @keyValue, CHARINDEX(':', @keyValue) + 1) - (CHARINDEX(':', @keyValue) + 1) ));
SELECT @hobbitID = convert(bigint, RTRIM(SUBSTRING(@keyValue, CHARINDEX(':', @keyValue, CHARINDEX(':', @keyValue) + 1) + 1, CHARINDEX('(', @keyValue) - CHARINDEX(':', @keyValue, CHARINDEX(':', @keyValue) + 1) - 1)));
SELECT @lockRes = RTRIM(SUBSTRING(@keyValue, CHARINDEX('(', @keyValue) + 0, CHARINDEX(')', @keyValue) - CHARINDEX('(', @keyValue) + 1));
--.............................................
--Validate DB name prior to running dynamic SQL
SELECT @databaseName = db_name(@dbid);
IF not exists(select * from sys.databases d where d.name = @databaseName)
BEGIN
RAISERROR(N'Database %s was not found.', 16, 1, @databaseName);
RETURN;
END
declare @objectName sysname, @indexName sysname, @schemaName sysname;
declare @ObjectLookupSQL as nvarchar(max) = '
SELECT @objectName = o.name, @indexName = i.name, @schemaName = OBJECT_SCHEMA_NAME(p.object_id, @dbid)
FROM ' + quotename(@databaseName) + '.sys.partitions p
JOIN ' + quotename(@databaseName) + '.sys.indexes i ON p.index_id = i.index_id AND p.[object_id] = i.[object_id]
JOIN ' + quotename(@databaseName)+ '.sys.objects o on o.object_id = i.object_id
WHERE hobt_id = @hobbitID'
;
--print @ObjectLookupSQL
--Get object and index names
exec sp_executesql @ObjectLookupSQL
,N'@dbid int, @hobbitID bigint, @objectName sysname OUTPUT, @indexName sysname OUTPUT, @schemaName sysname OUTPUT'
,@dbid = @dbid
,@hobbitID = @hobbitID
,@objectName = @objectName output
,@indexName = @indexName output
,@schemaName = @schemaName output
;
DECLARE @fullObjectName nvarchar(512) = quotename(@databaseName) + '.' + quotename(@schemaName) + '.' + quotename(@objectName);
SELECT fullObjectName = @fullObjectName, lockIndex = @indexName, lockRes_key = @lockres, hobt_id = @hobbitID, waitresource_keyValue = @keyValue;
--Validate object name prior to running dynamic SQL
IF OBJECT_iD( @fullObjectName) IS NULL
BEGIN
RAISERROR(N'The object "%s" was not found.',16,1,@fullObjectName);
RETURN;
END
--Get the row that was blocked
--NOTE: we use the NOLOCK hint to avoid locking the table when searching by %%lockres%%, which might generate table scans.
DECLARE @finalResult nvarchar(max) = N'SELECT lockResKey = %%lockres%% ,*
FROM ' + @fullObjectName
+ ISNULL(' WITH(NOLOCK INDEX(' + QUOTENAME(@indexName) + ')) ', '')
+ ' WHERE %%lockres%% = @lockres'
;
--print @finalresult
EXEC sp_executesql @finalResult, N'@lockres nvarchar(255)', @lockres = @lockres;
Александр, приветствую! Спасибо большое, за очередной интересный доклад. А что делать в большой, промышленной среде , хотя бы на 30+ инстансов(на разных хостах)? Дело в том, что эта утилита требует ручной настройки и судя по всему за ней нужно следить(с блокировками и профайлером шутки плохи). Есть ли какое-то решение/лучшие практики как построить автоматизированный мониторинг большого числа инстансов(с алертами)? Сам использую zabbix+TSQL, в принципе все работает. Но было бы очень интересное послушать Ваше мнение)
Виктор, приветствую! Хороший вопрос:) Ну... давайте начнем с того, что определимся хотим ли мы видеть платное или бесплатное решение:) Ну и предполагаю ответ, что хотелось бы конечно что-то, что не будет стоить, как "чугунный мост" . И вот тут наступает немая пауза, потому что все крутые мониторинги именно под SQL, подчеркну именно заточенные под SQL - они платные. Я говорю про те, которые могут и специализированно мониторить, т.е. понимают, чем latch от lock отличается и знают про клерк памяти, если нужно мониторить базовые показатели, жизнь сервиса, но не погружаться сильно глубоко, то мне тут нравится SCOM от Microsoft. Свою задачу он знает и решает, но "глубины" от него, к сожалению, ждать сильно не приходится, но алерты и т.д. там все это есть.
Теперь про бесплатное и вот решение zabbix+tsql мне кажется, что самое крутое, если кто-то может предложить тут в комментах еще что-то велком! Я буду только ЗА!
Есть еще вот такая штука sqlwatch.io/, она опенсорсная, построенная на tsql+powerbi, но алертить, кажется мне, не умеет. ну и лично у меня были некоторые проблемы с настройкой, но выглядит круто и знает про многие аспекты "жизни" SQL Server. Посмотрите, может быть понравится концепция :)
Спасибо за развернутый ответ! :)
По поводу платных решений:
Наверное, проще выбрать / сделать свое условно бесплатное решение. Заплатить ДБА который его напишет, внедрит, будет интерпретировать отчеты и оперативно реагировать на алерты. Нет толку от платного решения без ДБА, который может его разобрать и вылечить все issues (ИМХО).
Однако, может быть вы знаете какие-нибудь платные решения с “killer features”, что даже коллектив высококвалифицированных MS SQL инженеров быстро и качественно их не сделает в разумный срок(пара месяцев)? Над покупкой такого прорывного решения можно и задуматься..
Глянул sqlWatch - здорово! Как минимум 38 неплохих issues + готовый TSQL + примеры визуализации... еще и в свободном доступе, это очень круто.
Тут сразу вспоминается RAP от Microsoft :)) Вопрос: Есть ли где-то список issues которые потенциально может поймать RAP. Их изучение и анализ очень бы пригодилось при построении системы мониторинга многим специалистам по SQL Server?
@@viktorbekker1232 что-то из платного мне сложно советовать, потому что я его не использую. Однако, я сталкивался с правильными картинками из этого софта, по которым можно понять насколько детальная внутри информация. Вот тут нашлась линка на какой-то сайт: www.comparitech.com/net-admin/sql-server-monitoring-tools/ где в ТОП7 "сидят" как раз эти софтины. У них у всех есть триалки, поэтому можно поковырять, посмотреть. Однако, надо понимать, что все они "под капотом" используют одни и те же механизмы - DMV, xEvent, perfmon. Вот 3 основых источника информации у всех, поэтому сделать какую-то "вау фичу" не просто, так чтобы она не появилась у конкурентов через релиз (условно говоря), потому что источники информации ясны, более того запросы все трассируются на "раз два". Поэтому я думаю, что у всех примерно равные возможности будут. И еще момент, надо очень внимательно смотреть за тем, что они будут творить с вашим сервером, нагрузка от этих туловин может быть.
Еще посмотрите в сторону скриптов от Брен Озара - www.brentozar.com/first-aid/ Тут довольно много чего есть интересного.
RAP от Microsoft... там очень много проверок, этот софт с историей. Одних только вариантов issue там более 600-700 сотен, насколько я помню. Списком все эти "проблемы" я сомневаюсь, что можно найти где-то в открытом доступе, это было бы нарушением прав скорее всего.
Здравствуйте, извиняюсь если немнго не по теме, сталкивались ли вы с тем что события query_post_execution_showplan и query_post_execution_plan_profile не генерируют план для некоторых запросов?
Добрый день! Мне кажется, что я такое видел, но мне везло и нужные мне планы всегда ловились без проблем особых.
Вот интересная статья, где собран список причин, по которым могут быть проблемы при решении проблем с планами запросов.
www.dnsstuff.com/sql-server-query-plan-was-not-collected
А какой тип кода вы трассируете и не видите плана? Хранимка, динамический sql,... ?
А само событие он при этом генерирует? И в нем xml отсутствует или же он и события xevent-ов не выдаёт?
@@datainternalsru6025изначально проблема обнаружилась c parameterized query внутри хранимки. Но также повторяется и с ad hoc запросом полученным из него. Упрощал проблемный запрос, но не смог выявить прямой зависимости ни от числа джойнов, ни от набора результирующих полей, получателя данных, хэша текста запроса итд. При некоторых условиях даже изменение текста комментария могло повлиять на генерацию события. События query_post_execution_showplan и query_post_execution_plan_profile не генерируются, но например генерируется query_thread_profile. Из особенностей в запросе большое число результирующих полей (>100) и число джойнов (>20) но сам запрос простой, нет сложной логики.
@@datainternalsru6025 Спасибо большое за ссылку, похоже все таки по причине "optimize for ad hoc workloads"
@@Ренат-ц8ж, отключили и генерируется сейчас?
Вообще, странно, я всегда думал, что post_execution_showplan является фактом выполнения запроса и отображение реального плана. Любая параметризация simple/forced - это оптимизация компиляционных издержек и памяти, opt. for adhoc параметр не кеширует первое исполнение adhoc запроса, но как это может влиять на появление actual plan, не понимаю, если честно. Просто если взять adhoc и выполнить и включить отображение актуального плана - вы его получите, как он там кешироваться будет или нет, это вас уже не волнует, план вы получите. Думаю, как и событие xevent тоже, должны получить, процесс кеширования по-идее тут не должен влиять.
Вообще, интересно. А какая версия у вас sql server?