Oracle DBA Forum  

Вернуться   Oracle DBA Forum > Работа > Архитектура > Файловая подсистема

Ответ
 
Опции темы Опции просмотра
  #1  
Старый 05.03.2010, 14:08
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Файлы журнала базы данных

Файлы журнала базы данных

Файлы журнала базы данных это дисковые ресурсы, которые хранят внесенные пользователями Oracle изменения данных.

============================================

1) Оперативные файлы журнала базы данных это физические файлы, сохраняющие информацию из буфера журнала базы данных в SGA.
2) Изменения, внесенные в блоки данных в базе данных, сохраняются как записи повторов буфере журнала базы данных в SGA.
3) После фиксации транзакции или заполнения буфера журнала базы данных записи повторов скачиваются в оперативные файлы журнала базы данных.
4) Оперативные файлы журнала базы данных могут иметь зеркалированные файлы. Каждый набор файлов, содержащий те же самые данные, называется группой журнала базы данных, зеркалированные файлы называются членами журнала базы данных.
5) Если база данных используется в режиме ARCHIVELOG, то данные в оперативных файлах журнала базы данных архивируются в файлах архивных файлов журнала базы данных, как только журнал заполняется. Это можно сделать вручную или с помощью автоматических процессов архивирования.
6) Если база данных работает в режиме NOARCHIVELOG, то нет необходимости волноваться об архивировании оперативных файлов журнала базы данных.

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

Контрольные точки возникают, как минимум, при переключении журналов базы данных. Они могут также возникать, если с помощью параметров файла init.ora устанавливаются более частые интервалы.
Если интервал контрольно точки CKPT превышает размер файла журнала базы данных, контрольные точки возникают только при переключении журналов базы данных.
__________________
Телеграм чат

Последний раз редактировалось Marley; 05.03.2010 в 14:16.
Ответить с цитированием
  #2  
Старый 05.03.2010, 14:09
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Назначение и структура оперативных файлов журнала базы данных.

Назначение и структура оперативных файлов журнала базы данных.

Oracle использует файлы журнала базы данных для отслеживания производимых пользователями изменений данных, например изменения в блоках сегментов данных в таблицах или индексах. Каждый производящий такое изменение пользовательский процесс генерирует запись повтора, указывающую на выполненное изменение. Эта запись повтора помещается в область SGA называемую буфером журнала базы данных. Процесс LGWR записывает эти изменения в файлы на диске, называемые оперативными файлами журнала базы данных. Oracle предполагает, что существует минимум два файла журнала базы данных. Каждый из файлов журнала базы данных называется группой журнала базы данных (redo log group). В целях надежности Oracle также позволяет создавать зеркальное отображение каждого из файлов журнала базы данных. Такие зеркалированные (mirrored) файлы называются членами группы (members of the group)

Оперативные журналы базы данных функционируют следующим образом. Когда буфер журнала базы данных заполняется записями повторов из пользовательских процессов или если активная транзакция дает команду commit. LGWR записывает содержание буфера журнала базы данных в каждый член группы. Иногда это называется скачиванием (flushing) буфера повторов. Скачивание всего буфера журнала базы данных происходит, даже если фиксируется одна единственная активная транзакция. Записываемая группа считается текущей, потому что LGWR в настоящее время пишет в нее. LGWR вносит записи журнала базы данных в активную группу, пока она не заполнится, после чего переключается на запись в следующую группу журнала базы данных. Это называется переключением журналов (log switch). Когда заполняется и эта группа, LGWR переключается на следующую доступную группу, пока не достигнет последнего файла журнала базы данных. После его заполнения LGWR циклически возвращается назад к первой группе и продолжает вносить записи повторов.
__________________
Телеграм чат
Ответить с цитированием
  #3  
Старый 05.03.2010, 14:09
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Что происходит с содержимым первой группы?

Что происходит с содержимым первой группы?

Ответ на этот вопрос зависит от режима архивирования, в котором работает база данных Oracle. База данных может работать в режиме ARCHIVELOG или NORACHIVELOG. При работе в режиме NOARCHIVELOG LGWR пишет в каждую из групп журналов, а затем циклически возвращается к первой группе и перезаписывают ее содержимое. В случае сбоя этот тип режима не может вернуть базу данных в состояние на момент сбоя. В режиме ARCHIVELOG процесс архиватора (ARCn) копирует внесенные в группы журналов записи повторов в различные местоположения. Для ускорения процесса архивирования можно активизировать более одного процесса архиватора. При работе в этом режиме, базу данных можно восстановить на момент сбоя, применив эти записи архивных файлов журнала базы данных к восстановленным резервным копиям.

