(Возврат на основную страницу)
Новая степень детализации блокирования индексов в SQL Server 2005 предоставляет больше возможностей
Большинство администраторов баз данных знакомо с тем, как работает блокирование таблиц, но лишь немногие администраторы баз данных знают, каким образом SQL Server 2005 осуществляет блокирование на индексах.
Индексы, подобно таблицам, являются объектом блокирования. И, как известно большей части администраторов баз данных, неподходящее блокирование (в таблицах или индексах) может негативно сказаться на производительности SQL Server.
Как и в случае блокирования таблиц, оптимизатор запросов SQL Server динамически управляет блокированием индексов, стараясь изо всех сил сбалансировать потребности в блокировании и производительности сервера. Важно помнить, что хотя блокирование может быть помехой производительности SQL Server, оно также — весьма важная и критическая функция SQL Server. В конце концов, блокирование используется для предотвращения возможности замены множеством пользователей одних и тех же данных в одно и то же время. Оптимизатор запросов старается сбалансировать количество и тип блокировок, созданных им, для того чтобы обеспечить интеграцию данных и в то же время не воздействовать негативно на производительность более, чем это неизбежно.
Один из способов, используемых оптимизатором запросов для достижения этого, — то, что называют эскалацией блокировок. Другими словами, оптимизатор запросов старается заблокировать минимально необходимое количество строк. Например, самое детализированное блокирование происходит на уровне индивидуальной строки. Если необходимо заблокировать только одну строку, то это отлично, так как минимизирует возможность того, что другой пользователь будет заблокирован при обращении к тому же индексу. Но в некоторых случаях изза природы изменений, которые должны быть проделаны, оптимизатор запросов может заблокировать тысячи строк. Чем больше отдельных строк нужно заблокировать SQL Server (и за которыми нужно следить), тем больше ресурсов необходимо для выполнения этой задачи. Так, в некоторых случаях, особенно если необходимо сделать много блокировок, SQL Server расширит блокирование с уровня строки до уровня страницы. При блокировании и отслеживании страницы вместо отдельных строк используется меньше ресурсов. С другой стороны, по мере того как все больше строк оказываются заблокированными, увеличивается вероятность блокировки запроса. Это решение о балансе, которое необходимо принять оптимизатору запросов.
В редком случае, если необходимо заблокировать на изменение огромное количество строк, оптимизатор запросов может заблокировать индекс целиком, вместо того чтобы блокировать отдельные строки или страницы данных. Опять же, это делается потому, что блокирование индекса целиком требует меньше ресурсов, чем блокирование и управление сотнями, если не тысячами индивидуальных страниц или строк. Но опятьтаки, использование меньшего объема ресурсов, когда заблокирован весь индекс, также может привести к отсутствию доступа к индексу коголибо еще — до того как будет снята блокировка индекса. Это зависит от того, какого типа блокирование используется.
Процесс, который я только что описал, называют эскалацией, так как обычно оптимизатор запросов сначала пытается использовать блокировку строк, затем страниц и затем блокировку всего индекса. Другими словами, оптимизатор запросов может начать с блокировки строки, а закончить блокировкой целого индекса. Как вы понимаете, хотя процесс эскалации достаточно целесообразен, но он также занимает время и использует много ресурсов. Другими словами, было бы эффективнее, если бы в случае, когда нужна блокировка целого индекса, она была бы получена немедленно, без предварительной блокировки строки и страницы. К несчастью, оптимизатор запросов не всегда достаточно умен, чтобы знать это.
В большинстве случаев оптимизатор запросов замечательно справляется с блокировками индексов, однако есть некоторые условия, при которых оптимизатор запросов может не справиться с блокировкой индексов так идеально, как мог бы.
Например, в некоторой базе данных есть таблица, редко изменяемая, но часто используемая. Таблица поиска — хороший пример. Возможно, эта таблица используется десятки тысяч раз каждый день. Каждый раз, когда к ней обращаются, оптимизатор запросов будет проходить через процесс эскалации блокировок. Изза того, что это таблица поиска и она редко изменяется, с точки зрения использования ресурсов и производительности будет гораздо лучше, если каждый раз будет использоваться распределенная блокировка индекса, вместо процесса эскалации блокировки.
До SQL Server 2005 у администраторов баз данных не было никакого контроля над эскалацией блокировки индексов. Им приходилось мириться с любым решением оптимизатора запросов. Но в SQL Server 2005 администратор БД имеет возможность влиять на то, как оптимизатор запросов использует эскалацию блокировки. Например, если мы захотим, то можем теперь сказать оптимизатору запросов, что желаем пропустить блокировку уровня строки и/или страницы в индексе и перейти сразу к блокировке всего индекса. Если бы мы сделали это для нашей таблицы поиска из раннего примера, то могли бы всегда использовать распределенную блокировку индекса, снизив общее потребление ресурсов SQL Server и помогая увеличить общую производительность.
Решить, стоит ли вмешиваться в то, как оптимизатор запросов проводит эскалацию блокировки на индексах, не так просто. Это должен делать только опытный администратор баз данных, который полностью понимает все последствия изменения поведения оптимизатора запросов.
Но если вы решили попробовать, то можете изменить поведение блокировки индексов в SQL Server 2005 следующим образом. В выражениях CREATE INDEX и ALTER INDEX есть две новые опции:
• ALLOW_ROW_LOCKS (по умолчанию ON) определяет, используется ли блокировка строк при обращении к данным индекса.
• ALLOW_PAGE_LOCKS (по умолчанию ON) определяет, используется ли блокировка страниц при обращении к данным индекса.
По умолчанию эти две новые опции включены. Это значит, что оптимизатор запросов волен использовать блокировки строки, страницы или всего индекса по своему усмотрению. Как администратор баз данных, вы можете решить указать оптимизатору запросов, чтобы он выключил блокировку строк, выключил блокировку страниц или выключил обе. В последнем случае единственно оставшейся возможностью оптимизатора запросов будет использование блокировки индекса целиком.
Как видите, это следует делать на основе индивидуального подхода к использованию конкретного индекса, что означает, что, если вы решаете использовать эти новые опции управления эскалацией индексов, вам действительно нужно полностью понимать вашу базу, ваши данные, ваши индексы и то, как к данным обращается приложение. Если это не так, то решение использовать хотя бы одну из этих опций означает, что вы ищете неприятностей.
Безопасность SQL Server: серверные роли
Начиная с версии SQL Server 7.0, в целях облегчения администрирования Microsoft разработала несколько изначально заданных фиксированных ролей. Эти роли обладают различными правами и должны дать возможность распределять административные обязанности без необходимости предоставлять контроль целиком. Администраторы баз данных могут использовать эти фиксированные серверные роли для назначения различных административных задач персоналу и предоставлять этим пользователям только те права, которые им абсолютно необходимы. Серверные роли, которые доступны в SQL Server 2000, это:
• bulkadmin;
• dbcreator;
• diskadmin;
• processadmin;
• securityadmin;
• serveradmin;
• setupadmin;
• sysadmin.
Эти фиксированные серверные роли полезны, если вы хотите передать часть административных полномочий по работе с определенным SQL Server, но в то же время попрежнему «крепко держать штурвал». Например, если ваша организация решает, что неопытный администратор должен обеспечивать безопасность на серверах SQL, но не хочет, чтобы он получил все права над всеми системами, то вы можете использовать серверные роли. Вы можете назначить младшему администратору фиксированную серверную роль securityadmin на каждом сервере, и этот младший администратор сможет выполнять свои обязанности по обеспечению безопасности, не получив при этом полных административных прав над экземпляром SQL Server.
Производительность процессора сервера SQL Server, 2006
Данный исторический обзор роста производительности процессоров представлен как путеводитель в усовершенствовании старых серверных систем и как стратегия закупок для новых систем.
В статье автор использует термин «сокращение» или «урезание» (shrink) для описания перехода на технологический процесс с меньшими размерностями геометрии процессора (например, замена 180 nm на 130 nm, — прим. ред.).
Концентрация внимания на линейке Intel IA32 (также называемых x86) объясняется тем, что Intel разрабатывает процессоры в соответствии с законом Мура и обычный набор результатов по производительности доступен для этой линейки процессоров за обширный период времени. Некоторые рассуждения также касаются связанных с производительностью SQL Server характеристик Opteron и Itanium.
Прошло более шести лет с тех пор, как был представлен процессор Pentium III на технологии 180 nm. С того времени линейка Pentium III была сменена в персональных компьютерах и серверных системах линейкой Pentium IV, а в мобильных системах линейкой Pentium M. И линейка Pentium IV, и линейка Pentium M теперь сменены линейкой Core 2, которая, по большей части, является потомком Pentium M с новыми генами, позаимствованными от Pentium IV. Техпроцесс 180 nm (или 0,18 µm) сменен тремя поколениями процессов 130 nm, 90 nm и теперь 65 nm.
Применение закона Мура заключается в том, что для серверных систем с быстрым ростом нагрузки, из расчета 40% из года в год, частый цикл замены, раз в два года, более эффективен, чем цикл замены раз в четырепять лет. Это противоречит обычным практикам отчетности, по которым выходит, что компьютерным системам следует иметь пятилетний жизненный цикл. Поэтому важно, чтобы администратор БД мог привести доводы тем, кто решает вопросы управления, о том, что технологические практики должны основываться на технологических разработках, а не на непререкаемых правилах отчетности.
(Возврат на основную страницу)