Oracle DBA Forum  

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

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

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

__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 12.11.2009 в 00:54.
Ответить с цитированием
  #2  
Старый 11.11.2009, 15:04
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Файлы данных

Файлы данных


Код:
select file#, name, status from v$datafile;
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 11.11.2009 в 16:37.
Ответить с цитированием
  #3  
Старый 11.11.2009, 15:05
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Файлы журнала

Файлы журнала


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

После заполнения журнальными записями (redo log entries) первого файла текущий журнальный файл помечается как ACTIVE, если он продолжает оставаться необходимым для восстановления экземпляра, или как INACTIVE, если он более не требуется для восстановления экземпляра; следующий журнальный файл используется повторно с самого начала файла и помечается как CURRENT.

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

Код:
select * from v$logfile;

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

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

Добавление журнала в группу:

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


Код:
alter database add logfile group grpnum filename.

Добавление группы журналов:

Код:
alter database
add logfile group 5
(  'u02/oracle/dc2/log_3a.dbf',
   'u03/oracle/dc2/log_3b.dbf',
   'u04/oracle/dc2/log_3c.dbf') size 10m;

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

Начиная с Oracle 10g, для помощи при определении оптимальных размеров файлов журналов базы данных можно использовать утилиту Redo Logfile Sizing Advisor, позволяющую избежать избыточной деятельности ввода/вывода или заторов.
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 17.11.2009 в 14:21.
Ответить с цитированием
  #4  
Старый 11.11.2009, 15:05
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Управляющие файлы

Управляющие файлы (control files)

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

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

Команда alter database backup control file to trace является еще одним способом копирования управляющего файла. Она продуцирует сценарий SQL, который может быть использован для повторного создания управляющего файла базы данных на тот случай, если все мультиплексированные двоичные версии управляющего файла утеряны вследствие катастрофического отказа.

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

Код:
select * from v$controlfile;
Код:
select name, value from v$spparameter where name='control_files'


Мультиплексирование управляющих файлов

Код:
alter system

set control_files = '/u01/oracle/wnse2/ctriwhsel.ctl', 
                         '/u01/oracle/wnse2/ctrlwhse2.ctl',
                         '/u03/oracle/whse2/ctrlwhse3.ctl',
scope = spfile;
Изменения могут вступить в силу только при следующем запуске экземпляра. Следовательно, будет изменен только SPFILE.

В любом случае, следующим шагом должна быть остановка базы данных. Скопируйте управляющие файлы в новые пункты назначения, специфицированные в параметре CONTROL_FILES, и перезапустите базу данных.
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 05.03.2010 в 14:52.
Ответить с цитированием
  #5  
Старый 11.11.2009, 15:06
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Архивные файлы журналов базы данных

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

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

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

Использование нескольких адресов для архивации заполненных журналов очень важным для одной из возможностей обеспечения высокой доступности Oracle, известной под названием Oracle Data Guard (раньше она называлась Oracle Standby Database резервная база данных Oracle).

Код:
select member from v$logfile
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 11.11.2009 в 16:18.
Ответить с цитированием
  #6  
Старый 11.11.2009, 15:06
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Файлы параметров инициализации

Файлы параметров инициализации

При запуске экземпляра базы данных выделяется память для экземпляра Oracle и открывается один их двух типов файла параметров инициализации: либо текстовый файл, который называется init.ora (PFILE), либо файл параметров сервера (SPFILE).

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

Применение SPFILE значительно упрощает управление параметрами и делает его более эффективным для АБД. Если для работающего экземпляра используется SPFILE, любая команда alter system, изменяющая нараметр инициализации системы, может автоматически изменить параметр инициализации в SPFILE.

Код:
select * from v$spparameter
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 11.11.2009 в 16:51.
Ответить с цитированием
  #7  
Старый 11.11.2009, 15:07
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Сигнальный файл ALERT и файл трассировки

Сигнальный файл ALERT и файл трассировки

Логи Oracle пишет в файл сигнального журнала - alert.log
Логи фоновых процессов или сеансов пользователей и в файл трассировочного журнала trace.log.

В файле сигнального журнала ALERT, содержатся как обычные сообщения о состоянии (status messages), так и сообщения о нештатных ситуациях. Когда база данных запускается или останавливается, в файл сигнального журнала делаются соответствующие записи, вместе со списком параметров инициализации, отличающихся от своих значений по умолчанию. Кроме того, фиксируется любая команда alter database или alter system, выданная АБД. Здесь также фиксируются операции, где участвуют табличные пространства и входящие в них файлы данных, например, добавление или удаление табличного пространства, добавление файла данных к табличному пространству. Кроме того, здесь также фиксируются такие исключительные ситуации, как переполнение табличного пространства, разрушение файлов журналов базы данных и т. д.

---

Трассировочные файлы для фоновых процессов экземпляра Oracle также содержатся в BACKGROUND DUMP DEST. Например, в трассировочные файлы для процессов PMON и SMON будут сделаны записи, если происходит ошибка или если процессу SMON необходимо провести восстановление экземпляра; файлы трассировки для процесса QMON содержат информационные сообщения, когда он порождает новый процесс.
Кроме того, трассировочные файлы создаются и для сеансов индивидуальных пользователей или подключений к базе данных.

Трассировочные файлы для процессов пользователей создаются в двух ситуациях: во-первых, когда некоторые типы ошибок происходят в сеансе пользователя вследствие проблемы с привилегиями, выходом за пределы отведенного пространства и тому подобных. Во второй ситуации трассировочный файл может быть создан явно, с помощью команды alter session set sql_trace=true.

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

Сигнальный файл alert может быть удален или переименован в любой момент времени; он будет повторно создан, как только будет сгенерировано новое сообщение в сигнальный файл.
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 11.11.2009 в 15:38.
Ответить с цитированием
  #8  
Старый 11.11.2009, 15:08
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Файлы резервных копий

Файлы резервных копий

Код:
select name from V$recovery_File_Dest;
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 17.11.2009 в 16:25.
Ответить с цитированием
  #9  
Старый 11.11.2009, 15:09
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Файлы паролей

Файлы паролей

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

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

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


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

Совет: Создайте, по крайней мере, еще одного пользователя, кроме пользователей SYS или SYSTEM, у которого имеются привилегии АБД для ежедневных административных задач. Если у базы данных есть несколько АБД, занимающихся ее администрированием, каждый из них должен иметь свою собственную учетную запись с привилегиями АБД.


Аутентификация привилегий SYSOPER и SYSDBA может быть выполнена с помощью аутентификации операционной системы; в этом случае нет необходимости создавать файл паролей, и параметр инициализации REMOTE_LOGIN_PASSWORDFILE должен быть установлен на NONE.
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 11.11.2009 в 15:56.
Ответить с цитированием
Ответ

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

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

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

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


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


Powered by vBulletin®