Архивация данных

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

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

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

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

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

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

Другой вариант заключается в создании разделов таблицы. Этот вариант позволяет определить диапазоны значений ключевых полей отдельных таблиц как относящиеся к различным разделам и затем разместить эти разделы в различных группах файлов. Управляя размещением тех или иных данных в различных группах файлов в пределах одной таблицы можно добиться лучшего контроля над расходованием средств. Можно разместить отдельные группы файлов на различных физических дисках (см. выше примечание о дешевых и дорогих дисках), выбрать группы файлов для резервного копирования и определить периодичность резервного копирования. Если эти группы файлов создаются «только для чтения», то можно также использовать частичные резервные копии

Количество баз данных

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

Ответ. Независимо от количества персонала в вашей организации поддерживать идентичный код СУБД во всех базах данных будет трудной задачей. После исправления ошибки в коде СУБД придется выполнить развертывание 5000 раз. Кроме того, время восстановления базы данных будет чрезмерно большим, также как и время выполнения таких операций, как создание резервных копий и проверка согласованности баз данных. Сравните это с такой ситуацией: станет ли банк создавать отдельную базу данных на своем сервере для каждого клиента, имеющего текущий счет?

Сервер SQL Server™ позволяет создать очень много баз данных, но этот подход не всегда лучший. Представьте себе объем работы, необходимый для выполнения одной транзакции в каждой базе данных в один и тот же момент времени, притом что в каждой базе данных ведется собственный журнал транзакций. Как известно, одним из ключевых факторов производительности при оперативной обработке транзакций (online transaction processing, OLTP) является поддержание среды, в которой при ведении журнала транзакций используется последовательная запись на диск. Если в этих базах данных нужно выполнять транзакции, а не только читать данные, такой подход использовать не стоит.

Запросы к связанному серверу

Вопрос. Выполняется разработка хранилища данных на сервере SQL Server 2005 с пакетом обновления 1 (SP1). Исходный сервер расположен в домене партнера, а конечный сервер — в нашем собственном домене. Извлечение записей с исходного сервера выполняется при помощи связанного сервера. Запрос, включающий объединение исходных таблиц, выполняется очень быстро. Однако даже простой запрос, включающий объединение с конечными таблицами, выполняется очень долго. Почему это происходит?

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

Измерение пропускной способности

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

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

Защита доступа к серверу SQL Server

Нужны рекомендации по защите доступа к серверу SQL Server в рабочей среде? Обратитесь в «Центр для разработчиков Microsoft patterns & practices». Наибольший интерес представляют три документа:

• Security Engineering Index
• Security Guidance for Applications Index
• Threat Modeling Web Applications

Нужны подробные указания для настройки полной рабочей среды? Вот два полезных источника:

• Windows Server System Reference Architecture
• Data Services Implementation Guide

Readers Comments (Комментариев нет)