атомарные операции - это операции которые выполняются без прерывания потока.




управление памятью

Когда запускается база данных, в оперативной памяти распределяется область SGA и запускаются фоновые процессы. Совокупность этих процессов и областей оперативной памяти называется экземпляром базы данных Oracle.

процессы

Процесс - это «канал управления», механизм в операционной системе, который выполняет определенную последовательность действий.

В общем, в Oracle имеетcя два типа процессов: пользовательские процессы и процессы Oracle.

запуск и остановка экземпляра

Для запуска базы данных или инстанции(экземпляр) используйте либо диалоговое окно Start Up Instance, либо команду STARTUP (после того, как соединитесь с ORACLE как INTERNAL). Вы можете запустить экземпляр и базу данных различными способами:

запустить экземпляр без монтирования базы данных

запустить экземпляр и смонтировать базу данных, но оставить ее закрытой

запустить экземпляр, смонтировать и открыть базу данных в одном из следующих режимов:

неограниченном режиме (доступна всем пользователям)

ограниченном режиме RESTRICTED (доступна только АБД)

Кроме того, вы можете форсировать запуск экземпляра, либо заставить экземпляр начать немедленно после запуска полное восстановление носителя.

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

Вы также должны подключиться как INTERNAL. Это условие обязательно, независимо от того, используете ли вы графический интерфейс SQL*DBA или команды SQL.

использование оперативной памяти (SGA, PGA, состав, назначение)

Глобальная область системы (SGA) - это область разделяемой памяти, занимаемая Oracle в оперативной памяти, которая содержит данные и управляющую информацию для одного экземпляра Oracle. SGA распределяется при запуске экземпляра и освобождается при его закрытии. Каждая экземпляр имеет свою собственную область SGA. Данные в SGA совместно используются всеми пользователями, работающими с базой данных. Размер SGA должен быть максимально большим, чтобы держать как можно больше данных в памяти и минимизировать дисковые операции. Информация, хранящаяся в SGA, подразделяется на несколько типов структур памяти, включая буфера базы данных, буфера журнала повторения и разделяемый пул. Эти области имеют фиксированные размеры и создаются при запуске экземпляра

Глобальная область программы (Program Global Area) - это буфер памяти, содержащий данные и управляющую информацию для процесса сервера. PGA создается Oracle при запуске серверных процессов. Информация в области PGA зависит от конфигурации Oracle.

 

Shared pool (разделяемый пул)

Разделяемый пул (Shared Pool) - это часть SGA, содержащая разделяемые области SQL.

database buffer cache (буферный кэш)

В Буферном кэше базы данных (Database Buffer Cache) базы данных в SGA находятся недавно использовавшиеся блоки данных. Также там могут находиться модифицированные данные, которые еще не записаны на диск для постоянного хранения. Поскольку последние использовавшиеся (в том числе и наиболее часто использующиеся) данные находятся в памяти, требуется меньше дисковых операций при работе и, как следствие, увеличивается производительность.

redo log buffer (буфер журналов повторения)

Буфер журнала повторения (Redo Log Buffer) повторения хранит в SGA журнал изменений, осуществленных в базе данных. Затем эти данные переносятся из буферов, в файл журнала повторения.

library cache (библиотечный кэш)

dictionary cache (кэш словаря данных)

использование памяти в Shared pool-е

Разделяемая область SQL используется для обработки предложения SQL. Здесь сохраняется «дерево разбора» и план исполнения каждого SQL предложения.

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

База данных разделяется на логические единицы хранения, называемые Табличными пространствами. Табличное пространство служит для того, чтобы группировать вместе объекты схем базы данных. Например, в табличном пространстве обычно группируются все объекты приложения, чтобы упростить некоторые административные операции.

 

- табличное пространство SYSTEM

Каждая база данных ORACLE содержит табличное пространство SYSTEM, которое создается автоматически при создании базы данных. Табличное пространство SYSTEM всегда содержит таблицы словаря данных для всей базы данных. Небольшой базе данных может оказаться достаточным одного табличного пространства SYSTEM; однако рекомендуется создать по меньшей мере одно дополнительное пространство, чтобы хранить данные пользователей отдельно от информации словаря данных. Это позволит более гибко осуществлять разнообразные операции администрирования.

