ЭЛЕКТРОННАЯ БИБЛИОТЕКА КОАПП
Сборники Художественной, Технической, Справочной, Английской, Нормативной, Исторической, и др. литературы.






        ГЛАВА 8           СТРУКТУРЫ ПАМЯТИ ORACLE

             Own only what you can always carry with you; know
             languages, know countries, know people. Let your
             memory be your travel bag.
                          Alexander Solzhenitsyn

             When I was younger I could remember anything, whether
             it had happened or not.
                          Mark Twain

Эта глава описывает различные направления использования памяти системой ORACLE,
включая  области пользователей и глобальные области. Разделы включают в себя:
    * общее описание использования памяти системой ORACLE
    * Системная Глобальная Область (SGA)
    * Программные Глобальные Области (PGA)
    * области контекста
    * программные области

Для более подробной информации о требованиях  и использовании памяти обратитесь
к "Руководству пользователя по инсталяции" для Вашей операционной системы.
Параметры, содержащиеся в файле INIT.  ORA, описанные в приложении D,  также
влияют на требования памяти для системы ORACLE.

        Как ORACLE использует память ?


    ORACLE RDBMS использует память в следующих целях:
* для хранения выполнимого программного кода
* для хранения  данных,  необходимых  в  процессе  выполнения программ
  (например - текущего состояния запроса, для которого выбираются строки)
* для запоминания информации, которая разделяется или используется для связи
  между процессами ORACLE (например - для фиксации информации)
* для запоминания информации, которая передается между оперативной и периферий-
  ной памятью (например - блоки данных базы,  передающиеся с диска в программу)

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

Виртуальная память имитирует  память  за  счет  использования комбинации
реальной (основной) и вторичной памяти (обычно - дисков).  Операционная система
позволяет пользовательским программам обращается к виртуальной памяти, как
будто это реальная память.

        Области программного кода

Области программного  кода  - это части основной памяти,  используемые для
хранения программных  кодов,  которые  исполняются или будут исполняться.
Программный код RDBMS хранится в области, обычно отличной от области прикладных
программ  (более  защищенной).

    Размер

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

                                    -- 89 --



    Только читаемая, разделяемая и не разделяемая

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

        System Global Area (SGA)

Глобальная область  системы  (обычно называемая SGA) содержит данные и
управляющую информацию для одного экземпляра  ORACLE. Вы могли слышать также
название Shared Global Area (разделяемая глобальная область), эти термины
эквивалентны.

SGA распределяется при запуске экземпляра ORACLE  и удаляется при остановке.
Текущим  пользователям базы необходимо видеть текущие копии информации из SGA.

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

* информацию, передаваемую между процессами (например -  информацию фиксации)
* буферы базы данных
* информацию словаря данных (хранимую в кеше словаря).

    Для оптимальной работы в большинстве систем SGA должна быть в постоянной
готовности в реальной памяти.  Если это не так, производительность системы
может  катастрофически снижаться,  так как части SGA участвуют в страничном
обмене между внешней  и основной памятью.

        Размер

    Размер SGA  определяется при старте экземпляра ORACLE и затем не меняется.
Для того,  чтобы посмотреть размер SGA после старта экземпляра, используйте
команду  SHOW SGA утилиты SQL*DBA.  (См.  Приложение В).

    Первичное определение размера SGA задается  при  варьировании параметров
файла INIT.ORA. Для обсуждения параметров, их назначения и влиянии на SGA
обратитесь к Приложению D.  Кроме того,  дополнительная информация,  зависящая о

        Разделяемось и возможность записи

    SGA как разделяемая,  так и "записываемая",  но в  нее  может писать
информацию только RDBMS.  На каждый экземпляр ORACLE распределяется одна SGA.

        Program Global Area (PGA)

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




                                    -- 90 --



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

        Размер

    Размер PGA может меняться,  но не динамически.  Он зависит от операционной
системы.  PGA распределяется в момент подключения пользователя; если требуемая
память не доступна, Вы получите сообщение  об ошибке.  Эта ошибка будет ошибкой
ORACLE из диапазона ошибок операционной системы.  Достаточно или нет памяти
для  регистрации, пользователь не может работать вне области PGA.

Следующие параметры  файла  INIT.ORA влияют на размер PGA для пользовательских
процессов:
    * OPEN_CURSORS
    * OPEN_LINKS
    * SAVEPOINTS
    * DB_FILES
    * LOG_FILES

    Размер области PGA для фоновых процессов (DBWR,  LGWR,  SMON, PMON и ARCH)
зависят от некоторых дополнительных параметров.

        Неразделяемость и возможность записи

PGA - это не разделяемая область с возможностью записи. Одна PGA распределяется
для каждого процесса пользователя.  PGA  может читаться и записываться
программами  ORACLE  для  единственного пользовательского процесса.

        Области контекста

    Каждый SQL  - оператор,  выданный пользовательским процессом, нуждается в
области контекста.  Область контекста - это  отдельная от PGA область памяти,
содержащая состояние одного оператора SQL.  Область контекста содержит все
структуры данных,  необходимые для выполнения оператора SQL, включая:
    * текст SQL - оператора
    * SQL - оператор в оттранслированном виде
    * одну  строку результата работы оператора и некоторые промежуточные значени
    * используемую для выполнения оператора информацию состоянии курсора
    * управляющую информацию для сортировки

    Термин "Область  контекста"  обычно  применяется  как синоним
термина "Курсор".  В Главе 10 обсуждается  различие  между  этими
терминами.

        Количество курсоров

Пользовательский процесс  может иметь несколько открытых курсоров (и, следова-
тельно, областей контекста); количество открытых курсоров устанавливается
параметром OPEN_CURSORS файла INIT.ORA.  Большое количество больших курсоров
хорошо работает при  использовании виртуальной памяти; при работе на реальной
памяти пользователь должен закрывать ненужные курсоры.

Если курсор не может быть открыт из-за ограничения  на  количество открытых
курсоров, можно сделать следующее:



                                    -- 91 --



    * увеличить значение параметра OPEN_CURSORS
    * увеличить CONTEXT_AREA
    * увеличить CONTEXT_INCR

Многие операторы требуют рекурсивных   курсоров   для  их выполнения. Например,
команда CREATE TABLE влечет за собой большого числа модификаций во многих
таблицах словаря данных (чтобы записать новые таблицы и столбцы).  Для таких
курсоров  выполняются рекурсивные вызовы; один курсор может выполнить несколько
вызовов.

        Размер курсора

    Области контекста сперва создаются  определенного  размера,  а затем
динамически  растут  по мере необходимости.  Таким образом, Вас редко будет
касаться размер памяти для контекста.

Общая память,  первоначально распределяемая для области  контекста,
устанавливается  параметром  CONTEXT_AREA файла INIT.ORA.  Для большинства
операционных систем по умолчанию  принимается 4К.  Написанные пользователем
программы  могут при  открытии  курсоров указывать иное значение памяти.

     ГЛАВА 9                  СТРУКТУРА ПРОЦЕССОВ ORACLE

             Solitude is fine but you need someone to tell you
             that solitude is fine.
                                 Honore de Balzac

Эта глава описывает различные  процессы,  которые  составляют систему ORACLE.
Вводятся некоторые термины и концепции:
    * процессы пользователя
    * фоновые процессы
    * однозадачные и двухзадачные системы ORACLE
    * системы с одним и несколькими процессами
    * программный интерфейс
    * драйверы протокола обмена

Эта глава  дает общее описание типов процессов,  используемых ORACLE RDBMS;
существующие ограничения и опции, зависящие от операционных систем.  За  более
конкретной информацией обратитесь к "Руководству пользователя по инсталяции"
для  Вашей операционной системы; более  подробная информация о драйверах
программного интерфейса дана в "Руководстве пользователя по SQL*Net".

          Что такое процесс ?

    Процесс -  это  "направляющая  нить" операционной системы,  а именно - это
механизм операционной системы, позволяющий выполнять серии шагов. Некоторые
операционные системы используют термин работа (job) или задача (task).  Обычно
процесс  имеет  собственную область памяти, в которой и работает.

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


                                    -- 92 --



    Таким образом, разделение ресурсов может увеличить производительность.

        Типы процессов системы ORACLE

    Система ORACLE имеет два основных типа процессов:

      процессы пользователя:

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

  процессы сервера:

    Процессы сервера  активируются другими процессами,  чтобы "от их имени"
    выполнялись действия

    Кроме того, существует два типа процессов - серверов:

  теневые процессы:

    Теневые процессы описываются далее в  этой  главе  в  разделе "Двухзадачная
система ORACLE и теневые процессы".  Каждым теневым процессом владеет процесс
пользователя (поэтому и термин - теневой)

  фоновые процессы:

Это стандартный набор процессов (ARCH,  DBWR,  LGWR,  PMON, SMON), используемый
в мульти-процессовых системах ORACLE. Они описаны в разделе "Фоновые процессы
ORACLE" этой главы. Фоновыми процессами не владеет ни один процесс пользовате-
ля, но они выполняют функции, в интересах всех пользователей системы.  Фоновые
процессы стартуют  при  старте  экземпляра ORACLE  и завершаются вместе с ним.

        Однозадачная и двухзадачная системы ORACLE

    Структура процессов  ORACLE RDBMS имеет два основных варианта в зависимости
от того,  как работают пользовательская программа и ORACLE: в одном или в
разделенных процессах.

    Некоторые операционные системы дают возможность выбора: однозадачный или
двухзадачный ORACLE.  Для детального обсуждения этих опций обратитесь к
"Руководству пользователя по инсталяции".

        Пользовательские процессы

    Пользовательские процессы существуют в любой системе. Пользовательский
процесс вызывается из прикладной программы,  такой как программа на Pro*C, или
из инструментального средства, такого как SQL*DBA. Пользовательский процесс
обычно создается, когда пользователь присоединяется к системе ORACLE с
терминала  или запускает пакетное задание.

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

        Однозадачный ORACLE




                                    -- 93 --



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

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

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

    Рисунок 9-1  иллюстрирует  соединение  между пользовательским процессом и
