Руководство администратора баз данных Inrformix.
Добавить в закладки К обложке
- 1. Теоретические основы. - Страница 1
- 1.1.1 Основные функции СУБД - Страница 2
- 1.1.2 Типовая организация современной СУБД - Страница 5
- 1.2 Понятие архитектуры клиент-сервер. - Страница 6
- 2. Теоретические основы СУБД сервера Informix OnLine v.7.X - Страница 7
- 2.1.1 Описание продуктов Informix - Страница 8
- 2.1.2 Типовые конфигурации - Страница 9
- 2.2 Архитектура СУБД сервера Informix OnLine v.7.X - Страница 10
- 2.2.1 . Динамическая масштабируемая архитектура - Страница 11
- 2.2.1.1 Потоки - Страница 12
- 2.2.1.2 Виртуальные процессоры - Страница 13
- 2.2.1.3 Планирование потоков - Страница 14
- 2.2.1.4 Разделение потоков между виртуальными процессорами. - Страница 15
- 2.2.1.5 Экономия памяти и других ресурсов - Страница 16
- 2.2.2 Организация разделяемой памяти - Страница 17
- 2.2.3 Организация операций обмена с дисками - Страница 18
- 2.2.3.1 Управление дисковой памятью - Страница 19
- 2.2.3.2 Асинхронный ввод-вывод - Страница 20
- 2.2.3.3 Опережающее чтение - Страница 21
- 2.2.4 Поддержка фрагментации таблиц и индексов - Страница 22
- 2.2.5 Параллельная обработка запросов - Страница 23
- 2.2.5.1 На чем основана технология PDQ - Страница 24
- 2.2.5.2 Итераторы - Страница 25
- 2.2.5.3 Примеры применения параллелизма - Страница 27
- 2.2.5.4 Баланс между OLTP и DSS-приложениями - Страница 28
- 2.2.6 Оптимизатор выполнения запросов по стоимости - Страница 29
- 2.2.7 Средства обеспечения надежности - Страница 30
- 2.2.7.1 . Зеркалирование дисковых областей - Страница 31
- 2.2.7.2 Тиражирование - Страница 32
- 2.2.7.3 Быстрое восстановление при включении системы - Страница 33
- 2.2.7.4 Архивирование и восстановление данных - Страница 34
- 2.2.8 Динамическое администрирование - Страница 35
- 2.2.8.1 Интерфейс мониторинга системы - Страница 36
- 2.2.8.2 Утилита DB/Cockpit - Страница 37
- 2.2.8.3 Утилита OnPerf - Страница 38
- 2.2.8.4 Утилита параллельной загрузки - Страница 39
- 2.2.9 Распределенные вычисления - Страница 40
- 2.2.9.1 Взаимодействие клиент-сервер - Страница 41
- 2.2.9.2 Прозрачность расположения данных - Страница 42
- 2.2.9.3 Распределенные базы данных и протокол двухфазовой фиксации транзакций - Страница 43
- 2.2.10 Поддержка национальных языков - Страница 44
- 2.2.11 Средства безопасности класса С2 - Страница 45
- 2.3 Дополнительные компоненты компании Informix для выполнения специфических задач. - Страница 46
- 2.3.1 Informix-Enterprise Gateway 7.1 - Страница 47
- 2.3.2 Технология и компоненты EDA/SQL - Страница 48
- 2.3.2.1 EDA API/SQL - Страница 49
- 2.3.2.2 EDA/Link - Страница 50
- 2.3.2.3 EDA/SQL Server - Страница 51
- 2.3.2.4 EDA/Data Drivers - Страница 52
- 2.3.3 Возможности Enterprise Gateway - Страница 53
- 2.3.3.1 Прозрачный доступ для чтения и записи - Страница 54
- 2.3.3.2 Распределенные соединения - Страница 55
- 2.3.3.3 Конфигурирование Enterprise Gateway - Страница 56
- 2.3.3.4 Безопасность - Страница 57
- 2.3.4 Библиотеки сопряжения сервера Informix-OnLine DS с менеджерами транзакций: Informix-TP/XA и Informix-TP/TOOLKIT - Страница 58
- 2.4 Заключение - Страница 59
- 2.5 Литература - Страница 61
2.2.9.3 Распределенные базы данных и протокол двухфазовой фиксации транзакций
INFORMIX-OnLine DS поддерживает запросы к распределенным базам данных и автоматически применяет протокол двухфазовой фиксации для транзакций, которые модифицируют данные более чем на одном сервере баз данных, например:
CONNECT TO stores@italy
BEGIN WORK
UPDATE stores:manufact SET manu_code = 'SHM'
WHERE manu_name = 'Shimara'
INSERT INTO stores@france:manufact
VALUES ('SHM', 'Shimara', 30)
INSERT INTO stores@australia:manufact
VALUES ('SHM', 'Shimara', 30)
COMMIT WORK
Здесь BEGIN WORK, COMMIT WORK - инструкции, отмечающие начало и конец транзакции, stores - имя базы данных, italy, france, australia - имена серверов.
Внешне такая транзакция выглядит как транзакция в локальной базе. На самом деле она состоит из ряда локальных транзакций, каждая из которых может быть либо зафиксирована, либо прервана. Распределенная транзакция фиксируется только в том случае, если зафиксированы все локальные транзакции. Если хотя бы одна из локальных транзакций была прервана, то необходимо прервать и все остальные.
Каждая транзакция, реализуемая согласно протоколу двухфазовой фиксации, выполняется под управлением одного сервера, называемого координатором. В качестве координатора выбирается текущий сервер. В примере выше это будет сервер italy, поскольку к нему относится оператор CONNECT.
Первая фаза начинается с того, что координатор, получив от пользователя инструкцию COMMIT WORK, рассылает серверамучастникам сообщения о том, что нужно подготовиться к фиксации. Каждый участник решает, может ли он зафиксировать свою часть транзакции, и посылает соответствующее сообщение координатору.
Вторая фаза начинается, когда координатор, получив сообщения от участников, принимает решение о фиксации или откате транзакции. Если все участники прислали положительные ответы, то координатор посылает им сообщения о том, чтобы они зафиксировали свои локальные транзакции. Если хотя бы один участник прислал отрицательный ответ или вообще не прислал ответа, то координатор прерывает транзакцию и посылает всем участникам сообщение о том, что транзакцию нужно откатить.
Процедура восстановленияЕсли один из серверов вышел из строя до завершения протокола двухфазовой фиксации транзакции, то необходимо восстановить совокупную согласованность распределенных данных. Для этой цели в INFORMIX-OnLine DS предусмотрены специальные процедуры восстановления, которые автоматически выполняют все необходимые действия с учетом того, в какой ситуации и на каком сервере произошел отказ. Единственное, что должен сделать в этой ситуации администратор - это перезапустить сервер.
Оптимизация транзакцийПри обработке распределенных транзакций INFORMIX-OnLine DS использует метод оптимизации, основанный на предположении о прерывании транзакции (presumed abort optimization). Смысл его заключается в том, что, если в журнале транзакций отсутствует информация о некоторой глобальной транзакции, то считается, что она прервана. Этот метод позволяет сократить число операций обмена с диском, а также число сообщений, пересылаемых между серверами.
Рассматриваемый метод оптимизации позволяет исключить два шага из классического протокола двухфазовой фиксации транзакций. Во-первых, координатор не производит синхронизированной записи на диск о начале транзакции. Синхронизированная запись на диск - дорогостоящая операция, и координатор производит ее только в двух случаях - когда все участники присылают сообщения "могу зафиксировать", и когда все участники присылают сообщения "транзакция зафиксирована". Если происходит отказ координатора до принятия решения о фиксации, и в журнале отсутствует информация о данной глобальной транзакции, то все участники считают, что она прервана, и откатывают свои части транзакции. Во-вторых, оптимизация достигается тем, что участники не должны посылать координатору подтверждения об откате транзакции. Координатор, если он принял решение об откате, рассылает участникам соответствующие сообщения, и сразу же откатывает глобальную транзакцию, изымая информацию о ней из свой разделяемой памяти.
Разрешение тупиковых ситуацийТупиковая ситуация возникает, например, когда работают два пользователя, и каждый блокирует объект данных, необходимый другому. Каждому из них, для того чтобы завершить обработку и разблокировать свой объект, необходимо получить доступ к объекту, заблокированному другим пользователем. Если оба объекта находятся на одном сервере, то INFORMIX-OnLine DS самостоятельно обнаруживает и предотвращает такие ситуации. При обработке распределенных запросов используется параметр конфигурации DEADLOCK_TIMEOUT - время, в течение которого INFORMIX-OnLine DS ожидает разблокирования объекта данных. По истечении этого периода одному из пользователей выдается сообщение об ошибке.