Oracle вид асу цель создания
Словарь данных. Первыми таблицами, создаваемыми в любой базе данных, являются системные таблицы, или словарь данных Oracle. Системные таблицы хранят информацию о структуре базы данных и объектов внутри нее, и Oracle обращается к ним, когда нуждается в информации о базе данных или когда выполняет оператор DDL (Data Definition Language - язык определения данных) либо оператор DML (Data Manipulation Language - язык манипулирования данными). Эти таблицы никогда непосредственно не обновляются, однако обновление в них происходит в фоновом режиме всякий раз, когда выполняется оператор DDL. Главные таблицы словаря данных содержат нормализованную информацию, которая является довольно трудной для восприятия человеком, так что в Oracle предусмотрен набор представлений, выдающих информацию главных системных таблиц в более понятном виде. Oracle запрашивает информацию из таблиц словаря данных для синтаксического разбора любого оператора SQL. Информация кэшируется в области словаря данных разделяемого пула в SGA.
Сегменты отката. Когда данные в Oracle изменяются, изменение должно быть или подтверждено, или отменено. Если изменение отменяется ("откатывается назад"), содержимое блоков данных восстанавливается в исходное состояние, существовавшее до изменения. Сегменты отката - это системные объекты, которые поддерживают этот процесс. Всякий раз, когда осуществляются какие-либо изменения в таблицах приложения или в системных таблицах, в сегмент отката автоматически помещается предыдущая версия изменяемых данных, так что старая версия данных всегда доступна, если требуется отказ. Другие пользователи при необходимости чтения данных, в то время как изменение не завершено, всегда имеют доступ к прежней версии из сегмента отката. Им предоставляется непротиворечивая по чтению версия данных. После того как изменение фиксируется, доступной становится измененная версия данных. Сегменты отката получают внешнюю память таким же образом, как другие сегменты - экстентами. Сегменту отката, однако, нужно первоначально распределить минимум два экстента.
Временные сегменты используют пространство в файлах базы данных, чтобы создать временную рабочую область для промежуточных стадий обработки SQL и для больших операций сортировки. Oracle создает временные сегменты в процессе работы и они автоматически удаляются, когда фоновый процесс SMON больше в них не нуждается. Если требуется только небольшая рабочая область, Oracle не создает временного сегмента, но вместо этого как временная рабочая область используется часть памяти PGA (глобальная область программы). Администратор базы данных может определять, в каких табличных пространствах будут располагаться временные сегменты для различных пользователей.
Сегмент начальной загрузки (или кэш-сегмент) - специальный тип объекта в базе данных, выполняющий начальную загрузку кэша словаря данных в область разделяемого пула SGA. Oracle использует кэш-сегмент только при запуске экземпляра и не обращается к нему вплоть до рестарта экземпляра. Сегмент необходим, чтобы выполнить начальную загрузку кэша словаря данных, после чего занимаемая им память освобождается.
Словарь данных.
Фундаментальное различие между RDBMS и другими БД и файловыми системами заключается в способе доступа к данным. RDBMS позволяет обращаться к физическим данным в более абстрактной, логической форме, обеспечивая легкость и гибкость при разработке кода приложения. Программы, использующие RDBMS, обращаются к данным через "машину" базы данных без непосредственной зависимости от фактического источника данных, изолируя приложение от деталей "нижележащих" физических структур данных. RDBMS сама заботится о том, где поле хранится в базе данных. Такая независимость данных возможна благодаря словарю данных RDBMS, который хранит метаданные (данные о данных) для всех объектов, расположенных в базе данных.
Словарь данных Oracle - множество таблиц и объектов базы данных, которое хранится в специальной области базы данных и ведется исключительно ядром Oracle. Словарь данных содержит информацию об объектах базы данных, пользователях и событиях. К этой информации можно обратиться с помощью представлений словаря данных. Как показано на рис.31, запросы чтения или обновления базы данных обрабатываются ядром Oracle с использованием информации из словаря данных.
Информация в словаре данных предназначена для подтверждения существования объектов, обеспечения доступа к ним и описания фактического физического расположения в памяти.
RDBMS не только обеспечивает размещение данных, но также определяет оптимальный путь доступа для хранения или выборки данных. Oracle использует сложные алгоритмы, которые позволяют выбирать информацию с наибольшей производительностью, исходя из критерия скорейшего получения первых строк результата или критерия минимального времени выполнения запроса в целом.
Представления словаря данных
Словарь данных содержит информацию об объектах базы данных, пользователях и событиях. К этой информации можно обратиться с помощью представления словаря данных:
Системные привилегии, выданные текущему пользователю.
Динамические таблицы производительности, доступные пользователю SYS, позволяют управлять производительностью работы сервера СУБД.
Специальные таблицы
Список сцепленных строк таблицы или кластера, использованного в команде ANALYZE.
Столбец | Тип данных |
OWNER-NAME | VARCHAR2 |
TABLE-NAME | VARCHAR2 |
CLUSTER-NAME | VARCHAR2 |
HEAD_ROWID | ROWID |
TIMESTAMP | DATE |
Таблица EXCEPTIONS
Эта таблица используется для определения строк, нарушающих правила целостности, если правила целостности включены.
Столбец | Тип данных |
HEAD.ROWID | ROWID |
OWNER | VARCHAR2 |
TABLE-NAME | VARCHAR2 |
CONSTRAINT | VARCHAR2 |
Эта таблица может заполняться командой EXPLAIN PLAN для того, чтобы описать план выполнения оператора SQL.
Столбец | Тип данных |
STATEMENT.ID | VARCHAR2 |
TIMESTAMP | DATE |
REMARKS | VARCHAR2 |
OPERATION | VARCHAR2 |
OPTIONS | VARCHAR |
OBJECT_NODE | VARCHAR2 |
OBJECT_OWNER | VARCHAR2 |
OBJECT.NAME | VARCHAR |
OBJECT_INSTANCE | NUMBER |
OBJECT_TYPE | VARCHAR2 |
SEARCH_COLUMNS | NUMBER |
ID | NUMBER |
PARENT.ID | NUMBER |
POSITION | NUMBER |
OTHER | LONG |
2.1.1.3 Реляционная модель.
В 1970-1971 годах Е.Ф.Кодд опубликовал две статьи, в которых ввел реляционную модель данных и реляционные языки обработки данных - реляционную алгебру и реляционное исчисление.
- Реляционная алгебра Процедурный язык обработки реляционных таблиц.
- Реляционное исчисление Непроцедурный язык создания запросов.
Все существующие к тому времени подходы к связыванию записей из разных файлов использовали физические указатели или адреса на диске. В своей работе Кодд продемонстрировал, что такие базы данных существенно ограничивают число типов манипуляций данными. Более того, они очень чувствительны к изменениям в физическом окружении. Когда в компьютерной системе устанавливался новый накопитель или изменялись адреса хранения данных, требовалось дополнительное преобразование файлов. Если к формату записи в файле добавлялись новые поля, то физические адреса всех записей файла изменялись. То есть такие базы данных не позволяли манипулировать данными так, как это позволяла бы логическая структура. Все эти проблемы преодолела реляционная модель, основанная на логических отношениях данных.
До середины 70-х годов информация в базах данных распределялась по старинному иерархическому, или «древовидному», принципу, который до сих пор используется в настольных операционных системах.
Первые прототипы реляционных СУБД существовали уже в 70-е годы ХХ века. Однако мало кто верил в возможность добиться эффективной реализации таких систем. Тем не менее, к концу 1980-х годов реляционные системы заняли на мировом рынке СУБД доминирующее положение.
В связи с этим многие компании стали позиционировать свои СУБД как «реляционные» в рекламных целях. Но далеко не всегда они имели для этого достаточно оснований. Поэтому автор реляционной модели данных Эдгар Кодд в 1985 году опубликовал свои знаменитые «12 правил Кодда», которым должна удовлетворять каждая РСУБД.
Одним из первых прототипов реляционных баз данных была система System R. Это проект компании IBM, который появился в 1976 году. Он вдохновил будущих основателей Oracle на создание собственной реляционной СУБД , но сам так и не получил коммерческого успеха.
Главным среди создателей Oracle был Ларри Эллисон, который вместе с Бобом Майнером и Эдом Оутсом до Oracle работал над проектом для ЦРУ. В ряде источников говорится, что ему было присвоено кодовое наименование «Oracle». В 1977 году молодой программист Ларри Эллисон бросил учебу в Йельском университете, чтобы начать собственный бизнес. В распоряжении Ларри Эллисона тогда было всего $1200. Он уговорил вложиться двух указанных выше друзей, но стартовый капитал от этого вырос всего на $500.
16 июня 1977 года Эдом Оутсом, Бобом Майнером и Ларри Эллисоном в Калифорнии (США) была основана компания Software Development Laboratories, вскоре переименованная в Relational Software Inc. Молодые программисты начали разработку системы управления базами данных (СУБД), построенной на принципах реляционной алгебры.
До наших дней
В 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 («ПО как услуга»).
Высоконагруженные сайты, доступность «5 nines». На заднем фоне (backend) куча обрабатываемой информации в базе данных. А что, если железо забарахлит, если вылетит какая-то давно не проявлявшаяся ошибка в ОС, упадет сетевой интерфейс? Что будет с доступностью информации? Из чистого любопытства я решил рассмотреть, какие решения вышеперечисленным проблемам предлагает Oracle. Последние версии, в отличие от Oracle 9i, называются Oracle 10g (или 11g), где g – означает «grid», распределенные вычисления. В основе распределенных вычислений «как ни крути» лежат кластера, и дополнительные технологии репликации данных (DataGuard, Streams). В этой статье в общих чертах описано, как устроен кластер на базе Oracle 10g. Называется он Real Application Cluster (RAC).
Статья не претендует на полноту и всеобъемлемость, также в ней исключены настройки (дабы не увеличивать в объеме). Смысл – просто дать представление о технологии RAC.
Статью хотелось написать как можно доступнее, чтобы прочесть ее было интересно даже человеку, мало знакомому с СУБД Oracle. Поэтому рискну начать описание с аспектов наиболее часто встречаемой конфигурации БД – single-instance, когда на одном физическом сервере располагается одна база данных (RDBMS) Oracle. Это не имеет непосредственного отношения к кластеру, но основные требования и принципы работы будут одинаковы.
Clusterware. CRS.
На данном уровне необходимо обеспечить координацию и совместную работу узлов кластера, т.е. clusterware слой: где-то между самим экземпляром базы данных и дисковым хранилищем:
CRS (Cluster-Ready Services) – набор сервисов, обеспечивающий совместную работу узлов, отказоустойчивость, высокую доступность системы, восстановление системы после сбоя. CRS выглядит как «мини-экземпляр» БД (ПО) устанавливаемый на каждый узел кластера. Устанавливать CRS – в обязательном порядке для построения Oracle RAC. Кроме того, CRS можно интегрировать с решениями clusterware от сторонних производителей, таких как HP или Sun.
Опять немного «терминологии»…
- CSSD – Cluster Synchronization Service Daemon
- CRSD – Cluster Ready Services Daemon
- EVMD – Event Monitor Daemon
Как уже стало ясно из таблички, самым главным процессом, «самым могущественным демоном», является CRSD (Cluster Ready Services Daemon). В его обязанности входит: запуск, остановка узла, генерация failure logs, реконфигурация кластера в случае падения узла, он также отвечает за восстановление после сбоев и поддержку файла профилей OCR. Если демон падает, то узел целиком перезагружается. CRS управляет ресурсами OCR: Global Service Daemon (GSD), ONS Daemon, Virtual Internet Protocol (VIP), listeners, databases, instances, and services.
- Node Membership (NM).Каждую секунду проверяет heartbeat между узлами. NM также показывает остальным узлам, что он имеет доступ к так называемому voting disk (если их несколько, то хотя бы к большинству), делая регулярно туда записи. Если узел не отвечает на heartbeat или не оставляет запись на voting disk в течение нескольких секунд (10 для Linux, 12 для Solaris), то master узел исключает его из кластера.
- Group Membership (GM). Функция отвечает за своевременное оповещение при добавлении / удалении / выпадении узла из кластера, для последующей реконфигурации кластера.
Информатором в кластере выступает EVMD (Event Manager Daemon), который оповещает узлы о событиях: о том, что узел запущен, потерял связь, восстанавливается. Он выступает связующим звеном между CRSD и CSSD. Оповещения также направляются в ONS (Oracle Notification Services), универсальный шлюз Oracle, через который оповещения можно рассылать, например, в виде SMS или e-mail.
Стартует кластер примерно по следующей схеме: CSSD читает из общего хранилища OCR, откуда считывает кластерную конфигурацию, чтобы опознать, где расположен voting disk, читает voting disk, чтобы узнать сколько узлов (поднялось) в кластере и их имена, устанавливает соединения с соседними узлами по протоколу IPC. Обмениваясь heartbeat, проверяет, все ли соседние узлы поднялись, и выясняет, кто в текущей конфигурации определился как master. Ведущим (master) узлом становится первый запустившийся узел. После старта, все запущенные узлы регистрируются у master, и впоследствии будут предоставлять ему информацию о своих ресурсах.
Уровнем выше CRS на узлах установлены экземпляры базы данных.
Друг с другом узлы общаются по private сети – Cluster Interconnect, по протоколу IPC (Interprocess Communication). К ней предъявляются требования: высокая ширина пропускной способности и малые задержки. Она может строиться на основе высокоскоростных версий Ethernet, решений сторонних поставщиков (HP, Veritas, Sun), или же набирающего популярность InfiniBand. Последний кроме высокой пропускной способности пишет и читает непосредственно из буфера приложения, без необходимости в осуществлении вызовов уровня ядра. Поверх IP Oracle рекомендует использовать UDP для Linux, и TCP для среды Windows. Также при передаче пакетов по interconnect Oracle рекомендует укладываться в рамки 6-15 ms для задержек.
Oracle 5
В 1985 году Oracle выпустила на рынок версию 5.0, в которой была впервые введена архитектура клиент/сервер. Кроме того, компания выпустила SQL*Net – сетевой продукт, обеспечивающий прозрачное соединение между клиентом и базой данных или между двумя базами данных.
В версии 5.1 были впервые реализованы распределенные запросы — это давало возможность обращаться к данным, физически размещенным в разных узлах. Несколько взаимодействующих серверов могли создать у пользователя многих физически разнесенных баз данных иллюзию единой логической базы данных.
12 марта 1986 года состоялось первичное публичное размещение акций Oracle Corporation. Высокие темпы роста позволили Oracle выйти на IPO с прибылью в $55 миллионов в 1986 году и всего за три года удесятерить прибыль до $584 миллиона.
Oracle 6
Разработчики версии 6 стремились создать инструмент построения крупномасштабных информационных систем, ориентированных на обработку транзакций в режиме реального времени.
Были введены генераторы последовательностей и блокировка на уровне записи. В это же время Oracle стал первым многопользовательским сетевым сервером баз данных для OS/2, Xenix, Banyan Vines и Macintosh.
В версии 6 были заложены принципиально новые возможности, в полном объеме реализованные позже:
- SQL-запросы могли использоваться совместно с конструкциями процедурного языка PL/SQL и посылаться для исполнения на сервер как анонимные процедуры;
- язык PL/SQL стал использоваться в SQL*Forms в качестве средства программирования приложений;
- в описание схемы базы данных на синтаксическом уровне были введены (в соответствии с ANSI/ISO-стандартом) декларативные определения ограничений ссылочной целостности.
Oracle 3 и 4
В 1983 году на рынок вышла Oracle 3. Она была полностью переписана на С. Это во многом помогло решить проблему переносимости Oracle на широкий спектр платформ – их тогда было не менее 20. Кроме того, было реализовано атомарное выполнение транзакций: операция либо выполнялась полностью, либо не выполнялась вообще, соответственно, транзакция либо завершалась успешно по всем изменениям базы данных, либо откатывала все сделанные ею изменения.
С выходом Oracle 4 система была портирована на большие компьютеры c ОС VM и MVS, а также на персональный компьютер с 640 килобайтами оперативной памяти.
Также была реализована модель контроля доступа к базе данных, которая гарантировала, что результат запроса не противоречит состоянию базы данных на начало запроса. Благодаря этому было устранено известное противоречие между процессами чтения и записи.
Введение. Single-instance.
- область хранения данных, т.е. физические файлы на диске (datastorage) (сама БД)
- экземпляр БД (получающая и обрабатывающая эти данные в оперативной памяти) (СУБД)
Во всех современных реляционных БД данные хранятся в таблицах. Таблицы, индексы и другие объекты в Oracle хранятся в логических контейнерах – табличных пространствах (tablespace). Физически же tablespace располагаются в одном или нескольких файлах на диске. Хранятся они следующим образом:
Каждый объект БД (таблицы, индексы, сегменты отката и.т.п.) хранится в отдельном сегменте – области диска, которая может занимать пространство в одном или нескольких файлах. Сегменты в свою очередь, состоят из одного или нескольких экстентов. Экстент – это непрерывный фрагмента пространства в файле. Экстенты состоят из блоков. Блок – наименьшая единица выделения пространства в Oracle, по умолчанию равная 8K. В блоках хранятся строки данных, индексов или промежуточные результаты блокировок. Именно блоками сервер Oracle обычно выполняет чтение и запись на диск. Блоки имеют адрес, так называемый DBA (Database Block Address).
При любом обращении DML (Data Manipulation Language) к базе данных, Oracle подгружает соответствующие блоки с диска в оперативную память, а именно в буферный кэш. Хотя возможно, что они уже там присутствуют, и тогда к диску обращаться не нужно. Если запрос изменял данные (update, insert, delete), то изменения блоков происходят непосредственно в буферном кэше, и они помечаются как dirty (грязные). Но блоки не сразу сбрасываются на диск. Ведь диск – самое узкое место любой базы данных, поэтому Oracle старается как можно меньше к нему обращаться. Грязные блоки будут сброшены на диск автоматически фоновым процессом DBWn при прохождении контрольной точки (checkpoint) или при переключении журнала.
- Что будет, если Oracle упадет где-то на середине длинной транзакции (если бы она вносила изменения)?
- Какие же данные прочтет первая транзакция, когда в кэше у нее «под носом» другая транзакция изменила блок?
- журнал повтора (redo log)
- сегмент отмены (undo)
Когда в базу данных поступает запрос на изменение, то Oracle применяет его в буферном кэше, параллельно внося информацию, достаточную для повторения этого действия, в буфер повторного изменения (redo log buffer), находящийся в оперативной памяти. Как только транзакция завершается, происходит ее подтверждение (commit), и сервер сбрасывает содержимое redo buffer log на диск в redo log в режиме append-write и фиксирует транзакцию. Такой подход гораздо менее затратен, чем запись на диск непосредственно измененного блока. При сбое сервера кэш и все изменения в нем потеряются, но файлы redo log останутся. При включении Oracle начнет с того, что заглянет в них и повторно выполнит изменения таблиц (транзакции), которые не были отражены в datafiles. Это называется «накатить» изменения из redo, roll-forward. Online redo log сбрасывается на диск (LGWR) при подтверждении транзакции, при прохождении checkpoint или каждые 3 секунды (default).
С undo немного посложнее. С каждой таблицей в соседнем сегменте хранится ассоциированный с ней сегмент отмены. При запросе DML вместе с блоками таблицы обязательно подгружаются данные из сегмента отката и хранятся также в буферном кэше. Когда данные в таблице изменяются в кэше, в кэше так же происходит изменение данных undo, туда вносятся «противодействия». То есть, если в таблицу был внесен insert, то в сегмент отката вносится delete, delete – insert, update – вносится предыдущее значение строки. Блоки (и соответствующие данные undo) помечаются как грязные и переходят в redo log buffer. Да-да, в redo журнал записываются не только инструкции, какие изменения стоит внести (redo), но и какие у них противодействия (undo). Так как LGWR сбрасывает redo log buffer каждые 3 секунды, то при неудачном выполнении длительной транзакции (на пару минут), когда после минуты сервер упал, в redo будут записи не завершенные commit. Oracle, как проснется, накатит их (roll-forward), и по восстановленным (из redo log) в памяти сегментам отката данных отменит (roll-back) все незафиксированные транзакции. Справедливость восстановлена.
Кратко стоит упомянуть еще одно неоспоримое преимущество undo сегмента. По второму сценарию (из схемы) когда select дойдет до чтения блока (DBA) 500, он вдруг обнаружит что этот блок в кэше уже был изменен (пометка грязный), и поэтому обратится к сегменту отката, для того чтобы получить соответствующее предыдущее состояние блока. Если такого предыдущего состояния (flashback) в кэше не присутствовало, он прочитает его с диска, и продолжит выполнение select. Таким образом, даже при длительном «select count(money) from bookkeeping» дебет с кредитом сойдется. Согласованно по чтению (CR).
Отвлеклись. Пора искать подступы к кластерной конфигурации. =)
2.3.3 Защита данных.
Транзакции, фиксация и откат. Изменения в базе данных не сохраняются, пока пользователь явно не укажет, что результаты вставки, модификации и удаления должны быть зафиксированы окончательно. Вплоть до этого момента изменения находятся в отложенном состоянии, и какие-либо сбои, подобные аварийному отказу машины, аннулируют изменения.
Транзакция - элементарная единица работы, состоящая из одного или нескольких операторов SQL;
Oracle также реализует идею отката на уровне оператора. Если произойдет единственный сбой при выполнении оператора, весь оператор завершится неудачей. Если оператор терпит неудачу в пределах транзакции, остальные операторы транзакции будут находиться в отложенном состоянии и должны либо фиксироваться, либо откатываться.
Все блокировки, захваченные транзакцией, автоматически освобождаются, когда транзакция фиксируется или откатывается, или когда фоновый процесс PMON отменяет транзакцию. Кроме того, другие ресурсы системы (такие как сегменты отката) освобождаются для использования другими транзакциями.
Точки сохранения позволяют устанавливать маркеры внутри транзакции таким образом, чтобы имелась возможность отмены только части работы, проделанной в транзакции. Целесообразно использовать точки сохранения в длинных и сложных транзакциях, чтобы обеспечить возможность отмены изменения для определенных операторов. Однако это обусловливает дополнительные затраты ресурсов системы - оператор выполняет работу, а изменения затем отменяются; обычно усовершенствование в логике обработки могут оказаться более оптимальным решением. Oracle освобождает блокировки, захваченные отмененными операторами.
Целостность данных связана с определением правил проверки достоверности данных гарантирующих, что недействительные данные не попадут в ваши таблицы. Oracle позволяет определять и хранить эти правила для объектов базы данных, которых они касаются, таким образом, чтобы кодировать их только однажды. При этом они активируются всякий раз, когда какой-либо вид изменения проводится в таблице, независимо от того, какая программа выполняет вставки, модификации или удаления. Этот контроль осуществляется в форме ограничений целостности и триггеров базы данных.
Ограничения целостности устанавливают бизнес-правила на уровне базы данных, определяя набор проверок для таблиц системы, Эти проверки автоматически выполняются всякий раз, когда вызываются оператор вставки, модификации или удаления данных в таблице. Если какие-либо ограничения нарушены, операторы отменяются. Другие операторы транзакции остаются в отложенном состоянии и могут фиксироваться или отменяться согласно логике приложения.
2.1.1.2 Сетевая модель.
Сети - естественный способ представления отношений между объектами. Они широко применяются в математике, исследованиях операций, химии, физике, социологии и других областях знаний. Сети обычно могут быть представлены математической структурой, которая называется направленным графом. Направленный граф имеет простую структуру. Он состоит из точек или узлов,соединенных стрелками или ребрами. В контексте моделей данных узлы можно представлять как типы записей данных, а ребра представляют отношения один-к -одному или один-ко-многим. Структура графа делает возможными простые представления иерархических отношений (таких, как генеалогические данные) .
Сетевая модель данных - это представление данных сетевыми структурами типов записей и связанных отношениями мощности один-к-одному или один-ко-многим. В конце 60-х конференция по языкам систем данных (Conference on Data Systems Languages, CODASYL) поручила подгруппе, названной Database Task Group (DTBG), разработать стандарты систем управления базами данных. На DTBG оказывала сильное влияние архитектура, использованная в одной из самых первых СУБД, Iategrated Data Store (IDS), созданной ранее компанией General Electric.Это привело к тому, что была рекомендована сетевая модель.
Документы Database Task Group (DTBG) (группа для разработки стандартов систем управления базами данных) от 1971 года остается основной формулировкой сетевой модели, на него ссылаются как на модель CODASYL DTBG. Она послужила основой для разработки сетевых систем управления базами данных нескольких производителей. IDS (Honeywell) и IDMS (Computer Associates) - две наиболее известных коммерческих реализации. В сетевой модели существует две основные структуры данных: типы записей и наборы:
- Тип записей. Совокупность логически связанных элементов данных.
- Набор. В модели DTBG отношение один-ко-многим между двумя типами записей.
- Простая сеть. Структура данных, в которой все бинарные отношения имеют мощность один-ко-многим.
- Сложная сеть. Структура данных, в которой одно или несколько бинарных отношений имеют мощность многие-ко-многим.
- Тип записи связи. Формальная запись, созданная для того, чтобы преобразовать сложную сеть в эквивалентную ей простую сеть.
В модели DBTG возможны только простые сети, в которых все отношения имеют мощность один-к-одному или один-ко-многим. Сложные сети, включающие одно или несколько отношений многие-ко-многим, не могут быть напрямую реализованы в модели DBTG. Следствием возможности создания искусственных формальных записей является необходимость дополнительного объема памяти и обработки, однако при этом модель данных имеет простую сетевую форму и удовлетворяет требованиям DBTG.
Лучшие финансовые годы
Согласно данным Giga Information Group (The RDBMS Market: An Update, апрель 2001 года), общий объем рынка СУБД в 2000 году возрос по сравнению с 1999 годом на 20% и составил в денежном выражении $8,8 миллиарда. Основные факторы развития: поддержка электронной коммерции, поддержка хранилищ данных и консолидация серверов.
Примерное разделение рынка СУБД для платформы 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 в мире.
2.3.4 Привилегии системного уровня
Например, прежде чем создать триггер для таблицы (даже если вы владелец таблицы как пользователь Oracle), нужно иметь системную привилегию, называемую CREATE TRIGGER, назначенную вашему учетному разделу пользователя Oracle, или роли, присвоенной учетному разделу.
Привилегия CREATE SESSION - другая часто используемая привилегия системного уровня. Чтобы выполнить соединение с базой данных, учетный раздел Oracle должен иметь привилегию системного уровня CREATE SESSION.
Привилегии объектного уровня. Привилегии объектного уровня обеспечивают возможность выполнить определенный тип действия (выбрать, вставить, модифицировать, удалить и т.д.) с указанным объектом. Владелец объекта имеет полный контроль над объектом и может выполнять любые действия с ним; он не обязан иметь привилегии объектного уровня. Фактически владелец объекта - пользователь Oracle, который может предоставлять привилегии объектного уровня другим пользователям.
Например, если пользователь, который владеет таблицей, желает, чтобы другой пользователя вставлял и выбирал строки из его таблицы (но не модифицировал или удалял), он предоставляет другому пользователю привилегии (объектного уровня) отбора и вставки для этой таблицы. Вы можете предоставлять привилегии объектного уровня непосредственно пользователям или ролям, которые затем назначаются учетным разделам пользователей Oracle.
Привилегии выдаются пользователям и ролям командой GRANT и отбираются командой REVOKE. Все привелегии можно разделить на системные и объектные. Системные привилегии относятся ко всему классу объектов, а объектные относятся к заданным объектам.
Построение современных распределенных информационных систем сегодня на прямую связано с реаляционными и объектно-ориентированными СУБД, которые в последнее время утвердились как основные средства для обработки данных в информационных системах различного масштаба - от больших приложений обработки транзакций в банковских системах до персональных систем на РС. В настоящее время существует множество систем управления базами данных (СУБД) и других программ выполняющих сходные функции. Инструментальные средства Oracle - одни из лучших и наиболее мощных имеющихся инструментов разработки профессионального класса.
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.
2.1.1.1 Иерархическая модель
Первые иерархические и сетевые СУБД были созданы в начале 60-х годов. Причиной послужила необходимость управления миллионами записей (связанных друг с другом иерархическим образом), например при информационной поддержке лунного проекта Аполлон. Среди реализуемых на практике СУБД этого типа преобладает система IMS (Information Management System компании IBM) (На данный момент это самая распространенная СУБД из всех данного типа). Применяются и другие иерархические системы: TDMS (Time-Shared Date Management System) компании Development Corporation; Mark IV Multi - Access Retrieval System компании Control Data Corporation; System - 2000 разработки SAS-Institute.
Отношения в иерархической модели данных организованы в виде совокупностей деревьев, где дерево - структура данных, в которой тип сегмента потомка связан только с одним типом сегмента предка. Графически: Предок - точка на конце стрелки, а Потомок - точка на острие стрелки. В базах данных определено, что точки - это типы записей, а стрелки представляют отношения один - к - одному или один - ко - многим.
К ограничения иерархической модели данных можно отнести:
- Отсутствует явное разделение логических и физических характеристик модели;
- Для представления неиерархических отношений данных требуются дополнительные манипуляции;
- Непредвиденные запросы могут требовать реорганизации базы данных.
2.1.1 Классификация моделей построения баз данных
В зависимости от архитектуры СУБД делятся на локальные и распределенные СУБД. Все части локальной СУБД размещаются на одном компьютере, а распределенной на нескольких. За несколько десятилетий последовательно появлялись системы (СУБД), основанные на трех базовых моделях данных: иерархической, сетевой и реляционной. Основные определения теории баз знаний и баз данных представлены в таблице 1.
Табл.1. Основные определения
Базами данных называют электронные хранилища информации, доступ к которым осуществляется с помощью одного или нескольких компьютеров.
Системы управления базами данных (СУБД)
это программные средства для создания, наполнения, обновления и удаления баз данных.
Базы знаний это хранилища знаний, представленных в формализованном виде.
Система управления базами знаний СУБЗ
это программные средства для создания, наполнения, обновления и удаления баз знаний
Дополнения к таблице 1.
Виды знаний:
Процедурные
Декларативные
Знания, отвечающие на вопрос "Как решать поставленную задачу?"
Знания, не содержащие в явном виде процедуры решения задач.
Знания о причинно-следственных связях между объектами предметной области
Знания отличающиеся неполнотой или противоречивостью.
Парадигмы решения задач
Данные + Алгоритм = Программа решения задачи
Знания + Стратегия вывода = Решение проблемы.
Знания представленные в формате "ЕСЛИ-ТО"
Знания представленные в виде набора взаимосвязанный фреймов.
Граф, вершины которого соответствуют объектам или понятиям, а дуги определяют отношения между вершинами.
Структурированное описание объекта предметной области состоящее из наименования объекта (имя фрейма), атрибутов объекта (свойств, характеристик) - слоты фрейма.
Это фрейм у которого значения слотов не определены.
Это фрейм прототип с конкретными значениями.
Enterprise JavaBeans.
Стандарт для создания средствами языка Java пригодных для многократного использования компонентов, из которых формируются прикладные программы. Компоненты Enterprise JavaBeans облегчают разработку программ, обеспечивающих доступ к хранимой в базе данных информации.
Распараллеливание
обработки запроса
(Intraquery parallelism).
Использование нескольких ЦП для обработки одного запроса.
Параллельная
обработка запросов
(interquery parallelism)
подразумевает параллельную обработку нескольких запросов (на разных ЦП).
Уровень изоляции
(Isolation level).
Установочный параметр БД, определяющий, в какой степени одновременно обратившиеся к базе данных пользователи могут оказывать влияние на работу друг друга. Как правило, используются три уровня изоляции: завершение чтения (read committed), характеризуется большим количеством одновременно обслуживаемых пользователей и низким уровнем изоляции каждого из них); в установленном порядке (serializable), небольшое число одновременно обслуживаемых пользователей, высокая степень изоляции и повторяющееся чтение (repeatable read), сочетание двух первых уровней.
Технология СОМ
COM - Component Object Model - Компонентная модель объектов, предложена корпорацией Микрософт.
Технология CORBA
CORBA - Common Object Require Broker Architecture - архитектура с брокером требуемых общих объектов, разработана независимой группой OMG.
JDBC (Java
Database Connectivity).
Интерфейс взаимодействия с базами данных на языке Java. Этот стандарт, разработанный фирмой Sun Microsystems, определяет способы доступа Java-приложений к данным БД.
ODBC (Open
Database Connectivity).
Открытый интерфейс взаимодействия с базами данных. Предложенный корпорацией Microsoft стандарт, регулирующий доступ Windows -приложений к базам данных. Стандарт ODBC постепенно заменяется спецификацией OLE DB.
OLAP (Online
analytical processing).
Оперативный анализ данных. Этот метод обработки применяется с целью ускорения обработки запросов и предусматривает предварительный расчет часто запрашиваемых данных (например, сумм или значений счетчика).
OLE DB
(Object Linking and
Embedding Database).
OLE для баз данных. Новый стандарт Microsoft, регулирующий доступ приложений к базам данных. Имеет расширения для серверов OLAP и предусматривает применение специальных средств обработки мультимедийных данных.
Дополнения к табл.2
Операция соединения
(Join).
Процесс, позволяющий объединять данные из двух таблиц посредством сопоставления содержимого двух аналогичных столбцов.
SQL (Structured
query language).
Язык структурированных запросов, язык S0L. Является принятым в отрасли стандартом для выполнения операций вставки, обновления, удаления и выборки данных из реляционных БД.
Хранимая процедура
(Stored procedure).
Программа, которая выполняется внутри базы данных и может предпринимать сложные действия на основе информации, задаваемой пользователем. Поскольку хранимые процедуры выполняются непосредственно на сервере базы данных, обеспечивается более высокое быстродействие, нежели при выполнении тех же операций средствами клиента БД.
Транзакция
(Transaction).
Совокупность операций базы данных, выполнение которых не может быть прервано. Для того чтобы изменения, внесенные в БД в ходе выполнения любой из входящих в транзакцию операций, были зафиксированы в базе данных, все операции должны завершиться успешно. Все базы данных, представленные в нашем обзоре, позволяют использовать транзакции, тогда как БД для настольных систем, например Visual dBase фирмы Inprise или Microsoft Access, не предусматривают применения механизма транзакций.
Триггер
(Trigger).
Программа базы данных, вызываемая всякий раз при вставке, изменении или удалении строки таблицы. Триггеры обеспечивают проверку любых изменений на корректность, прежде чем эти изменения будут приняты
Кризис
В 1990 году компания столкнулась с серьезными проблемами, сообщив о значительных убытках. Эллисону пришлось уволить более 400 сотрудников для сокращения издержек. Он также распустил практически весь топ-менеджмент, в числе которого были близкие Ларри люди, в течение 10 лет вместе с ним приумножавшие славу и благосостояние Oracle. Ларри оставил в компании Боба Майнера, которого всегда считал одаренным программистом и просто хорошим добрым человеком.
Столь жесткие методы Ларри объяснил так:
Мы были самой быстрорастущей компанией в истории компьютерной индустрии, но внезапно зашли в тупик и стали биться головой о стену, – сказал он. – Мы достигли миллиардного дохода, но столкнулись с практически неразрешимыми проблемами управления. Дело в том, что люди, управлявшие миллиардной компанией, остались такими же, как в те времена, когда наша компания стоила $15 миллионов. Я испытывал невероятное чувство признательности всем, кто работал со мной, всем, с кем вместе мы создавали Oracle. Но у меня не было выбора. Я должен был уволить их, понимая, что если этого не сделать, то вскоре просто не будет никакого Oracle. Я чувствовал, прежде всего, ответственность перед всей компанией, перед всем персоналом, всеми акционерами и клиентами.
Кроме того, из-за совершенных ошибок в регистрации продаж и учёта ещё не прошедших сделок в бухгалтерских документах у Oracle возникли сложности с регуляторами на местном рынке.
В результате Oracle оказалась близка к банкротству, а такие конкуренты, как Informix и Sybase, начали медленно увеличивать свою долю на рынке.
На тот момент конкуренция между крупными игроками рынка достигла своего апогея — 90-ые могли запомниться многим, как период рекламной войны Oracle и Informix. Так, последняя выкупила билборд рядом с офисом Oracle и разместила на нем надпись «Осторожно, динозавры переходят дорогу», намекая на устаревшие технологии Oracle.
Однако Ларри все-таки нашел решение: он сформировал новый управленческий штат, который был «натаскан» на громадные объемы производства и жесткую конкуренцию. В результате через определенное время Oracle снова вернулась на прежние высоты.
А в 1992 году релиз Oracle 7 окончательно изменил ситуацию в лучшую сторону.
Oracle 7
Помимо общего повышения эффективности ввода/вывода, использования центрального процессора и работы с памятью, версия СУБД Oracle 7 обладала рядом инновационных архитектурных решений:
- разделяемый SQL-кэш на сервере: сервер распознает посылаемые клиентами SQL-запросы, которые ранее уже были проанализированы и скомпилированы и в данный момент находятся в кэш-памяти, за счет чего экономится время анализа, оптимизации и трансляции, а также память, требуемая для хранения SQL-запросов;
- разделяемый пул процессов сервера вместо отдельного процесса для каждого клиента, что позволяет сэкономить значительный объем памяти.
В версии 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 и асинхронная симметричная репликация данных вместе с асинхронным вызовом удаленных процедур.
В 1994 году в России появился первый официальный представитель Oracle — Андреас Харт. Тогда же клиентами Oracle в России стали такие мощные структуры, как ФСБ, Кабинет Министров, Мосприватизация, МПС, РАО ЕЭС и так далее.
Уровень доступа к данным. ASM.
Хранилищем (datastorage) в больших БД почти всегда выступает SAN (Storage Area Network), который предоставляет прозрачный интерфейс серверам к дисковым массивам.
Сторонние производители (Hitachi, HP, Sun, Veritas) предлагают комплексные решения по организации таких SAN на базе ряда протоколов (самым распространенным является Fibre Channel), с дополнительными функциональными возможностями: зеркалирование, распределение нагрузки, подключение дисков на лету, распределение пространства между разделами и.т.п.
Позиция корпорации Oracle в вопросе построения базы данных любого масштаба сводится к тому, что Вам нужно только соответствующее ПО от Oracle (с соответствующими лицензиями), а выбранное оборудование – по возможности (если средства останутся после покупки Oracle :). Таким образом, для построения высоконагруженной БД можно обойтись без дорогостоящих SPARC серверов и фаршированных SAN, используя сервера на бесплатном Linux и дешевые RAID-массивы.
На уровне доступа к данным и дискам Oracle предлагает свое решение – ASM (Automatic Storage Management). Это отдельно устанавливаемый на каждый узел кластера мини-экземпляр Oracle (INSTANCE_TYPE = ASM), предоставляющий сервисы работы с дисками.
Oracle старается избегать обращений к диску, т.к. это является, пожалуй, основным bottleneck любой БД. Oracle выполняет функции кэширования данных, но ведь и файловые системы так же буферизуют запись на диск. А зачем дважды буферизировать данные? Причем, если Oracle подтвердил транзакцию и получил уведомления том, что изменения в файлы внесены, желательно, чтобы они уже находились там, а не в кэше, на случай «падения» БД. Поэтому рекомендуется использовать RAW devices (диски без файловой системы), что делает ASM.
- отсутствие необходимости в отдельном ПО для управления разделами дисков
- нет необходимости в файловой системе
- Зеркалирование данных:
как правило, 2-х или 3-х ступенчатое, т.е. данные одновременно записываются на 2 или 3 диска. Для зеркалирования диску указываются не более 8 дисков-партнеров, на которые будут распределяться копии данных. - Автоматическая балансировка нагрузки на диски (обеспечение высокой доступности):
если данные tablespace разместить на 10 дисках и, в некоторый момент времени, чтение данных из определенных дисков будет «зашкаливать», ASM сам обратится к таким же экстентам, но находящимся на зеркалированных дисках. - Автоматическая ребалансировка:
При удалении диска, ASM на лету продублирует экстенты, которые он содержал, на другие оставшиеся в группе диски. При добавлении в группу диска, переместит экстенты в группе так, что на каждом диске окажется приблизительно равное число экстентов.
Таким образом, кластер теперь может хранить и читать данные с общего файлового хранилища.
Пора на уровень повыше.
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.
2.1 Базы данных и их сравнительные характеристики.
Читайте также: