Відео

@@1boxingclub378 про рост, да, наверное стоило. Вообще, autogrowth сам по себе процесс не очень удачный и может оказать негативное влияние. Тут не так давно нарвались на интересное ожидание, связанное с ростом лога и я могу сказать, что не зря процесс autogrowth считается нежелательных для высокопроизводительных БД.

@@datainternalsru6025 А вы можете дать рекомендации относительно параметров роста? Например у меня сервер с 1 физическим процессором 3 логических. У нас сейчас спор идет с коллегами относительно настройки файлов tempdb. Я топлю что надо оставить 8 файликов которые были до меня но изменить параметры роста. А коллеги говорят что надо ставить к-во файлов равное количеству процессоров. Что вы можете сказать по своему опыту? Система сама по себе имеет среднюю нагрузку

Спасибо за отзыв. Много мыслей и разных наработок за это время, и очень мало времени, к сожалению. Канал был всегда для души, поэтому надо "поймать волну" :)

@@datainternalsru6025 накидал ещё в копилку) что интересного от вас хотелось бы послушать: партициорование, колоночные индексы, анализ и диагностика always on, всякие фишки и плюшки по ней как раз, очень интересного было бы послушать про новинки в 2019 и 2022 сервере, про диагностику интересного было бы посмотреть. Правда канал для души, смотрится очень интересно не скучно.

Добрый день! Спасибо за просмотр. Насколько я помню этот кейс, задача была от заказчика переехать на повышенную версию sql server, с минимальным временем простоя. Ну, а в процессе разбирательства делал стенд, а потом решил сделать и вижео инструкцию, мало ли кому-то пригодится. Что касается миграции, то там немного вариантов, если надо переехать за пару минут. Один из путей - это сделать через зеркало, или alwayson, которое по своей сути зеркало тоже :)

Антон, приветствую! Сорри, забегался, упустил комментарий. Я не знаю какого-то магического скрипта, который бы преподнес эту информацию "на блюдичке", поэтому смотрю через DBCC OPENTRAN :(( learn.microsoft.com/ru-ru/sql/t-sql/database-console-commands/dbcc-opentran-transact-sql?view=sql-server-ver16

Антон, приветствую! а вот такой нашелся скрипт... попробуйте, нашел в закромах только что:) SELECT tst.[session_id] , s.[login_name] AS [Login Name] , DB_NAME (tdt.database_id) AS [Database] , tdt.[database_transaction_begin_time] AS [Begin Time] , tdt.[database_transaction_log_record_count] AS [Log Records] , tdt.[database_transaction_log_bytes_used] AS [Log Bytes Used] , tdt.[database_transaction_log_bytes_reserved] AS [Log Bytes Rsvd] , SUBSTRING(st.text, (r.statement_start_offset/2)+1, ((CASE r.statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE r.statement_end_offset END - r.statement_start_offset)/2) + 1) AS statement_text , st.[text] AS [Last T-SQL Text] , qp.[query_plan] AS [Last Plan] FROM sys.dm_tran_database_transactions tdt JOIN sys.dm_tran_session_transactions tst ON tst.[transaction_id] = tdt.[transaction_id] JOIN sys.[dm_exec_sessions] s ON s.[session_id] = tst.[session_id] JOIN sys.dm_exec_connections c ON c.[session_id] = tst.[session_id] LEFT OUTER JOIN sys.dm_exec_requests r ON r.[session_id] = tst.[session_id] CROSS APPLY sys.dm_exec_sql_text (c.[most_recent_sql_handle]) AS st OUTER APPLY sys.dm_exec_query_plan (r.[plan_handle]) AS qp WHERE DB_NAME (tdt.database_id) = 'tempdb' ORDER BY [Log Bytes Used] DESC GO

Добрый день! Да, операции модификации данных не должны испытывать проблем с REDO из-за бэкапа. Суть проблемы в том, что данные попадают в лог файл на вторичном узле, но REDO поток, "накатывающий" эти данные на database file заблокирован. В результате данные как бы есть (в транзакциооном лог файле) и одновременно ещё как бы и нет (в файле баз данных) :) На самом деле, заблокировать REDO можно не только бэкапом+шринк, есть ещё различные ситуации, когда REDO блокируется. Занятно, что вы спросили, я как раз сейчас разбираюсь в одной интересной ситуации, когда AG группа перекатилась, позеленела, а вот БД внутри неё не смогли почему-то разобраться кто из них primary, а кто secondary... :)))

