Администрирование оракл. Восстановление базы данных

Данный курс является первым шагом на пути к профессиональной работе с СУБД Oracle Database. Он дает базовые знания и навыки администрирования базы данных.

Курс знакомит с архитектурой Oracle Database 11g, работой и взаимодействием компонентов СУБД.

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

Успешное окончание обучения по программе курса позволит специалистам:

• Устанавливать инфраструктуру Oracle Database 11g.
• Устанавливать и конфигурировать базу данных.
• Конфигурировать сетевое окружение (Oracle Net).
• Отслеживать и управлять данными отмены (Undo).
• Управлять структурами хранения БД.
• Создавать и администрировать учетные записи пользователей.
• Выполнять базовые операции резервного копирования и восстановления БД.
• Управлять конкурентным доступом к данным.
• Следить за производительностью СУБД.
• Понимать архитектуру Oracle Database.

Цель курса

Формирование основ языка SQL для СУБД Oracle Database (версий 10g и 11g)

Целевая аудитория

• Администраторы СУБД Oracle Database.
• Разработчики Java-приложений.
• Инженеры технической поддержки.
• Технические консультанты

Необходимая подготовка

• Знания и опыт работы с SQL (рекомендуемый курс: Oracle Database: Основы языка SQL ).
• Желательны знания и опыт работы с PL/SQL (рекомендуемый курс:Oracle Database: Введение в язык PL/SQL ).
• Базовые знания технического английского языка

Архитектура базы данных

• Обзор архитектуры Oracle Database.
• Обзор архитектуры ASM.
• Архитектура процессов.
• Структуры памяти.
• Логическая и физическая структуры системы хранения.
• Компоненты системы хранения ASM.
• Практическое занятие: Исследование компонентов архитектуры базы данных.

2. Установка ПО Oracle

• Задачи администратора базы данных.
• Используемые инструменты администрирования СУБД.
• Инсталляция: системные требования.
• Oracle Universal Installer (OUI).
• Установка инфраструктуры Oracle Grid.
• Установка ПО Oracle Database.
• Практическое занятие: Установка и конфигурация ПО Oracle.

3. Создание базы данных

• Планирование базы данных.
• Использование DBCA для создания базы данных.
• Управление паролями.
• Создание шаблонов базы данных.
• Использование DBCA для удаления базы данных.
• Практическое занятие: Создание базы данных Oracle Database.

4. Конфигурация СУБД

• Запуск и остановка СУБД и ее компонентов.
• Использование Oracle Enterprise Manager.
• Доступ к базе данных с использованием SQL*Plus.
• Изменение инициализационных параметров СУБД.
• Описание стадий запуска СУБД.
• Описание вариантов остановки СУБД.
• Просмотр файла сигнальных сообщений (alert.log).
• Доступ к динамическим представлениям производительности.
• Практическое занятие: Управление экземпляра базы данных.

5. Конфигурация ASM

• Установка инициализационных параметров ASM.
• Запуск и остановка ASM.
• Администрирование дисковых групп ASM.
• Практическое занятие: Исследование компонентов ASM.

6. Конфигурация сетевого окружения

• Использование Oracle Enterprise Manager для создания и конфигурирования прослушивателя (listener).
• Использование Oracle Restart для наблюдения за работой прослушивателя.
• Использование утилиты tnsping для проверки настроек соединения Oracle Net.
• Варианты используется СУБД в режиме Shared Server и Deducated Server.
• Практическое занятие: Конфигурация сетевого окружения для удаленного доступа к БД.

7. Сопровождение структур хранения

• Структуры хранения.
• Как хранятся данные таблиц.
• Внутренняя структура блока базы данных.
• Управление пространством в разделах.
• Предустановленные разделы в базе данных.
• Сопровождение разделов.
• Файлы, сопровождаемые Oracle (OMF).
• Практическое занятие: Исследование структуры хранения БД.

8. Управление правами доступа пользователей

• Учетные записи пользователей.
• Предустановленные пользователи для администрирования СУБД.
• Преимущества использования ролей.
• Предустановленные роли.
• Применение профилей пользователей.
• Практическое занятие: Создание и использование профилей пользователей.

9. Управление конкурентным доступом к данным

• Конкуренция за данные.
• Механизм очередей.
• Разрешение конфликтов блокировок.
• Взаимные блокировки.
• Практическое занятие: Разрешение конфликтов блокировок.

10. Сопровождение данных отмены (Undo)

• Манипуляция данными.
• Транзакции и данные отмены.
• Различие данных отмены (Undo data) и журнальных записей (Redo data).
• Конфигурация политики удержания данных отмены.
• Практическое занятие: Управление данными отмены.

11. Использование аудита в Oracle Database

• Ответственности АБД за обеспечение информационной безопасности.
• Применение стандартных возможностей аудита БД.
• Определение параметров аудита.
• Просмотр собранной информации аудита.
• Сопровождение данных аудита.
• Практическое занятие: Конфигурирование аудита БД.

12. Сопровождение базы данных

• Управление статистикой оптимизатора.
• Управление Automatic Workload Repository (AWR).
• Использование Automatic Database Diagnostic Monitor (ADDM).
• Описание и использование советников (Advisors).
• Установка граничных значений сигнальных сообщений.
• Использование системных сигнальных сообщений.
• Использование автоматических задач.
• Практическое занятие: Сопровождение базы данных.

13. Управление производительностью БД

• Мониторинг производительности.
• Управление компонентами памяти.
• Включение режима автоматического управления памятью (AMM).
• Советник по автоматическому управлению компонентов SGA.
• Использование советников по памяти.
• Динамическая статистика производительности.
• Представления для поиска и устранения проблем производительности.
• Недействительные и неиспользуемые объекты.
• Практическое занятие: Управление производительностью БД.

14. Концепции резервного копирования и восстановления

• Часть ответственности администратора БД.
• Ошибки приложений.
• Ошибки пользователей.
• Понимание процесса восстановления экземпляра.
• Фазы восстановления экземпляра.
• Использование советника MTTR.
• Ошибки носителя.
• Архивные журнальные файлы.
• Практическое занятие: Конфигурирование БД для восстановления.

15. Резервное копирование базы данных

• Решения для резервного копирования.

• Oracle Secure Backup.
• Ручное резервное копирование.
• Терминология.
• Recovery Manager (RMAN).
• Конфигурирование параметров резервного копирования.
• Резервное копирование управляющего файла.
• Сопровождение Fast Recovery Area.
• Практическое занятие: Выполнение резервного копирования БД.

16. Восстановление базы данных

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

17. Перемещение данных

• Способы перемещения данных.
• Создание и использование объектов «директория».
• Обзор возможностей SQL*Loader для перемещения данных.
• Использование внешних таблиц для перемещения данных.
• Общая архитектура Data Pump.
• Использование Data Pump для экспорта и импорта данных.
• Практическое занятие: Перемещение данных с помощью SQL*Loader и Data Pump.

18. Взаимодействие со службой поддержки Oracle

• Использование EM Support Workbench.
• Работа с Oracle Support.
• Создание запросов на сопровождение (SR).
• Сопровождение патчей.
• Практическое занятие: Выявление критических ошибок

Сертификация

Курс подготовит к экзамену: 1Z0-052 Oracle Database 11g: Administration I , необходимому для сертификации Oracle Database 11g Administrator Certified Associate

Получаемый документ

Удостоверение о повышении квалификации, или Сертификат .

Государственный комитет Российской федерации

По высшему образованию.

ГОСУДАРСТВЕННЫЙ САНКТ-ПЕТЕРБУРГСКИЙ

