Дата публикации: 13 августа 2013г.

Автор: Боб Дорр – главный эскалационный инженер поддержки SQL Server
По материалам статьи: How It Works: SQL Server 2012 Database Engine Task Scheduling

В течении последних лет в разных источниках были описаны алгоритмы работы планировщика SQL Server. В частности, в статье «The Guru’s Guide to SQL Server Architecture and Internals» есть глава, написанная разработчиком планировщика (Sameer) и Кеном Хендерсеном. Автор этой статьи иранее описывал некоторые технические детали алгоритмов планирования задач SQLServer.

Эта статья посвящена некоторым изменениям, которые появились в SQL Server 2012. Статья не претендует на охват всех нюансов (коих слишком много), вместо этого будет частично проиллюстрирована работа алгоритма в его современной реализации, что позволит вам лучше понимать поведение планировщика SQLServer . Автор допускает по тексту несколько вольную трактовку в описании алгоритмов, преследуя цель избавить статью от лишней официальности. Read the rest of this entry »

По материалам статьи Крейга Фридмана: Introduction to Partitioned Tables

27 ноября 2006г.

В этой статье я собираюсь продемонстрировать особенности планов исполнения запросов при обращении к секционированным таблицам. Обратите внимание, что существует большая разница между секционированными таблицами (которые стали доступны только с SQL Server 2005) и секционированными представлениями (которые были доступных ещё в SQL Server 2000, и по-прежнему доступны в SQL Server 2005 и последующих версиях). Особенности планов запросов к секционированным представлениям я продемонстрирую в другой статье.
Read the rest of this entry »

По материалам статьи: Running SQL Server on Machines with More Than 8 CPUs per NUMA Node May Need Trace Flag 8048

Данная статья относится к следующим версиям SQL Sever: 2008, 2008 R2, 2012 и 2014. Первый вариант статьи был опубликован в 2011г.

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

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

CMemPartitioned можно считать обычной «кучей» (хотя это и не HeapCreate), поскольку используется одна и та же концепция. Если при создании «кучи» вам нужны синхронизированные оценки, то вы можете указать размер по умолчанию и другие атрибуты. Обычно, когда созданию объектов памяти причастны разработчики SQL Server, они обеспечивают индикацию того, что будет задействовано что-то вроде защищённого поточного доступа, схемы секционирования и другие опции.

Разработчик инициирует создание объекта, и потом, когда происходит новое распределение, всё будет происходить по твёрдым правилам, которые иллюстрирует рисунок ниже:

Слева показан приходящий от исполнителя запрос, которому нужен объекта памяти на базе модели секционирования памяти по узлам. Это позволяет использовать объекты синхронизации (обычно типа: CMEMTHREAD или SOS_SUSPEND_QUEUE) уровня узла, и память выделяется из локальной памяти того NUMA узла, для которого назначен этот исполнитель.

Справа приходит запрос на распределение объекта памяти, для которого предписано исполнение на конкретном процессоре. Это позволяет использовать объект синхронизации уровня процессора, и выделять память, локальную для исполнителя этого процессора.

В большинстве случаев дизайн, основанный на привязанных к конкретному процессору распределениях, снижает вероятность коллизий синхронизации, что является следствием особенностей работы планировщиков SQLOS. Приоритетные и фоновые задачи могут стать участниками коллизии, но планирование на уровне конкретных процессоров может значительно снизить вероятность возникновения подобных коллизий. Однако, использование секционирования по процессорам, а не по NUMA узлам, означает увеличение накладных расходов, поскольку возникает необходимость поддержки индивидуальных путей доступа к каждому процессору и соответствующих им списков памяти.

Read the rest of this entry »

Автор: Daniel Farina

http://www.mssqltips.com/sqlservertip/3328/sql-server-2014-real-time-query-monitoring/

Проблема

Если вдруг один из запросов к SQL Server выполняется слишком долго, вы может получить его план исполнения, что даст вам понимание того, что этот запрос делает, но из этого плана вы не сможете точно определить, что запрос делает именно в это время, т.е. на каком операторе плана он «застрял»?
Продолжая читать эту статью, вы узнаете, как научится следить за прогрессом исполнения запроса в режиме реального времени.

Read the rest of this entry »

http://www.sqlskills.com/blogs/paul/important-change-vlf-creation-algorithm-sql-server-2014/

Автор: Paul Randal

Опубликовано: 6 января 2015г.

SQL Server 2014 был выпущен еще в апреле прошлого года, и ходили некоторые слухи об изменениях в алгоритме создания VLF. Они направлены на уменьшение числа VLF, когда журнал увеличивается по команде или автоматически (далее я буду говорить для простоты авто-приращение, поскольку это наиболее распространенный сценарий). Я сделал несколько экспериментов и подумал, что понял изменения указанного алгоритма. Оказывается, я понял не всё. На прошлой неделе в переписке MVP всплыл вопрос, который породил целую дискуссию, и мы вместе пришли к выводу, что алгоритм ведет себя недетерминированно… другими словами, мы не знаем, что он делает. Так что я обратился к моим друзьям в CSS, которые исследовали код (спасибо Bob Ward и Suresh Kandoth!) и объяснили изменения.
Read the rest of this entry »

 По материалам статьи Craig Freedman: Parallel Hash Join

SQL Server использует один из двух вариантов стратегии распараллеливания хэш-соединения. Наиболее часто встречается хэш-секционирование (Hash Partitioning). Реже можно встретить Broadcast-секционирование; эту стратегию часто называют “Broadcast hash join”.

Read the rest of this entry »


AlexeiK
26 Jan 2010 5:34 AM

Авторы:: Стюарт Озер (Stuart Ozer) при участии Према Мехры (Prem Mehra) и Кевина Кокса (Kevin Cox)

Технические редакторы: Любор Коллар (Lubor Kollar), Томас Кейзер (Thomas Kejser), Дэнни Ли (Denny Lee), Джимми Мэй (Jimmy May), Майкл Рэдман (Michael Redman), Санджэй Мишра (Sanjay Mishra)

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

Read the rest of this entry »

« Older entries