Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 5)

(

номер1 IN NUMBER, -- дебет

номер2 IN NUMBER, -- кредит

сумма IN NUMBER

) IS

остаток1 NUMBER;

CURSOR курсор -- объявление курсора

(

номер_счёта_1 NUMBER,

номер_счёта_2 NUMBER,

) IS

SELECT номер, остаток

FROM счёт

WHERE номер = номер_счёта_1

OR номер = номер_счёта_2

FOR UPDATE OF остаток;

запись курсор%ROWTYPE; -- переменная того же типа, что и запись курсора: номер, остаток

BEGIN -- начало исполнительной части

OPEN курсор(номер1, номер2);

LOOP -- вход в цикл

FETCH курсор INTO запись;

EXIT WHEN курсор%NOTFOUND; -- выход из цикла, если записей больше нет

IF запис.номер = номер.1 THEN остаток1 = запись.остаток - сумма;

ELSE остаток1 = запись.остаток + сумма;

END IF;

UPDATE счёт SET остаток = остаток1;

WHERE CURRENT OF курсор;

END LOOP;

CLOSE CURSOR; -- после этого оператора доступ к записям курсора становится недоступен

COMMIT;

END;

Схема блокировки и обновления записи:

Первый процесс открывает курсор. На сервере выполняется оператор SELECT. Он найдёт записи с номерами 100 и 1001 и заблокирует их, так как указано FOR UPDATE.

При открытии курсора вторым процессом система найдёт (опять выполнится SELECT) записи 100 и 1001, но процесс перейдёт в состояние ожидания, так как записи уже заблокированы.

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

По оператору COMMIT данные из сегмента отказа переписываются в БД, то есть становятся видны всем пользователям. Записи с номерами 100 и 1001 разблокируются.

Теперь второй процесс может работать с записями 100 и 1001, тут повторяется всё то же самое.

Ведение транзакций

Логическая транзакция - совокупность изменений в БД, которые либо должны быть зафиксированы все, либо ни одно. Атомарная операция.

Схема ведения транзакций:

Предположим, Процесс 1 выполняет обновление данных, а Процесс 2 - чтение.

По оператору UPDATE в сегменте отката запоминаются записи до и после обновления. По оператору COMMIT система выполняет следующие действия:

1. записи после обновления переписываются в общесистемный буфер (в БД) и становятся видны всем пользователям. В заголовок записи вносится время её обновления;

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

Лекция №11 - Восстановление БД после сбоя

Особенности разработки приложений для работы с БД в сети

Ведение версий записи

Она же блокировка по чтению.

После выполнения COMMIT записи из сегмента отката удаляются не сразу. Это связано с ведением версий записей.

Предположим, что в момент T1 выполняется SELECT и проверяется время обновления записи. Если T1>t1, то запись читается из БД. Если T1<t1=tобновления, то записи читаются из сегмента отката (до обновления). Представленный механизм ведения версии записей обеспечивает целостность чтения данных в интервале T1−T2.

Схема восстановления данных после сбоя

При восстановлении данных используются два системных файла:

• журнал транзакций;

• сегмент отката.

В журнале транзакции сохраняются полные транзакции (записываются записи после обновления). В этом же журнале записываются метки по перезаписи всех "грязных" блоков.

В сегменте отката для каждой незавершённой транзакции записываются записи до и после обновления.

Предположим, что произошёл сбой. После восстановления выполняются следующие действия:

1. докат системы - ищется последняя метка о перезаписи всех "грязных" блоков на диск, и начиная с этой отметки и до конца файла читаются записи полных транзакций, и они перезаписываются в БД;

2. откат незавершённых транзакций - потому что в БД могли попасть записи незавершённых транзакций. Из сегмента отката с конца транзакции читаются записи до обновления и записываются в БД.

По оператору COMMIT сначала необходимо записать обновлённые записи транзакции в БД, а только потом эти записи записать в журнал транзакций.

Пример восстановления БД после сбоя

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

Перезапись "грязных" блоков из общесистемного буфера на диск выполняется в следующей строгой последовательности:

1. блоки сегмента отката;

2. блоки журнала транзакций;

3. блоки БД.

Обработка тупиковых ситуаций

Предположим, что процедура проверки реализутся иначе чем в прошлой лекции:

проводка(счёт1, счёт2, остаток)

-- дебет

UPDATE счёт1 -- запись автоматически блокируется до завершения операции (до COMMIT)

...

-- кредит

UPDATE счёт2 -- запись автоматически блокируется до завершения операции (до COMMIT)

...

COMMIT;

При одновременном обращении к этой процедуре двух процессов возможно возникновение тупиковой ситуации.

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

Лекция №12 - Анализ и выбор архитектуры

Анализ и выбор архитектуры распределённой системы

При выборе архитектуры решаются следующие задачи:

• выбор модели доступа к данным;

• выбор общесистемного ПО - которое покупается, а не разрабатывается самостоятельно;

