SQL Admin: Март 2008

Командная оболочка Microsoft Windows PowerShell и объектная модель SMO сервера SQL Server 2005. Часть 3

Восстановление после изолированного повреждения данных. Часть 1

Скотт Эмблер и Прамод Садаладж
(Scott W. Ambler and Pramod J. Sadalage)

Данная статья является выдержкой из главы 3 книги «Рефакторинг баз данных: эволюционное проектирование» под авторством Скотта Эмблера и Прамода Садаладжа, изданной Addison-Wesley Professional в марте 2006 года. Посетите www.awprofessional.com/title/0321293533 за дальнейшей информацией, включая содержание. В данной статье описывается, как провести в базе данных одиночный рефакторинг. Она содержит рабочий пример структурного рефакторинга перемещения поля, в процессе которого мы перемещаем поле Customer.Balance в таблицу Account, что на первый взгляд выглядит достаточно очевидным способом улучшить дизайн базы данных. Тем не менее, как вы увидите, даже сравнительно простой рефакторинг может оказаться не так просто осуществить без последствий внутри рабочей среды.

Научная истина торжествует по мере того,
как вымирают ее противники.

На рис. 1 показывается, как мы будем перемещать поле Customer.Balance в таблицу Account:

Работа, проводимая в данной главе, должна осуществляться внутри «песочницы разработчика» — рабочей среды, в которой у разработчиков есть их собственная копия исходного кода и базы данных. Грязная работа по рефакторингу базы данных выполняется внутри этой песочницы — здесь он продумывается, внедряется и тестируется — перед тем, как будет воплощен в других средах.

ПримечаниеАналогично существуют песочницы и для среды интеграции в рамках проекта, где члены команды внедряют и затем тестируют внесенные изменения; и для среды подготовки производства для тестирования системы, интеграции и принятия пользователями; и для производственной. Это подробно описано в главе 1 книги.

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

На рис. 2 изображена диаграмма действий UML 2, в которой рассмотрен процесс рефакторинга базы данных.

Процесс начинается с разработчика, который пытается внедрить чтото новое, чтобы исправить прошлый недостаток. Разработчик понимает, что схему базы данных, возможно, нужно переработать. В данном примере Эдди, разработчик, добавляет в приложение новый тип финансовой транзакции и понимает, что поле баланса Balance описывает сущности Account, а не сущности Customer. Поскольку Эдди следует распространенной практике быстрых изменений, такой как парное программирование (Williams & Kessler 2002) и совместное моделирование (Ambler 2002), то он решает использовать помощь Беверли, администратора баз данных (АБД) команды, чтобы та помогла ему применить рефакторинг. Вместе они многократно осуществляют следующие действия:

• Убедиться, что рефакторинг базы данных обоснован.

• Выбрать наиболее подходящий рефакторинг базы данных.

• Амортизировать изначальную схему базы данных.

• Модифицировать внешние программы доступа.

• Провести тесты возврата к предыдущему состоянию.

• Контролировать обновление версий во время работы.

Дон Шлихтинг (Don Schlichting)

* См. Дон Шлихтинг. Новое в SQL Server 2008. Часть 1 // SQL Server для администраторов. 2008. № 2.

В этой статье будут освещены некоторые из новых возможностей и преимуществ SQL Server 2008. Они включают в себя изменения в разработке, новые возможности бизнес-аналитики, дополнения по интеграции и новые типы данных.

Ниже приведены некоторые пункты, рассмотренные в части 1.

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

• Сжатие данных для снижения размера таблицы фактов.

• Управляющий ресурсами — он может быть использован для вызова события или остановки бесконтрольного или нагружающего ресурсы процесса.

• Данные о производительности — появился новый инструмент панели производительности, который может считывать сохраненные данные о производительности. Кроме того, есть новые отчеты, опции для мониторинга и настройки.

SQL Server 2008 будет выпущен примерно в феврале 2008 года вместе с новыми версиями Visual Studio и Windows. CTPсборка (Community Technology Preview) SQL Server 2008 сейчас доступна на скачивание с сайта Microsoft по следующей ссылке: http://www.microsoft.com/sql/prodinfo/futureversion/default.mspx.

В SQL 2008 используется новый Dot Net Framework 3.0 с LINQ (Language Integrated Query — интегрированные в язык запросы). Кроме того, здесь присутствует усиленная поддержка сущностей предметной области наряду с опциями синхронизации данных. Также появились новые опции по разработке с использованием ADO и Visual Studio. Все вместе это называется Dynamic Development и рассматривается ниже.