ИНСТИТУТ ТОЧНОЙ МЕХАНИКИ И ОПТИКИ

(ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ)

кафедра вычислительной техники

Администрирование баз данных

ORACLE
Санкт-Петербург

2000 год

1. Обязанности администратора базы данных (АБД) 3

2. Подключение в режиме INTERNAL 3

3. Утилиты АБД (Import, Export, Loader) 4

4. Пользователи базы данных и схемы 6

5. Табличные пространства и файлы данных 8

6.Схемы и объекты схемы 9

7. Блоки данных, экстенты и сегменты. 11

8.Структуры памяти и процессы 12

9. Пример работы Oracle. 13

10. Журнал Повторений 14

11. Транзакция (Transaction) 15

12. Обеспечение защиты базы данных 18

13. Представления словаря данных. 19

14. Привилегии (Grant, role). 20

15. Управление пользователями

16. Аудит базы данных 22

17. Обеспечение целостности базы данных 24

18. Создание базы данных. (файлы параметров) 25

19. Запуск и останов базы данных 26

20. Различные режимы работы базы данных 29

21. Резервное копирование базы данных 29

22. Динамический SQL 30

23. Объектно-ориентированные Базы Данных. 32

1. Обязанности администратора базы данных (АБД)

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

В обязанности администратора могут входить:

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

Сотрудники службы безопасности

В некоторых случаях база данных должна также иметь одного или нескольких сотрудников службы безопасности. СОТРУДНИК СЛУЖБЫ БЕЗОПАСНОСТИ главным образом отвечает за регистрацию новых пользователей, управление и отслеживание доступа пользователей к базе данных, и защиту базы данных.

Разработчики приложений

В обязанности разработчика приложений входит:
 проектирование и разработка приложений базы данных

 проектирование структуры базы данных в соответствии с требованиями приложений

 оценка требований памяти для приложения

 формулирование модификаций структуры базы данных для приложения

 передача вышеупомянутой информации администратору базы данных

 настройка приложения в процессе его разработки

 установка мер по защите приложения в процессе его разработки

2. Подключение в режиме INTERNAL

Запуск и останов базы данных - это мощные административные возможности. В угоду поддержания корректной работоспособности базы данных, функции(команды STARTUP или SHUTDOWN ) остановки и запуска разрешены, только для администратора подключенного к ORACLE в режиме NTERNAL(^ CONNECT INTERNAL ), а для возможности подключиться в режиме NTERNAL, вы должны соотвествовать одному из ниже следующих условий:

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

Все эти требования образуют дополнительный слой защиты, препятствующий несанкционированному запуску или остановке баз данных ORACLE. Для систем, имеющих пароль для INTERNAL, существуют дополнительные, ниже описываемые соображения.

Использование пароля для INTERNAL

Некоторые операционные системы позволяют устанавливать пароль для соединений в режиме INTERNAL. Можно установить пароль для INTERNAL во время инсталляции сервера ORACLE, Oracle предоставляет утилиту для управления этим паролем (создания, изменения и удаления его).

INTERNAL и незащищенные соединения

Если используется незащищенное соединение(как большинство сетевых соединений), то ДОЛЖНО использовать пароль для INTERNAL, для последующего подключения в режиме INTERNAL; это требование подразумевает, что в системе должен быть установлен пароль для INTERNAL.
В некоторых О.С. можно либо включить, либо полностью отключить возможность соединений CONNECT INTERNAL для незащищенных соединений. Выбор делается во время инсталляции ORACLE, и может быть изменен позднее.

3. Утилиты АБД (Import, Export, Loader)

SQL*Loader

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

Основные компоненты SQL*Loader

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

Входные данные

Утилита SQL*Loader может обрабатывать файлы данных практически любого типа и поддерживает собственные типы данных почти любой платформы. Данные обычно считываются из одного или нескольких файлов данных, однако они могут быть также внесены в управляющий файл после управляющей информации. Файл данных может находиться:

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

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

Oracle предоставляет набор различных инструментов для управление окружением сервера. Первый из них – Oracle Universal Installer (OUI) – которые используется (как следует из названия) для установки программных продуктов Oracle. Далее следует Database Configuration Assistang (DBCA) – это инструмент для создания БД. Существует также инструмент для обновления БД Database Upgrade Assistance (DBUA) – но его мы не будет рассматривать. С помощью OUI можно установить различные инструменты для управления БД, в основном используется SQL *Plus и Oracle Enterprise Manager (OEM). Так же часто используется SQL Developer.

Исторически, управление продуктами Oracle было не особо приятной задачей. Так сложилось, потому что DBA приходилось устанавливать различные продукты отдельно, в связи с проблемой несовместимости. Это не было необычным явлением, когда после успешной установки первого, второго и третьего продукта – установка четвертого продукта приводила к нерабчоему состоянию все три до этого установленные программы. Проблемы несовместимости лежат в использовании основных библиотек (base libraries). Эти библиотеки предоставляют функционал который используется во всех продуктах Oracle. Например все программы Oracle используют закрытый сетевой протокол Oracle Net – невозможно установить пррограммы Oracle без него. Если две программы Oracle используют одинаковую версию основных библиотек, то только тогда теоретически они могут быть установлены в одинаковой домашней директории Oracle (Oracle Home). Oracle Home – это путь куда установлена программа Oracle: набор файлов в папке. До OUI каждая программа имела свой установщик, которые не всегда мог корректно разобраться в совместимости с уже установленными программами.

OUI создан при помощи Java версии 5, что позволяет ему работать одинаково на всех платформах. Можно установить OUI как отдельный продукт в определённую домашнюю директорию, но обычно это не имеет смысла, так как OUI поставляется со всеми программами Oracle и может быть запущен из дистрибутива: он будет установлен вместе с программой в домашнюю директорию программы. Существуют различные версии OUI, и, если программа поставляется с более старой версией OUI, чем у другой уже установленной программы, то лучше использовать уже установленную версию (более новую) OUI. Когда OUI спросит местонахождение products.xml – просто укажите уме директорию новой программы.

OUI Inventory

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

%SystemRoot%\Program Files\Oracle\Inventory

Все ОС имеют предустановленный путь по которому OUI будет искать указатель о существующем хранилище. В Linux –е это будет файл

/etc/oraInst.loc

В Solaris-е это так же файл

/vat/opt/oracle/oraInst.loc

В Windows это запись в системном реестре

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\inst_loc

Когда запускается OUI – первым делом проверяется существование файла (или записи в реестре) и, если он не существует, предполагается что это первый запуск OUI и файл создаётся с записью в него пути к хранилищу. Все последующие вызовы OUI вне зависимости от версии смогут найти хранилище.

Такой механизм создания хранилища имеет проблемы с правами доступа ОС: в Linux или Unix пользователь который в первый раз запустит OUI должен иметь права записи в директорию где лежит указатель на хранилище. Однако только root пользователь может записывать в директории /etc или /var на Linux/Unix соответсвенно. Так как с точки зрения безопасности недопустимо запускать OUI с правами root, OUI сгенерирует скрипт, который необходимо будет выполнить от имени root пользователя для создания oraInst.loc файла-указателя на путь к хранилищу. В Windows пользователь запускающий OUI должен иметь права на запись в реестр.

Проверка системы

OUI проверяет компьютер на котором выполняется запуск на соответствие определённым критериям. Эти требования платформо-зависимы и записаны в файле установщика:

/install/oraparam.ini (Unix)

\install\oraparam.ini (Windows)

Они не сильно требовательные: проверить чтобы графическая система поддерживала 256 цветов.