- табличное пространство отката (UNDO,ROLLBACK)

ТП отката: если, например, в таблицу ввести 1000 строк, открывается транзакция; пока всё это грузится, система сохраняет предыдущее состояние. 1000 строк попадают в ТП отката – вдруг транзакцию отменим.

- временное табличное пространство (temporary tablespace)

Временные ТП нужны для операций по ссылочной целостности и для сортировок.

- использование нескольких табличных пространств

-табличные пространства в состоянии online и offline

Табличное пространство может быть доступным (состояние online) или недоступным (состояние offline). Обычно табличное пространство находится в состоянии online, и пользователи имеют доступ к информации в нем.

- когда табличное пространство находится в состоянии offline

Может понадобиться перевод табличного пространства в офлайн по одной из следующих причин:

 

○ чтобы сделать часть базы данных недоступной, сохраняя в то же время нормальный доступ к остальной части

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

○ чтобы сделать приложение вместе с его группой таблиц временно недоступным на время обновления или сопровождения этого приложения

○ Когда табличное пространство переводится в офлайн, ORACLE не позволяет последующим предложениям SQL обращаться к объектам этого табличного пространства.

○ Табличное пространство не может быть переведено в офлайн, если оно содержит активные сегменты отката. Табличное пространство может быть переведено в офлайн лишь в том случае, если все сегменты отката, содержащиеся в нем, не используются.

 

3) Файлы данных

Каждая база данных Oracle имеет один или более файлов данных. В них хранятся данные логических структур БД, таких как таблицы и индексы.

Файлы данных имеют следующие особенности:

· Файл данных может быть ассоциирован лишь с одной базой данных.

· Файл данных, при необходимости, может автоматически увеличиваться в размере.

· Один или несколько файлов данных формируют табличное пространство.

Файлы журнала повторения

Каждая база данных Oracle имеет набор из двух или более файлов журнала повторения. Основная функция журнала повторения (redo log) - регистрация всех изменений, осуществляемых в данных. Все изменения, выполняемые в базе данных, записываются в журнал повторения. Если в результате сбоя модифицированные данные не были записаны в файлы данных, эти изменения можно получить из журнала повторения.

Для работы, обязательно требуется наличие как минимум двух файлов журнала повторения.

 

4)Управляющие файлы.

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

- имя базы данных

- имена и местоположения файлов данных и файлов журнала повторения этой базы данных

- отметку времени создания базы данных

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

Управляющий файл базы данных используется также в тех случаях, когда требуется восстановление базы данных.

 

5) Базовые схемы

Схема (SCHEMA) — является одним из основных объектов базы данных Oracle.

В Oracle она привязывается только к одному пользователю (USER) и является логическим набором объектов базы данных. Схема создается при создании пользователем первого объекта, и все последующие объекты созданные этим пользователем становятся частью этой схемы.

 

 

4. Блоки данных, экстенты и сегменты.

В СУБД Oracle контроль над дисковым пространством происходит с использованием специальных логических структур. Эти структуры следующие:

● блоки данных - Это наименьшая единица хранения данных в БД Oracle. Блок БД содержит заголовочную информацию о себе, и данные.

● экстенты - Экстент состоит из блоков данных.

● сегменты - Сегмент состоит из совокупности экстентов, содержащих определенный вид данных.

Сегменты

БД Oracle использует четыре типа сегментов:

1. сегмент данных - хранит пользовательские данные.

2. индексный сегмент - содержит индексы.

3. сегмент отката - хранит информацию отката, используемую при возврате к предыдущему состоянию БД.

4. временный (промежуточный) сегмент - создается в случае, если для выполнения SQL-выражения необходимо дополнительное рабочее пространство. Эти сегменты уничтожаются сразу после выполнения SQL-команд. Промежуточные сегменты используются также в разнообразных операциях с БД, например, при сортировке.

 

Экстенты

Экстенты являются строительными блоками сегментов, и, в тоже время, состоят из блоков данных. Экстенты используются для минимизации неиспользуемого (пустого) пространства хранилища. По мере увеличения количества данных в табличных пространствах, экстенты используются для хранения тех данных, которые могут разрастаться. Таким образом, несколько табличных пространств могут делить между собой пространство хранилища без предопределения разделов этих табличных пространств.