@@datainternalsru6025 Доброго дня! Про то, что данные в логе, а редо-поток заблокирован я понял. Но я считал, что раз делается бэкап, то данные меняться не должны, а потому простой инсерт тоже не должен был дойти до БД, а остаться в логе до завершения бэкапа. Иначе может получиться, что данные у нас актуальные, а бэкап нет. Но тогда и селекты должны блокироваться, либо отрабатывать и после модифицироваться данными из лога, раз идет процесс бэкапа. Успехов вашим БД разобраться, кто из них главный =)

пожалуйста! Тема памяти, кажется, бесконечна и не переставает быть актуальной. Уже sql2022 вышел, а настройки памяти все еще переодически являются проблемами для серверов, хотя казалось бы, их же там 3-4 штуки, где же можно запутаться? Ан-нет, легко:)

всегда рад помочь!

*голосом кота матроскина а я и на гита-а-аре тоже немного умею :)

Евгений, приветсвую! Простите за долгий ответ, начал отвечать и отвлекли и.... :( Смотрите, там очень интересная история, я тоже не могу понять, почему он лезет в tempDB, начал смореть объем выделяемой Grant memory и моему удивлению не было предела... что-то в районе пары десятков мегабайт(!), больше не выделено было, сколько я не пытался его как-то ... заставить более менее адекватно выдавать память, у меня ничего не вышло. Т.е. получается изначально выделяется мало памяти, ее автоматом не хватает и он почти сразу начинает сливаться в БД tempDB. Мне остается только догадываться, почему он так себя ведет...

Валерий, спасибо! К сожалению, репликация не самый мой сильный "конек", мало я с ней работал, извините.

Добрый день! Мне кажется, что я такое видел, но мне везло и нужные мне планы всегда ловились без проблем особых. Вот интересная статья, где собран список причин, по которым могут быть проблемы при решении проблем с планами запросов. 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?

Пожалуйста! Я рад, что материал был вам полезен!

Александр, приветствую! Спасибо за ваш комментарий! Полностью согласен с вами, что в различных условия системы могут себя вести абсолютно не как оно "должно быть в теории". Любая система от 1Тб и более требует индивидуального подхода к обслуживанию и запуск обслуживания "в лоб" приведет к тому, что обслуживание просто выключат из-за проблем с ним :) Про ребилд на AlwaysOn - это вообще можно долго истории рассказывать, не зря ребилд иногда замедляют MAXDOP-ом 1, чтобы не создавал очередей на первичке или проблем для REDO на вторичке.

Константин, приветсвую! Да, это можно , например, '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;

@MrEdo999, добрый день! Попробуйте вот такой скрипт SELECT tst.[session_id] , s.[login_name] AS [Login Name] , DB_NAME (tdt.database_id) AS [Database] , tdt.[database_transaction_begin_time] AS [Begin Time] , tdt.[database_transaction_log_record_count] AS [Log Records] , tdt.[database_transaction_log_bytes_used] AS [Log Bytes Used] , tdt.[database_transaction_log_bytes_reserved] AS [Log Bytes Rsvd] , SUBSTRING(st.text, (r.statement_start_offset/2)+1, ((CASE r.statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE r.statement_end_offset END - r.statement_start_offset)/2) + 1) AS statement_text , st.[text] AS [Last T-SQL Text] , qp.[query_plan] AS [Last Plan] FROM sys.dm_tran_database_transactions tdt JOIN sys.dm_tran_session_transactions tst ON tst.[transaction_id] = tdt.[transaction_id] JOIN sys.[dm_exec_sessions] s ON s.[session_id] = tst.[session_id] JOIN sys.dm_exec_connections c ON c.[session_id] = tst.[session_id] LEFT OUTER JOIN sys.dm_exec_requests r ON r.[session_id] = tst.[session_id] CROSS APPLY sys.dm_exec_sql_text (c.[most_recent_sql_handle]) AS st OUTER APPLY sys.dm_exec_query_plan (r.[plan_handle]) AS qp WHERE DB_NAME (tdt.database_id) = 'tempdb' ORDER BY [Log Bytes Used] DESC GO

Виктор, приветствую! Хороший вопрос:) Ну... давайте начнем с того, что определимся хотим ли мы видеть платное или бесплатное решение:) Ну и предполагаю ответ, что хотелось бы конечно что-то, что не будет стоить, как "чугунный мост" . И вот тут наступает немая пауза, потому что все крутые мониторинги именно под 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 сотен, насколько я помню. Списком все эти "проблемы" я сомневаюсь, что можно найти где-то в открытом доступе, это было бы нарушением прав скорее всего.