ORACLE в однозадачной системе.
            Ъ----Д    Ъ------------------------------------------ї
            і         і        П Р О Г Р А М М А                 і
            і         і                П О Л Ь З О В А Т Е Л Я   і
  Один      і         і                                          і
  процесс   і         і                                          і
  (для обеихі         Г------------------------------------------ґ
  программ) і         і             Программный                  і
            і         Г------------------------------------------ґ
            і         і                   интерфейс              і
            і         Г------------------------------------------ґ
            і         і        П Р О Г Р А М М А                 і
            і         і                     O R A C L E          і
            А------   А------------------------------------------Щ
         Рисунок 9-1 Однозадачная система на одном компьютере

        Двухзадачный ORACLE и теневые процессы

В двухзадачной системе ORACLE процесс самого  ORACLE  отделен от пользователь-
ского процесса.  Как и в однозадачной системе, программный интерфейс выполняет
функции взаимодействия между двумя программами. Однако в двухзадачном варианте
взаимодействие осуществляется с использованием механизма межпроцессных связей
операционной системы.

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

    Рисунок 9-2 иллюстрирует двухзадачную систему,  работающую на одном
процессоре.  Двухзадачный ORACLE  используется  также  и в SQL*Net,  когда
программа пользователь работает на локальном компьютере,  а  база данных - на
удаленном компьютере.  Как показано на Рис. 9-3, программный интерфейс также
поддерживает взаимосвязь между программами,  хотя протокол связи и программные
средства связи принадлежат операционной системе и зависят от инсталяции.

    Двухзадачность может быть также использована в некоторых приложениях, когда
многие присоединения к системе ORACLE могут быть использованы с единственной
базой.  Однозадачные  системы  иногда используются для целей отладки и работы
одного пользователя.
            Ъ----Д    Ъ------------------------------------------ї

                                    -- 94 --



  Процесс   і         і        П Р О Г Р А М М А                 і
  пользова- і         і                П О Л Ь З О В А Т Е Л Я   і
  теля      і         Г------------------------------------------ґ
            і         і          ^  Программный                  і
            А------   А----------Е--------------------Е----------Щ
                                 і                    і
            Ъ----Д    Ъ----------Е--------------------Е----------ї
            і         і                   интерфейс   V          і
            і         Г------------------------------------------ґ
  Теневой   і         і                                          і
  процесс   і         і        П Р О Г Р А М М А                 і
            і         і                     O R A C L E          і
            А------   А------------------------------------------Щ
             Рис. 9-2 Двухзадачная система на одном компьютере

              Ъ-- Ъ--------------------------------ї
  Процесс     і   і     ПРОГРАММА ПОЛЬЗОВАТЕЛЯ     і
  пользователяі   Г--------------------------------ґ
              і   і                 ^              Г----ї
              А-- А------------В----Е--------------Щ    і
                           Ъ--ДЕ----Б--Дї               і
                           і   v        Г--ї Драйверы   іПРОГРАМ-
  ЛОКАЛЬНАЯ МАШИНА         А----Д^------Щ  і взаимодей- іМНЫЙ
                                 і         і ствия      іИНТЕР-
 --------------------------------Е--------ДЕ------------Е----Д
                                 А--ї      і и Протокол іФЕЙС
  УДАЛЕННАЯ                Ъ--------v--Дї  і            і
       МАШИНА              і            Г--Щ            і
                           А--ДВ----Д^--Щ               і
                  Ъ------------Е----ДБ------------Дї    і
                  і            v                   Г----Щ
                  Г--------------------------------ґ
                  і        ПРОГРАММА ORACLE        і
                  А--------------------------------Щ
              Рис. 9-3 Двухзадачная система на двух компьютерах

        Многопроцессные и однопроцессные экземпляры ORACLE

ORACLE RDBMS  может работать как в однопроцессном,  так и во многопроцессном
вариантах. Если значение параметра SINGLE_PROCESS файла INIT.ORA имеет значение
TRUE, система однопроцессовая, если - FALSE, система многопроцессная.

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

        Однопроцессный ORACLE

Однопроцессный ORACLE  (называемый  иногда однопользовательским) - это система,
в которой база данных доступна только одному пользователю. Несколько пользова-
телей одновременно не могут обращаться к базе.  ORACLE работает на персональных
компьютерах в однопользовательском режиме,  так как MS-DOS не поддерживает
работу нескольких пользователей.  Единственный процесс означает  и один
экземпляр ORACLE;  база не может быть открыта другими экземплярами.



                                    -- 95 --



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

        Многопроцессный ORACLE

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

        Фоновые процессы ORACLE

    Для работы   многих  пользователей  многопроцессная  система ORACLE
использует некоторые дополнительные  процессы,  называемые фоновыми.  Цель этих
процессов - увеличение производительности за счет закрепления за ними некоторых
функций,  которые будут выполняться  в  интересах  всех пользователей системы
ORACLE.  Фоновые процессы асинхронно выполняют чтение/запись данных в базу,
мониторинг  процессов ORACLE для того,  чтобы достигнуть большего параллелизма
и, следовательно, большей производительности и достоверности работы системы
ORACLE.  Каждый экземпляр  ORACLE  может  использовать до пяти фоновых
процессов. Они называются DBWR, LGWR, SMON, PMON и ARCH.

    Если несколько экземпляров ORACLE разделяют одну базу данных, каждый имеет
собственный набор фоновых процессов.

    Во многих операционных системах эти процессы создаются  автоматически при
старте  экземпляра  ORACLE.  В других операционных системах процессы сервера,
равно как и пользователи (идентификаторы пользователей) создаются в процессе
инсталяции ORACLE. Подробную информацию Вы найдете в своем "Руководстве
пользователя по инсталяции".

    Так как иногда желательно иметь несколько систем ORACLE,  параллельно
работающих на одном компьютере, ORACLE обеспечивает механизм именования
экземпляров.  С целью различения принадлежности фоновые процессы снабжаются
префиксами,  связанными с идентификатором экземпляра ORACLE. Например,
экземпляр с именем BIRD в системе DEC VMS будет иметь отдельные процессы со
следующими именами:
    * ORA_BIRD_DBWR
    * ORA_BIRD_LGWR
    * ORA_BIRD_SMON
    * ORA_BIRD_PMON
    * ORA_BIRD_ARCH

        Database Writer (DBWR)

    Назначение этого  процесса  -  запись модифицированных блоков данных из кеш
- буфера базы на диск.  Блоки записываются в порядке, требуемом  для поддержа-
ния целостности базы.  Алгоритм записи гарантирует, что буферы всегда будут
доступны  для  записи.  Если требуются дополнительные буферы,  наиболее старые
записываются на диск в первую очередь.

Так как попутно  ORACLE  осуществляет  протоколирование  (См.  Главу 15), DBWR
не нуждается в записи буферов на диск при выполнении операции COMMIT.



                                    -- 96 --



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

        Log Writer (LGWR)

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

        System Monitor (SMON)

    Цель SMON - выполнить восстановление экземпляров ORACLE. Он используется
при старте экземпляра ORACLE а также для того, чтобы выполнить соответствующее
восстановление при отказе процессора на разделяемой дисковой системе.  Кроме
того, SMON несет ответственность за очистку временных сегментов, необходимость
в которых отпала и наконец - за восстановление "погибших" транзакций, пропущен-
ных во время аварии и восстановления экземпляра,  вызванных ошибками чтения
файла или выводом в offline. Эти транзакции  в конце концов восстанавливаются с
помощью SMON-а,  когда табличное пространство или файл вновь возвращаются в
online.  SMON периодически "пробуждается",  чтобы проверить,  нет ли в нем
необходимости, а также в случае, когда другой процесс обнаруживает эту
необходимость.

        Process Monitor (PMON)

Назначение PMON - выполнять восстановление аварийно завершившихся пользователь
ских процессов.  PMON отвечает также за очистку кеш -  памяти  и освобождение
ресурсов,  используемых процессом.  Например - меняет статус активной таблицы
транзакций, освобождает фиксации объектов  системы  и убирает идентификаторы
процессов из списка активных процессов ORACLE.  Также как и SMON,  PMON
периодически  "пробуждается"  сам,  а также может быть вызван другим процессом,
если он определит, что PMON должен выполнить свои функции.

        Archiver (ARCH)

    Процесс Archiver производит копирование на ленту находящегося в online
файла журнала повторного выполнения при  его заполнении.  Процесс ARCH активен,
если используется режим ARCHIVELOG и архивация активирована (автоматически или
вручную). Информацию об активировании архивации Вы найдете в Главе 15.

    Детали процесса  архивации  зависят от операционной системы и могут
требовать выделенного ленточного драйвера.  Для более  подробной информации
обратитесь к Главе 15 и "Руководству пользователя по инсталяции".

        Программный интерфейс

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

                                    -- 97 --



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

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

        Структура программного интерфейса

Как видно из рисунка 9-4,  программный интерфейс  состоит  из нескольких
частей:
* программный  интерфейс  со стороны пользователя (называемый также UPI - User
  Program Interfase)
* программный интерфейс со стороны ORACLE (называемый OPI)
* различные драйверы (протоколо-зависимые программы,  обеспечивающие связь)
* программы связи операционной системы
* ORACLE call interface (OCI)
* интерфейс прекомпилятора SQL (SQL)

    Равно как  и  драйверы,  программный  интерфейс и со стороны пользователя,
и со стороны ORACLE  является  частью  программного обеспечения ORACLE.

SQL*Net - это часть программного интерфейса, которая позволяет пользовательским
программам и ORACLE функционировать  на  различных процессорах.

    Драйверы программного интерфейса

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

    Вы можете  инсталировать  несколько  драйверов  (например  - асинхронный и
драйвер DECnet) и выбрать один  умалчиваемый  драйвер, и разрешить отдельным
пользователям указывать в момент связи желаемый драйвер. Различные процессы
могут использовать различные драйверы. Один и тот же процесс может параллельно
связываться либо с одной базой,  либо с несколькими (локальными  или
удаленными), используя драйверы SQL*Net.

    Руководство пользователя  по  инсталяции  детально описывает выбор и
инсталяцию драйверов, а также добавление драйверов после инсталяции.
"Руководство пользователя  SQL*Net" описывает выбор драйвера во время работы
(при обращении к ORACLE).


    Программное обеспечение связи операционной системы

    Окончательно связывается  интерфейс  со  стороны  ORACLE и со стороны
пользователя через программные  средства, предоставляемые операционной
системой.  Примеры тому: DECnet, TCP/IP и ASYNC. Эта связь должна обеспечивать
защиту (разделение) пользователя и операционной системы.

    Для обеспечения работы ORACLE фирмой  разработаны специальные драйверы для