При создании табличного пространства, Вы можете указать минимальное число определения экстент, а также число экстент, добавляемых при заполнении уже определенных. Это распределение позволяет вам контролировать пространство хранилища БД.

 

Блоки данных

Это наименьшие единицы БД Oracle. Они физически хранятся на диске. Блоки данных на большинстве систем 2Кб (2048 байт), но Вы можете изменить этот размер на свое усмотрение для увеличения эффективности работы системы.

 

5. Структуры памяти и процессы.

 

Процессы

Механизмы ORACLE работают через использование структур памяти и процессов. Все структуры памяти располагаются в основной памяти (иногда называемой виртуальной памятью или памятью произвольного доступа) компьютеров, составляющих систему базы данных.

 

ПРОЦЕССЫ (PROCESS) - это задания или задачи, работающие в памяти этих компьютеров. ПРОЦЕСС - это "канал управления", или механизм в операционной системе, способный выполнять последовательность шагов.. Процесс обычно имеет свою собственную личную область памяти, в которой он выполняется. (V$PROCESS - информация об активных и V$BGPROCESS – информация о фоновых процессах)

 

В экземпляре Oracle существуют три обширных класса процессов:

• Серверные процессы. Эти процессы выполняют свои задачи в зависимости от запроса клиента. Мы уже до определенной степени ознакомились с выделенным и разделяемым сервером. Они относятся к серверным процессам.

 

• Фоновые процессы. Эти процессы запускаются при запуске базы данных и выполняют различные служебные задачи, такие как запись блоков на диски, поддержание оперативных журналов повторения, очистка после прерванных процессов,

обслуживание AWR (Automatic Workload Repository — автоматический репозиторий рабочей нагрузки) и т.п.

 

• Подчиненные процессы. Эти процессы аналогичны фоновым, но выполняют дополнительную работу от имени либо фонового, либо серверного процесса.

 

Серверные процессы:

Серверные процессы — это процессы, которые выполняют действия от имени сеанса клиента. Эти процессы обязательно принимают и реагируют на SQL-операторы, которые наши приложения отправляют базе данных.

 

есть 2 типа подключений к ORACLE:

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

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

 

Процессы как выделенного, так и разделяемого сервера решают одну и ту же задачу: они обрабатывают все передаваемые им SQL-запросы. При передаче базе данных запроса SELECT * FROM EMP процесс выделенного/разделяемого сервера осуществляет синтаксический разбор запроса и помещает его в разделяемый пул (или находит его в разделяемом пуле, если он уже там присутствует). При необходимости процесс создает план запроса и выполняет его, возможно отыскивая необходимые данные в буферном кэше или считывая данные с диска в буферный кэш. Серверные процессы проделывают всю “черную” работу. Во многих случаях именно они являются в системе основными потребителями ресурсов процессора системы, поскольку они выполняют сортировку, суммирование и соединение — практически, все необходимые действия.

 

Фоновые процессы

Экземпляр Oracle образован двумя компонентами: памятью SGA и фоновыми процессами. Фоновые процессы выполняют рутинные задачи по обслуживанию, необходимые для поддержания базы данных в рабочем состоянии. Например, существует процесс, который обслуживает кэш буферов блоков, по мере необходимости записывая блоки в файлы данных. Другой процесс отвечает за копирование файла оперативного журнала повторения при его заполнении в каталог архива. Еще один процесс выполняет очистку за прерванными процессами и т.д. Каждый из этих процессов в достаточной степени специализирован для решения своей задачи, но работает с учетом всех остальных процессов. Например, когда процесс, отвечающий за запись журнальных файлов, заполнит один журнал и перейдет к следующему, он сообщит процессу, отвечающему за архивирование заполненного журнального файла, о наличии задачи, которую нужно выполнить.

 

Существуют два класса фоновых процессов: специализированные для выполнения конкретных задач (подобные описанным) и предназначенные для выполнения ряда других задач (служебные процессы - Эти фоновые процессы создаются исключительно по необходимости. Они предоставляют функциональные возможности, которые не требуются в повседневной работе базы данных, если только администратор сам не прибегнет к ним, например, создав очередь заданий, или не применит использующую их функцию, такую как новые диагностические возможности Oracle).

 