Также в файле oraparam.ini нахоидтся путь к файлу products.xml. В файле products.xml описаны какие продукты могут быть установлены с конкретного дистридутива. У каждой программы есть набор своих критериев, и они более требовательные. Требования программы перечислены в XML файле. Обычно это

/stage/prereq/db/refhost.xml (Unix)

\stage\prereq\db\refhost.xml (Windows)

В фале Windows обычно указаны требования к размеру файла подкачки и версии ОС. Если у вас объём оперативной памяти 512-2048 МБ, то файл подкачки долже быть в 1.5 раза больше чем объём оперативной памяти. Для Unix систем критерии ещё более требовательные: помимо размера файла подчкачки проверяется наличие ряда установленных пакетов и настроек ядра.

Выполнение этих требований достаточно трудоёмкая задача и если вы уверены что конкретный пакет корректен (к примеру у вас стоит более поздняя версия) или значение параметра верно, вы можете пропустить эту проверку несколькими способами. Во первых, удалить требование из файла refhost.xml. Во-вторых, запустить OUI в режиме без предварительной проверки системы. И в третьих – во время работы программы OUI указать в диалоговом окне – игнорировать несоответствия.

Database Creation and Upgrade Tools

The database Configuration Assistant (DBCA) – графический инструмент для создания и изменения БД. Мастер установки поможет выбрать необходимые параметры и настроить пути для файлов без особых усилий. DBCA сгенерирует скрипты создания БД согласно выбранных вами параметров, проверит их на наличие ошибок и выполнит. Так же всё можно сделать вручную. DBCA написан на языке Java и требует настроенной домашней директории и графической подсистемы. Все сказанное выше верно также и для Database Upgrade Assistant (DBUA).

Инструменты для выполнения SQL команд: SQL *Plus и SQL Developer

Существует много инструментов для работы с Oracle. Два стандартных инструментра это SQL *Plus и SQL Developer. Они предоставляются компанией Oracle и подходят для администрирования и разработки. У SQL Developer больше функционал, но он требует графической подсистемы, а SQL *Plus можно использовать в режиме командной строки.

SQL *Plus доступен для всех платформ на которых можно установить Oracle, и он устанавливается по умолчанию с серверным и клиентским программным обеспечением Oracle. В Linux исполняемый файл называется sqlplus. Местоположение этого файла зависит от установки и обычно это

/u01/app/oracle/pdoruct/db_1/bin/sqlplus

Ваш системный аккаунт должен быть настроен определённым образом, чтобы работать с SQL *Plus. Необходимо установить переменные системы

• ORACLE_HOME
• LD_LBIRARY_PATH

PATH должна включать в себя путь к папке bin в домашней директории программы. LD_LIBRARY_PATH – это путь к папке lib домашней директории программы. На рисунке 2-1 представлен пример проверки системных переменных и запуск SQL *Plus.

В системе Windows раньше было две версии SQL *Plus: программа в режиме командной стркои и программа с графическим интерфейсом (sqlplus.exe и sqplusw.exe соответственно). В версии 11g графическая версия больше недоступна, однако можно использовать программу более ранней версии (до 9i включительно, изменения в Oracle Net не позволят использовать программы версии ниже 9i для работы с БД версии старше 9i). Т.е. SQL Plus 10g может подключаться к БД 9i и наборот: SQL *Plus версии 9i можно использовать для работы с БД 11g. В Windows OUI сохраняет значения системных переменных в реестре в процессе установки, поэтому необязательно устанавливать значения переменных вручную, однако если SQL *Plus не запускается, стоит проверить реестр. На рисунке 2-2 указано окно Windows с фрагментов реестра. Путь к значениям используемым SQL *Plus

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraDb11g_home1

SQL Developer

SQL Developer – это инструмент для подключения к серверу Oracle (и не только Oracle) и выполнения команд SQL. В нём также можно разрабатывать PL/SQL объекты. В отличие от SQL *Plus – это графический инструмент с настроенными макросами для распространённых действий. SQL Developer разработан на языке Java и наличие JRE необходимо для запуска. Т.е. SQL Developer доступен для любой платформы для которой существет Java Runtime Environment. Последнюю версию можно скачать с сайта Oracle.

На рисунке 2-3 показан пример пользовательского интерфейса SQL Developer подключенного к БД и выполняющего простой SQL запрос. Он состоит из левой части используемой для навигации между объектами БД и правой части для ввода и вывода информации.

Курс дает базовые знания, требуемые для планирования, эксплуатации и настройки СУБД Oracle и баз данных на платформах класса Windows и Unix.

Знания даются для версий Oracle 8i, 9i, 10g, 11g и 12с. Курс сопровождается практическими упражнениями, позволяющими закрепить понимание главных понятий и освоить основные технические приемы администрирования БД.

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

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

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

Программа курса "Администрирование баз данных Oracle"

1. Общая информация о СУБД Oracle

• Введение в Oracle
• Версии и разновидности Oracle
• Расширения базовой поставки
• Общая архитектура Oracle
• Основные элементы архитектуры
• Разновидности рабочих конфигураций
• Задачи администрирования БД
• Ресурсы знаний

2. Установка Oracle

• Местонахождение Oracle в операционной и файловой системе
• Рекомендуемая структура каталогов для Oracle
• Общая схема установки Oracle
• Основные этапы установки
• Установка ПО Oracle
• Формирование характеристик БД и СУБД
• Заведение инфраструктуры для размещения планируемой БД
• Порождение сценария заведения БД
• Номинальное создание БД: предложение CREATE DATABASE
• Заведение словаря-справочника для БД
• Создание дополнительных элементов и структур БД
• Указание свойств местности для БД и работающих с ней программ
• Выбор кодировки БД и приложения
• Выбор языка сообщений, форматов выдачи и прочего
• Где выполняются установки свойств местности, и где наблюдаются
• Замена и правка свойств существующих языковых установок БД и создание новых
• Запуск и останов СУБД и БД
• Службы ОС в Windows
• Запуск и останов СУБД и БД вручную
• Действия по убиранию Oracle с компьютера
• Убирание БД из компьютера
• Убирание программных компонент с помощью Oracle Universal Installer
• «Чистое» убирание Oracle

3. Использование SQL*Plus в администрировании

• Вызов SQL*Plus
• Наиболее популярные установки параметров и режимов SQL*Plus
• Наиболее популярные команды SQL*Plus
• Файлы glogin.sql и login.sql
• Использование SQL*Plus для форматированной выдачи
• Совместное использование команд SPOOL, SAVE и START

4. Средства слежения за работой Oracle

• Использование базовых и виртуальных таблиц
• Статические таблицы
• Динамические таблицы
• Сценарии на SQL и PL/SQL, поставляемые Oracle
• utlbstat.sql и utlestat.sql (все версии)
• STATSPACK (версия 8.1.6 и выше)
• AWR (версия 10 и выше)

• Активное отслеживание событий (версия 10 и выше)
• Прочие полезные сценарии на SQL и PL/SQL
• Примеры запросов для слежения за использованием ресурсов БД и СУБД
• Специальные программные продукты
• Oracle Enterprise Manager
• Собственные возможности наблюдения OEM

5. Конфигурирование, настройка и поддержка

• Процессы конфигурирования и настройки
• Объекты конфигурирования
• Объекты настройки
• Конфигурирование и настройка операционной среды
• Конфигурирование и настройка Windows
• Конфигурирование и настройка Unix/Linux
• Конфигурирование составных частей БД и СУБД Oracle
• Конфигурирование контрольного файла
• Конфигурирование сегментов отката/сегментов отмены
• Конфигурирование табличных пространств
• Конфигурирование табличных пространств для временных данных
• Конфигурирование файлов табличного пространства
• Конфигурирование журнальных файлов
• Конфигурирование хранимых объектов БД
• Конфигурирование таблиц
• Конфигурирование индексов
• Некоторые специальные случаи конфигурирования хранения и использования таблиц и индексов

