Oracle DBA Forum  

Вернуться   Oracle DBA Forum > Oracle University Official Study Notes (RUS) > База данных Oracle 10g Администрирование > База данных Oracle 10g Администрирование II

Ответ
 
Опции темы Опции просмотра
  #21  
Старый 11.10.2009, 05:10
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Использование возможности выделения пространства для возобновления приостановленной



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

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

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

Команда ALTER SESSION ENABLE RESUMABLE.
Задание отличного от нуля значения для параметра инициализации RESUMABLE_TIMEOUT С ПОМОЩЬЮ команды ALTER SESSION ИЛИ ALTER SYSTEM.

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

Время тайм-аута можно также задать с помощью команды:

Код:
ALTER SESSION ENABLE RESUMABLE TIMEOUT 3600;
Значение параметра TIMEOUT действует до следующего его изменения в другой команде ALTER SESSION ENABLE RESUMABLE, следующего изменения с помощью иного средства и до конца сеанса. При использовании фразы ENABLE RESUMABLE TIMEOUT для включения возобновляемого режима значение тайм-аута по умолчанию -7200 секунд (2 часа).

Дополнительно можно задать имя для возобновляемых команд.

Например:

ALTER SESSION ENABLE RESUMABLE TIMEOUT 3600 NAME 'multitab insert';


Имя команды используется для идентификации возобновляемой команды в представлении DBA_RESUMABLE ИЛИ USER_RESUMABLE.


Пример:



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

Так как возобновляемые команды удерживают некоторые системные ресурсы, пользователям должна быть предоставлена системная привилегия RESUMABLE перед тем, как они смогут включить возможность выделения пространства для продолжения операции и начнут выполнять возобновляемые команды.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #22  
Старый 11.10.2009, 05:14
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Возобновление приостановленных команд



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


Пример:

1. Команда INSERT наталкивается на ошибку, связанную с тем, что таблица полностью заполнена.
2. Команда INSERT приостанавливается, и никакая ошибка не передается клиенту.
3. Дополнительно может сработать триггер AFTER SUSPEND.
4. Дополнительно с помощью процедуры DBMS_RESUMABLE.ABORT может быть возбуждено исключение SERVERERROR для аварийного завершения команды.
5. Если команда не завершилась аварийно и успешно добавлено свободное пространство таблице, команда INSERT возобновляет выполнение.

Обнаружение приостановленной команды

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

Возможные действия в приостановленном состоянии

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

Внутри кода триггера можно использовать представление USERRESUMABLE или DBA_RESUMABLE, а также функцию DBMS_RESUMABLE . SPACE_ERROR_INFO ДЛЯ получения информации о возобновляемых командах.

Когда приостанавливается возобновляемая команда:

сеанс, в котором была введена команда переходит в состояние ожидания; в представление V$SESSION_WAIT вставляется строка, содержащая в столбце EVENT следующее: "statement suspended, wait error to be cleared";
появляется сигнальное сообщение о необходимости дополнительных ресурсов для завершения приостановленной операции над объектом.


Завершение приостановленной команды

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

Для приостановленной команды можно принудительно возбудить исключение SERVERERROR с помощью процедуры DBMS_RESUMABLE . ABORT (). Эта процедура может быть выполнена пользователем с ролью DBA или же тем, кто производит приостановленную операцию.

Когда заканчивается временной интервал приостановки, команда автоматически аварийно завершается и пользователю возвращается сообщение об ошибке.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #23  
Старый 11.10.2009, 05:15
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Переносимые табличные пространства



Переносимые табличные пространства

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

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

Примечание: функциональная возможность межплатформенных табличных пространств (cross-platform transportable tablespace feature) требует, чтобы обе платформы использовали одну и ту же кодировку символов.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #24  
Старый 11.10.2009, 05:16
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Концепция минимального уровня совместимости



Концепция минимального уровня совместимости

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

Когда файлы данных в первый раз открываются базой данных Oracle 10g с параметром инициализации COMPATIBLE, в котором установлено значение 10.0.0 (или выше), информация о платформе запоминается в файлах (platform-aware files). На диаграмме это отображается отметкой ("галочкой"). Каждый файл идентифицируется платформой, которой он принадлежит. Такие файлы (platform-aware files) имеют на диске одинаковые форматы блоков заголовков файлов, которые используются для идентификации и верификации. Файлы, находящиеся в режиме 'только чтение' или в автономном состоянии, начинают использовать преимущество переносимости после перевода в режиме чтение/запись или оперативное состояние. Вследствие этого табличные пространства, находившиеся в состоянии 'только чтение' в базах данных Oracle до версии 10g, должны быть хотя бы раз переведены в режим чтения/записи перед тем, как они начнут использовать возможность межплатформенной переносимости.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #25  
Старый 11.10.2009, 05:17
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Процедура переноса табличных пространств



Процедура переноса табличных пространств

При переносе с одной платформы на другую (из источника в целевую систему) файлы данных, принадлежащие набору переносимых табличных пространств должны быть преобразованы в формат, распознаваемый целевой базой данных. Несмотря на то, что дисковые структуры базы данных Oracle 1 Og соответствуют общему формату, возможны отличия на платформе-источнике и целевой платформе в используемых форматах, определяющих порядок байтов в данных (endian formats). Если такие форматы отличаются, воспользуйтесь командой CONVERT утилиты RMAN для преобразования порядка байтов. Эта операция может быть произведена либо на платформе-источнике, либо на целевой платформе. Для платформ с совпадающим порядковым форматом {endian format) преобразование не требуется.

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

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