Когда вызывается прикладная программа или инструментальное средство, например, Enterprise Manager, Oracle создает серверный процесс для выполнения команд, порождаемых приложением.

Кроме того, Oracle создает набор фоновых процессов для экземпляра. Эти процессы взаимодействуют друг с другом и с операционной системой. Они управляют структурами памяти, записывают информацию на диск в асинхронном режиме ввода/вывода и выполняют общесистемные служебные действия.

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

 

Наиболее общие процессы следующие:

● Системный монитор (System monitor – SMON); выполняет восстановление после отказа экземпляра при старте экземпляра.

● Монитор процессов (Process monitor – PMON); выполняет очистку после аварийного завершения пользовательского процесса.

● Процесс записи в БД (Database writer – DBWn); пишет модифицированные блоки из кэша буферов БД в файлы на диск.

● Процесс контрольной точки (Checkpoint – CKPT); сигнализирует DBWn о контрольной точке и изменяет все файлы данных и управляющие файлы, внося в них информацию о самой последней контрольной точке.

● Процесс записи в журнал (Log writer – LGWR); пишет журнальные записи на диск.

● Архиватор (Archiver – ARCn); копирует файлы оперативного журнала в архив после заполнения оперативных журнальных файлов или после выполнения переключения журнала.

 

Выполнив select paddr, name, description from v$bgprocess, мы увидим фоновые процессы для экземпляра.

Подчиненные процессы

Существуют два типа подчиненных процессов Oracle: подчиненные процессы ввода-вывода и подчиненные процессы параллельных запросов.

 

Подчиненные процессы ввода-вывода:

Подчиненные процессы ввода-вывода служат для эмуляции асинхронного ввода-вывода для тех систем или устройств, которые его не поддерживают. Например, лентопротяжные устройства (которые славятся медленной работой) не поддерживают асинхронный ввод-вывод. Используя подчиненные процессы ввода-вывода, для лентопротяжных

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

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

 

подчиненные процессы параллельных запросов:

Она позволяет создавать для SQL-оператора, такого как SELECT, CREATE TABLE, CREATE INDEX, UPDATE и т.п., план выполнения, состоящий из множества планов выполнения, которые могут быть сделаны одновременно. Результаты выполнения всех этих планов объединяются в один общий результат. Цель такого подхода — сокращение времени выполнения операции по сравнению с последовательным ее выполнением. Например, предположим, что существует действительно большая таблица, распределенная по десяти различным файлам. Предположим также, что в нашем рас-

поряжении имеется 16 процессоров и нужно выполнить какой-либо особый запрос этой таблицы. Вероятно, имеет смысл разбить план выполнения на 32 небольших фрагмента и действительно в полной мере задействовать вычислительные возможности компьютера, вместо того чтобы применять только один процесс для последовательного чтения и обработки всех данных.

При использовании параллельного запроса создаются процессы Pnnn — это собственно серверы выполнения параллельного запроса. Во время обработки параллельного оператора серверный процесс известен под названием координатора параллельного запроса. Его название не изменяется на уровне операционной системы, но в документации по параллельным запросам он упоминается именно так.

 

Структуры памяти

ORACLE создает и использует свои структуры памяти для выполнения некоторых задач. Например, память используется для размещения исполняемого программного кода и данных, разделяемых между пользователями. С ORACLE ассоциируются несколько базовых структур памяти:

глобальная область системы (System Global Area– SGA, разделяемая всеми серверными и фоновыми процессами, также содержаться в которой содержатся данные и управляющая информация экземпляра)

глобальные области программ (Программная глобальная область - Program Global Area – PGA, частная для каждого серверного и фонового процесса; для каждого процесса выделяется одна PGA).

Глобальная область системы (SGA)

SGA содержит следующие структуры данных:

 

Кэш буферов БД (Database buffer cache) - для блоков данных выбираемых из БД.

Журнальный буфер (Redo log buffer) - для кэширования информации повторного выполнения (используемой при восстановлении экземпляра) до момента их записи в журнальные файлы.