SQL Server 2008 и ADO.NET теперь позволяют создавать бизнесобъекты высокого уровня, такие как Customers (клиенты) или Parts (части). Данные сущности можно использовать вместо стандартного метода, возвращающего индивидуальные строки и таблицы. Если вы используете моделирование ER (связь по отношениям), то ваши объекты в SQL теперь будут совпадать с моделью. Есть несколько новых структур ADO.NET, которые могут обращаться к таким сущностям — например, такие как LineofBusiness (LOB) и Entity Query Language (eSQL).

LINQ предоставляет стандартный синтаксис разработки для доступа к данным в независимости от того, где они находятся. Например, один и тот же синтаксис можно использовать для обращения как к данным SQL Server, так и к данным XML. LINQ используется вместо TSQL внутри языка приложений, такого как C# или VB.

Объединение SQL 2008, Visual Studio и ADO.NET приносит с собой новые способы создания синхронизирующихся или редко отключающихся приложений, что позволяет проще создавать клиентские приложения, которые синхронизируются с центральной базой. В SQL 2005 начали с предоставления поддержки отслеживания изменений при помощи триггеров. Синхронизация в SQL 2008 лучше интегрирована и оптимизирована.

Следующие группы возможностей все вместе объединены под названием «за пределами реляционности» (Beyond Relational). Они включают в себя типы данных для хранения данных о расположении (spatial), геометрии и дате и времени. Кроме того, в SQL Server 2008 встроены новые возможности полнотекстового поиска и файлового потока (filestream).

Ранее в SQL 2005 пользовательские типы данных (UDT) не могли быть больше, чем 8000 байтов. В SQL 2008 больше нет никаких ограничений на размер, что позволяет хранение очень больших UDT.

• Date Это тип данных только даты, без времени.

• Time Тип времени без даты. Точность может достигать 100 наносекунд.

• Date Time Offset Этот тип данных хранит универсальное синхронизированное время (UTC — время по Гринвичу), зависимое от временной зоны.

Новый тип данных VarBinary(Max) FileStream позволяет манипулировать двоичными данными при помощи директив TSQL Select, Insert, Update и Delete. В прошлом, для хранения двоичных данных использовался BLOB, к которому обращалось приложение на Dot.Net. Теперь функции SQL, такие как триггеры, полнотекстовый поиск и восстановление из резервной копии, можно применять к двоичным данным, хранящимся на файловой системе.

Новый тип Spatial Data позволяет хранить в SQL Server широту, долготу и данные GPS. Этот тип данных отвечает нескольким промышленным стандартам, таким как Open Geospatial Consortium (OGC) Simple Features for SQL и ISO 19125 Simple Feature Access.

В предыдущих версиях SQL Server не существовало встроенного способа передать таблицу хранимой процедуре. Обычным обходным путем было передать большой тип varchar или XML и разобрать его. Теперь в SQL Server 2008 доступны табличные параметры. Следующий код представляет пример передачи таблицы в хранимую процедуру.

CREATE TYPE PartType
AS Table (PartID varchar(50), Descr varchar(100), createdate datetime);

CREATE PROCEDURE AddPart(@PartList PartType READONLY)
AS
SELECT * FROM @PartList

DECLARE @PartTable PartType;
INSERT INTO @PartTable values('Part1', N'Table Test', '2007-08-20');
EXEC AddPart @PartTable

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

Усовершенствовано управление памятью в SQL Server 2008 Reporting Service. Так что выполнение больших отчетов теперь не должно потреблять всю доступную память. Кроме того, вывод отчетов стал более слаженным.

Как объяснялось в части 1, основная поддержка для SQL 2000 заканчивается в апреле 2008 года. Это касается и версии CE.

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

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

• Резервные копии можно шифровать для предотвращения раскрытия или порчи данных.

• Изменения данных и доступ к ним теперь можно отслеживать.

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

• Управляющий ресурсами может предотвратить бесконтрольное использование ресурсов.

• SQL 2008 поддерживает «горячую» коммутацию процессора.

• Сильно увеличено количество счетчиков производительности.

В части 3 мы рассмотрим следующие темы по SQL Server 2008:

• Возможности интеграции данных, такие как директива MERGE, параллелизм, усовершенствования многопроцессорности SSIS и производительности поиска.

• Усовершенствования Analysis Service, включая производительность стека BI, анализ масштабирования, вычисление блокировок и перспективы.

