График с транзакциями за секунду заставил улыбнутся. Вот честно… почему тут призывают покупать SSD дорогие — иногда достаточно просто посмотреть в корень. Да простое обновление до 2014 версии существенно ускоряет работу с tempdb. Возникают задержки при работе с логом? Например, WRITELOG… укрупнить транзакции либо купи хороший APC и включи delayed durability. И так далее… ни на одном проекте у меня не было SSD и это не мешало делать высокопроизводительные решения.
С индексами… там не все так просто. Информация о том нужны они или нет строится на основании sys.dm_db_index_usage_stats. Если индексу делают REBUILD (это пофиксили в последних SP для 2014 + уже изначально в 2016 версии) или на базе включено AUTO_CLOSE, то значения сбрасываются в ноль и может казаться что индекс не используются. Поэтому аккуратнее тут нужно себя вести.
Например, можно заглянуть в кеш планов и оттуда узнать какие индексы используются:
SELECT *
FROM (
SELECT DISTINCT Sch = t.c.value('@Schema', 'SYSNAME')
, Obj = t.c.value('@Table', 'SYSNAME')
, Ind = t.c.value('@Index', 'SYSNAME')
FROM sys.dm_exec_query_stats q
CROSS APPLY sys.dm_exec_query_plan(q.plan_handle) p
CROSS APPLY p.query_plan.nodes('//*:Object') t(c)
WHERE t.c.exist('@Index') = 1
AND p.dbid = DB_ID()
) t
WHERE t.Sch != '[sys]'
Про этот тул уже давно знаю :) dbForge Studio весьма хороша, но строго в своей епархии. Тут имею ввиду, дата и схема компараторы и SQL Complete которым регулярно пользуюсь. Остальное дело вкуса. Если брать рутинные задачи мне тоже SSMS вполне хватает. Надеюсь в новой версии скоро темную тему прикрутят.
Что сказать… полностью поддерживаю Вашу точку зрения. На текущем проекте использовался Entity Framework, который в отдельных случаях такую ересь пытался выполнить на сервере. Неявное преобразование типов, Index Scan вместо Index Seek при выборе единичного значения, и прочие радости жизни… Вычистили все проблемные места, но осадок от использования подхода Code First остался при использовании на больших объемах данных.
Про MySQL не планировал, потому что мало с ним работал. Однако, в планах сделать еще большой пост про типичные ошибки при написании запросов на T-SQL.
Спасибо и Вам что прочитали. Можно вопрос… а в чем нашли проблемы? Не во всех ситуациях запросы будут возвращать 100% адекватную информацию. Например, MissingIndexGroup секция строится на основе предположений оптимизатора и не всегда предлагает самый оптимальный индекс. Очень рекомендую взглянуть на DEFAULT TRACE.
Рад, что Вам понравилось. Если народу будет интересно, потом планировал написать пост как можно с помощью запросов к системным представлениям определять узкие места в конфигурации сервера и автоматизировать проверку с помощью tSQLt.
Серверная в другом офисе просто открывалась на целый день для всех. И нет, там не было камер ни в коридоре, ни в самой серверной.
А у меня на первой работе серверная располагась игровой. Пошел в теннис поиграть и заодно проверил как там серверки живут. Помогал когда-то восстанавливать базы SQL Server на одном заводе так так еще веселее… Серверная в подвале где вечный конденсат капал на сервера и ничего… секреты производства на дисках еще живы :)
Что сказать… обычно старые посты комментировать редко стоит, но знакомая девушка-маркетолог пообещала пойти на свидание, если я тут оставлю ссылку на SQL Complete. А если по делу, то в целом поддерживаю Вашу точку зрения. Code Completion мне тоже по душе. Чего действительно не хватает, так это просмотра DDL объектов в попапе, но это скоро уже должны добавить.
Добавьте, пожалуйста, еще SQL Complete. ИМХО, неплохой плагин в SSMS для написания запросов T-SQL. Есть бесплатная версия с урезанными подсказками либо можно попросить лицензию в обмен на фитбек о продукте.
Если мы пользуемся Stretch таблицей, то можно забыть про эффективный поиск. С одной стороны это из-за бага про который я написал. С другой стороны печален и другой нюанс: filters on SQL Server indexes are not propagated to the remote table. Надеюсь, что с SP1 эти проблемы и ограничения уйдут в прошлое.
Про то какая программа использовалась ответил ниже.
Пробовал такой вариант. Переключение секций происходит мгновенно и перенос данных в Azure тоже достаточно быстро работает (когда тестировал, данные переносились со скоростью примерно 1-4 Мб в секунду). Однако в моих условиях нужно было потом часто обращаться к данным в Stretch таблице, а это сильно снижало производительность системы. Увы… но не прижилось.
Такой вариант уже рассматривали. К слову он лучше на порядок, но сейчас все на Express работает и этого вполне хватает. В планах миграция, когда пользователей TMetric больше станет.
Спасибо за статью. Когда читал чуть слезу не пустил, потому что сражался примерно с такими же проблемами :)
Вариант с sys.sp_executesql действительно очень хороший. НО! Он не всегда будет работать. Если в настройках линкед-сервера отключен RPC, то запрос будет падать по ошибке:
DECLARE @SP_CMD NVARCHAR(50) = N'[linked_server].[AdventureWorks2012].sys.sp_executesql'
DECLARE @SQL_CMD NVARCHAR(4000) = N'SELECT name FROM sys.databases'
EXEC @SP_CMD @SQL_CMD
Server '...' is not configured for RPC.
В большинстве случаев, это можно игнорировать, но в моем случае мы разрабатывали плагин для SSMS, который должен был подсказывать объекты линкед-сервера и работать при этом на любой конфигурации. Настройки менять не разрешалось. В результате множества тестов вот такой вариант оставили:
SELECT name
FROM [linked_server].[AdventureWorks2012].sys.databases
Относительно того куда обратиться. Есть хороший форум sql.ru. Но опять же хрустального шара у людей нет. Нужно репро хоть какое-то, чтобы понять в чем может быть проблема. Не помешает узнать и какими запросами Вы грузите сервер. Планы выполнения и прочее, что может помочь разобраться.
Например, можно заглянуть в кеш планов и оттуда узнать какие индексы используются:
Относительно Днепра… да, буду. Два доклада планирую на SQL Saturday Dnepr. Приезжайте 26 ноября — мероприятие обещает быть очень интересным.
Про MySQL не планировал, потому что мало с ним работал. Однако, в планах сделать еще большой пост про типичные ошибки при написании запросов на T-SQL.
А у меня на первой работе серверная располагась игровой. Пошел в теннис поиграть и заодно проверил как там серверки живут. Помогал когда-то восстанавливать базы SQL Server на одном заводе так так еще веселее… Серверная в подвале где вечный конденсат капал на сервера и ничего… секреты производства на дисках еще живы :)
Про то какая программа использовалась ответил ниже.
Azure SQL Database поддерживает возможность включения Delayed Durability (хотя SSMS в свойствах базы соответствующей опции не показывает)
Сложно ответить на Ваш вопрос не зная специфики проекта и то как разворачивается тестовое окружение. Если уточните вопрос, то буду рад помочь.
Вариант с sys.sp_executesql действительно очень хороший. НО! Он не всегда будет работать. Если в настройках линкед-сервера отключен RPC, то запрос будет падать по ошибке:
В большинстве случаев, это можно игнорировать, но в моем случае мы разрабатывали плагин для SSMS, который должен был подсказывать объекты линкед-сервера и работать при этом на любой конфигурации. Настройки менять не разрешалось. В результате множества тестов вот такой вариант оставили:
Вы имеете ввиду миграции в рамках EF? Или какие-то другие?