всех протоколов связи.


                                    -- 98 --



    Сетевое программное обеспечение может поставляться корпорацией ORACLE,
однако обычно продается отдельно поставщиками аппаратуры или третьими фирмами.
                              Ъ----------ї    Ъ----------ДїПрограмма
                              іПрограмма і    іПрограмма  іпольз-ля
               Ъ--------Дї    іпольз. OCIі    іпольз. PCC і
               і         і  ЙНШННННННННННШННННШНННННННННННОННННННННН»
               і Пакет,  і  є іИнтерфейс і    іИнтерфейс  і         є
               іпоставля-і  є ГORACLE    ґ    ГPCC SQL    ґ         є
               і  емый   і  є іCALL (OCI)і    і  (SQL)    і         є
               і ORACLE  і  є і          і    і           і         є
             ЙНШНННННННННШННј і          і    і           і         є
             є Г--------ДБ----Б----------Б----Б----------Дґ         є
             є іПрограммный интерфейс пользователя (UPI)  і         є
 ПРОГРАММНЫЙ є Г--------ДВ----В----------В----В----------Дґ --ї     є
             є і DECNET  і    і  ASYNC   і    і  SINGLE   і   і     є
 ИНТЕРФЕЙС   є А--В------Щ    А--ДВ------Щ    Г----------Дґ   і     є
             є    ^ VMS           іRS232      і           і   і     є
             є    іDECNET         ^           і           і   іSQL* є
             є    А--Дї           і           і           і   іNet  є
             є        і           А--Дї       і           і   і     є
             є        v               і       і           і   і     є
             є    VMS і               і       і           і   і     є
             є  DECNETі         RS232 v       і           і   і     є
             є Ъ------Б--ї    Ъ------ДБ--ї    Г----------Дґ   і     є
             є і DECNET  і    і ASYNC    і    і  SINGLE   і   і     є
             є Г--------ДБ----Б----------Б----Б----------Дґ --Щ     є
             є іПрограммный интерфейс ORACLE (OPI)        і         є
             є Г------------------------------------------ґ         є
             ИНШННННННННННННННННННННННННННННННННННННННННННШНННННННННј
               і                                          і Программа
               і       O R A C L E   R D B M S            і ORACLE
               А------------------------------------------Щ
            Рисунок 9-4 Структура программного интерфейса

        ГЛАВА 10                   ОБРАБОТКА SQL - ОПЕРАТОРОВ

Perhaps of all the creations of  man  language  is  the  most astonishing
Lytton Strachey A clear statment is the strongest argument.  English proverb

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

Хотя некоторые прикладные средства ORACLE упрощают или,  наоборот, ограничивают
использование SQL, именно SQL - операторы обеспечивают в конце концов доступ
или изменение данных в  базе.  Все другие попытки  доступа  к  данным  в обход
системы защиты ORACLE RDBMS потенциально нарушают целостность данных.

                                    -- 99 --



    Детали, описанные в этой главе по большей  части  скрыты от конечных
пользователей, работающих с инструментальными и прикладными средствами ORACLE.
Однако, если Вы разработчик прикладных программ, то Вам, возможно, потребуется
более гибкое управление доступом (особенно в  больших  или комплексных
приложениях).  В частности,  программный  интерфейс  по  сравнению с утилитами
ORACLE, дает более широкие и гибкие возможности. За деталями можно обратиться к
документации по прекомпиляторам,  например - "Руководству пользователя по
PRO*FORTRAN".

        Что из себя представляет SQL - оператор ?

    Оператор SQL - это строка на языке SQL, передаваемая на обработку RDBMS.
Текст  строки состоит из зарезервированных слов SQL (слов, имеющих в SQL
специальное значение и обычно не  используемых в других целях).  Например -
слова SELECT и UPDATE - зарезервированные слова и не могут использоваться  в
качестве  названий таблиц. Оператор  должен быть эквивалентен "предложению"
SQL, как например:

    SELECT ENAME, DEPTNO FROM EMP ;

Только такой оператор может быть выполнен (в отличие от фрагмента). Например,
задание
    SELECT ENAME

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

        Курсоры и области контекста

    В целях обработки оператор SQL связывается с курсором. Курсор -  это
практически синоним "области контекста",  обсуждавшейся в Главе 8. Различие
между этими понятиями весьма тонкое.

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

    Курсор, в зависимости от действий,  предпринимаемых пользователем, может
находиться в различных состояниях  или  фазах.

    Область контекста - это область памяти, содержащая информацию курсора. Вы
можете считать курсор именем области контекста.

        Простой пример выполнения SQL - оператора

    Ниже приводится упрощенное описание выполнения оператора SQL.  В этом
примере используется оператор DML (UPDATE); операторы запросов (SELECT) требуют
дополнительные  шаги.  Детальное  описание обработки всех  типов  операторов
SQL приводятся позже в этой же главе.

    Допустим, Вы используете программу на PRO*FORTRAN-е  с  целью увеличить
жалование всем служащим отдела. В программе должен быть следующий оператор:

    EXEC SQL UPDATE EMP SET SAL = 1.10 * SAL
         WHERE DEPTNO = :DEPTNO


                                   -- 100 --



    Допустим, что  Вы соединились с ORACLE и имеете соответствующие привилегии
для изменения записей.  :DEPTNO -  это  переменная главного языка, содержащая
значение для номера отдела; это значение должно быть занесено в переменную до
выполнения нашего оператора. При выполнении SQL - оператора PRO*FORTRAN
скопирует значение DEPTNO в этот оператор.

    Выполнение оператора разбивается на следующие шаги:

1. Создание курсора.  Курсор создается  вызовом  программного интерфейса.
   Курсор  создается независимо от типа SQL - оператора; он создается в
   предверии оператора.  В программах  прекомпиляторов он может создаваться
   неявно.

2. Разбор  оператора. Сканируется синтаксис оператора SQL и его
   представление загружается в курсор. Процесс разбора включает в себя:
* трансляцию SQL - оператора
* загрузку его в курсор
* проверку полномочий доступа к участвующим объектам базы
* определение пути доступа,  который будет использоваться при выполнении
   оператора
* определение требуемых для выполнения ресурсов
* блокировку этих ресурсов.

Например, определения объектов базы, требуемых для выполнения оператора
(например - таблицы и индексы), могут быть зафиксирова- ны, дабы не изменялись
в процессе выполнения оператора.

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

4. Выполнение оператора. В этой точке RDBMS имеет всю необходимую информацию
  для выполнения оператора.

        Использование курсоров для повторного выполнения операторов

    После выполнения каждой фазы в  курсоре  остается  достаточно информации
для повторения оператора без прохода всех фаз с самого начала. Эта возможность
сохраняется до тех пор, пока SQL - оператор ассоциируется  с  этим курсором.
Другими словами,  в однажды проанализированном операторе можно выполнить фазу
связывания  переменных для  других их значений и выполнить оператор без
повторного разбора.  Если связанные переменные не изменяют типов данных и их
значений,  можно  опустить и фазу связывания и просто вновь выполнить оператор.
Если переменные связаны по ссылкам (адрес,  а не значение),  отпадает
необходимость в повторном связывании, так как ORACLE знает адреса памяти
переменных и  может  автоматически взять их новые значения.

    Открыв несколько  курсоров,  мы можем сохранить проанализированное
состояние нескольких SQL - операторов.  Повторное выполнение этих операторов
может начинаться с фазы связывания или выполнения, экономя тем самым время на
открытии  курсоров  и  разборе операторов.

    Обработка оператора (детально)



                                   -- 101 --



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

    На рисунке 10-1 показаны стадии исполнения оператора SQL.
                Ъ----------------------------Дї
                і  Определить область         і
                і   контекста (курсор)        і
                А------------ДВ--------------ДЩ
                Ъ------------ДБ--------------Дї
                і  Выполнить разбор оператора і
                і  SQL в области контекста    і
                А------------ДВ--------------ДЩ
                              Г----<--------------ї
                Ъ------------ДБ--------------Дї   і
                і  Связать все подставляемые  і   і
                і         значения            і   і
                А------------ДВ--------------ДЩ   і
                Ъ------------ДБ--------------Дї   і
                і  Выполнить текущий оператор,і   і Пока курсор
                і  находящийся в области кон- і   і остается от-
                і          текста             і   і крытым, опе-
Закончить, если А------------ДВ--------------ДЩ   і ратор может
это не  ----------------------Е------>------------ґ выполняться
запрос      Ъ-- Ъ------------ДБ--------------Дї   і многократно
            і   і  Описать, если это оператор і   і без повтор-
            і   і  запроса, вид результата    і   ^ ного разбора
            і   А------------ДВ--------------ДЩ   і
            і                 Г------Д>----------Дґ
            і   Ъ------------ДБ--------------Дї   і
 Эти шаги   і   і  Определить, если это опера-і   і
 выполняютсяі   і  тор запроса, переменные дляі   ^
 только для і   і         результата          і   і
 запросов   і   А------------ДВ--------------ДЩ   і
            і                 Г-------->----------Щ
            і   Ъ------------ДБ--------------Дї
            і   і  Если это оператор запроса, і
            і   і  выбрать результирующие     і
            і   і  строки                     і
            А-- А----------------------------ДЩ
            Рисунок 10-1 Стадии обработки SQL - операторов

        Открытие и закрытие курсоров

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

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



                                   -- 102 --



* Общесистемный  предел количества курсоров на одного пользователя устанавли-
  вается параметром  OPEN_CURSORS  файла  INIT.ORA.  Более детально этот
  параметр описан в Приложении D.

Явное создание  курсоров может предоставить некоторые преимущества настройки
приложения. Например, увеличение количества курсоров обычно  позволяет умень-
шить  частоту  анализирования SQL операторов и повысить производительность.

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

Для более подробной информации о настройке  прикладных  программ обратитесь к
Главе 19.

    Синтаксический разбор операторов

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

Блокировка грамматического разбора  (анализа)  отменяется при закрытии курсора
или при замене в курсоре одного SQL - оператора на другой (повторное
использование).

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

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

        Связывание переменных

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



                                   -- 103 --



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

        Описание результатов

