2.5.3. Сопровождение в оперативном режиме.

В идеальном случае утилиты сопровождения должны поддерживать непрерывные операции, с помощью которых система должна редуцировать или даже исключать плановые и неплановые неполадки. Часто в реляционных СУБД приходится выходить в режим off-line, чтобы выполнить некоторую утилиту. Утилиты для загрузки, резервирования, восстановления, проверки целостности, реорганизации индексов и т.д. должны допускать выполнение в оперативном режиме. Если происходит сбой во время выполнения этих операций, утилита не должна быть запущена с начала операции. Например, могут выполняться периодические проверки или даже полное протоколирование, позволяющее запустить утилиты с места сбоя. Другие возможности, так как автоматическое архивирование и архивирование в оперативном режиме полных протоколов, автоматический перезапуск (без дополнительных операторов), управляемые времена перезапуска системы имеют также большое значение; это минимальный набор тех операций, которые могут потребовать, чтобы реляционная СУБД вошла в режим off-line.

2.5.4. Устойчивость.

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

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

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

3. Технология хранения данных. Корпоративные базы данных.

3.1. Современные требования к корпоративным базам данных.

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

Распределенная обработка данных.

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

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

Технологии хранилищ данных.

Любая корпорация сегодня должна анализировать накопленные данные - без такого анализа невозможно принимать управленческие решения. Анализ должен быть всесторонним (иначе решение будет неправильным) и быстрым (иначе решение запоздает). Для этого средства анализа должны быть гибкими и понятными конечному пользователю.

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

Таким образом, современная корпоративная база данных должна располагать средствами построения хранилищ данных и OLAP-анализа.

Масштабируемость.

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

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

Для получения объективных оценок производительности и соотношения "цена/производительность" применяются стандартные тесты, разрабатываемые Советом по обработке транзакций (Transaction Processing Council - TPC). Результаты тестов регулярно публикуются на Web-узле TPC - http://www.tpc.org.

Снижение стоимости владения.

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

В сфере корпоративных систем обработки данных в последнее время большое значение придается совокупной стоимости владения (Total Cost of Ownership, TCO). Этот показатель учитывает не только начальные вложения в систему обработки данных - приобретение аппаратуры и системного ПО, но и дальнейшие затраты - разработку прикладного ПО, внедрение, обучение пользователей, текущее сопровождение, модернизацию.

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