• Интеграция с Microsoft Office 2007, такая как экспортирование отчетов служб отчетов в документ Word, улучшение формата и шрифта SSRS, а также Office Tool Bar.

Командная оболочка Microsoft Windows PowerShell и объектная модель SMO сервера SQL Server 2005 SMO. Часть 3*

Мафесами Ананта Кумар (Muthusamy Anantha Kumar aka The MAK)

В частях 1 и 2 данной серии обсуждалась установка PowerShell и простые командлеты SMO и WMI. В части 3 демонстрируется, как писать и выполнять скрипты с командлетами PowerShell. Написание скриптов является неотъемлемой частью автоматизации и выполнения повторяющихся задач.

** См. Мафесами Ананта Кумар. Командная оболочка Microsoft Windows PowerShell и объектная модель SMO сервера SQL Server 2005. Части 1–2 // SQL Server для администраторов. 2007 № 11; 2008 № 2.

Вильям Брюер (William Brewer)

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

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

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

• Быть методичным в деле снижения рисков, в написании скриптов и в тренировках восстановления в случае ЧП.

• Встроить устойчивость и «сигнализацию о неполадке» и в ПО, и в железо.

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

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

Расчет текущей доступности вашей системы базы данных

Доступность начинается с клиента. Базы данных не могут быть «доступными» с точки зрения АБД, когда на самом деле они недоступны для пользователя. Сайт eCommerce доступен только тогда, когда клиент может торговать!

Доступность базы данных вычисляется просто

ALTER FUNCTION ufrDatabaseAvailability
(
   @MeanTimeBetweenFailures real, --среднее время между падениями (в часах)
   @MeanTimeToRealise real,     --среднее время на обнаружение проблемы (в часах)
   @MeanTimeToRepair real      --среднее время на устранение проблемы (в часах)
)
RETURNS REAL
AS BEGIN
RETURN ( @MeanTimeBetweenFailures - ( @MeanTimeToRealise
                 + @MeanTimeToRepair ) ) * 100.000
    / @MeanTimeBetweenFailures * 1.0000
END

--так что если падения случаются каждые два месяца, и уходит
--примерно 3 часа на обнаружение этого
--и 8 часов на починку, то ваша доступность...

SELECT dbo.ufrDatabaseAvailability(2 * 30 * 24, 4, 8)
--99.16666

Даже при достаточно плохих характеристиках вы можете получить доступность в 99%. Тем не менее, ваш SLA (ServiceLevel Agreement — соглашение об уровне сервиса) может содержать четыре девятки, означая, что у вас есть только две минуты на то, чтобы обнаружить отказ, и две минуты на то, чтобы его преодолеть.

Две девятки (доступность 99%) сравнительно легко достичь, установив соответствующий мониторинг и оповещение, осуществляя частое и правильное резервное копирование и имея на руках точные и ясные указания по восстановлению в случае ЧП.

Три девятки (доступность 99,9%) можно достичь только тогда, когда у вас есть устойчивое оборудование, используются избыточные компоненты, включая резервные сетевые карты, маршрутизаторы и массивы RAID горячей замены.

Стремление к четырем девяткам (доступность 99,99%) требует всех «трех девяток», а кроме того, сервис должен продолжать работать и во время запланированного обслуживания — за счет использования резервных систем. Ваше суммарное время простоя в год может составлять 51,6 минуты.

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

Это трудная для вычисления величина. Часто вычисляется за минуту, как «стоимость в минуту». К сожалению, отказ в середине пика торговли несколько отличается от такого же отказа в спокойный период. Для некоторых производственных систем эту величину практически невозможно вычислить, и она должна быть установлена и оговорена с экономистами до того, как случится простой.

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

Перед тем как внедрить жизнеспособную систему, вам нужно:

• Понять вычислительные потребности всех приложений, обращающихся к базам данных.

• Составить список всех учетных записей безопасности, настроек безопасности, настроек конфигурации, баз данных, объектов уровня экземпляра, пакетов DTS/SSIS, поступлений данных, удаленных/прилинкованных серверов.

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

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

Полностью тестируйте план восстановления хотя бы раз в год.

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

Минимизация незапланированного времени простоя

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

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

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

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

Это запасной сервер той же спецификации, что и производственный, который сконфигурирован и готов для получения копии базы данных, взятой из резервных копий производственного сервера.

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

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

Синхронизации серверов при теплом или горячем резерве можно достичь следующими способами:

