Oracle DBA Forum  

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

Ответ
 
Опции темы Опции просмотра
  #11  
Старый 26.09.2009, 19:33
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Фоновые процессы и восстановление: оперативные журналы и процесс записи в журнал



Фоновые процессы и восстановление: оперативные журналы и процесс записи в журнал

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

Журнальные файлы входят в группы журналов. Группа содержит журнальный файл и его мультиплексируемые копии. Каждая такая копия - элемент журнальной группы, и каждая группа однозначно определяется ее номером. Процесс записи данных повторного выполнения (log writer - LGWR) пишет информацию из журнального буфера во все файлы журнальной группы. После заполнения файлов журнальной группы или выполнения операции перехода из одной группы в другую процесс LGWR начинает писать в следующую группу. Журнальные группы используются 'по кругу' .

Подсказка по наилучшему практическому методу работы: если это возможно, располагайте мультиплексируемые оперативные журнальные файлы на различных дисках.
__________________
Телеграм чат
Ответить с цитированием
  #12  
Старый 26.09.2009, 19:34
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Фоновые процессы и восстановление: процесс архивирования (ARCn)



Фоновые процессы и восстановление: процесс архивирования (ARCn)

ARCn - необязательный фоновый процесс. Однако он необходим для восстановления потерянных данных из-за сбоев дисков. Как только текущие журнальные файлы заполнятся, Oracle начинает писать в следующие доступные журнальные файлы. Этот процесс называется переключением (log switch). Процесс ARCn запускает резервирование (или архивирование) группы заполненных журнальных файлов после переключения журнальных файлов. Он автоматически архивирует журналы до их повторного использования, сохраняя все изменения, произведенные в базе данных. Это предоставляет возможность администратору восстановить базу данных на определенный момент времени, даже в случает выхода из строя дисков.

Одно из важных решений, которое должен принять АБД, состоит в выборе между двумя режимами работы базы данных: ARCHIVELOG или NOARCHIVELOG.

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

Примечание: режим ARCHIVELOG требуется для реализации большинства стратегий резервирования (и его очень просто сконфигурировать).
__________________
Телеграм чат
Ответить с цитированием
  #13  
Старый 26.09.2009, 19:36
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Восстановление после сбоя экземпляра



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

База данных Oracle 10g автоматически восстанавливается после сбоя экземпляра. Все, что необходимо сделать АБД, - запустить экземпляр базы данных обычным образом. Экземпляр монтирует управляющий файл и затем пытается открыть файлы данных. Если обнаруживается, что файлы данных не были синхронизированы при остановке экземпляра, они подкатываются вперед до момента перед остановом. При этом используется информация в группах оперативных журналов, которая позволяет также подкатить вперед и файлы табличного пространства отмены, чтобы затем откатить незафиксированные транзакции.
__________________
Телеграм чат
Ответить с цитированием
  #14  
Старый 26.09.2009, 19:37
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Фазы восстановления экземпляра



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

Чтобы экземпляр смог открыть файл данных, системный номер изменений (system change number - SCN) в заголовке файла данных должен соответствовать текущему SCN в управляющих файлах базы данных.

Если это не так, экземпляр применяет оперативные журнальные файлы (online redo logs) последовательно "повторно выполняя" транзакции, пока файлы данных не будут синхронизированы с управляющими файлами. Сразу после этого открывается база данных, и пользователи могут к ней подсоединяться .

Когда применяются записи повторного выполнения (redo) оперативного журнала, все транзакции накатываются до момента сбоя. В их число входят и те, которые не были зафиксированы. После открытия базы данных для таких незафиксированных транзакций выполняется откат. В конце фазы отката все файлы содержат только зафиксированные данные.
__________________
Телеграм чат
Ответить с цитированием
  #15  
Старый 26.09.2009, 19:37
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Настройка процесса восстановления после сбоя экземпляра



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

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

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

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

Расстояние между позицией контрольной точки и концом журнала никогда не должно превышать 90% размера наименьшего оперативного журнального файла.
__________________
Телеграм чат