6. Администрирование доступа в Oracle

• Политика безопасности
• Основные средства администрирования доступа
• Пользователи и схемы
• Привилегии
• Опосредованный доступ к данным в таблицах
• Ограничение доступа к отдельным частям таблицы
• Защита сведений в БД внешними средствами
• Шифрование данных
• «Шифрование» исходных текстов программных элементов в БД
• Подключение к СУБД
• Пример внешней (EXTERNAL) аутентификации в ОС Windows
• Профили пользователей
• Ограничения расходования ресурсов СУБД
• Контроль за использованием паролей
• Включение контроля ресурсов
• Динамическое регулирование выделяемых сеансам ресурсов СУБД и БД
• Рекомендации Oracle для администраторов

7. Аудит

• Виды действий для отслеживания системным аудитом Oracle
• Общее разрешение на сбор СУБД информации о действиях пользователей
• Примеры конкретной выдачи заданий на аудит
• Таблицы с протоколом аудита
• Пример рекомендаций по осуществлению политики аудита
• Примеры оформления рутинных действий с таблицей аудита
• Создание таблицы для сбора обобщенной ежедневной статистики
• Сбор обобщенной ежедневной статистики
• Чистка журнала аудита
• Выборочный аудит доступа к таблицам
• Аудит с помощью триггерных процедур
• Отслеживание изменений отдельных строк таблиц
• Отслеживание изменений строк с точностью до столбцов
• Отслеживание прочих действий
• Отслеживание истории изменений в БД по журналу

8. Администрирование работы в сети

• Общая архитектура сетевой поддержки в Oracle
• Дополнительные возможности и средства SQL*Net/Net8/Oracle Net
• Конфигурирование Oracle Net для среды клиент/сервер
• Конфигурируемые компоненты SQL*Net/Net8/Oracle Net
• Способы адресации нужной БД
• Конфигурирование с помощью Net Manager
• Конфигурирование вручную
• Наладка и контроль соединения по Oracle Net
• Использование программы lsnrctl
• Проверка соединения по Oracle Net
• Настройка соединений по Oracle Net

9. Экземпляр СУБД Oracle

• Составные части экземпляра СУБД
• Процессы СУБД
• Стандартные фоновые процессы
• Дополнительные фоновые процессы
• Серверные процессы
• Просмотр имеющихся в составе СУБД процессов
• Структуры данных в составе экземпляра СУБД
• Область SGA
• Область PGA
• Область UGA
• Схемы выполнения некоторых внутренних процедур
• Выполнение контрольной точки
• Журнализация изменений в БД
• Состояния базы данных в Oracle

10. Настройка экземпляра СУБД Oracle

• Ручная настройка (для всех версий)
• Методики настройки
• Настройка SGA
• Настройка областей PGA
• Настройка в версии 9
• Настройка SGA
• Настройка областей PGA
• Настройка в версиях 10+
• Настройка SGA
• Настройка PGA
• Экспертные советы СУБД по выбору новых значений
• Автоматический сбор статистики и авторегулирование
• Аппарат «советников»
• Настройка в версии 11
• Настройка SGA и PGA
• Настройка выполнения контрольных точек
• Настройка журнализации
• Настройка СУБД и БД
• Решения на уровне приложения

11. Организация хранения данных в Oracle

• Хранение объектов БД на диске
• Внутренняя организация хранения данных в табличных пространствах
• Управление памятью в табличных пространствах для нужд сегментов
• Управление памятью в сегментах для нужд размещаемых данных
• Управление памятью в блоках с данными

12. Настройки операций ввода/вывода

• Ручная настройка для всех версий
• Выбор варианта RAID
• Автонастройка и управление в версиях 10+

13. Резервное копирование и восстановление

• Виды резервного копирования
• Физическое резервирование
• Логическое резервирование
• Резервирование изменений (частичное)
• Холодное/горячее резервирование
• Режим ARCHIVELOG работы БД
• Основные сценарии физического резервирования
• Холодное резервирование
• Пример автоматизации
• Включение режима архивирования
• Горячее резервирование
• Резервирование журнальных файлов
• Основные сценарии восстановления на физическом уровне
• Восстановление по полной холодной копии
• Общая схема восстановления с использованием архивных копий журналов
• Восстановление всей БД
• Восстановление данных табличного пространства
• Пробное восстановление
• Режим автовосстановления
• Физическое копирование и восстановление с помощью RMAN
• Пример копирования и восстановления базы данных
• Другие примеры

14. Дополнительные базовые программные средства для администрирования

• exp и imp
• Общие принципы работы программ exp и imp
• Некоторые типовые сценарии
• Некоторые параметры настройки
• Полный экспорт и экспорт изменений
• Таблицы словаря-справочника для записи информации об экспорте
• Дополнительные достоинства экспорта/импорта
• expdp и impdp
• SQL*Loader
• Загрузка данных в фиксированном формате

В конце обучения на курсе проводится итоговая аттестация в виде теста или на основании оценок за практические работы, выполненных в процессе обучения.

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

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

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

Обучение позволит Вам не только получить знания и навыки, но и подтвердить их, сдав соответствующие экзамены на статус сертифицированного специалиста. Опытные специалисты по СУБД Microsoft SQL Server или Oracle могут быть заинтересованы в изучении систем бизнес-аналитики. Это задачи достаточно сложные, использующие громоздкий математический аппарат, но они позволяют не только анализировать происходящие процессы, но и делать прогнозы на будущее, что востребовано крупными компаниями. Именно поэтому специалисты по бизнес-аналитике востребованы на рынке, а уровень оплаты их труда весьма и весьма достойный, хотя и квалифицированным специалистам по базам данных, администраторам и разработчикам, жаловаться на низкий уровень дохода тоже не приходится. Приходите к нам на курсы и получайте востребованную и высокооплачиваемую профессию. Мы ждем Вас!

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

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

Введение

Опыт автора говорит о высокой планке вхождения в администрирование СУБД Oracle даже для квалифицированного IT специалиста. Познакомившись с СУБД Oracle в 2001 году, автор долго и болезненно шёл к изучению и пониманию этого продукта в дополнение ко всем другим интересам и задачам, и вышел таки на уровень администратора БД, имел опыт практической работы и перевёл несколько книг из документации к СУБД, в частности руководство по тюнингу экземпляра версии 9i. В силу различных причин уровень углубления автора в эту тему не является абсолютным, и автор не считает себя так называемым гуру, но для задуманного цикла статей опыта и понимания будет достаточно. Важно, что в настоящее время профессия Oracle DBA привлекает IT специалистов своей востребованностью и довольно высоким уровнем оплаты. Конечно, это верно только для крупных городов Руси, и рынок этот не массовый, но всё же он есть, и интересен высококвалифицированным и опытным IT специалистам, ищущим новые направления в своей деятельности

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

Настоящий цикл статей не призван предоставить читающему абсолютно полноценную и достоверную документацию по СУБД Oracle, задача в другом - предоставить достаточно адекватную информационную модель для быстрого вхождения в администрирование СУБД Oracle, для общего понимания заложенных в СУБД идей и для выполнения типовых операций, которые обычно являются "первыми целями" - развёртывание движка СУБД, организация резервирования данных и навык восстановления данных (бэкап) и сервиса (стэндбай), начальная аналитика уровня экземпяра в целом и т.п.

