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






     ГЛАВА 19           ПОВЫШЕНИЕ ЭФФЕКТИВНОСТИ ПРИЛОЖЕНИЙ

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

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

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

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

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

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

Замечание: Информация, содержащаяся в этой главе, относится к текущей версии
           ORACLE RDBMS на время написания этого руководства; эта информация
           является объектом изменений в будущих реализациях.

            Важность проектирования хорошей реляционной таблицы

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

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

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

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


                                   -- 197 --



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

        Старшинство операций внутри оператора

Использование скобок вносит ясность в смысл комплексных SQL - операторов и
потому рекомендуется.  Например, без скобок смысл следующего оператора не
очевиден:
    SELECT ENAME, DEPTNO
    FROM EMP
    WHERE JOB = 'CLERCK'
    AND DEPTNO = 10
    OR  DEPTNO = 20

так как может интерпретироваться как один из двух запросов:

1. "Выдать имена и отделы всех клерков в  отделе  10  и  всех сотрудников в
    отделе 20"   или
2. "Выдать имена и отделы всех клерков,  но только  если  они работают в
    отделах 10 или 20"

Допустим, мы хотим увидеть запрос номер 2: имена и номера отделов всех клерков,
которые работают в отделах 20 или 30. Если мы добавим знаки пунктуации, мы
можем изменить смысл запроса (и следовательно - результат) поскольку внесем
ясность в  наши  намерения. Если мы не используем знаки пунктуации:
    SELECT ENAME, DEPTNO
    FROM EMP
    WHERE JOB = 'CLERCK'
    AND DEPTNO = 20
    OR  DEPTNO = 30

то в результате получим всех клерков,  работающих в отделе 20 и всех без
исключения сотрудников отдела 30:
    ENAME               DEPTNO
    -------------  ------------
    ALLEN                   30
    WARD                    30
    MARTIN                  30
    TURNER                  30
    ADAMS                   20
    JAMES                   20

Если мы возьмем в скобки (DEPTNO =20 or DEPTNO =30) :
    SELECT ENAME, DEPTNO
    FROM EMP
    WHERE JOB = 'CLERCK'
    AND ( DEPTNO = 20
    OR  DEPTNO = 30 )

то в результате получим всех клерков, работающих в отделах 20 и 30 (желаемый
результат):
    ENAME               DEPTNO
    -------------  ------------
    ADAMS                   20
    JAMES                   20



                                   -- 198 --



Если мы  добавим  скобки  в  другом  месте  (JOB = 'CLERC' OR DEPTNO = 20) :
    SELECT ENAME, DEPTNO
    FROM EMP
    WHERE ( JOB = 'CLERCK'
    AND  DEPTNO = 20 )
    OR  DEPTNO = 30

В результате  мы  получим то же,  что и в варианте без знаков пунктуации, но в
последнем случае  результат  однозначный  -  все клерки, работающие в отделе 20
и все сотрудники отдела 30 :
    ENAME               DEPTNO
    -------------  ------------
    ALLEN                   30
    WARD                    30
    MARTIN                  30
    TURNER                  30
    ADAMS                   20
    JAMES                   20

              Эффективное использование языка SQL

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

    Кроме того,  освойте многие  функции  языка  SQL,  такие  как DECODE,
SUBSTR и INSTR.  Вы будете поражены простотой,  с которой реализуются
комплексные запросы и манипуляция с данными.
За более подробной информацией  об  языке  SQL  обратитесь  к "Справочному
руководству по языку SQL".

        Оптимизация, выполняемая автоматически

Этот раздел кратко описывает работу некоторых средств оптимизации системы
ORACLE,  которыми вы не можете управлять вообще или управлять весьма слабо.
Следующие далее разделы описывают ситуации, с  которыми Вы можете столкнуться,
перестраивая предложение на языке SQL.

      Использование ключевого слова DISTINCT

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

      Использование ключевого слова GROUP BY

    Запросы GROUP BY обрабатываются аналогично с DISTINCT. Выбрав строки,
ORACLE их сортирует,  формируя при этом в группы и удаляя дублирования (если
они возникают).  Индексы не участвуют в выполнении GROUP  BY  (хотя  они  могут
использоваться в других частях запроса).

      Подзапросы

    Некоторые подзапросы автоматически преобразуются в  объединения.  Запросы,
содержащие IN иногда не могут быть преобразованы в объединения. Например:

                                   -- 199 --



    SELECT * FROM EMP
    WHERE EMP.DEPTNO IN
    ( SELECT DEPTNO FROM EMP )

может быть обработан как следующий логический запрос, имеющий НЕПРАВИЛЬНЫЙ
синтаксис языка SQL:
    SELECT EMP.A FROM EMP, D:
    (SELECT DISTINCT DEPTNO FROM DEPT)
    WHERE D.DEPTNO = EMP.DEPTNO

Другие аналогичные преобразования выполняются автоматически.

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

Если таблица во фразе FROM гарантированно указывает на единственную  строку,
эта  строка в объединении располагается первой.  Приведем примеры этого:
* уникальный индекс вместе с WHERE = константа
* обзоры с единственным   результатом  (например  -SELECT AVG(SAL) FROM EMP)
* путь доступа через ROWID.

        Использование преимуществ индексов в SQL - операторах

ORACLE RDBMS может обращаться к данным таблиц двумя способами:
* используя полное сканирование таблицы
* используя индексы

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

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

    Индекс может быть полезен в следующих случаях:

* если он ссылается на предикат.  Предикат - это любая  часть критерия выбора,
используемая для включения строк в результат или исключения их.  Например,
следующая фраза WHERE содержит два предиката:
        WHERE DNAME = 'DEVELOPMENT'
        AND SEX != 'FEMALE'

* индексируемый столбец не меняется функцией или арифметической операцией

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

Индекс не будет использоваться в следующих случаях:
* нет фразы WHERE
* предикат каким-либо способом модифицирует индексный столбец (через функцию
  или арифметическое выражение)
* для поиска явно по значениям NULL или NOT NULL  в индексных столбцах (это
  означает,  что  в предикатах явно используется "IS NULL" или "IS NOT NULL").

                                   -- 200 --



