Эти материалы являются объектом авторского права и защищены законами РФ и международными соглашениями о защите авторских прав. Перед использованием материалов вы обязаны принять условия лицензионного договора на использование этих материалов, или же вы не имеете права использовать настоящие материалы

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

Введение

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

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

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

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

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

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

СУБД Oracle является реляционной СУБД. Предполагается, что читатель является квалифицированным UNIX специалистом, хоть немного знакомым с такими СУБД, как MySQL и PostgreeSQL, знакомым с основами языка SQL и понятием реляционные базы данных. Такая планка предварительных требований отражает именно опыт автора - именно с таких стартовых условий начинал вхождение в мир Oracle автор, и специфику именно таких начальных условий автор знает и может поделиться ключевыми моментами дальнейшего движения. Увы, чудес не бывает - администрирование СУБД Oracle - сложная и многодетальная задача, и воспитываемые администрированием UNIX навыки позволяют довольно быстро научиться как пониманию основ, так и положить себе в копилку навыки и опыт базовых операций с СУБД Oracle

Обзор задач

Первое, с чем сталкиваешься при изучении работы СУБД - большое количество отдельных технических решений в составе движка СУБД 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, который фактически умертвили - вот, вот, вот, вот
• относительно эпопеи с появлением LibreOffice (у меня уже установен, а у вас ?) - вот, вот, вот, вот, вот
• относительно эпопеи с рекомендованным ядром - вот, заметьте фразу "The Unbreakable Enterprise Kernel is now the only Linux kernel Oracle recommends for use with Oracle software", теперь это единственное рекомендованное ядро
• любопытное интервью Дж. Гослинга, создателя Java, ушедшего, как показывают публикации, из за отношений внутри корпорации - вот, вот, вот
• относительно хамского, на взгляд автора, поступка по отношению к PostgreSQL - вот

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

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

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