В дальнейшем при желании идти вглубину профессии необходимо будет обратиться к обширной документации от производителя, начав с книги "Концепции", и перейдя к материалам, описывающим более детально конкретные аспекты. В любом случае эти материалы составляют не одну сотню страниц, к тому же барьером зачастую является английский язык изложения, поэтому короткие вводные материалы, котрыми является настоящий цикл статей, на взгляд автора могут быть интересны начинающим и раздумывающим - стоит ли заниматься администрированием Oracle, и как бы попробовать "малой кровью". В первую очередь настоящие материалы адресованы UNIX администраторам, перед которыми волею случая возникают те или иные задачи, связанные с администрированием СУБД Oracle. Зачастую такие IT специалисты заинтересованы не в погружении в глубины профессии администратра баз данных, но только в решении ряда типовых задач, что тоже требует некоего базового понимания "как это всё" работает, то есть достаточной для решения таких задач информационной модели

Я рекомендую читать материалы минимум два раза полностью, далее по необходимости, между прочтениями обеспечить себе хотя бы недельную паузу. Первое прочтение делать без каких либо попыток проработать что либо на практике и без желания запомнить всё. Задача первого прочтение - создать "координатно - понятийную сетку" в подсознании. Второе прочтение можно уже совмещать с попытками установить движок БД, создать и попробовать администрировать какие либо тестовые базы. Также нужно понимать, что процесс вникания и "намаливания" практических решений требует времени, которое может исчисляться как минимум несколькими месяцами

Также важно, что настоящие материалы являются авторской интеллектуальной собственностью и защищены Законами РФ и международными соглашениями, и без принятия условий лицензионного соглашения использовать эти материалы запрещено. И ещё - если материалы помогли вам, не постесняйтесь написать автору, ему важна обратная связь. Адрес электронной почты есть в разделе контактные координаты настоящего сайта

Обзор задач

Первое, с чем сталкиваешься при изучении работы СУБД - большое количество отдельных технических решений в составе движка СУБД Oracle. Это объективная необходимость, связанная с особенностями задач - обеспечение одновременной работы большого количества клиентских сессий на одном банке данных, транзакционность (атомарность) обработки запросов, обеспечение отказоустойчивости, целостности и не противоречивости данных, высокая производительность и одновременное оперирование большими объёмами информации

Для хранения и управления данными СУБД Oracle использует многодетальный комплекс технических решений, самостоятельно управляющий использованием аппаратных ресурсов - оперативной памятью, дисковым вводом/выводом, процессорными ресурсами

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

Для взаимодействия с клиентами по сети реализован свой механизм SQLNet, требующий установки на клиенте клиентского ПО, решающего ряд задач, например передачу запросов и приём результата, перекодировку в различные национальные кодировки и т.п. Для целей администрирования доступно несколько интерфейсов, базовым из которых является интерфейс командной строки и использование диалекта языка SQL от производителя. Для аналитики в СУБД поддерживается накопление разнообразной статистической информации

Таким образом базовыми понятиями для начального вхождения в тему являются

• архитектура движка СУБД и некоторое углубление в отдельные компоненты архитектуры
• понятия об алгоритмах обработки запросов и оптимизаторе (детальное понимание работы оптимизатора также достижимо, и доступна документация от производителя, но это уже следующий уровень углубления, который будет рассмотрен в отдельной статье)
• особенности проведения базовых работ, в частности установка движка СУБД, создание базы, доступные методы и базовые приёмы администрирования СУБД

Все эти моменты автор планирует раскрыть в настоящей статье, по возможности сократив объём информации для ясности восприятия. Но к многодетальности таки нужно быть готовым. Описание базовых понятий есть в книге "Концепции", доступной среди нескольких десятков книг, поставляемых производителем и доступных для скачивания на сайтах производителя, но книги эти англоязычные. Автору же интересно не только выверить собственную понятийную картину, но и подготовить вводный материал на основе его понимания методов преподавания компьютерных дисциплин - так что статья будет писаться в первую очередь "из головы", но не делаться перевод "концепций". В дальнейшем серьёзному интересующемуся потребуется обращаться к официальной документации, но сейчас наша задача - по возможности быстрое вхождение в тему

Как сказано у одного автора "эх, Каштанка, насекомое ты существо супротив человека, вот как столяр супротив плотника". И добавим - или как ДБА супротив администратора UNIX, для которого администрирование Oracle является задачей администрирования всего лишь ещё одного сервиса в череде десятков прочих. Так путь юниксоиды выбирают свободные СУБД, например PostgreSQL, но и при невозможности такого выбора, например, в силу "политических" моментов, пусть юниксоидов, знающих основные моменты работы с СУБД Oracle, будет больше

Помните, коллеги UNIX администраторы, редкий администратор баз данных (DBA) имеет опыт в администрировании нескольких пригодных для использования операционных систем семейства UNIX, и мало кто из них имеет навыки администрирования различных административных, файловых, инфраструктурных, коммуникационных и т.п сервисов. Поэтому быстрое вхождение в задачи администрирования СУБД Oracle для вас реальность - именно в силу специфической заточки мозгов на восприятие информации и "укладку" нового в уже наработанную вами картину IT мира. А вот обратное - быстрое вхождение коллег DBA в задачи администрирования OC UNIX, если не спользовать ОС только как подстилку для СУБД - дело на мой взгляд мало реальное

Обзор архитектуры движка

Как говорилось выше, СУБД Oracle использует большое количество комплексных технических решений. На серверный узел для начала устанавливается программное обеспечение движка СУБД. Одновременно может быть установлено несколько движков разных версий и редакций (standart edition, enterprice edition). После этого создаются непосредственно базы. Для управления каждой базой предварительно запускается так называемый экземпляр (движка)

Вообще запуск базы на серверном узле проходит через несколько фаз. Сначала на основании файла инициализационных параметров выделяется память и запускаются так называемые фоновые процессы (в терминах операционной системы), обязательными из которых для версии 9i являются только пять. Совокупность выделенной памяти и запущенных фоновых процессов называется экземпляром. Эта фаза носит названия "запуска без монтирования". Экземпляр (движка) обслуживает свою базу данных, представленную файлами или специализированным хранилищем. Одновременно на одном серверном узле может быть запущено несколько экземпляров движка одной или разных версий, обслуживающих каждый свою базу данных

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

Понимание архитектуры работы СУБД является обязательной основой. Ключевым понятием, от которого можно оттолкнуться, является использование оперативной памяти. На рисунке ниже представлена архитектура работы движка СУБД, и далее мы рассмотрим представленную на рисунке модель детально

После поднятия экземпляра и открытия базы экземпляр готов принимать запросы от пользователей. В наиболее распространённом случае (так называемый режим работы выделенного сервера - dedicated mode) на серверном узле запускается отдельное приложение, входящее в состав движка и называемое прослушиватель (listener), который ожидает запросы от пользователей и для каждой новой пользовательской сессии создаёт так называемый серверный процесс (в терминах операционной системы) на серверном узле, и передаёт ему взаимодействие с пользователем. Таким образом серверный процесс принимает запросы от пользователей, и, совместно с экземпляром движка обеспечивает выполнение таких запросов и отдачу пользователю результатов. По окончании пользователем сессии соответствующий серверный процесс убивается