Фаза описания  результатов операции требуется только для операторов запросов.
Запросы отличаются от операторов других  типов тем, что  в  случае успешного
выполнения возвращают данные.  В то время как остальные операторы возвращают
только  значения  успеха или неудачи,  запросы  могут возвращать многие тысячи
строк.  Результат запроса всегда представляется в табличном формате и в
результате выбираются строки ( либо построчно, либо группами).  В фазе описания
нет необходимости нет надобности,  если результат известен.  Например, мы
знаем, что для следующего запроса нам потребуется дав столбца:

    SELECT ENAME, EMPNO FROM EMP ;

    И наоборот, мы не знаем какой результат будет у запроса:

    SELECT * FROM DEPT ;

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

        Определение выхода

    Также как и  фаза  описания,  фаза  определения  используется только для
запросов.  В фазе определения Вы указываете расположение, размер и тип данных
для переменных,  которые будут принимать выбранные значения.(Если необходимо,
ORACLE будет выполнять преобразование данных).

        Выполнение

    В процессе  выполнения  SQL  - оператора необходимые действия производятся.
Для некоторых операторов можно  указать  количество выполнений. Это  называется
"обработка массивов".  Указав "n" выполнений, надо затем связать и определить
адрес  начала  массива размерности "n".  Более  подробно смотрите в руководстве
по программному интерфейсу, например "Руководство пользователя по PRO*C".

        Обработка операторов DDL

Выполнение операторов DDL отличается от выполнения DML и запросов, так  как в
случае их успеха требуется доступ по записи к словарю данных. Для операторов
DDL фаза грамматического разбора включает в  себя  одновременно  и анализ
оператора,  и обращение к словарю, и выполнение.  В обработке этих  операторов
отсутствуют стадии связывания и определения выхода.

        Обработка запросов

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

                                   -- 104 --



    INSERT INTO table SELECT ....
    UPDATE table SET x = y WHERE ...
    DELETE FROM table EHERE ...
    CREATE table AS SELECT ...

    Запросы имеют следующие особенности:
* они могут потребовать выполнения фаз описания и определения
* в фазе выполнения реально они не выполняются (за исключением предварительной
  работы по подготовке к выборке строк)
* требуют не противоречивого чтения (См. Главу 12)
* могут использовать для промежуточной обработки временные сегменты (См.Главу4).

    Выборка результирующих строк запроса

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

        ГЛАВА 11                УПРАВЛЕНИЕ ТРАНЗАКЦИЯМИ

                Success generally depends upon knowing how long
                it takes to succeed.
                      Charles Louis de Secondant Montesquieu

    В этой  главе дается определение транзакции и способы,  с помощью которых
изменения транзакции запоминаются  в  базе  данных.  Глава описывает следующие
понятия:
   * определение  транзакции (называемой также логической единицей работы)
   * точки сохранения и "мгновенные снимки"  для  согласованного чтения
   * SQL - операторы, используемые для управления транзакциями:
         * COMMIT
         * ROLLBACK
         * SAVEPOINT
    * эффект от выдачи этих операторов явно и неявно.

    Материал этой  главы будет интересен как разработчикам приложений, так  и
администраторам  базы  данных.  Связанная  с  этой информация может быть
найдена в :
    * Главе 12        Параллельная обработка и блокировка
    * Главе 15        Восстановление базы данных

        Определение транзакции

    Транзакция (или логическая единица работы) -  это  последовательность SQL
-  операторов,  которые ORACLE трактует как единый объект. Большинство
программных приложений содержат несколько типов транзакций.  Транзакция  может
быть либо повторяющейся - как при добавлении новых строк в таблицу результатов
научных наблюдений, либо  в  каком-то смысле случайной,  как при "просмотре
данных" с целью хорошего ими владения или при выдаче незапланированных запросов.

    Транзакция может состоять из одного или нескольких операторов SQL и
следовательно,  быть короткой или длинной.  Например,  ниже приведены
допустимые транзакции:
    * создание таблицы с именем TEMPTABLE
    * вставка одной новой строки в таблицу VENDORS
    * удаление сотрудницы из списков одного отдела, добавление ее к сотрудникам

                                   -- 105 --



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

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

    Понятие "успешное завершение SQL - операторов"  отличается от понятия
"транзакция записана" (committed).

Успешное выполнение означает, что оператор проанализирован и найден правильным,
а затем безошибочно  исполнен.  Однако,  пока оператор не подтвержден как часть
транзакции,  пользователь,  выдавший этот оператор, может "откатить" его
(отменить все его изменения). Успешно завершился оператор, но не транзакция.

Быть записанным-означает, что хозяин оператора явно или неявно сказал "сделать
изменения этой транзакции  постоянными".  Вы записываета транзакцию, состоящую
из одного или нескольких операторов SQL, а не оператор! Пока транзакция не
записана, ни одно из ее действий "не видно" другим пользователям.  Вместо
записи Вы можете откатить (отменить) транзакцию (roll back). В этой главе
обсуждаются соответствующие операторы SQL: COMMIT и ROLLBACK.

    Роль транзакций в системе

Система ORACLE гарантирует согласованность  данных основанную не на единствен-
ном SQL - операторе,  а на транзакции (хотя транзакция может состоять и из
одного оператора). Именно для транзакции  данные либо постоянно сохраняются,
либо откатываются назад.  Если операционная система или программа пользователя
отказали  в процессе транзакции, данные в базе автоматически восстанавливаются
в состояние, предшествующее этой транзакции.

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

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

    Начало и окончание транзакции

Транзакция начинается при появлении первого выполнимого  SQL - оператора.
Выполнимый  SQL - оператор генерирует обращение к базе данных и включает в себя
операторы DML, DDL и DCL.

    Транзакция завершается при появлении одного из следующих  событий:
    * выдан COMMIT или ROLLBACK
    * выдана  команда  DDL  (такая как CREATE,  DROP,  RENAME или ALTER)
      (записывается предыдущая транзакция)
    * завершился оператор DDL (транзакция, содержащая в себе оператор DDL,
      записывается автоматически)
    * пользователь  отсоединился  от  ORACLE (например - EXEC SQL ... RELEASE)
      (Транзакция записывается)
    * аварийное завершение процесса пользователя (транзакция  откатывается).




                                   -- 106 --



    Как только транзакция завершена, следующий SQL - оператор начинает новую
транзакцию.  Если в конце  транзакции  не  появились операторы COMMIT  или
ROLLBACK,  то нормальное завершение программы (например - EXIT в SQL*Plus или
DISCONNECT) подтвердит выполнение транзакции, и наоборот, аварийное завершение
(когда программа заканчивается до EXIT или DISCONNECT) вызовет откат назад.

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

    Если аварийно завершится операционная система (а не пользовательский
процесс),  данные восстановятся во время  восстановления операционной системы
(как часть восстановления экземпляра ORACLE).

    Транзакции типа "только-чтение"

    Транзакции такого типа полезны при запросах или выдаче отчетов по данным с
доступом к нескольким базовым таблицам. Например, если Вам обычно требуется,
чтобы данные из группы  взаимосвязанных таблиц были согласованны на момент
запроса.

    Используя SQL - оператор SET TRANSACTIONS READ ONLY Вы можете указать, что
определенная транзакция будет только читать.  За более детальной информацией об
этом операторе обратитесь к Главе 12.

    Как транзакции определяются в утилитах ORACLE?

   Обычно утилита ORACLE или прикладная программа сами  представляют, что
является  для  них транзакцией и Вам лишь надо позаботиться вовремя сделать
COMMIT или ROLLBACK для этой транзакции.

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

    Транзакция должна содержать  все  части,  необходимые  данной единице
работы (не больше и не меньше!).  До начала транзакции и по ее окончании все
данные  в  связанных  между  собой  таблицами должны быть согласованы между
собой.  Другими словами, транзакции должны состоять из SQL -  операторов,
выполняющих  согласованные изменения данных.

    Например, передача  фондов  (скажем - 1000 долларов) с одного счета на
другой должна как уменьшение первого счета, так и увеличение второго.  Оба
действия должны выполняться вместе. Ни в коем случае выполнять commit после
снятия, но перед добавлением.

    Аналогично, если должны выполниться две операции  дебита (250 и 750
долларов),  то одновременно должны записываться  три  действия (два дебита и
один кредит).  С другой стороны - не связанная с ними операция, например -
вклад - не должна включаться в предыдущую транзакцию.

        Управление транзакциями с помощью операторов SQL




                                   -- 107 --



    Для выполнения или отката транзакции используются  следующие SQL - операторы
    COMMIT WORK
    SAVEPOINT
    ROLLBACK WORK

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

        Оператор COMMIT WORK

Оператор COMMIT WORK выполняет следующие действия:
    * делает "постоянными" все  изменения,  сделанные  в  текущей транзакции
      (естественно, данные могут быть изменены в дальнейшем)
    * очищает все точки сохранения для данной транзакции
    * завершает транзакцию
    * освобождает объекты, заблокированные в транзакции

    Синтаксис оператора следующий:  COMMIT [WORK]

    Ключевое слово WORK необязательное.

Рекомендуемая практика  -  в  прикладных программах завершать транзакции явно,
используя оператор COMMIT  WORK  (или  ROLLBACK WORK),  включая и последнюю
перед отсоединением транзакцию.  Если Вы явно не записалили транзакцию и
программа завершилась аварийно, последняя не записанная транзакция будет
отменена (откат).

    Что происходит при выполнении COMMIT ?

Перед записью транзакции,  в которой Вы меняли данные, выполняется следующее:
    * RDBMS генерирует в памяти записи rollback
    * RDBMS генерирует в памяти записи журнала повторного  выполнения  (Эти
      изменения могут попасть на диск до записи транзакции)
    * изменения производятся в буферах базы данных

    Когда транзакция явно или  неявно  записывается,  выполняется следующее:
    * Транзакция помечается "завершенной".
    * Если записи журнала повторного выполнения еще не записаны в online файл,
      это выполняется
    * Заблокированные строки и таблицы освобождаются (но не освобождаются
      объекты, заблокированные при синтаксическом разборе)

    После выполнения  COMMIT  (но  не  обязательно - в тот же момент),  буферы
записываются в базу.  Для записанной транзакции не требующаяся более информация
отката на диск не записывается.

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

        Использование оператора SAVEPOINT





                                   -- 108 --



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

