Автор: Paul Randal, Trimming the Transaction Log Fat
Для многих рабочих нагрузках SQL Server, особенно OLTP, журнал транзакций базы данных может быть узким местом, увеличивающим время завершения транзакции. Большинство людей предполагают, что реальным узким местом является подсистема ввода-вывода, которая не справляется с объёмом журнала транзакций, генерируемого рабочей нагрузкой.
Автор: 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, чтобы вы могли автоматизировать этот процесс. Поехали.
