Данный курс является первым шагом на пути к профессиональной работе с СУБД 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 предоставляет набор различных инструментов для управление окружением сервера. Первый из них – 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
Санкт-Петербург

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 может обрабатывать файлы данных практически любого типа и поддерживает собственные типы данных почти любой платформы. Данные обычно считываются из одного или нескольких файлов данных, однако они могут быть также внесены в управляющий файл после управляющей информации. Файл данных может находиться:

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

Год выпуска: 2003

Издательство: Фолио

Формат:DJVU

К нига по священа СУБД Oracle - одной из самых популярных платформ, предназначенных для работы с базами данных. Рассматриваются общие вопросы технологии Oracle , структура баз данных и основные принципы управления файлами базы данных, их размерами, политика защиты баз данных, использование структурированного языка запросов SQL (создание простых и вложенных запросов, добавление и изменение информации в базах данных, создание и модификация основных объектов реляционных систем), язык программирования PL / SQL . Используемые практические примеры ориентированы на версию СУБД - Oracle 9 i

Введение

Часть I. ТЕОРИЯ БАЗ ДАННЫХ

Глава 1.1. Введение в базы данных

Что такое база данных

Структура базы данных

Глава 1.2. Реляционная модель базы данных

Домены и отношения

Целостность данных

Реляционная алгебра

Реляционное исчисление

Глава 1.3. Проектирование логической структуры базы данных

Концепция функциональной зависимости

Нормализация базы данных

Объектное моделирование

Глава 1.4. Функции защиты базы данных

Транзакции и параллелизм

Безопасность и целостность баз данных

Глава 1.5. Дополнительные аспекты реляционной технологии

Повышение производительности с помощью оптимизации

Домены, отношения и типы данных

Неопределенные значения и трехзначная логика

Распределенные базы данных

Часть II . ИНСТАЛЛЯЦИЯ ORACLE 9i

Глава 2.1. Oracle 9i - новые возможности

Oracle 9i - общие сведения

Новшества Oracle 9i Database

Новые возможности в SQL Oracle

Java и XML

Преимущества новых опций СУБД Oracle

Cache Fusion

Возможности восстановления

Возможности, основанные на усовершенствованной архитектуре

Другие возможности Oracle 9i

Глава 2.2. Требования по инсталляции

Компоненты Oracle_Home

Основные соглашения системы компонентов

Индивидуальные требования к компонентам

Требования к обновлению базы данных

Oracle Universal Installer - общее представление

Инсталляция продуктов Oracle 9 i

Выбор типа базы данных

Настройка сети

Конфигурация сервера в сети

Общее представление о пользователях и паролях

Глобальное имя базы данных и ее идентификатор

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

Часть III . ЭКЗЕМПЛЯР ORACLE

Глава 3 .1. Архитектура экземпляров Oracle

Экземпляр Oracle

Структура экземпляра

Фоновые процессы Oracle

Анатомия транзакции

Мониторинг экземпляра

Глава 3.2. Настройка СУБД Oracle

Необходимость выполнения настройки

Параметры настройки и ее этапы

Часть IV . ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ORACLE

Глава 4.1. Работа с SQL * PIus

Настройка программы SQL * Plus

Запуск SQL * Plus и некоторые соглашения

Команды SQL * Plus

Операция редактирования в SQL * Plus

Запуск команд SQL на выполнение

Блокировка команд SQL

Команды администратора БД

Команда EXECUTE

Управление выводом информации

План выполнения EXPLAIN PLAN

Глава 4.2. Импорт и экспорт

Назначение и возможности импорта и экспорта

Экспорт данных

Импорт данных

Глава 4.3. Oracle Enterprise Manager

Общие сведения и архитектура

Подключение Standalone

Подключение к Management Server

Приложения Management Packs и приложения управления базой данных

Планирование заданий

Часть V . ЯЗЫК СТРУКТУРИРОВАННЫХ ЗАПРОСОВ SQL

Глава 5.1. Выборка данных

Оператор SELECT

Базовый синтаксис оператора SELECT

Операторы сравнения

Диапазоны

Списки (IN и NOT IN)

Проверка значений на определенность

Поиск по шаблону

