Советы и хитрости для высокой производительности FILESTREAM

Автор: Paul Randal, High-performance FILESTREAM tips and tricks

У меня было много вопросов о производительности FILESTREAM и о том, как заставить NTFS хорошо масштабироваться. Я только что закончил писать 30-страничный технический документ о FILESTREAM для команды SQL Server, который должен быть опубликован до конференции PASS 2008 в ноябре. Хотя мой технический документ не совсем о производительности, в нём есть длинный раздел о настройке системы для достижения высокой производительности FILESTREAM. В этой статье я хочу дать список рекомендаций, которые помогут вам добиться хорошей производительности. Все они более подробно описаны в техническом документе.

Могут ли ключи кластерного индекса с типом GUID вызывать фрагментацию некластерных индексов?

Автор: Paul Randal, Can GUID cluster keys cause non-clustered index fragmentation?

На встрече пользовательской группы я потратил некоторое время на объяснение того, как GUID могут вызывать фрагментацию как в кластерных, так и в некластерных индексах, даже если GUID специально не включён в ключ некластерного индекса. GUID — это, по сути, случайные значения (псевдослучайные в диапазонах, если генерируются с помощью NEWSEQUENTIALID), которые также уникальны. Их уникальность делает их привлекательными для многих разработчиков в качестве значения ключа, не понимая при этом того хаоса, который они могут вызвать в производственной среде с точки зрения фрагментации и низкой производительности запросов.

Насколько сложно выбрать правильные некластерные индексы?

Автор: Paul Randal, How hard is it to pick the right non-clustered indexes?

На собрании группы разработчиков .NET в Редмонде, и во время того, как Кимберли рассказывала о пропущенных и лишних индексах, возник следующий вопрос:

«Какой некластерный индекс лучше всего использовать для запроса с условием WHERE lastname = 'Randal' AND firstname = 'Paul' AND middleinitial = 'S'?»

Кимберли сказала, что для этого случая порядок ключей не имеет значения. Я подумал секунду, а затем возразил, сказав, что наиболее селективный столбец должен быть первым. Мы согласились обсудить это с группой в конце, но я подумал ещё немного и понял (и признался группе), что она права – мне следовало бы знать, что не стоит подвергать сомнению знания Кимберли об индексировании… :-)

Разочарование от обобщений

Автор: Paul Randal, The frustration of sweeping generalizations – follow on from Search Engine Q&A #12

Постоянное участие в дискуссиях побудило меня высказать свои мысли о многочисленных обобщениях, которые преследуют индустрию и иногда затрудняют дачу советов на форумах и в блогах. 

Некоторые примеры вопросов, которые порождают обобщения:

• Следует ли создавать кластерные индексы для всех таблиц? (Известный спор о кластерных индексах, как его любит называть Кимберли.)
• Следует ли перестраивать или реорганизовать индексы для устранения фрагментации?
• Какое решение высокой доступности следует использовать?

Проблема — как и с большинством советов — в том, что крайне сложно делать обобщения. Это связано как с тем, что без большого количества доказательств многие люди (вполне обоснованно) не верят обобщениям, поскольку они могли обжечься на одном из них в прошлом, так и с тем, что почти каждая ситуация уникальна, поэтому многие обобщения бесполезны.

Журнал транзакций SQL Server. Часть 4: записи журнала

Автор: Paul Randal, The SQL Server Transaction Log, Part 4: Log Records

Ранее я рассказывал о том, зачем нужно ведение журнала, об архитектуре и циклической природе журнала, и теперь пришло время взглянуть на самое сердце системы ведения журнала — на сами записи журнала. Как всегда, рекомендую прочитать предыдущие статьи в этой серии, прежде чем читать эту.

Следует ли создавать несколько файлов для пользовательской базы данных на многопроцессорном сервере?

Автор: Paul Randal, Search Engine Q&A #12: Should you create multiple files for a user DB on a multi-core box?

На сайте SQLServerCentral.com развернулась очень интересная дискуссия о том, стоит ли создавать несколько файлов для пользовательской базы данных, потому что на сервере несколько ЦП. Я написал пару длинных ответов в ходе дискуссии и хотел продублировать их здесь, так как считаю, что это представляет широкий интерес.

Горячее добавление ЦП и маска привязки

Автор: Paul Randal, SQL Server 2008: Hot-Add CPU (and affinity masks)

Короткая заметка сегодня, так как я готовлюсь к выступлению на собрании пользовательской группы SQL Server в Тихоокеанском Северо-Западе сегодня вечером в кампусе Microsoft в Редмонде.

