Архитектура_oracle-1 часть

1. Лекция 1

АРХИТЕКТУРА СУБД

2. Корпоративные базы данных

В большой организации применяют различные базы
данных:mySql, Sqlite, Oracle, PostgreSQL, Firebird…
• Простенькие базы данных не выдерживают
большой нагрузки.
• Следует принять во внимание возможность СУБД
«расти» вместе с развитием организации.
• Малому бизнесу могут потребоваться только
базовые
функции
и
возможности,
а
также
небольшое
количество
информации,
размещаемой в БД. Но требования могут
существенно расти с течением времени, а переход
на другую СУБД может стать проблемой.
2

3.

3

4. ОПЦИИ РЕДАКЦИИ ENTERPRISE EDITION

• Partitioning- разбиение таблиц и индексов на более
простые
компоненты
для
обеспечения
высокой
производительность и доступности базы данных.
• Real Application Clusters - построение отказоустойчивых
и
хорошо
масштабируемых
систем
на
основе
объединения нескольких серверов .
• Real Application Testing - захват рабочей нагрузки и ее
воспроизведение для тестирования изменений нагрузки.
• Data Masking - помогает администраторам БД и
администраторам
безопасности
преобразовать
конфиденциальные данные в реалистичные, но при этом
"очищенные" от важной информации, основываясь на
правилах маскирования.
4

5. ОПЦИИ РЕДАКЦИИ ENTERPRISE EDITION

• При возникновении тяжелых сбоев в работе СУБД
администратор за короткое время в состоянии
стресса должен понять причину сбоя, выбрать и
оценить способы восстановления. Как правило сам
процесс восстановления БД после сбоя
занимает 10-15% времени простоя, остальное
время уходит на сбор и анализ информации.
• Reparing Adviser позволяет решить эту
проблему - он сам соберет информацию,
проанализирует ее с учетом конкретных условий
эксплуатации (наличие бэкапов, резервной базы и
т д.) и выдаст рекомендации по восстановлению
после сбоя.
5

6. СЕРВЕРНАЯ АРХИТЕКТУРА ORACLE

• Экземпляр (Oracle Instance)
• База данных (Oracle Database)
• Файлы базы данных (Database Files)
• Серверные процессы (Server Processes)
• Структура памяти (Memory Structures)
• Транзакции (Transactions)
• Словарь данных (Data Dictionary)
• Схема и пользователи (Schema And Users)
• Логическая структура представлена иерархией:
tablespaces, segments, extents and blocks. 6

7.

7

8. ЭКЗЕМПЛЯР БД (INSTANCE )

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

9.

9

10. СТРУКТУРА ПАМЯТИ ORACLE

Структура памяти Oracle состоит из двух основных
областей:
• System Global Area (SGA): Служит для хранения
данных и управляющей информации для одного
экземпляра,
распределяется
при
запуске
экземпляра и освобождается при закрытии
экземпляра.
• Program Global Area (PGA): Выделяется при
запуске серверного процесса, зарезервирована
для
процессов,
подключающихся
к
БД,
используется одним пользовательским процессом
Oracle.
10

11. Program Global Area (PGA)

• В PGA находятся память сеансов и приватная область
SQL, характеристики обработки курсоров, области
сортировки.
• Объемом памяти можно управлять с помощью
параметра
инициализации PGA_AGGREGATE_TARGET.
• Начиная с Oracle Database 11g выделение памяти для
PGA настраивается автоматически, как и для SGA,
путем задания параметра MEMORY_TARGET.
11

12. ВИДЫ ПРОЦЕССОВ В ORACLE

12

13. SGA

• Буферный кэш базы данных – нужен для
ускорения
процесса
ввода-вывода,
содержит
последние по времени использования блоки данных
из БД. Блоки могут содержать модифицированные
данные, которые еще не были записаны на диск
(грязные) и блоки, не подвергшиеся модификации,
или блоки, которые были записаны на диск после
модификации (чистые блоки)
• Буфер журнала повтора (восстановления),
журнальный буфер (Redo log buffer) - содержит
записи
журнала
восстановления,
которые
используются для восстановления данных в случае
сбоя.
• Разделяемый пул (Shared pool).
13

14. SGA

• Разделяемый пул (Shared pool) - содержит
библиотечный кэш (содержит результат
синтаксического
анализа,
текст
подвергшихся грамматическому разбору
SQL – операторов, планы выполнения SQL
– операторов для повторного применения) и
кэш словаря данных(кэш строк).
• В
кэше
строк
хранится
последняя
информация словаря данных
Oracle, к
которой проводилось обращение.
14

15. ФОНОВЫЕ ПРОЦЕССЫ

• Database Writer (DBWR) запись модифицированных
(грязных) блоков из буферного кэша области SGA в файлы
данных (datafiles) на диске.
• System Monitor (SMON) - восстановление системы после
аварии или при сбое экземпляра вследствие отключения
питания, отказа ЦП. Восстановление транзакций, которые не
были выполнены до конца из-за аварийного отказа системы,
дефрагментация БД.
• Process Monitor (PMON) - отслеживание пользовательских
процессов, которые обращаются к БД, их восстановление
после аварийной ситуации (разорвался сеанс SQL*Plus).
Очистка ресурсов, которые использовались до аварийной
ситуации, и освобождение от всех блокировок, установленных
процессом до аварии.
• Archiver (ARCH) - копирование оперативных файлов журнала
восстановления на архивное запоминающее устройство
после их заполнения.
• Recoverer (RECO) -освобождение ресурсов, которые
захвачены аварийно завершившимися или зависшими
15
распределенными транзакциями.

16. ФОНОВЫЕ ПРОЦЕССЫ

• Log Writer (LGWR) - запись данных из буфера
журнала в журнал восстановления.
• Checkpoint (СКРТ) - выдача процессу DBWR
сообщения,
что
необходимо
выполнить
операции, связанные с созданием контрольной
точки, т.е. модифицировать все файлы данных и
все управляющие файлы БД.
Часто в alert.log базы возникают сообщения
«Checkpoint not complete». В этом случае:
«увеличьте количество и/или размер redo-логов»
16

17. ФОНОВЫЕ ПРОЦЕССЫ

• Контрольная точка — это событие, во время
которого
«грязные»
(изменённые)
блоки
записываются в файлы данных, событие контрольной
точки происходит при переключении online redo лога.
• Событие
контрольной
точки
обеспечивает
согласованность данных и быстрое восстановление
базы.
• Восстановление
данных
ускоряется,
т.к.
все
изменения до контрольной точки пишутся в файлы
данных.
• Это избавляет от необходимости во время
восстановления
применять
redo-логи,
сгенерированные ДО контрольной точки.
• Контрольная точка гарантирует, что все изменённые
блоки
в
кэше
действительно
записаны
в
соответствующие файлы данных.
17

18. ФОНОВЫЕ ПРОЦЕССЫ

18

19. ФОНОВЫЕ ПРОЦЕССЫ

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

20. ФОНОВЫЕ ПРОЦЕССЫ

20

21.  Real Application Clusters (RAC) позволяет строить отказоустойчивые и хорошо масштабируемые серверы баз данных на основе

ФОНОВЫЕ ПРОЦЕССЫ
Real Application Clusters (RAC) позволяет строить отказоустойчивые и хорошо
масштабируемые серверы баз данных на основе объединения нескольких
вычислительных систем.
21

22. ФОНОВЫЕ ПРОЦЕССЫ

22

23. Как Oracle обрабатывает транзакцию

1) Пользователь запрашивает соединение с сервером Oracle, используя
Oracle Net Services.
2) После проверки запроса сервер запускает новый выделенный
серверный
процесс
для
этого
пользователя.
3) Пользователь выполняет оператор для изменения новой строки в
таблице.
4) Oracle проверят привилегии пользователя. Если информация о
привилегиях пользователя отсутствует в библиотечном кэше, она будет
прочитана с диска в этот кэш.
5) Если пользователь имеет необходимые привилегии, Oracle проверяет,
не выполнялся ли подобный данному оператор SQL недавно, и не
находится
ли
он
в
разделяе
мом пуле. Если да, Oracle выполняет эту версию оператор SQL, а в
противном случае разбирает и выполняет новый пользовательский
оператор SQL. Затем Oracle создает частную область SQL в PGA
пользовательского сеанса.
6) Oracle проверяет, нет ли нужных данных в буферном кэше данных.
Если нет, серверный процесс читает необходимую таблицу из файлов
23
данных на диске.