Дополнительные возможности оператора SELECT

Использование выражений

Использование специальных псевдостолбцов

Использование псевдонимов столбцов и таблиц

Выбор уникальных значений

Соединение в запросе нескольких таблиц

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

Глава 5.2. Функции Oracle

Функции преобразования

Календарные функции

Числовые функции Oracle

Символьные функции Oracle

Универсальные функции Oracle

Аналитические SQL -вычисления в Oracle 9 i

Механизмы агрегирования

Глава 5.3. Сложные запросы Oracle

Древовидные (иерархические) запросы

Внешнее соединение

Слияние результатов нескольких запросов

Глава 5.4. Создание таблиц

Использование оператора CREATE TABLE

Использование оператора ALTER TABLE

Переименование и удаление таблицы

Глава 5.5. Изменение данных таблицы

Транзакции

Вставка данных

Копирование данных из другой таблицы

Изменение данных

Удаление данных

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

Блокирование строк

Скоростное удаление данных

Изменение данных и привилегий

Индексы и ограничения

Триггеры базы данных

Глава 5.6. Другие объекты базы данных

Индексы

Особенности работы с индексами

Использование кластеров

Преимущества и недостатки кластеров

Последовательности

Представления

Синонимы

Часть VI . ЯЗЫК ПРОГРАММИРОВАНИЯ PL / SQL

Глава 6.1. Программы и модули

Процедуры и функции

Модули

Синтаксические конструкции

Глава 6.2. Использование подпрограмм и модулей

Общие сведения

Локальные подпрограммы

Хранимые и локальные подпрограммы

Хранимые подпрограммы и модули

Состояние модулей на этапе выполнения

Хранимые подпрограммы и привилегии.

Глава 6.3. Триггеры базы данных

Типы триггеров

Создание триггеров

Специфика использования триггеров

Изменяющиеся таблицы

Глава 6.4. Динамический SQL

SQL в PL / SQL

Использование DBMS . SQL

Использование внутреннего SQL

Дополнительные особенности

Глава 6.5. Взаимодействие между соединениями

Модуль DBMS_PIPE

Модуль DBMS _ ALERT

Сравнение модулей DBMS _ PIPE и DBMS _ ALERT

Глава 6.6. Объектные свойства

Объектные типы

Объекты в базе данных

Сборные конструкции

Часть VII . ОСНОВЫ АДМИНИСТРИРОВАНИЯ БАЗ ДАННЫХ

Глава 7.1. Окружение Oracle

Рабочая среда Oracle

Настройка рабочей среды Oracle

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

Обязанности АБД

Обязанности других пользователей базы данных

Учетное имя АБД в операционной системе

Подключение пользователя DBA

Учетные имена АБД

Планирование базы данных

Глава 7.3. Создание базы данных

Этапы создания БД

Создание экземпляра

Создание файла параметров инициализации

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

Создание объектов поддержки БД

Последние этапы создания БД

Запуск базы данных

Процедура остановки базы данных

Снятие сессий

Часть VIII . КОНФИГУРИРОВАНИЕ СЕРВЕРА ORACLE

Глава 8.1. Управление контрольными файлами

Общие сведения

Создание нового управляющего файла

Операции с контрольными файлами

Глава 8.2. Управление онлайновым журналом

Общие сведения

Создание групп онлайнового журнала

Создание членов онлайнового журнала

Переименование и перемещение членов онлайнового журнала

Удаление групп онлайнового журнала

Удаление членов онлайнового журнала

Глава 8.3. Управление контрольными точками и переключением журнала

Общие сведения

Установка интервалов контрольных точек БД

Форсирование переключения журнала

Форсирование быстрой контрольной точки без переключения журнала

Получение информации о журнале повторения

Часть IX . НАСТРОЙКА ПАРАМЕТРОВ ПАМЯТИ БАЗЫ ДАННЫХ

Глава 9.1. Управление размером и файлами базы данных

Политика управления табличными пространствами и файлами данных

Сегментирование табличных пространств

Создание табличных пространств и файлов данных

Добавление файлов данных к табличному пространству

Установка параметров памяти для табличных пространств

Переименование и перемещение файлов данных

