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

Содержание номера за Июль 2006 год

Выбор правильного издания SQL Server: все не так просто

Вы пытаетесь сделать оптимальный выбор между изданиями SQL Server 2005? За последнее время я получил огромное количество вопросов от пользователей, которые интересовались: «Могу ли я обойтись Standard­изданием SQL Server 2005, вместо того чтобы платить десятки тысяч долларов за дополнительную лицензию издания Enterprise?» или «Могу ли я обойтись бесплатной версией издания SQL Server 2005 Express, вместо того чтобы платить за издание Standard?». Такие вопросы возникли давно. Размышляют над ними и пользователи SQL Server 2000. Однако в случае SQL Server 2000 ответ гораздо проще и очевиднее.

При выборе издания SQL Server 2005 первая проблема, которая встает перед многими фирмами, заключается в том, платить ли за SQL Server или попытаться обойтись некоммерческой версией. Никто не хочет платить лишние деньги, и в случае SQL Server 2000 решение было простым. MSDE, его бесплатная версия, не включала в себя инструменты для управления сервером и имела регулятор производительности, который делал продукт пригодным для удовлетворения лишь самых тривиальных потребностей реального мира или же для персонального использования. Однако SQL Server 2005 Express Service Pack 1 (SP1) в настоящее время предоставляет пользователю набор GUI­инструментов администрирования. Используя его на быстром сервере с двухъядерным процессором и 1 Гб памяти, вы получите вполне пригодную платформу для обеспечения нужд производства небольшого масштаба. SQL Server 2005 Express вкупе с расширенными службами Advanced Services даже поддерживает службы создания отчетов Reporting Services.

Вместе с тем выбор между изданиями Enterprise и Standard в случае SQL Server 2005 стал более сложным. Издание Enterprise и в SQL Server 2005, и в SQL Server 2000 включает в себя многочисленные возможности, которые не поддерживаются соответствующими Standard­изданиями. Тем не менее в случае SQL Server 2000 главным аргументом в пользу перехода на Enterprise является проблема использования памяти. Standard SQL Server 2000 ограничивает память 4 Гб. Если вам нужны большие ресурсы, Enterprise­издание будет единственным выходом независимо от того, хотели или нуждались ли вы в других его расширенных возможностях.

Однако в случае SQL Server 2005 память уже не является основным фактором, поскольку новое Stan­dard­издание поддерживает столько памяти, сколько может использовать операционная система. Можно по­прежнему применять только четыре процессора, в то время как в Enterprise­издании их количество ограничено лишь возможностями операционной системы (Windows 2003 Server может поддерживать до 64 процессоров). Microsoft определяет процессор на уровне разъемов (socket). Это означает, что вы можете использовать четыре процессора с двойным ядром. Это не так быстро, как в случае настоящей восьмипроцессорной машины, но зато не будет провала в производительности. Да и, черт возьми, ведь процессоры с четырьмя ядрами уже не за горами! Предлагает ли Enterprise­издание кучу модных возможностей, которые вы жаждете получить — иными словами, готовы за них заплатить? Безусловно! Enterprise­издание содержит огромное количество часто используемых и наращиваемых возможностей, которые не включены в Standard­издание. Однако истинное положение вещей состоит в том, что и Standard предоставляет потрясающую вычислительную мощность, и многие пользователи, которые обратились к Enterprise­изданию из­за памяти или процессорной мощности, могут более в этом не нуждаться.

Я не собираюсь рассказывать, какие специфические возможности в различных изданиях способные по­влиять на ваш выбор между изданиями. У меня даже не хватит времени, чтобы обратиться к данной теме на этой неделе. Цель этой статьи — просто заставить вас задуматься. Какая версия необходима вам? Сможете ли вы обойтись менее дорогим изданием SQL Server 2005? Возможно, ответом будет «да».

Двухпроцессорный комплекс против процессора с двойным ядром

«Выиграю ли я от использования нескольких процессоров?» — этот вопрос задают часто. С растущей популярностью двухъядерных процессоров данная тема важна как никогда! Будут ли выгодны для вас многопроцессорность или процессор с двойным ядром и в чем заключается разница между ними? Разрешить проблемы вам поможет эта статья.

