УПРАВЛЕНИЕ РАСПРЕДЕЛЕННЫМИ БАЗАМИ ДАННЫХ ORACLE
ГЛАВА 15
----------------------------------------------------------------
УПРАВЛЕНИЕ РАСПРЕДЕЛЕННЫМИ БАЗАМИ ДАННЫХ
Эта глава объясняет, как управлять базой данных, являющейся
частью системы распределенных баз данных. Темы этой главы
включают обсуждение следующих вопросов:
* указания по распределенным базам данных
* управление глобальными именами баз данных
* создание, использование и удаление связей баз данных
* реализация прозрачности местоположения
* установление силы точки подтверждения
* разрешение проблем в распределенных базах данных
Информация этой главы применима только к системам, использующим
ORACLE с распределенной опцией.
Управление распределенными базами данных 15-1
----------------
Рекомендации по организации системы распределенных баз данных
Следующие секции обсуждают некоторые важные вопросы, которые вы
должны рассмотреть, приступая к реализации системы
распределенных баз данных.
Назначьте администраторов
-------------------------
Так как узлы в системе распределенных баз данных ORACLE являются
автономными, за каждую базу данных в системе распределенных баз
данных должен отвечать хотя бы один администратор. Каждый АБД
несет ответственность за вопросы, касающиеся только своей базы
данных, такие как управление памятью или локальная защита.
Однако администраторы различных баз данных в распределенной
системе должны также координировать свою деятельность в
вопросах, касающихся распределенной обработки, таких как вопросы
проектирования данных, резервного копирования и восстановления,
а также удаленной защиты.
Рассмотрите вопросы сети и коммуникаций
---------------------------------------
Администраторы баз данных, системы и сети могут нести
ответственность за гарантирование сетевых соединений,
связывающих машины, которые участвуют в распределенных
транзакциях. Это включает инсталляцию и запуск необходимых
драйверов SQL*Net, организующих коммуникации между серверами баз
данных ORACLE. Для дополнительной информации о SQL*Net
обратитесь к вашей документации по SQL*Net.
Определите глобальные имена баз данных и связи баз данных
---------------------------------------------------------
Дайте каждой базе данных уникальное глобальное имя, и определите
связи баз данных в локальной базе данных, чтобы предложения SQL,
которые выдаются пользователями и приложениями, могли обращаться
к объектам в удаленных базах данных. Подробнее об этом см. в
секциях "Управление глобальными именами баз данных" на странице
15-3 и "Управление связями баз данных" на странице 15-7.
Решите, где размещать данные
----------------------------
В среде распределенных баз данных, администраторы баз данных
должны вместе с разработчиками приложений определять наилучщие
места для размещения данных. Рассмотрите следующие вопросы:
* число транзакций, выпускаемых с каждого места
* объем данных (процент таблицы), используемый каждым узлом
* характеристики производительности и надежности сети
* скоростные и емкостнные характеристики узлов
* критичность доступа пи отказах узла или соединения
* необходимость ссылочной целостности между таблицами
15-2 Руководство администратора
Для дополнительной информации о выработке компромиссов при
размещении данных обратитесь к документу ORACLE7 Server
Application Developer's Guide.
Обеспечьте защиту в системе распределенных баз данных
-----------------------------------------------------
В общем, вопросы защиты контролируются администратором каждой
базы данных, и не могут администрироваться удаленно; например,
вы не можете назначать системные и объектные привилегии
удаленным пользователям. Удаленное соединение подчинено домену
защиты того учетного имени, которое используется связью баз
данных для этого соединения. В некоторых случаях вы можете
осуществлять ограниченное локальное управление привилегиями для
удаленных объектов; см. "Баланс между прозрачностью
местоположения и защитой" на странице 15-12.
Ресурсные лимиты применяются лишь на том узле, к которому
пользователь присоединен непосредственно. Удаленные сессии,
учрежденные от имени связей баз данных, также подчиняются
ресурсным лимитам, установленным на удаленной базе данных.
Аналогично, аудиторские записи генерируются от имени соединений,
установленных в каждой базе данных, включая соединения,
установленные через связи баз данных. Аудиторские записи
генерируются в той базе данных, где происходит изменение.
Планируйте копирование и восстановление распределенной базы данных
------------------------------------------------------------------
Рассмотрите стратегии копирования и восстановления для
глобальной распределенной базы данных, прежде чем принимать
автономные решения для локальных баз данных. Некоторые важные
вопросы обсуждаются в секциях "Рассмотрите вопросы копирования
распределенной базы данных" на странице 18-4 и "Координируйте
распределенное восстановление" на странице 19-3.
----------------
Управление глобальными именами баз данных
В системе распределенных баз данных ORACLE каждая база данных
должна иметь уникальное глобальное имя базы данных, так, чтобы
все объекты в глобальной распределенной базе данных можно было
уникально идентифицировать. Глобальное имя базы данных состоит
из двух компонент: компоненты имени базы данных (используемого
для локальных административных операций, таких как запуск,
операции восстановления, останов) и компоненты сетевого домена
(используемого для указания местоположения этой базы данных в
структуре сети).
Замечание: Хотя глобальные имена баз данных ORACLE напоминают
сообщества SQL*Net, которые также имеют сетевые домены, это
разные вещи. Для информации о сообществах SQL*Net обратитесь к
вашей документации по SQL*Net.
Выбор глобального имени базы данных
-----------------------------------
Прежде, чем создавать базу данных ORACLE (или переименовывать
существующую базу данных), выберите глобальное имя этой базы
данных так, чтобы она была уникально идентифицирована в любой
Управление распределенными базами данных 15-3
сети баз данных; иными словами, обеспечьте уникальность
комбинации имени базы данных и сетевого домена. При выборе
имени базы данных рассмотрите следующие моменты:
* Компонента имени в глобальном имени базы данных обычно
соответствует информации, хранящейся в этой базе данных.
Например, если база данных предназначена для информации
по продажам, она могла бы называться SALES; если она
хранит археологическую информацию о доисторичеких
рептилиях, она могла бы иметь имя DINOSAUR.
* Компонента имени в глобальном имени базы данных не должна
включать сведения о ее местоположении. Этого обычно
избегают, для того чтобы обеспечить дополнительный слой
прозрачности местоположения по отношению к глобальным
именам объектов; такая прозрачность будет потеряна, если
пользователям придется явно специфицировать глобальные
имена объектов в своих предложениях SQL.
* Вы должны иметь некоторый административный контроль над
сетевым доменом, в котором содержится ваша база данных.
Например, вы не должны создавать базу данных в сетевом
домене высокого уровня, в котором вы не можете
проконтролировать повторение имен. Имея контроль над
сетевым доменом, вы сможете гарантировать, что все имена
баз данных внутри этого домена уникальны.
* Вы должны предвидеть потенциальные конфликты между
именами баз данных в сетевом домене. Если вы предвидите
такие конфликты, спуститесь на один уровень ниже в
сетевом домене, чтобы избежать таких конфликтов. Однако
создавайте минимальное число уровней в домене, чтобы
обеспечивать лишь уникальность имен; не создавайте
чрезмерно длинных и запутанных имен баз данных.
* Помещайте взаимосвязанные базы данных в один сетевой
домен. Это улучшает организацию внутри сетевых доменов и
упрощает спецификацию имен в связях баз данных между
этими взаимосвязанными базами данных.
Создание глобального имени базы данных
--------------------------------------
Специфицируйте обе компоненты глобального имени базы данных в
файле параметров перед созданием базы данных; после того как
база создана, изменение ее глобального имени может серьезно
затронуть существующие приложения и определения объектов.
Вы задаете глобальное имя базы данных, устанавливая параметры
DB_NAME и DB_DOMAIN. Параметр DB_NAME определяет компоненту
имени глобального имени базы данных; одновременно он задает
локальное имя базы данных, которое вы можете специфицировать при
административных операциях (таких как запуск или восстановление
базы данных). Параметр DB_DOMAIN указывает местоположение (в
строго логическом смысле) этой базы данных в сетевой структуре.
15-4 Руководство администратора
Комбинация значений этих двух параметров образует глобальное имя
базы данных, которое должно быть уникальным в сети. Например,
чтобы создать базу данных с глобальным именем TEST.US.ACME.COM,
отредактируйте параметры в файле параметров следующим образом:
DB_NAME = TEST
DB_DOMAIN = US.ACME.COM
DB_NAME должен быть алфавитно-цифровой текстовой строкой длиной
не более восьми символов, без специальных символов. Во время
создания базы данных ее имя, заданное параметром DB_NAME,
записывается в файлы данных, файлы журнала повторения и
управляющие файлы этой базы данных. Если во время запуска базы
данных значение параметра DB_NAME не совпадет с именем базы
данных, записанным в управляющем файле, то база данных не
запустится.
DB_DOMAIN должен быть алфавитно-цифровой текстовой строкой
длиной не более 119 символов, и задает сетевой домен, в котором
создается база данных (обычно имя организации, которой
принадлежит база данных). Прописные и строчные буквы не
различаются. Уровни в имени домена разделяются точками; точки
должны отделять листья в структуре домена. Порядок имен в
домене - от листа к корню, слева направо (в соответствии со
стандартным соглашением Internet).
Изменение глобального имени базы данных
---------------------------------------
В редких ситуациях, вам может потребоваться изменить глобальное
имя базы данных. Это изменение может привести к некоторым
нежелательным побочным эффектам, включая следующие:
* Существующие связи баз данных в удаленных базах данных,
указывающие на переименовываемую базу данных, не
переименовываются автоматически.
* Существующие синонимы в удаленных базах данных,
указывающие на объекты в переименовываемой базе данных,
не обновляются автоматически.
* Существующие программные единицы PL/SQL в удаленных базах
данных, обращающиеся к данным в переименовываемой базе
данных, не обновляются автоматически.
Если вам абсолютно необходимо изменить глобальное имя базы
данных, сначала согласуйте это изменение с администраторами
других баз данных в системе. После этого вы можете (хотя и не
обязаны) перевести инстанцию в режим ограниченной сессии (с
помощью опции ENABLE RESTRICTED SESSION команды SQL ALTER
SYSTEM) и снять все текущие сессии. Чтобы переименовать базу
данных, используйте параметр RENAME GLOBAL_NAME команды ALTER
DATABASE. Например, предположим, что при реорганизации компании
Управление распределенными базами данных 15-5
ACME отдел Sales переведен в Австралию. Вы могли бы изменить
глобальное имя базы данных отдела Sales следующим образом:
ALTER DATABASE RENAME GLOBAL_NAME TO sales.australia.acme.com
Закончив переименование базы данных, можно разрешить
пользователям соединяться с инстанцией; для этого используйте
опцию DISABLE RESTRICTED SESSION команды SQL ALTER SYSTEM.
Включение глобального именования
--------------------------------
В большинстве случаев, вы должны ощутить выгоду от использования
средств ORACLE глобального именования объектов при работе в
распределенной базе данных. Однако, для обеспечения
совместимости сверху вниз с более ранними версиями ORACLE, вам
может потребоваться отключить средство разрешения глобальных
имен. Отключение этого средства также позволит именам связей
баз данных не иметь соответствия с глобальными именами баз
данных.
Режим разрешения глобальных имен управляется на двух уровнях:
для всей Режим разрешения глобальных имен управляется на
инстанции системном уровне через параметр инициализации
GLOBAL_NAMES; если значение этого параметра
TRUE, то запускаемая позднее инстанция включает
разрешение глобальных имен. Умалчиваемое
значение этого параметра - FALSE. Текущее
значение для инстанции может быть перекрыто во
время работы инстанции с помощью параметра SET
GLOBAL_NAMES команды ALTER SYSTEM (TRUE или
FALSE).
для отдельной Режим разрешения глобальных имен может
сессии управляться на уровне сессии с помощью параметра
SET GLOBAL_NAMES команды ALTER SESSION (TRUE или
FALSE).
Вывод глобальных имен баз данных
--------------------------------
Любой пользователь может узнать глобальное имя базы данных через
обзор словаря данных GLOBAL_NAME. Например, следующий запрос
выдает глобальное имя базы данных, к которой вы подключены (в
данном случае, SALES.US.ACME.COM):
SELECT * FROM GLOBAL_NAME;
GLOBAL_NAME
----------------------
SALES.US.ACME.COM
15-6 Руководство администратора
----------------
Управление связями баз данных
Администратор базы данных и администраторы приложений базы
данных, входящей в распределенную базу данных, отвечают за
поддержание необходимых связей баз данных, которые определяют
пути к связанным удаленным базам данных. Следующие секции
предоставляют рекомендации и процедуры, которые должны быть
рассмотрены при управлении связями баз данных.
Рекомендации по связям баз данных
---------------------------------
В распределенной базе данных разработчикам приложений и
индивидуальным пользователям часто разрешается создавать личные
связи баз данных. Однако вы должны иметь в виду дополнительные
обязанности по обеспечению защиты, возникающие в распределенной
системе.
Как администратор, вы отвечаете за создание всех общих и сетевых
связей баз данных. В общем, общие связи определяются так, что
соблюдаются следующие условия:
* Все пользователи локальной базы данных могут обращаться к
данным в удаленных базах данных в системе, при условии,
что они имеют необходимые полномочия в этих удаленных
базах данных.
* Пользователи, создающие совпадающие личные связи баз
данных, не должны быть обязаны специфицировать сложные
строки баз данных.
Разработчики приложений и конечные пользователи не должны
заучивать строки соединений SQL*Net и полностью
специфицированные глобальные имена баз данных, а должны вместо
этого получить список имен удаленных баз данных. Этот подход
позволяет вам контролировать то, как личные связи баз данных
устанавливают соединения с удаленными базами данных.
Совет: Воспользуйтесь преимуществом того факта, что ORACLE может
строить полную строку соединения из частичных связей; это
позволяет сделать управление связями баз данных простым и хорошо
определенным. Создайте общие связи баз данных со строками баз
данных для всех нужных баз данных, так, чтобы разработчики
приложений и конечные пользователи могли создавать простые
личные связи без необходимости специфицировать информацию
сетевого соединения. Обратитесь к документу ORACLE7 Server
Concepts Manual за подробностями о путях поиска связей баз
данных в ORACLE.
Создание связей баз данных
--------------------------
Пользователи и администраторы могут создавать связи баз данных
для облегчения соединений с удаленными базами данных, когда в
предложении SQL или программной единице PL/SQL встречается
глобальное имя объекта. Имя связи баз данных должно совпадать с
именем базы данных, на которую указывает эта связь. Если такой
базы данных нет, связь создается, но возвращает ошибку при
попытке разрешения ссылок на объекты.
Управление распределенными базами данных 15-7
Для создания связи баз данных и определения пути к удаленной
базе данных используйте команду CREATE DATABASE LINK.
Необязательная фраза CONNECT TO специфицирует удаленное учетное
имя/пароль, которые будут использоваться при создании сессии в
удаленной базе данных; если эта фраза опущена, то для создания
удаленной пользовательской сессии ORACLE будут использоваться
локальные имя и пароль пользователя. Необязательная фраза USING
задает строку базы данных (строку, содержащую специфичную для
операционной системы и для SQL*Net информацию, идентифицирующую
коммуникационный протокол). Обратитесь к вашему руководству по
инсталляции [IUG] и документации по SQL*Net для дополнительной
информации о строках соединения.
Например, предположим, что локальная база данных называется
HQ.ACME.COM, а удаленная база данных, содержащая информацию о
продажах, имеет имя SALES.ACME.COM.
CREATE PUBLIC DATABASE LINK sales.acme.com
USING 'dbstring';
Этот пример создает общую связь баз данных к удаленной базе
данных SALES. Заметьте следующие моменты:
* В качестве имени связи баз данных специфицировано полное
имя удаленной базы данных (имя и сетевой домен).
* Фраза CONNECT TO опущена, так что ORACLE будет
использовать локальные имя и пароль при создании сессии в
удаленной базе данных через эту связь баз данных.
* Параметр USING задает строку базы данных dbstring.
CREATE DATABASE LINK sales
CONNECT TO scott IDENTIFIED BY tiger;
Второй пример создает личную связь баз данных для создателя этой
связи. Заметьте следующие моменты:
* В качестве имени связи баз данных специфицировано
частичное имя удаленной базы данных (только компонента
имени). Как следствие, ORACLE автоматически расширяет
имя связи баз данных, добавляя к заданному имени сетевой
домен локальной базы данных и получая таким способом
глобальной имя удаленной базы данных.
* Фраза CONNECT TO специфицирована явно. При установлении
сессии в удаленной базе данных через эту связь баз данных
будет использоваться идентификация SCOTT/TIGER.
* Фраза USING опущена. Поэтому, когда используется эта
личная связь баз данных, должна существовать одноименная
общая или сетевая связь баз данных, содержащая строку
15-8 Руководство администратора
базы данных для установления соединения с удаленной базой
данных.
Во всех случаях, полное глобальное имя связи баз данных доступно
в локальном словаре данных, через обзоры DBA_DB_LINKS,
ALL_DB_LINKS и USER_DB_LINKS. Имя связи баз данных должно быть
уникальным в той сфере, в которой создается эта связь.
[Trusted]
Замечание: Если вы используете Trusted ORACLE в режиме OS MAC,
обратитесь к документу Trusted ORACLE7 Server Administrator's
Guide для дополнительной информации о создании связей баз
данных.
Привилегии, требуемые для создания связи баз данных
Создатель связи баз данных должен иметь либо системную
привилегию CREATE DATABASE LINK (для создания личных связей),
либо системную привилегию CREATE PUBLIC DATABASE LINK (для
создания общих связей баз данных).
Удаленное учетное имя, на которое указывает связь баз данных,
должно иметь по крайней мере системную привилегию CREATE
SESSION. Если связь баз данных использует индивидуальные
учетные имена в удаленной базе данных, то локальный пользователь
базы данных должен иметь свое учетное имя в удаленной базе
данных. Администратор каждой базы данных должен определить
привилегии для каждого такого учетного имени. Требования,
обсуждаемые в этом параграфе, не проверяются при создании связи
баз данных; они проверяются при попытке установления соединения
через эту связь баз данных.
Управление соединениями, устанавливаемые фоновым процессом RECO
---------------------------------------------------------------
Пытаясь разрешить сомнительную распределенную транзакцию,
фоновый процесс RECO устанавливает соединения с удаленными
узлами, участвовавшими в этой транзакции. Чтобы контролировать
стоимость соединений с другими базами данных, вы можете захотеть
контролировать время, в течение которого поддерживаются такие
соединения от имени RECO. Это можно сделать через параметр
инициализации DISTRIBURED_RECOVERY_CONNECTION_HOLD_TIME.
Удаление связей баз данных
--------------------------
Связь баз данных удаляется командой DROP DATABASE LINK.
Например, чтобы удалить общую связь баз данных с именем SALES,
введите следующее предложение:
DROP PUBLIC DATABASE LINK sales.acme.com;
Частичные глобальные имена баз данных расширяются с помощью
компоненты сетевого домена локальной базы данных.
Замечание: Не следует удалять связь баз данных, если она
требуется для разрешения сомнительной распределенной транзакции.
См. "Разрешение проблем распределенных транзакций" на странице
15-15 для дополнительной информации о сомнительных
распределенных транзакциях.
Управление распределенными базами данных 15-9
Привилегии, требуемые для удаления связи баз данных
Если связь баз данных личная, ее может удалить лишь ее владелец.
Если связь баз данных общая, вы должны иметь системную
привилегию DROP PUBLIC DATABASE LINK.
Вывод доступных связей баз данных
---------------------------------
Определения всех связей баз данных для базы данных хранятся в
словаре данных этой базы данных. Их можно посмотреть через
обзоры словаря данных USER/ALL/DBA_DB_LINKS.
Например, предположим, что локальная база данных имеет
глобальное имя MKTG.ACME.COM. Предположим также, что один и тот
же пользователь выдал следующие два предложения:
CREATE DATABASE LINK hq.acme.com
CONNECT TO guest IDENTIFIED BY password;
CREATE DATABASE LINK sales USING 'dbstring';
Следующий запрос выдает все личные связи баз данных,
содержащиеся в схеме текущего пользователя, который выдает этот
запрос:
SELECT db_link, username, host
FROM user_db_links;
Например, если этот запрос выдаст пользователь, создавший
показанные выше связи баз данных (HQ и SALES), он получит
следующие результаты:
DB_LINK USERNAME HOST
---------------- -------- ----------
HQ.ACME.COM GUEST
SALES.ACME.COM dbstring
Заметьте, что поля USERNAME и HOST могут быть пустыми, если
определения связей баз данных не указывают полных путей к
удаленной базе данных.
Ограничение числа активных связей баз данных
--------------------------------------------
Вы можете лимитировать число соединений от пользовательских
процессов к удаленным базам данных с помощью параметра
OPEN_LINKS. Этот параметр контролирует количество удаленных
соединений, которые любой единичный пользователь может
одновременно использовать внутри одного предложения SQL. Чтобы
улучшить производительность приложений, увеличьте значение этого
параметра, если пользователям необходимо одновременно обращаться
к большему числу баз данных; это позволит пользователю иметь
доступ ко всем нужным ему удаленным данным без ожидания, пока
локальная инстанция закрывает и открывает соединения. Для
дополнительной информации обратитесь к приложению A.
15-10 Руководство администратора
----------------
Обеспечение прозрачности местоположения
Прозрачность местоположения означает, что физическое
местоположение данных таблицы не задается конечными
пользователями и разработчиками приложений (а возможно, и
неизвестно им). Прозрачность местоположения выгодна, потому что
доступ к удаленным данным упрощается, как локальные, так и
удаленные сущности могут быть скрыты от пользователей, а объекты
можно перемещать, не затрагивая пользователей и приложений.
Прозначность местоположения не обеспечивается автоматически, но
ее можно предоставить конечным пользователям и приложениям,
когда это желательно, с помощью нескольких различных методов:
* Локально определенный обзор может предоставлять
прозрачность местоположения, обращаясь в своем
определении к удаленным таблицам.
* Локальный синоним может скрывать связь баз данных,
используемую для доступа к удаленной таблице или обзору.
* Предложения в локальной процедуре могут обращаться к
удаленным данным и удаленным процедурам. Пользователи
этой процедуры просто вызывают ее, чтобы обратиться к
удаленным данным.
Рассмотрите эти методы, если вы стремитесь обеспечить
прозрачность местоположения в своей распределенной системе.
Ниже обсуждаются связанные с этим вопросы.
Разрешение объектов и прозрачность местоположения
-------------------------------------------------
При определении обзоров, синонимов и процедур, обращающихся к
удаленным объектам, рассмотрите следующие вопросы, чтобы ваши
обзоры, синонимы и процедуры всегда имели доступ к нужным
объектам с нужными привилегиями:
* Если только все удаленные объекты не квалифицированы явно
через их имена в схемах, адресуемый объект зависит от
того, как установлено соединение через связь баз данных.
Так, если вы хотите, чтобы локальный синоним EMP ссылался
на удаленную таблицу SCOTT.EMP, явно укажите схему SCOTT
в определении этого синонима, например:
CREATE SYNONYM emp FOR scott.emp@hq.acme.com;
Связи баз данных, определенные с фразой CONNECT TO,
всегда соединяются с удаленной базой данных под именем
пользователя, которое задано в фразе CONNECT TO. Обзоры,
синонимы и процедуры, использующие этот тип связей баз
данных, всегда подчиняются привилегиям и разрешению имен
в схеме этого специфицированного удаленного пользователя.
Альтернативно, если в определении обзора, синонима или
процедуры используется связь баз данных, не содержащая
фразы CONNECT TO, то удаленное соединение зависит от
Управление распределенными базами данных 15-11
локального пользователя. Как правило, обзоры и процедуры
должны использовать связи с явными учетными именами,
чтобы гарантировать, что они могут функционировать с
должными удаленными полномочиями.
Циклические ссылки и прозрачность местоположения
------------------------------------------------
Когда обзоры, процедуры и синонимы используются для обеспечения
прозрачности местоположения, циклические ссылки не распознаются
ORACLE, но их можно контролировать с помощью ресурсных лимитов
(профилей), и особенно лимита SESSIONS. Например, предположим,
что общий синоним EMP в базе данных SALES разрешается в общий
синоним EMP в базе данных HQ, который, в свою очередь,
разрешается в общий синоним EMP в базе данных SALES.
Предложение SQL, обратившееся к общему синониму EMP в любой из
этих двух баз данных, будет прекращено, когда исчерпается
максимальное число сессий.
Баланс между прозрачностью местоположения и защитой
---------------------------------------------------
Выбор между использованием обзора, синонима или процедуры для
обеспечения прозрачности местоположения определяет степень, до
которой локальные и удаленные администраторы способны обеспечить
защиту объектов. Следующие секции обсуждают вопросы, которые
необходимо рассматривать при выборе между этими возможностями.
Предложение, выданное в удаленной базе данных:
GRANT SELECT, DELETE ON scott.emp TO user1;
Предложения, выданные в локальной базе данных:
CREATE DATABASE LINK hr.acme.com
CONNECT TO user1 IDENTIFIED BY password
USING 'db_string';
CREATE VIEW admin.emp_view AS
SELECT * FROM scott.emp@hr.acme.com;
CREATE PROCEDURE admin.fire_emp (enum NUMBER) AS
BEGIN
DELETE FROM scott.emp@hr.acme.com
WHERE empno = enum;
END;
CREATE SYNONYM admin.emp_syn FOR scott.emp@hr.acme.com;
Управление привилегиями для обзоров
Предположим, что локальный обзор (ADMIN.EMP_VIEW) обращается к
удаленной таблице или обзору. Владелец локального обзора может
назначать лишь те объектные привилегии по своему обзору, которые
были назначены удаленным пользователем, использующимся в связи
баз данных; это аналогично управлению привилегиями для обзоров,
обращающихся к локальным данным. Следовательно, локальное
управление привилегиями возможно, когда для обеспечения
прозрачности местоположения применяются обзоры. Например,
пользователь ADMIN может успешно назначать для обзора EMP_VIEW
привилегии SELECT и DELETE, но не привилегии INSERT или UPDATE.
15-12 Руководство администратора
Обзоры - хороший метод для обеспечения прозрачности
местоположения, когда неограниченный локальный контроль над
привилегиями является обязательным требованием. Например,
предположим, что локальный администратор защиты должен выборочно
назначить объектные привилегии для нескольких удаленных таблиц.
Удаленный администратор может создать у себя мощное учетное имя,
которому назначается много привилегий для многих удаленных
таблиц. Затем локальный администратор создает личную связь баз
данных, которая соединяется с мощным удаленным "пользователем",
и, в той же схеме, создает обзоры, реализующие нужные
"отражения" удаленных таблиц. Локальный администратор локально
управляет привилегиями для удаленных таблиц путем назначения
привилегий на эти локальные обзоры. Заметим также, что в этом
примере личная связь баз данных может использоваться многими
пользователями.
Управление привилегиями для процедур
Предположим теперь, что локальная процедура содержит
предложение, обращающееся к удаленной таблице или обзору (см.
пример на предыдущей странице). Владелец этой локальной
процедуры может дать привилегию EXECUTE любому пользователю, тем
самым предоставляя этому пользователю возможность выполнять эту
процедуру и обращаться к удаленным данным.
В общем, процедуры способствуют защите; пользователи, вызывающие
процедуру, могут выполнять над данными лишь операции,
контролируемые процедурой, и привилегии для объектов, адресуемых
в процедуре, не требуется явно назначать вызывающим ее
пользователям. Во многом подобно обзорам, процедуры дают
хороший метод для обеспечения прозрачности местоположения, когда
неограниченный локальный контроль над привилегиями является
обязательным требованием. Например, предположим, что локальный
администратор защиты должен выборочно разрешить пользователям
опрашивать и обновлять несколько удаленных таблиц. Удаленный
администратор может создать у себя мощное учетное имя, которому
назначается много привилегий для многих удаленных таблиц. Затем
локальный администратор создает личную связь баз данных, которая
соединяется с мощным удаленным "пользователем", и, в той же
схеме, создает процедуры, которые опрашивают и модифицируют
удаленные таблицы, как требуется. Локальный администратор
контролирует доступ локальных пользователей к удаленным таблицам
путем выборочного назначения привилегий EXECUTE для этих
локальных процедур.
Управление привилегиями для синонимов
Предположим, что локальный синоним является алиасом для
удаленного объекта. Владелец этого локального синонима НЕ МОЖЕТ
назначать никаких объектных привилегий по этому синониму никаким
другим локальным пользователям. Это поведение отличается от
управления привилегиями для синонимов, указывающих на локальные
таблицы или обзоры; когда синоним указывает на удаленный объект,
локальные привилегии для этого синонима не могут назначаться,
потому что это могло бы вылиться в назначение привилегий на
удаленный объект, что не допускается. Поэтому никакое локальное
управление привилегиями невозможно, когда для обеспечения
прозрачности местоположения применяются синонимы; защита
базового объекта полностью контролируется на удаленном узле.
Например, пользователь ADMIN не может назначать никаких
объектных привилегий для синонима EMP_SYN.
Управление распределенными базами данных 15-13
В отличие от связи баз данных, используемой в определении обзора
или процедуры, связь баз данных, используемая в синониме,
разрешается сначала путем поиска личной связи, принадлежащей той
схеме, которая является текущей в момент разбора синонима (а не
выполнения предложения, обращающегося к синониму). Поэтому,
чтобы гарантировать правильное разрешение объектов, особенно
важно специфицировать схему адресуемого объекта в определении
синонима.
----------------
Ограничение числа распределенных транзакций на узел
Параметр DISTRIBUTED_TRANSACTIONS контролирует число возможных
распределенных транзакций, в которых данная инстанция может
одновременно участвовать, и как клиент, и как сервер. Если
достигается этот лимит, то очередной пользователь, пытающийся
выдать предложение SQL с обращением к удаленной базе данных,
получит следующее сообщение об ошибке:
ORA-2042: too many global transactions
(слишком много глобальных транзакций)
Например, предположим, что для данной инстанции установлено
значение 10 для параметра DISTRIBUTED_TRANSACTIONS. В этом
случае, лишь десять сессий могут одновременно заниматься
обработкой распределенных транзакций; если одиннадцатая сессия
попытается выдать предложение DML, требующее распределенного
доступа, то этой сессии будет возвращено сообщение об ошибке, а
предложение будет подвергнуто откату.
Администратор базы данных должен рассмотреть вопрос об
увеличении значения параметра инициализации
DISTRIBUTED_TRANSACTIONS, если инстанция регулярно участвует в
многочисленных распределенных транзакциях, и приведенное выше
сообщение встречается часто. Увеличение этого лимита позволит
большему числу пользователей одновременно выдавать
распределенные транзакции.
Если параметр DISTRIBUTED_TRANSACTIONS установлен в нулевое
значение, то ни одна сессия в инстанции не может выдавать
распределенных предложений SQL. Кроме того, фоновый процесс RECO
не стартует при запуске локальной инстанции, и сомнительные
распределенные транзакции, которые, возможно, присутствуют
(после предыдущего сетевого или системного сбоя), не могут быть
автоматически разрешены ORACLE; поэтому устанавливайте нулевое
значение этого параметра инициализации лишь тогда, когда вы
уверены, что не существует сомнительных распределенных
транзакций, оставшихся после последнего останова инстанции.
15-14 Руководство администратора
----------------
Установление силы точки подтверждения для инстанции
Установите силу точки подтверждения для каждой базы данных
ORACLE так, чтобы наиболее критичный сервер был "не-блокирующим"
в случае сбоя во время двухфазного подтверждения. Сила точки
подтверждения базы данных должна определяться оценкой числа
коллизий, которые могут быть вызваны данными, заблокированными
сомнительными транзакциями. Например, базы данных, работающие
пол управлением ORACLE на больших ЭВМ, скорее всего должны иметь
более высокую силу точки подтверждения, чем базы данных,
работающие на миникомпьютерах, а те, в свою очередь, должны
иметь более высокую силу точки подтверждения, чем базы данных на
PC. Чтобы определить такие характеристики, все администраторы в
системе распределенных баз данных должны совместно выработать
общую точку зрения на то, как определять силы точек
подтверждения.
Сила точки подтверждения инстанции базы данных устанавливается
параметром инициализации COMMIT_POINT_STRENGTH. Это значение
должно быть целым в интервале от 0 до 255. Например, чтобы
установить силу точки подтверждения 200, включите следующую
строку в файл параметров базы данных:
COMMIT_POINT_STRENGTH = 200
Умалчиваемое значение зависит от операционной системы;
обратитесь к вашему руководству по инсталляции [IUG].
----------------
Разрешение проблем распределенных транзакций
Сетевой или системный сбой может вызвать следующие типы проблем
для пользователей системы распределенных баз данных:
* Двухфазное подтверждение транзакции, обрабатывавшееся во
время сбоя, могло не завершиться на всех или некоторых
узлах дерева сессий.
* Если сбой продолжителен (например, если сеть отказала на
долгий период времени), то данные, монопольно
заблокированные сомнительными транзакциями, остаются
недоступными предложениям в других транзакциях.
Эти ситуации описываются в следующих секциях.
Сбои, прерывающие двухфазное подтверждение
------------------------------------------
Пользовательская программа, подтверждающая распределенную
транзакцию, информируется о возникшей проблеме одним из
следующих сообщений об ошибках:
Управление распределенными базами данных 15-15
ORA-02050: transaction rolled back, some remote dbs may be
in-doubt
ORA-02051: transaction committed, some remote dbs may be
in-doubt
ORA-02054: transaction in-doubt
Приложение должно сохранить информацию о транзакции, если оно
получает одну из этих ошибок. Эта информация может оказаться
полезной впоследствии, если потребуется ручное восстановление
распределенной транзакции.
Замечание: Сбойные ситуации, вызывающие эти сообщения об
ошибках, выходят за рамки этой книги; их не требуется понимать
для того, чтобы осуществлять функции администрирования системы.
Ни на одном из узлов, имеющих сомнительные транзакции в
результате сетевого или системного сбоя, не требуется никаких
действий администраторов. Автоматические средства
восстановления ORACLE прозрачно завершают любую сомнительную
транзакцию так, что она имеет один и тот же исход (подтверждение
или откат) на всех узлах дерева сессий после разрешения сетевого
или системного сбоя. Однако, если простой затягивается,
администратор может решить форсировать подтверждение или откат
транзакции на своем узле, чтобы освободить заблокированные
данные. Приложения должны считаться с такими возможностями.
Сбои, препятствующие доступу к данным
-------------------------------------
Когда пользователь выдает предложение SQL, ORACLE пытается
заблокировать ресурсы, требуемые для успешного выполнения этого
предложения. Однако, если запрашиваемые данные в этот момент
удерживаются другими неподтвержденными транзакциями и остаются
заблокированными достаточно долгое время, то наступает таймаут.
Рассмотрим следующие два сценария.
Пример 1:
Таймаут транзакции
Предложение DML, требующее блокировки на удаленной базе данных,
может быть приостановлено, если другая транзакция
(распределенная или нераспределенная) удерживает блокировки на
запрашиваемые данные. Если эти блокировки продолжают
задерживать запрашивающее предложение SQL, то возникает таймаут,
предложение откатывается, и пользователю возвращается следующее
сообщение об ошибке:
ORA-02049: time-out: distributed transaction waiting for lock
Так как никакие данные не были модифицированы, в результате
таймаута не требуется никаких действий. Приложения должны
продолжаться так, как будто имел место захват. Пользователь,
выполнявший предложение, может попытаться повторить это
предложение позже. Если ошибка повторится, пользователь должен
обратиться к администратору и сообщить об этой проблеме.
Интервал таймаута, применяющийся в описанной выше ситуации,
может контролироваться через параметр инициализации
DISTRIBUTED_LOCK_TIMEOUT. Этот интервал задается в секундах.
15-16 Руководство администратора
Например, чтобы установить 30-секундный интервал таймаута для
инстанции, включите следующую строку в ассоциированный файл
параметров:
DISTRIBUTED_LOCK_TIMEOUT = 30
При установленном таким способом интервале таймаута ошибка
таймаута, которая обсуждалась в предыдущем абзаце, возникнет,
если транзакция не сможет продолжиться после 30 секунд ожидания
недоступных ресурсов.
Для дополнительной информации о параметрах инициализации и
редактировании файлов параметров обратитесь к приложению A.
Пример 2:
Блокировка из-за сомнительной транзакции
Запрос или предложение DML, требующее блокировки на локальной
базе данных, может попасть в бесконечное ожидание, если нужные
ресурсы заблокированы сомнительной распределенной транзакцией.
В таком случае предложение немедленно откатывается, а
пользователю немедленно возвращается следующее сообщение об
ошибке:
ORA-01591: lock held by in-doubt distributed transaction
Пользователь, выполнявший предложение, может попытаться
повторить это предложение позже. Если ошибка повторится,
пользователь должен обратиться к администратору и сообщить об
этой проблеме, УКАЗАВ идентификатор сомнительной распределенной
транзакции.
Шансы возникновения таких ситуаций весьма малы, учитывая низкую
вероятность сбоев во время критических участков двухфазного
подтверждения. Даже если такой сбой случится, то, при условии
быстрого восстановления после сетевого или системного сбоя, эти
проблемы решаются автоматически без ручного вмешательства, так
что они будут, скорее всего, разрешены прежде, чем будут
замечены пользователями или администраторами баз данных.
Ручное разрешение сомнительных транзакций
-----------------------------------------
Администратор базы данных может вручную форсировать операцию
COMMIT или ROLLBACK для локальной порции сомнительной
распределенной транзакции. Однако конкретная сомнительная
транзакция должна разрешаться вручную ТОЛЬКО в следующих
ситуациях:
* Сомнительная транзакция блокирует данные, требуемые
другим транзакциям; это имеет место, если пользователи
жалуются, что их транзакции сталкиваются с сообщением об
ошибке ORA-01591.
* Сомнительная транзакция не позволяет другим транзакциям
использовать экстенты сегмента отката. Первая компонента
локального идентификатора транзакции для сомнительной
распределенной транзакции соответствует идентификатору
Управление распределенными базами данных 15-17
сегмента отката, как показывают обзоры словаря данных
DBA_2PC_PENDING и DBA_ROLLBACK_SEGS.
* Сбой, не давший завершиться двухфазному подтверждению, не
будет исправлен за приемлемое время. Примерами таких
случаев могут служить отказ телекоммуникационной сети или
повреждение базы данных, которое требует значительного
времени на восстановление.
Как правило, решение локально форсировать разрешение
сомнительной распределенной транзакции должно приниматься после
консультации с администраторами других узлов. Вы должны
понимать, что неверное решение может привести к
несогласованностям в базах данных, которые придется
корректировать вручную и которые может оказаться нелегко
отследить.
Если условия, приведенные выше, не имеют места, ВСЕГДА
позволяйте автоматическим средствам восстановления ORACLE
разрешать транзакцию. Однако, если приведенные выше условия
справедливы, администратор должен рассмотреть необходимость
ручного завершения сомнительной транзакции. Если такое решение
принимается, АБД должен проанализировать имеющуюся информацию,
имея в виду следующие цели:
* Попытайтесь найти узел, успевший либо подтвердить, либо
выполнить откат этой транзакции. Если вы можете найти
узел, уже разрешивший транзакцию, вы можете следовать
действию, выполненному на таком узле.
* Проверьте, нет ли какой-нибудь информации в столбце
TRAN_COMMENT обзора DBA_2PC_PENDING для распределенной
транзакции. Там может быть комментарий, который был
включен в параметр COMMENT команды COMMIT. Например,
комментарий сомнительной распределенной транзакции может
сообщать источник этой транзакции и ее тип:
COMMIT COMMENT 'Finance/Accts_pay/Trans_type 10B';
* Проверьте, нет ли какой-нибудь информации в столбце
ADVISE обзора DBA_2PC_PENDING для распределенной
транзакции. Приложение могло предусмотреть совет о том,
подтверждать или откатывать отдельные части своей
распределенной транзакции, с помощью параметра ADVISE
команды SQL ALTER SESSION. Во время фазы подготовки на
каждый узел посылается совет, действовавший на момент
выполнения последнего предложения DML в базе данных,
инициировавшей транзакцию. Например, рассмотрим
распределенную транзакцию, которая перемещает запись о
сотруднике из таблицы EMP на одном узле в таблицу EMP на
другом узле. Транзакция могла защитить эту запись, даже
на случай, если администраторы независимо будут
форсировать сомнительную транзакцию на каждом узле, с
помощью следующей последовательности предложений SQL:
15-18 Руководство администратора
ALTER SESSION ADVISE COMMIT;
INSERT INTO emp@hq ...; /* совет подтвердить на HQ */
ALTER SESSION ADVISE ROLLBACK;
DELETE FROM emp@sales ...; /* совет откатить на SALES */
ALTER SESSION ADVISE NOTHING;
Если в данном случае на каждом узле последуют совету при
ручном разрешении сомнительной транзакции, то худшее, что
может произойти, - это то, что на каждом узле останется
копия перемещавшейся записи; зато эта запись не
потеряется.
Пример ручного разрешения транзакции
Следующий пример иллюстрирует сбой во время подтверждения
распределенной транзакции, и показывает, как получить
необходимую информацию перед принятием решения о ручном
подтверждении или откате локальной порции сомнительной
распределенной транзакции. Этот пример показан на рис.15-1.
Рис.15-1
Пример сомнительной распределенной транзакции
WAREHOUSE.ACME.COM HQ.ACME.COM
---¬ ---¬---¬
¦--¦ ¦- ¦¦--¦
¦--¦ ¦ -¦¦--¦
L--- готов L---L--- commit
¦ ¦
¦ +
¦ T Разрыв связи
¦ ¦
L-----------T-------------
¦
---¬
¦ ¦ SALES.ACME.COM
¦ ¦
L--- готов
---¬ ---¬
¦ ¦ ¦- ¦
¦ ¦ Глобальный координатор ¦ -¦ Сторона точки подтверждения
L--- L---
---¬
¦--¦
¦--¦ Сервер базы данных
L---
В этом случае сбоя, фаза подготовки завершена. Однако, во время
фазы подтверждения, сообщение о подтверждении, информирующее
глобального координатора о том, что транзакция подтверждена на
стороне точки подтверждения, не успевает быть принятым
глобальным координатором из-за разрыва связи. Текст возле
каждого узла показывает состояния узлов, вовлеченных в
сомнительную транзакцию.
Допустим, вы администратор базы данных WAREHOUSE. Ваши данные
заблокированы, потому что сомнительная транзакция удерживает
свои блокировки до тех пор, пока она не будет подтверждена или
отменена.
Управление распределенными базами данных 15-19
Далее, вы понимаете, что коммуникационный канал между базами
данных SALES и HQ не будет восстановлен немедленно. Поэтому вы
решаете вручную форсировать локальную порцию сомнительной
транзакции, выполняя следующие шаги:
1. Запишите реакцию пользователей.
2. Опросите локальный обзор DBA_2PC_PENDING, чтобы получить
идентификатор глобальной транзакции и другую информацию о
сомнительной транзакции.
3. Опросите локальный обзор DBA_2PC_NEIGHBORS, чтобы начать
отслеживание дерева сессий с целью найти узел, успевший
разрешить сомнительную транзакцию.
4. После восстановления связи проверьте флаг смешанного исхода.
Следующие секции подробно описывают каждый из этих шагов.
ЗАПИШИТЕ РЕАКЦИЮ ПОЛЬЗОВАТЕЛЕЙ. Пользователи локальной базы
данных, конфликтующие с блокировками сомнительной транзакции,
будут получать следующее сообщение об ошибке:
ORA-01591: lock held by in-doubt distributed transaction 1.21.17
Здесь 1.21.17 - локальный идентификатор сомнительной
распределенной транзакции в нашем примере. Локальный
администратор должен записать все такие идентификаторы, запросив
их у тех пользователей, которые сообщают о проблемах.
ОПРОСИТЕ DBA_2PC_PENDING. Опросите локальный обзор
DBA_2PC_PENDING, чтобы получить информацию о сомнительной
транзакции:
SELECT * FROM sys.dba_2pc_pending
WHERE local_tran_id = '1.21.17';
Например, выдав этот запрос на базе данных WAREHOUSE, вы можете
получить следующие результаты. (Здесь результаты запроса для
простоты переставлены.)
15-20 Руководство администратора
Column Name Value
---------------------- -----------------------------------------
LOCAL_TRAN_ID 1.21.17
GLOBAL_TRAN_ID SALES.ACME.COM.55d1c563.1.93.29
STATE prepared
MIXED no
ADVICE
TRAN_COMMENT Sales/New Order/Trans_type 10B
FAIL_TIME 31-MAY-91
FORCE_TIME
RETRY_TIME 31-MAY-91
OS_USER SWILLIAMS
OS_TERMINAL TWA139:
HOST system1
DB_USER SWILLIAMS
COMMIT#
Глобальный идентификатор транзакции - это общий идентификатор
распределенной транзакции, который один и тот же на всех ее
узлах. Он имеет следующую форму:
глобальное_имя_базы_данных.hhhhhhhh.локальный_id_транзакции
Здесь глобальное_имя_базы_данных - это имя базы данных
глобального координатора (источника транзакции), hhhhhhhh -
внутренний идентификатор базы данных глобального координатора (8
шестнадцатеричных цифр), а локальный_id_транзакции -
соответствующий локальный идентификатор транзакции, назначенный
на глобальном координаторе. Поэтому на глобальном координаторе
локальный идентификатор транзакции (LOCAL_TRAN_ID) и последняя
часть глобального идентификатора транзакции (GLOBAL_TRAN_ID)
всегда совпадают; в нашем случае вы можете сделать вывод, что
WAREHOUSE не является глобальным координатором для данной
транзакции, так как эти номера не совпадают.
Состояние транзакции (STATE) на данном узле - "готов"
(prepared). Следовательно, WAREHOUSE ожидает получения от
своего координатора сообщения о подтверждении либо откате.
Комментарий (TRAN_COMMENT) или совет (ADVICE) может включать
информацию о транзакции. Если это так, попытайтесь использовать
эту информацию к своей выгоде. В нашем случае, в комментарий
транзакции включены ее источник (приложение ввода заказов из
отдела Sales) и тип транзакции. Эта информация может раскрыть
какие-либо сведения, которые помогут вам решить, подтвердить или
отменить локальную порцию транзакции.
Если сомнительная транзакция не сопровождается полезными
комментариями, вы должны выполнить некоторую дополнительную
административную работу, чтобы выстроить дерево сессий и найти
узел, успевший разрешить транзакцию. Перейдите к следующему
шагу.
ОПРОСИТЕ DBA_2PC_NEIGHBORS. Цель этого шага - взбираться по
дереву сессий к координаторам, достигнув в конечном счете
глобального координатора. По пути вы можете найти координатора,
Управление распределенными базами данных 15-21
который уже разрешил эту транзакцию. Если нет, то вы в конце
концов дойдете до стороны точки подтверждения, на которой
сомнительная транзакция всегда разрешена.
Обзор DBA_2PC_NEIGHBORS предоставляет информацию о соединениях,
ассоциированных с сомнительной транзакцией. Информация о каждом
соединении разная, в зависимости от того, является ли соединение
входящим или исходящим:
* Если соединение входящее, то ваш узел подчинен (является
сервером для другого узла). В этом случае столбец
DATABASE показывает имя базы данных клиента,
соединившегося с вашим узлом, а столбец DBUSER_OWNER
показывает локальное учетное имя, которое использовалось
для соединения через связь баз данных для сомнительной
транзакции.
* Если соединение исходящее, то ваш узел является клиентом
других серверов. В этом случае столбец DATABASE
показывает имя связи баз данных, использовавшейся для
соединения с удаленным узлом, а столбец DBUSER_OWNER
показывает владельца этой связи баз данных.
Кроме того, столбец INTERFACE показывает, является ли локальный
узел или подчиненный узел стороной точки подтверждения.
Для трассировки дерева сессий вы можете опросить локальный обзор
DBA_2PC_NEIGHBORS. В данном случае, вы опрашиваете этот обзор
на базе данных WAREHOUSE. (Здесь результаты запроса для
простоты переставлены.)
SELECT * FROM sys.dba_2pc_neighbors
WHERE local_tran_id = '1.21.17'
ORDER BY sess#, in_out;
Column Name Value
--------------------- --------------------------------------
LOCAL_TRAN_ID 1.21.17
IN_OUT in
DATABASE SALES.ACME.COM
DBUSER_OWNER SWILLIAMS
INTERFACE N
DBID 000003F4
SESS# 1
BRANCH 0100
Особый интерес здесь представляют столбцы IN_OUT, DATABASE,
DBUSER_OWNER и INTERFACE. В данном примере эта информация
сообщает о том, что наш узел (WAREHOUSE) является сервером узла
15-22 Руководство администратора
SALES, и что соединение к WAHEHOUSE было установлено через связь
баз данных под учетным именем SWILLIAMS.
В этот момент вы можете обратиться к администраторам локальных
узлов и попросить их повторить шаги 2 и 3, используя глобальный
идентификатор транзакции.
Замечание: Если вы можете непосредственно соединиться с этими
узлами, используя другую сеть, то вы можете повторить шаги 2 и 3
самостоятельно.
Например, следующие результаты будут получены при выполнении
шагов 2 и 3 на узлах SALES и HQ, соответственно:
На узле SALES:
SELECT * FROM sys.dba_2pc_pending
WHERE global_tran_id = 'SALES.ACME.COM.55d1c563.1.93.29';
Column Name Value
---------------------- -----------------------------------------
LOCAL_TRAN_ID 1.93.29
GLOBAL_TRAN_ID SALES.ACME.COM.55d1c563.1.93.29
STATE prepared
MIXED no
ADVICE
TRAN_COMMENT Sales/New Order/Trans_type 10B
FAIL_TIME 31-MAY-91
FORCE_TIME
RETRY_TIME 31-MAY-91
OS_USER SWILLIAMS
OS_TERMINAL TWA139:
HOST system1
DB_USER SWILLIAMS
COMMIT#
SELECT * FROM sys.dba_2pc_neighbors
WHERE global_tran_id = 'SALES.ACME.COM.55d1c563.1.93.29'
ORDER BY sess#, in_out;
На узле SALES для этой транзакции выдаются три строки (одна для
соединения к WAREHOUSE, одна для соединения к HQ, и одна для
соединения, установленного пользователем). Информация,
соответствующая соединениям с узлами WAREHOUSE и HQ, показана
ниже:
Управление распределенными базами данных 15-23
Column Name Value
--------------------- --------------------------------------
LOCAL_TRAN_ID 1.93.29
IN_OUT OUT
DATABASE WAREHOUSE.ACME.COM
DBUSER_OWNER SWILLIAMS
INTERFACE N
DBID 55d1c563
SESS# 1
BRANCH 1
Column Name Value
--------------------- --------------------------------------
LOCAL_TRAN_ID 1.93.29
IN_OUT OUT
DATABASE HQ.ACME.COM
DBUSER_OWNER ALLEN
INTERFACE C
DBID 00000390
SESS# 1
BRANCH 1
Эта информация вскрывает несколько фактов:
* SALES - это глобальный координатор, потому что для него
локальный идентификатор транзакции и глобальный
идентификатор транзакции совпадают. Заметьте также, что
из этого узла установлены два исходящих соединения, но
нет ни одного входящего соединения (т.е. этот узел не
является сервером никаких других узлов).
* HQ или один из его серверов (в нашем примере таких нет)
является стороной точки подтверждения.
На узле HQ:
SELECT * FROM sys.dba_2pc_pending
WHERE global_tran_id = 'SALES.ACME.COM.55d1c563.1.93.29';
Column Name Value
---------------------- -----------------------------------------
LOCAL_TRAN_ID 1.45.13
GLOBAL_TRAN_ID SALES.ACME.COM.55d1c563.1.93.29
STATE COMMIT
MIXED NO
ADVICE
TRAN_COMMENT Sales/New Order/Trans_type 10B
FAIL_TIME 31-MAY-91
FORCE_TIME
RETRY_TIME 31-MAY-91
OS_USER SWILLIAMS
OS_TERMINAL TWA139:
HOST SYSTEM1
DB_USER SWILLIAMS
COMMIT# 129314
15-24 Руководство администратора
К этому моменту вы нашли узел, который разрешил транзакцию, и
узнали, что она была подтверждена. Поэтому вы можете
форсировать подтверждение этой сомнительной транзакции на вашей
локальной базе данных (см. следующую секцию для информации о
ручном подтверждении или откате сомнительных тразакций).
Хорошей идеей было бы также связаться со всеми остальными
администраторами, которых вы знаете, и которые могли бы извлечь
пользу из ваших расследований.
ПРОВЕРКА НА СМЕШАННЫЙ ИСХОД. После того, как вы вручную
форсируете подтверждение или откат транзакции, соответствующая
строка в таблице висящих транзакций остается. Состояние
транзакции (STATE) изменяется на "forced commit" или "forced
abort", в зависимости от того, как вы разрешили транзакцию.
Впоследствии, когда соединения между инстанциями смогут быть
восстановлены, процесс RECO проверяет глобальный исход
транзакции. Если вы разрешили транзакцию неверно, то столбец
MIXED изменится на "yes", и строка для этой транзакции не будет
удалена. Если вы когда-нибудь встретитесь с транзакцией,
разрешенной неверно, вы должны знать, что может иметь место
глобальная несогласованность данных между базами данных. В
конечн счете, вы можете вручную удалить ненужные строки из
таблицы висящих транзакций.
Ручное подтверждение сомнительных транзакций
Чтобы вручную форсировать подтверждение сомнительной транзакции,
локальный администратор может использовать либо диалоговое окно
Recover In-Doubt Transaction SQL*DBA, либо команду SQL COMMIT
WORK с опцией FORCE и текстовой строкой, указывающей локальный
или глобальный идентификатор подтверждаемой транзакции.
Рис.15-2 показывает диалоговое окно Recover In-Doubt
Transaction.
Рис.15-2
Диалог Recover In-Doubt Transaction
---------------------------------------------------------------¬
¦ File Edit Session Instance Storage Log Backup Security¦
¦--------------------------------------------------------------+
¦¦ ¦
¦¦ г=========== Recover In-Doubt Transaction ======¬ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ (o) Commit ¦ ¦
¦¦ ¦ ( ) Rollback ¦ ¦
¦¦ ¦ ¦ ¦
¦¦ ¦ In-Doubt Distributed Transaction: ¦ ¦
¦¦ ¦ --------------------------------------------¬ ¦ ¦
¦¦ ¦ ¦ SALES.ACME.COM.55d1c563.1.93.29-----------¦ ¦ ¦
¦¦ ¦ ¦ SALES.ACME.COM.55d1c563.1.93.45 ¦ ¦ ¦
¦¦ ¦ ¦ ¦ ¦ ¦
¦¦ ¦ L-------------------------------------------- ¦ ¦
¦¦ ¦-----------------------------------------------¦ ¦
¦+--------¦ (OK) (Cancel) ¦----+
¦¦ L===============================================- ¦
¦¦ ¦
¦¦ ¦
¦L-------------------------------------------------------------+
L---------------------------------------------------------------
Управление распределенными базами данных 15-25
Следующее предложение является командным эквивалентом
диалогового окна Recover In-Doubt Transaction, показанного на
рис.15-2:
COMMIT FORCE 'SALES.ACME.COM.55d1c563.1.93.29';
В обоих примерах транзакция подтверждается на локальном узле, и
в столбец STATE в строке локальной таблицы висящих транзакций
для данной транзакции записывается значение "forced commit".
При форсировании подтверждения транзакции можно специфицировать
необязательный системный номер изменения (SCN) для этой
транзакции; это средство позволяет вам подтвердить сомнительную
транзакцию с тем SCN, который был ей назначен при подтверждении
на других узлах, и тем самым поддержать синхронизацию момента
подтверждения распределенной транзакции даже в случае сбоя. SCN
должен специфицироваться лишь в том случае, если вы можете
определить SCN этой транзакции, успевшей подтвердиться на другом
узле.
Например, предположим, что вы хотите вручную подтвердить
транзакцию с глобальным идентификатором транзакции global_id.
Прежде всего, опросите обзор DBA_2PC_PENDING на удаленной базе
данных, также участвовавшей в этой транзакции, и запишите SCN,
который был использован при подтверждении транзакции на этом
узле. Затем специфицируйте этот SCN (десятичное число) при
подтверждении транзакции на локальном узле. Например, если
обнаруженное значение SCN равно 829381993, выдайте команду:
COMMIT FORCE 'global_id', 829381993;
Ручной откат сомнительных транзакций
Чтобы вручную форсировать откат сомнительной транзакции,
локальный администратор может использовать либо диалоговое окно
Recover In-Doubt Transaction SQL*DBA, либо команду SQL ROLLBACK
WORK с опцией FORCE и текстовой строкой, указывающей локальный
или глобальный идентификатор подтверждаемой транзакции.
Например, чтобы форсировать откат сомнительной транзакции с
локальным идентификатором транзакции 2.9.4, введите следующее
предложение:
ROLLBACK FORCE '2.9.4';
После выполнения этого предложения транзакция откатывается на
локальном узле, и в столбец STATE в строке локальной таблицы
висящих транзакций для данной транзакции записывается значение
"forced abort".
Замечание: Нельзя форсировать откат сомнительной распределенной
транзакции к точке сохранения; можно форсировать лишь ее полный
откат.
Привилегии, требуемые для ручного подтверждения или отката
сомнительных распределенных транзакций
Для ручного подтверждения или отката сомнительной распределенной
транзакции, которая была выдана вами, вы должны иметь системную
привилегию FORCE TRANSACTION. Для ручного подтверждения или
отката сомнительной распределенной транзакции, которая была
15-26 Руководство администратора
выдана другим пользователем, вы должны иметь системную
привилегию FORCE ANY TRANSACTION. Обе привилегии могут быть
получены как явно, так и через роль.
Замечание: Форсирование подтверждения или отката сомнительной
распределенной транзакции не влияет на состояние текущей
транзакции оператора.
Изменение времени удержания соединения
--------------------------------------
После сбоя распределенной транзакции, соединение от локального
узла к удаленному узлу не обязательно закрывается немедленно;
вместо этого оно остается открытым на случай, если связь будет
восстановлена быстро, что позволит не устанавливать соединение
заново. Вы можете установить интервал времени, в течение
которого соединение удерживается открытым, с помощью параметра
инициализации DISTRIBUTED_RECOVERY_CONNECTION_HOLD_TIME.
Высокое значение минимизирует стоимость возобновления соединений
после сбоев, но заставляет локальную базу данных потреблять
больше ресурсов. Напротив, низкое значение этого параметра
минимизирует стоимость ресурсов, удерживаемых в течение сбоя, но
увеличивает стоимость возобновления соединений после отказа.
Умалчиваемое значение этого параметра - 200 секунд. Для
дополнительной информации обратитесь к приложению A.
Ограничение числа распределенных транзакций
-------------------------------------------
Параметр базы данных DISTRIBUTED_TRANSACTIONS задает максимум
для числа распределенных транзакций, в которых может участвовать
база данных. Вы должны увеличить значение этого параметра, если
ваша база данных вовлекается в большое число распределенных
транзакций; умалчиваемое значение его зависит от операционной
системы.
Напротив, если на вашем узле слишком часто возникают сетевые
отказы, вы можете временно уменьшить значение этого параметра.
Это ограничит количество распределенных транзакций, в которых
принимает участие ваша сторона, и тем самым ограничит как объем
блокированных данных на вашем узле, так и число сомнительных
транзакций, которые вам может потребоваться разрешать.
Для дополнительной информации об этом параметре обратитесь к
приложению A.
Тестирование средств восстановления распределенных транзакций
-------------------------------------------------------------
Если хотите, вы можете искусственно вызвать сбой распределенной
транзакции, чтобы пронаблюдать, как RECO автоматически разрешит
локальную порцию этой транзакции. Альтернативно, вы можете
захотеть вызвать сбой распределенной транзакции для того, чтобы
попрактиковаться в ручном разрешении сомнительных распределенных
транзакций и пронаблюдать результаты. Следующие секции
описывают возможные средства и необходимые шаги для
осуществления таких операций.
Форсирование сбоя распределенной транзакции
В параметр COMMENT предложения COMMIT следует включить
специальный комментарий. Чтобы преднамеренно вызвать сбой
Управление распределенными базами данных 15-27
распределенной транзакции во время двухфазного подтверждения,
включите в параметр COMMENT следующий комментарий:
COMMIT COMMENT 'ORA-2PC-CRASH-TEST-n';
где n - одно из следующих целочисленных значений:
n Эффект
----------------------------------------------------------------
1 Сбой стороны точки подтверждения после сбора
2 Сбой не стороны точки подтверждения после сбора
3 Сбой стороны точки подтверждения перед подготовкой
4 Сбой не стороны точки подтверждения после подготовки
5 Сбой стороны точки подтверждения перед подтверждением
6 Сбой стороны точки подтверждения после подтверждения
7 Сбой не стороны точки подтверждения перед подтверждением
8 Сбой не стороны точки подтверждения после подтверждения
9 Сбой стороны точки подтверждения перед забыванием
10 Сбой не стороны точки подтверждения после забывания
Например, следующее предложение возвращает приведенные ниже
сообщения, если локальная сила точки подтверждения выше
удаленной силы точки подтверждения, и обновлялись оба узла:
COMMIT COMMENT 'ORA-2PC-CRASH-TEST-7';
ORA-02054: transaction #.##.## in-doubt
ORA-02059: ORA-CRASH-TEST-n in commit comment
В этот момент сомнительная распределенная транзакция появится в
обзоре DBA_2PC_PENDING. Если процесс RECO включен, он
автоматически быстро разрешит эту транзакцию.
Привилегии, требуемые для форсирования сбоя двухфазного подтверждения
Вы можете вызывать сбои двухфазного подтверждения через
приведенные выше комментарии только тогда, когда и локальная, и
удаленная сессии имеют системную привилегию FORCE ANY
TRANSACTION. В противном случае при выдаче предложения COMMIT с
комментарием такого вида будет возвращена ошибка.
Включение и выключение RECO
---------------------------
Фоновый процесс RECO можно включать и выключать с помощью
команды ALTER SYSTEM с опциями ENABLE/DISABLE DISTRIBUTED
RECOVERY, соответственно. Например, вы можете захотеть временно
отключить RECO для того, чтобы форсировать сбой двухфазного
подтверждения и вручную разрешить сомнительную транзакцию.
Следующее предложение отключает процесс RECO:
ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY;
15-28 Руководство администратора
Альтернативно, следующее предложение включает процесс RECO, так
что сомнительные транзакции будут разрешаться автоматически:
ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY;
Замечание: Однопроцессные инстанции (например, на PC под
управлением MS-DOS) не имеют отдельных фоновых процессов, и,
следовательно, не имеют отдельного процесса RECO. Поэтому при
первом запуске однопроцессной инстанции, участвующей в
распределенной базе данных, следует вручную включать средства
распределенного восстановления посредством предложения,
показанного выше. Обратитесь к вашему руководству по
инсталляции [IUG] для дополнительной информации о восстановлении
распределенных транзакций для однопроцессных инстанций.