• емкость связана с объемом данных, резервные копии которых необходимо создавать регулярно;

• надежность носителей и оборудования для резервного копирования определяет конечный результат восстановления системы после сбоя, при этом очевидно, что степень надежности зависит от бюджета организации, а также то, что увеличение надежности, как правило, увеличивает и временные затраты;

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

• скорость создания резервных копий и восстановления данных, чем выше скорость, тем выше затраты;

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

• 3.Восстановление корпоративных данных

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

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

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

Минимальное ведение журнала (bulk-logged) – сокращает использование пространства в журналах, но сохраняет большую часть возможностей полного резервного копирования. Массовые операции с данными заносятся в журнал минимально, что не позволяет контролировать каждую такую операцию в отдельности. Поэтому, если сбой данных произойдет перед создание очередной полной или дифференциальной копии, операции массовой загрузки данных придется повторить вручную. Стратегия резервного копирования при использовании этой модели возможна в двух вариантах: создание полных и дифференциальных резервных копий в сочетании с копиями журнала транзакций или же только полных копий и копий журналов транзакций.

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

Сервер горячего резерва – автоматически обновляемый сервер, начинающий работу немедленно после сбоя основного СУБД-сервера.

Сервер холодного резерва - сервер, обновляемый вручную, который в случае отказа основного СУБД-сервера нужно перевести в рабочий режим вручную.

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

4. Планирование резервного копирования корпоративных данных

Планирование резервного копирования очень больших БД

Если необходимо разработать план резервного копирования и восстановления очень больших БД, следует воспользоваться преимуществами параллельного резервного копирования и восстановления, когда SQL Server применяет несколько потоков для чтения и записи данных и может работать одновременно со многими источниками данных. Процессы резервного копирования и восстановления используют параллельные операции ввода-вывода следующим образом:

• резервное копирование/восстановление использует по одному потоку на каждое дисковое устройство, если БД была определена файлами, расположенными на разных дисках;

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

Стратегия резервного копирования должна быть реализована таким образом, чтобы БД использовали:

• несколько дисковых накопителей для хранения данных;

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

5. Распределенные базы данных (РБД) КИС

ТЕХНОЛОГИИ РАСПРЕДЕЛЕННОЙ ОБРАБОТКИ ДАННЫХ

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

РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ (РБД)

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

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

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

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

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

Система управления распределенными базами данных, или РСУБД, предоставляет клиентам унифицированный интерфейс доступа к данным, благодаря которому возникает иллюзия единого сервера. Если данные находятся в разных местах, РСУБД посылает запросы и обновления в соответствующие хранилища. В зависимости от того, с каким хранилищем ведется работа, производительность системы может оказаться разной, но, клиентам не приходится самим заниматься выбором сервера. В идеале, клиенты не знают, является система распределенной или нет – свойство прозрачности. Они лишь посылают ей запросы, а система возвращает клиентам результаты этих запросов. На практике распределенные базы данных проявляют разную степень "прозрачности".

ДВЕНАДЦАТЬ ПРАВИЛ ДЕЙТА для РБД

1. Независимость локального узла (local autonomy) – каждый локальный узел может действовать как независимая, автономная централизованная СУБД. Каждый узел отвечает за безопасность, управление параллельным выполнением, резервное копирование и восстановление данных

2. Независимость от центрального узла (no reliance on central site) – все узлы системы независимы м имеют равные возможности, а расположенные на них базы данных являются равноправными поставщиками в общее пространство данных. БД на каждом из узлов полностью защищена от НСД.

3. Независимость от сбоев (continuous operation) – функционирование всей системы не зависит от сбоя на каком-либо узле, система продолжает выполнение операций даже при неисправности узла или при расширении сети. Это возможность непрерывного доступа к данным (извест. как "24 часа в сутки, семь дней в неделю") в рамках ddb вне зависимости от их расположения и вне зависимости от операций, выполняемых на локальных узлах. Это качество можно выразить лозунгом "данные доступны всегда, а операции над ними выполняются непрерывно

4. Прозрачность расположения (location independence) – пользователь не обязан знать реальное, физическое расположение данных в РБД. Транспортировка запросов к базам данных осуществляется встроенными системными средствами

5. Прозрачность фрагментации(fragmentation independence)– пользователь видит единую логическую БД, у него нет необходимости знать структуру и имена фрагментов БД для получения доступа к ним

6. Прозрачность репликации или тиражирования данных(replication independence) – СУБД управляет всеми фрагментами так, что пользователь работает в рамках единой логической БД с актуальными данными,

7. Распределенная обработка запросов (distributed query processing) – может выполняться на нескольких узлах процессоров данных DP (Data Processor) в рамках обычного SQL-запроса. Оптимизацию запросов СУБД выполняет прозрачно для пользователя

8. Распределенная обработка транзакций (distributed transaction processing) – транзакции могут согласованно обновлять данные на нескольких различных узлах, выполнение распределенной транзакции на нескольких узлах DP происходит прозрачно для пользователя

9. Независимость от оборудования (hardware independence) – система должна выполняться на любой аппаратной платформе

10. Независимость от ОС (operationg system independence) - система должна выполняться в любой ОС

11. Независимость от сети (network independence) –система должна работать на любой сетевой платформе, то есть РСУБД должна поддерживать широкий спектр сетевых протоколов

12. Независимость от базы данных (database independence) –система должна поддерживать Базы Данных различных производителей

Правила Дейта описываю полностью распределенные базы данных, и хотя ни одна из современных РБД не соответствует всем этим правилам, тем не менее, ими следует руководствоваться при проектировании и разработке распределенной БД.

Основные практические проблемы РБД:

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

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

3. необходимость обеспечения совместимости данных стандартных типов, для хранения которых в разных системах используются разные физические форматы и кодировки

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

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

6. необходимость обеспечения совместимости СУБД разных типов

ТИПЫ РАСПРЕДЕЛЕННЫХ БД

РБД подразделяются на однородные (гомогенные) илиразнородные(гетерогенные).

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

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

Любая распределенная СУБД должна иметь следующий набор функциональных возможностей:

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

2. расширенные средства ведения каталога, позволяющие сохранять сведения о распределении данных

3. средства обработки распределенных запросов

4. расширенные функции управления безопасностью, которые обеспечивают соблюдение правил авторизации и прав доступа к распределенным данным

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

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