(Возврат на основную страницу)

 

Содержание номера за Февраль 2012 год

SQL Server

Февраль 2012 № 2 (20)

 

  1. О ляпсусах в работе с SQL Server рассказывает Грант Фритчи
    Грант Фритчи (Grant Fritchey)

  2. Ограничения и база данных, управляемая тестами
    Сэм Бендайян (Sam Bendayan)

  3. Нешуточные дебаты вокруг SQL Server: блокировка страниц в памяти
    Джонатан Кехайяс (Jonathan Kehayias)

  4. Как оценить использование данных
    Мишель Уффорд (Michelle Ufford)

  5. Определяем число записей, вставляемых в секунду в каждую таблицу
    Мишель Уффорд (Michelle Ufford)

  6. Код для извлечения информации о безопасности для SQL Server 2012
    ВидхаСагар (VidhyaSagar)

О ляпсусах в работе с SQL Server рассказывает Грант Фритчи
Грант Фритчи (Grant Fritchey)
 

Мы решили попросить разных известных специалистов по SQL Server написать о наиболее запомнившихся им ляпсусах в работе с ним. Ляпсусы – это такие часто встречающиеся неправильные представления о работе SQL Server, которые в итоге оканчиваются слезами и жалобными вопросами на форумах. Настоящую серию публикаций открывает Грант Фритчи (Grant Fritchey) рассказом о некоторых из таких ляпсусов, отложившихся у него в памяти.
Почти с любой точки зрения, SQL Server – это довольно впечатляющий образец программного обеспечения. Более того, в его поставку входит великолепный набор документации Books Online (BOL). Хоть я и зарабатываю на жизнь публикацией книг и статей, но хочу сказать следующее: на самом деле вам не нужна никакая другая документация, чтобы обеспечить достаточно хорошую работу большинства экземпляров SQL Server в большинстве рабочих сред. Ну да, встречаются крайности и исключения, когда документации BOL, возможно, окажется недостаточно, но, в общем и целом, ее авторы действительно проводят достойную разъяснительную работу. И потом есть ляпсусы. Это такие функции, которые… ну, в общем, они просто не вполне корректно или подробно документированы. Почему я так решил? Потому что на разных форумах и на сервисе Twitter все время появляются вопросы, одни и те же вопросы по одним и тем же темам.

Ограничения и база данных, управляемая тестами
Сэм Бендайян (Sam Bendayan)
 

Неправильные данные, по-видимому, всегда появляются тогда и там, когда и где их меньше всего ожидают. Сэм объясняет, как это важно, – использовать оборонительный подход, основанный на применении ограничений, для любой команды разработчиков, создающей приложение, в котором данные должны быть абсолютно правильными, и где неверные данные могли бы привести в дальнейшем к тяжелым финансовым потерям. Такой подход, вероятно, лучше рассматривать как создание базы данных, управляемой тестами.
Автоматизированное модульное тестирование для разработки баз данных было представлено недавно в рамках методологий гибкого программирования (agile programming methodologies). Хотя принять на практике разработкау баз данных, управляемых тестами, вещь стоящая, ее не следует отделять от установившейся практики использования ограничений базы данных. Само по себе применение ограничений уже обеспечивает нам средства создания баз данных, управляемых данными. По сути дела, ограничения базы данных – это просто тесты. Тесты на целостность данных. К тому же, эти тесты не противоречат практическим методикам agile-тестирования в том смысле, что ограничения обычно проектируются первыми, – до того, как вы напишете хоть одну строчку кода, аналогично разработке, ведущейся по принципу «сначала тест» («test-first development»).
Предложение использовать ограничения базы данных является весьма ценным для любого разрабатываемого проекта. Отказ от применения ограничений равнозначен отказу от тестирования выходных данных вашего программного обеспечения.

Нешуточные дебаты вокруг SQL Server: блокировка страниц в памяти
Джонатан Кехайяс (Jonathan Kehayias)
 

Было немало споров о необходимости использовать параметр «блокировка страниц в памяти» (Lock Pages in Memory, LPIM) для 64-разрядных версий сервера SQL Server. Джонатан Кехайяс рассказывает без прикрас об истории этого параметра, окружающей его использование путанице и объясняет, почему он считает, что использовать этот параметр как настройку по умолчанию все-таки полезно для 64-разрядных экземпляров сервера SQL Server, даже если они функционируют под управлением операционных систем Windows Server 2008 и Windows Server 2008R2.
 