При этом между экземпляром движка, а именно его фоновыми процессами, и всеми серверными процессами, взаимодействующими с пользователями, существует "разделение труда", которое обеспечивает эффективную работу с данными одновременно для множества пользовательских сессий. Для этого при старте экземпляра выделяется большая область памяти, называемая кэшем буферов (buffer cache). При обращении к данным каждый серверный процесс сначала пытается найти данные в кэше буферов, и, при удаче считывает данные из оперативной памяти (из кэша буферов), не задействуя довольно медленный ввод/вывод с физического хранилища (дисков). Если же данных в кэше буферов нет, то именно серверный процесс, отвечающий за обслуживание конкретной пользовательской сессии, читает требуемые данные из файлов базы данных и помещает их не куда нибудь, а в кэш буферов, после чего использует эти данные для отработки пользовательского запроса. Таким образом процесс чтения одних и тех же данных несколькими сессиями существенно оптимизируется

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

Запись грязных буферов на диск осуществляет фоновый процесс, принадлежащий движку и называемый DBWR. Перед тем, как записать данные в файлы данных базы на диск, все изменения заносятся в буфер оперативных журналов, откуда они достаточно часто переносятся в файлы оперативных журналов на диск (redo logs). Запись соответствующих изменений в файлы оперативных журналов до записи соответствующих грязных буферов в файлы данных базы обеспечивается и гарантируется движком СУБД. Запись в оперативные журналы производится выделенным фоновым процессом LGWR последовательно, в порядке проведения модификаций и достаточно часто (каждые три секунды, если заполнено больше 1 мегабайта, при отработке контрольной точки, при заполненности буфера оперативных журналов на треть, перед записью соответствующих данных DBWR, при фиксации транзакции). Это позволяет проводить довольно громоздкую операцию записи процессом DBWR в файлы данных относительно нечасто, и при этом гарантировать возможность восстановления данных в случае сбоя, используя прежние версии файлов данных и данные, сохранёные в оперативных журналах. Таким образом достигается оптимизация процесса одновременной модификации данных множеством сессий - модификации проводятся в оперативной памяти, в кэше буферов, и сбрасываются на диск фоновым процессом экземпляра по мере необходимости

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

Важным аспектом для обеспечения такой работы является понятие контрольных точек. Каждая модификация даных в базе имеет свой постоянно возрастающий номер модификации SCN. Понятие контрольная точка обозначает тот последний номер SCN, который гарантированно сохранён в файлах базы данных. Каждые три секунды процесс CKPT записывает в управляющий (контрольный) файл номер SCN, гарантированно сброшенный в файлы оперативных журналов. В то же время при записи процессом DBWR данных в файлы данных в каждом файле данных сохраняется максимальный записанный в файл данных номер SCN. Ситуация, когда в заголовке разных файлов данных присутствует разный SCN, вполне возможна, например, при сбое экземпляра.Поэтому в случае сбоя экземпляра или некорректного завершения работы базы при следующем старте движок будет знать, что, по сравнению с номером SCN из контрольного файла номер SCN отдельных файлов данных отличается, и, значит, нужно провести восстановление, докатив данные из оперативных журналов в файлы данных, и далее откатив изменения по незавершённым транзакциям, используя данные пространства отмены (undo), сохраняемые как часть файлов данных

Таким образом достигается оптимизация использования ввода/вывода и обеспечивается механизм отказоустойчивости и механизм версионности, то есть сохранения какого то количества прежних версий модифицированных данных. К слову сказать это не единственный вариант обеспечения механизма версионности. Если СУБД Oracle сохраняет только изменения для каждого блока данных, то СУБД PostgreSQL сохраняет несколько версий строки для модифицируемой таблицы целиком. Таким образом размер информации отката у СУБД Oracle существенно меньше, что может быть оптимальным для нагруженных баз, однако механизм версионности СУБД PostgreSQL не требует проверки модификации и наложения информации отмены на запрашиваемые блоки, что снижает стоимость получения прежних версий (количество физических чтений, операции проверки модификаций и поиск информации отмены в данном случае не нужны, потому что просто берётся строка, соответствующая затребованной точке времени)

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

Обзор оптимизатора

Вторым комплексным механизмом оптимизации является оптимизатор запросов и библиотечный кэш. Запросы, приходящие к СУБД, пишутся на языке SQL и допускают различные варианты написания. Не оптимальный текст многократно повторяющихся сложных запросов может резко увеличить нагрузку на сервер СУБД. Примером могут быть многократно вложенные запросы с несколькими внешними соединениями без адекватных уточняющих фильтров на больших таблицах без индексов. Поэтому каждый запрос, пришедший к СУБД, подвергается анализу, при необходимости он переписывается (производится трансформация), после чего генерируется несколько вариантов выполнения запроса - с различными методами доступа к данным (например, полное сканирование таблиц, поиск по подходящему индексу, выборка тоько из индекса), для сложных запросов - с различными методами соединения таблиц (например, соединения вложенным циклом, сортированное слияние, слияние по хэшу) и с различным порядками соединения (какая таблица ведущая, какая ведомая)

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

Такая обработка каждого входящего запроса производится автоматически, называется полным или жёстким разбором запроса (hard parsing) и требует ресурсов, поэтому после проведения полного разбора запроса данные о таком запросе помещаются в библиотечный кэш, выделенный в оперативной памяти, и повторные запросы по возможности используют результаты разбора из библиотечного кэша. Этим достигается как цель оптимизации метода выполнения самого запроса, так и оптимизация ресурсов, затрачиваемых на повторный разбор запросов

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

Обзор методов администрирования

Когда основы архитектуры работы движка становятся примерно понятны, возникает следующий вопрос. Как администрируется движок? Основным способом является использование языка SQL, расширенного корпорацией Oracle в сторону команд, управляющих экземпляром и базой данных. Так что для управления, начиная от запуска экземпляра и до его остановки, используется обычная клиентская SQL сессия. Точно так же, как в MySQL или PostgreSQL существуют утилиты интерактивного доступа к базе (например для PostgreSQL это утилита psql), у СУБД Oracle существует утилита sqlplus, запускаемая из командной строки операционной системы, и позволяющая стартовать или потушить базу, а также отправлять SQL запросы и получать от СУБД ответы. Запросы же могут как обрабатывать данные, так и управлять объектами базы, создавая/удаляя/модифицируя их, или же выполнять административные задачи

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

Все такие данные представлены как таблицы или представления, к которым можно обращаться через обычные запросы выборки "select ...". Не все такие данные являются фактическими таблицами, многие из них просто маскируются движком под таблицы, являясь отражением структур, размещаемых движком в памяти на время работы экземпляра. Однако механизм получения доступа для администратора БД не меняется - все данные доступны администратору как таблицы и представления. Имена таких таблиц и представлений известны и детально расписаны в документации, поставляемой корпорацией Oracle, включая поля таблиц и их описание. Нюансом здесь является тот момент, что каждый объект базы данных, будь то таблица, хранимая процедура, правило целостности и т.д. имеет своего владельца. Все обьекты одного владельца называются "схемой". Вот удобное правило, помогающее понять, схема Oracle соответствует пользователю в операционной системе, роль Oracle соответствует группе в операционной системе

При создании каждой новой базы в базе создаётся так называемый словарь - хранилище метаданных, а также несколько системных пользователей и соответствующих им объектов данных. В частности все основные объекты, предоставляющие описанную выше информацию для администратора БД имеют владельцем пользователя SYS, или же, иначе, расположены в схеме SYS

Существует множество надстроек над базовым методом администрирования. Официальные надстройки от корпорации Oracle называются Oracle Enterprise Manager, Oracle Management Server, а упрощённым вариантом является DB Console. Однако такие надстройки не позволяют глубоко разобраться в деталях функционирования и администрирования движка и всегда более ограничены. чем базовый интерфейс через SQL запросы, однако могут быть интересны тем, что предоставляют наглядную и агрегированную информацию в виде графиков