24. Как Oracle обрабатывает транзакцию

7) Oracle применяет блокировки уровня строки, где это необходимо,
предотвращая попытки других процессов изменить те же данные
параллельно.
8) Сервер пишет изменения в буфер журнала повторного выполнения.
9) Сервер модифицирует табличные данные в буферном кэше
данных.
10) Пользователь фиксирует транзакцию. Oracle снимает блокировки.
11) Процесс-писатель журнала записывает измененные данные из
буферов журналов повторного выполнения в онлайновый файл
журнала.
12) Серверный процесс посылает сообщение клиентскому процессу,
сигнализируя об успешном завершении операции «COMMIT
COMPLETE».
13) Изменения, проведенные в таблице посредством, могут быть не
сразу записаны на диск. Процесс-писатель базы данных производит
запись пакетами, так что может пройти некоторое время, прежде чем
вставленная информация действительно попадет в файл данных на
24
диске.

25. ЛОГИЧЕСКАЯ И ФИЗИЧЕСКАЯ СТРУКТУРА ORACLE

26. РАСПОЛОЖЕНИЕ ПО И ФАЙЛОВ ORACLE

26

27.

27

28.

OMF Oracle Managed Files
Используя OMF, не нужно задавать местоположение файлов данных. Oracle
автоматически создаст файл или добавит файл данных в место,
специфицированное в init.ora.
V$PARAMETER,
SHOW PARAMETER [ ]
28

29. ФИЗИЧЕСКИЙ УРОВЕНЬ

• файлы
данных
хранят
информацию,
имеющуюся в БД. Количество файлов данных
ограничено параметром MAXDATAFILES.
• файлы журналирования операций (redo log
files) - содержат информацию, необходимую для
процесса восстановления в случае сбоя системы
для восстановления изменений, произведенных,
но не зафиксированых перед сбоем системы.
• управляющие файлы - содержат информацию,
необходимую для запуска экземпляра Oracle
(расположение файлов данных и файлов
журналирования операций и др.)
• файл паролей,
файл параметров, файлы
конфигурирования и др.
29

30. ПОДДЕРЖКА НЕСКОЛЬКИХ РАЗМЕРОВ БЛОКА ДАННЫХ

• С Oracle 9i появилась возможность
поддержки табличных пространств с
разным размером блока данных.
• Манипуляция с небольшим числом
больших
блоков
данных
имеет
преимущества
над
манипуляциями
большим числом блоков меньшего
размера.
• Для OLTP - рекомендуется небольшой
размер блока, а для Data Warehouse –
наоборот.

31. ПОДДЕРЖКА НЕСКОЛЬКИХ РАЗМЕРОВ БЛОКА ДАННЫХ

• Рекомендуется устанавливать
DB_BLOCK_SIZE = Размер блока операционной
системы (ОС).
• Наиболее
распространенное
значение
DB_BLOCK_SIZE 8 Кбайт.
• В БД могут присутствовать от 1 до 4 табличных
пространств с нестандартным размером блока
(отличным от того, который определен при
создании БД). Размеры блоков в могут быть
2,4, 8,16, 32 Кб.
• Блоки в табличных пространствах SYSTEM,
SYSAUX
и
временных
табличных
пространствах
должны
иметь
размер
DB_BLOCK_SIZE.

32.

http://oracledba.ru/docs/architecture/tablespaces/c
reate-new-tablespace/

33. ОПЕРАЦИИ НАД ТАБЛИЧНЫМИ ПРОСТРАНСТВАМИ

• Изменение размера файла
ALTER
DATABASE
DATAFILE
'\disc01\myfile2.dbs' resize 10M;
• Привязывание дополнительных файлов
БД
ALTER TABLESPACE user1 ADD DATAFILE
'\disc01\myfile2.dbs' size 10M;
• Перенос таблицы из одного табличного
пространства в другое командой:
ALTER TABLE <имя таблицы> MOVE
TABLESPACE <имя другого табличного
пространства>