Индекс не  может  быть использован,  если столбец должен быть модифицирован для
приведения к критерию выбора.  Ниже даны примеры предикатов, в которых индекс
не будет использоваться:

    WHERE SAL * 12 = 24000
    WHERE SAL + 0 = 500
    WHERE ' '||ENAME = ' Smith'
    WHERE SUBSTR(ENAME, 1, 1) = 'S'

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

    { MIN | MAX | ( col { + | - } constant }

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

    SELECT 2 * MAX (SAL + 1) FROM EMP

      Создание эффективных индексов

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

В последующих примерах предполагается,  что создан  следующий конкатенированный
индекс:
    CREATE INDEX INDNAME_CITY_STATE ON
    EMPLOYEE (LAST_NAME, CITY, STATE)

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

    SELECT ...
    FROM EMPLOYEE
    WHERE LAST_NAME = 'SMITH'
    AND CITY = 'FREDERIK'
    AND STATE = 'MD'

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

    SELECT ...
    FROM EMPLOYEE
    WHERE LAST_NAME = 'JONES'

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

    SELECT SITY, STATE
    FROM EMP
    WHERE LAST_NAME = 'JONES'



                                   -- 201 --



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

    SELECT ...
    FROM EMPLOYEE
    WHERE CITY = 'BLACKSBURG'
    AND STATE = 'MD'

    SELECT ...
    FROM EMPLOYEE
    WHERE STATE = 'DC'

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

    SELECT * FROM EMP
    WHERE TO_CHAR(HIREDATE, 'Month dd, yyyy') = 'January 14, 1986'

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

Следующий пример также будет использовать индекс:

    SELECT * FROM EMP
    WHERE HIREDATE = '1-JAN-86'

          Единственный индекс

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

Рассмотрим запрос:

    SELECT EMPNO, ENAME FROM EMP
    WHERE JOB = 'CLERK'

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

      Индексы и значения NULL

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


                                   -- 202 --



то индекс использоваться не будет.  Однако если Вы хотите получить из запроса
не пустые значения  (т.е.  не  значения  NULL), можно написать SQL - оператор,
который будет обрабатываться с использованием индекса.  Это может быть сделано
лишь  для  возврата запросом строк, НЕ содержащих значение NULL.

Например, если вы хотите посмотреть всех сотрудников, имеющих комиссионные (чьи
комиссионные NOT NULL),  можно ввести следующие запросы:

    Запрос 1:                                  Запрос 2:
    SELECT * FROM EMP                          SELECT * FROM EMP
    WHERE COMM IS NOT NULL                     WHERE COMM >= 0

В предположении, что для столбца COMM индекс существует, можно утверждать, что
он не будет использоваться в Запросе 1,  но в Запросе 2 он будет использоваться
для получения  результатов  без выполнения полного сканирования.  Однако, если
большинство записей в таблице EMP (более 25%) имеют значение в столбце COMM,
Запрос 1 предпочтительнее. Запрос 2 предпочтителен, если большинство записей
имеют значение NULL в столбце COMM.

      Несколько индексов на одной таблице

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

Данные, возвращаемые для каждого индекса, "сливаются" из первичных  результатов
для получения конечного результата. Несколько индексов не используется для
предикатов типа "ограничение  диапазона и равенство" (таких как: DEPTNO != 10),
как например:
    SELECT *
    FROM EMP
    WHERE JOB = 'MANAGER'
    AND DEPT != 10

В этом примере запрос будет выполняться только за счет индекса JOB.

      Выбор из множества индексов

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

    Если доступны как уникальный,  так  и  неуникальный  индексы, ORACLE
использует  уникальный  индекс и игнорирует неуникальный, избегая таким
образом,  "слияния". Допустим, что EMPNO - уникальный индекс, а SAL -
неуникальный, рассмотрим запрос:

    SELECT ENAME
    FROM EMP
    WHERE SAL = 3000
    AND EMPNO = 7902

    Для выполнения этого запроса ORACLE будет использовать только индекс EMPNO.
Если найдена строка со значением EMPNO = 7902, проверяется реальное  поле  SAL
на  предмет   нахождения   значения 3000 вместо использования индекса SAL.



                                   -- 203 --



    Максимально можно слить до пяти (5) индексов.  Если в запросе более пяти
критериев (предикатов фразы WHERE), сливаться будет не более пяти индексов,  а
оставшиеся данные проверяются "вручную" с целью выбрать записи, удовлетворяющие
оставшимся критериям.

      Подавление использования индексов

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

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

    SELECT ENAME, DEPTNO, SAL
    FROM EMP
    WHERE DEPTNO + 0 = 20
    AND ENAME = 'SMITH'

        Оптимизация различных SQL - операторов

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

      Оптимизация запросов (SELECT)

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

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

Например - оценка первого предиката во фразе WHERE исключает 75% строк большой
таблицы, в то время как оценка другого предиката может исключить только 15%.

oRACLE использует различные внутренние алгоритмы  для  выбора точки (называемой
"ведущим" столбцом или условием), с которой начинается тестирование по всем
выражениям фразы WHERE.

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


                                   -- 204 --



Ниже показаны общие правила сравнения различных путей:
  Эти пути быстрее                     чем эти пути
    ----------------------------------------------------------
    индексированные столбцы              не индексированные столбцы
    уникальные индексы                   неуникальные индексы
    ROWID (=константа)                   любой другой поиск
    ограниченный диапазон                неограниченный диапазон
    сравнение по образцу вида 'x%'       -------"-------- '%x%'

              Оптимизация отрицаний (NOT)

    ORACLE не использует индексы для предикатов, содержащих выражения "не
равно" (!= или NOT=), хотя он может использовать индекс для другого предиката.
Например, в выражении:

    WHERE X != 7 AND Y = 8

индекс не  используется  для  столбца X,  но используется для столбца Y.
Обычно в запросах с  "NOT="  количество  возвращаемых строк больше,  чем
количество пропущенных.  ORACLE для чтения индекса и затем - таблицы
затрачивает  дополнительный  ввод/вывод.  Таким образом,  может  получиться
быстрее  просто просканировать таблицу, нежели использовать индекс.

Если предикат  содержит  NOT  вместе  с  другими  операциями, ORACLE
преобразует его в вид, позволяющий использовать индексы:
  Исходный            Преобразованный
    ----------------------------------Д
    NOT >                   <=
    NOT >=                  <
    NOT <                   >=
    NOT <=                  >

          Оптимизация операции OR

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

Допустим, существует запрос:
    SELECT *
    FROM EMP
    WHERE DEPTNO = 10 OR JOB = 'CLERK'

в котором оба столбца - и DEPTNO,  и  JOB  -  имеют  индексы.  ORACLE будет
использовать  оба индекса и выполнять что-то вроде объединения следующих
запросов:
    Запрос 1:                              Запрос 2:
    SELECT *                               SELECT *
    FROM EMP                               FROM EMP
                                           AND DEPTNO != 10

Помня об  этом,  лучше  помещать более спецефичный индекс в начале списка
предикатов (или индекс,  пропускающий большее количество записей).  Этим  Вы
минимизируете количество проверок типа "НЕ РАВНО".




                                   -- 205 --



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

Кроме того,  оптимизация применяется во  фразах  IN,  которые транслируются в
OR. Так например, следующая фраза:

    DEPTNO IN (X, Y, Z)
    OR DEPTNO = Z

означает то же, что и:

    DEPTNO = X OR DEPTNO = Y OR DEPTNO = Z

              Программа сортировки/объединения системы ORACLE

Программа сортировки/объединения  системы ORACLE ускоряет выполнение таких
операций как: CREATE INDEX, SELECL DISTINCT, ORDER BY,  GROUP BY и некоторых
объединений.  Попросту говоря,  данные, которые должны быть упорядочены,
сперва подвергаются  внутренней сортировке  по  определенным критериям и затем
сливаются в конечный, отсортированный вариант.

На работу программы сортировки/объединения влияют три параметра; они начинаются
с префикса SORT и описаны в приложении D.

Кроме того, на ее работу влияют две рабочие области:

internal         Этот размер устанавливается параметром файла
(внутренняя)     INIT.ORA - SORT_AREA_SIZE.

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

        Оптимизация ORDER BY

  Хотя для достижения упорядоченности существует несколько способов написания
SQL - оператора,  гарантировать это может только наличие в конце оператора
фразы ORDER BY.

Упорядоченные результаты,  получившиеся   без   использования ORDER BY,  в
следующих версиях системы ORACLE могут оказаться не упорядоченными. Таким
образом, рекомендуется явное упорядочение с помощью фразы ORDER BY.

В запросе, содержащем фразу ORDER BY, данные сперва выбираются, а затем уже
сортируются с помощью  либо  доступных  индексов, либо с помощью программы
сортировки/объединения.

      Оптимизация GROUP BY

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

                                   -- 206 --



    SELECT JOB, AVG(SAL)
    FROM EMP
    WHERE JOB != 'PRESIDENT' AND JOB != 'MANAGER'
    GROUP BY JOB

лучше, нежели чем такой:

    SELECT JOB, AVG(SAL)
    FROM EMP
    GROUP BY JOB
    HAVING JOB != 'PRESIDENT' AND JOB != 'MANAGER'

по двум причинам:

    1. Так как запрос 2 не содержит фразы WHERE, все существующие строки
включаются  в  работу  фразы  GROUP BY.  Сюда включаются и строки, которые
должны быть пропущены и удалены ранее  с  помощью фразы WHERE.

    2. Фразы HAVING используются для удаления данных,  сгруппированных по
определенному критерию (например -  меньше минимального или больше среднего).
Хотя синтаксис этих фраз и аналогичен фразе WHERE,  они не позволяют (и,
следовательно, не должны) использоваться взаимозаменяемо с WHERE.

      Оптимизация объединений

Ниже приведены основные правила  для  оптимизации  выполнения объединений:

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

      Неиндексированные объединения

Если столбцы,  участвующие в объединении,  не  индексированы, при выполнении
следующих условий выполняется операция "сортировки /объединения":

    * если  не  существует  другого  способа  выполнения  запроса (если ORACLE
      определит,  что можно использовать индексы, он будет использовать их, а
      не сортировку/объединение)

    * фраза объединения должна быть следующего вида:
         tab_a.expression = tab_b.expression
         как например:
         tab_a.col_a + 1 = to_number (tab_b.col_b)

    Например - объединение не может содержать "больше или равно".

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

Если существуют  дополнительные  предикаты отбора (например - DEPTNO = 20),
поместите наиболее "селективные" предикаты в конец списка.

      Индексированные объединения


                                   -- 207 --



Если только одна из сцепляемых таблиц  имеет  индекс,  другая таблица  будет
ведущей  в  выполнении  запроса.  Например,  если EMP.DEPTNO индексирован,  а
DEPT.DEPTNO - нет,  тогда в следующих запросах DEPT будет ведущей таблицей:

    SELECT ENAME, DNAME             SELECT ENAME, DNAME
    FROM DEPT, EMP                  FROM EMP, DEPT
    WHERE EMP.DEPTNO =              WHERE EMP.DEPTNO =
         DEPT.DEPTNO                     DEPT.DEPTNO
    AND JOB != 'SALESMAN'           AND JOB != 'SALESMAN'

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

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

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

    Имейте в виду, что:

* Каждый предикат,  сцепленный с помощью ключевого слова AND, вычисляется
  независимо в соответствии со  значениями,  указанными на Рис. 19-1 начиная с
  наименьших (быстрых) к большим (медленным).

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

Следовательно, необходимо большие таблицы с наименьшим числом подходящих строк
располагать во фразе FROM -  последними,  а  при написании мультитабличных
объединений (3 или более таблиц) располагать пары таблиц с минимальным
результатом ранжирования в конце объединения.

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

Чем ниже ранг, тем быстрее путь доступа
    Ранг        Путь
    1           ROWID = constant
    2           уникально индексированный столбец = constant
    3           полностью уникальный конкатенированный индекс= constant
    4           полный ключ кластера = соответствующему кластерному ключу в
                другой таблице того же кластера

                                   -- 208 --



    5           полный ключ кластера = constant
    6           полный неуникальный конкатенированный индекс= constant
    7           неуникальный индекс = constant
    8           полный конкатенированный индекс = нижняя граница
    9           специфицировано начало конкатенированного индекса
    10          уникально индексированный столбец специфицирован с помощью
                выражения BETWEEN ... AND ...; уникально индексированный
                столбец специфицирован: LIKE 'C%' (ограниченный диапазон)
    11          неуникально индексированный столбец специфицирован с помощью
                выражения BETWEEN ... AND ...; неуникально индексированный
                столбец специфицирован: LIKE 'C%' (ограниченный диапазон)
    12          уникально индексированный столбец или константа (не-
                ограниченный диапазон)
    13          неуникально индексированный столбец или константа (не-
                ограниченный диапазон)
    14          сортировка/объединение (только объединения)
    15          MAX или MIN на единственном индексированном столбце
    16          ORDER BY для полного индекса
    17          полное сканирование таблицы
    18          не индексированный столбец = constant или IS NULL или LIKE
                '%C%' (полное сканирование таблицы)
    Рисунок 19-1 Способы запросов, ранжированные по скорости

        Векторная обработка

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

    Пользователи могут заметить повышение  эффективности  при  использовании
массивов  для  операторов  INSERT  и  SELECT в языках программирования.
Описание вызовов и типов данных приведено в соответствующих руководствах  по
языкам программирования,  например "Руководстве пользователя по Pro*FORTRAN"

        Как избежать повторного разбора и связывания переменных

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

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

Прекомпиляторы предлагают   две   опции   командной   строки:  HOLD_CURSOR=YES
и  REBIND=NO для сохранения курсоров открытыми а также для сохранения связанных
переменных и  разобранного  SQL  - оператора.  Следовательно, курсоры
сохранятся, а операторы не будут анализироваться повторно, даже если каждый из
них выполняется много раз.

Например, на одном из тестов с транзакцией, состоящей из двух десятков
операторов, время ответа благодаря использованию HOLD_CURSOR=YES и REBIND=NO
сократилось с 20 до 4 секунд.

             ГЛАВА 20        НАСТРОЙКА БАЗЫ ДАННЫХ

                                   -- 209 --



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

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

    ORACLE RDBMS поддерживается DBA с точки зрения ее настройки и мониторинга.
Настройка базы может выполняться различными способами, например - упорядочением
различных структур базы или варьированием параметров файла INIT.ORA. Мониторинг
работы базы может выполняться с помощью регулярного просмотра и анализа
информации, выдаваемой командой MONITOR утилиты SQL*DBA.

        Основные концепции настройки базы

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

Архитектура ORACLE RDBMS Version 6 содержит некоторые возможности, специально
предназначенные для высокой производительности, которые включают в себя:
    * блокировку на уровне строк
    * косвенную запись

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

Высокая параллельность работы ORACLE  RDBMS  Version  6  дает возможность более
полно использовать  вычислительные мощности, предоставляемые многопроцессорными
машинами.  Эти  машины  обычно предоставляют большую вычислительную  мощность
по отношению к цене по сравнению с однопроцессорными.  Так как мощность CPU
значительно определяет прохождение транзакции в ORACLE RDBMS Version 6,
мультипроцессорность очень выгодна.

Две основные концепции связаны с настройкой базы:
    * оптимизация использования памяти
    * оптимизация дискового ввода/вывода

    Другими словами, Вам надо оптимизировать и производительность и память.
Цель настройки состоит балансе загрузки памяти (процессора) и ввода/вывода.  В
оптимально настроенных системах как CPU, так и диски загружены почти на 100
процентов.


                                   -- 210 --



      Знайте требования пользователей

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

* Сколько в среднем пользователей с уникальными именами будут одновременно
  работать в системе ?
* Каково максимальное количество пользователей может пожелать работать в
  системе ?
* Какое количество пользователей будет выполнять определенные действия ?
  Например - какое количество пользователей  будет  ис- пользовать SQL*Forms, в
  то время как все остальные - Pro*FORTRAN?  Или будут ли все пользователи
  выполнять на SQL*Plus запросы  спе- циального типа ?
* Для широко используемых прикладных программ: какова средняя и максимальная
  длина транзакции?
* Какая учетная информация необходима? Какая - желательна ?
* Какие типы SQL - операторов наиболее часто применяются в широко используемых
приложениях ?  Будут ли пользователи выдавать запросы по  большому или малому
числу таблиц ?  Потребуется ли им много временных сегментов ?  Будут ли многие
пользователи  созда- вать таблицы или менять привилегии ?
* Насколько сложной будет схема данных  ?  Будут ли таблицы нормализованы или
  файлы операционной системы будут просто преобразованы в таблицы ?
* Внимательно ли будут выбираться индексы и кластеры ?

      Как настраивать эффективно ?

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

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

          Уровни настройки системы

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

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

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

Оптимизация разработки приложений включает применение в прикладных программах
инструментальных   средств,   таких   как SQL*Menu, SQL*Forms,  PRO* -
прекомпиляторы.  Этот широкий раздел лишь слегка раскрыт в данной главе.
Необходимо обратиться к доку- ментации по каждому конкретному продукту.

                                   -- 211 --



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

    Настройка конфигурации ORACLE RDBMS включает в себя основы правильного
применения переменных параметров  файла  INIT.ORA.  Эта  тема  раскрывается  в
данной главе,  а Приложение D содержит полное описание файла INIT.ORA и каждого
параметра в отдельности.

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

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

      Основные средства настройки

Сама система  ORACLE RDBMS содержит многие средства,  которые поддаются
настройке администратором базы. Они включают в себя:
    * файл конфигурации системы (INIT.ORA)
    * управление буферами
    * фоновый процесс DBWR
    * фоновый процесс LGWR
    * сегменты отката.

        Настройка во время инсталяции

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

      Пример действий по настройке операционной системы

Информация, похожая на приведенную описывается в руководствах по инсталяции:

* предлагаемые структуры каталогов и расположения файлов системы ORACLE
* требования и рекомендации по внешней памяти
* требования и рекомендации по оперативной памяти
* привилегии и приоритеты процессов
* преимущества разделяемого кода ORACLE
* предпочтительные устройства внешней памяти (например - по скорости и емкости)
* DMA (direct memory access - прямой доступ к памяти)
* использование системы и ее загрузка

      Назначение приоритетов процессам




                                   -- 212 --



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

      Избежание фрагментации дисков

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

        Техника быстрой настройки

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

* Поместите файл журнала повторного выполнения на устройство, отличное от
  файлов базы.
* Снизьте частоту контрольных точек,  увеличив значение параметра
  LOG_CHECKPOINT_INTERVAL файла INIT.ORA.
* Уменьшите частоту распределений журнала,  увеличив значение параметра
  LOG_ALLOCATION.
* Увеличьте размер SGA за счет увеличения параметра DB_BLOCK_ BUFFERS.

* В дополнение к сегменту отката SYSTEM создайте дополнительные сегменты.

        Оптимизация ввода/вывода

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

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

Воздействовать на ввод/вывод можно различными  способами, включая следующие:

* экспериментирование с различными параметрами памяти отделных объектов базы
* оптимизация использования дисков  путем  размещения  файлов данных на
  различных дисках
* разделение данных и индексов размещением их в различных табличных
  пространствах
* оптимизация SGA


                                   -- 213 --



      Мониторинг В/В с помощью SQL*DBA

Чтобы посмотреть  физическое  число  чтений и записей на диск относительно
файлов, можно использовать команду MONITOR FILE. Для примера использования
этой  команды  и интерпретации результатов обратитесь к Приложению В.

      Использование табличных пространств по умолчанию

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

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

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

      Минимизация количества экстентов

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

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

    Чтобы посмотреть,  сколько экстентов занимает таблица или индекс, запросите
обзор USER_SEGMENTS словаря данных.

Чтобы минимизировать количество экстентов, воспользуйтесь одним (или
несколькими) из указанных методов:

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


                                   -- 214 --



Для объединения  экстентов таблицы применяется следующая последовательность
действий:
    1. Переименуйте основную таблицу.
    2. Создайте новую таблицу с настроенными соответственно параметрами памяти.
    3. Скопируйте данные в новую таблицу и проверьте их.
    4. Удалите старую таблицу.
    5. Пересоздайте индексы.

      Когда желательно большее количество экстентов

    Иногда бывает  желательно  распределить  данные по нескольким экстентам для
уменьшения заполнености  блоков  ускорения  многих параллельных модификаций.
Это  особенно полезно в случае,  когда таблица очень интенсивно меняется.  В
этом случае более приемлемо иметь меньшее количество строк на блок и,
следовательно, увеличивается общее количество блоков.  (Хотя  количество
блоков  будет расти, количество экстентов может расти,  а может и нет - в
зависимости от параметров памяти FIRST, NEXT, PCTINCREASE).

    Чтобы уменьшить количество памяти (а значит - и строк) блока, доступного
таблице, увеличьте значение параметра памяти PCTFREE в операторе CREATE  TABLE.
Указав значение PCTFREE,  равное 95-99, можно снизить число строк таблицы в
блоке до одного. (Не забудьте соответственно уменьшить значение параметра
PCTUSED).

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

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

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

      Снижение частоты распределения экстентов

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

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


                                   -- 215 --



      Разделение индексов и данных

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

    Местоположение таблиц и индексов в базе определяется в момент создания этих
объектов.  Операторы  CREATE  TABLE и CREATE INDEX должны ссылаться на
различные табличные пространства (файлы, входящие в эти пространства должны
располагаться на разных дисках).

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

Для изменения табличного пространства для индекса надо просто отменить индекс и
создать заново в требуемом пространстве.

          "Растягивание" больших таблиц

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

1. Создать табличное пространство,  состоящее из  10  файлов, каждый немного
   больше 10 Мбайтов (для некоторых накладных расходов). Причем создайте все
   файлы на разных дисках.
2. Создайте таблицу, используя следующие параметры памяти:
    storage(initial 10m next 10m minextents 10 pctincrease 0)
3. Когда таблица загрузится, данные будут распределены по десяти файлам, причем
   нет необходимости загружать сразу же все данные.

          В/В для файлов базы данных и управляющих файлов

    Система ORACLE в дополнение к файлам программного обеспечения требует по
крайней мере один файл базы,  один управляющий  и  два файла журнала повторного
выполнения.  Оптимальное размещение файлов влияет на производительность системы
и стратегию восстановления в случае аварии носителя.  Относительно размещения
управляющих файлов и файлов базы можно сказать следующее:
* во избежание соперничества за в/в помещайте файлы  базы  на различные диски
* помещайте несколько копий управляющих файлов  на  различные диски.

      В/В файла журнала

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

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



                                   -- 216 --



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

               Оптимизация управления буферами

    Следующее описание  применимо для ORACLE Version 6.0.26 и ниже. Описание
для версии 6.0.27 и выше приведено в "Руководстве по настройке
производительности базы".

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

Так как запись модифицированных буферов косвенна до  выполнения commit, большое
количество  модифицированных буферов должно храниться в кеше одновременно. Для
поддержания параллельной обработки важно точно идентифицировать, какие блоки
должны остаться в кеше, к какие - быть записаны на диск.  Таким образом,
настройка управления буфером,  буферным пулом и процессом DBWR может
значительно влиять на производительность.

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

    Программа администратор буфера  системы  ORACLE  поддерживает LRU - список
буферов (Least Recently Used).  В этом списке буферы упорядочены на основании
того, насколько давно к ним было последнее обращение. В вершине списка
находится буфер, использовавшийся последним,  а внизу списка - наиболее долго
не  использовавшийся.  Администратор  буфера  гарантирует,  что более часто
используемые данные будут находиться в кеше большее время, чем менее часто
используемые.

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

    Если буфер не используется в течение длительного  времени,  он постепенно
мигрирует  в конец списка LRU и однажды будет "очищен" процессом DBWR и затем
заполнен новой информацией.  Буфер, содержащий модифицированные данные, не
может быть помечен "свободным", пока его содержимое не будет скопировано на
диск процессом DBWR.

      Мониторинг буферов

    Для отслеживания  работы  администратора  буфера используется команда
SQL*DBA MONITOR с опцией STATISTICS.  С работой администратора буфера связана
следующая статистика:
    * физические чтения
    * физическая запись
    * ожидание из-за занятости буферов

     Увеличение количества буферов базы

                                   -- 217 --



Наиболее важный  параметр  файла INIT.ORA,  который Вы можете менять -
DB_BLOCK_BUFFERS.  Он управляет количеством буферов в буферном пуле базы.

Умалчиваемое значение  32 слишком мало для большинства реальных баз.  Более
реально число между 100 и 200. Если Ваша база занимает более  100  мегабайтов,
необходимо  рассмотреть установку этого параметра до 1000 и более.  В больших
системах  VAX/VMS  (с памятью 64  Мбайтов)  конфигурируется буферный пул до 20
Мбайтов.  Конкретное значение,  однако,  зависит от работающих приложений и от
операционной системы.

Увеличивая значение DB_BLOCK_BUFFERS, Вы также увеличиваете:
    * размер области SGA (буферный пул)
    * общее количество данных, которые могут кешироваться
    * вероятность того, что данные останутся в буфере
    * использованную оперативную память
    * страничный обмен

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

      Снижение конкуренции на уровне блоков

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

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

        Настройка процесса DBWR

    Следующее описание  применимо для ORACLE Version 6.0.26 и ниже. Описание
для версии 6.0.27 и выше приведено в "Руководстве по настройке
производительности базы".

    Если параметр DB_BLOCK_BUFFERS назначает 500 и менее буферов, умалчиваемые
параметры файла INIT.ORA будут обеспечивать удовлетворительную эффективность.
Однако,  если  Вы установили значение этого параметра более 500, необходимо
настроить систему таким образом, чтобы  уменьшить суммарную работу для процесса
DBWR и процессов пользователей.

Наиболее полезны при настройке DBWR следующие параметры:
    * DB_BLOCK_MAX_MOD_PCT
    * DB_BLOCK_MAX_CLEAN_PCT
    * DB_BLOCK_TIMEOUT_WRITE_PCT
Каждый параметр представляет из себя процент от DB_BLOCK_BUFFERS


                                   -- 218 --



      Как работает DBWR

В момент поиска свободного буфера в списке LRU процесс пользователя посчитывает
количество пропущенных буферов.  Как  только процесс   пропустит количество
буферов,  большее  чем  процент DB_BLOCK_MAX_MOD, он сообщит об этом процессу
DBWR, чтобы последний начал очистку буферов. Пользовательский процесс прекратит
поиск свободного буфера, когда переберет кол-во буферов DB_BLOCK_MAX_SCAN_PCT,
если в этом случае он не найдет свободного буфера, будет увеличено значение
статистической записи "dbwr free needed", что означает, что пользовательский
процесс ожидает, пока DBWR очистит буфер для использования.

    Когда возникает такое событие,  процесс DBWR начинает чистить список LRU
начиная с "наиболее раннего  использованного  буфера".  Если  буфер содержит
измененные данные,  DBWR "очищает" его путем записи информации на диск и  затем
помечает  свободным.  Процесс чистки продолжается до тех пор, пока не будет
очищен процент блоков, равный DB_BLOCK_MAX_CLEAN_PCT.

    В моменты, когда база не загружена, процесс DBWR периодически просыпается
(в  моменты  "timeout")  и  очищает  столько  блоков, сколько указано в
DB_BLOCK_TIMEOUT_WRITE_PCT. Если система не занята довольно долго, DBWR
периодически очищает весь буферный пул.

Таким образом, процесс DBWR уведомляется в двух случаях:
* когда процесс пользователя прочитал больше чем DB_BLOCK_MAX_MOD_PCT буферов в
  поисках свободного
* периодически, во время таймаутов.

      Мониторинг DBWR

Для отслеживания работы процесса  DBWR  используется  команда MONITOR
STATISTICS  утилиты  SQL*DBA.  Можно  попытаться получить следующую статистику
низкого уровня:  (Полное описание дано в Приложении В)
    * DBWR buffers scanned
    * DBWR free low
    * DBWR free needed
    * DBWR timeouts
    * free buffer inspected
    * free buffer waits

Используя команду MONITOR LATCH можно отследить следующие защелки (блокировки
низкого уровня):
    * cache buffer chains
    * cache buffers LRU chain

Для двух  последних  защелок  число в столбце TIMEOUTS должно быть взято
минимальным.

      Минимизация работы DBWR

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

Если DBWR не работает достаточно четко, системе будет не хватать свободных
буферов, и пользователи будут ждать их освобождения. Статистика  DBWR free
needed показывает,  сколько раз в системе случалась нехватка свободных буферов.
Это значение надо стараться свести к минимуму.



                                   -- 219 --



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

В процессе  очистки DBWR запрашивает и освобождает блокировки буферов и частей
списка LRU. Это блокирование будет конкурировать с пользовательскими процессами
в случае, когда DBWR слишком активен. Однако,  количество буферов,  которые он
очистит  за  каждый просмотр, будет снижаться до минимума. Параметр файла
INIT.ORA DB_BLOCK_MAX_CLEAN_PCT определяет максимальное  количество  буферов,
которые будет очищать DBWR;  действительное количество показывается в элементе
статистики DBWR buffers scanned.

Если буферный пул содержит много модифицированных блоков, процесс пользователя
должен затратить большее время на поиск свободного.  Количество просмотренных
при поиске буферов должно быть по возможности - минимизировано.  Максимальное
количество буферов, которые пользовательский процесс будет просматривать  в
поисках свободного, устанавливается в файле INIT.ORA параметром DB_BLOCK_
MAX_SCAN_PCT; действительное количество  просканированных буферов отмечается в
параметре статистики free buffers inspected.

Уменьшение параметра DB_BLOCK_MAX_MOD_PCT будет снижать показатель статистики
free buffers inspected, в то время как его увеличение - понижает параметр DBWR
buffers scanned.  Вследствие того, что желательно иметь небольшими  оба  этих
показателя,  надо попробовать несколько  значений  параметра
DB_BLOCK_MAX_MOD_PCT и выбрать оптимальное значение.

    Значения показателей DBWR free needed  и  free  buffer  waits всегда должны
быть нулевыми.  Если это не так,  необходимо увеличить значение параметра
DB_BLOCK_MAX_CLEAN_PCT.

        Настройка журнала повторного выполнения

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

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

Фоновый процесс LGWR уведомляется о следующих событиях:
    * когда требуется commit
    * когда процессу LGWR необходимо очистить блоки буферов
    * при заполнении буфера журнала

    После уведомления LGWR записывает все  модифицированные буферы журнала на
диск (и подтвержденные, и не подтвержденные). Операция commit для нескольких
пользователей может быть выполнена  за одну операцию ввода/вывода. Этот размер
определяется параметром  файла INIT.ORA LOG_IO_SIZE.


                                   -- 220 --



    Чем больше операций commit будет связано вместе (называется - "коэффициент
пакетирования"),  тем выше производительность. Коэффициент пакетирования - это
среднее количество транзакций на операцию записи; он измеряется следующим
отношением:
            (user commits/small redo writes) = transactions/write

      Краткое обобщение способов оптимизации журнала

* помещайте online - файлы журнала на "быстрые" устройства
* размещайте на дисках, не содержащих файлы данных
* увеличьте значения параметра LOG_BUFFER для снижения В/В
* уменьшите частоту контрольных точек увеличив параметр LOG_CHECKPOINT_INTERVAL
* уменьшите частоту распределения журнала,  увеличив значение параметра
  LOG_ALLOCATION&

      Мониторинг журнала повторного выполнения

    Для отслеживания работы журнала  повторного  выполнения  воспользуйтесь
командой MONITOR STATISTICS утилиты SQL*DBA. Наиболее интересная статистика
журнала следующая:
    * DBWR checkpoints   (контрольные точки)
    * chunk allocations  ("большие" распределения)
    * small redo writes  (малые записи в журнал)
    * large redo writes  (большие записи в журнал)

      Оптимизация буфера журнала

    Параметр LOG_BUFFER файла INIT.ORA определяет размер (в  байтах) буферов
журнала,  находящихся в SGA. Увеличение этого значения снижает активность В/В
для журнала в особенности - при  большом количестве длинных транзакций.

      Снижение частоты контрольных точек

    Контрольные точки  могут  периодически снижать производительность базы.
Они возникают после того, как будет записано определенное   число   блоков
журнала  (указывается  параметром  файла INIT.ORA LOG_CHECKPOINT_INTERVAL) или
после заполнения  одного из активных файлов журнала (при переключении журнала).

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

Увеличить время между контрольными точками  можно  следующим способом:

* Создать файлы журнала от 10 Мбайтов и больше
* Установить  для  параметра  LOG_CHECKPOINT_INTERVAL   очень большое значение
  (например - 500000) чтобы гарантировать возникновение контрольных точек
  только после заполнения одного из  файлов журнала.

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




                                   -- 221 --



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

Замечание: Увеличение  времени между контрольными точками соответственно
           увеличивает время восстановления после аварии.

    Количество контрольных точек, выполненных для данного экземпляра,
содержится в параметре статистики dbwr checkpoints.

      Снижение частоты распределений журнала

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

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

    Количество реально возникших распределений журнала можно посмотреть в
параметре статистики chunk allocations.

Разделяющие диски системы должны использовать значение параметра
LOG_ALLOCATIONS,  которое отражает количество экземпляров и размеры файлов
журнала.  Для более полной информации об установке этого параметра обратитесь к
Главе 21.

        Взаимосвязь между параметрами и статистикой

В следующей таблице обобщается связь между  значениями  параметров статистики и
параметрами файла INIT.ORA для системы ORACLE Version 6.0.26 и ранее.  Для
версии 6.0.27 и выше - обратитесь  к "Руководству по настройке
производительности ORACLE RDBMS".

  Статистика           Желательно ...     Рекомендуемые действия
--------------------------------------------------------------
chunk allocations          снизить    Увеличить LOG_ALLOCATION
buffer busy waits                     Увеличить число сегментов отката и/или
                                      уменьшить таблицы, чтобы строка по-
                                      мещалась в блок.
DBWR buffers scanned       снизить    Уменьшить
                                      DB_BLOCK_MAX_CLEAN_PCT и/или
                                      DB_BLOCK_TIMEOUT_WRITE_PCT
DBWR checkpoints           снизить    Увеличить
                                      LOG_CHECKPOINT_INTERVAL и/или увеличить
                                      размер файлов журнала повторного
                                      выполнения.
DBWR free low              снизить    Увеличить
                                      LOG_CHECKPOINT_INTERVAL
                                      и/или увеличить
                                      DB_BLOCK_MAX_CLEAN_PCT

                                   -- 222 --



DBWR free needed           снизить    Увеличить
                                      DB_BLOCK_MAX_SCAN_PCT и/или
                                      увеличить
                                      DB_BLOCK_MAX_CLEAN_PCT
DBWR timeouts              снизить    Уменьшить
                                      DB_BLOCK_MAX_MOD_PCT
free buffers inspected     снизить    Увеличить
                                      DB_BLOCK_MAX_CLEAN_PCT и/или увеличить
                                      DB_BLOCK_TIMEOUT_WRITE_PCT
free buffer requested      снизить    Увеличить DB_BLOCK_BUFFERS и/или изменить
                                      приложение так, чтобы сделать более
                                      эффективным использование кеша.

free buffer scans                     Увеличить DB_BLOCK_BUFFERS
                                      и/или увеличить
                                      DB_BLOCK_MAX_CLEAN_PCT
                                      и/или увеличить
                                      DB_BLOCK_TIMEOUT_WRITE_PCT
free buffer waits          снизить    Увеличить DB_BLOCK_BUFFERS
                                      и/или увеличить
                                      DB_BLOCK_MAX_CLEAN_PCT
                                      и/или увеличить
                                      DB_BLOCK_TIMEOUT_WRITE_PCT
                                      и/или повысить приоритет
                                      процесса DBWR
physical reads             снизить    Увеличить DB_BLOCK_BUFFERS
physical writes            снизить    Увеличить DB_BLOCK_BUFFERS
(User commits/small redo writes)
                           снизить    Увеличить LOG_BUFFER и/или
                                      увеличить LOG_IO_SIZE

cache buffer handles    снизить чи-   Уменьшить
cache buffer chains     сло ожиданий  DB_BLOCK_MAX_CLEAN_PCT
cache buffers LRU chain               и/или уменьшить
                                      DB_BLOCK_TIMEOUT_WRITE_PCT

        Настройка сегментов отката

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

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

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



                                   -- 223 --



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

    Основными параметрами файла INIT.ORA, используемыми для настройки сегментов
отката, являются:
    * ROLLBACK_SEGMENTS
    * TRANSACTIONS_PER_ROLLBACK_SEGMENT

      Мониторинг сегментов отката

    Чтобы посмотреть текущее  состояние  сегментов  отката,  надо запросить
обзор  DBA_ROLLBACK_SEGS.  Сегменты  отката  помечаются "INUSE" (используется)
или "AVAILABLE"  (доступный).  Кроме  того, для просмотра  статистики сегментов
отката можно использовать команду MONITOR ROLLBACK.

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

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

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

      Использование нескольких сегментов отката

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

    Однако если  существует  множество  параллельных  транзакций, возможна
конкуренция и пользователи выстраиваются в очередь к заголовку сегмента.
Элемент статистики header units/sec в отображении команды MONITOR ROLLBACK
показывает насколько часто эта ситуация возникает.  Лучший выход из  такой
ситуации  -  создание  и использование более одного сегмента отката.

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

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

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

                                   -- 224 --



      Выбор размера сегментов отката

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

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

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

      Кеширование сегментов отката

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

    Следовательно, сегменты отката должны быть  достаточно  малы, но все  же
иметь достаточно памяти для обеспечения согласованного чтения.

                Мониторинг использования внешней памяти

        Выбор разумных опций протоколирования

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

        Выявление проблем

Если Вы предполагаете,  что в системе появились узкие  места, они могут быть
следующими:
    * ограничения CPU
    * ограничения защелок
    * ограничения DBWR
    * ограничения LGWR
    * ограничения ввода/вывода

Работа системы  "ограничивается" ресурсом (таким как DBWR или В/В), если этот
ресурс замедляет или ограничивает  производительность и  если с увеличением
этого ресурса растет и производительность. Другими словами - ресурс достигает
своего предела и не может выполнять  быстрее  дополнительную работу, а
следовательно - ограничивает и всю систему.

                                   -- 225 --



      Ограничения CPU

    Теоретически - максимум пропускной способности системы ORACLE Version 6
достигается из-за ограничений на  мощность  процессора.  Чтобы определить,  что
работа системы ограничивается CPU, необходимы специальные диагностические
работы  (зависят  от  конкретной операционной системы).

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

      Ограничения защелок

    Система может быть ограничена защелками,  если  велико  число таймаутов.
Защелки - это механизм блокировок низкого уровня, применяемый для организации
последовательного доступа  к  структурам данных в SGA.  Защелки блокируют на
очень короткое время и представляют теоретический максимум  пропускной
способности  системы.  Для отслеживания  защелок  используется  команда
MONITOR LATCHES утилиты SQL*DBA,  однако интерпретация данных зависит от
операционной системы  и  является  профилактическим действием.  За более
подробной информацией обратитесь к "Руководству  пользователя  по инсталяции".

      Ограничения DBWR

Проблема с фоновым процессом DBWR возникает,  если система не может выполнить
необходимого ввода/вывода. Чтобы посмотреть, возникла ли  такая ситуация,
посмотрите  выдачу  команды   MONITOR STATISTICS. Если это действительно так,
воспользуйтесь описанными выше опциями настройки процесса DBWR.

      Ограничения LGWR

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

      Ограничения В/В

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

     ГЛАВА 21     СИСТЕМЫ, РАЗДЕЛЯЮЩИЕ ДИСКИ

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

        Что значит - система, разделяющая диски

                                   -- 226 --



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

        Использование SQL*DBA в нескольких экземплярах ORACLE

    Нормально эта  утилита обращается к умалчиваемому экземпляру, работающему
на основной машине.  Если же работает SQL*Net,  администратор базы  может
присоединиться к другим экземплярам,  воспользовавшись командой SET INSTANCE
(См. Приложение В).

    Каждый экземпляр  должен  ссылаться   на   собственный   файл INIT.ORA, в
котором указываются одни и те же (общие) управляющие файлы. Таким образом,
INIT.ORA - неразделяемый файл,  в то время как управляющие - разделяемые.

      Старт системы с опцией SHARED

Для систем, разделяющих диски (например - VAXCLusters) каждый экземпляр должен
монтировать базу в режиме SHARED или стартовать экземпляр с опцией SHARED:

    SQLDBA> STARTUP SHARED

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

        Параметры INIT.ORA для систем, разделяющих диски

К таким системам относятся параметры с префиксом "GC":
    * GC_DB_LOCKS
    * GC_ROLLBACK_LOCKS
    * GC_ROLLBACK_SEGMENTS
    * GC_SAVE_ROLLBACK_LOCKS
    * GC_SEGMENTS
    * GC_SORT_LOCKS
    * GC_TABLESPACES


   Префикс "GC" означает "Global Cache".  Его назначения определяют глобальный
набор блокировок, защищающих буферы базы для всех экземпляров. Назначение этих
параметров повлияет на использование определенных ресурсов операционной
системы.

    За дополнительной информацией по этим параметрам обратитесь к Приложению D
и "Руководству пользователя по инсталяции"  по Вашей операционной системе.

Существуют дополнительные параметры,  связанные с разделением дисков:
    * INSTANCES
    * LOG_ALLOCATION

        Использование сегментов отката





                                   -- 227 --



Сегменты отката  кроме SYSTEM должны быть отдельными для каждого экземпляра;
они не разделяются экземплярами. Сегмент отката может быть создан DBA для
любого экземпляра и в произвольном табличном пространстве.  Пока экземпляр не
имеет доступа как минимум - к одному личному или общему сегменту отката,  он не
может стартовать.

Для пользователя безразлично,  работает ли он с  личными  или общими (PUBLIC)
сегментами отката.

      Личные сегменты отката

Для того, чтобы распределить личный сегмент для единственного экземпляра
ORACLE, DBA должен:

1. С  помощью SQL - оператора CREATE ROLLBACK SEGMENT создать сегмент отката.
2. Указать  имя  этого сегмента в качестве значения параметра ROLLBACK_SEGMENTS
   файла INIT.ORA;  этим Вы закрепите этот сегмент за данным экземпляром.
3. Для начала работы экземпляра с этим  сегментом  необходимо остановить и
   вновь стартовать экземпляр.

      Общие сегменты отката

    Общие сегменты (PUBLIC) могут создаваться любым экземпляром и становятся
доступными  немедленно по создании.  Неиспользуемые в данный момент общие
сегменты могут  "резервироваться"  любым экземпляром и  м будут сохраняться за
ним до остановки (shut down).  После остановки освобожденные общие сегменты
могут резервироваться любым другим экземпляром. Обычно общие сегменты не
указываются в файлах INIT.ORA.

                Копирование и восстановление систем, разделяющих диски

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

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

      Распределение экземплярам памяти в журнале

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

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


                                   -- 228 --



Несколько рекомендаций по поводу распределения файлов журнала:
    * указывайте  в  параметре  LOG_ALLOCATION как минимум - 1000 блоков
    * распределяйте каждый файл журнала размером 2000 блоков, ум- ноженное на
      число экземпляров
    * если возможно,  исходите из четырех - пяти распределений на каждый
      экземпляр.

Уменьшение распределяемой памяти несколько  улучшает  ее  использование, так
как в них  остается меньше не использованного места на момент переключения с
одного файла на другой.

      Контрольные точки

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

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

     Назначение режима журнала

    Режим использования журнала (ARCHIVELOG или NOARCHIVELOG) устанавливается
при создании базы и может быть впоследствии изменен командой ALTER DATABASE.
Эта характеристика относится ко всей базе, а не к конкретному экземпляру и,
таким образом,  ответственность по архивации файлов журнала экземпляры могут
делить  между собой. Все экземпляры должны использовать одинаковые режим
журнала и местоположение архива.

      Архивация

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

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

      Восстановление экземпляра

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

                                   -- 229 --



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

     ГЛАВА 22     РАСПРЕДЕЛЕННЫЕ БАЗЫ И РАСПРЕДЕЛЕННАЯ ОБРАБОТКА

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

    Информация этой главы должна быть дополнена материалами,  которые можно
найти в другой документации Oracle Corporation,  особенно - по SQL*Net
(например - общие руководства по SQL*Net, описания  конкретных  протоколов
связи,   а   также   "Руководства пользователя по инсталяции").

        Что такое SQL*Star ?

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

    SQL*Connect   Этот продукт служит как-бы "шлюзом" с другими системами
                  (например - SQL/DS или DB2). Этот продукт позволяет некоторым
                  средствам ORACLE функционировать с другими базами, как если
                  бы это были базы ORACLE. SQL*Connect вместе с SQL*Net может
                  работать с удаленными базами данных.

    SQL*Net       Этот продукт является гетерогенным сетевым интерфейсом
                  SQL*Star. Он дает возможность пересылать данные в
                  соответствии с протоколами связи между различными базами
                  данных.

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

        Что такое "распределенная обработка" ?

Распределенная обработка    появляется   в   случае,   когда прикладное
средство, работающее на одном процессоре, обращается к базе другого
процессора.  Преимущества  распределенной обработки заключаются в следующем:

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

                                   -- 230 --



* С относительно меньшими затратами на оборудование Вы можете обслуживать
большее  количество пользователей.  Большая часть обработки может выполняться
на персональных компьютерах  и  мощность может  расти  за счет использования PC
вместо большой центральной ЭВМ.

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

        Что такое "распределенная база данных" ?

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

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

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

        Преимущества распределенной обработки ORACLE

В дополнение к общим преимуществам и гибкости,  предоставляемым распределенными
базами и распределенной обработкой,  совместное использование  ORACLE и SQL*Net
дает дополнительно две важных возможности: прозрачность расположения и местная
автономия.

      Прозрачность расположения

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

* Данные  могут  быть разбиты по нескольким базам (например - LONDON и BOSTON)
  и пользователя интересует таблица  EMP  из  базы LONDON, а не BOSTON.

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

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





                                   -- 231 --



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

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

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

      Местная автономия

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

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

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

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

                Роль клиентов и серверов

        Распределенная база состоит из клиентов и серверов.

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

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

      Связь клиентов и серверов

                                   -- 232 --



Распределенная система нуждается в предварительно  определенных путях для связи
между ее частями. Предварительно определенные связи называют "базовыми связями"
(DBLINKS).  Более подробно  они описываются ниже.

Например - если Вы присоединились к Базе-А, пытаетесь запросить таблицу Table-M
и База-А определила,  что эта таблица на самом деле находится в Базе-В,  то
База-А передаст Ваш запрос (если только существует действительный путь для
связи с Базой-В. Фактически База-А  в Ваших интересах присоединяется к Базе-В,
создает там процесс для выполнения Вашего запроса и  возвращает результат в
Базу-А.

      Разделение работы между Клиентами и Серверами

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

      Связь между различными версиями системы ORACLE

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

        Особенности ORACLE и SQL*Net

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

В настоящее время ORACLE вместе  с  SQL*Net  не  поддерживают возможность
распределенного изменения данных.  Изменения (UPDATE, DELETE,  INSERT и команды
DDL) могут выполняться только в узле, к которому  Вы  присоединились. Поскольку
Вы можете менять данные только в узле,  в котором зарегистрировались, DBA
должен побеспокоиться,  чтобы  данные находились в местах,  где с ними наиболее
активно работают.

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

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




                                   -- 233 --



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

      Переключение между подразумеваемой и другими ЭВМ

Обычно большинство пользователей будет работать с одним и тем же набором
прикладных программ и соответствующих данных  и только иногда делать запросы по
другим базам.  DBA должен попытаться соотнести пользователей с умалчиваемыми
базами  данных, называемыми DEFAULT HOSTS. Доступ к этим данным должен быть
упрощен, чтобы не надо было указывать сетевой протокол, имя базы и т.д.

    Host - это синоним имени базы в SQL*NET.  Переключиться с текущей базы на
другую можно с помощью команды SET INSTANCE утилиты SQL*DBA. Первоначальная
главная  ЭВМ   идентифицируется   пустым (null) именем  и  является  той
машиной,  с которой была связь во время работы SQL*DBA.

Текущая главная ЭВМ - та, к которой Вы присоединились последней либо явно (с
помощью SET INSTANCE),  либо неявно (присоединяясь без назначения главной ЭВМ).

oбратитесь к началу Приложения В и к описанию команды SET INSTANCE (там же) за
описанием выбора удаленных экземпляров и выполнения функций DBA на удаленных
ЭВМ.

      Решение вопроса о месте расположения прикладных программ

В среде  распределенной  обработки  вопрос  о  местоположении прикладных
программ не зависит  от  местоположения  данных.  Ниже приведены важные
факторы выбора машины для размещения прикладной программы:

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

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

При разработке оптимального распределения данных и схемы  обработки DBA должен,
как минимум, учитывать следующие вопросы:
    * где данные располагаются в настоящее время ?
    * в каком месте будет вводиться (INSERT) основная часть  данных ?
    * какое количество различных приложений будет использоваться ?
    * из какого места пользователи прикладных программ обращаться к данным ?
    * какая аппаратура доступна сейчас и появится в будущем ?
    * какой требуется уровень производительности ?
    * каковы наиболее важные требования по защите данных ?


                                   -- 234 --



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

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

      Перемещение данных командой COPY

Перемещение данных может быть выполнено командой  COPY.  Подробный синтаксис
Вы  найдете  в  "Справочнике  пользователя  по SQL*Plus". Возможно копирование
данных из одного  удаленного узла в другой  (если  они оба входят в одну
распределенную базу);  при этом нет необходимости присоединяться к обоим узлам.
Кроме того, следующая команда скопирует данные из удаленного узла в локальный:

    INSERT INTO table_here
    SELECT * FROM table_there@dblink

За описанием ограничений в выполнении запросов  на  распределенной системе
обратитесь к "Справочнику   пользователя  по SQL*Plus".

        Создание связей в базе данных

    Для присоединения  к базе в удаленном узле необходимо создать связь. Эта
связь содержит достаточную информацию  для  уникальной идентификации "пути" от
одной локальной базы к другой.  База-клиент определяет и владеет указанной
связью (DBLINK),  которая специфицирует (явно или неявно) имя пользователя и
пароль,  действительные в базе-сервере. DBLINK содержит следующую информацию:
    * сетевой протокол
    * имя узла
    * имя базы
    * пользователь/пароль (необязательно)
    * опции протокола

как например:

    D:LONDON:'LONDB':SCOTT/TIGER

Заметьте, что клиент не указывает своего  имени пользователя, но присоединяется
к конкретному пользователю в базе-сервере. Этот факт дает некоторые
преимущества в определения связи.

DBLINK, определяемая с помощью SQL -  оператора, запоминается в словаре данных
базы-клиента (См. обзоры  USER_DB_LINKS, ALL_DB_LINKS и DBA_LINKS).

    CREATE [ PUBLIC ] DATABASE LINK dbname
    [ CONNECT TO username IDENTIFIED BY pwd ]
    USING 'netprefix:dbstring'

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



                                   -- 235 --



    CREATE DATABASE LINK LONDB
    CONNECT TO CHARLES IDENTIFIED BY DICKENS
    USING 'D:THAMES'

и Вы можете выполнить, например, следующую команду:

    SQL> SELECT * FROM EMP@LONDB

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

    CREATE SYNONYM EMP FOR EMP@LONDB;
    SELECT * FROM EMP;

      Личные межбазовые связи

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

    Личные связи  в  общем случае обеспечивают лучшую защиту данных. Если же
несколько пользователей обращаются к одному учетному номеру в удаленной базе,
имеет смысл создать общую (public) связь.

      Общие межбазовые связи

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

        Выбор пользователей для доступа к удаленным данным

При доступе  к  базе данных ORACLE Вы должны указать действительные имя
пользователя и пароль (идентификатор  пользователя  - UID).

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

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

      Использование для клиентов одного общего учетного номера

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


                                   -- 236 --



* кто бы то ни было,  желающий изменить  привилегии  в  базе, должен изменить
  их только для одного UID.

Однако этому методу присущи недостатки,  связанные с безопасностью:

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

* возможна тенденция к превышению необходимых привилегий (таких как  UPDATE,
  INSERT,  DELETE)  для выполнения требований все возможных клиентов

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

Технически при  этом способе создается связь с базой для спецефичного идентифи
катора пользователя ORACLE  в  базе-сервере,  к которому могут обращаться все
пользователи:
            CREATE DATABASE LINK NODE1
            CONNECT TO NETUSER IDENTIFIED BY NETPASS USING 'dbstring';

Создав такую связь, администратор базы может затем выдать:

    GRANT CONNECT TO NETUSER IDENTIFIED BY NETPASS
а затем предоставить соответствующие привилегии для таблиц.

      Индивидуальные учетные номера для клиентов

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

Возможные преимущества этого метода включают в себя:

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

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

Каждый пользователь  может  иметь  свою  собственную  связь с конкретным
пользователем удаленной базы:

    CREATE DATABASE LINK MYLINK
    CONNECT TO SCOTT2 IDENTIFIED BY TIGER2 USING 'dbstring';



                                   -- 237 --



А иначе, пользователи могут ссылаться на связь PUBLIC, не содержащую имени
пользователя и пароля. В этом случае используются локальные имя пользователя и
пароль:
           CREATE PUBLIC DATABASE LINK HQ USING 'dbstring';

Более подробная  информация содержится в "Справочном руководстве по языку SQL".





















































                                   -- 238 --


KOAP Open Portal 2000



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