Последний раз редактировалось Marley; 11.11.2009 в 20:37.
Ответить с цитированием
  #16  
Старый 26.09.2009, 19:38
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Консультант MTTR



Консультант MTTR

Консультант позволяет задать требуемое среднее время восстановления (mean-time-to-recover). Чтобы получить подсказку при установлении целевого значения MTTR, перейдите следующим образом с домашней страницы в Enterprise Manager: Administration > Advisor Central > MTTR Advisor Консультант преобразует величину параметра FAST_START_MTTR_TARGET в значения нескольких параметров, позволяющие выполнить восстановление экземпляра за требуемое или меньшее время, если это возможно.

Явное задание значения 0 для параметра FAST_START_MTTR_TARGET отключает автоматическую настройку контрольной точки.
Явное задание для параметра FAST_SТART_MTTR_TARGEТ значения, отличного от нуля, также включает консультанта оперативного журнала (Redo Log Advisor) Устанавливаемое значение параметра FAST_SТART_MTTR_TARGEТ должно удовлетворять соглашению об уровне обслуживания для вашей системы. Установка слишком малой величины для целевого значения MTTR приводит к росту нагрузки на систему со стороны операций ввода-вывода из-за выполнения дополнительных операций записи в файлы данных (что влияет на производительность). Установка же слишком большого значения MTTR означает, что экземпляру понадобится дольше времени, чтобы восстановиться после аварийного завершения.
__________________
Телеграм чат

Последний раз редактировалось Marley; 24.07.2010 в 19:08.
Ответить с цитированием
  #17  
Старый 26.09.2009, 19:39
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Сбой носителя



Сбой носителя

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

При восстановлении необходимо скопировать из резерва и восстановить потерянные файлы. Используйте рекомендуемые приемы, кратко изложенные на следующих страницах. Они обеспечивают возможность восстановления базы данных после сбоя носителя.
__________________
Телеграм чат
Ответить с цитированием
  #18  
Старый 26.09.2009, 19:40
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Конфигурирование, способствующее восстанавливаемости



Конфигурирование, способствующее восстанавливаемости

Для обеспечения наилучшей защиты данных:

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

Мультиплексируйте управляющие файлы. Все управляющие файлы одной и той же БД одинаковые. Не очень сложно восстановиться после потери одного управляющего файла. Более сложно - после потери всех управляющих файлов. Защититься от потери всех управляющих файлов можно, если иметь много копий (по крайней мере, три).

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

Хранение архивных копий оперативных журналов. При потере файла его копию восстанавливают из резерва и применяет к ней информацию повторного выполнения, подкатывая копию вперед до самого последнего SCN, содержащегося в управляющем файле. В конфигурации по умолчанию журнальные данные могут быть переписаны сразу после того, как они попали в файлы данных. БД можно сконфигурировать так, чтобы журнальная информация копировалась и сохранялась в архивных копиях. Для этого базу данных надо перевести в режим ARCHIVELOG.
__________________
Телеграм чат
Ответить с цитированием
  #19  
Старый 26.09.2009, 19:43
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Управляющие файлы



Управляющие файлы

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

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

Потеря одного управляющего файла вызовет отказ экземпляра, поскольку все управляющие файлы должны быть все время доступны. Однако восстановиться можно простым копированием одного из неповрежденных управляющих файлов. При потере всех управляющих файлов восстановиться немного сложнее, но обычно это не катастрофическая ситуация.
__________________
Телеграм чат
Ответить с цитированием
  #20  
Старый 26.09.2009, 19:45
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Дублирование управляющего файла



Дублирование управляющего файла

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

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

создать нескольких копий управляющих файлов - включить имена управляющих файлов в параметр инициализации CONTROL_FILES во время создания базы данных:

CONTROL_FILES=$HOME/ORADATA/u01/ctrl01.ctl,
$HOME/ORADATA/u02/ctrl02.ctl

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

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

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

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


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


Powered by vBulletin®