спасибо

вот вам еще и шаблон для унификации имен объектов при разработке базы данных, можете подправить под свои нужды https://github.com/ktaranov/sqlserver-kit/blob/master/SQL%20Server%20Name%20Convention%20and%20T-SQL%20Programming%20Style.md#sql-server-object-name-convention

Разыскиваются специалисты или компании - соисполнители. Писать в лс.

Да. Надо синхронизировать потоки. Ща попробую вашу штуку

кстати Брент Озар последнее время топит за отсутствие префиксов - по крайней мере для индексов т.к. префикс не несет никакой смысловой нагрузки - в плане запроса и так написано, что это индекс.
еще есть аргумент в пользу отсутствия префикса - возможность менять тип объекта без оглядки на семантику имени: таблица<->view<->tvf  могут выдавать идентичный резалтсет и нет особого смысла указывать тип объекта с помощью префикса

Не проще ли использовать service broker? Закинул туда таску в очередь и он сам все разгребет.

Когда DevOps Брент начнет более углубленно заниматься и хранить структуру в Гите с поддержкой миграции, тогда пусть советует) я с ним в переписке это обсуждал, но он до сих пор не понимает зачем менять табы на пробелы (или наоборот, но не смешивать) в first responder kit

Я не к тому что Брент дурное посоветует, просто в его кейсах  (он в основном учит и консалтит) это не важно, но в других случаях это спасает

Брента, фильтровать очень сильно... не принимать все на веру

Брент в последнее время как шоумен.
Посмотрел его пару выпусков последних и столько трепа, как он куда-то поехал, как его жена что-то там придумала, как они провели время с друзьями и т.д.
У меня сложилось впечатление, что я снова включил телевизор, хотя не смотрел его уже более 10 лет.

Но, пусть объем полезного времени трансляции значительно меньше, но его весело смотреть)))

Value падает от просмотра.

Коллеги, вопрос.
Смотрю выполняемые подключения к базе и вижу один зависший какой-то. duration_seconds ооочень большая величина
Как его правильно "отключить"?

Заппросы проверяю так:

SELECT
session_id , elapsed_time_seconds as duration_seconds, *
FROM sys .dm_tran_active_snapshot_database_transactions
ORDER BY duration_seconds DESC;

kill <session_id>

спс

проверьте еще  является ли это пользовательский процесс sys.dm_exec_sessions.is_user_process = 1
не стоит килять не пользовательские.

Он 100% пользовательский. Я определил его по приложению, работающему с базой, но он похоже сильно огромный. Из приложения я пользователя сбросил, а подключение в БД ещё висело мин 5, потом отскочило, не успел kill применить

вьюха sys.dm_db_index_usage_stats.
В столбце user_updates у класт.индекса PK__ORDERS__5CC1BC92 количество обновлений больше в 20 раз, чем суммарно строчек в таблице. Как это понимать - это общее число операций insert, update, delete по всей таблице (так как кластеризованный индекс покрывает всю таблицу), или это количество I,U,D конкретно суррогатного интового поля, по которому определён индекс?

Если у вас есть кластерный индекс то это и есть ваша таблица... И как связано количество обновлений кластерного индекса с количеством строчек в таблице? Я могу таблицу с одной строкой обновить миллион раз например