Инстанс базы данных что это
Что такое экземпляр sql server?
Я разрабатываю приложение на C# в Visaul Studio 2015, которое работает с sql базой данной. Я программист самоучка, практик без какого-либо теоретического образования, все вопросы которые возникают просто гуглю, а тут бьюсь какую неделю и ни как не могу разобраться. Помогите, пожалуйста.
Была база данных sql и проект, по моему в 2012 студии. Базу данных делал в какой-то sql management studio, не помню какая версия. И вот пришлось вернуться к заводским настройкам компьютера и все, что было устанавливать заново. Установил 2015 Visual Studio, sql express 2014 и sql management studio 2014. Все устанавливал «по умолчанию» просто нажимал кнопку далее, так как мало что во всем этом понимаю. После запуска старого проекта в Visual Studio 2015, она видит файл базы данных, но с красным крестиком, и когда я нажимаю «проверить подключение» выдает ошибку:
«Значение источника данных в строке подключения указывает на неустановленный экземпляр SQL Server. Для устранения этой проблемы установите соответствующий экземпляр SQL Server или измените значение источника данных в строке подключения.»
что такое экземпляр SQL Server? как его узнать и как установить? я установил еще SQL Server 2012, но все равно выдает ошибку.
Заранее большое спасибо за помощь.
Скорей всего после установки у вас поменялся Хост или имя БД. Вам нужно найти в вашем коде описанные реквизиты и исправить их на корректные.
Значение источника данных в строке подключения указывает на неустановленный экземпляр SQL Server. Для устранения этой проблемы установите соответствующий экземпляр SQL Server или измените значение источника данных в строке подключения.
Ошибка ведь сама за себя говорит: когда пытаетесь открыть БД в студии, настройку подключения она «подхватывает» из файла app.config (web.config, если web-приложение). Сейчас, видимо, у вас указана неверная строка, которая ссылается на SQL Server другой версии.
Вот как примерно должен выглядеть параметр строки подключения:
В основном, обычно, в разных версиях SQL Server меняется только параметр «Data Source» в этой строке.
Oracle RAC. Общее описание / Часть 1
Высоконагруженные сайты, доступность «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. Это не имеет непосредственного отношения к кластеру, но основные требования и принципы работы будут одинаковы.
Введение. Single-instance.
Во всех современных реляционных БД данные хранятся в таблицах. Таблицы, индексы и другие объекты в 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 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).
Отвлеклись. Пора искать подступы к кластерной конфигурации. =)
Уровень доступа к данным. 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.
Таким образом, кластер теперь может хранить и читать данные с общего файлового хранилища.
Пора на уровень повыше.
Clusterware. CRS.
На данном уровне необходимо обеспечить координацию и совместную работу узлов кластера, т.е. clusterware слой: где-то между самим экземпляром базы данных и дисковым хранилищем:
CRS (Cluster-Ready Services) – набор сервисов, обеспечивающий совместную работу узлов, отказоустойчивость, высокую доступность системы, восстановление системы после сбоя. CRS выглядит как «мини-экземпляр» БД (ПО) устанавливаемый на каждый узел кластера. Устанавливать CRS – в обязательном порядке для построения Oracle RAC. Кроме того, CRS можно интегрировать с решениями clusterware от сторонних производителей, таких как HP или Sun.
Опять немного «терминологии»…
Как уже стало ясно из таблички, самым главным процессом, «самым могущественным демоном», является 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.
Информатором в кластере выступает 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 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 Database 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 теперь подбирает автоматически, исходя из того, как сконфигурировано табличное пространство отката.
Изучите поставляемую с вашей версией СУБД документацию в части дополнительных параметров инициализации, поскольку эта информация изменяется от версии к версии.
Single-instance архитектура
Это наиболее распространённая архитектура. Один экземпляр на компьютере, работающий с файлами базы данных на локальных жётских дисках. Instance состоит из структур памяти и процессов. Как только вы выключаете экземпляр, все следы его работы исчезают (останавливаются процессы, освобождается память). База данных же состоит из физических файлов, на жётском диске. Вне зависимости от состояния они всегда остаются. Таким образом жизенный цикл экземпляра длится до тех пор пока он остаётся в памяти, т.е. экземпляр может быть запущен и остановлен. База данных, как только она создана, существует бесконечно долго – пока вы умышленно не удалите файлы принадлежащие базе данных.
Процессы, которые являются частью экземпляра базы данных обычно называют background processes, так как они существуют и запущены всё время пока instance активен. Эти процессы не требуют дополнительного администрирования, хотя в некоторых случаях администратор может повлиять на них. Структуры памяти расположенные в разделяемой области памяти операционной системы назыываются system global area или SGA. Эта область памяти выделяется при запуске и освобождается при остановке инстанса. В зависимости от определённых условий, SGA в экземпляре БД версии 11g может быть перемещена в памяти либо автоматически либо как результат выполнения команд администратора.
Пользовательские сессии состоят из пользовательского процесса, запущенного на машине пользователя, который подключается к серверному процессу, работающему на сервере. Технология запуска серверного процесса по запросу пользовательской сессии мы расмотрим в главе четыре. Взаимодействие между пользовательским процессом и серверным обычно происходит посредством локальной сети используя закрытый протокол Oracle Net поверх стандартного сетевого протокола (обычно TCP). Данный подход реализует клиент-серверную модель: пользовательский процесс генерирует SQL команды; серверный процесс выполняет. Серверные процессы обычно называют foreground процессами, в противовес background процессам которые составляют экземпляр БД. Для каждого пользовательского процесса выделяется область неразделяемой памяти, называемой program global area или PGA. Это область в отличие от SGA доступна только пользовательской сессии. Примечание: у background процессов тоже есть PGA. Область такой памяти для конкретной сессии может отличаться в зависимости от памяти необходимой для даннйо сессии в момент времени. Администратор базы данных может установить предельное значение для всех областей PGA и Oracle будет контролировать выделение памяти автоматически.
Управление памятью в версии 11g может быть полностью автоматическим: администратор может не делать ничего кроме указания полного объема памяти доступного для SGA и PGA и позволить Oracle серверу управлять им как ему угодно. Но также администратор может и устанавливать ограничения на выделение памяти вручную. Администратору доступна настройка определенных ограничений для автоматического управления памятью.
Физические структуры из которых состоит база данных – это файлы данныx (data files), журнал изменений (redo log) и файл управления (control file). Внутри физической структуры файлов данных лежит логическая структура доступная для конечных пользователей (разработчиков, бизнес аналиттиков и т.п.). Такая архитектура позволяет абстрагировать логическую структуру от физической: программисту нет необходимости знать где физически находится информация, так как он взаимодействует только с логическими структурами, такими как таблица. Таким же образом, системный администратор не знает какие данные лежат в физических структурах, он видит только системные файлы, а не то что внутри них. Только администратор базы данных видит обе стороны.
Данные хранятся в data файлах. Нету практических ограничений к количеству этих файлов или их размеру, и разделение физической и логической структуры означает, что можно переместить, изменить размер или добавить новые файлы, а пользователя это не затронет. Эта взаимосвязь между физической и логической структурами хранится в словаре данных (data tictionary), которые содержит мета-данные для всез базы данных. Путем просмотра определенных представлений (views) в словаре данных, администратор базы данных (DBA) может точно определить где какая часть таблица находится в физической структуре.
Словарь данных – это набор таблица внутри базы данных. Возникает рекурсивная проблема: инстанс должен знать взаимосвязь файлов и логических структур, а эта информация находится внутри самой базы данных. Решение, представляющее собой поэтапный процесс запуска, расмотрим в главе три.
Стандартное требование к реляционной системе управления базами данных (RDBS) – данные не могут быть потеряны. Это значит что должны быть резервные копии, и более того, все изменения в данных между резервными копиями должны храниться в таком виде, чтобы было возможным применить их к восстановленной копии. Такой тип восстановления реализован в Oracle с помощью файла изменений (redo log). В этом файле последовательно хранятся все изменения в данных (change vector). Эти изменения – это изменения данных сделанные с помощью команд DML (Data Manipulation Language: INSERT, UPDATE или DELETE). Любое изменение сделанное пользовательской сессией, изменяет данные в файле и записывается в файл изменений в виде, позволяющем повторить это действие. В случае нарушения работы файлов данных, последняя копия может быть востановлена и Oracle последовательно выполнит все изменения из файла изменения, таким образом восстановив состояние данных внутри файла. Это гарантирует что никакие изменения данных не будут потеряны, только в случае если нарушения настолько серъёзные что затронули и файлы данных, и резервные копии и файл изменений.
Файл управления (control file) содержит данные о физической структуре базы данных и является отправной точкой для её связи с логической структурой. Когда экземпляр стартует, процесс начинается с чтения файла управления. Внутри этого файла информация, которая позволит подключится к собственно базе данных и словарю данныx (data dictionary) внутри базы.
Архитектура single-instance в общем состоит из 4 взаимодействующих процессов:
Абсолютно невозможно как-то повлиять на базу данных со стороны пользователя напрямую: пользователь может создать команду, а уже сервер выполнит её.
Распределенные системные архитектуры
В single-instance архитектуре, один экземпляр работает с одной базой данных. В распределенных системах, различные комбинации группировки экземпляров и баз данных возможны. Главным образом:
Real Application Cluster (RAC) когда множество экземпляров работает с одной базой данных;
Потоки (Streams) – когда разные сервера обмениваются информацией об изменениях друг с другом;
Dataguard — когда основная база обновляет состояние вспомогательной.
Используя комбинации этих архитектур, можно добиться работы системы 365/24/7 без каких либо потерь данных с неограниченными возможностями масштабирования и производительности.
Real Application Cluster (RAC)
RAC предоствляет поразительные возможности для увеличения производительности, отказоустойчивости и масштабирования и является частью концепции сетевой инфраструктуры Oracle (Grid). Раньше RAC (и его предшественник Oracle Parallel Server) был отдельной дорогой надстройкой, но начиная с версии 10 g, RAC доступен с лицензией Standard Edition. Это показывает насколько сильно Oracle хочет популяризировать данную технологию. Standard Edition RAC имеет ограничения к количеству серверов и используемых ядер, но даже с этими ограничениями это достаточно мощная среда. Enterprise лицензия доступна за отдельную плата, но она предоставляет возможности, ограниченные только операционной системой и физическими характеристиками серверов.
Архитектура RAC может быть сконфигурирована таким образом, чтоб обеспечить 100 % доступность базы данных. Один экземпляр данных можно выключить (напирмер для ремонтных работ), а база данных будет доступна за счёт других экземпляров работающих на других серверах. Пользовательские сессии с выключенного экземпляра будут распределены между остальными инстансами без каких-либо неудобств для пользователей.
Прозрачная масштабируемость даёт возможность добавлять экземпляры, работающие на разных серверах динамически. Они будут автоматически забирать часть нагрузки с других экземпляров БД.
Некоторые приложения определенно выиграют при переходе на RAC архитектуру. Параллельное выполнение улучшает производительность определённых задач, таких как длительные запросы или большие обновления данных. В single-instance архитектуре включение механизма параллельного выполнения поможет, но все запросы будут работать на одном экземпляре на одном сервере. В RAC – параллельное выполнение будет работать на разных машинах, что может позволить обойти некоторые узкие места присущие архитектуре single-instance. Другие задачи, такие как обработка большого количества небольших атомарных операций (transaction), присущие OLTP системам, не получат преимуществ при переходе на RAC.
Streams
Существует много обстоятельств, которые делают нужным передачу данных из одной базы данных в другую. Одна из причин для этого – это отказоустойчивость. Она может быть достигнута таким образом: если имеются 2 или более географически разделённых серверов, содержащих одни и те же данные и доступные для работы, тогда не важно что случится с одним из них, работа может продолжаться на других. Другая причина – разделение задач. К примеру одна база может быть сконфигурирована под OLTP систему, а вторая под хранилище данных.
Задачи синхронизации баз данных должна происходить полностью автоматически, и все изменения из в базах данных должны быть переданы в режиме реального (или около реального) на другие базы данных. Для хранилищ данных данные из OLTP систем должны быть переданы в базу данных хранилища и впоследствии периодически обновляться. Потом данные передаются дальше, возможно в витрины данных, каждая из которых работает с хранилищем данных. Потоки – это возможность сбора изменений, произошедших с таблицей и затем применения этих изменения на удалённые копии таблиц.
Потоки могут быть двунаправленными: одинаковые таблицы с двух или более серверов и все атомарные операции пользователей по изменению данных применяются на всех серверах. Эта модель используется для обеспечения отказоустойчивости. Другая модель использования – для предоставления данных в хранилище, как описано выше. В такой модели поток поднонаправленные, и структуры таблиц могут быть не одинаковы.
Dataguard
Механизм Dataguard использует одну базу данных как главную, в которой производятся изменения и одну или несколько баз данных как вспомогательные для обеспечения отказоустойчивости или для выполнения запросов. Вспомогательные сервера создаются из резервной копии главного сервера и все изменения с главного сервера применяются к вспомогательным (возможно в режиме реального времени).
Вспомогательные сервера бывают двух видов. Физический тип – это побитовая копия основной машина и основная цель такого вспомогательного сервера – обеспечение отсутствия потерь данных. Даже если главные сервер будет полностью разрушен – вся информация доступна на вспомогательном сервере. Изменения с главного сервера передаются на вспомогательный в форме записей изменений (redo records) и происходит процесс применения этихз ихменений, схожий с восстановлением из резервной копии и записью файла изменений. Логический вспомогательный сервер содержит те же данные что и главный, но с возможными различиями в структуре данных, к примеру для обеспечения быстродействия при выполнения запросов. На главном сервере могуть быть созданы индексы (для обеспечения быстродействия OLTP системы), а на вспомогательном индексы будут отсутствовать, для обеспечения быстрого выполнения задач типичных для хранилищ данных. Изменения в таком случае передаются в форме SQL команд используя механизм потоков.