Oracle DBA Forum  

Вернуться   Oracle DBA Forum > Работа > Администрирование

Ответ
 
Опции темы Опции просмотра
  #1  
Старый 03.03.2010, 11:42
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Конфигурирование, способствующее восстанавливаемости

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

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

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

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

Хранение архивных копий оперативных журналов. При потере файла его копию восстанавливают из резерва и применяет к ней информацию повторного выполнения, подкатывая копию вперед до самого последнего SNC, содержащегося в управляющем файла. В конфигурации по умолчанию, журнальные данные могут быть переписаны сразу после того, как они попали в файлы данных. БД можно сконфигурировать так, чтобы журнальная информация копировалась и сохранялась в архивных копиях. Для этого БД надо перевести в режим ARCHIVELOG.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #2  
Старый 03.03.2010, 11:42
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Мультиплексирование управляющих файлов

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

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

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


Дублирование управляющего файла (Мультиплексирование управляющего файла)
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 05.03.2010 в 13:23.
Ответить с цитированием
  #3  
Старый 03.03.2010, 11:42
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию

Оперативные журнальные файлы

Журнальные группы (redo log groups) состоят из одного или нескольких журнальных файлов ( журнальных файлов повторного выполнения, redo log files). Каждый файл внутри группы точная копия других элементов группы. Oracle рекомендует иметь, по крайне мере, два файла на группу, а также распределять их по разным диска/ контроллерам так, чтобы отказ какого-то одного устройства не повредил всю журнальную группу.

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

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


Мультиплексирование журнала



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


Перейдите на страницу Redo Log Groups
Выберите группу и щелкните на кнопке Edit, или же щелкните на ссылке, представляющей номер группы.

В разделе Redo Log Members щелкните на кнопке Add. Появится страница Add Redo Log Member.

Введите имя файла и имя каталога. Щелкните на кнопке Continue.

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

Сразу после добавления члена группы его статус INVALID. Это ожидаемое состояние, поскольку в новый файл группы еще не было записи. После переключения журнала, когда группа станет текущей, статус нового файла изменится на CURRENT
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #4  
Старый 03.03.2010, 11:43
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию

Архивные журнальные файлы.

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

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

1) Задать формат имени архивных журнальных файлов.

2) Указать одно или несколько мест хранения архивных журналов.

3) Перевести базу данных в режим ARCHIVELOG

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


Имена и места расположения архивных журнальных файлов

Щелкните на ссылке Configure Recover Settings на странице Maintenance.

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

%s включает в имя файла номер журнала (log sequence number);

%t включает в имя файла номер потока (thread number)

%r идентификатор сброса журналов (Resetlogs ID); гарантирует уникальность имени архивных журнальных файлов после выполнения специального восстановления, вызывающего сброс номера журнала;

%d включает в имя файла идентификатор БД (database ID).

Формат должен содержать шаблоны %s, %t, %r. Если одно место хранения используется для размещения архивных журналов нескольких баз данных, следует использовать шаблон %d.

Максимально архивные журналы могут записываться в десять различных мест расположения. Эти места расположения могут быть локальными (каталог) или удаленными (пресдоним Oracle Net для резервной базы данных. Имя локального местоположения должно заканчиваться косой чертой (/) или (в Windows) обратной косой чертой (\).

По умолчанию архивный журнал создается в месторасположение под номером 10, определяемом параметром инициализации DB_RECOVERY_FILE_DEST. Этот параметр задает флешь-область восстановления (flash recovery area). Месторасположение флешь-области выводится в нижней части страницы Configure Recovery Settings в поле Flash Recovery Area Location. Чтобы это месторасположение не использовалось для хранения архивных журналов, просто удалите USE_DB_RECOVERY_FILE_DEST.

Операции по изменению параметров восстановления необходимо выполнять, подсоединившись как SYSDBA или SYSOPER


Режим ARCHIVELOG

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

Следующая команда SQL переводи базу данных в режим ARCHIVELOG;
SQL> ALTER DATABASE ARCHIVELOG;

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

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

В режиме ARHCIVELOG восстановление возможно до момента времени последней фиксации. Большинство промышленных баз данных работает в режиме ARCHIVELOG.

Примечание: Выполните резервирование базы данных после перевода в режим ARCHIVEOG, поскольку в этом режиме база данных может быть восстановлена с использованием последних резервных объектов, полученных только в этом режиме.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
Ответ

Метки
дублирование управляющего файла, control file multiplexing

Опции темы
Опции просмотра

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

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

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


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


Powered by vBulletin®