«An ounce of prevention is worth more than a pound of cure» – Benjamin Franklin


Недавно, я откликнулся на следующий, казалось бы, безобидный вопрос, заданный в Twitter: «Должен ли я включить в конфигурацию блокировку страниц в памяти как настройку по умолчанию?» Мой ответ был утвердительным: если это 64-разрядная версия, если у вас установлено свыше 16-32 Гб оперативной памяти (RAM), если вы указали соответствующее значение для параметра конфигурации «max server memory» и ведете наблюдение за счетчиком доступной физической памяти «Memory\Available Mbytes», то вы должны разрешить блокировку страниц по умолчанию. В ходе последовавшего обсуждения выяснилось, что мой совет несколько расходится с тем, что предлагали по этому вопросу служба поддержки пользователей фирмы Microsoft и несколько уважаемых обладателей статуса «SQL Server MVP»; расходится не в том смысле, что параметр «Lock Pages in Memory» все-таки иногда необходим, как реакция на испытываемое SQL Server принуждение со стороны операционной системы, заставляющее сервер выполнить усечение своего рабочего набора, но по вопросу о том, надо ли использовать этот параметр по умолчанию.
С их любезного разрешения я намерен выделить записи, оставленные в их блогах двумя обладателями статуса «SQL Server MVP» и многоуважаемыми членами нашего сообщества пользователей SQL Server Брентом Озаром (Brent Ozar) и Гленном Аланом Берри (Glenn Alan Berry), в которых подытоживается противоборствующее мнение:

Другими словами, в младших версиях Windows Server, которые активно реагировали на нехватку памяти усечением рабочего набора SQL Server, настоятельно рекомендовалось использовать механизм LPIM. Однако, с появлением новых операционных систем, обладающих более совершенным механизмом управления памятью, параметр LPIM лучше не использовать, если только в этом нет настоятельной необходимости. Во многих отношениях этот совет является разумным, и еще не далее, как в начале 2011 года, когда началось мое сотрудничество в роли консультанта с фирмой SQLskills, я согласился бы с ним целиком и полностью. Однако, полученный с тех пор опыт убедил меня в обратном. В настоящей статье я надеюсь окончательно прояснить основные вопросы, сопровождающие использование механизма LPIM, и объяснить, почему я рекомендую применять блокировку страниц в памяти как конфигурационную настройку по умолчанию на всех 64-разрядных экземплярах SQL Server, если только у вас нет серьезной причины (например, использование виртуальной среды) не делать этого.

Как оценить использование данных
Мишель Уффорд (Michelle Ufford)

Недавно на конференции был задан вопрос "А какая часть наших данных фактически используется?" Соответственно, возникает желание понять, а вообще возможно ли извлечь эту информацию из недр SQL Server? Я полагаю, что ответ будет "да".
SQL Server собирает статистику использования индексов и характер этого использования. Для получения данных по статистике нам предлаагется использовать представление sys.dm_db_index_usage_stats.
С точки зрения бизнес перспективы мне кажется более интересным содержание БД т.е. таблицы: сколько места занимают таблицы, которых никто не касался уже много дней. Для получения этой информации я буду анализировать использование любых индексов, принадлежащих интересующей меня таблице.

Определяем число записей, вставляемых в секунду в каждую таблицу
Мишель Уффорд (Michelle Ufford)

Приходилось ли вам когда-нибудь определять, сколько записей вставляются в таблицы баз данных на сервере? Или возникает необходимость убедиться, что все процессы закончили запись в таблицы. У меня подобные вопросы возникают регулярно. Для получения указанной информации я написала запросы, которые использую информацию из представления sys.partitions. Использованный подход не так аккуратен, как исполнение SELECT COUNT(*) FROM, но работает гораздо быстрее. Следует иметь ввиду, что код смотрит только на число записей и не очень годится для таблиц, которые интенсивно обновляют или удаляют записи. Но для моих задач он вполне подходит и я исспользую его достаточно часто.

Код для извлечения информации о безопасности для SQL Server 2012
ВидхаСагар (VidhyaSagar)


SQL Server 2012 уже скоро выйдет на рынок. Известно, что в новой версии реализовано немало новшеств, относящихся к вопросам безопасности, у нас появятся contained database, в которых мы сможем создавать contained user, появятся изменяемые серверные роли... Я написал несколько запросов, которые обращаются к новой информации, доступной в SQL Server 2012.

(Возврат на основную страницу)

Hosted by uCoz