Синтаксис соответствующего SQL - оператора следующий:
    SAVEPOINT savepoint_id

    Где savepoint_id - это идентификатор SQL (подчиняется  тем же правилам, что
и другие объекты базы) или переменная главного языка программирования:

    SAVEPOINT add_eml1
    SAVEPOINT insertsmade

    Если вы создаете точку сохранения с таким же идентификатором, что и
предыдущая, предыдущая информация теряется. После того, как точка сохранения
создана, можно выполнить COMMIT :

    COMMIT WORK

    или откатиться к точке сохранения:

    ROLLBACK WORK TO savepoint_id

    По умолчанию на процесс принимается 5 активных точек сохранения. Активной
точкой сохранения называется такая,  которая специфицирована после последней
операции commit или rollback.  Это ограничение может быть изменено заданием
нового  значения параметру SAVEPOINTS файла  INIT.ORA.  Максимально  можно
указать 255 точек сохранения.

На рисунке 11-1 показано использование точек  сохранения  для отмены части
транзакции.

    UPDATE EMP SET DEPT = 'US SALES' WHERE DEPT = 'SALES'
    SAVEPOINT USDONE

    UPDATE EMP SET DEPT = 'INT'L SALES' WHERE MGR = 6745
    SAVEPOINT ILDONE

    UPDATE EMP SET  MGR = 6745  WHERE MGR = 5902
    ROLLBACK TO USDONE

    UPDATE EMP SET  MGR = 6745  WHERE MGR = 5902
    UPDATE EMP SET DEPT = 'INT' SALES' WHERE MGR = 6745
    COMMIT

  Рисунок 11-1 Пример операторов SAVEPOINT, COMMIT и ROLLBACK

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




                                   -- 109 --



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

        Rollback на уровне оператора

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

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

    Таким образом,  аварийное завершение SQL - оператора приведет к потере
лишь  его  работы;  это не влечет за собой потери всего предшествующего из
текущей транзакции.  Если  это  оператор  DDL, предшествующий ему commit не
откатывается.

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

        Оператор ROLLBACK WORK

Этот оператор  служит  для  отмены  работы  и имеет следующий синтаксис:

    ROLLBACK  [ WORK ] [ TO [SAVEPOINT] savepoint_id ]

Ключевое слово WORK необязательно.
Использование ROLLBACK без фразы TO SAVEPOINT приводит к :
    * завершению транзакции
    * отмене всех изменений в текущей транзакции
    * очистке точек сохранения для текущей транзакции
    * отмене всех блокировок транзакции

    Использование ROLLBACK с фразой TO SAVEPOINT приводит к :

    * откату только части транзакции
    * сохранению данных до точки сохранения и откату -  после. На рисунке 11-1
      ROLLBACK откатывает работу, сохраненную в точке сохранения ILDONE, но
      сохраняет работу до точки USDONE.
    * освобождению всех блокировок строк и таблиц,  выполненных после создания
      точки сохранения, но не освобождает блокирование транзакции (TX).

Блокировка транзакции освобождается при выполнении commit или rollback.  Если
пользователи ожидают строк, заблокированных в Вашей транзакции, им придется
ожидать до освобождения TX.



                                   -- 110 --



Рекомендуемая практика  -  в  прикладных программах завершать транзакции явно,
используя оператор COMMIT  WORK  (или  ROLLBACK WORK),  включая и последнюю
перед отсоединением транзакцию.  Если Вы явно не записали транзакцию и
программа  завершилась аварийно, последняя не записанная транзакция будет
отменена (откат).

        Выдача команд COMMIT или ROLLBACK

Команды COMMIT и ROLLBACK могут выдаваться как явно  программой или
пользователем,  так  и  неявно  (автоматически) системой ORACLE.

        Явные команды Commit/Rollback

    В большинстве   продуктов  ORACLE  Вы  должны  явно  записать (commit) или
откатить (rollback) транзакцию с  помощью  соответствующих команд.  Кроме того,
в этих продуктах можно пользоваться оператором SAVEPOINT.

    Неявные (автоматические) команды Commit/Rollback

Неявный commit происходит в следующих случаях:
    * перед оператором DDL
    * после оператора DDL
    * при нормальном отсоединении от базы

    Операторы определения данных (такие как CREATE, DROP и GRANT) всегда
приводят к неявным операциям commit в  момент  их  работы.  Если Вы вводите
оператор DDL, введя предварительно несколько операторов DML,  сперва
выполняется commit для предшествующих операторов, затем выполняется оператор DDL

    Неявные откаты происходят, когда процесс или экземпляр ORACLE завершаются
аварийно. Неявные откаты уровня оператора выполняются при аварийном выполнении
этого оператора.

        ГЛАВА 12               НЕПРОТИВОРЕЧИВОСТЬ И  ПАРАЛЛЕЛЬНАЯ ОБРАБОТКА

               Make'em laugh; make'em cry; make'em wait.
                                       Charles Reade

               Thow canst not say I did it; never shake
               Thy gory locks at me.
                                       Shakespeare: Macbeth III.iv

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

В этой главе обсуждаются следующие предметы:
    * согласованное чтение
    * транзакции типа "только чтение"
    * перекрытие умалчиваемых блокировок
    * использование утилиты SQL*DBA для отслеживания текущего резервирования и
      фиксаций
    * обнаружение тупиковых ситуаций
    * параметры SERIALIZABLE и ROW_LOCKING файла INIT.ORA.

    В отдельных  частях  этой  главы  непосредственно указывается разница между
ORACLE RDBMS версии 6 с опцией обработки транзакций и без нее.

                                   -- 111 --



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

    * Приложение В - справочник по утилите SQL*DBA для информации о средстве
      MONITOR LOCKS
    * Глава 11  - управление транзакциями

            Основные понятия о параллельных обращениях к базе

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

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

    Данные и  структура данных могут стать предметом компромисса в следующих
случаях:
    * "потерянные изменения" (одно изменение перекрывает другое)
    * два параллельных изменения приводят  к  возникновению  двух одинаковых
      индексов при объявленном уникальном индексе
    * таблица  изменяется,  в  то  время как она удаляется другим пользователем
      или у нее меняется структура.

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

Цель ORACLE RDBMS - сделать так,  чтобы это ожидание было или несущественным
или не влияющим на каждого пользователя.  Все операторы SQL (DML,  DDL и
запросы) должны выполняться с как  только возможно малым и взаимным влиянием,
а разрушающее взаимное влияние транзакций должно быть запрещено.  Не должно
быть  компромисса между производительностью и целостностью данных.

Система ORACLE обрабатывает параллельные запросы на изменение данных, используя
систему  различных типов блокировки и режимов работы.  Эти возможности
базируются на понятии транзакции. Разработчик  прикладной  системы должен
гарантировать,  что транзакции определены правильно (как описано в Главе 11).

    Существует много типов блокировки ,  часть из  которых  может управляться
пользователем, а часть-нет.  Текущие блокировки в работающей  системе ORACLE
можно  увидеть,  используя   команду MONITOR утилиты SQL*DBA.  Синтаксис и
описание команды MONITOR, а также примеры выдачи приведены в Приложении В.

            Согласованное чтение

    Система ORACLE поддерживает модель  "согласованного  чтения", что означает:




                                   -- 112 --



    * гарантию того, что данные, "видимые" оператором (например - при запросе)
      не меняются в течение работы оператора
    * пользователи,  читающие данные из базы не ожидают пишущих в этот же блок
      базы

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

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

    "Моментальный снимок" делается на  фазе  выполнения.  Это не обязательно
полная  копия  данных,  хотя можно представлять себе именно так.  Вместо этого,
если данные запрашиваются в момент их изменения  ORACLE  реконструирует  старое
состояние блока данных, используя сегменты отката.  Реконструкция необходима
только  тем блокам  данных,  которые  изменились с момента начала запроса.  В
этом случае достигается согласованность чтения и в  то  же  время
производительность остается приемлемой.

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

Ваше знание того, что команда EXEC SQL OPEN после старта создаст "моментальный
снимок" данных и все изменения в  данных,  сделанные позже не будут "видимы" из
программы. Вероятно Вы захотите поместить этот вызов в программе как можно
позже.

    Примеры согласованного чтения

Например, если BARB выполняет запрос по таблице EMP,  результаты,  возвращаемые
по ее запросу - это данные, которые существовали в таблице EMP на момент старта
запроса. Эти результаты включают в себя все изменения,  сделанные ею с помощью
операторов DML до запроса (записаны они или нет) а также все записанные измене
ния этой таблицы,  сделанные другими пользователями. Однако изменения,
сделанные BARB в таблице EMP после начала запроса, не войдут  в  его результат,
равно  как и все не записанные изменения других пользователей.

    Рассмотрим двух пользователей:  Bert и Ernie, вместе обращающихся к
финансовому учету.  Bert запрашивает базу (назовем TX-B - "transaction-B"),
суммируя DEBITS и CREDITS,  желая сравнить  результаты. В тот же момент Ernie
может выдать транзакцию (TX-E) по дебетированию ACCT1 и кредитированию ACCT2.

Если Bert запрашивает в момент,  когда Ernie находится посредине транзакции,
согласованность чтения гарантирует, что Bert получит старый баланс DEBITS и
CREDITS. Если приложение разработано правильно, транзакция Ernie будет записана
после выполнения и дебета и кредита. Таким образом, Bert сможет увидеть только
результаты завершенных транзакций;  в этом случае его запрос, выданный до TX-E,
покажет старое значение баланса.  Если же  Bert  выдаст запрос после того,  как
Ernie запишет транзакцию TX-E, он получит новые значения, но они будут также
равны.

                                   -- 113 --



    Если Ernie модифицирует данные в то время как  Bert выполняет запрос, в
результате он увидит еще не измененные данные даже если Ernie выдаст commit до
обращения Bert к этим строкам.

            Сообщение "Snapshot Too Old"

