Автор: Sarjen Haque, Performance issues from ORDER BY/GROUP BY - spills in tempdb
Совершенно обычно и ожидаемо видеть запрос, содержащий предложение ORDER BY или GROUP BY для целей отображения или группировки. Также часто разработчики используют предложение ORDER BY по привычке, не задумываясь о его необходимости. В результате запросы со временем замедляются по мере увеличения количества записей.
Автор: Sarjen Haque, Using Managed Service Account with SQL Server Service
MSA — это управляемая учётная запись Active Directory, которая автоматически управляется Active Directory (AD). MSA (domain\account$) назначается Windows Server, а управление паролями обрабатывается Windows (не нужно их самим менять и обслуживать).
Автор: Paul Randal, Transaction Log Configuration Issues
В моих предыдущих статьях я обсуждал способы уменьшения объёма генерируемого журнала транзакций и как обеспечить его правильную очистку. В этой статье я хочу продолжить тему производительности журнала транзакций и обсудить некоторые проблемы его конфигурации, которые могут вызывать трудности.
Примечание переводчика: начиная с SQL Server 2022 описываемое в этой статье поведение журнала транзакций претерпело значительное изменение.
Автор: Remus Rusanu, Understanding Hash, Sort and Exchange Spill events
Некоторые операции при выполнении запросов SQL Server рассчитаны на наилучшую производительность при использовании (относительно) большого объёма памяти в качестве промежуточного хранилища. Оптимизатор запросов выбирает план и оценивает стоимость, основываясь на том, что эти операторы используют эту «черновую» память. Но это, конечно, лишь оценка. Во время выполнения оценки могут оказаться неверными, и план должен продолжить работу, несмотря на нехватку памяти. В таком случае эти операторы выполняют сброс на диск (spill). Когда происходит сброс, «черновая» память сбрасывается в tempdb, и новые данные размещаются в (теперь) свободной памяти. Когда данные, сброшенные в tempdb, снова нужны, они читаются с диска. Само собой разумеется, сброс в tempdb на порядок медленнее, чем использование только «черновой» памяти. Мониторинг сбросов особенно важен в ETL-задачах, поскольку эти случаи могут растянуть выполнение ETL на многие минуты, а иногда даже часы. Для исчерпывающего обсуждения ETL, включая некоторые ссылки на сбросы, см. Руководство по производительности загрузки данных.
Автор: mssql-support, How It Works: Soft NUMA, I/O Completion Thread, Lazy Writer Workers and Memory Nodes
Похоже, существует некоторая семантическая путаница в описании SOFT NUMA в документации Books Online. Область путаницы — это раздел SQL Server 2008 Books Online, показанный ниже.
Автор: Sarjen Haque, NUMA and soft-NUMA in SQL Server: To get additional I/O threads
Производительность может быть значительно улучшена, если ядро SQL Server обнаруживает физические узлы NUMA в системе Windows. Наряду с аппаратным NUMA, Microsoft также представила архитектуру soft-NUMA (программный NUMA) для создания дополнительных виртуальных узлов NUMA внутри SQL OS. Начиная с SQL Server 2016 (13.x), если ядро базы данных обнаруживает более восьми «физических ядер на узел NUMA» или более восьми «сокетов», узлы soft-NUMA создаются автоматически. Создание узлов soft-NUMA позволяет ядру базы данных SQL Server создавать больше потоков ввода-вывода для повышения производительности требовательных транзакционных рабочих нагрузок SQL Server.
Автор: Paul Randal, Are I/O latencies killing your performance?
В этой статье я объясняю некоторые методы исследования и снижения задержек ввода-вывода для tempdb и журнала транзакций, которые могут серьёзно препятствовать производительности вашей рабочей нагрузки.
Я запускал опрос, попросив выполнить код для расчёта средних задержек ввода-вывода и отправить мне результаты и получил результаты с 1094 случайных серверов по всему миру, на которых размещено 25445 баз данных, и мне потребовалось некоторое время, чтобы загрузить все результаты в SQL Server для агрегации данных. Вот они.
Автор: Paul Randal, Understanding data vs log usage for spills in tempdb
В списке рассылки SQL MCM (в котором участвуют все действующие инструкторы MCM) было обсуждение, где пытались понять огромное несоответствие между использованием файлов данных tempdb и файлов журнала. Я объяснил ответ и решил поделиться им со всеми вами.
ConnectionStrings.com предоставляет удобный справочник по строкам подключения. База знаний, состоящая из статей и практических руководств по темам, связанным с источниками данных и программными соединениями, а также набор форумов с вопросами и ответами, где разработчики помогают друг другу находить решения, связанные с подключением, для своих систем.
Я восстанавливал свою трёхсайтовую демонстрационную лабораторию SQL Server и столкнулся с тем, чего давно хотел. Если вы когда-либо проектировали среду SQL Server на ActiveCluster, вам знаком этот сценарий: два FlashArray, работающие с синхронно реплицируемым модулем (pod) для нулевой точки восстановления (RPO) между сайтами, и третья система хранения где-то ещё для более длительного хранения и копии для аварийного восстановления. Проблема была в том, что вы не могли получить данные на эту третью систему хранения напрямую из пода Группы защиты внутри растянутого пода просто не могли иметь целью систему хранения.
Это изменилось, и это возможно уже дольше, чем многие из нас осознают. Вы можете создать группу защиты внутри модуля ActiveCluster, добавить третий FlashArray в качестве цели и асинхронно реплицировать на него снимки по расписанию. Ваши синхронно реплицируемые данные получают третью копию, и вам не нужно создавать параллельный набор томов вне пода, а затем клонировать их в эти тома, чтобы добиться этого.
В этой статье я покажу, как настроить это «от начала до конца» с помощью Pure Storage PowerShell SDK2, чтобы вы могли автоматизировать этот процесс. Поехали.
В чём разница между сжатием строк (row compression) и сжатием страниц (page compression) в SQL Server, и когда имеет смысл применять каждое из них?
Чтобы увидеть это более подробно, давайте запустим одну из моих Database Animations.