Начальная сложность

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

• Понятие структуры памяти, выделяемой экземпляру - SGA (system global area) , в том числе
  • кеш буферов (buffer cache, буферный кеш), в которрый читаются данные из файлов и в котором данные модифицируются
  • буфер оперативных журналов
  • библиотечный кеш (фактически SQL area), хранящий планы разборов запросов и наряду с резервным пулом, а также кешем словаря входящий в т.н. разделяемый пул
  • другие структуры памяти, например пул Java
• Понятие структуры памяти, выделенные серверным процессам - PGA (processes global area) , отвечающим за обслуживание процессов клиентских. Хранят результаты запросов, а также могут использоваться для сортировок при упорядочивании, опреациях соединения (нескольких таблиц в запросе) и т.п.
• Понятие оперативные журналы (redo logs) , в которые заносятся все модификации, выполненные в базе, и использующиеся для восстановления данных. Обычно создаётся несколько групп оперативных журналов, состящих из одного или нескольких файлов. Запись журнальной информации ведётся параллельно во всё файлы группы для обеспечения отказоустойчивости, а при восстановлении автоматически берутся доступные экземпляры файла журнала (в версии 9i приходилось напарываться на некорректность этого утверждения). Запись журнальной информации ведётся последовательно в каждую группу, и по исчерпании места продолжается с первой группы, то есть циклически
• Понятие архивные журналы (archive logs) , сохраняющие конкретные версии оперативных журналов, и необходимые потому, что размер оперативных журналов ограничен. Режим, при котором данные оперативных журналов сохраняются в архивных журналах, не является для БД обязательным и должен включаться или выключаться отдельно. Однако такой режим обязателен для создания бэкапа БД без остановки сервиса и для "продакшен" баз является фактическим стандартом
• Понятие пространства отмены (UNDO, более раннее - сегменты отката) - это выделенная в БД область (сегменты или целое табличное пространство специального типа), сохраняющая все прежние значения при проведении транзакций в базе данных. Количество сохраняемых прежних значений зависит от размера пространства отмены и интенсивности модификаций в базе, причём при исчерпании места в UNDO и невозможности автоматического расширения первыми удаляются наиболее старые данные о прежних значениях данных в завершённых транзакциях. Эта область используется для отката данных в отменённых транзакциях, восстановления после сбоев и получения старых значений данных для обеспечения мультиверсионности и непротиворечивости чтения
• Понятие физических и логических структур хранения данных . Каждый файл данных базы приписывается к какому либо табличному пространтву с уникальным именем, и размечаются на блоки фиксированной длины. Существует несколько предопределённых размеров блоков и размер по умолчанию 8 КБайт. Для каждого задействованного размера блоков, а он может быть разным для разных табличных пространств, обязательно выделение соответствующего такому размеру пространства в памяти SGA, а именно в кеше буферов. Данные таких объектов, как индексы и таблицы, располагаются в выделяемых в табличном пространстве сегментах данных, причём объекту обычно выделяется персональный сегмент. Сегмент фактически является списком непрерывных групп блоков, называемых экстентами

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

• Понятие экземпляра , описывающее запущенные фоновые процессы (это в терминологии Oracle, в терминологии ОС это настоящие серверные процессы, наравне с теми, что обслуживают клиентские запросы) и выделенные структуры памяти и понятие базы данных , описывающее файлы данных, контрольные файлы и файлы оперативных журналов. Контрольные файлы являются двоичными во внутреннем формате Oracle, содержат, кроме прочего. информацию о каждом файле данных, в том числе его место положения и максимальный заведомо сохранённый номер SCN (согласно технологии неполной контролькой точки), и могут быть пересозданны администратором при условии знания последним файлов даных базы с принадлежностью к табличным пространствам и оперативных журналов
• Понятие SCN - номер системной модификации , монотонно возрастающий для каждой модификации в базе. Понятие контрольной точки , которая бывает полная, когда соотнесённый с контрольной точкой SCN отражает реально записанные в файлы данных грязные буфера, и неполной, когда SCN из контрольного файла отражает максимально записанные в оперативные журналы данные. Во втором случае сохранность данных при сбоях экземпляра также гарантируется на момент контролькой точки, но могут потребоваться операции автоматического восстановления процессом SMON при старте после сбоя
• Понятие полного и мягкого разборов запросов , а также алгоритма работы оптимизатора
• Понятие модели разграничения прав - любой объект базы имеет владельцем какого либо пользователя, иначе говорят, что объект находится в схеме с именем этого пользователя. Существуют типовые права - привелегии, которые бывают системными, объектными и колоночными (на отдельные колонки какого либо объекта). Привелегии выдаются пользователю либо непосредственно, либо присваиваются именованой группе (называемой также ролью), а уже роль выдаётся пользователю

Также для начала необходимо понимание типовых процедур, проводимых администратором, а именно:

• Установка движка БД, создание БД и предоставление доступа к ней, обновление движка и базы - обзор вынесен в
• Методы холодного и горячего резервного копирования и снятия дампов данных - обзор вынесен в
• Методы организации отказоустойчивых решений - организация холодного и тёплого стэндбаев - обзор вынесен в
• Методы контроля деятельности и оптимизации работы экземпляра
• Методы оптимизации отдельных запросов. Хотя эта задача больше соответствует разработчику, администратор БД должени иметь общее представление о возможностях оптимизации запросов, хотя бы для того, чтобы выявить нетиповую нагрузку и аргументированно предложить разработчикам оптимизировать прикладную часть
• Продвинутые и зачастую дорогостоящие методы организации отказоустойчивых решений - организация кластера Oracle RAC

Такой практический багаж, будучи наработан с той или иной степенью углубления, уже позволяет говорить о начальном вхождении в профессию. Насколько глубоко стоит идти дальше - личное дело каждого. Автор статей выводит понимание всех этих тем, подтверждённое практическим опытом, на уровень формализации и объяснения себе своими словами - в первую очередь для того, чтобы освободить память для более достойного содержимого. И, как показывает практика - а именно несколько обученных с нуля администраторов UNIX, объяснение "от автора" воспринимается коллегами проще, чем сухая документация от производителя, хочется верить, что алгоритмы мышления и чувствования потенциальных ораклоидов отличаются слабо, в выбранная манера подачи материала и уровень углубления будут кому то полезны. Впрочем, это ещё и шпаргалка по отдельным темам для самого автора и его знакомых, так что принцип формирования многоосевого объёма в статьях соблюден. В настоящем цикле статей планируется рассмотреть большую часть отмеченных здесь задач

Обзор установки СУБД и создания БД

Эта часть вынесена в отдельную статью цикла. Обзор установки движка СУБД, создания базы и получения административного доступа вынесен в . Также в отдельные статьи планируется выносить обзоры по одельным административным задачам. Кроме того на сайте автора доступен FAQ по решению отдельных небольших административных задач, а также ряд статей автора по Oracle, не входящих в цикл "Oracle - это просто"

Обзор лицензионной политики

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

Также важно, что в свете принятия 4 части ГК РФ и ст. 146 части 2 УК РФ нелицензионная установка СУБД Oracle, учитывая стоимость лицензий, может сразу подпадать под крупный или особо крупный размер ущерба правообладателю, за который предусмотренна отсидка. Важно, что непосредственным исполнителем преступления, то есть установки нелицензионной копии, является обычно администратор, какие бы басни не пело руководство организации. Когда дойдёт до крайней точки, суд будет прислушиваться не к басням, а к фактам. Фактом является действие - установка не лицензионного программного обеспечения, и есть лицо, эти действия совершившее. Обычно это администратор. А пойдёт ли руководство соучастниками - большой вопрос, который можно рассматривать ещё и как отягчающее - преступление, совершённое группой по предварительному сговору. Так что в настоящее время у администратора, не желающего отсидки, два пути - либо добиваться лицензирования организацией программного обеспечения (ПО), или же немедленно "стучать", чтобы не оказаться крайним. Неприятная, однако, ситуация