Приветствую, Антон! И я рад Вас видеть! :))) Ну что ж... надо будет собрать мысли "в кучку"... и попробовать как-то рассказать, что внутри файлов смотреть и как анализировать. И желательно не на сто часов видео)))

Рад, что материал вам был интересен!

@@datainternalsru6025 Жаль видео мало. Сейчас контента в ру сегменте по mssql вообще мало толкового.

@@KittenYour, а какие темы по sql были бы интересны?

Он тоже кластеризируется :) есть разные способы

Добрый день! И да и нет, это утилита, внутри неё сидят скрипты уже. Честно сказать, какой именно скрипт использовался, уже сложно вспомнить.

Добрый день! Стенд собирался на рабочем ноуте, lenovo p50, на нем все обкатывалось, тестировалось и эти видео делал. У заказчика, где выполнялись реальные работы, там сервер конечно. И не один:)

Антон, приветствую! Для начала проверьте, что у вас файлы одного размера (текущий размер имеет значение) и размер автоприроста у всех файлов стоит одинаковый. Еще хорошая практика флаги - T1117, T1118. до 2016 они актуальны, потом уже не очень ( blog.sqlauthority.com/2020/02/27/sql-server-tempdb-and-trace-flag-1117-and-1118-not-required/ www.mssqltips.com/sqlservertip/4364/sql-server-2016-trace-flags-1118-and-1117-for-page-allocations/) После этого можно наверно подумать про увеличение количества файлов, но 48 и так довольно много, у меня как-то сомнения, что доп. файлы помогут такой проблеме. Я не могу припомнить, чтобы кто-то из моих заказчиков имел такой конфиг, чтобы файлов было больше, чем физических ядер на сервере. Сложно предположить, какой может быть от этого эффект. А что у вас за нагрузка такая на tempdb? Много временных объектов или механизм версионности работает?

i dont mean to be so offtopic but does anybody know of a method to log back into an instagram account..? I stupidly lost the account password. I would appreciate any help you can offer me!

@Dominick Max instablaster =)

@Colten Ben thanks for your reply. I found the site on google and Im in the hacking process now. Takes a while so I will get back to you later when my account password hopefully is recovered.

@Colten Ben it worked and I finally got access to my account again. I'm so happy:D Thanks so much you saved my ass !

@Dominick Max You are welcome =)

Денис, приветсвую! Сорри, вовремя не увидел комментарий. Я не смог добиться изменения memory grant для такой статистики. Мне это тоже оч. не понравилось и я в бэкграунде игрался, но результата особо не было. Параллельный план должен больше брать, конечно, но ошибка уж очень большая была и, как мне кажется, не компенсируется.

Евгений, пожалуйста! Рад, что было интересно. Про перенос статистики сам случайно узнал, что так можно. На практике пока не удалось еще применить, но штука оч. интересная.

Рад, что понравилось. Есть еще одно видео на данную тему - ua-cam.com/video/TdhhT5TqqAw/v-deo.html Или Вам было бы интересно про обслуживание баз данных видео?

спасибо! Я рад, что было полезно! я сам большинство видео смотрю на полуторной или двойной скорости. когда видео пишешь, думать и говорить с двойной скоростью не получается пока что:)))

прикольно:) вроде ничего, сижу вот спокойно пью кофе, а тут такое...))) проверил у своего провайдера и с телефона билайн, вроде все ок. Там https не используется, может быть поэтому браузер/провайдер решили, что не безопасно на такие сайты ходить.

@@datainternalsru6025 Похоже какой-то странный прикол у РТК. Оплатил за апрель - пустило xD

спасибо

Всегда рад! Да, я как-то раньше не принимал во внимание этот "эффект", проблема всплыла на сервере с огранниченной по размеру tempDB. Начали разбираться и вот... решил поделиться

​Добрый день, спасибо что делитесь такой интересной информацией. Жду новое видео! А какие были изначально симптомы у проблемы? Ошибки, инф.сообщения? В своей практике не ограничиваю системные БД. Пару слов можете сказать где это приемлемо использовать? Ясно что все зависит в целом от ситуации.., но все же? И бывают порой моменты, что tempdb(файлы БД, не лог) не хочет шринковаться ни в какую, можно ли выяснить какие странички кем заняты, чтобы не прибегать к перезапуску сиквела?