Удаление табличных пространств и файлов данных

Глава 9.2. Управление объектами схемы

Управление использованием памяти блоками данных

Установка параметров памяти

Управление таблицами

Работа с представлениями

Управление последовательностями

Использование синонимов

Применение индексов

Работа с кластерами

Управление хеш-кластерами и их таблицами

Переименование объектов схемы

Очистка таблиц и кластеров

Работа с триггерами

Управление ограничениями целостности

Ручная перекомпиляция объектов

Глава 9.3. Управление сегментами отката

Общие сведения

Принцип работы сегмента отката

Множественные сегменты отката

Установка размера сегмента отката

Установка параметра OPTIMAL

Создание сегментов отката

Удаление сегмента отката

Глава 9.4. Фрагментация базы данных

Фрагментация табличного пространства

Фрагментация объектов

Глава 9.5. Анализ таблиц, индексов и кластеров

Общие сведения о возможностях анализа

Управление сбором статистики

Часть X . ЗАЩИТА БАЗЫ ДАННЫХ И АУДИТ

Глава 10.1. Установление политики защиты БД

Политика защиты данных

Управление пользователями базы данных

Идентификация пользователей

Политика защиты пользователей

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

Идентификация пользователей

Создание пользователей

Изменение пользователей

Удаление пользователей

Глава 10.3. Управление ресурсами через профили

Общие сведения

Создание профилей

Использование умалчиваемого профиля

Назначение профилей

Изменение профилей

Использование составных ограничений

Удаление профилей

Включение и выключение ресурсных ограничений

Получение информации о пользователях и профилях

Глава 1 0.4. Управление привилегиями и ролями

Системные привилегии

Объектные привилегии

Создание ролей

Удаление ролей

Назначение системных привилегий и ролей

Назначение объектных привилегий

Отзыв системных привилегий и ролей

Отзыв объектных привилегий

Каскадные эффекты отзыва привилегий

Получение информации о привилегиях и ролях

Глава 10.5. Аудит базы данных

Общие сведения

Включение и выключение опций аудита

Команда AUDIT

Выключение опций аудита

Контролирование роста и размера аудиторского журнала

Очистка аудиторских записей из аудиторского журнала

Защита аудиторского журнала

Обработка информации аудиторского журнала

Аудит с помощью триггеров базы данных

Аудит с помощью инструментальных средств Oracle

Часть XI . РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ

Глава 11. 1 Распределенные СУБД

Общие сведения о распределенных базах данных

Распределенные транзакции

Принудительное управление транзакцией

Глобальное имя базы данных

Использование связей

Обеспечение прозрачности местоположения

Глава 11.2. Управление материализованными представлениями (снимками)

Общие сведения о репликации с помощью материализованных представлений

Группы репликации

Виды материализованных представлений

Создание материализованного представления

Внутренняя реализация снимка

Установление параметров памяти

Обновление материализованных представлений

Обновляемые группы

Удаление материализованных представлений

Журналы материализованных представлений

Часть XII КОПИРОВАНИЕ И ВОССТАНОВЛЕНИЕ БД

Глава 12.1. Архивирование информации повторения

Выбор режимов архивирования

Установка режима архивирования

Глава 12.2. Стратегия резервного копирования

Физическая и логическая потеря данных

Подготовка к резервному копированию

Стратегия копирования базы, работающей в режиме ARCHIVELOG

Полное копирование базы данных («холодное» копирование)

Частичное копирование базы данных («горячее» копирование)

Копирование управляющего файла

Экспорт/импорт (логическое копирование)

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

Подготовка к восстановлению

Восстановление файлов данных

Реставрация архивных файлов журнала

Восстановление с «холодной» копии

Восстановление БД работающей в режиме ARCHIVELOG

Применение файлов журнала повторения

Потеря файлов оперативного журнала повторения

Потеря архивных файлов журнала повторения

Потеря управляющих файлов

Восстановление после ошибок пользователя

Глава 12.4. Использование RMAN

Что такое RMAN

Архитектура RMAN

Интерфейс RMAN

Работа RMAN

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

Введение

Опыт автора говорит о высокой планке вхождения в администрирование СУБД 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 года

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

Нравится