программа оракал что это такое

История СУБД 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: структура и процессы

На рис. 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 Database для начинающих: основы базы данных

Илья Дергунов

Автор статьи. ИТ-специалист с 20 летним стажем, автор большого количества публикаций на профильную тематику (разработка ПО, администрирование, новостные заметки). Подробнее.

Базы данных и экземпляры Oracle

Многие пользователи Oracle Database употребляют термины экземпляр и база данных как синонимы. На самом деле это разные (хотя и взаимосвязанные) вещи. Различие существенно, так как проливает свет на архитектуру Oracle.

В Oracle термином база данных описывается физическое хранилище информации, а термином экземпляр – программное обеспечение, работающее на сервере и предоставляющее доступ к информации в базе данных Oracle Database. Экземпляр исполняется на конкретном компьютере или сервере; база данных хранится на дисках, подключенных к этому серверу. Эта взаимосвязь изображена на рисунке 1 ниже:

Рис. 1. Экземпляр и база данных

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

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

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

В реальном мире есть хорошая аналогия экземплярам и базам данных. Можно считать экземпляр мостом к базе данных, а саму ее – островом. Транспорт попадает на остров и уходит с него по мосту. Если мост перекрыт, то остров на месте, но транспорту туда не попасть. В терминологии Oracle, если экземпляр запущен, то данные могут попадать в базу и уходить из нее. Физическое состояние базы данных при этом изменяется. Если же экземпляр остановлен, то пользователи не могут обращаться к базе данных, пусть даже физически она никуда не делась. База данных в этом случае статична, никаких изменений в ней не происходит. Экземпляр снова запущен – и данные тут как тут.

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

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

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

Любые данные, хранящиеся в базе Oracle, должны находиться в каком-то табличном пространстве. Табличное пространство (tablespace) – это логическая структура; нельзя попросить операционную систему показать вам табличное пространство. Каждое табличное пространство состоит из физических структур, называемых файлами данных (data files). В одном табличном пространстве может быть один или несколько файлов данных, тогда как каждый файл данных принадлежит ровно одному табличному пространству. При создании таблицы можно указать, в какое табличное пространство ее поместить. Тогда Oracle найдет для нее место в одном из файлов данных, составляющих указанное табличное пространство.

На рисунке 2 показано соотношение между табличными пространствами и файлами данных. Здесь мы видим два табличных пространства в базе данных Oracle.

При создании новой таблицы ее можно поместить в табличное пространство DATA1 или DATA2. Физически таблица окажется в одном из файлов данных, составляющих указанное табличное пространство.

Начиная с версии Oracle Database 10g Release 2 для всех типов таблиц по умолчанию подразумеваются локально управляемые табличные пространства. В таком табличном пространстве можно создавать большие файлы, то есть при работе в 64-разрядных системах задействуется возможность создавать сверхбольшие файлы.

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

В Oracle9i появился механизм файлов, управляемых Oracle (Oracle Managed Files, OMF), позволяющий автоматически создавать, именовать и, если понадобится, удалять все файлы, составляющие базу дан­ных. OMF упрощает обслуживание базы данных, поскольку не нужно помнить имена всех составляющих ее файлов. К тому же не возникают проблемы из-за ошибок человека, ответственного за именование фай­лов. Начиная с версии Oracle Database 10g сочетание OMF и таблич­ных пространств с большими файлами делает работу с файлами дан­ных совершенно прозрачной.

Файлы базы данных Oracle

База данных Oracle состоит из физических файлов трех основных ти­пов:

На рис. 3 показаны эти три типа файлов и отношения между ними.

Рис. 3. Файлы, составляющие базу данных

Управляющие файлы не только содержат важную информацию, необ­ходимую при запуске экземпляра, они полезны и при удалении базы данных. Начиная с версии Oracle Database 10g с помощью команды DROP DATABASE можно удалить все файлы, перечисленные в управ­ляющем файле базы данных, а также сам управляющий файл.

Инициализация базы данных

При запуске экземпляра Oracle считываются параметры инициализа­ции. Они определяют, как база данных должна использовать физиче­скую инфраструктуру и иную конфигурационную информацию об эк­земпляре. Параметры инициализации хранятся в файле параметров инициализации экземпляра, который обычно называют просто INIT.ORA, или, начиная с версии Oracle9i, в репозитории, который на­зывается файлом параметров сервера (или SPFILE). Количество обяза­тельных параметров инициализации уменьшается с выходом каждой новой версии Oracle. В дистрибутиве Oracle есть пример файла инициа­лизации, пригодный для запуска базы данных. Либо можно воспользо­ваться программой Database Configuration Assistant (DCA), которая подскажет обязательные значения (например, имя базы данных).

Вот обязательные параметры инициализации для версии Oracle Data­base 11g:

Местонахождение управляющих файлов.

Локальное имя базы данных.

Имя домена базы данных (например, us.companyname.com).

Местонахождение архивного журнала.

Параметр, включающий архивирование журналов.

Местонахождение области быстрого восстановления (flash recovery area) (каталог, файловая система или группа дисков ASM).

Максимальный размер области быстрого восстановления базы дан­ных в байтах.

Размер блока базы данных в байтах (например, для 4 Кбайт указы­вается значение 4096).

Максимальное число процессов операционной системы, обслужи­вающих одновременный доступ к базе данных.

Максимальное число сеансов работы с базой данных.

Максимальное число открытых в базе данных курсоров.

Минимальное число разделяемых серверов базы данных.

REM O TE_LI S TENER

Имя удаленного прослушивателя.

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

Размер области памяти, автоматически выделяемой для SGA и PGA экземпляра.

Язык, определенный в подсистеме поддержки национальных язы­ков (National Language Support, NLS) для базы данных.

Территория, определенная в подсистеме поддержки национальных языков для базы данных.

В качестве признака взятого курса на автоматизацию отметим, что в версии Oracle Database 11g параметр UNDO_MANAGEMENT по умол­чанию устанавливается в режим автоматического управления откатом (undo). Механизм отката применяется при откате транзакций, а также для восстановления базы данных, обеспечения согласованности по чтению и реализации ретроспекции. (Однако записи о повторном вы­полнении располагаются в физических журналах повтора, или нака­та, redo log; в них хранятся изменения, произведенные в сегментах данных и блоках сегментов отката, там же хранится таблица транзак­ций для сегментов отката.) Время хранения информации для отката Oracle теперь подбирает автоматически, исходя из того, как сконфигу­рировано табличное пространство отката.

Изучите поставляемую с вашей версией СУБД документацию в части дополнительных параметров инициализации, поскольку эта информа­ция изменяется от версии к версии.

Источник