Для СУБД корпорация предоставляет несколько релизов (версий), внутри которых выделяется несколько редакций (edition). Выделяют Enterprise edition (EE), Standart edition (SE), Standart edition one (SE One). Ставятся все редакции с одного дистрибутива, причём EE является наиболее полной, а SE - подмножеством EE. Кроме редакций существует понятие опций, то есть дополнительного функционала, такого, как кластер RAC, партицирование, ADDM(AWR) и т.п. Использование опций стоит отдельных лицензионных отчислений

Лицензирование непосредственно СУБД производится либо по сокетам, либо по количеству пользователей. Причём редакции имеют ограничения - SE One может использовать не более двух сокетов, но она и дешевле. Опции распределяются тоже довольно причудливо - например для SE построение кластера Oracle RAC будет бесплатным, а для EE за него придётся заплатить

Таким образом для лицензирования СУБД необходимо определиться, какая редакция вам требуется, какие дополнительные опции вам требуются, как вам выгоднее лицензироваться - по сокетам сервера или же по пользователям. Нюансом здесь является то, что лицензирование по пользователям подразумевает всех пользователей, заведённых в базе, а не тех, которые реально обращаются к ней

Ещё одним важным моментом является оплата технической поддержки. Насколько помню, она составляет около 25% от стоимости лицензий всех СУБД, приобретённых организацией, в год. Важно, что при возобновлении контракта на техническую поддержку после перерыва от вас потребуют оплаты техподдержки всех СУБД за период перерыва. Важно, что техподдержку вы сможете приобрести только на все свои лицензии скопом, но не на одну базу. Ну, в этом есть логика, но это совсем не дёшево. Однако я могу ошибаться, и эти моменты лучше уточнить из официальных источников

Для чего нужна техническая поддержка? После заключения контракта вы получаете доступ на сайт технической поддержки Oracle https://metalink.oracle.com, или Металинк. На сайте доступно множество материалов по возникавшим проблемам и методам их решения. Также на сайте доступны обновления для релизов СУБД. И, хотя зачастую используется только базовый функционал СУБД, информационная поддержка может оказаться очень нужной. Также на сайте можно задавать вопросы сотрудникам службы технической поддержки Oracle (к сожалению, только на нерусском английском языке), и получать консультации

Обзор других продуктов корпорации Oracle

СУБД является не единственным продуктом корпорации Oracle, ею представлены как системные продукты (например, Oracle HTTO server, Oracle Identity Management, Oracle Application Server), так и прикладные решения типа OEBS, Siebel и т.п. Автор имеет право на своё мнение, и мнение автора здесь таково - возможно для сверхбольших организаций, построенных по бездушному иудохристианскому (европейскому) принципу, эти продукты и оптимальны. Однако существуют свободные альтернативы, использование которых с учётом и сиюминутных интересов в виде лицензирования, и с учётом долговременной перспективы предпочтительнее. Проявленная корпорацией Oracle манера приобретения чужих продуктов не способствует уважению, проявляемому к разработчику, а не перекупщику. Тот же Oracle HTTP сервер - это прекрасно известный свободный HTTP сервер Apache с дополнительными модулями авторизации и увязки с хранимыми процедурами БД, а в основе LDAP каталога используется (по крайней мере в версии 9i) не менее широко известный свободный сервер OpenLDAP от компании PADL

В этом, конечно, нет криминала. Но последующий уход от типовых и привычных администраторам типовых решений, которые можно применять и вне "экосистемы Oracle", например замена своего сервера приложений на основе широко известного Apache приобретённым на стороне продуктом WebLogic, говорит о желании привязать пользователя к своим продуктам. Или, как минимум, сделать подбор альтернатив более сложным. Конечно, корпорация Oracle имеет право на выбор позиции, но и пользователь имеет право выбирать - использовать или нет её продукты, которые, я допускаю, пытаются манипулировать вашим выбором при наличии альтернатив. Альтернативой Application Server, например, является, например, связка Tomcat и Apache. И так далее - к результату всегда можно придти разными дорогами, и дорога корпорации Oracle более не представляется автору заманчивой

Кстати относительно недавно корпорация преподнесла очередной сюрприз - если ранее для установки СУБД Oracle можно было официально использовать несколько различных дистрибутивов Linux, то сейчас фактически остался только дистрибутив Linux от самой корпорации Oracle, потому что осталось только одно рекомендованное ядро. Всё бы ничего, если бы именно они вложили свой труд в создание этого дистрибутива с нуля. Но, насколько я помню, вся эпопея с дистрибутивом Linux от Oracle началась с предложения корпорации предоставлять техническую поддержку для дистрибутива RedHat за деньги меньшие, чем поддержка этого же дистрибутива самим производителем - компанией RedHat, вложившей в свой дистрибутив огромное количество труда и заслуживающей подлинного уважения сообщества Open Source. Конечно я могу ошибаться, и с тех времён корпорация Oracle могла сделать полностью свой, независимый дистрибутив, не основывающийся на наработках честного трудяги Red Hat. Что же, кому интересно - пусть задаст этот вопрос Ораклу

С учётом приобретённой ранее компании SUN Microsystems, являющейся владельцем патентов на процессоры SPARC и операционной системы SUN Solaris, и фактически похороненной далее разработкой Open Solaris (энтузиастами сделан форк, но врядли он жизнеспособен), а также созданием отдельной организации и массовым, если верить новостям, переходом в неё разработчиков офисного пакета Open Office, доставшегося корпорации по наследству (также сделан форк, правильный офисный пакет теперь называется LibreOffice и сопровождается основанием организации наподобие Mozilla Foundation, так что перспективы вполне радужные) на взгляд автора можно и нужно говорить о предпочтительности свободных альтернатив

• относительно эпопеи с OpenSolaris, который фактически умертвили - вот , вот , вот
• относительно хамского, на взгляд автора, поступка по отношению к PostgreSQL - вот

Кстати, применительно непосредственно к СУБД также существуют альтернативы, например свободный PostgreSQL приближен по функционалу к Oracle Database Standart Edition, а в чём то, на взгляд автора, и превосходит его, например поддержкой процедурных языков, известных администраторам - Perl, Python и т.д. И эти альтернативы по возможности нужно развивать и использовать - приоритетно. А если для зарабатывания на жизнь вам потребуется временно, до победы свободных или уж честно и самостоятельно созданных коммерческих продуктов, администрировать СУБД Oracle - настоящий цикл статей призван вам помочь

Свои выводы каждый делает сам. Мнение автора таково - программное обеспечение СУБД Oracle как базовые технологии настолько же хорошо, качественно и удобно для обеспечения управления большими базами с позиции администратора, насколько не удобны другие продукты. И, опять же на взгляд автора, лицензионная политика, проявляемое корпорацией отношение к проектам сообщества и тенденция перехода от базирующихся на свободных продуктах решений к "чёрным ящикам" обуславливает необходимость быстрого поиска альтернатив и переход на них там, где это возможно, и, по возможности это должны быть либо решения от национального производителя, дабы развивать отрасль внутри страны, либо же открытые программные решения, такие, как PostgreSQL

Белонин С.С. (С), сентябрь 2010 года

(даты последующих модификаций не фиксируются)