ГОСЫ / KIS_Romanova
.pdfРепликация моментальных снимков (или просто репликация снимков, snapshot replication) – это наиболее простой и легко реализуемый метод репликации. При использовании репликации снимков периодически создается снимок (картина) базы данных, который распространяется подписчикам. Главным преимуществом репликации снимков является то, что она не требует непрерывной нагрузки на издателей и подписчиков. Издателям не нужно непрерывно следить за изменениями данных, а также не требуется непрерывной передачи данных подписчикам. Главным недостатком является то, что база данных у подписчика соответствует только последнему снимку базы данных издателя. Как правило, репликацию снимков применяют в тех случаях, когда данные серверов-подписчиков используются только для чтения или данные по своей природе являются редко обновляемыми (справочники) или объем данных не очень большой. Дополнительной причиной для применения этого метода может быть низкая пропускная способность сетевых соединений. Сеансы связи назначаются в то время, когда общая нагрузка на сеть наиболее низкая.
Репликацию транзакций (transactional replication) можно использовать для распространения изменений, вносимых в базу данных. При использовании репликации транзакций любые изменения, вносимые в статьи (наборы данных, сконфигурированные для репликации) на сервере-издателе, немедленно считываются из журнала транзакций и распространяются дистрибьюторами. Используя репликацию транзакций, можно поддерживать издателя и его подписчиков почти всегда в одинаковом состоянии. Репликацию транзакций следует использовать в тех случаях, когда важно поддерживать все реплицируемые системы на уровне текущих изменений. Репликация транзакций накладывает на систему более высокую нагрузку, чем репликация снимков, поскольку она по отдельности передает в реплицируемые системы каждую транзакцию, которая вносит изменения в систему. Для репликации транзакций необходимо постоянное и надежное сетевое подключение. Однако репликация транзакций поддерживает реплицируемые системы в более согласованном состоянии, чем репликация снимков и репликация слиянием (сведением).
Репликация слиянием (или сведением, merge replication) похожа на репликацию транзакций, так как тоже работает с изменениями, которые вносятся в статьи для реплик. Но вместо отдельного распространения транзакций, которые инициируют изменения, репликация слиянием периодически передает накопленный к тому моменту времени пакет изменений. Этот метод является потенциальным источником большого количества конфликтов между изменениями, вносимыми отдельными пользователями. Поэтому это самый сложный в проектировании и обслуживании тип репликации. (задачу разрешения конфликтов решает соответствующий агент – Merge Agent – на основе заранее назначенных приоритетов). Репликация слиянием в основном предназначена для клиентов с мобильными устройствами и тем, кому часто приходится работать в автономном режиме.
Независимо от того, какой метод репликации выбран администратором системы, его реализация всегда
начинается с выполнения репликации снимков, то есть создания первой копии реплицируемых данных на подписчике.
ПЛАНИРОВАНИЕ РЕПЛИКАЦИИ
Реплицированные данные подчиняются правилу взаимной непротиворечивости, которое требует,
чтобы все копии фрагментов были идентичны. Для обеспечения этого СУБД должна гарантировать, что обновление РБД выполняется на всех узлах, где есть реплики данных. Очевидно, что репликация влечет за собой дополнительные расходы, поскольку система должна обслуживать каждую копию данных. Вместе с тем, репликация позволяет восстановить утерянные на одном из узлов данные.
На репликацию БД влияет несколько факторов, главные из которых:
размер БД
частота использования БД
топология сети и ее пропускная способность.
21
Проектирование и планирование репликации является сложной задачей, поскольку для выработки эффективного решения необходимо учесть большое количество факторов.
Для начала нужно собрать максимум информации о потоках и структуре данных, об организационной структуре, потребностях и процессе работы пользователей, конфигурации сети и серверов системы:
Очень важно собрать как можно больше сведений о будущих подписчиках и их пользователях, чтобы определить их цели и задачи. Следует принять во внимание аппаратные возможности серверов, количество обслуживаемых ими пользователей, способы подключения к серверам (TCP/IP, Multiprotocol, Named pipes), полосу пропускания и надежность соединений. Количество подписчиков также влияет на выбор архитектуры репликации.
Далее необходимо выделить данные, которые нуждаются в репликации (таблицы или некоторое подмножество их строк и столбцов). При этом следует придерживаться общего правила: никогда не реплицируйте больше данных, чем необходимо, так как это увеличивает нагрузку на оба сервера издателя и подписчика.
Одним из ключевых вопросов проектирования архитектуры репликации является определение допустимого времени ожидания обновления данных. Если, например, подписчик не может больше, чем несколько минут функционировать без изменений, внесенных на сервере-издателе, то репликация снимков категорически не подходит (поскольку копирование снимка между серверами выполняется очень медленно). Если же подписчику достаточно получать обновления раз в день, неделю или месяц, то репликация снимков - наилучшее решение. Кроме того, можно уменьшить стоимость репликации для удаленных узлов за счет использования коммутируемых соединений вместо стационарных линий.
Для выбора модели и метода репликации важна полоса пропускания соединения, его надежность и стоимость передачи данных. Очевидно, что лучше планировать репликационный обмен в часы самой высокой скорости передачи данных.
Служба поддержки распределения Distribution Agent может работать либо на дистрибьюторе, либо на подписчике. Агент требует большое количество ресурсов сервера, поэтому его лучше устанавливать на менее загруженный сервер.
Репликация значительно усложняет работу СУБД-сервера: увеличивается рабочая нагрузка, возникает необходимость в дополнительном пространстве на жестком диске (для хранения реплицируемых данных, файлов снимков и базы данных distribution). Поэтому администратору нужно включать в проект репликации требования к оперативной памяти, быстродействию процессора и объему жесткого диска реплицируемых серверов. Чтобы правильно оценить эти требования, нужно учесть объемы реплицируемых данных, количество публикаций, количество статей в каждой публикации, частоту репликационного обмена и максимально возможную длительность хранения на издателе и дистрибьюторе подготовленных к тиражированию данных, а также обычную рабочую нагрузку серверов издателей и дистрибьюторов.
После сбора всей необходимой информации и определения требований, составляется проект репликации и детальный план реализации. При этом рекомендуется составить диаграмму структуры сети, расположения и взаимодействия компонентов репликации.
22
Настройка репликации является итерационным процессом, где строго определен порядок выполнения операций. Сначала конфигурируется и настраивается дистрибьютор, потом – издатель. Издатель – это основа и источник всего процесса, именно здесь определяются статьи и публикации. Важно помнить о том, что реплицируются только необходимые данные, одним из важнейших средств их отбора являются вертикальные и горизонтальные фильтры. Последним конфигурируется и настраивается подписчик
-----------------------------------------------------------------------------------------------------------------------
23
9.Распределенная обработка данных в КИС
РАСПРЕДЕЛЕННАЯ ОБРАБОТКА ДАННЫХ
В распределенных системах база данных состоит из нескольких частей – фрагментов, расположенных на разных узлах. При распределенной обработке данных (distributed processing) логические процессы базы данных также распределяются среди двух или более, физически независимых узлов компьютерной сети. Например, распределенная обработка может выполнять ввод/вывод данных, выборку и проверку данных на одном сервере, а затем на другом выпускать отчет на основе полученной информации. При этом следует понимать, что распределенная обработка данных, в общем случае, не требует распределенной базы данных, но распределенная база данных в обязательном порядке требует распределенной обработки информации.
Всостав системы управления РБД должны входить следующие компоненты:
1.серверы и рабочие станции (узлы), формирующие сетевую систему. Система РБД должна быть независимой от оборудования
2.компоненты сетевого оборудования и ПО каждой рабочей станции, при этом следует стремиться к тому, чтобы функции РБД могли выполняться на различных платформах
3.коммуникационные устройства, система управления РБД не должна зависеть от коммуникаций, то есть должна поддерживать несколько типов коммуникационных устройств
4.процессор транзакций (transaction processor TP), представляющий собой программный компонент, находящийся на каждом компьютере системы, где выполняется запрос данных. TP называют также менеджером транзакций (transaction manager TM)
5.процессор данных (data processor DP), представляющий собой программный компонент, находящийся на каждом компьютере системы, где хранятся и извлекаются данные. DP также называют менеджером данных (data manager DM). Процессор данных может представлять собой централизованную СУБД
Связь между DP и TP поддерживается протоколами. Протоколы определяют то, как система РБД:
1.организует интерфейс с сетью передачи данных и команд между DP и ТP
2.синхронизирует все данные, полученные от DP (сторона TP) и маршрутизирует полученные данные на соответствующие TP (сторона DP)
3.обеспечивает функции общего управления БД в распределенной среде (безопасность,
управление параллельным выполнением, создание резервных копий и восстановление) Процессоры DP и TP могут размещаться на одном и том же компьютере, позволяя конечным пользователям получать доступ к локальным и глобальным данным, не заботясь об их местонахождении
Для распределенных баз данных свойственны следующие характеристики:
1.РБД – это логически связанные, разделяемые на некоторое количество фрагментов, данные
2.фрагменты распределяются по разным узлам, связанные между собой сетевыми коммуникациями
3.в обязательном порядке предусмотрена репликация фрагментов
4.доступ к данным на каждом узле происходит под управлением СУБД, которая на каждом узле должна поддерживать работу как локальных, так и глобальных приложений
Основные требования к распределенной обработке данных:
1.прозрачность относительно расположения данных СУБД должна представлять все данные так, как, если бы они были локальными
24
2.гетерогенность системы СУБД должна работать с данными, которые хранятся в системах с различной архитектурой и производительностью
3.прозрачность относительно сети СУБД должна одинаково работать в условиях разнородных сетей
4.поддержка распределенных запросов пользователь должен иметь возможность работать с данными из любых баз, даже если они размещены в разных подсистемах
5.поддержка распределенных изменений пользователь должен иметь возможность изменять данные в любых базах, на доступ к которым у него есть права, даже если эти базы размещены в разных подсистемах
6.поддержка распределенных транзакций СУБД должна выполнять транзакции,
выходящие за рамки одной вычислительной системы, и поддерживать целостность распределенной БД даже при возникновении отказов, как в отдельных системах, так и в сети
7.безопасность СУБД должна обеспечивать защиту всей распределенной БД от НСД
8.универсальность доступа СУБД должна обеспечивать единую методику доступа ко всем данным
25
10. Распределенный запрос в РБД КИС
РАСПРЕДЕЛЕННЫЙ ЗАПРОС
Распределенный запрос позволяет получить данные из разнородных источников, то есть от нескольких узлов DP (процессор данных). Для однократного выполнения распределенного запроса используют динамическое подключение к серверу-источнику данных (путем вызова специального контактного запроса с использованием функций opendatasource или opendataset). Как правило, для многократного выполнения распределенного запроса используют технологию связанного (или прилинкованного) сервера. Это простой и эффективный способ объединения серверов РБД.
Выполнение запроса начинается с его компиляции. Рассмотрим общую схему распределенной
компиляции.
Будем называть главным узлом тот узел сети, в котором инициирован процесс компиляции предложения SQL, и дополнительными узлами - те узлы, которые вовлекаются в этот процесс в ходе его выполнения. На самом низком уровне процесс компиляции можно разбить на следующие фазы:
1.В главном узле производится грамматический разбор предложения SQL с построением внутреннего представления запроса в виде дерева. На основе информации из локального каталога главного узла и удаленных каталогов дополнительных узлов производится замена имен объектов, фигурирующих в запросе, на их системные идентификаторы.
2.В главном узле генерируется глобальный план выполнения запроса, в котором учитывается лишь порядок взаимодействия узлов при реальном выполнении запроса. Для выработки глобального плана используется расширение техники оптимизации, применяемой в СУБД. Глобальный план отображается в преобразованном соответствующим образом дереве запроса.
3.Если в глобальном плане выполнения запроса участвуют дополнительные узлы, производится его декомпозиция на части, каждую из которых можно выполнить на одном узле (например, локальная фильтрация отношения в соответствии с заданным в условии выборки логическим ограничением). Соответствующие части запроса (во внутреннем представлении) рассылаются на дополнительные узлы.
4.На каждом узле, участвующем в глобальном плане выполнения запроса (главном и дополнительных), исполняется завершающая стадия компиляции. Эта стадия включает, по существу, две последние фазы процесса компиляции: оптимизацию и генерацию машинных кодов. При этом производится проверка прав пользователя, от имени которого производится компиляция, на выполнение соответствующих действий; осуществляется локальная оптимизация обрабатываемой части запроса, и, наконец, производится генерация кода.
Очевидно, что распределенное размещение данных и возможная их репликация, усложняют доступ к данным. Для устранения связанных с этим проблем и обеспечения приемлемой производительности системы, СУБД использует технологию оптимизации запросов. Целью оптимизации является минимизация общих затрат, связанных с выполнением запроса. Затраты зависят от следующих факторов:
1.времени доступа при выполнении операций ввода/вывода физических данных на диске
2.коммуникаций передачи данных между узлами в системе РБД
3.нагрузки CPU (центрального процессора)
Хотя затраты часто разделяют на коммуникационные затраты и затраты на обработку, на самом деле их очень трудно отделить друг от друга. Не все алгоритмы оптимизации используют одинаковые параметры и не все алгоритмы присваивают одинаковые веса этим параметрам. Например, некоторые
26
алгоритмы минимизируют общее время, другие - время коммуникаций, а третьи не принимают в расчет время работы CPU, считая эти затраты незначительными по сравнению с другими расходами. Чтобы оценить оптимизацию запроса, следует понимать, что процессор транзакций TP должен получить данные от процессора данных DP, синхронизировать их, скомпоновать ответ и предоставить его конечному пользователю или приложению. Хотя этот процесс является стандартным, необходимо учитывать, что запрос может выполняться на нескольких узлах. Время отклика узлов не всегда легко определить, поскольку некоторые узлы могут выполнить свою часть запроса быстрее других.
Большинство алгоритмов оптимизации запросов основаны на двух принципах:
1.выбор оптимального порядка выполнения
2.выбор узлов, к которым необходимо получить доступ для минимизации стоимости коммуникаций
На основе этих двух принципов алгоритм оптимизации можно оценить по режиму его работы или
расчетному времени оптимизации.
Режим работы может быть ручным или автоматическим. Автоматическая оптимизация запроса означает, что СУБД сама находит наиболее эффективный путь доступа без вмешательства пользователя. Ручная оптимизация запроса предполагает, что оптимизация и исполнение определяются программистом. Автоматическая оптимизация запроса более предпочтительна с точки зрения пользователя, однако при этом могут возрасти непроизводительные издержки СУБД.
По времени выполнения оптимизации алгоритмы подразделяются на статические и динамические.
Статическая оптимизация запроса выполняется во время компиляции. Такой подход применяется в том случае, если SQL-операторы встроены в процедурный язык программирования. Когда программа передается СУБД для компиляции, создается план доступа к БД. При выполнении программы СУБД использует этот план для доступа к БД.
Динамическая оптимизация запроса производится на этапе его выполнения. Стратегия доступа к БД динамически определяется СУБД при выполнении программы на основе самой последней информации о БД. Хотя динамическая оптимизация запроса является более эффективной, затраты на нее определяются стоимостью выполнения всех ее процессов. Наилучшая стратегия определяется каждый раз при выполнении запроса, а это может происходить несколько раз в одной программе.
Наконец, технологии оптимизации запросов различаются в зависимости от типа информации, используемой для оптимизации запроса. Например, оптимизация запросов может быть основана на
статистических алгоритмах или на алгоритмах, использующих определенные правила.
Статистические алгоритмы оптимизации запросов используют статистическую информацию о БД – размер БД, число записей, среднее время доступа, число обработанных запросов, число пользователей с определенными правами доступа и т.д. Эта статистическая информация используется СУБД для определения наилучшей стратегии. Статистику можно вести в автоматическом и ручном режиме. В автоматическом – СУБД ведет и обновляет статистику после каждого доступа к данным. В ручном режиме создания статистики ее необходимо периодически обновлять при помощи специальных утилит (например, RUNSTUT)
Алгоритм оптимизации запроса на основе правил основан на наборе определенных администратором правил, определяющих наилучшую стратегию запросов. Эти правила носят общий характер и устанавливаются администратором БД.
27
11. Характеристики и требования к транзакциям
При выполнении транзакции в любом режиме система управления базами данных должна придерживаться определенных правил обработки набора команд, входящих в транзакцию. В частности, разработано четыре правила, известные как требования ACID, они гарантируют правильность и надежность работы системы.
Одним из наиболее распространённых наборов требований к транзакциям и транзакционным системам является набор ACID (Atomicity, Consistency, Isolation, Durability).
ACID-свойства транзакций
Характеристики транзакций описываются в терминах ACID.
Atomicity, Consistency, Isolation, Durability – неделимость(атомарность),
согласованность(целостность), изолированность, устойчивость(живучесть).
Транзакция неделима в том смысле, что представляет собой единое целое. Все ее компоненты либо имеют место, либо нет. Не бывает частичной транзакции. Если может быть выполнена лишь часть транзакции, она отклоняется.
Транзакция является согласованной, потому что не нарушает бизнес-логику и отношения между элементами данных, что обеспечивает целостность данных. Это свойство очень важно при разработке клиент-серверных систем, поскольку в хранилище данных поступает большое количество транзакций от разных подсистем и объектов. Если хотя бы одна из них нарушит целостность данных, то все остальные могут выдать неверные результаты.
Транзакция всегда изолирована, поскольку ее результаты самодостаточны. Они не зависят от предыдущих или последующих транзакций – это свойство называется сериализуемостью и означает, что транзакции в последовательности независимы (каждая транзакций отделена от эффекта других транзакций).
Транзакция устойчива. После своего завершения она сохраняется в системе и выполняется фиксация транзакции, означающая, что ее действие постоянно даже при сбое системы. При этом подразумевается некая форма хранения информации в постоянной памяти как часть транзакции. Ядро базы данных должно быть спроектировано так, чтобы даже в случае выхода из строя устройства данных, БД можно было восстановить до состояния последней подтвержденной перед сбоем транзакции.
Указанные выше правила выполняет СУБД-сервер.
28
12.Распределенная транзакция в РБД КИС
РАСПРЕДЕЛЕННАЯ ТРАНЗАКЦИЯ
Транзакции – основной инструмент управления параллельными процессами обработки данных в корпоративных приложениях.
Под транзакцией понимается неделимая с точки зрения воздействия на БД последовательность операторов манипулирования данными (чтения, удаления, вставки, модификации), приводящая к одному из двух возможных результатов: либо последовательность выполняется, если все операторы выполнены, либо вся транзакция откатывается, если хотя бы один оператор не может быть успешно выполнен. Таким образом транзакция переводит базу данных из одного целостного состояния в другое. Механизм транзакций гарантирует целостность информации в базе данных.
Поддержание механизма транзакций – показатель уровня развитости СУБД и одновременно является основой обеспечения целостности БД. Транзакции также составляют основу изолированности в многопользовательских системах, где с одной БД параллельно могут работать несколько пользователей или прикладных программ. Одна из основных задач СУБД – обеспечение изолированности, т.е. создание такого режима функционирования, при котором каждому пользователю казалось бы, что БД доступна только ему. Такую задачу СУБД принято называть параллелизмом транзакций.
Большинство выполняемых действий над данными производится в теле транзакций. По умолчанию каждая SQL-команда выполняется как самостоятельная транзакция.
При необходимости программист может явно указать ее начало (BEGIN TRANSACTION) и конец
(COMMIT TRANSACTION или ROLLBACK TRANSACTION), чтобы иметь возможность включить в нее несколько команд. При явном режиме определения транзакции пользователь должен сам заботиться о соблюдении в рамках приложения логической целостности данных. Именно пользователь решает, какие операторы должны выполняться в рамках одной транзакции, а какие могут быть представлены несколькими, последовательно выполняемыми транзакциями: операции, которые должны выполняться, как единое целое (например, списание суммы с одного счета и зачисление на другой), следует объединить в одну транзакцию. И наоборот, если операции между собой логически не связаны и откат одной операции не оказывает влияние на результаты другой, необходимо выполнять их в рамках различных транзакций.
В режиме автоматически фиксируемых транзакций неявная транзакция стартует автоматически (SQLоператоры, которые являются началом новой транзакции в неявном режиме: ALTER TABLE, CREATE,
DELETE, DROP, FETCH, GRANT, INSERT, OPEN, REVOKE, SELECT, TRUNCATE TABLE, UPDATE),
а по завершении также автоматически подтверждается или отменяется. Если выполнение SQLоператора заканчивается успешно, произведенные им изменения будут зафиксированы. Если же при выполнении оператора произошла ошибка, то для всех произведенных им изменений будет инициирован откат. По умолчанию SQL Server работает в режиме автоматически фиксируемых транзакций. В дальнейшем пользователь может установить на уровне сеанса режим явных транзакций.
Допустимой считается ситуация, когда внутри одной транзакции запускается еще одна транзакция. Вложенной транзакцией называется транзакция, выполнение которой инициируется из тела активной транзакции. Использование вложенных транзакций доступно только в режиме явных транзакций. Как правило, к вложенным транзакциям прибегают в случае, когда необходимо реализовать выполнение хранимой процедуры в рамках уже активной транзакции. Для создания вложенной транзакции не нужны какие-либо дополнительные команды: пользователь просто начинает новую транзакцию в теле активной. Фиксация всех вложенных транзакций откладывается до завершения вызвавшей их транзакции (главной). Если для главной транзакции выполняется откат, то для всех затронутых при
29
этом вложенных транзакций, также будет выполнен откат. Фиксация всех вложенных транзакций будет выполнена при фиксации главной.
Не каждая SQL-операция может быть выполнена в рамках транзакции. Не выполняются те операции, для которых невозможно выполнить откат:
CREATE DATABASE, ALTER DATABASE, DROP DATABASE, BACKUP (резервное копирование),
RESTORE (восстановление), RECONFIGURE (изменение параметров настройки сервера), UPDATE STATISICS (обновление статистики).
При выполнении транзакции в любом режиме система управления базами данных должна придерживаться определенных правил обработки набора команд, входящих в транзакцию. В частности, разработано четыре правила, известные как требования ACID, они гарантируют правильность и надежность работы системы.
ACID-свойства транзакций
Характеристики транзакций описываются в терминах ACID.
Atomicity, Consistency, Isolation, Durability – неделимость(атомарность),
согласованность(целостность), изолированность, устойчивость(живучесть).
Транзакция неделима в том смысле, что представляет собой единое целое. Все ее компоненты либо имеют место, либо нет. Не бывает частичной транзакции. Если может быть выполнена лишь часть транзакции, она отклоняется.
Транзакция является согласованной, потому что не нарушает бизнес-логику и отношения между элементами данных, что обеспечивает целостность данных. Это свойство очень важно при разработке клиент-серверных систем, поскольку в хранилище данных поступает большое количество транзакций от разных подсистем и объектов. Если хотя бы одна из них нарушит целостность данных, то все остальные могут выдать неверные результаты.
Транзакция всегда изолирована, поскольку ее результаты самодостаточны. Они не зависят от предыдущих или последующих транзакций – это свойство называется сериализуемостью и означает, что транзакции в последовательности независимы (каждая транзакций отделена от эффекта других транзакций).
Транзакция устойчива. После своего завершения она сохраняется в системе и выполняется фиксация транзакции, означающая, что ее действие постоянно даже при сбое системы. При этом подразумевается некая форма хранения информации в постоянной памяти как часть транзакции. Ядро базы данных должно быть спроектировано так, чтобы даже в случае выхода из строя устройства данных, БД можно было восстановить до состояния последней подтвержденной перед сбоем транзакции.
Указанные выше правила выполняет СУБД-сервер.
СБОИ ТРАНЗАКЦИЙ
Изолированность между транзакциями может быть далеко несовершенной, и это может проявляться,
как:
грязное чтение;
неповторяющееся чтение;
фантомные строки.
30