программа оракал что это такое
Система Oracle: структура и процессы
На рис. 1. изображена упрощенная система процессов Oracle, которых более чем достаточно для понимания структуры базы данных. На ней изображено только самое основное (можно сказать архитектура СУБД Оракл), о чем будет рассказано в этой статье; все остальное – лишь глазурь на торте.
На рис. 1. показаны структура файлов данных базы, состоящая из двух типов файлов. Файлы с данными, хранящие «настоящие» данные, и файлы журнала повтора (redo log files, часто их называют просто файлами журнала), хранящие непрерывный поток всех изменений, производимых в файлах данных.
Рис. 1. Схема процесса Oracle, содержащая «только самое необходимое»
Файлы с данными поддерживают произвольный доступ, а для большей эффективности, каждому из них назначается размер единицы ввода/вывода – размер блока который может быть равен 2 Кбайта, 4 Кбайта, 8 Кбайт (наиболее типичное значение по умолчанию), 16 Кбайт или (на некоторых платформах) 32 Кбайта. Файлы с данными могут объединяться в логические объекты, которые называют табличными пространствами (tablespace). Табличное пространство можно рассматривать, как естественную «крупномасштабную» единицу базы данных – простые объекты данных связываются с табличными пространствами, а не с файлами данных.
Существует три основных типа табличных пространств, лежащих в основе системы Oracle Database: табличные пространства отмены (undo tablespaces), временные табличные пространства (temporary tablespaces) и «все остальное».
Временные табличные пространства появилось в версии базы данных Oracle 8, а табличные пространства отмены – в Oracle 9. До этого (начиная с версии 6, когда вообще появились табличные пространства) все табличные пространства были одинаковыми. Среди «всех остальных» имеется несколько табличных пространств, считающихся специальными (даже при том, что они интерпретируются так же, как другие табличные пространства): системное табличное пространство system и вспомогательное системное табличное пространство sysaux, которые не должны использоваться для хранения пользовательских данных.
Табличное пространство sysaux появилось в версии Oracle 10g и служит для хранения наиболее динамических и потенциально объемных данных, сгенерированных внутренними механизмами управления и обслуживания. Табличное пространство system служит для хранения словаря данных (data dictionary) – метаинформации, описывающей базу данных.
Файлы журналов поддерживают последовательный ввод/вывод, и для них назначается минимальный размер блока, обычно 512 байт, для записи. Некоторые файлы журналов называются оперативными файлами журналов повтора (online redo log files) и находятся в постоянном использовании. Остальные называются архивными файлами журналов повтора (archived redo log files) и являются простыми копиями оперативных файлов журналов, которые создаются по мере их заполнения.
Примечание. Разумеется, существуют и другие типы файлов, но мы не будем рассматривать их в данной заметке блога.
Когда программное обеспечение выполняется под управлением ОС UNIX (и во многих других ОС), в памяти создается несколько копий одного и того же процесса, и эти копии совместно используют значительный сегмент памяти. В Windows создается единственный процесс с именем oracle, в рамках которого выполняется множество независимых потоков. В последнем случае немного проще представить потоки, совместно использующие сегмент памяти. Формально,
файлы с данными называют базой данных (database), а комбинацию памяти и действующую программу (или программы) – экземпляром (instance). При использовании кластеризованной версии Real Application Clusters (RAC) можно настроить несколько компьютеров так, чтобы на каждом выполнялся отдельный экземпляр, но все они совместно использовали одну базу данных.
Сегмент совместно используемой памяти (формально: системная глобальная область (System Global Area), иногда ее называют разделяемой глобальной областью (Shared Global Area), но чаще просто используют аббревиатуру SGA) хранит массу разнообразной информации. Самыми важными хранимыми компонентами являются: кэш данных (окно в файлы с данными, хранящее копии некоторых блоков), буфер журнала (очень небольшой фрагмент памяти, используемый как циклический буфер для хранения информации, которая в скором времени будет записана в файлы журналов) и кэш библиотек (хранит информацию об инструкциях SQL и блоках PL/SQL, выполнявшихся последними). Формально, кэш библиотек является частью разделяемого пула (shared pool), но это слишком широкий термин и, к тому же, он часто применяется для обозначения любой памяти в SGA, используемой в текущий момент.
Примечание. Существует еще несколько не менее важных компонентов системы Oracle, а именно: пул потоков данных (streams pool), Java-пул и большой пул (large pool). Но все они являются обычными областями памяти, изолированными от разделяемого пула и предназначенными для поддержки специализированных механизмов.
Если вы сможете разобраться с разделяемым пулом, вы без труда разберетесь и с другими пулами. В SGA имеется сегмент, заслуживающий отдельного упоминания: «часы» (clock), используемые экземплярами для координации действий. Это простой счетчик, который называется системным номером
изменения (System Change Number, SCN) иногда его называют (не совсем правильно) системным номером подтверждения транзакции (System Commit Number).
Все процессы, имеющие доступ к SGA, могут читать и изменять SCN. Обычно процессы читают текущее значение в начале каждого запроса или транзакции (с помощью подпрограммы kcmgss – Get Snapshot SCN), и каждый раз, когда процесс подтверждает транзакцию, он увеличивает значение SCN (с помощью
подпрограммы kcmgas – Get and Advance SCN). Значение SCN увеличивается также в других случаях, именно поэтому название «системный номер изменения» (System Change Number) лучше соответствует его сути, чем название «системный номер подтверждения транзакции» (System Commit Number).
Теперь остаются всего три процесса (точнее, три типа процессов) и один важный факт, которые вы должны знать. Важный факт: программы конечного пользователя не взаимодействуют напрямую ни с файлами данных, ни даже с разделяемой памятью.
Существует отдельный процесс, копирующий информацию из буфера журнала в файлы. Его так и называют – процесс записи в журналы (log writer, известный также как lgwr). Каждый экземпляр имеет только один процесс lgwr. Аналогично существует отдельный процесс, копирующий информацию из кэша в файлы данных. Это – процесс записи в базу данных (database writer, известный также как dbwr). Часто экземпляры имеют только один такой процесс, но в очень больших и высоконагруженных системах возможно (а часто и необходимо) обеспечить запуск нескольких процессов записи в базу данных, которые получат имена dbwN (где диапазон возможных значений N отличается для разных версий Oracle).
Наконец, в каждом экземпляре существует несколько копий серверных процессов. Эти процессы выполняют операции с SGA и читают файлы с данными от имени конечного пользователя. Программы конечных пользователей передают инструкции и принимают результаты через конвейер SQL*Net. Администратор базы данных (то есть, вы!) может выбирать в настройках между двумя типами серверных процессов: выделенные (dedicated) серверные процессы и разделяемые (shared, прежде их называли многопоточными (multithreaded)).
На практике чаще используются выделенные серверы, но в некоторых системах большинство легковесных задач решается с помощью разделяемых серверов, а более тяжеловесные задачи – с помощью выделенных серверов.
Что действительно нужно знать о системе Oracle?
В конечном счете все сводится к следующему:
Конечный пользователь отправляет запросы в форме инструкций SQL (или PL/SQL) серверному процессу; каждая инструкция интерпретируется и выполняется; процесс выбирает нужные данные; процессу может потребоваться изменить данные, не нарушая их целостность; экземпляр предпринимает все меры по защите базы данных от повреждений.
Вся эта работа выполняется в контексте многопользовательской системы Oracle, где множество конечных пользователей пытаются одновременно манипулировать одними и теми же данными. Вследствие этого возникает несколько важных вопросов: «Как наиболее эффективно читать данные?», «Как наиболее эффективно записывать данные?», «Как защитить базу данных?», «Как минимизировать конфликты между пользователями?» и «Когда база данных развалится, можно ли будет собрать ее обратно?».
Заключение
В следующих статьях моего блога мы постепенно выясним, как система Oracle решает проблемы эффективности и параллельного выполнения. Мы начнем с простых изменений данных и механизмов, которые используются в Oracle для записи и применения изменений, а затем исследуем порядок объединения изменений в транзакции. По мере знакомства с этими механизмами, мы также узнаем, как они решают проблемы конкурентного доступа, и немного коснемся некоторых проблем, возникающих из-за отсутствия временных ограничений на выполнение операций в Oracle.
Затем последует предварительное обсуждение типичных для Oracle структур в памяти, и механизмов защиты разделяемой памяти от опасных параллельных изменений. Опираясь на эту информацию, мы перейдем к исследованию механизмов поиска данных в памяти и чтения данных из дисковых файлов в память.
После этого мы сможем обсудить другие механизмы передачи данных – записи из памяти в файлы – и параллельно узнаем, как Oracle отслеживает данные в структурах памяти. Уделив значительную часть времени обработке данных, мы затем посмотрим, как Oracle обрабатывает код запросов (SQL) и узнаем, насколько механизмы обработки кода похожи на механизмы обработки данных, даже при том, что код запросов не имеет ничего общего с данными.
В заключение мы быстренько пройдемся по кластеризованной версии (RAC). Выясним, какие проблемы возникают из-за необходимости синхронизировать работу нескольких экземпляров на разных компьютерах.
История СУБД Oracle — первой коммерчески успешной реляционной СУБД
До середины 70-х годов информация в базах данных распределялась по старинному иерархическому, или «древовидному», принципу, который до сих пор используется в настольных операционных системах.
Первые прототипы реляционных СУБД существовали уже в 70-е годы ХХ века. Однако мало кто верил в возможность добиться эффективной реализации таких систем. Тем не менее, к концу 1980-х годов реляционные системы заняли на мировом рынке СУБД доминирующее положение.
В связи с этим многие компании стали позиционировать свои СУБД как «реляционные» в рекламных целях. Но далеко не всегда они имели для этого достаточно оснований. Поэтому автор реляционной модели данных Эдгар Кодд в 1985 году опубликовал свои знаменитые «12 правил Кодда», которым должна удовлетворять каждая РСУБД.
16 июня 1977 года Эдом Оутсом, Бобом Майнером и Ларри Эллисоном в Калифорнии (США) была основана компания Software Development Laboratories, вскоре переименованная в Relational Software Inc. Молодые программисты начали разработку системы управления базами данных (СУБД), построенной на принципах реляционной алгебры.
Oracle 2
Первая коммерческая версия СУБД Oracle получила название Oracle 2. Такой ход должен был дать заказчикам понять, что система надежна и даже прошла проверку временем.
В конце 70-х главным конкурентным преимуществом СУБД Oracle была высокая скорость обработки огромных массивов информации, которую отметили все эксперты. В отличие от System R, для работы которой был необходим мощный суперкомпьютер — мейнфрейм, Oracle 2 справлялась с обработкой информации на более «миниатюрных» машинах. Эти и другие преимущества привели к тому, что в начале 80-х годов СУБД начала стремительно распространяться.
У Эллисона с коллегами возникли сложности при реализации совместимости с СУБД IBM System R. Нежелание IBM раскрывать исходные коды стало ключевой проблемой. В результате совместимости между двумя системами так и не удалось достичь.
Ларри Эллисон — основатель Oracle
Oracle стала исторически первой и одной из наиболее развитых реализаций архитектуры клиент/сервер. Переносимость и масштабируемость всегда имели высокий приоритет у разработчиков Oracle. Это сыграло ключевую роль в достижении успеха компании на рынке СУБД.
Oracle 2 работала на мини-компьютере PDP-11 фирмы Digital Equipment в операционной среде RSX-11. Большая часть Oracle была написана на ассемблере PDP-11, а отдельные компоненты — на новом для того времени языке C. Уже в те дни система была портируемой и работала в других операционных средах PDP-11: IAS, RSTS и UNIX. Тогда же было принято решение о переносе Oracle в новую ОС VMS. Благодаря этому СУБД Oracle заняла обширную нишу корпоративных информационных систем на быстро растущем рынке VAX.
Еще одной важной особенностью системы стала полная реализация возможностей нового языка запросов SQL — подзапросы, операция соединения и так далее. Благодаря этому многократно выросла производительность труда SQL-программистов.
Стандартный SQL (IBM) был расширен операцией CONNECT BY, позволяющим обрабатывать древовидные структуры, что становится уникальным для SQL-систем.
Конечно, над СУБД нужно было еще долго работать. В Oracle 2, например, не поддерживались транзакции: если в процессе обновления базы данных происходил сбой, предыдущее состояние БД восстановить было практически невозможно. Поэтому пользователи были вынуждены часто делать резервные копии базы данных во избежание потерь информации.
29 октября 1982 года компания переименована в Oracle Systems.
Oracle 3 и 4
В 1983 году на рынок вышла Oracle 3. Она была полностью переписана на С. Это во многом помогло решить проблему переносимости Oracle на широкий спектр платформ – их тогда было не менее 20. Кроме того, было реализовано атомарное выполнение транзакций: операция либо выполнялась полностью, либо не выполнялась вообще, соответственно, транзакция либо завершалась успешно по всем изменениям базы данных, либо откатывала все сделанные ею изменения.
С выходом Oracle 4 система была портирована на большие компьютеры c ОС VM и MVS, а также на персональный компьютер с 640 килобайтами оперативной памяти.
Также была реализована модель контроля доступа к базе данных, которая гарантировала, что результат запроса не противоречит состоянию базы данных на начало запроса. Благодаря этому было устранено известное противоречие между процессами чтения и записи.
Oracle 5
В 1985 году Oracle выпустила на рынок версию 5.0, в которой была впервые введена архитектура клиент/сервер. Кроме того, компания выпустила SQL*Net – сетевой продукт, обеспечивающий прозрачное соединение между клиентом и базой данных или между двумя базами данных.
В версии 5.1 были впервые реализованы распределенные запросы — это давало возможность обращаться к данным, физически размещенным в разных узлах. Несколько взаимодействующих серверов могли создать у пользователя многих физически разнесенных баз данных иллюзию единой логической базы данных.
Oracle 6
Разработчики версии 6 стремились создать инструмент построения крупномасштабных информационных систем, ориентированных на обработку транзакций в режиме реального времени.
Были введены генераторы последовательностей и блокировка на уровне записи. В это же время Oracle стал первым многопользовательским сетевым сервером баз данных для OS/2, Xenix, Banyan Vines и Macintosh.
В версии 6 были заложены принципиально новые возможности, в полном объеме реализованные позже:
Кризис
В 1990 году компания столкнулась с серьезными проблемами, сообщив о значительных убытках. Эллисону пришлось уволить более 400 сотрудников для сокращения издержек. Он также распустил практически весь топ-менеджмент, в числе которого были близкие Ларри люди, в течение 10 лет вместе с ним приумножавшие славу и благосостояние Oracle. Ларри оставил в компании Боба Майнера, которого всегда считал одаренным программистом и просто хорошим добрым человеком.
Столь жесткие методы Ларри объяснил так:
Кроме того, из-за совершенных ошибок в регистрации продаж и учёта ещё не прошедших сделок в бухгалтерских документах у Oracle возникли сложности с регуляторами на местном рынке.
В результате Oracle оказалась близка к банкротству, а такие конкуренты, как Informix и Sybase, начали медленно увеличивать свою долю на рынке.
На тот момент конкуренция между крупными игроками рынка достигла своего апогея — 90-ые могли запомниться многим, как период рекламной войны Oracle и Informix. Так, последняя выкупила билборд рядом с офисом Oracle и разместила на нем надпись «Осторожно, динозавры переходят дорогу», намекая на устаревшие технологии Oracle.
Однако Ларри все-таки нашел решение: он сформировал новый управленческий штат, который был «натаскан» на громадные объемы производства и жесткую конкуренцию. В результате через определенное время Oracle снова вернулась на прежние высоты.
А в 1992 году релиз Oracle 7 окончательно изменил ситуацию в лучшую сторону.
Oracle 7
Помимо общего повышения эффективности ввода/вывода, использования центрального процессора и работы с памятью, версия СУБД Oracle 7 обладала рядом инновационных архитектурных решений:
В версии 7 были полностью реализованы декларативные ограничения ссылочной целостности в соответствии со стандартами ANSI/ISO. В рамках этих ограничений (первичные и внешние ключи) пользователь мог специфицировать каскадное удаление связанных с некоторым первичным ключом записей. Процедуры PL/SQL могли описываться на уровне схемы базы данных (хранимые процедуры) и вызываться любым приложением, другими процедурами и триггерами.
Другим важным нововведением стали триггеры базы данных.
Триггер представляет собой пару (событие+действие), где событие — это удаление/занесение/обновление записей таблицы, а действие (тело триггера) — процедура PL/SQL, выполняемая при совершении события.
Триггеры могут определяться на уровне операций (DELETE, INSERT, UPDATE) или на уровне отдельных строк (FOR-EACH-ROW-триггеры, которые, к тому же, могут работать со старыми и новыми значениями строк). С помощью триггеров можно реализовать сложные правила контроля целостности, прав доступа, вывода значений и прочее.
Роль — это совокупность прав доступа к объектам базы данных (INSERT, UPDATE, SELECT и другие) и системных прав (CREATE TABLE, ALTER SYSTEM и так далее). Определив роль, администратор базы данных может с помощью одной команды дать пользователю привилегии для работы с некоторым приложением.
В 1994 году компания выпустила версию Oracle 7.1, в том числе и для IBM PC. Ранее Oracle не рассматривала эту платформу как серверную, а ограничивалась лишь созданием для нее клиентских частей своей СУБД.
В Oracle 7.1 появилась опция параллельных запросов (parallel query option), а также возможность определения количества серверных процессов, необходимых для выполнения SQL-запроса, на основе результатов работы оптимизатора запросов. В данной версии была достигнута полная интеграция PL/SQL и SQL, введен встроенный пакет DBMS_SQL и асинхронная симметричная репликация данных вместе с асинхронным вызовом удаленных процедур.
Oracle 8 и 9
В 1997 году вышла версия 8, в которой появились объектная модель, новые свойства и средства администрирования. Oracle 8.0 была более надежной по сравнению с предыдущей версией, обладала большей устойчивостью к высоким нагрузкам. Кроме того, в ней была реализована возможность партиционирования таблиц.
В 1998 году компания анонсировала Oracle 8i Release 1 (8.1.5). Буква «i» означает, что версия обладает поддержкой Интернета.
Начиная с Oracle 8.1.5 в последующих версиях появляется встроенная в СУБД виртуальная машина Java (JVM). Далее вышла версия Oracle 8i Release 2 (8.1.6), которая поддерживала XML, а также содержала определенные новшества, связанные с созданием хранилищ данных.
В 2001 году появилась версия Oracle 9i Release 1 (9.0.1), в которой было сделано более 400 изменений по сравнению с предыдущей. Среди них – «интеллектуализация» автоматизированных систем и расширение возможностей для аналитики.
В новой версии появились средства обработки XML-документов, технология Oracle RAC (Real Application Clusters) – как замена Oracle Parallel Server (OPS), механизм создания репликаций Oracle Streams, скроллируемый курсор для программ на Си и C++, встроенная в СУБД поддержка OLAP и Data Mining, переименование столбцов и ограничений целостности, поддержка Java 1.3.1 и Unicode 3.1.
Лучшие финансовые годы
Примерное разделение рынка СУБД для платформы Unix.
Примерное разделение рынка СУБД для платформы Windows NT.
В 2004 году появилась версия Oracle 10g Release 1 (10.1.0). Буква «g» в названии обозначает «Grid» («сеть») и символизирует поддержку Grid-вычислений.
Этот год стал одним из самых успешных в истории компании – норма прибыли составила 38% (самый высокий показатель за все время существования корпорации), годовой оборот возрос до 7% ($10,2 миллиарда), доходы от продаж ПО поднялись на 12% ($8,1 миллиарда), чистая прибыль выросла на 16% ($2,7 миллиарда).
Офис Oracle в России и СНГ вошел в тройку лучших представительств Oracle по темпам роста в регионе ЕМЕА (Европа, Ближний Восток и Африка), а также пятый год подряд — в пятерку лучших среди 145 представительств Oracle в мире.
До наших дней
В 2005-м была анонсирована Oracle 10g Release 2 (10.2.0.1). А в 2007-м – Oracle 11g Release 1 (11.1.0.6).
Состояние рынка СУБД на 2007 год
В 2009 году компания выпустила Oracle 11g Release 2 (11.2.0.1). В версию была введена новая для Oracle возможность «горячего» (без остановки сервера) внесения изменений в метаданные и бизнес-логику на PL/SQL – это стало возможным благодаря механизму одновременной поддержки нескольких версий схемы и логики под названием editions.
2013 год — вышла версия 12c (12.1.0.1), основное новшество — поддержка подключаемых баз данных (pluggable database), обеспечивающая свойства мультиарендности и живой миграции баз данных, суффикс «c» в названии обозначает cloud (облако).
24 апреля 2015 года стало известно о планах Oracle перевести почти все свои продукты в облако. Таким образом, американская компания решила изменить свою бизнес-модель, чтобы соответствовать изменениям на рынке.
В сентябре 2016 года Ларри Эллисон объявил о создании в Oracle дата-центров для работы с IaaS второго поколения и заявил, что лидерство компании Amazon на облачном рынке подходит к концу. Цель компании – предложить клиентам Oracle пакет услуг, где будут совмещены IaaS, PaaS и SaaS («ПО как услуга»).
База данных Oracle. Структура и основные понятия СУБД Oracle
Oracle Database — это объектно-реляционная СУБД (система управления базами данных), созданная компанией Oracle. В настоящее время она имеет множество разных версий и типов. Однако в этой статье мы поговорим не о видах баз данных Oracle, а о структуре и основных концепциях, которые относятся к СУБД Oracle Database. Поняв архитектуру СУБД Oracle, вы заложите фундамент, необходимый для понимания прочих средств (а они весьма обширны), предоставляемых базой данных Oracle.
Базы данных Oracle: экземпляры и сущности
СУБД Oracle Database включает в себя физические и логические компоненты. Особого упоминания заслуживает понятие экземпляра. Замечено, что некоторые используют термины «база данных» и «экземпляр» в качестве синонимов. Да, это взаимосвязанные, но всё же разные вещи. База данных в терминологии Oracle — это физическое хранилище информации, а экземпляр — это программное обеспечение, которое работает на сервере и предоставляет доступ к информации, содержащейся в базе данных Oracle. Экземпляр исполняется на конкретном сервере либо компьютере, в то самое время как база данных хранится на дисках, подключённых к этому серверу:
При этом база данных Oracle является физической сущностью, состоящей из файлов, которые хранятся на дисках. В то же самое время, экземпляр – это сущность логическая, состоящая из структур в оперативной памяти и процессов, которые работают на сервере. Экземпляр может являться частью только одной базы данных. При этом с одной базой данных бывает ассоциировано несколько экземпляров. Экземпляр ограничен по времени жизни, тогда как БД, условно говоря, может существовать вечно.
Также стоит заметить, что у пользователей нет прямого доступа к информации, которая хранится в базе данных Oracle — они должны запрашивать эту информацию у экземпляра Oracle.
Если упрощённо, то экземпляр — это мост к базе данных, а сама БД – это остров. Когда экземпляр запущен, мост работает, а данные способны попадать в базу данных Oracle и покидать её. Если мост перекрыт (экземпляр остановлен), пользователи не могут обращаться к базе данных, несмотря на то, что физически она никуда не исчезла.
Структура базы данных Oracle
База данных Oracle включает в себя: — табличные пространства; — управляющие файлы; — журналы; — архивные журналы; — файлы трассировки изменения блоков; — ретроспективные журналы; — файлы резервных копий (RMAN).
Табличные пространства Oracle
Любые данные, которые хранятся в базе данных Oracle, просто обязаны существовать в каком-либо табличном пространстве. Под табличным пространством (tablespace) понимают логическую структуру, то есть вы не сможете попросить ОС показать вам табличное пространство Oracle.
При этом каждое табличное пространство включает в себя физические структуры, называемые файлами данных (data files). Одно табличное пространство Oracle способно содержать один либо несколько файлов данных, в то время как каждый файл данных может принадлежать лишь одному tablespace. Создавая таблицу, мы можем указать, в какое именно табличное пространство мы её поместим — Oracle находит для неё место в каком-нибудь из файлов данных, которые составляют указанное табличное пространство.
На рисунке ниже вы можете посмотреть на соотношение между файлами данных и табличными пространствами в базе данных Oracle.
Создавая новую таблицу, мы можем поместить её в табличное пространство DATA1 либо DATA2. Таким образом, физически наша таблица окажется в одном из файлов данных, которые составляют указанное табличное пространство.
Файлы базы данных Oracle
База данных Oracle может включать в себя физические файлы 3-х основных типов: • control files — управляющие файлы; • data files — файлы данных; • redo log files — журнальные файлы либо журналы.
Посмотрим на отношения между ними:
В управляющих файлах содержится информация о местонахождении других физических файлов, которые составляют базу данных Oracle, — речь идёт о файлах данных и журналов. Также там хранится важная информация о содержимом и состоянии БД Oracle. Что это за информация: • имя базы данных Oracle; • время создания БД; • имена и местонахождение журнальных файлов и файлов данных; • информация о табличных пространствах; • информация об архивных журналах; • история журналов, порядковый номер текущего журнала; • информация о файлах данных в автономном режиме; • информация о резервных копиях, контрольных точках, копиях файлов данных.
При этом функция управляющих файлов не ограничивается хранением важной информации, нужной при запуске экземпляра, — полезны они и в процессе удалении БД Oracle. К примеру, уже с версии Oracle Database 10g можно посредством команды DROP DATABASE удалить все файлы, которые перечислены в управляющем файле БД, включая сам управляющий файл.
Инициализация СУБД Oracle
Когда вы запускаете экземпляр Oracle, происходит считывание параметров инициализации. Параметры определяют, каким образом базе данных Oracle следует использовать физическую инфраструктуру и прочую конфигурационную информацию об экземпляре.
Как правило, инициализационные параметры хранятся в файле параметров инициализации экземпляра (обычно это INIT.ORA) либо, начиная с Oracle9i, в репозитории, называемом файлом параметров сервера (SPFILE). С выходом каждой новой версии Oracle число обязательных параметров инициализации уменьшается.
Кстати, в дистрибутиве Oracle можно найти пример файла инициализации, который пригоден для запуска базы данных. Также можно воспользоваться специальной программой Database Configuration Assistant (DCA) — она подскажет обязательные значения.
Более подробную информацию смотрите в официальной документации для СУБД Oracle Database.