В этот момент многих менее опытных в управлении Oracle администраторов БД интересует следующее: если Oracle позволяет восстановиться на момент сбоя, когда база данных работает в режиме ARCHIVELOG, почему же тогда кто-то запускает базу данных в режиме NOARCHIVELOG? Ответ прост. Работающая в режиме ARCHIVELOG база данных Oracle медленнее базы данных, работающей в режиме NOACHIVELOG, хотя при оптимальной настройке базы данных разница в производительности минимальна. Кроме того, не каждой базе данных Oracle требуется архивировать все ее повторы. Например, базе данных в режиме «только для чтения», используемой для обращений к информационному хранилищу, не требуется работа в режиме ARCHIVELOG, потому что пользователи не смогут изменить уже загруженные данные.
__________________
Телеграм чат
Ответить с цитированием
  #4  
Старый 05.03.2010, 14:10
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Переключение режимов архивирования.

Переключение режимов архивирования.

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

1) В SQL*Plus выключите базу данных, для которой требуется изменить режим архивирования с помощью команды shutdown normal или shutdown immediate.
2) Запустите и смонтируйте экземпляр, но не открывайте базу данных. Для перевода базы данных в необходимое состояние, можно использовать команду startup mount.
3) Измените состояние архивирования базы данных с помощью команды alter database archivelog или alter database noarchivelog. Эта команда изменит содержание управляющего файла. Если перезапустить базу данных с помощью команды startup open, Oracle запустит базу данных в указанном режиме.
4) Выключите базу данных на этом этапе и произведите полное резервное копировании в автономном режиме. Если этот шаг останется невыполненным, а затем возникнет необходимость восстановления базы данных из файлов данных, резервные копии которых были созданы до изменения режима архивирования, восстановленная база данных не будет отражать изменения в режиме архивирования. Кроме того, если переключиться из режима NOARCHIVELOG в режим ARCHIVELOG и впоследствии не сделать резервные копии базы данных, нельзя будет восстановить базу данных на момент сбоя. Причина в том, что во время резервного копирования Oracle работает в режиме NOARCHIVELOG.
5) Повторно откройте базу данных с помощью команды alter database open.
__________________
Телеграм чат
Ответить с цитированием
  #5  
Старый 05.03.2010, 14:11
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Управление переключением журнала базы данных и контрольными точками.

Управление переключением журнала базы данных и контрольными точками.

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

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

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

От администратора БД мало что зависит при управлении переключением журналов. Поскольку пользователи будут всегда изменят данные, администратор БД может сделать кое-что для предотвращения записи информации о повторе. Это значит, что можно управлять частотой переключения, изменяя размер членов оперативных файлов журнала базы данных, или вручную, принудительно устанавливая переключения журналов с помощью команды alter system switch logfile. Чем больше файл, тем реже происходит переключение журналов, а чем меньше файлы члена, тем чаще это происходит.

Контрольная точка возникает не только в время переключения журналов, но и из-за конфигурации, при которой для CKPT задаются регулярные интервалы. Если сконфигурировать CKPT с равномерными интервалами, то контрольные точки будут возникать равномерно, так же как и переключение журналов.
__________________
Телеграм чат
Ответить с цитированием
  #6  
Старый 05.03.2010, 14:12
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Определение частоты контрольной точки.

Определение частоты контрольной точки.

Если журналы базы данных очень большие, следует настроить базу данных так, чтобы контрольные точки возникали чаще, чем в момент переключения журналов. Параметр LOG_CHECKPOINT_INTERVAL или LOG_CHECKPOINT_TIMEOUT в файле init.ora позволит установить более частые контрольные точки. Эти два параметра отражают два различных принципа, на которых основывается частота контрольной точки: интервалы по объему и интервалы по времени.

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

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

Другой способ определения частоты контрольной точки состоит в использовании временного интервала. Он задается в параметр LOG_CHECKPOINT_TIMEOUT файла init.ora. Конфигурировать интервалы контрольной точки на основе времени гораздо проще, чем на основе объема, хотя в этом случае контрольные точки возникают через одинаковые интервалы, независимо от объема транзакций в системе. Задание LOG_CHECKPOINT_TIMEOUT устанавливает позицию контрольной точки в то место в файле журнала, где конец журнала базы данных был несколько секунд назад. Благодаря этому во время восстановления требуется считать только число блоков, равное указанному числу секунд. Однако для Oracle разница заключается только в формулировке. Для отключения контрольных точек на основе времени установите LOG_CHECKPOINT_TIMEOUT в ноль, а также не забудьте о новом параметре FAST_START_IO_TARGET. Этот параметр повышает производительность при восстановлении экземпляра. Чем меньше значение этого параметра, тем выше производительность при восстановлении, так как приходится восстанавливать меньшее число блоков. Если этот параметр установлен, DBWn скачивает измененные буферы более энергично.

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

