(Возврат на основную страницу)
Чери Уоррен SQL Server 2008: минимизация блокирования в SQL Server
Ричард Динг Узнайте размер таблиц и других объектов базы данных SQL Server с помощью хранимой процедуры
Что не надо делать при программировании на TSQL, или Как правильно писать быстрый код
Дубликаты, неопределенные значения, первичные и возможные ключи и другие экзотические прелести языка SQL
SQL Server 2008: минимизация блокирования SQL Server
Блокирование необходимо для поддержки текущих действий чтения и записи базы данных, но оно может отрицательно влиять на производительность системы, причем иногда трудно обнаруживаемыми способами. В данной статье рассматривается оптимизация базы данных SQL Server 2005 и SQL Server 2008 для минимизации блокирования, а также отслеживание состояния системы для лучшего понимания воздействия блокирования на производительность.
Блокирование и укрупнение
SQL Server выбирает наиболее подходящую грануляцию блокировки на основе количества затрагиваемых записей и существующих в системе одновременных действий.
По умолчанию SQL Server использует наименьшую возможную грануляцию блокировки, выбирая крупногранулированные блокировки только в случае возможности более эффективного использования системной памяти. SQL Server укрупняет блокировку, если это повышает общую производительность системы.
Как показано на рис. 1, укрупнение происходит в случае, если количество блокировок в определенном просмотре превышает 5000, или если память, используемая системой для блокировок, превышает доступный объем:
• ядром СУБД используется 24 процента памяти не AWE при параметре блокировок — 0;
• ядром СУБД используется 40 процентов памяти не AWE при параметре блокировок, отличном от 0.
Возникающая блокировка всегда является блокировкой таблицы.
Предотвращение появления ненужных блокировок
Блокирование может происходить с любой грануляцией, но ее воздействие увеличивается при возникновении укрупнения. Укрупнение блокировок может свидетельствовать о неэффективной архитектуре, коде или настройке приложения.
Соблюдение основ структуры базы данных (таких как нормализованная схема с узкими ключами и избегание использования массовых операций с данными в транзакционных системах) является важным для предотвращения блокировок. При несоблюдении этих принципов (например, при отделении системы отчетности от транзакционной системы или обработке потоков данных в нерабочее время) настройка системы будет затруднена.
Индексирование может быть ключевым фактором определения количества блокировок, необходимых для доступа к данным.
Индекс может уменьшить количество записей, доступных для запроса, путем уменьшения количества внутренних просмотров, которые должны быть выполнены ядром СУБД. Например, при выборе одной строки таблицы в неиндексированном столбце все строки таблицы должны быть временно заблокированы до определения необходимой записи. Если этот столбец был индексирован, потребуется только одна блокировка.
Серверы SQL Server 2005 и SQL Server 2008 содержат динамические административные представления (sys.dm_db_missing_index_group_stats, sys.dm_db_missing_index_groups, sys.dm_db_missing_index_details), отображающие таблицы и столбцы, получающие преимущества от индексов, на основе статистики суммарного использования. Проблемы производительности также могут быть связаны с фрагментацией в том отношении, что ядру СУБД может требоваться доступ к большему количеству страниц, чем обычно необходимо. Более того, неверная статистика может быть причиной выбора оптимизатором запросов менее эффективного плана.
Следует иметь в виду, что, хотя индексы убыстряют доступ к данным, они могут замедлять изменение данных, поскольку требуется не только изменение базовых данных, но и обновление индексов. Динамическое административное представление sys.dm_db_index_usage_stats показывает частоту использования индексов. Распространенным примером неэффективных индексов являются составные индексы, в которых один столбец индексируется отдельно и вместе. Поскольку SQL Server обращается к индексам слева направо, индекс используется, если самые левые столбцы полезны.
Таблицы секционирования могут оптимизировать систему (уменьшая воздействие блокировки) и поделить данные на отдельные физические объекты, обеспечивая возможность работы с ними по отдельности. Хотя секции по строкам — наиболее очевидный способ секционирования данных, также заслуживает внимание секционирование данных по горизонтали. Можно специально выбрать денормализацию путем разделения таблицы на отдельные таблицы с таким же числом строк и ключей, но различным числом столбцов, чтобы уменьшить возможность того, что отдельные процессы одновременно захотят получить монопольный доступ к одним и тем же данным.
Чем более разнообразны способы доступа приложения к определенной строке данных и чем больше столбцов могут быть включены в эту строку, тем более привлекательным является подход с секционированием столбцов. Иногда этот подход может быть выгоден для очереди приложения и таблиц состояния. В SQL Server 2008 добавлена возможность отключения укрупнений блокировок для отдельных секций (или таблиц, если для таблицы не включены секции).
Узнайте размер таблиц и других объектов базы данных SQL Server с помощью хранимой процедуры
Ричард Динг
Sp_spaceused — это хранимая процедура, входящая в состав SQL Server и применяемая для отображения сведений об использовании дискового пространства объектами базы данных SQL Server. Во многих ситуациях я обнаруживаю, что она не вполне соответствует моим запросам.
От нее мало толку, когда мне требуются общие сведения о размере пользовательских таблиц в текущей базе данных SQL Server, когда мне нужен список десяти крупнейших индексированных объектов или если мне необходимо узнать общий объем пространства, занимаемый группой таблиц.
Потому я и написал хранимую процедуру sp_SOS — расширенную версию sp_spaceused; ее можно использовать для вычисления пространства, используемого объектами базы данных SQL Server, а также для выполнения некоторых других операций.
В sp_SOS я хотел сохранить базовый функционал sp_spaceused, — то есть алгоритм суммирования пространства используемого данными и индексами, выделенного и неиспользуемого пространства для каждого объекта. Я не буду останавливаться на вопросах измерения базы данных, а сразу перейду к хранимой процедуре для создания отчетов о размере объектов базы данных.
Что не надо делать при программировании на TSQL, или Как правильно писать быстрый код
По материалам форума http://itsecure.org.ua/
Одним из вопросов, все чаще обсуждаемых мной в последние дни с клиентами или администраторами/разработчиками баз данных, является создание такой политики компании, которая бы описывала ряд стандартов, которым должны следовать при создании хранимых процедур для SQL server. С одной стороны, политика стандартов уровня компании или подразделения не должна быть столь ограничительной или «высеченной на камне», чтобы душить всякий творческий потенциал, который часто необходим для решения требований бизнеса, стоящих перед разработчиками. С другой стороны, она должна обеспечить такие рекомендации, которые ограничивали стиль кодирования таким образом, чтобы он не создавал проблем безопасности, падения производительности или проблем обслуживании в будущем.
Хотя всесторонняя политика является слишком большой, чтобы быть описанной в этой статье, вы могли бы сделать небольшую электронную книгу только по стандартам TransactSQL, а я бы с удовольствием обсудил те вопросы, относящиеся к стилю, которые чаще всего вызывают падение производительности на сайтах моих клиентов.
Дубликаты, неопределенные значения, первичные и возможные ключи и другие экзотические прелести языка SQL
Наверное, многим знатокам языка SQL содержимое этой заметки покажется тривиальным. Особенно тем, кто читает колонку Криса Дейта в журнале «Database Programming and Design» (www.dbpd.com). Поверьте, что мы не конкурируем с уважаемым господином (и нашим любимым автором) Дейтом, а лишь хотим высказать свои собственные соображения, возникшие в ходе подготовки практического курса по языку SQL. Мы занимаемся вопросами, связанными с организацией доступа к базам данных, уже более 20 лет, и поэтому нам самим было странно обнаружить в языке SQL некоторые неафишируемые, но глубоко присущие ему свойства, отстраняющие язык от классической реляционной теории.
(Возврат на основную страницу)