34. СОЗДАНИЕ ТАБЛИЧНОГО ПРОСТРАНСТВА С НЕСТАНДАРТНЫМ РАЗМЕРОМ БЛОКА

1) установить параметры инициализации db_cache_size (не
db_block_buffers, они совместно не применяются)
и db_nk_cache_size, где nk – размер желаемого блока.
2) CREATE TABLESPACE с указанием опции BLOCKSIZE

35. BIGFILE TABLESPACES

По умолчанию, все табличные пространства создаются c
smallfile:
Но эту настройку можно изменить командой:
ALTER DATABASE SET DEFAULT BIGFILE TABLESPACE

36. BIGFILE TABLESPACES

• Табличные пространства bigfile состоят
только из 1 файла данных, который может
расти до 8 экзабайт (8 млн. Тб) в зависимости
от размера блока.
• CREATE
BIGFILE
TABLESPACE
<имя_табл_простр> DATAFILE <путь> SIZE
10M AUTOEXTEND ON NEXT 10M.
• В представление dba_tablespaces добавлено
поле BIGFILE (указывает, является ли
табличное пространство - bigfile tablespace).

37. BIGFILE TABLESPACES

Многие ОС не поддерживают настолько большие
файлы,
чтобы
использовать
табличные
пространства типа bigfile :
SQL> alter tablespace big_users add datafile
'D:\ORACLE\PRODUCT\ORADATA\TESTDB\B
IG_USERS02.DBF'
size
20M;
ORA-32771: cannot add file to bigfile tablespace

38. Табличные пространства

39. ТАБЛИЧНЫЕ ПРОСТРАНСТВА

В
Oracle 11g при создании базы через
Database Configuration Assistant создаются
такие табличные пространства:
• SYSTEM,
• SYSAUX,
• UNDO,
• USERS,
• TEMP.

40.

41.

42. Временное табличное пространство

• Каждому
пользователю
назначается
временное
табличное пространство или группа (тип TEMPORARY),
в котором БД хранит временные сегменты.
• В БД может быть несколько временных табличных
пространств, находящихся в оперативном режиме
одновременно.
• Временные сегменты создаются во время операций:
ORDER BY, GROUP BY, SELECT DISTINCT, MERGE
JOIN или CREATE INDEX, используются при
использовании временных таблиц (create global
temporary table ).

43. MERGE

