Oracle DBA Forum  

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

Ответ
 
Опции темы Опции просмотра
  #1  
Старый 03.10.2009, 02:38
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию 04 Восстановление после несущественных потерь

__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #2  
Старый 03.10.2009, 02:39
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Рассматриваемые вопросы

__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #3  
Старый 03.10.2009, 02:41
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Причины потери файла



Причины потери файла

Файлы могут быть потеряны или повреждены вследствие следующих причин:

Ошибка пользователя. Администратор может непреднамеренно удалить или перенести необходимый для функционирования файл в операционной системе.
Ошибка в приложении. Приложение или скрипт может содержать логическую ошибку, которая при обработке файлов базы данных приводит к потере или повреждению файла.
Потеря носителя. Может произойти полный или частичный откат дисковода или контроллера, в результате чего искажаются или даже полностью теряются файлы.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #4  
Старый 03.10.2009, 02:42
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Сравнение критических и некритических потерь



Сравнение критических и некритических потерь

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

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

Например:

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

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

- Потеря временного табличного пространства может не позволить пользователям выполнять запросы или создавать индексы до тех пор, пока пользователям не будет назначено новое временное табличное пространство.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #5  
Старый 03.10.2009, 02:44
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Потеря временного файла (TEMPFILE)



Потеря временного файла (TEMPFILE)

Временной табличное пространство (например, TEMP) становится недоступным, когда теряется или повреждается принадлежащий ему файл. Эта проблема обнаруживается в ходе выполнения команд SQL, которым необходимо временное табличное пространство для сортировки.

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

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

В таких случаях в сигнальном файле при старте БД появляется сообщении, подобное приведенному ниже:

Recreating tempfile /u01/app/oracle/oradata/orcl/temp01.dbf
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #6  
Старый 03.10.2009, 02:46
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Восстановление при потере временного файла



Восстановление при потере временного файла

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

Чтобы выполнить восстановление в базе данных после такого удаления добавьте новый файл, а затем выполните операцию drop для удаленного файла:

Код:
SQL> ALTER TABLESPACE temp ADD TEMPFILE
'/u01/app/oracle/oradata/orcl/temp02.dbf' SIZE 20M; Tablespace altered.

SQL> ALTER TABLESPACE temp DROP TEMPFILE '/u01/app/oracle/oradata/orcl/temp01.dbf;
Tablespace altered.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #7  
Старый 03.10.2009, 02:47
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Статус журнальной группы



Статус журнальной группы

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

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

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

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

INACTIVE
Выше упомянутая контрольная точка завершилась, и поэтому оперативная журнальная группа больше не нужна для восстановления после сбоя экземпляра. Такая группа свободна и может быть следующей текущей (статус CURRENT) журнальной группой.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #8  
Старый 03.10.2009, 02:49
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Потеря элемента оперативной журнальной группы



Потеря элемента оперативной журнальной группы

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

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

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

При потере нетекущей оперативной журнальной группы можно воспользоваться командой ALTER DATABASE CLEAR LOGFILE, чтобы пересоздать элементы этой группы. При этом не происходит никаких транзакционных потерь. В случае, когда журнальная группа была заархивирована до того, как произошла ее потеря, больше ничего не требуется делать. В противном случает необходимо немедленно выполнить полное резервирование базы данных. Резервные объекты, полученные до момента потери журнала, не пригодны для восстановления.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #9  
Старый 03.10.2009, 02:52
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Пересоздание оперативных журнальных файлов



Пересоздание оперативных журнальных файлов

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

Для удаления оперативной журнальной группы необходимо иметь системную привилегию ALTER DATABASE.

Кроме того, следует принять меры предосторожности и учесть следующие ограничения:

Экземпляру требуются хотя бы две группы оперативных журнальных файлов, независимо от количества элементов в группах.
Группу или элемент группы можно удалить только, когда группа неактивна (статус INACTIVE в представлении V$LOG).
Когда БД в архивном режиме, удалить элемент или группу можно, если оперативная журнальная группа заархивирована (YES в столбце ARCHIVED представления V$LOG).



Удаление группы оперативных журналов производится по команде SQL ALTER DATABASE, содержащей фразу DROP LOGFILE.

Следующая команда удаляет группу под номером 3:

Код:
ALTER DATABASE  DROP LOGFILE GROUP 3;

Чтобы удалить элемент оперативной журнальной группы, необходимо иметь системную привилегию ALTER DATABASE.

Кроме того, следует принять меры предосторожности и учесть следующие ограничения:

Можно удалить оперативные журнальные файлы, и в результате мультиплексируемый журнал становится временно асимметричным. Например, при использовании дуплексных групп оперативных журналов можно удалить один элемент в одной группе, при этом во всех остальных группах останется по два файла. Настоятельно рекомендуется немедленно исправить эту ситуацию и сделать так, чтобы во всех группах было хотя бы два элемента. Тогда все группы будут защищены от возможного сбоя.
Экземпляру требуются хотя бы две работоспособные группы оперативных журнальных файлов, независимо от количества элементов в группах.
Если БД в архивном режиме, проверьте, что группа, к которой принадлежит удаляемый файл, была заархивирована. Для этого запросите представление
V$LOG.
Элемент журнальной группы не может быть удален, когда его группа активна или является текущей. Если необходимо удалить элемент текущей группы, сначала выполните принудительное переключение журнала. После этого группа переходит либо в состояние ACTIVE, либо INACTIVE. Если состояние INACTIVE, тогда можно выполнить команду удаления группы. Если же состояние ACTIVE, тогда следует сначала выполнить принудительную контрольную точку, чтобы перевести группу в состояние INACTIVE. В следующем примере показывается, как происходит такой переход для первой группы (1 в столбце GROUP# ), которая сначала имела статус CURRENT, затем ACTIVE и наконец INACTIVE:





Для удаления элемента неактивной и нетекущей группы оперативных журналов используется команда SQL ALTER DATABASE, содержащая фразу DROP LOGFILE MEMBER.

Следующая команда удаляет оперативный журнальный файл /u01/арр/oracle/oradata/orcl/redo02b.log:


Код:
ALTER DATABASE DROP LOGFILE MEMBER
'/u01/арр/oracle/oradata/orcl/redo02b.log';
При удалении журнальной группы или отдельного элемента всегда удаляются ссылки на них в управляющем файле, а соответствующие файлы в операционной системе остаются, кроме случая, когда используются файлы, сопровождаемые Oracle {Oracle Managed Files - OMF). Проверьте, что операция удаления элемента или оперативной журнальной группы завершилась успешно, а затем, если не использовались OMF-файлы, удалите файлы оперативных журналов с помощью соответствующих команд ОС.

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

Последний раз редактировалось Marley; 03.10.2009 в 02:55.
Ответить с цитированием
  #10  
Старый 03.10.2009, 02:56
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Пересоздание оперативных журнальных файлов



Пересоздание оперативных журнальных файлов

Enterprise Manager позволяет создавать и редактировать информацию о группах оперативных журналов, связанных с текущей базой данных. Для этого на странице Administration выберите ссылку Redo Log Groups в секции Storage.

На странице Redo Log Groups выводится информация о каждой журнальной группе, а также предоставляется возможность просмотра и редактирования состава группы.

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

Добавить или удалить элементы группы можно, используя кнопку Edit.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
Ответ
Опции темы
Опции просмотра

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

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

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


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


Powered by vBulletin®