Не существует рекомендованного Майкрософт способа уведомления администраторов о том, что SQL Server выгрузил дамп страниц памяти на диск. Также весьма затруднительно отслеживать такие дампы средствами SQL Server или операционной системы, поскольку во время выгрузки дампа работа сервера баз данных и большинства системных процессов «замирает». Однако, вполне возможно обнаружить последствия выгрузки дампа, поскольку в указанной для дампов папке вместе с файлами дампа появится файл с именем: «SQLDUMPER_ERRORLOG.log». Имя этого файла неизменно, на этом и основан предлагаемый вашему вниманию способ слежений за появлением новых дампов. Настройка пути к папке дампов хранится в системном реестре. По этому пути можно посредством PowerShell узнать существует ли в папке дампов файл с именем «SQLDUMPER_ERRORLOG.log». Такую проверку можно делать по расписанию в задании Агента SQL Server. Если файл обнаружен, то можно совершить необходимое действие. Например, в приведенном ниже сценарии будет отправлено письмо электронной почты на указанный список адресов. Отправку осуществит подсистема SQL Server DatabaseMail. Для корректной отправки сообщения нужно указать существующий почтовый профиль.
Обычно, администраторы изучают причины, вызвавшие создание дампа по файлам текстовых описаний дампа и логу. Вместе с этим можно переименовать и/или скопировать файлы дампа в другое место, или удалить. Также, можно составить сценарий PowerShell таким образом, чтобы необходимые действия выполнялись в дополнение к предлагаемому ниже примеру сценария: Read the rest of this entry »

Craig Freedman April 25, 2007
https://blogs.msdn.microsoft.com/craigfr/2007/04/25/read-committed-isolation-level

SQL Server 2000 поддерживал четыре уровня изоляции транзакций: «read uncommitted» (nolock), «read committed», «repeatable read» и «serializable». В SQL Server 2005 были добавлены два новых уровня изоляции: «read committed snapshot» и «snapshot». Указание уровня изоляции определяет, какие блокировки будут использованы SQL Server при доступе к данным. Следовательно, выбор уровня изоляции фактически определяют степень параллелизма и согласованности, которые станут возможны для операций с данными и транзакций. Все указанные уровни изоляции описаны в Books Online. Read the rest of this entry »

По материалам статьи Craig Freedman: Semi-join Transformation
4 декабря 2006г.

В предыдущих статьях я приводил примеры полу-соединений (semi-joins). Вспомним, что полу-соединение возвращает строку из таблицы, если для этой строки есть хотя бы одна совпадающая строка во второй таблице. Вот простой пример:
Read the rest of this entry »

По материалпм статьи: SQL 2016 – It Just Runs Faster: Automatic Soft NUMA
30 марта 2016

Автор: Nitin Verma – Principal SQL Server Developer, Bob Dorr – Principal SQL Server Escalation Engineer

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

Read the rest of this entry »

Дата публикации: 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 »

« Older entries