Главным для некоторых людей, собирающихся приобрести высокопроизводительную систему, является вопрос о том, нужно ли им два процессора. Для тех, кто занимается обработкой видео, многопоточными приложениями или имеет дело с большим количеством одновременных задач, ответом будет весьма твердое «да». В этом случае вопрос превращается в другой: выбрать ли два независимых процессора (как в двухпроцессорной системе Xeon или Opteron) или подойдет один двухъядерный процессор (такой как Pentium D или Athlon64 X2)? Два процессора или двойное ядро — что лучше?

Что такое двойное ядро

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

Использование двух процессоров (и системной платы, которая может их поддерживать) является более дорогостоящим решением, поэтому компьютерные инженеры предложили другой подход: взять два процессора, объединить их в одну микросхему — и готово! Мощность двух процессоров и только один разъем на системной плате. При этом цена платы остается вполне разумной и позволяет использовать мощь двух процессоров (также называемых ядрами) по цене, меньшей, чем стоимость двух отдельных микросхем. Таким образом, термин «двойное ядро» означает два процессора, объединенные в одной микросхеме (рис. 1).

Есть более тонкие различия между двойными ядрами различных производителей (каким образом два ядра соединены в одной микросхеме и какова частота каждого из них), которые могут повлиять на прирост производительности. Кроме того, разные типы программ получают разный выигрыш от использования двухъядерной микросхемы.

Диспетчирование потоков

Есть еще один момент, о котором следует помнить: каким образом компьютер определяет, когда какое из ядер использовать. В операционной системе Windows есть «планировщик», который сообщает процессору, какая программа будет работать в каждый момент. Это позволяет нескольким программам оставаться активными одновременно, процессор же переключается между ними, как требуется. Если запущено много программ, компьютер может начать медленно реагировать, поскольку планировщику Windows приходится распределять ресурсы процессора во многих направлениях. Если присутствует двухъядерный процессор, то планировщик неожиданно получает в два раза больше ресурсов для работы. Это позволяет добиться того, что одно ядро занимается поддержкой работы, например только игры, в то время как второе используется для выполнения фоновых действий, которые поддерживают функционирование всей остальной системы. Иногда оба ядра могут даже работать с одной и той же программой (если она включает возможность использования преимуществ больше чем одного ядра — многопоточность). Однако важно заметить, что если вы запускаете одну программу и она не многопоточная, то вы не заметите выигрыша при наличии больше чем одного процессора или ядра (рис. 2).

Реализация двойного ядра

Поскольку AMD и Intel по­разному пришли на рынок двухъядерных процессоров, каждая платформа справляется с повышенными потребностями взаимодействия их новых процессоров по­разному. AMD заявляет, что они уже в течение нескольких лет планировали переход на двухъядерные процессоры еще с тех пор, как были выпущены первые Athlon64 и Opteron. Преимущество их решения в том, что два ядра процессоров сообщаются напрямую — структура уже была готова к тому, чтобы они работали вместе. Intel, с другой стороны, просто поместил два ядра типа Pentium на одну микросхему, и если им требуется сообщаться между собой, то приходится делать это через набор микросхем системной платы. Это не очень элегантное решение, но оно работает и позволило Intel быстро вывести свои разработки двухъядерных процессоров на рынок. В будущем Intel планирует перейти на объединенный вариант, и только время покажет, как это будет выглядеть.

Компания Intel не увеличила частоту системной шины процессора (связь между процессором и системной платой) при переходе на двойное ядро, то есть, хотя мощность процессора удвоилась, полоса пропускания каждого ядра осталась прежней. Это создает дополнительную нагрузку, что, скорее всего, мешает процессору стать таким мощным, каким он мог бы быть. Чтобы перекрыть этот эффект, Intel продолжает использовать для снабжения ядер процессора информацией более быструю системную память. Заметим, что лучшая по производительности микросхема от Intel, Pentium Extreme Edition 955, обладает более быстрой системной шиной процессора, а также большей кэш­памятью (2 Мб на каждое ядро) и способностью использовать Hyperthreading (чего недостает всем другим, не Extreme Edition Pentium D, процессорам). Этот вариант весьма интересен для тех, кто хочет обойти некоторые недостатки двухъядерного решения от Intel.