• выбор комплекса технических средств и топологии - рабочие станции, сервера, коммуникационное оборудование;

• анализ и выбор метода тиражирования данных - репликация.

Модели доступа к данным

В настоящее время используются следующие:

• модель файлового сервера;

• модель сервера БД;

• модель сервера приложений;

• модель доступа по технологии Интернет/Интранет;

• использование CORBA/DCOM.

Модель файлового сервера

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

СУБД этой модели:

• Borland dBase;

• CAI CA-Clipper;

• Microsoft FoxPro;

• Borland Paradox;

• Microsoft Access.

Преимущества:

• дешёвые;

• реализация системы не зависит от сетевой ОС.

Недостатки:

• часто перегружают каналы связи, так как передаются не только записи таблиц БД, но и промежуточные (индексы, данные сортировки). Файловый сервер выступает в качестве удалённого разделяемого диска;

• не поддерживает распределённую обработку - СУБД не выполняет оптимизацию SQL запроса;

• ядро СУБД дублируется на всех рабочих станциях, то есть нерационально используется оперативная память;

• блокировка и ведение транзакций осуществляется средствами ОС.

Модель сервера БД

Пользователь жмёт кнопку, запускается обработчик нажатия. Если есть SQL оператор, то он не выполняется на рабочей станции, а передаётся на сервер БД. Там он разбирается и выполняется. При этом доступ к файлам БД осуществляется через внутреннюю шину сервера. Результаты возвращаются в программу, и результаты отображаются на экране.

Можно разрабатывать прикладные программы, которые будут выполняться в СУБД: триггеры и хранимые процедуры.

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

Хранимая процедура - выполняется ядром СУБД, пишется прикладным программистом. Может выполнять обращение к другим процедурам, а также вызываться из прикладных программ.

СУБД этой модели:

• Oracle;

• Microsoft SQL Server;

• SyBase;

• Informix;

• Centure (Gupta).

Преимущества:

• большая производительность, чем у файл-серверной модели;

• поддерживают распределённую обработку - есть оптимизация SQL запросов;

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

Недостатки:

• СУБД намного дороже, чем СУБД из файл-серверной модели;

• сложны в освоении из-за обилия возможностей, требуется определённая квалификация администраторов;

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

• для проявления преимуществ оптимизации SQL запросов в сети должно быть несколько серверов.

Модель сервера приложений

Пользователь жмёт кнопку, на сервере приложений запускается соответствующий сервис (например, A). Если есть SQL оператор, то он передаётся на сервер БД. Там он разбирается и выполняется. При этом доступ к файлам БД осуществляется через внутреннюю шину сервера. Результаты сервиса возвращаются в рабочую станцию и там отображаются на экране.

СУБД этой модели:

• BEA Systems Tuxedo;

• IBM CICS.

Преимущества:

• возможность централизованного администрирования приложений;

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

• можно уменьшить число лицензий на СУБД.

Недостатки:

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

Модель доступа по технологии Интернет/Интранет

В рамках этой модели используются следующие варианты:

• доступ к данным из CGI и API программ;

• доступ к данным из Java-апплетов и управляющих элементов ActiveX.

Лекция №13 - Анализ и выбор архитектуры (продолжение)

Анализ и выбор архитектуры распределённой системы

Модели доступа к данным

Модель доступа по технологии Интернет/Интранет

В рамках этой модели используются следующие варианты:

• доступ к данным из CGI и API программ;

• доступ к данным из Java-апплетов и управляющих элементов ActiveX.

CGI и API

Браузер отображает страницу, пользователь заполняет поля формы и жмёт submit, который связан с определённой CGI-программой. Программы выполняется на сервере, обращаясь к ODBC, который обращается к БД. Результаты выполнения запросов возвращаются к CGI-программе, которая генерирует новый HTML и отдаёт его на рабочую станцию пользователю в веб-браузер.

Преимущества CGI:

• веб-сервер выступает в роли сервера-приложений (централизованное администрирование CGI-программ);

• CGI-интерфейс универсален и реализован во всех веб-серверах;

• для доступа к данным подходит любой веб-браузер.

Недостатки CGI:

• каждая CGI-программа (даже самая крохотная) выполняется как задача на уровне ОС. Инициализация каждой задачи и переключение между задачами занимает много времени, так как требуется переключение между блоками управления страницей;

• CGI-программы не поддерживают контекст связи с БД. БД открывается при каждом вызове очередной (да и той же самой) CGI-программы.

Для устранения недостатков CGI используется API-интерфейс (активные страницы):

• ASP;

• PHP;

• JSP.

В отличие от CGI выполняются как потоки в рамках одной задачи - не создают новые задачи в рамках ОС.

Преимущества API:

• выполняются быстрее, чем CGI;

• позволяют поддерживать контекст соединения с БД.

Недостатки API:

• программы разных производителей несовместимы между собой;

• платформозависимы.

Java-апплеты и ActiveX

Характеристики

Список файлов лекций