В некоторых случаях RDBMS не может выдать  набор результатов, согласованный по
чтению.  Эта ситуация возникает при очень активных модификациях (в таблице или
сегменте отката), в результате чего  в  сегменте отката остается недостаточно
информации для реконструирования более старых  данных.  В  этом случае
возникает ошибка 1555:

    ORA 1555 snapshot too old (rollback segment too small)
    (снимок слишком старый (сегмент отката слишком мал)

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

            Введение в блокировку

    ORACLE RDBMS  использует блокировку для управления параллельным доступом к
данным. Блокировка - это механизм, предназначенный для  предотвращения
взаимного влияния пользователей, разрушающего данные базы. Разрушающее
взаимодействие может быть определено как некорректное изменение данных или
соответствующих структур данных (таких как определения столбцов,  таблиц,
индексов или  полномочий).

Блокировка используется для достижения двух важных целей:
    Непротиворечивость   Гарантирует, что данные, которые просма-
    (достоверность)      тривает или изменяет пользователь, не будут изменены,
                         пока он с ними работает.

    Целостность          Гарантирует, что данные и структуры отра- жают в
                         правильном порядке все изменения, проведенные над ними

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

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

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

           Какие ресурсы можно блокировать ?
    Блокирование может  быть задумано как назначение пользователю базы
"временной собственности"  некоторого  ресурса,  такого  как таблица  или
строка в таблице.  Ресурсы состоят из двух основных типов объектов:



                                   -- 114 --



* пользовательские объекты, например - таблицы  и  строки (структуры и данные)
* системные объекты, невидимые пользователю, такие как разделяемые структуры в
  SGA и буферах базы.

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

    В процессе своей работы ORSCLE RDBMS в пользовательских целях блокирует
большое количество структур.  Пользователи  могут  явно блокировать  строки
таблиц,  используя  оператор SELECT ...  FOR UPDATE, или полностью таблицы,
используя оператор LOCK TABLE.

    Таблицы словаря данных  не  могут  быть  заблокированы  явно.  Правда
отдельные таблицы словаря ORACLE RDBMS блокирует сам, но с целью нормального
функционирования системы. Эта блокировка выполняется на короткие интервалы
времени. Для дополнительной информации смотрите ниже раздел "Блокировка
словаря".

    Продолжительность блокировки

Продолжительность блокировок варьируется в зависимости от того, что защищается.
Некоторые типы блокировок (внутренние блокировки)  занимают очень маленький
интервал - на момент манипуляций с ресурсом.  Другие - на более продолжительное
время (например  - блокировка  таблиц или строк выполняется на протяжении всей
транзакции). И наконец, отдельные типы блокировок выполняются на весь период,
когда база открыта (например - блокирование , гарантирующее, что только один
экземпляр ORACLE будет писать в определенный сегмент отката).

    Все типы блокировок отменяются при выполнении commit.  Блокировка таблиц
снимается при откате к точке сохранения.  Резервирование же строк при таком
откате не отменяется.

    Кто может явно блокировать ресурсы ?

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

    * DBA может заблокировать любую таблицу
    * Остальные пользователи могут блокировать  свои  собственные таблицы,  а
      также таблицы других пользователей, для которых имеют любые табличные
      привилегии (такие  как  SELECT,  INSERT,  UPDATE, DELETE).

            Умалчиваемые и ручные блокировки

    Большая часть блокировок либо не может быть перекрыта,  либо в этом нет
необходимости.  Однако Вы можете запросить специфичное блокирование данных для
таблиц и строк,  используя операторы  SQL (если Вы имеете возможность это
сделать).

В следующих разделах этой главы описываются результаты блокирования по
умолчанию.  В заключительных разделах  рассказывается, как изменить
умалчиваемые блокировки ,  используя SQL - операторы LOCK TABLE и SELECT FOR
UPDATE.  Кроме того,  описывается команда SET  TRANSACTION  READ  ONLY, которая
меняет  поведение системы ORACLE для нескольких запросов в транзакциях, не
делающих изменений в данных.

                                   -- 115 --



            Типы блокировок

    Блокирование в системе ORACLE делится на следующие общие  категории:

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

    Блокирование словаря  Этот тип блокировки защищает структуру объектов базы.
Например - оно защищает определения таблиц и обзоров. Блокирование словаря
бывает двух типов: блокирование для анализа синтаксиса и DDL - блокировка .

    Внутренняя блокировка и защелки Это резервирование внутренних структур базы
и выполняется автоматически.

Чтобы увидеть текущие блокировки, используйте команды MONITOR LOCK и MONITOR
LATCHES утилиты SQL*DBA.  Краткое описание типов блокировок в системе ORACLE
приведено на Рис. 12-1.
  Тип блокировки                                   Наименование
  ------------------------------------------------------------Д
    Блокировка данных (DML)
        Блокировка таблиц                              TM
            EXCLUSIVE                                  X
            SHARE UPDATE                               RS
            SHARE ROW EXCLUSIVE                        SRX
            ROW SHARE                                  RS
            ROW EXCLUSIVE                              RX
            SHARE                                      S
        Блокировка строк (транзакции)                  TX
    Блокировка словаря
            Блокировка разбора                         TD (S)
            DDL - блокировка                           TD (X)
            Временный сегмент TT (S или X)
    Внутренняя блокировка                              (числовое)
    Защелки                                            (числовое)

    Блокирование кеша словаря
            Разделяемое
            Исключительное
    Блокировки управления файлами и журналом
    Блокировки табличных пространств и Rollback - сегментов

Рисунок 12-1  Краткое описание всех типов блокировок


            Блокировки данных (DDL - блокировки)

Цель блокировок данных - гарантировать согласованность данных при параллельном
доступе к ним нескольких пользователей.  Блокировки данных предотвращают
взаимное  вмешательство  одновременных DML - операций, потому и называются DML
- блокировками. Например, строка в таблице может быть модифицирована в данный
момент только одной транзакцией,  хотя и могла бы модифицироваться быстрее
последовательностью нескольких транзакций.

Выполнение блокировок данных для системы ORACLE с опцией  обработки транзакций
Замечание: Следующие разделы описывают,  как ведут себя умалчиваемые блокировки



                                   -- 116 --



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

    Таким образом,  в следующих разделах предполагается,  что для системы
ORACLE с опцией обработки транзакций два  параметра файла INIT.ORA установлены
в умалчиваемые значения:

    SERIALIZABLE = FALSE
    ROW_LOCKING = ALWAYS

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

            Операторы согласованного чтения для запросов,  изменений и удалений

    SQL - операторы SELECT,  INSERT ...  SELECT,  UPDATE и DELETE прямо или
косвенно выполняют запросы данных.  Каждый из этих операторов для привязки к
необходимым данным использует запрос  (какие данные будут выбираться,
вставляться, заменяться или удаляться).

    Оператор SELECT непосредственно выполняет запрос  явно (может содержать
гнездованные запросы).  Оператор INSERT также может использовать гнездованные
запросы. Операторы UPDATE и DELETE должны иметь фразы WHERE для привязки только
к определенным строкам таблицы и могут в свою очередь содержать подзапросы.

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

            Умалчиваемая блокировка для запросов

    Запросы - это операторы, только читающие данные и не меняющие их. Благодаря
этому они в наименьшей мере влияют на работу других SQL - операторов. Однако
пользователей, выдающих запросы, заботит непротиворечивость данных.

Если запрос не использует фразу FOR UPDATE,  для  него  верны следующие
характеристики:
    * запрос не требует блокировки данных
    * запрос  никогда  не ожидает освобождения других блокировок; он может
      продолжаться всегда
    * запрос всегда возвращает согласованные по чтению данные
    * к запрашиваемой таблице могут обращаться  другие транзакции (в том числе
      и к выбираемым запросам строкам)

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

ORACLE RDBMS на момент исполнения запроса всегда устанавливает "моментальный
снимок".  Запрос возвращает все данные,  которые были записаны на момент его
старта плюс те, которые были выполнены в транзакции, частью которой является
запрос.


                                   -- 117 --



    На Рисунке 12-2 кратко перечислены  умалчиваемые  блокировки, выполняемые
для SQL - операторов в системе ORACLE с опцией обработки транзакций.

  SQL - оператор               Блокировка строки       Таблицы
  ------------------------------------------------------------
    SELECT                          БЛОКИРОВКА НЕ ВЫПОЛНЯЕТСЯ
    SELECT FOR UPDATE               X                        RS
    LOCK table IN mode MODE:
            EXCLUSIVE               -                        X
            SHARE UPDATE            -                        RS
            SHARE ROW EXCLUSIVE     -                        SRX
            ROW SHARE               -                        RS
            ROW EXCLUSIVE           -                        RX
            SHARE                   -                        S
    INSERT                          X                       RX
    UPDATE                          X                       RX
    DELETE                          X                       RX
    DDL/DCL                         -                       X
Рисунок 12-2 Умалчиваемые блокировки с опцией обработки транзакций

            Умалчиваемая блокировка для изменений и удалений

    Модель согласованного чтения также  поддерживает  целостность результатов,
возвращаемых операторами DELETE и UPDATE. Эти операторы, как и запросы,
используют моментальные снимки, но для своих внутренних запросов.

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

    Ниже приведены характеристики команд UPDATE, DELETE и  INSERT:

    * Запрос в пользу команд UPDATE, DELETE или INSERT всегда начинается с согла
    * Операторы  выполняют  исключающие блокировки (X) на строки, подлежащие
      модификации и исключающие  блокировки  строк  (RX)  на таблицы,
      содержащие эти строки.
    * Другие транзакции могут запрашивать строки,  подлежащие модификации, но не
    * Другие транзакции могут выполнять любые действия над другими строками
      таблицы даже если  эти  строки  находятся  в  том  же физическом блоке
      или если блокировки задержаны.
    * Блокировки строк и таблиц освобождаются при записи (commit) транзакции.
    * При откате к точке сохранения освобождаются блокировки, выполненные после 

            Перекрытие умалчиваемых блокировок

Ручная блокировка  предпочтительнее  умалчиваемой в следующих случаях:

* если Вы хотите видеть несколько таблиц в согласованном состоянии (данные
соответствуют друг другу по всем таблицам). Примером может служить одна главная
и несколько подчиненных уточняющих таблиц.  Этого Вы можете достигнуть лишь
применяя не умалчиваемые блокировки или транзакции в режиме "только чтение".


                                   -- 118 --



* Вы хотите,  чтобы никто другой не мог изменить данные, Вами заблокированные
до завершения транзакции (независимо от того, будете или нет изменять данные)

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

* Вам  требуется  выполнить "многократное чтение" ( сделать в одной транзакции
несколько запросов по одной таблице  будучи  уверенным, что она не меняется).
Этого можно достигнуть лишь применяя не умалчиваемые блокировки или транзакции
в  режиме  "только чтение".

Транзакции типа "только чтение" можно начинать с оператора SET TRANSACTION READ
ONLY,  а перекрывать  умалчиваемые  значения блокировок одним из двух SQL -
операторов:  LOCK TABLE или SELECT FOR UPDATE. Эти операторы используются
исключительно для перекрытия умалчиваемых блокировок данных; невозможно
напрямую управлять блокировками словаря или внутренними блокировками.

            Использование оператора LOCK TABLE

Оператор LOCK  TABLE позволяет вручную перекрыть умалчиваемые блокировки
определенных данных в указанном режиме. Синтаксис опе- ратора следующий:

    LOCK TABLE table [,table] ... IN
         { ROW SHARE |
           ROW EXCLUSIVE |
           SHARE UPDATE |
           SHARE |
           SHARE ROW EXCLUSIVE |
           EXCLUSIVE }
    MODE [ NOWAIT ]
где:

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

lock modes     определяет шесть режимов блокировки, описанных ниже. (ROW SHARE
           и SHARE UPDATE идентичны, поэтому реально используется пять типов
           блокировок)

NOWAIT     указывает, что вы не хотите ожидать начала выполнения блокировки.
           Если  ресурс недоступен, управление сразу же возвращается в Вашу
           прикладную программу, где можно выполнять другую работу, чтобы
           впоследствии вернуться к запросу блокировки.  По умолчанию (если
           опущено NOWAIT)  Вы  будете ожидать освобождения подлежащего
           блокировке ре- сурса.

    Разделяемые и исключительные блокировки

Режимы блокировки варьируются от различных  типов разделяемых блокировок
(shared locks), до исключительных (exclusive).

share locks    Разделяемые блокировки указывают, что блокируемый ресурс может
           различными способами разделяться. Это означает, что несколько
           пользователей могут выполнить несколько разделяемых блокиро- вок
           одного ресурса.


                                   -- 119 --



exclusive lock Исключительная блокировка - это наиболее жесткий тип блокировок.
           Она запрещает любое разделение ресурса (хотя запросы  не
           запрещаются).  Это означает, что первый пользователь, запросивший
           исключительную блокировку, будет единолично владеть ресурсом до
           освобождения блокировки.

            Описание режимов блокировки

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

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

    Exclusive (X)       Исключительные блокировки разрешают выпол-
(исключительная)    нять запросы для заблокированных объектов, но запрещают
                        любые другие действия.

Share (S)           Разделяемые блокировки разрешают запросы,
(разделяемая)       но запрещают изменения в таблицах.

Row Share и         Разделение строк разрешает параллельный
Share Update (RS)   доступ к таблице. Она запрещает другим
(разделение строк   пользователям блокировать таблицу в исклю-
 или разделение     чительном режиме. Разделение строк и раз-
 изменений)         деление изменений являются синонимами (последняя оставлена
                    для совместимости с предыдущими версиями ORACLE RDBMS).

Row Exclusive (RX)  Исключительные для строк блокировки анало-
(исключительная     гичны разделению строк, но кроме того за-
 для строк)         прещают блокировку в разделяемом режиме.  Эти блокировки
                    применяются при изменении, удалении и вставке строк.

Share Row           Блокировки типа исключительного разделения
Exclusive (SRX)     строк используются для просмотра всей таб-
(исключительное     лицы для выборочных изменений и позволяют
 разделение строк)  другим пользователям просматривать строки в этой таблице,
                    но не позволяет блокировать таблицу в разделяемом режиме
                    или для об- новления строк.

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

Рисунок 12-3  показывает режимы блокировок данных и режимы, с которыми они
совместимы.
  Режим       Запрещенные      Разрешенные   Соответствующий
  блокировки  действия         действия      SQL - оператор
  --------------------------------------------------------------
    RS и        исключитель-     Изменения:    SELECR...FOR UPDATE
    Share Update ный доступ: X   RS,RX,S,SRX
    RX         исключительный    Изменения:    UPDATE, INSERT,
               доступ по чтению/  RX, RS       DELETE
               записи: S,SRX,X

                                   -- 120 --



    S          изменения:        Блокировка    LOCK TABLE table IN
               RX, SRX, X        строк: RS,S   SHARE MODE
    SRX        чтение всей таб-  Блокировка    LOCK TABLE table IN
               лицы: RX,S,SRX,X  строк: RS     SHARE ROW EXCLUSIVE
    X          все, кроме за-    запросы       LOCK TABLE table IN
               просов:                         EXCLUSIVE MODE
               RS,RX,S,SRX,X                   и большинство DDL - операторов

Рисунок 12-3 Совместимость режимов блокировки данных

            Эскалация блокировок

В некоторых базах может возникнуть эскалация  блокировок; это происходит в
случае, когда существует несколько блокировок на одном уровне (например -
блокировка строк)  и  RDBMS  автоматически меняет  их  на другие блокировки
более высокого уровня (таких как блокировка таблиц). Следовательно, количество
блокировок уменьшается,  а  их степень повышается.  Эскалация блокировок
значительно увеличивает вероятность тупиковой блокировки. (Тупики описываются
ниже в этой главе).  ORACLE RDBMS не выполняет эскалации блокировок.

        Преобразование блокировок

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

            Когда используется SELECT FOR UPDATE

В дополнение  к  оператору LOCK TABLE умалчиваемые блокировки можно перекрывать
с помощью оператора SELECT FOR UPDATE.  Он  выполняется  в ожидании  проведения
изменений и выполняет исключительную блокировку строк (то же делает и оператор
UPDATE).  Разница между SELECT FOR UPDATE и UPDATE состоит в  том, что SELECT
FOR  UPDATE  блокирует строки раньше.  Сперва он выполняет запрос для выявления
строк, подлежащих блокировке, а затем блокирует этот набор строк.
Осуществляется, как описано ранее, "оптимистичная" блокировка.

Оператор SELECT FOR UPDATE  рекомендуется,  когда  Вы  хотите заблокировать
строку,  реально ее модифицируя.  Например, если Вы обращаетесь к базе для
изменения существующих значений в строках и хотите быть уверены, что строки не
изменит кто-нибудь еще до Вас.

Запрос SELECT FOR UPDATE завершается (и блокировки освобождаются) при выдаче
COMMIT или ROLLBACK.  Оператор SELECT FOR UPDATE предпочтительнее выдавать для
небольшого количества строк.

            Использование оператора SET TRANSACTION READ ONLY

По умолчанию модель непротиворечивости системы  ORACLE  RDBMS гарантирует
согласованность результатов одного оператора. Однако в некоторых ситуациях Вам
необходимо выполнить несколько операторов над набором данных,  заведомо
непротиворечивом. В этом случае Вы можете считать,  что  модель
непротиворечивости  применима  к транзакции (нескольким операторам), а не
только к одному оператору.

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

                                   -- 121 --



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

SQL - оператор SET TRANSACTION READ ONLY используется для начала транзакции
"только чтение". К этому оператору относятся следующие правила:

    * Оператор SET TRANSACTION READ ONLY должен быть первым  опе-
      ратором транзакции; в противном случае возникает ошибка.

    * В  этой  транзакции  допустимы только операторы запросов (и оператор
      завершения  транзакции),  иначе  получите  сообщение  об ошибке (например
      SELECT FOR UPDATE приведет к ошибке).

    * Транзакция завершается операторами COMMIT, ROLLBACK и DDL - операторами
      (последние неявно выдают commit).

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

    * При желании остальные пользователи могут продолжать запрашивать и менять
      данные.

    * Транзакция типа "только чтение" будет видеть только те данные, которые
были записаны в  базу  до  ее  начала;  более  того, независимо от  изменений,
проводимых другими транзакциями,  наша транзакция будет до ее завершения видеть
только данные, с которыми начинала.
    * Слишком длинные транзакции типа "только чтение" могут получать ошибку
"моментальный снимок слишком стар" (snapahot  is  too old). В  этом случае
транзакция должна быть закончена и при необходимости запущена новая.

            Блокировки словаря

    Блокировки словаря выполняются автоматически  системой ORACLE RDBMS в
случае, когда это требуется для выполнения работы пользователя. Пользователи не
могут непосредственно запрашивать  блокировки словаря данных. Если блокируется
одна таблица словаря, весь словарь остается незаблокированным.

    Словарь блокируется с целью  защиты  описания  объектов  базы (таблиц,
обзоров  или  кластеров)  в  процессе  его использования (например - когда
словарь запрашивается в  процессе  разбора  текущего оператора).

        Блокировки разбора

    Блокировка словаря в разделяемом режиме называется  блокировкой разбора.
Она блокирует объект начиная с момента анализирования SQL - оператора и кончая
закрытием курсора или с началом анализирования в этом курсоре другого
оператора.

            Блокировки DDL

Блокировки словаря в исключительном режиме называются  DDL - блокировками. Они
выполняются для SQL - оператора,  потенциально несовместимого с другими
операторами,  ссылающимися на этот  объект. Все DDL - операторы (такие как
CREATE,  DROP,  DROP) требуют исключительной блокировки. Не требуют блокировки
только следующие DDL - операторы:

                                   -- 122 --



    AUDIT  -  NOAUDIT
    GRANT ...
    COMMENT ...
    CREATE SYNONYM
    CREATE VIEW
    CREATE TABLE  (если таблица не кластеризована)
    REVOKE ...

    Эти операторы  не требуют исключительной блокировки словаря и поэтому
допускают разбор курсоров для объектов,  к которым ссылаются.

            Блокировки словаря и кластеры

Блокировки разбора для кластеров, если одна из таблиц кластера заблокирована.
Если кластеризовано несколько таблиц, их данные разделяют общие физические
блоки. Хотя это и не влияет на поведение блокировок уровня строк (блокировки
данных),  DDL - блокировка, примененная к одной таблице кластера, применяется
ко всем его таблицам. Следовательно, если оператор открыт на таблицу,
принадлежащую кластеру, то пока оператор не завершится, в этом кластере нельзя
создать новую таблицу.  Этот вопрос должен рассматриваться при разработке схемы
данных  и  приложений  для  кластеризованных данных.

        Внутренние блокировки и защелки

Внутренние блокировки и защелки защищают базу данных и структуры памяти (эти
структуры недоступны пользователям).  Пользователям нет  необходимости
управлять  их  работой и длительностью.  Предлагаемая информация поможет Вам
интерпретировать  результаты выдачи на  экран команд утилиты SQL*DBA:  MONITOR
LOCKS и MONITOR LATCES.

        Защелки

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

Реализация защелок в значительной мере зависит от операционной  системы,
особенно в  части:  должен  ли  процесс ждать открытия защелки и как долго.  В
выдаче команды MONITOR LATCHES появляются несколько различных типов защелок.
Подробнее об этом смотрите в Приложении В.

            Внутренние блокировки

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

            Блокировки кеша словаря

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

Разделяемые блокировки  освобождаются, когда завершится процесс синтаксического
разбора оператора. Исключительные блокировки освобождаются по завершении
операции DDL.


                                   -- 123 --



        Блокировки управления файлами и журналом

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

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

        Блокировки табличных пространств и сегментов отката

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

        Мониторинг блокировок с помощью SQL*DBA

При работающей базе DBA в любой момент может посмотреть текущие блокировки и
защелки экземпляра ORACLE с помощью утилиты SQL* DBA. Для этого необходимо:
1. Запустить SQL*DBA.
2. Присоединиться к базе (connect) с именем пользователя,имеющим привилегии DBA

    SQLDBA>  CONNECT SYSTEM/MANAGER

3. Затем ввести:

    SQLDBA>  MONITOR LOCKS

    SQLDBA>  MONITOR LATCHES

    Синтаксис и  применение этих команд подробно описаны в Приложении В.
Используя команду SQL*DBA SPOOL, выходную информацию команды MONITIR  можно
записать в файл.  В выходных экранах команды MONITOR приняты следующие
обозначения:
  TM   показывает блокировку данных на таблице. Также выдается идентификатор
       (ID) таблицы. Может присутствовать в любом режиме  блокировки  данных.
       Эта блокировка может быть запрошена  как  явно, так и неявно.
  TX   показывает блокировку транзакции и запрашивается для любой транзакции,
       требующей блокировки строк Указывает идентификатор транзакции,
       заблокировавшей строку. Другие транзакции, желающие  заблокировать
       те же строки должны ожидать освобождения первой блокировки.
  TD   показывает блокировку словаря для таблицы. Указывает идентификатор
       таблицы и может возникнуть только в режиме S  (блокировка  разбора) или
       X (DDL - блокировка).
  TT   показывает блокировку  словаря  для  временного сегмента.
  RT   показывает блокировку журнала.

Заметьте, что  показываются не абсолютно все блокировки.  Это относится к
блокировкам отдельных строк.  Однако появление блокировок транзакции (TX)
указывает, что в ней установлена блокировка строк.

        Выявление тупиков


                                   -- 124 --



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

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

Рисунок 12-4 иллюстрирует тупик для двух пользователей.
    Транзакция А             Время         Транзакция В

    Оператор 1:                            Оператор 2:

    UPDATE EMP                             UPDATE EMP
    SET SAL = 1200                         SET SAL = 1000
    WHERE ENAME = 'LEWIS'                  WHERE ENAME = 'MILLER'
                               X

    Оператор 3:                            Оператор 4:

    UPDATE EMP                             UPDATE EMP
    SET SAL = 1500                         SET SAL = 1750
    WHERE ENAME = 'MILLER'                 WHERE ENAME = 'LEWIS'
                               Y
    Рис. 12-4 Пример тупика у двух процессов.

    В первый  момент (Время Х) каждая транзакция запрашивает блокировку строки
для разных строк.  Однако, когда каждая транзакция пытается (без commit или
завершения транзакции) блокировать строку, уже задержанную друго транзакцией,
возникает тупиковая ситуация. Тупик возникает в момент времени Y,  так как для
нормального или аварийного завершения ни одна из транзакций не может получить
необходимый ресурс и, наоборот, не освобождает своего.

    Если для  оператора 3 будет выполнен roll back,  транзакция В все равно не
сможет быть выполнена,  так как требует ресурс, блокированный в операторе 1.
Таким образом,  чтобы Транзакция А завершилась, необходим откат оператора 4.

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

    Обычно тупики возникают при эскалации блокировок  пользователей. Допустим,
две  транзакции пытаются вставить строки в одну и ту же таблицу,  а значит
запрашивают запрашивают  режим  исключительной блокировки строк. Если затем
каждая транзакция попытается запросить исключительную блокировку (для  чтения
данных,  например), получится тупиковая ситуация.  Так как ORACLE RDBMS сама не
выполняет эскалации блокировок, тупики в системе ORACLE - явление редкое.

            Как избежать тупиковой ситуации




                                   -- 125 --



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

Если Вы выбирает порядок, в котором будут выполняться блокировки в транзакции,
начинать следует с наименее совместимых (более исключительных).

            Параметры SERIALIZABLE и ROW_LOCKING файла INIT.ORA


Замечание: Оставшиеся разделы в основном адресованы  тем, кто работал или
           работает  на  более ранних версиях ORACLE или должен работать в ANSI
           - совместимом режиме.

При запуске экземпляра ORACLE два параметра определяют  порядок обработки
блокировок:  для ORACLE с опцией обработки транзакций SERIALIZIBLE установлен в
FALSE и  ROW_LOCKING  установлен  в ALWAYS.

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

Установка этих параметров производится при остановленном экземпляре ORACLE.
Если к  одной  дисковой   системе   обращаются несколько экземпляров ORACLE,
все они должны использовать одинаковые значения этих параметров.

            Установка значения TRUE для SERIALIZABLE

    Когда параметр SERIALIZABLE установлен в TRUE, все блокировки (и ресурсы)
выполняются на уровне таблиц. Это значит, что если Вы блокируете строку таблицы
( с намерением изменить ее или без  такового), никто  другой  не  сможет
модифицировать ни одной строки данной таблицы.

    Когда параметр SERIALIZABL установлен в  TRUE,  ORACLE  RDBMS так планирует
работу параллельных транзакций, как если бы они работали последовательно.
Пользователь получает возможность запрашивать одну  таблицу  многократно в
течение транзакции с гарантией того, что все запросы "видят" одинаковые данные
("повторное  чтение"), но  за  счет потери параллельности обработки.  Хотя
другие транзакции и могут выполнять запросы к таблице, которую Вы читаете, для
ее изменения они должны дождаться окончания Вашей транзакции.

    Установка параметра SERIALIZABLE в TRUE - это один из способов обеспечения
"повторных чтений".  Далее указаны три других способа достижения этого:
    * использование SERIALIZABLE=FALSE и блокировка таблицы в режиме разделения
      (SHARE)
    * использование оператора SQL: SET TRANSACTION READ ONLY
    * использование во всех запросах  SELECT  FOR  UPDATE,  чтобы заблокировать
      прочитанные строки в исключительном режиме.

        Установка значения INTENT для ROW_LOCKING




                                   -- 126 --



    Если параметр  ROW_LOCKING  установлен в ALWAYS (умалчиваемое значение для
ORACLE с опцией обработки транзакций) и  Вы  меняете данные в  таблице (с
помощью INSERT,  UPDATE или DELETE),  другие пользователи могут менять другие
строки этой таблицы даже  в  момент активности Вашей транзакции.

tак как управление блокировками на уровне  строк возможно только в ORACLE с
опцией обработки транзакций, в системах без обработки транзакций параметр
ROW_LOCKING  всегда  установлен  в INTENT. Если ROW_LOCKING установлен в
INTENT,  то  при  изменении Вами данных в таблице (с помощью INSERT,  UPDATE
или DELETE) другие пользователи не могут ее модифицировать.  Если таблица
заблокирована Вами,  другие  пользователи  могут выполнять запросы или
блокировать строки с помощью SELECT FOR UPDATE,  но для изменения данных будут
вынуждены  ждать окончания Вашей транзакции.  Таким образом, хотя несколько
пользователей и могут выполнять блокировку SELECT  FOR  UPDATE  на той же
таблице (даже в том же блоке), каждый должен ждать окончания исключающей
блокировки для выполнения INSERT, UPDATE или DELETE.

        Резюме для неумалчиваемых блокировок

Так как  для  изменения  способов блокировки в файле INIT.ORA существует два
параметра,  кроме умалчиваемого  есть  возможность задания еще трех вариантов
назначений. На рисунке 12-5 обобщаются возможности неумалчиваемых назначений а
также причины их выбора.
  Вариант                 I              II             III
    ----------------------------------------------------------
     SERIALIZABLE=           FALSE          TRUE           TRUE
     ROW_LOCKING =           INTENT         ALWAYS         INTENT

  Рисунок 12-5    Использование  параметров  SERIALIZABLE  и
                  ROW_LOCKING

Вариант I:  Эквивалентен более ранним версиям ORACLE RDBMS (в таблице не
            параллельных изменений)
Вариант II: ANSI - совместимый
Вариант III:ANSI - совместимый,  с блокировкой на уровне таблицы (в таблице
            не параллельных изменений)

В системе ORACLE с опцией  обработки  транзакций,  включающей возможность
блокировок на уровне строк, параметр SERIALIZABLE установлен в FALSE, с
ROW_LOCKING - в ALWAYS.

Рисунок 12-6 иллюстрирует возможное поведение блокировок,  вытекающие из
вариантов назначения параметров,  показанных на Рис.  12-5.

           Выполняемые блокировки (на уровне строк и таблиц)
  ------------------------------------------------------------
                       Вариант I      Вариант II      Вариант III
    Оператор         строка таблица строка таблица  строка таблица
    --------------------------------------------------------------
    SELECT             -     -         -      S         -     S
    SELECT FOR
    UPDATE             X     RS        X      S         X     S
    LOCK ... IN xxx MODE:

      EXCLUSIVE        X     X         X      X         X     X
      SHARE ROW
      EXCLUSIVE        SRX   SRX       SRX    SRX       SRX   SRX


                                   -- 127 --



      ROW SHARE        RS    RS        RS     RS        RS    RS
      ROW EXCLUSIVE    RX    RX        RX     RX        RX    RX
      SHARE            S     S         S      S         S     S

    INSERT             X     SRX       X      RX        X     SRX
    UPDATE             X     SRX       X      SRX       X     SRX
    DELETE             X     SRX       X      SRX       X     SRX
    DDL/DCL            -     X         -      X         -     X
 Рисунок 12-6 Варианты неумалчиваемых блокировок.

KOAP Open Portal 2000



Яндекс цитирования