Примечание: Порядок байтов может повлиять на результат при чтении или записи данных. Например, 2-х байтное целое число 1 записывается как 0x0001 в системах с обычным порядком байтов (big-endian system). Пример такой системы - Sun SPARC Solaris. Такое же число в системе с ооратным порядком {little-endian system) хранится в виде 0x0100 . Пример таких систем - Intel-совместимые PC.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #26  
Старый 11.10.2009, 05:19
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Выяснение порядкового формата платформы



Выяснение порядкового формата платформы

Для проверки того, одинаков ли порядковый формат на обоих платформах, выполните запрос к представлению V$TRANSPORTABLE_PLATFORM. Представление V$DATABASE содержит два столбца, используемые для нахождения наименования и идентификатора вашей платформы.

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



На платформе Microsoft Windows на основе процессоров Intel команда SELECT возвращает следующее:


__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #27  
Старый 11.10.2009, 05:20
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Переносимые базы данных



Переносимые базы данных

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

Назначение функциональной возможности переносимых баз данных - предоставить быстрый и простой способ переноса базы данных между различными платформами, имеющими одинаковый порядковый формат (endian format). Однако исходная и целевая платформы могут иметь различное выравнивание на диске (disk alignment). Например, HP-UX и Solaris -обе платформы с порядковым форматом big, но дисковое выравнивание для HP-UX - 8, для Solaris - 4.

Для переноса баз данных с одной платформы на другую необходимо убедиться в том, что исходная и целевая системы функционируют на платформах, присутствующих в представлении V$TRANSPORTABLE_PLATFORM, а также имеют одинаковый порядковый формат. Например, можно перенести базу данных, функционирующую в Linux IA (32-bit), на одну из платформ Windows.

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

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

Примечание: перенос БД более быстро перемешает данные, чем Data Pump.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #28  
Старый 11.10.2009, 05:21
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Процедура переноса базы данных: преобразование в исходной системе



Процедура переноса базы данных: преобразование в исходной системе

Перед переносом базы данных ее следует открыть в режиме READ ONLY. Затем с помощью RMAN необходимо преобразовать требуемые файлы данных.

Когда преобразование выполняется на исходной платформе, применяется новая команда RMAN CONVERT DATABASE. Она генерирует скрипт, содержащий корректную команду CREATE CONTROLFILE RESETLOGS, используемую в целевой системе для создания новой базы данных. Кроме того, команда CONVERT DATABASE преобразует все идентифицируемые файлы данных (platform-aware files) таким образом, чтобы их можно было использовать в целевой системе. После выполнения команды CONVERT DATABASE вы передаете файлы данных и сгенерированный скрипт на целевую платформу. В результате выполнения переданного скрипта на целевой платформе создается новая копия вашей базы данных.

Примечание: Исходная база данных должна функционировать с параметром инициализации COMPATIBLE, имеющем значение 10.0.0 или выше. Все идентифицируемые табличные пространства должны хотя бы однажды находиться в состоянии READ WRITE после того момента, когда для параметра COMPATIBLE было установлено значение 10.0.0 или выше.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #29  
Старый 11.10.2009, 05:22
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Процедура переноса базы данных: преобразование в целевой системе



Процедура переноса базы данных: преобразование в целевой системе

Перед переносом базы данных ее следует открыть в режиме READ ONLY. Затем с помощью RMAN необходимо преобразовать требуемые файлы данных.

Чтобы выполнить преобразования на целевой платформе, сначала в исходной системе выполните команду CONVERT DATABASE, генерирующую два скрипта. Эти скрипты используются в целевой системе для преобразования файлов данных и для пересоздания управляющих файлов новой базы данных. После выполнения в исходной системе команды CONVERT DATABASE передайте на целевую платформу идентифицируемые файлы данных и оба скрипта. Затем выполняете эти два скрипта в правильном порядке. В первом скрипте для преобразования файлов данных применяется команда RMAN CONVERT DATAFILE. Во втором скрипте для создания новой базы данных используется команда SQL CREATE CONTROLFILE RESETLOGS, в которой указаны преобразованные файлы данных.

Примечание: Исходная база данных должна функционировать с параметром инициализации COMPATIBLE, имеющем значение 10.0.0 или выше. Все идентифицируемые табличные пространства должны хотя бы однажды находиться в состоянии READ WRITE после того момента, когда для параметра COMPATIBLE было установлено значение 10.0.0 или выше.
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 18.11.2009 в 15:30.
Ответить с цитированием
  #30  
Старый 11.10.2009, 05:24
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Переносимые базы данных: указания



Переносимые базы данных: указания

Журнальные файлы, управляющие файлы и временные файлы (tempfiles) не переносимы. Они пересоздаются для новой базы данных на целевой платформе. Поэтому новая база данных должна открываться с опцией RESETLOGS.

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

В выходных результатах команды CONVERT DATABASE приводятся все объекты directory, а также объекты, использующие тип данных BFILE и внешние таблицы в исходной БД. Возможно вам придется изменить в этих объектах имена каталогов и файлов. Кроме того, вы должны передать на целевую платформу существующие BFILE.
В сгенерированном pfile и скрипте переноса в качестве файлов данных указываются файлы, сопровождаемые Oracle (Oracle Managed Files - OMF). Если вы не хотите использовать OMF, измените pfile и скрипт переноса.

Перенесенная БД имеет такой же идентификатор (DBID), как и исходная база данных. Вы можете воспользоваться утилитой DBNEWID для изменения DBID. Как в скрипте переноса, так и в выходных результатах команды CONVERT DATABASE приводится подсказка по использованию утилиты DBNEWID.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
Ответ
Опции темы
Опции просмотра

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 17:20. Часовой пояс GMT +3.


Powered by vBulletin®