• Доставка журнала транзакций Это просто, дешево и надежно. Этим можно обеспечить на расстоянии «теплый резерв», но не «горячий», однако вам потребуется написать скрипт смены ролей, синхронизации учетных записей и перенаправления клиентов, чтобы минимизировать время простоя. При преодолении отказа время от времени можно потерять транзакции из последней передачи журнала. Поскольку доставка журнала копирует базу данных, а не весь сервер, то не копируются новые учетные записи, пользователи баз данных, пакеты DTS/SSIS, задания агента и т. д. Это необходимо делать отдельно. Это можно реализовать без времени простоя, однако всегда будет необходимо ручное вмешательство для преодоления отказа. SQL Backup теперь предоставляет весьма слаженный инструмент доставки журнала, которому требуется меньшая ширина канала, чем стандартной доставке журнала, и он быстрее.

• Зеркалирование Это новая технология в SQL Server 2005. Подобно кластеризации, она может осуществлять преодоление отказа на уровне базы данных, то есть быть горячим резервом. Она требует короткого перерыва в работе производственного сервера во время синхронизации, однако, в отличие от кластеризации, не требует связи с широким каналом, специально сертифицированного оборудования или специальных умений для настройки и использования. Здесь для синхронизации баз данных используются записи журнала транзакций, и управление может быть быстро передано резервному серверу. Клиентские приложения можно запрограммировать на автоматическое перенаправление информации о подключениях и, в случае преодоления отказа, заставить их автоматически подключаться к резервным серверу и базе данных. Зеркалирование баз данных поможет быстро преодолеть отказ без потери подтвержденных данных. В зеркалировании используется член«свидетель» сеанса зеркалирования базы данных для определения того, случился ли отказ. Если серверыпартнеры зеркалирования не видят друг друга, то они связываются со свидетелем, чтобы узнать, может ли он связаться с другим сервером.

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

• Синхронизация При помощи версии SQL Data Compare для командной строки можно держать базы данных синхронизированными, чтобы обеспечить «теплый резерв». Тем не менее, это эффективно только для небольших баз данных, дает нагрузку на сервер, и синхронизация может быть отложена на десять минут, в зависимости от того, как часто она происходит. Здесь также требуется ручное вмешательство в случае преодоления отказа, как и в случае доставки журнала.

• Репликация Это умеренно простой в реализации и не требующий восстановления резервной копии способ, поскольку синхронизация происходит через мгновенный снимок. Не сказать, чтобы это был вариант высокой доступности, однако я привожу его, т. к. иногда его предлагают. Наиболее он полезен для приложений Web Farm, использующих синхронизацию слиянием, но, как правило, в такой системе слишком много единичных точек отказа, чтобы квалифицировать его как альтернативу.

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

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

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

Каждой базе данных также требуется выполнение запланированных заданий по поддержке; нужно осуществлять настройку, выполнять резервное копирование, работать с индексами и так далее. В большинстве случаев SQL Server позволяет осуществлять это во время работы службы. Обычно существует способ выбрать метод и распланировать задание так, чтобы не останавливать службу. Например, при использовании директивы DBCC INDEXDEFRAG, которая не содержит блокировок, вы можете избежать блокирования любых идущих запросов и обновлений.

Хотя совсем предотвратить отказы нельзя, но можно принять все разумные предосторожности. Наиболее очевидная и самая важная предосторожность — это внедрение хорошо разработанного и реализованного режима резервного копирования, принимающего в расчет особые потребности приложения. Этот предмет выходит за границы данной статьи, однако, тем не менее, стоит отметить его значимость. А также…

• Контролируйте доступ к серверу и серверной комнате.

• Обеспечьте, чтобы вся ваша команда ясно понимала свои роли и обязанности.

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

• Документируйте и составляйте схему всех экземпляров SQL Server, особенно внимательно в отношении связей приложений, таких как репликация или доставка журналов, поступления данных, пути обмена сообщениями, связи, удаленное управление/доступ и пути передачи файлов.

• Убедитесь, что ваши тестовые сервера идентичны в конфигурации производственным серверам.

• Перед применением исправлений, пакетов обновлений и служебных пакетов проверьте их на тестовом сервере.

• Документируйте все произведенные изменения.

• Составьте список вероятных воздействий на производственную систему.

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

• Проверьте эффект изменений в отношении функциональности и воздействия/нагрузки.

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

Меры против естественных отказов, вызванных человеческим фактором, и катастроф

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

