Н
в чем была проблема?
Там файлами бэкапа была не разбериха. Помог вот это, за что автору респект:https://habr.com/ru/post/154907/
Size: a a a
2019 June 28
2019 July 01
ל
сколько можно "OR" условий использовать максимально ?
A
На кол-во предекатов ограничения нет. Остаётся только учесть Макс кол-во символов в запросе
ל
Alexander
На кол-во предекатов ограничения нет. Остаётся только учесть Макс кол-во символов в запросе
спасибо
2019 July 02
НК
эй, BrentOzarULTD/SQL-Server-First-Responder-Kit oна имеет новый релиз: 20190702
Вы можете прочитать описание версии здесь:
https://github.com/BrentOzarULTD/SQL-Server-First-Responder-Kit/releases/tag/20190702
Вы можете прочитать описание версии здесь:
https://github.com/BrentOzarULTD/SQL-Server-First-Responder-Kit/releases/tag/20190702
2019 July 22
SS
Коллеги! Подскажите что то на русском по планам запросов.
SS
SS
И вообще по проблемам перформанса
SS
Как их мониторить и тп
2019 July 23
KO
Как их мониторить и тп
путями винды или самого MSSQL?
2019 July 24
A
Как их мониторить и тп
Кого мониторить, планы запросов? Учитесь, пожалуйста, задавать вопросы, будете получать хорошие ответы.
Вопрос анализа производительности sql server - это одна стезя.
В ходе анализа производительности, выяснив, что дисковая подсистема работает штатно, памяти хватает, ожиданий по метрикам, связанным с оборудованием, не наблюдается - тогда начинают отлавливать самые тяжёлые запросы. Это вторая стезя.
Получив тяжёлый запрос, мы доходим до вашего первого вопроса - план запроса.
И при этом многое зависит от проектируемой базы данных, какие индексы на таблицах, актуальна ли статистика и т.д.
К сожалению, не существует подробной документации обо всех этих вопросах сразу, тем более на русском.
Один из вариантов анализа - сбор счётчиков производительности performance_counters + параллельная сборка запросов через Extended Events или Profiler.
Затем это нужно исследовать на момент узких мест.
При этом, если собирать счётчики производительности через windows тулзу perfmon, которая складывает результат в *.blg, его можно использовать для сопряжения с трассой, собранной через Profiler. В результате по оси времени будут разложены все запросы, собранные трассой + какие были показания счётчиков в этот момент времени.
Вопрос анализа производительности sql server - это одна стезя.
В ходе анализа производительности, выяснив, что дисковая подсистема работает штатно, памяти хватает, ожиданий по метрикам, связанным с оборудованием, не наблюдается - тогда начинают отлавливать самые тяжёлые запросы. Это вторая стезя.
Получив тяжёлый запрос, мы доходим до вашего первого вопроса - план запроса.
И при этом многое зависит от проектируемой базы данных, какие индексы на таблицах, актуальна ли статистика и т.д.
К сожалению, не существует подробной документации обо всех этих вопросах сразу, тем более на русском.
Один из вариантов анализа - сбор счётчиков производительности performance_counters + параллельная сборка запросов через Extended Events или Profiler.
Затем это нужно исследовать на момент узких мест.
При этом, если собирать счётчики производительности через windows тулзу perfmon, которая складывает результат в *.blg, его можно использовать для сопряжения с трассой, собранной через Profiler. В результате по оси времени будут разложены все запросы, собранные трассой + какие были показания счётчиков в этот момент времени.
SS
Давайте начнём с описания плана запроса.
2019 July 25
G⚔
2019 July 28
2019 July 29
НК
Надо
там по ссылке смотри
НК
2019 August 12
A
господа, а linux версию mssql при менее 2 гигов в системе - никак не вынудить стартовать?