• Позволяет дополнять и обновлять данные одной таблицы данными другой таблицы.
• При слиянии таблиц проверяется условие, и если оно
истинно, то выполняется Update, а если нет - Insert. Причем
нельзя изменять поля таблицы в секции Update, по
которым идет связывание двух таблиц.
• Является командой DML.
• Синтаксис
MERGE INTO TABLE_NAME USING table_reference ON
(condition) WHEN MATCHED THEN UPDATE SET column1 =
value1 [, column2 = value2 ...] WHEN NOT MATCHED THEN
INSERT (column1 [, column2 ...]) VALUES (value1 [, value2 ...)
43

44.

45.

46. ФАЙЛЫ ДАННЫХ БД

• Файлы данных с расширением .dbf хранят
"табличные пространства“ по адресу
%ORACLE_BASE% \ORADATA\%ORACLE_SID%
• SELECT
TABLESPACE_NAME,
FILE_NAME,
BYTES
FROM
DBA_DATA_FILES
• свободное место в табличном пространстве через
представление словаря данных DBA_FREE_SPACE

47.

47

48. УПРАВЛЯЮЩИЕ ФАЙЛЫ

• Без управляющих файлов сервер базы данных
Oracle не может находить свои физические
компоненты;
• Управляющие
файлы
мультиплексированы;
должны
быть
• Расположение задает параметр CONTROL_FILES в
файле параметров initsid.ora.
• V$SPPARAMETER, V$PARAMETER ,
V$CONTROLFILE;

49. СОДЕРЖИМОЕ УПРАВЛЯЮЩЕГО ФАЙЛА

50. ФАЙЛЫ ЖУРНАЛОВ БД

• Журналы повтора - это дисковые ресурсы, в
которых фиксируются изменения, вносимые в
БД транзакциями и внутренними процессами
сервера.
• В
журнал
заносится
информация
о
зафиксированных транзакциях.
• Журналы
применяются
в
ситуациях
аварийного завершения экземпляра для
восстановления зафиксированных данных,
которые не были записаны в файлы данных.

51. ФАЙЛЫ ЖУРНАЛОВ БД

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

52. ФАЙЛЫ ЖУРНАЛОВ БД

53. ФАЙЛЫ ЖУРНАЛОВ БД

• Журнальные файлы объединены в группы.
Журнальные файлы используются в круговом
режиме. Должно быть, по крайней мере, 2
журнальные группы.
• Отдельный журнал внутри группы называется
элементом.
• Текущий
порядковый
номер
(Сurrent)
журнального файла хранится в управляющем
файле и в заголовке каждого файла данных.
• Если журнальный файл заполнился и еще
требуется для восстановления экземпляра, он
помечается Active, и если нет,– Inactive.

54.

Статус журнала
Из V$LOG можно получить следующую информацию.
UNUSED. В этот журнал никогда оракл не записывал.
CURRENT. Этот журнал активный, необходим для восстановления. В
данный момент Oracle в него пишет. Этот журнал может быть открыт
или закрыт.
ACTIVE. Этот журнал активный, а значит, необходим для
восстановления. Но в этот журнал Oracle в данный момент не пишет.
Возможно, в данный момент используется для восстановления блоков.
Может быть как заархивированным, так и незаархивированным.
CLEARING. Этот журнал создается повторно и очищается командой
ALTER DATABASE CLEAR LOGFILE. Затем он перейдет в статус
UNUSED.
CLEARING_CURRENT. Текущий журнал очищается закрытым потоком.
Журнал может быть в этом статусе, если при переключении
произойдет сбой (например, ошибка ввода-вывода при записи нового
заголовка журнала).
INACTIVE. Журнал уже не нужен для восстановления экземпляра, но
возможно будет использован при восстановлении носителя. Может
быть как заархивированным, так и незаархивированным.

55. ФАЙЛЫ ЖУРНАЛОВ БД

При определении размера и количества оперативных журналов
повторного выполнения необходимо учитывать:
• Частота контрольной точки - один из факторов, влияющих на
время, требуемое БД на восстановление после сбоя.
• КОНТРОЛЬНАЯ ТОЧКА - регулярное событие в БД, дающее
процессу записи в БД сигнал скачать измененные буферы в
файлы данных и обновить управляющие файлы и заголовки
файла с помощью информации контрольной точки.
• Контрольные точки возникают, как минимум, при переключении
журналов базы данных. Если интервал контрольной точки
>размера файла журнала БД, то контрольные точки возникают
только при переключении журналов БД.
• Они могут также возникать, если с помощью параметров файла
init.ora устанавливаются более частые интервалы.
55

56. НАСТРОЙКА ЧАСТОТЫ КОНТРОЛЬНЫХ ТОЧЕК

• параметры инициализации в файле initSID.ora
LOG_CHECKPOINT_INTERVAL (в блоках ОС) или
LOG_CHECKPOINT_TIMEOUT (в секундах) - параметр задает в
секундах время ожидания инкрементальной контрольной точки.
Иначе говоря, ни один блок не может быть грязным более чем
указанное этим параметром время.
• принудительно:
ALTER SYSTEM SWITCH LOGFILE (переключение журнальных
файлов). По этой команде происходит переключение текущего
журнала, активный журнал также становится неактивным.
ALTER SYSTEM
CHECKPOINT
(контрольная точка)- Если
журнальный файл имел статус активный ACTIVE , то после
выполнения этой команды его статус меняется на неактивный
NOACTIVE.
• Время появления контрольных точек можно регистрировать в файле
alert: log_checkpoints_to_alert=true в init.

57. НАСТРОЙКА ЧАСТОТЫ КОНТРОЛЬНЫХ ТОЧЕК

• параметр инициализации ARCHIVE_LAG_TARGET.
задает время в секундах между переключениями
журнальных групп, т.е., чтобы переключение
журналов происходило не по событию, а через
некоторый период времени при условии, что
текущий журнальный файл не пустой.
Это нужно:
• Для уменьшения рассинхронизации резервной и
основной базы (standby).
• Для точного указания периода времени, за которое
может быть потеряна информация.
• Для принудительного архивирования.

58. ФАЙЛЫ ЖУРНАЛОВ БД

1. Когда заполненные журналы повторного выполнения
посылаются на другую машину и там применяются к копии
текущей БД (при резервировании, standby), необходимо
много небольших файлов журнала. Это поможет
уменьшить рассинхронизацию резервной БД с основной.
2. Если много пользователей, изменяющих одни и те же
блоки, то могут понадобиться большие файлы журнала
повторного выполнения. Т.к. все изменяют одни и те же
блоки, желательно чтобы до того как блоки будут
сброшены на диск, было выполнено как можно больше
изменений. Каждое переключение журнала инициирует
обработку контрольной точки, так что желательно
переключать журналы как можно реже. Но это может
замедлить восстановление.
58

59. ФАЙЛЫ ЖУРНАЛОВ БД

3. Если необходимо обеспечить максимально
быстрое восстановление, придется использовать
файлы журнала меньшего размера. Система в
целом будет работать медленнее, чем могла бы (из-за
слишком частой обработки контрольных точек), но
восстановление будет выполняться быстрее. Для
сокращения времени восстановления можно изменять
и другие параметры БД.
59

60. ИЗМЕНЕНИЕ ПАРАМЕТРОВ ЖУРНАЛЬНЫХ ФАЙЛОВ

• Удалять элемент можно только из неактивной
заархивированной группы.
• В группе должен оставаться, по крайней
мере, один действительный элемент.
• Статус элемента группы можно узнать из
представления v$logfile, v$log.
• Элементов в одной группе может быть меньше,
чем в прочих группах. Но это нежелательно.
• После
удаления
элемента
группы
соответствующий файл из операционной
системы не удаляется.

61.

ФАЙЛЫ ЖУРНАЛОВ БДрекомендации
• В Oracle рекомендуют использовать четыре группы
журналов
повторного
выполнения,
чтобы
программе записи журналов не приходилось
дожидаться освобождения доступной группы при
каждом переключении с одного журнала на другой.
• 4 групп журналов повторного выполнения (файлы
журналов повторного выполнения) должны иметь
одинаковый размер.
• Oracle предлагает устанавливать размеры файлов
журналов повторного выполнения такими, чтобы при
большой
нагрузке
переключение
происходило
каждые 20 минут, а при нормальных нагрузках —
61
один раз в час.

62. ПОЛУЧЕНИЕ ИНФОРМАЦИИ ОБ АРХИВНЫХ ЖУРНАЛАХ , flashback

• V$LOGFILE, V$LOG, v$database
(log_mode, flashback_on)
Проверка состояния архивирования:
ALTER DATABASE ARCHIVELOG;

63. ИЗМЕНЕНИЕ ПАРАМЕТРОВ ЖУРНАЛЬНЫХ ФАЙЛОВ

Добавление члена в группу файлов журнала :
ALTER DATABASE ADD LOGFILE MEMBER
'\u05\oracle\d2\log_3.dbf' TO GROUP 3;
Увеличение числа групп:
ALTER DATABASE ADD LOGFILE GROUP 5
( '\u05\oracle\d2\log_5a.dbf' ,
'\u05\oracle\d2\log_5b.dbf' ) size 10 M ; (по 10M
каждый)
Удаление журнальных файлов:
ALTER DATABASE DROP LOGFILE GROUP
<номер группы>
Удаление члена группы:
ALTER DATABASE DROP LOGFILE MEMBER
‘C:\ORACLE\ORADATA\MY_DB\REDO2.LOG’

64. ИЗМЕНЕНИЕ ПАРАМЕТРОВ ЖУРНАЛЬНЫХ ФАЙЛОВ

• Удалять можно только из неактивной
заархивированной группы
• В группе должен оставаться, по крайней
мере, один действительный элемент
• Статус элемента группы можно узнать из
представления v$logfile, v$log
• Элементов в одной группе может быть
меньше, чем в прочих группах. Но это
нежелательно.
• После
удаления
элемента
группы
соответствующий файл из операционной
системы не удаляется.

65.

СПАСИБО ЗА ВНИМАНИЕ!
65