И наконец, можно принудительно расставить контрольные точки с помощью принудительного переключения журналов или вызова контрольной точки. И то и другое можно выполнить с помощью команды alter system. Для принудительного переключения журналов введите команду alter system switch logfie. Для принудительного вызова контрольной точки введите команду alter system checkpoint. Контрольные точки, возникающие без соответствующего переключения журналов базы данных, называются быстрыми контрольными точками (fast_checkpoints), а контрольные точки с переключением полными (full) или завершенными контрольными точками (complete chtckpoints)
__________________
Телеграм чат
Ответить с цитированием
  #7  
Старый 05.03.2010, 14:13
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Мультиплексирование и поддержка журнала базы данных

Мультиплексирование и поддержка журнала базы данных

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

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

Мультиплексирование журнала базы данных на разных дисках полезны для базы данных и в других отношениях. Процесс архиватора (ARCn) управляет архивированием файлов журнала базы данных автоматически, когда база данных работает в режиме ARCHIVELOG. Во время работы ARCn автоматически перемещает архивированные файлы журнала базы данных в местоположение архива, указанное параметром LOG_ARCHIVE_DEST_n в файле init.ora при каждом переключении журналов базы данных. Если группы журнала базы данных находятся на одном диске, во время переключения журналов базы данных может возникать конкуренция при попытке ARCn копировать заполненный журнал базы данных в местоположение архива одновременно с попыткой LGWR писать в следующую группу журналов базы данных. Если члены журнала базы данных и местоположение архива одновременно с попыткой LGWR писать в следующую группу журналов базы данных. Если члены журнала базы данных и местоположение архива находятся на разных дисках, вероятность конкуренции между ARCn и LGWR небольшая, так как ARCn может работать но одном диске, а LGWR на другом.


select a.group#, member, a.status, bytes/1024/1024 as "MB"
from v$log a, v$logfile b
where a.group# = b.group#
order by 1;



select group#, status from v$log;



Сделать первую группу неактивной

SQL> alter system switch logfile;


Удалим 1 группу

SQL> alter database drop logfile group 1;


Добавим 1 группу

SQL> alter database add logfile group 1 ('C:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO1A.LOG ', 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\REDO1B.LOG' ) size 75m;

Делаем, чтобы было

__________________
Телеграм чат

Последний раз редактировалось Marley; 21.09.2015 в 09:58.
Ответить с цитированием
  #8  
Старый 05.03.2010, 14:14
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Добавление и удаление журналов базы данных и членов

Добавление и удаление журналов базы данных и членов

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

alter database add logfie member filename to group grpnum
filename - имя файла с абсолютным путем, который будет теперь иметь группа;
grpnum - номер группы, к которой добавляется член.

Можно также добавить новые группы оперативных файлов журнала базы данных с помощью команды alter database add logfile group grpnum filename.

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

Код:
alter database drop logfile group grpnum.
Учтите, что удаление группы журналов базы данных не удаляет с хоста реальный файл. Эти файлы автоматически удаляются, когда группа журналов базы данных или ее члены удалены.
__________________
Телеграм чат
Ответить с цитированием
  #9  
Старый 05.03.2010, 14:15
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Переименование файлов журнала базы данных

Переименование файлов журнала базы данных

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

1) Введите команду shutdown. Базу данных нельзя открыть, пока вы переименовываете журнал базы данных.
2) Скопируйте файлы журнала базы данных из их старого местоположения в новое с помощью команды операционной системы.
3) Запустите экземпляр и смонтируйте, но не отрывайте базу данных.
4) В SQL*Plus введите команду alter database rename file, чтобы предупредить Oracle о новом местоположении журнала. После ввода этой команды можно удалит копию журнала базы данных из его старого ( а не нового) местоположения.
5) Откройте базу данных
6) Сделайте резервную копию нового управляющего файла.
__________________
Телеграм чат
Ответить с цитированием
Ответ

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

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

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

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


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


Powered by vBulletin®