Разделяемый пул (Shared pool) - для кэширования различных структур, которые могут совместно использоваться пользователями.

Большой пул (Large pool) – необязательная область, в которой отводится память для буферов, требуемых большими операциями ввода/вывода.

Java-пул, используемый для Java-кода сеансов и данных внутри виртуальной Java-машины (Java Virtual Machine – JVM).

 

При запуске экземпляра с помощью Enterprise Manager или SQL*Plus выводится информация о памяти, выделенной для SGA. В рамках динамической инфраструктуры SGA можно без остановки экземпляра менять размеры кэша буферов БД, разделяемого пула, большого пула, Java-пула и пула потоков.

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

Oracle позволяет выдавать сигнальные сообщения (alerts) для своевременного определения проблем, связанных с размером структур памяти, и содержит советчики (advisors), которые помогают установить подходящие значения для параметров.

 

Программная глобальная область (PGA)

Это область памяти, выделяемая для каждого серверного процесса, содержащая данные и управляющую информацию этого процесса. Серверный процесс – это процесс, который обрабатывает запросы клиента. Каждый серверный процесс имеет свою приватную область PGA, которая создается при старте серверного процесса. Доступ к этой области имеет только этот серверные процесс, чтения и запись в эту область выполнятся через код Oracle, вызываемый из этого серверного процесса.

Совокупный размер памяти, выделяемый под области PGA и их содержимое, зависит от того, сконфигурирован ли в экземпляре режим разделяемого сервера.

 

Обычно PGA содержит:

● Приватную область SQL (Private SQL area), в которой находятся информация привязки и структуры памяти, создаваемые при выполнении команд. Каждый сеанс, в котором выполняется команда SQL, имеет приватную область SQL.

● Память сеанса (Session memory), выделяемая для обработки переменных сеанса и другой связанной с сеансом информацией.

 

 

6. Журнал повторений, его структура.

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

 

Файлы журналов повторения транзакций

Каждая база данных ORACLE имеет набор из двух или более ФАЙЛОВ ЖУРНАЛА ПОВТОРЕНИЯ РАБОТЫ. Комплект файлов журнала повторения работы для одной базы данных совместно называется ЖУРНАЛОМ ПОВТОРЕНИЯ (redo log).

 

В базе данных как минимум должно быть не менее двух оперативных журналов повтора.

Журнал повтора часто называют журналом транзакций.

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

 

Файлы журнала повторения критичны в вопросе защиты базы данных от сбоев. Чтобы защититься от таких сбоев, которые затрагивают сам журнал повторения, ORACLE допускает ЗЕРКАЛЬНЫЙ ЖУРНАЛ ПОВТОРЕНИЯ, так что две или более копий журнала повторения можно поддерживать одновременно на разных дисках.

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

 

Процесс применения журнала повторения в процессе операции восстановления базы данных называется ПРОКРУТКОЙ ВПЕРЕД.

База данных может работать в двух режимах. В режиме ARCHIVELOG и в режиме NOARCHIVELOG, соответственно либо, создается архивная копия всех журналов транзакций, либо содержимое транзакций не сохраняется.

Для определения текущего режима работы экземпляра выдают команду archive log list, из под Server Manager. Многие аспекты процесса архивирования указаны параметрами файла INIT.ORA

Восстановление после сбоя экземпляра, с использование только журнала обновления, называется - оперативным восстановлением.

 

ЕСТЬ 2 типа файлов журнала повторения: оперативные и архивные.

 

Оперативный журнал повторения транзакций

Каждая БД имеет, по меньшей мере, 2 группы файлов оперативных журналов повторений. Каждая группа состоит из одного или нескольких элементов, причем отдельные элементы являются точными копиями (зеркальными образами) друг друга. Файлы фиксируются по размеру и используются поочередно.

 

СУБД записывает в группу 1, а когда дойдет до до конца, перейдет к группе 2, закончив в группе 2 она опять вернется к группе один и перепишет содержимое. (если 3 группы - то она по кругу будет по 3-м ходить и т.п.)

 

Переход от одной группы журнальных файлов к другой называется переключением журнальных файлов. бывает, то этот переход вызывает “паузу” - СУБД делает создание контрольной точки.

 