SQL Server 2005 представил концепцию горячего добавления памяти (hot-add memory) для динамической обработки рабочей нагрузки. SQL Server 2008 расширяет эти возможности, добавляя также горячее добавление ЦП (hot-add CPU). Начиная с SQL Server 2025 (17.x), функция горячего добавления ЦП не рекомендуется и планируется удалить в будущей версии SQL Server. «Горячее добавление» означает возможность установить ЦП в работающую машину и затем перенастроить SQL Server для использования этого ЦП ONLINE (т.е. без какого-либо простоя приложения).

Как влияет сжатие резервных копий на загрузку процессоров

Автор: Paul Randal, SQL Server 2008: Backup Compression CPU Cost

Я давно обещал написать о встроенном сжатии резервных копий (Backup Compression). Для этой статьи я расширил базу данных AdventureWorks до 322 МБ (случайный размер, но достаточно большой, чтобы получить приемлемое время выполнения на моём сервере). Я использовал системный монитор (System Monitor) для измерения времени ЦП в пользовательском режиме (%user-mode CPU time), а также пропускной способности резервного копирования и восстановления для сжатой и несжатой операций резервного копирования, а затем и восстановления.

Cколько времени займёт выполнение CHECKDB?

Автор: Paul Randal, CHECKDB From Every Angle: How long will CHECKDB take to run?

Это тема, о которой я уже писал в своём старом блоге, но на конференции SQL Connections она всплывала несколько раз, поэтому я хочу переопубликовать её для тех, кто только начал следить за моим блогом.

Структуры хранения #4 – Memory-optimized columnstore

Автор: Hugo Kornelis, Storage structures 4 – Memory-optimized columnstore;

Настало время для следующей части моей серии о структурах хранения. Предыдущие части охватывали дисковое хранение строк, колоночные индексы и оптимизированное для памяти хранение. В этой части я рассмотрю комбинацию двух последних: оптимизированные для памяти колоночные индексы.

Оптимизированные для памяти колоночные индексы были представлены в SQL Server 2016. За это время я видел несколько эффектных маркетинговых презентаций Microsoft, в которых много говорилось о «аналитике в реальном времени» (real-time operational analytics). Новая тенденция, согласно которой аналитическая обработка больше не должна выполняться на устаревшей копии данных в отдельном хранилище, а непосредственно в OLTP-базе данных. Отчёты всегда были бы полностью актуальными, необходимость в ETL-конвейере отпала бы, а благодаря сочетанию оптимизированных для памяти структур для OLTP-нагрузок и колоночных индексов для аналитической обработки всё всегда было бы быстро. В теории.

Я больше не слышал термин «аналитика в реальном времени» после первоначального выпуска SQL Server 2016. А начиная с внедрения SQL Server 2017, я не припомню, чтобы слышал от кого-либо из сотрудников Microsoft использование терминов «оптимизированный для памяти» и «колоночный» в одном докладе, не говоря уже об одном предложении.

Я действительно не знаю, есть ли в мире клиенты, которые действительно используют оптимизированные для памяти колоночные индексы в своих производственных системах, и я серьёзно размышлял, стоит ли вообще включать эту структуру хранения в свою серию. Но я перфекционист. Поэтому я всё равно пишу о ней.

Оптимизация производительности SQL Server с помощью тестирования дисков

Автор: Steve Stedman, CrystalDiskMark: Optimize SQL Server Performance with Disk Benchmarking

Скорость и эффективность вашей системы хранения напрямую влияют на то, насколько быстро SQL Server сможет выполнять запросы, управлять транзакциями и обрабатывать резервные копии. Игнорирование этого критически важного компонента может привести к неприятным узким местам, которые затронут всю среду базы данных.

Клонирование с помощью аварийно-устойчивых снимков в Hyper-V

Автор: Anthony Nocentino, Crash-Consistent Snapshot Cloning - Hyper-V Edition

Если вы следили за моей серией статей о резервном копировании через снимки с помощью T-SQL (T-SQL Snapshot Backup), то большая часть из того, о чём я рассказывал, требовала участия SQL Server в создании снимка: заморозка операций записи, резервное копирование метаданных, скоординированный рабочий процесс. Эта статья покрывает другую сторону этого вопроса: клонирование, устойчивое к аварийному отказу (crash-consistent cloning). Никакой заморозки записи. Никакого резервного копирования. Никакого восстановления на момент времени. Просто клон тома «сырых» данных, который SQL Server автоматически восстанавливает при подключении.

Как выбор типа данных влияет на производительность

Автор: Paul Randal, How can data-type choice affect performance?

На одном из занятий, которые мы с Кимберли вели на этой неделе на конференции SQL Connections, мы обсуждали, как выбирать эффективные типы данных. Я хотел бы поделиться этим обсуждением здесь на примере.

Проверка узких мест ввода-вывода за 45 секунд