AMD, с другой стороны, использует системную шину процессора нетрадиционным способом. Для сообщения с чипсетом и системной памятью они применяют технологию, называемую HyperTransport, а также контроллер памяти был перемещен с чипсета на процессор. Расположив контроллер прямо на процессоре, в AMD дали большое преимущество своей платформе, особенно после перехода на двойное ядро. Последнее поколение одиночных процессоров AMD может использовать одно­ или двухканальную PC3200 память, но интересно отметить, что даже несмотря на то, что функционирование двух каналов удваивает частоту памяти, для процессоров с одним ядром оно не удваивает ее реальную производительность. Похоже, двухканальная память просто предоставляет значительно большую полосу пропускания, чем может использовать процессор с одним ядром. Однако в случае двойного ядра увеличенная полоса пропускания может хорошо послужить, позволяя оставить неизменной технологию, уже использующуюся в микросхемах с одним ядром, и не создавая при этом такой проблемы, от которой сейчас страдает Intel.

Сравнение производительности в случае платформы AMD

Чтобы сравнивать разницу в производительности здесь, в Puget Custom Computers, мы создаем набор исходных данных, беря их из систем, разработанных нами ранее. Это очень полезно, когда вы ищете ответы на вопросы о производительности, а именно этим мы сейчас и занимаемся! Сначала разберемся с AMD. Это будет сравнение двух систем с условно одинаковым «железом». Используемые видеокарты и жесткие диски — от одного и того же производителя и одинаковой модели. Количество динамической памяти (ОЗУ) одинаковое (2 по 1 Гб PC3200) с единственным различием в том, что в системе Opteron использовалась память ECC. Серьезная разница состояла лишь в системной плате и процессорах. Для системы Opteron использовались 2 процессора модели 248 с частотой 2,2 ГГц каждый и 1 Мб кэш­памяти. Они были установлены на плате Tyan Thunder K8WE, которая использует чипсет nVidia nForce Professional. Решение с одним процессором выглядит так: Athlon64 X2 4400+ с двумя ядрами, каждое по 2,2 ГГц и каждое с поддержкой 1 Мб кэш­памяти. Этот процессор был установлен на системную плату Asus A8N­SLI Premium, использующую чипсет nVidia nForce4 SLI (рис. 3).

Как видите, производительность графики очень близка, 3dMark05 набирает только на одно очко больше и имеет менее чем 4%­ное колебание по сравнению со значениями 3dMark'03. Приглядевшись внимательнее, мы можем заметить, что основные показатели в случае PCMark04 также очень близки: наибольшее различие видно в дополнительной степени воздействия ECC на производительность памяти. Я бы сказал, что в случае платформы AMD разница между сдвоенным процессором и двухъядерным процессором малозаметна. Это довольно приятное известие, ведь что бы вы ни выбрали, вы получите такую же мощность!

Поскольку денег у нас хватает, мы спокойно можем собрать систему AMD Opteron с системной платой для двух процессоров и поместить двухъядерный процессор в каждый разъем. В целом это даст четыре функционирующих процессорных ядра! Этот вариант особенно предпочтителен, если вам необходимо держать постоянно открытыми много приложений с большой нагрузкой (CAD, обработка видео и моделирование — вот что приходит на ум). Только побеспокойтесь о том, чтобы предоставить этим процессорам достаточно памяти.

Сравнение производительности в случае платформы Intel