• Смоделируйте отказ во всех подозрительных местах, чтобы проверить, что вторичное оборудование «вмешается», как ожидалось.

• Предоставьте диаграмму архитектуры и ясные инструкции по всем операциям восстановления оборудования, которые будут понятны группе первичного реагирования.

• Используйте избыточные источники питания.

• Используйте инструменты мониторинга оборудования и ПО: оборудование часто посылает тревожные сигналы перед тем, как «вырубиться».

• Используйте RAIDмассив или SAN для хранения данных, с дисками горячей замены и готовой заменой. Stripe of Mirrors (Raid 10), возможно, будет лучшим решением.

• Установите избыточность в контроллерах хранилищ.

• Разместите базы данных сервера на отдельном от журнала транзакций массиве raid. Поместите TempDB на высокопроизводительный RAIDмассив. SQL Server не может функционировать без нее.

• Обеспечьте избыточность и сетевой карты и маршрутизатора.

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

• Отказ ПО может произойти изза изменений в ПО, но также изза изменений данных. Даже изменение даты может вызвать отказ. «Загнивание кода» — распространенный термин для ситуации отказа ПО системы, когда не производилось никаких программных изменений.

• Используйте контроль за изменениями и источником (смотрите меры против отказа изза изменений выше).

• Перед тем как развернуть производственный выпуск, проведите строгое «предельное» тестирование (тестирование при экстремальных значениях количества данных или ширины канала и в случае, когда компоненты оборудования случайным образом отсоединяются, чтобы определить, будет ли упадок в работе ПО
«изящным»).

• Проводите регулярное тестирование возврата в прошлое состояние на тестовом сервере с различными моделируемыми нагрузками.

• Избегайте перекрывающихся заданий в агенте SQL Server; проводите регулярные проверки DBCC и переиндексацию таблиц в периоды низкой нагрузки.

• TCP/IP был изначально разработан как устойчивая к отказам система, однако возможность направлять сетевые пакеты через альтернативные пути в случае отказа основного пути зависит от сетевой инфраструктуры.

• Должны быть предоставлены вторичные сервера DNS/WINS.

• Система не должна полагаться только на один сервер домена или active directory.

• Должны присутствовать избыточные маршрутизаторы/коммутаторы.

• Очень важны избыточные подключения к WAN/Internet.

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

• Обеспечьте физическую безопасность каждого сервера SQL Server.

• Создавайте оповещения и отчеты на каждое необычное действие пользователей на сервере и исследуйте их (для этого очень подойдет SQL Data Compare).

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

• Ведите аудит за всеми событиями входа и выхода из системы.

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

• Применяйте все текущие лучшие методы организации при реализации сервера.

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

Best practices for highly available HP Integrity servers and Microsoft SQL Server (http://h71028.www7.hp.com/ERC/downloads/4AA08978ENW.pdf). Это отличный пример тестирования высокодоступного решения, с хорошими примерами видов тестов системы и функциональности, которые подкрепляют высокую доступность. Нельзя поспорить и с их рекомендациями по части оборудования.

Восстановление после изолированного повреждения данных. Часть 1

Как быстрее всего снова заставить систему работать?

Кимберли Л. Трипп (Kimberly L. Tripp)

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

Тем не менее, перед тем как перейти к обсуждению этих стратегий, давайте посмотрим, чем могут быть вызваны изолированные повреждения. Один из возможных источников — это отказ оборудования. Однако более вероятной причиной потери данных — и, разумеется, простоя в работе — будет человеческая ошибка. Может быть, АБД случайно удалил таблицу или по ошибке стер или обновил записи изза неверного предложения WHERE. Или разработчик недостаточно хорошо оттестировал код приложения, и пользователи смогли получить доступ куда не следует и управлять не теми данными. Восстановление от изолированного повреждения, вызванного ошибкой человека, может оказаться более трудным, чем восстановление после сбоя оборудования, поскольку вы можете просто не знать, что же именно повреждено, когда это произошло или причину и степень повреждений. Если у вас нет такой информации, то восстановление может стать обременительным, долговременным и вызвать другие ошибки и дальнейшую потерю данных. Причина проблемы определяет, как следует провести восстановление, так что давайте посмотрим на подход к восстановлению после сбоя оборудования и после сбоя, вызванного ошибкой человека.

Содержание номера за Март 2008 год

SQL Server для администраторов

Март 2008
№ 3 (21)

Содержание номера за Март 2008 год

SQL Server для администраторов

Март 2008 № 3 (21)

Март 2008
№ 3 (21)