Автор: Luca Biondi, Check IO Bottlenecks in 45 Seconds. The "45 Seconds DBA Series" – What Real DBAs Check First | Part 5

В этой статье я покажу вам, как выявить узкие места ввода-вывода SQL Server менее чем за 45 секунд с помощью специализированных динамических административных представлений (DMV). Перестаньте гадать между задержкой и пропускной способностью и начните исправлять реальные очереди к системе хранения!

В продолжение темы о промежуточной материализации (сбросе) в TempDB

Автор: Luca Biondi, Why SQL Server Starts Spilling to TempDB

Как мы говорили в предыдущей статье: когда загрузка ЦП в порядке, операции ввода-вывода в порядке, а запросы выглядят «нормально», но производительность нестабильна: иногда быстро, иногда медленно – настоящая проблема часто кроется в сбросах в TempDB. В этой второй части мы глубже разберём первопричину!

SQL101: Проверка согласованности данных на уровне приложения

Автор: Paul Randal, SQL101: Application data consistency checking

Довольно часто случается, что компания, пережившая аварию, вызвавшую повреждение данных, но не имеющая действительных резервных копий для восстановления и возможности выполнить отработку отказа на избыточную вторичную реплику, просто запускает восстановление (repair), а затем немедленно снова начинает работать в продуктивной среде.

Работают ли многоядерные процессоры лучше, чем одноядерные?

Автор: Paul Randal, Search Engine Q&A #5: Do multi-core CPUs perform better than single-core CPUs?

Вот интересный вопрос, который прислал мне мой друг Стив Джонс из SQL Server Central — будет ли один процессор с двумя ядрами работать лучше, чем два одноядерных процессора? Оба варианта имеют два вычислительных ядра, но аппаратная архитектура разная — какой из них обеспечит лучшую производительность SQL Server? Что ж, однозначного ответа нет — всё зависит от многих факторов! Я обсуждал эту тему с Джеромом Халмансом, бывшим коллегой по команде Storage Engine в SQL Server, и с его разрешения я основываю эту статью на нашем обсуждении.

Проверка состояния TempDB за 45 секунд

Автор: Luca Biondi, SQL Server Parameter Sniffing: The Bug That Isn’t a Bug (But Breaks Everything)

В этой статье я покажу вам, как обнаружить нагрузку на TempDB менее чем за 45 секунд и, что ещё важнее, — как правильно её интерпретировать.
Потому что выявление истинного узкого места — это то, что отличает реактивных администраторов баз данных от инженеров по производительности.

Когда сервер работает медленно, но метрики CPU и ввода-вывода выглядят нормально. Когда планы выполнения выглядят приемлемо, но что-то всё равно не так. Когда запросы нестабильны — то быстры, то еле ползут — и пользователи жалуются, хотя вы не видите ничего очевидного...

Вот где многие администраторы баз данных тратят часы.

👉 Помните: TempDB часто оказывается замешана, но почти никогда не является первопричиной.

Индексы под всеми углами: Как определить, используется ли индекс?

Автор: Paul Randal, Indexes From Every Angle: How can you tell if an index is being used?

Когда бы я ни обсуждал обслуживание индексов, и в частности фрагментацию, я всегда подчёркиваю: «Прежде чем что-либо делать с фрагментацией, убедитесь, что индекс используется».

Если индекс используется не очень активно, но при этом имеет очень низкую плотность страниц (много свободного места на страницах индекса), то он будет занимать гораздо больше дискового пространства, чем мог бы, и, возможно, его стоит уплотнить (с помощью перестроения или реорганизации), чтобы вернуть это дисковое пространство. Однако обычно нет особого смысла тратить ресурсы на устранение какой бы то ни было фрагментации, когда индекс не используется. Это особенно верно для тех, кто перестраивает все индексы каждую ночь или каждую неделю.

Чтение заголовков файлов SQL Server с помощью DBCC FILEHEADER

Автор: Anthony Nocentino, Reading SQL Server File Headers with DBCC FILEHEADER

Недавно я глубоко погрузился в изучение дисковых структур SQL Server, и одно из моих любимых направлений — это перечитывание серии статей Пола Рэндала (Paul Randal) о страницах заголовков файлов. Если вы её не читали, сделайте это прямо сейчас. В ней рассказывается о том, что такое страницы заголовков файлов, что они содержат и что происходит при их повреждении. Эта статья развивает эту концепцию. Я буду использовать DBCC FILEHEADER для чтения заголовка каждого файла пользовательской базы данных на сервере и отвечу на вопрос, который возникает чаще, чем можно подумать: можно ли определить, какие файлы принадлежат одной базе данных, исключительно по заголовку файла, без обращения к sys.databases?

Короткий ответ — да, и поле, которое делает это возможным, называется BindingId. Давайте разбираться.