Максим Чалышев - Oracle SQL. 100 шагов от новичка до профессионала

На прошлом шаге мы создали таблицу MAN5.

В одном окне выполним следующие команды:

Напишем запрос:

Запрос вернул 3 строки.

Теперь перейдем во второе окно.

Напишем запрос:

Очистим нашу таблицу с помощью команды DELETE.

Рассмотрим, как работает режим SERIALIZABLE;

Во втором окне задействуем режим изоляции данных SERIALIZABLE.

ALTER SESSION SET ISOLATION_LEVEL=SERIALIZABLE;

В первом окне:

Запрос возвращает 7 строк.

Во втором окне, там, где включен режим (уровень изоляции) SERIALIZABLE, пишем запрос:

Запрос возвращает 3 строки.

В первом окне пишем команду удаления данных:

Данный запрос возвращает нам пустое множество.

Переходим в окно, где используется уровень изоляции SERIALIZABLE.

По-прежнему возвращает 3 строки.

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

Для чего используется на практике уровень изоляции SERIALIZABLE?

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

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

При работе с уровнем я получаю ошибку ORA-8177, почему так происходит и как избежать данной ошибки?

Данная ошибка возникает при изменении данных одной таблицы разными сессиями в режиме SERIALIZABLE.

Уровень изоляции SERIALIZABLE захватывает слот в списке заинтересованных транзакций. Если ORACLE-слот недоступен, то возникает ошибка ORA-8177. Доступные слоты ITL контролируются параметрами INITRANS и MAXTRANS, которые задаются при создании таблицы.

Попробуйте увеличить параметры INITRANS и MAXTRANS и пересоздать таблицы, с которыми работает сессия SERIALIZABLE.

Другие СУБД поддерживают уровень изоляции SERIALIZABLE?

MS SQL поддерживает данный уровень изоляции, MYSQL, PostgreSQL поддерживают в ограниченном режиме, этот момент необходимо уточнить в документации к этим СУБД.

Какие еще бывают уровни изоляции?

Использую материал из Википедии.

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

READ COMMITTED (чтение фиксированных данных). Большинство промышленных СУБД, в частности Microsoft SQL Server, PostgreSQL и ORACLE, по умолчанию используют именно этот уровень. На этом уровне обеспечивается защита от чернового, «грязного» чтения, тем не менее в процессе работы одной транзакции другая может быть успешно завершена и сделанные ею изменения зафиксированы. В итоге первая транзакция будет работать с другим набором данных.

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

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

Материализованные представления используются при построении отчетности и позволяют ускорить построение отчетов с помощью запросов SQL в несколько десятков раз, позволяя за считаные секунды оперировать миллионами записей.

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

Материализованные представления появились в арсенале средств управления данными в базе данных ORACLE, начиная с ORACLE 8i. До этого подобные специальные конструкции назывались SNAPHSHOT. В материализованных представлениях предварительно вычисляются и сохраняются результаты запроса к базе данных, в этом запросе при желании могут быть использованы соединения, агрегирования, результаты сложных математических расчетов.

Создание материализованного представления.

Синтаксис:

Рассмотрим некоторые важные конструкции оператора CREATE MATERIALIZED VIEW.

BUILD OPTION может принимать следующие значения:

• BUILD IMMEDIATE позволяет сразу заполнить материализованное представление данными из запроса; значение по умолчанию;

• BUILD DEFERRED разрешает загрузить данные в материализованное представление позднее, в указанное время.

REFRESH OPTION

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

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

ENABLE QUERY REWRITE показывает оптимизатору ORACLE переписать все запросы с использованием материализованных представлений вместо лежащих в основе представления таблиц.

AS SELECT * FROM — запроc, на основании которого строится материализованное представление.

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