Для Intel мы проводили сравнение между парой процессоров Xeon 3,0 ГГц с 1 Мб кэш­памяти каждый и одиночным Pentium D 830. Pentium D имеет два ядра, каждое с частотой 3,0 ГГц и 1 Мб кэш­памяти. Кроме того, оба варианта для связи с материнской платой используют системную шину процессора с частотой 800 МГц. Платы сами по себе различны, но в каждой системе одинаковое количество памяти (2 Гб) и одинаковые видеокарты (GeForce 6800GT 256 Mб). Есть еще некоторое различие между этими системами, поскольку память сконфигурирована по­разному: Xeon использует две планки памяти по 1 Гб PC3200, а Pentium — 4 планки по 512 Мб PC2 5400. Это дает Pentium D определенное преимущество по суммарной доступной полосе пропускания памяти, однако этот весьма ощутимый выигрыш присущ всем процессорам серии Pentium D. На время написания статьи Intel еще не усовершенствовала свои процессоры Xeon и их чипсеты для поддержки более мощной динамической памяти (рис. 4).

И снова мы ясно видим практически одинаковую производительность графики, причем Xeon чуть­чуть лучше. Однако в тестах, более ориентированных на производительность, мы видим, что Pentium слегка опережает своего противника. Скорее всего, это происходит из­за его значительного преимущества в быстроте памяти, но опять же это очень справедливый и значительный результат. Динамическая память, которая использовалась в Pentium D, является стандартной для этой платформы, но, даже если бы мы захотели, мы не смогли бы сделать систему на Xeon с такой же скоростью памяти. Поэтому, несмотря на то, что процессоры могут быть очень похожи в производительности, в целом победа, несомненно, остается за двухъядерной платформой Pentium D.

Заключение

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

Внимание: читая техническую статью, всегда смотрите на дату. Эта статья может быть уже неактуальной, так как написана 25 марта 2006 года.

Получение скриптов объектов базы данных при помощи SMO

Одним из значительных изменений в SQL Server 2005 стал переход от SQL­DMO к SMO (SQL Server Management objects), использующему библиотеки управляемого кода. В статье представлен код, который демонстрирует, как можно все это использовать для получения скриптов ваших объектов.

Скриптование объектов базы данных необходимо, если вы хотите иметь возможность из своего приложения программно создавать различные объекты базы. Для извлечения скриптов объектов базы данных можно выполнить запрос к системным таблицам или воспользоваться системными хранимыми процедурами. Раньше для этих целей применялся SQL­DMO, но он не столь эффективен с точки зрения памяти, потребляемых ресурсов и загрузки сети. Одно из нововведений .NET Framework 2.0, SMO, представляет собой доработанную и расширенную версию SQL­DMO, которая может быть использована во всех задачах, решавшихся с помощью SQL­DMO, и содержит некоторые новые возможности. В этой статье описаны различные способы получения готовых скриптов для перемещения или пересоздания некоторых объектов базы данных.

Моментальные снимки баз данных в SQL Server 2005

Мнение DBA (администратора баз данных)

Моментальные снимки баз данных — новый инструмент, появившийся в издании Enterprise SQL 2005, который позволяет создавать доступную только для чтения «виртуальную» копию базы данных на определенный момент времени. В этой статье рассказывается о том, как, с точки зрения DBA, можно использовать их в производственной среде.

Вы можете счесть моментальные снимки баз данных непригодными для решения некоторых рекомендуемых задач, таких как:

• защита системы от ошибки пользователя или администратора;

• создание отчетов без дополнительной нагрузки;

• поддержка архивных данных.

Однако мне хотелось бы также выделить две другие области, в которых, как я считаю, этот инструмент будет весьма полезен, а именно:

• модернизация системы;

• овеществление данных на резервных серверах.

За и против

Ниже приведен список сильных и слабых сторон моментальных снимков.

За:

• Они предоставляют непротиворечивую доступную только для чтения копию ваших данных на определенный момент.

• Когда идет запрос к снимку, вы не столкнетесь с блокировкой из­за операций изменения/вставки (update/insert), как может произойти при обращении к исходной базе (предполагается, что не используется новый уровень изоляции транзакций — snapshot isolation).

• Изначально файлы данных моментальных снимков малы и очень быстро создаются. Они могут стать очень большими, только если база подвергается частым модификациям.

Против:

• Вы не можете сделать резервную копию снимка, поэтому, если вам необходимо восстановить базу данных, моментальные снимки будут потеряны.

• Дефрагментирование индексов базы данных уменьшает выгоду от малого размера файлов, если разреженные файлы хранятся на протяжении определенного периода времени.

• Там, где страницы данных не изменялись, вы будете обращаться к файлам исходной базы, что может привести к соперничеству за файл, поскольку и база, и снимок будут обращаться к одному и тому же файлу MDF.

• Каждая транзакция по изменению/вставке на исходном сервере потенциально несет дополнительную нагрузку операций копирования для под­держки снимков.

• Из­за связи с исходной базой снимок должен располагаться на том же сервере, что и база.

• Вы не можете назначить новому пользователю права на данные моментального снимка. Разрешения наследуются из основной базы в том виде, в каком она существовала на момент создания снимка, и последующие изменения в ее политике безопасности снимкам не передаются.

SQL Server 2005 Upgrade Advisor
(помощник по модернизации)

Вы начали задумываться о возможных проблемах перехода ваших приложений на версию SQL Server 2005? Если нет, то, быть может, в качестве первого шага вам следует посмотреть, что сделает для вас SQL Server 2005 Upgrade Advisor. В этой статье рассказывается, что такое Upgrade Advisor и как им пользоваться.

Помощник по модернизации SQL Server 2005 Upgrade Advisor — это инструмент, который доступен с электронного ресурса Microsoft. Его можно применять для определения того, готово ли ваше окружение SQL Server 7.0 и 2000 к обновлению до SQL Server 2005. Upgrade Advisor выявляет возможные препятствия, которые могут помешать успешному переходу к SQL Server 2005. Помощник — это простой в использовании мастер, который не обновляет ваше существующее окружение, а только исследует его и докладывает о результатах. Благодаря этому вы можете проанализировать отчет и затем грамотно спланировать успешный перевод ваших компонентов версии 7.0 и 2000 на новую версию.

Как было замечено выше, Upgrade Advisor доступен в Интернете. С тех пор как компания Microsoft впервые представила Upgrade Advisor, было выпущено несколько новых версий. Я бы посоветовал вам загрузить самую новую и затем, по мере того как вы будете осуществлять переход на SQL Server 2005, постоянно отслеживать и загружать все последующие. Сделать это можно, перейдя по ссылке http://go.microsoft.com/fwlink/?LinkId=45788.

Выбор служебных учетных записей

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

Не так давно я писал статью о служебных учетных записях SQL Server 2005 (см. врезку «Учетные записи служб SQL Server 2005»), где дал некоторую базовую информацию об имеющихся службах и о том, как создавать учетные записи и управлять ими. Однако кто­то спросил меня, какие типы учетных записей следует использовать и как распределить их среди десятка возможных служб. На одиночном SQL Server у вас вряд ли будет 10 запущенных служб, однако 4 или 5 будет наверняка. На большом консолидированном сервере с многочисленными экземплярами это число увеличится.

Мне и раньше задавали подобные вопросы, причем часто это делали люди, которые пытались определить, как наилучшим образом установить службы, ограниченные в SQL Server 2000 всего лишь двумя. Многие не очень хорошо понимали, как лучше настроить эти службы, особенно администраторы Windows, впервые познакомившиеся с SQL Server. Здесь я попытаюсь дать несколько советов и пояснить различные способы установки служб.

Типичная установка

Я встречался с двумя типичными способами установки SQL Server. Ни один из них не рекомендуется использовать, однако это самый простой путь, и поэтому его выбирает большинство.

Первый способ заключается в том, чтобы запустить все службы из­под локальной системной учетной записи (Local System). Это была единственная встроенная учетная запись в версиях до Windows 2003, которая позволяла запускать службы. Она доступна из программы установки, и большинство людей используют эту учетную запись, если они еще не создали другую. Такой подход не рекомендуется, так как она эквивалентна, а в некоторых случаях и более влиятельна, чем учетная запись локального администратора. Это дает ненужные привилегии службе SQL Server и, если сервер находится в небезопасной зоне, может привести к тому, что кто­нибудь сумеет захватить управление всем сервером Windows.

Я знаю, что данный аргумент не слишком убедителен, так как это происходит довольно редко и для большинства людей представляется абстрактной возможностью. Но тем не менее это риск. Кто­нибудь может спокойно создать задание (SQL­job) или запустить команду xp_cmdshell, которая навредит серверу Windows, удалит файлы или произведет какое­то иное действие, способное нарушить работу вашей службы.

Другой вариант установки, который мне часто приходится видеть, — установка SQL Server с правами администратора из­под учетной записи администратора (локального или в домене) или записи с правами администратора, принадлежащей тому, кто устанавливает сервер, например sjones. Этот способ часто применяют потому, что не могут заставить что­то работать и не задумываясь обращаются к записи с наивысшими правами, чтобы не сталкиваться с проблемами. Это плохая привычка — по многим причинам, что и в случае Local System, но также и по другим.

Нам часто требуется изменить пароль для учетных записей пользователей, включая и учетную запись администратора. Это обычная и, несомненно, правильная практика, которая обычно заканчивается тем, что кто­нибудь забывает поменять пароль для службы. А спустя пару недель SQL Server не сможет запуститься, и никто не будет знать почему, или не удастся соединение по сети — и уйма времени уйдет на выявление неисправностей.

Обеих указанных практик следует избегать — это  просто, если совершить некоторые предварительные действия и выполнить стандартную процедуру.

Рекомендация не используйте учетную запись Administrator или LocalSystem.

Общие учетные записи

Я редко видел, чтобы в компании был только один SQL Server — разве что в очень маленькой, приобретшей сервер баз данных под определенный программный продукт. Обычно в организации их два или больше, иногда сотни. И мне часто доводилось наблюдать, что их запускают под одной и той же учетной записью пользователя — если не под LocalSystem, то под Administrator.

Использование общей учетной записи для ваших серверов SQL — не слишком блестящая идея. Простота создания только одной учетной записи, наличия центральной точки смены пароля и одного набора разрешений, которые необходимо установить, обманчива. Это плохая идея. Предположим, у вас работает десять или более серверов под одной учетной записью. Смена пароля потребует от вас посетить все эти серверы — и если вы забудете хотя бы один, то можете нажить себе проблемы, аналогичные указанным выше. Я знаю, что, скорее всего, вы редко будете менять пароли на служебные учетные записи, но я уже видел, как подобная ситуация может закончиться проблемами, выраженными в странном поведении серверов или в невозможности запуска серверов после патча. Разобраться в этом, если у вас установлено 3 сервера, не так сложно, но когда их 300, будет уже не смешно.

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

В случае SQL Agent проблема гораздо шире. По­скольку это служба, которая запускает задания SQL­jobs и выполняет различные действия, часто расположена в файловой системе или на другом сервере, то она более подвержена риску, чем основной сервер базы. К тому же, поскольку данная учетная запись обычно реагирует на различные события рассылкой электронной почты, использование специализированной учетной записи поможет определить источник проблем.

Вряд ли что­нибудь изменится для учетной записи, используемой для работы служб, вряд ли они будут взломаны или будут заниматься чем­либо, кроме работы SQL Server. Однако что вы все же предпочтете — чтобы упал один сервер/служба или сто? Смена паролей, смена учетных записей или иные операции на большом количестве серверов отнимают много времени и являются абсолютно ненужной работой. Если используются отдельные учетные записи, то число зависимостей минимизировано и грандиозный сбой никогда не произойдет.

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

Учетные записи пользователей

Итак, если вы согласны, что приведенные выше рекомендации — хорошая идея, то какую учетную запись все же следует использовать?

Я рекомендую вам создать доменную учетную запись пользователя для каждой службы и сервера. Это должна быть базовая учетная запись, член группы Everyone и никакой другой в домене, если речь идет о самостоятельном SQL Server. Если вы назначаете эту учетную запись при помощи программы установки, Enterprise Manager в SQL Server 2000 или Con­fi­guration Manager в SQL Server 2005, то тогда соответствующие права будут настроены на локальной машине — как права пользователя, так и разрешения ACL для доступа к каталогам. Использование базовой учетной записи без каких­либо специальных групп делает ее наиболее оптимальной с точки зрения безопасности.

Если вы меняете что­то в установке SQL Server, например располагаете файлы в других катологах или требуете разрешения на доступ вне положений по умолчанию, то следует создать еще и группу для этой службы. В этом случае я рекомендую вам создать группу, в имени которой сочетались бы SQL с именем службы и экземпляра сервера. Назначьте ей необходимые права и затем добавьте в нее доменного пользователя. Для сетевого или мультисерверного доступа используйте доменную группу.

Я бы посоветовал вам не использовать в данном случае пользовательские группы, так как права их групп меняются и они должны быть закреплены для пользователя(­ей) за определенной рабочей функцией. Вместо этого создавайте специальные группы, предоставляющие права, необходимые для функционирования нужного сервера баз данных.

Это также упростит использование почтовых служб для SQL Server. Назначая доменного пользователя для каждой почтовой службы (отдельно для SQL Server и SQL Agent), вы можете создавать раздельные почтовые ящики и отслеживать, откуда изначально пришло электронное письмо. Это также ослабляет зависимость между службами, поэтому, если один ящик вдруг перестанет функционировать, второй продолжит работу.

Планирование

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

Я бы выбрал простое правило именования, такое как SQL_(имя_сервера)_(экземпляр)_(служба), поскольку мне нравится венгерская нотация и нам не нужно лишних проблем с какими­либо скриптами или другим программным кодом, что может случиться при обработке имен с пробелами. Неважно, какое конкретно правило именования вы выберете, — главное, чтобы оно было понятно другим служащим и задокументировано.

Когда вы проделаете это, не забудьте установить пароль, который не требует смены и срок действия которого не истекает через некоторый промежуток времени. Периодическое изменение паролей представляет собой хорошую практику, однако если вы забудете об этом или у вас не будет времени, то вряд ли вы захотите, чтобы они перестали действовать. Соответственно не требуйте и смены, так как первый вход в систему, скорее всего, произойдет без вашего участия.

И последнее замечание: поставьте трудный для угадывания, сложный, плохо запоминающийся пароль. Поскольку вам придется устанавливать его только один раз (будем надеяться!), пусть он имеет длину 15—20 символов разного регистра и состоит из чисел и букв. Если нужно, запишите его, возможно, собрав все учетные записи на одном листе бумаги, пока не установите их все, а затем уничтожьте записи.

Заключение

Установка отдельных учетных записей для каждого сервера, почтовой рассылки, компьютера и последующее добавление их в группы — это напряженный труд. Он утомителен, отнюдь не доставляет удоволь­ствия, несколько скучен, поэтому большинство людей не хочет им заниматься. Однако все это необходимо проделать только один раз или, по крайней мере, относительно редко. Потратьте пару минут, как следует настройте учетные записи, и, возможно, это не раз спасет вас в дальнейшем — ведь последнее, что вы хотите получить, это сервер или, что хуже, 30 серверов, которые не запустятся после ночной установки патча.

Систематизация разных типов фрагментации

Возможно, вы знаете о том, что в Server 2005 появилась новая табличная функция sys.dm_db_index_physical_stats. Заменяя функцию DBCC SHOWCONTIG, она возвращает информацию о физической организации ваших структур данных.

Систематизация

Фрагментация, которая отображает степень компактности и непрерывности последовательности хранения данных, бывает двух видов — внутренняя и внешняя. Внутренняя фрагментация показывает количество свободного места, оставшегося на страницах, и степень компактности хранения данных. Внешняя фрагментация отображает степень непрерывности следования страниц.

Ни в одном случае не рассматривается излишняя (чрезвычайная) фрагментация. Если ваши приложения беспорядочно обращаются к отдельным рядам данных, тогда число рядов на странице или близость одного ряда к другому не имеет значения. Обратиться к одному ряду из фрагментированной таблицы не сложнее, чем из нефрагментированной. Тем не менее, если ваши приложения производят сканирование по упорядоченным диапазонам и, следовательно, считывают все или большинство страниц в таблице, внешнее фрагментирование может существенно замедлить процесс сканирования. Чем меньше промежутков в таблице и чем лучше упорядочены страницы, тем эффективней SQL Server cможет провести сканирование.

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

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