Как раз и есть задача АБД определить размеры журналов повторения, чтобы системе, к примеру, не приходилось дожидаться завершения создания контрольных точек(*чтобы “пробки” не возникали) во время пиковых нагрузок.

Не существует никакого правильного размера журнала повторений, но требуется чтобы они были достаточно большими для данной конкретной нагрузки.

 

Архивный журнал повторения транзакций

Том Кайт говорит: “Сохранение данных и обеспечение невозможности их потери - это первоочередная задача АДБ”

 

БД работает в одном из 2 режимов: ARCHIVELOG и NOARCHIVELOG. том кайт заверяет что нужно работать чаще всегов режиме ARCHIVELOG. Т.к. если данные сгорели(жесткий диск накрыло нахер), а вы делаил бэкап раз в неделю, то найдя другой диск, восстановили бы всю резервную копию с прошлого бэкапа, применя архивные журнальные файлы и оперативные журнальные файлы - ДАННЫЕ НИКАКИЕ НЕ ТЕРЯЮТСЯ!

Восстановление идет на момент отказа диска.

 

NOARCHIVELOG пашет быстрее, но данные не в сохранности.

 

7. Транзакции, различные виды SQL-предложений (понятие транзакции, автономные транзакции, управление транзакциями, COMMIT и ROLLBACK, анонимные блоки, процедуры, функции, пакеты в СУБД Oracle).

 

Транзакция является единственной единицей работы. Если транзакция выполнена успешно, все модификации данных, сделанные в течение транзакции, принимаются и становятся постоянной частью базы данных. Если в результате выполнения транзакции происходят ошибки и должна быть произведена отмена или выполнен откат, все модификации данных будут отменены.

В ORACLE нет явного оператора, чтобы начать транзакцию, но и нет автоматического завершения транзакции. Транзакция автоматически начинается с первого оператора, который начал изменения. Заканчивается явным оператором окончания транзакции.

 

автокоммит - автоматической режим фиксации изменений

устнаовка:

SET AUTOCOMMIT ON;

 

Блокировками (locks) называются механизмы, применяемые для управления параллельными изменениями данных. Блокировки используются для приостановки выполнения одних SQL-операторов, пока выполняются другие.

 

Автономные транзакции - Автономные транзакции можно еще назвать вложенными транзакциями. Автономные транзакции позволяют вам создать “транзакцию внутри транзакции”, которая зафиксирует или выполнит откат изменений, независимо от родительской транзакции. Они позволяют вам приостановить текущую выполняемую транзакцию, запустить новую, проделать некоторую работу и зафиксировать или откатить ее — все это не затрагивая состояния текущей выполняемой транзакции.

 

 

Создадим процедуру с автономной транзакцией:

create or replace procedure AT_P

as

pragma autonomous_transaction;

begin

insert into table1 ('Autonom');

commit;

end;

 

 

Пример:

Мы выполняем в анонимном блоке insert into table1 values (‘1’);

После чего выполняем процедуру с автономной транзакцией AT_P;

И производим rallback;

 

Внешняя транзакция откатилась и значения ‘1’ не попало в таблицу, а значение 'Autonom' попало, т.к. это была внутренняя транзакция.

 

Если бы мы не писали pragma autonomous_transaction;, то ничего бы не откатилось, commit зафиксировал бы оба оператора.

 

 

Операторы управления транзакциями:

● COMMIT

● ROLLBACK

● SAVEPOINT

● ROLLBACK TO

● SET TRANSACTION

 

Подробности по каждому оператору:

● COMMIT.

Оператор COMMIT завершает транзакцию и делает любые выполненные в ней изменения постоянными. Освобождаются блокировки.

 

● ROLLBACK.

Оператор отката завершает транзакцию и отменяет все выполненные в ней и незафиксированные изменения. Для этого он читает информацию из сегментов отката и восстанавливает блоки данных в состояние, в котором они находились до начала транзакции. Освобождаются блокировки.

 

По завершении транзакции необходимо явно указывать одну из команд завершения транзакции иначе за вас это сделает среда, в которой вы работаете (а среда не всегда это делает так, как вы предполагаете).

 

