(Возврат на основную страницу)
Если вы администратор баз данных, в ваши обязанности, возможно, не входит обновление операционной системы на сервере баз данных, но при решении задач повышения производительности SQL Server путем модернизации операционной системы сервера до Windows 2003 придется расширить таким образом круг своих задач.
Существует несколько результатов тестов, демонстрирующих эффективность модернизации системы (результаты одного из тестов, проведенных Microsoft, см. по адресу http://www.microsoft.com/SQL/evaluation/compare/benchmarks.asp), но я могу подтвердить, что после модернизации наблюдал повышение производительности приблизительно на 25% при выполнении заданий с большим количеством операций вводавывода. К счастью, это обновление прошло почти так же безболезненно, как уверяла Microsoft. Я продемонстрирую процесс миграции SQL Server, работающего на кластере из двух узлов Windows 2000 Advanced Server, к Windows Server 2003 Enterprise Edition.
Приготовления
Вопервых, вы должны убедиться в том, что установлен SQL Server 2000 SP3.
Предыдущие версии SQL Server, такие как 7.0 и 6.5, не совместимы с Windows Server 2003 и не поддерживаются Microsoft. Хотя я и слышал, что SQL Server 7.0 успешно работает с Windows Server 2003, но я бы не рекомендовал использовать эту конфигурацию в промышленной среде.
Первое, что вы должны проверить, — это совместимость аппаратного обеспечения и драйверов, установленных на сервере баз данных с системой Windows Server 2003. Большинство компанийпроизводителей размещают информацию о совместимости продуктов на своем Webсайте. Если вы не можете найти нужную информацию на сайте компании, необходимо связаться с ней непосредственно для выяснения этого вопроса. Это очень важный шаг при обновлении системы, поскольку проблемы в работе одного драйвера могут привести к тому, что обновление завершится ошибкой, или даже хуже — при видимой на первый взгляд корректной установке обновления возникает множество неожиданных проблем после обновления.
На следующем шаге нужно определить стратегию восстановления в случае сбоя. Это наиболее важная часть обновления. Как минимум, вы должны сделать резервные копии баз данных и других промышленных данных на сервере. Кроме этой резервной копии я настоятельно рекомендую использовать Symantec Ghost либо другое подобное программное обеспечение, чтобы непосредственно перед обновлением создать образ вашей системы. Это способно помочь сэкономить время в случае необходимости восстановления и определенно стоит потраченного времени при возникновении такой ситуации.
Запуск обновления
Есть два пути обновления вашего кластера, хотя они состоят из похожих шагов. Различаются они только временем, которое проходит между обновлением узлов. Метод поочередного обновления состоит в обновлении сначала одного узла кластера, а затем постепенном перемещении ресурсов кластера на другой узел, что повышает производительность и стабильность системы. Хотя я нахожу этот метод наиболее предпочтительным, так как при этом у вас всегда имеется один исправный узел, он накладывает ограничение на создание кластерных ресурсов в смешанном режиме (когда отличаются операционные системы на разных узлах кластера).
Если же вы не можете позволить себе лишиться возможности создавать кластерные ресурсы, можно немедленно, после окончания обновления первого, обновить и второй узел, выбрав метод одновременной миграции. Различия между этими методами незначительны, и выбор метода ограничивается только требованиями логики вашего бизнеспроцесса.
Инструкцию по обновлению Windows 2000 до Windows Server 2003 можно найти по адресу http://download.microsoft.com/download/9/9/6/996f17f2e0084581a26f9098f87690e2/Upgwin2k.doc. В этой документации также можно получить информацию об Application Compatibility Toolkit (набор утилит для проверки совместимости программного обеспечения). Это свободно распространяемый Microsoft комплект утилит, который может помочь в том, чтобы обновление прошло более гладко. Однако самым полезным инструментом из этого набора утилит может стать Application Verifier. Application Verifier применяется, чтобы проверить любое пользовательское программное обеспечение на совместимость с Windows 2003 Server.
После окончания процесса обновления операционной системы и применения всех существующих к этому моменту исправлений первое, что вы должны сделать, — переместить экземпляр SQL Server на активный узел. Завершив это перемещение, необходимо немедленно начать проверку работоспособности процессов этого экземпляра SQL Server. Для этого можно запустить любое задание, которое имеется у этого экземпляра, и просмотреть результаты на предмет выявления отклонений. Если экземпляр участвует в репликации, необходимо проверить, что репликация отрабатывает корректно. И в заключение следует запустить несколько пользовательских процессов и проверить, нет ли отклонений в их работе.
Если вы удовлетворены результатами, полученными для обновленного узла, необходимо подумать, когда лучше выполнить обновление следующего узла. Я рекомендую подождать несколько дней, если для вашей промышленной среды это допустимо, чтобы убедиться, что все функционирует нормально. Как только будете готовы, перенесите все ресурсы кластера на узел Windows Server 2003 и начинайте процесс обновления второго узла. вы не должны упустить из вида, что аппаратные средства, драйверы и программное обеспечение должны быть идентичны на обоих узлах. Если же это не так, необходимо проверить совместимость и отследить любые подобные отклонения.
Итоги
После модернизации вы сразу же заметите повышение производительности процессов, для которых необходимы частые операции вводавывода. Как было упомянуто выше, я добился увеличения скорости на 25%. Одно это служит стимулом для перехода на Windows Server 2003. Подготовительная работа перед обновлением может быть несколько утомительна, но она полностью окупается тем, что обновление затем проходит без помех.
Используйте эти возможности AD для идентификации пользователей
Профессионалы ИТ отвечают за гарантии того, что системы, которые они разрабатывают и администрируют, защищены всеми доступными средствами как от внешних, так и от внутренних угроз. Жизненно важным, но зачастую упускаемым аспектом компьютерной безопасности является безопасность системы управления базами данных. В таких системах управления базами данных, как SQL Server, безопасность начинается с процесса идентификации, который представляет собой процедуру проверки того, что пользователь, запрашивающий некоторую услугу, является легальным пользователем и уполномочен получать доступ к этой услуге.
В SQL Server 2000 доступны два метода идентификации: через Windows и через SQL Server. Идентификация средствами Windows использует учетные записи, поддерживаемые операционной системой Windows. При идентификации с помощью SQL Server используются учетные записи, полностью поддерживаемые средствами SQL Server. В отличие от учетных записей Windows они хранятся не в централизованной базе данных безопасности, поэтому ими нельзя управлять с помощью политик учетных записей. Специалисты Microsoft разъясняют эти вопросы в статье «Система безопасности Microsoft SQL Server 2000» (http://www.microsoft.com/sql/techinfo/administration/2000/securitywp.asp). В ней утверждается, что система идентификации Windows более безопасна, чем система идентификации SQL Server, которая поддерживается лишь для обеспечения обратной совместимости, а также для работы под управлением Windows Me и Windows 98. При установке SQL Server 2000 по умолчанию применяется конфигурация системы безопасности на основе режима идентификации Windows. Это указывает, что в будущих версиях SQL Server может поддерживать только данную конфигурацию.
По материалам статьи Andres Taylor Advanced SQL Server Locking
Перевод Виталия Степаненко (http://www.sql.ru/forum/actualtopics.aspx?bid=55)
Я думал, что знаю SQL Server достаточно хорошо. Я использую этот продукт уже больше 6 лет, и мне нравится знать об используемых мною инструментах все. Когда я преподавал на курсах программирования SQL Server, я заметил, что в материалах Microsoft представлена таблица совместимости блокировок. Та же таблица была представлена и в MSDN. Рассматривая эту таблицу, я удивился: неужели здесь нет блокировки Intent Update? Это привело меня к исследованию блокировок. Данная статья и есть результат этого исследования. Я написал эту статью для определенного читателя — для того, кто понимает уровни изоляции, блокировки намерения, мертвые блокировки и уровни блокировок. Если вы недостаточно уверенно разбираетесь в этих областях, вам нужно сначала ознакомиться с ними перед чтением этой статьи.
Я надеюсь, что я расширю ваше понимание блокировок в SQL Server и, возможно, научу вас некоторым приемам, которые вы будете использовать во время программирования на SQL Server.
Должен сказать, что вы можете вполне успешно работать с SQL Server долгое время и не знать, как он блокирует свои ресурсы, и в то же время писать высококачественные код и схемы баз данных. Но если вы похожи на меня и хотите знать внутреннее строение вещей или если вы работаете с системой, которая требует хотя бы небольшого прироста производительности, то я могу научить вас коечему полезному.
Интересовались ли вы когданибудь, можно ли выполнять хранимую процедуру асинхронно по отношению к какомулибо коду TSQL? Я имею в виду запуск хранимой процедуры в фоновом режиме и продолжение выполнения следующей строки кода сценария TSQL до окончания выполнения хранимой процедуры. В этой статье рассказывается, когда может понадобиться асинхронное выполнение хранимых процедур, как его осуществить, и рассматривается пример, который поможет вам попрактиковаться в его запуске.
Прежде чем показывать, как выполнять хранимую процедуру асинхронно, давайте разберемся, где асинхронная логика поможет улучшить приложение. Скажем, у меня имеется приложение для ввода заказов в реальном времени, когда оператор принимает заказы по телефону. Мое приложение было сдано в эксплуатацию 12 месяцев назад, а теперь база данных разрослась и содержит миллионы записей. Когда это приложение впервые начало использоваться, на обработку заказа уходило в среднем 2 минуты. Но постепенно время, затрачиваемое на обработку заказа, становилось все больше и больше. Теперь, когда в базе данных содержится более миллиона записей, ввод нового заказа занимает от 15 до 20 минут. Такое падение производительности вызвано ошибками в проектировании базы данных. Этот недостаток приводит к падению доходов, потому что клиенты не желают ждать у телефона 20 минут, пока их заказ будет обработан.
Проанализировав положение, я понял, что основное время ожидания обусловлено спиралевидной структурой базы данных и большой продолжительностью обновления всех таблиц, которое необходимо было проводить после того, как сам заказ уже был введен. Для завершения телефонного разговора в основном требовалось обновить только пару таблиц, а все остальные обновления (те самые, которые требовали 20 и более минут) можно было выполнить после того, как клиент уже повесил трубку. Поэтому я решил, что проще всего будет взять исходную хранимую процедуру ввода заказа и переписать ее запуск так, чтобы 20минутная транзакция выполнялась бы асинхронно. Такой подход показался мне более предпочтительным, потому что хранимая процедура ввода заказа вызывается из множества точек в приложении, и изменение исходной логики потребует переписывания значительно большего объема кода, чем переделка одной хранимой процедуры ввода заказов.
Теперь, когда понятна проблема с хранимой процедурой, давайте рассмотрим текущее состояние хранимой процедуры с низкой производительностью.
Задачи журналирования различных событий, происходящих в базе данных, рано или поздно встают практически перед каждым, кто имеет отношение к процессу разработки, поддержки и сопровождения, администрирования, документирования и распространения программных систем, связанных с использованием БД.
Задачи, которые решает контроль изменений структуры
· 1. Кто, когда, с какой машины и каким приложением менял структуру базы.
Задача скорее административная. Для разбирательств постфактум «кто, когда и зачем все сломал».
· 2. Ведение истории изменений для последовательного наращивания версий.
Пример 1: у пользователей есть версия X базы, разработчики постепенно вносят некоторые изменения, и спустя какоето время появляется версия Y. Задача состоит в том, чтобы, не ломая существующей у пользователей базы, также последовательно нарастить ее до версии Y. Впрочем, такую задачу можно (и даже более удобно) решить и без накапливания последовательных изменений: сравнивая две базы с использованием системных представлений, процедур и таблиц.
· 3. Автоматизация различных рутинных действий в базе.
Пример 2: в разрабатываемой
системе есть два типа пользовательских таблиц — реплицируемые и нет. Структура
репликации хорошо продумана, все обкатано и работает. Пусть имена реплицируемых
таблиц начинаются с префикса «rt», а нереплицируемых — с префикса «t». При
добавлении новой таблицы она автоматически включается в публикацию, если имеет
соответствующий префикс. Изменение структуры базы — добавление таблицы —
является сигналом для запуска кода, который может добавить таблицу в
существующую публикацию.
Пример 3: на таблицы в базе (все или некоторые)
автоматически создается набор триггеров определенной структуры для решения
стандартных для данной системы задач. Или набор процедур, когда прямые действия
с таблицами запрещены, а разрешены только через хранимые процедуры.
Задачи, которые решаются контролем изменений данных
· 1. Кто, когда, с какой машины и каким приложением менял данные в базе.
Задача, скорее
относящаяся к безопасности. Журнал используется для восстановления реальной
картины событий, когда данные испорчены/утеряны, а те пользователи, кто имеет
доступ к базе и права на работу с данными, искажают (намеренно или нет) картину
прошлых действий. Данные,
которые
нужны
для
такой
задачи:
user_name, date/time, host_name, app_name, table_name, record_id.
Подвидом данной задачи и ее упрощенным
вариантом является хранение сведений о последнем изменении в данных, т. е.
last_user, last_datetime и т. д.
Как в полном виде, так и в сокращенном, данный тип отвечает скорее за
административный аспект необходимости журналирования. Длительность хранения
данных в журнале может сильно варьи
роваться.
· 2. Ведение истории изменения данных.
Здесь в большей степени имеет значение, какие именно данные менялись, старые/новые значения. Используется в случаях, когда нужна полная история изменения данных. История хранится достаточно долго, возможно, на протяжении всей жизни данных. В некоторых случаях история хранится и после того, как данные были удалены.
· 3. Уведомление об изменениях данных.
Уведомления клиентских приложений, что данные, отражаемые на интерфейсе, устарели и должны быть обновлены. Если система кэширует на промежуточном или клиентском уровне какието данные, то ее необходимо уведомлять, что данные устарели и кэш надо обновлять. Здесь реализация может сильно отличаться в зависимости от решаемой задачи. В некоторых случаях достаточно журналирования лишь факта операции, в некоторых — журнал должен содержать все сведения вплоть до старых/новых значений. Характерным признаком данного класса задач является короткая продолжительность хранения данных в журнале. Типичная ситуация: с некоторой периодичностью запускается процесс, который считывает все изменения из журнала, рассылает уведомления, очищает журнал и отключается.
· 4. Нестандартная репликация.
В MSSQL 2000 есть различные типы репликации, которые при грамотном использовании способны решить большинство задач, связанных с синхронизацией данных на разных серверах. Большинство, но не все. Типичный пример — offline репликация (на дискетах/компактах/по почте). Данную задачу при некотором упорстве можно решить, используя триггеры и журналирование данных.
(Возврат на основную страницу)