● SAVEPOINT <точка сохранения>.

Позволяет создать в транзакции точку сохранения. В одной транзакции можно выполнять оператор SAVEPOINT несколько раз, устанавливая несколько точек сохранения. Точки сохранения позволяют устанавливать маркеры внутри транзакции таким образом, чтобы была возможность отмены только части работы, проделанной в транзакции. Оправдано использование точек сохранения в продолжительных и сложных транзакциях. ORACLE освобождает блокировки, которые были установлены отменённым оператором.

Неявные точки сохранения Перед выполнением каждого предложения INSERT, UPDATE и DELETE ORACLE создает неявную точку сохранения (недоступную вам). Если предложение сбивается, то выполняется откат к этой неявной точке. Обычно отменяется лишь сбившееся предложение SQL, а не вся транзакция.

 

 

● ROLLBACK TO <точка сохранения>.

Этот оператор используется совместно с оператором SAVEPOINT. Транзакцию можно откатить до указанной точки сохранения, не отменяя все сделанные до нее изменения. Таким образом, можно выполнить два оператора UPDATE, затем — оператор SAVEPOINT, а после него — два оператора DELETE. При возникновении ошибки или исключительной ситуации в ходе выполнения операторов DELETE транзакция будет откатываться до указанной оператором SAVEPOINT точки сохранения; при этом будут отменяться операторы DELETE, но не операторы UPDATE.

 

● SET TRANSACTION.

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

 

По дефолту режимом для всех транзакций является согласованность данных по чтению НА УРОВНЕ ОПЕРАЦИИ. Т.е. запрос видит лишь то состояние данных, которое было перед началом его выполнения, плюс все изменения, которые внесены предыдущими операциями в текущей транзакции. Если во время запроса другие пользователи (транзакции) вносят изменения в эти же таблицы базы данных, то эти изменения будут видны лишь последующим, но не текущему, запросу.

 

Синтаксис:

 

SET TRANSACTION

{ ISOLATION LEVEL { READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE }

 

| { READ ONLY | READ WRITE }

 

| { DIAGNOSTICS SIZE count_message }

};

 

 

- ISOLATION LEVEL указывает устанавливаемый уровень изоляции

 

- READ ONLY устанавливает режим, при котором разрешается только чтение. Этот режим устанавливается по умолчанию, если уровень изоляции определен как READ UNCOMMITTED. (При режиме READ ONLY на данные не устанавливается никаких блокировок.)

 

Пользователь может начать такую транзакцию при помощи оператора set transaction read only и закончить оператором commit/rollback

Внутри такой транзакции можно употреблять только операторы select, операторы DML недопустимы. При обращении операторов select из различных частей транзакции к одним и тем же строкам данных Oracle выдает либо одинаковые непротиворечивые данные, находившиеся в БД на момент начала транзакции (set transaction read only), либо ошибку ORA-1555.

 

- READ WRITE устанавливает режим, который разрешает как чтение, так и запись данных. При этом режиме уровень изоляции не может быть установлен как READ UNCOMMITTED. (Режим READ WRITE устанавливается по умолчанию для любого уровня, отличного от READ UNCOMMITTED.)

 

set transaction read write синоним set transaction isolation level read committed

 

Транзакция по умолчанию является транзакцией этого типа. Перед началом любой транзакции по умолчанию неявно выполняется оператор set transaction read write.

Если два оператора select в разных частях транзакции этого типа обращаются к одним и тем же строкам в таблице БД, то возможно получение различных (противоречивых) результатов. Противоречие возникнет в том случае, если какой-либо пользователь модифицировал и зафиксировал изменения этих строк на интервале времени между двумя вышеупомянутыми операторами select. То есть в рамках одной транзакции возможно чтение данных, модифицированных и зафиксированных (committed) другими пользователями.

 

- SERIALIZABLE

Сериализуемая транзакция.

set transaction isolation level serializable

 

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

 

- Фраза DIAGNOSTICS SIZE определяет размер области, используемой для записи диагностических сообщений, доступ к которым осуществляется оператором GET DIAGNOSTICS.

 

Некоторые особенности выполнения транзакций в ORACLE:



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-02-16 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: