Что такое автономная транзакция oracle

Обновлено: 04.07.2024

Oracle Autonomous Transaction Processing is a cloud database service that eliminates the complexity of operating and securing high-performance databases. The service automates provisioning, configuring, tuning, scaling, patching, encrypting, and repairing of databases. Additionally, the service includes all of Oracle’s advanced database options, such as real application clusters (RAC), multitenant, partitioning, in-memory, advanced security, and advanced compression. The service is built to support everything from simple web apps to large and sophisticated applications that are critical for business operation. Autonomous Transaction Processing service is available in both the Oracle public cloud and your own data center on Exadata Cloud@Customer.

Autonomous Transaction Processing ranks highest in all four categories in the 2020 Gartner Critical Capabilities for Cloud Database Management Systems for Operational Use Cases report.

Move to Oracle Autonomous Transaction Processing, from On-premises Oracle Database Standard Edition, at lower cost and 5x performance

After evaluating multiple cloud providers, NEC Nexsolutions migrated to fully isolated, private database cloud using Dedicated infrastructure with minimal application modification.

Wikibon compares Amazon RDS vs. Oracle Autonomous Transaction Processing

Wikibon finds Autonomous Transaction Processing can improve the database price-performance by 2X and reduce the downtime costs by 2.5-5X when compared with AWS and other cloud alternatives.

Autonomous Transaction Processing features

Autonomous operations

Auto-provisioning

Deploys fault-tolerant and highly available databases in minutes.

Auto-scaling

Scales compute resources automatically to meet performance and throughput requirements without any downtime. Enables true pay-per-use experience with online dynamic scaling.

Auto-tuning

Configures and tunes databases automatically even as data and schema change over time. The memory configuration, data formats, indexes, and access structures are automatically optimized to improve performance.

Automated backups

Performs weekly full and daily incremental backups of the database in Oracle’s object storage and retains them for up to 60 days to restore and recover to any point in time.

Auto-repairing

Fixes hardware and software faults by continuously monitoring and predicting failures. Requests are immediately redirected to healthy devices, maintaining database performance.

Auto-failover

Eliminates site downtime by maintaining a real-time remote copy of a production database and automatically switching from primary to remote copy using Autonomous Data Guard.

Simplified application development

Support for relational and nonrelational data models

Natively supports multiple data types including document, graph, spatial, JSON, XML, and more for faster application development. Prevents data fragmentation and reduces data management hassles resulting from siloed data stores.

REST API support for modern application development

Provides database management REST APIs, web interface, and PL/SQL Gateway to REST-enable all your data for simpler and faster access.

No-code/Low-code development

Oracle’s low-code application development platform, APEX, is built into Autonomous Transaction Processing and eliminates 98% of hand coding. APEX empowers developers to rapidly build sophisticated applications.

In-database machine learning (ML) algorithms

Provides more than 30 ML algorithms, automated ML functions, and integration with open source Python and R to make it easy to build ML models and analytical dashboards without moving data out of the database.

Self-service tools for API-driven development

Built-in data tools provide self-service data loading, data transformations, and business models, making it easy to load any data, run complex queries across multiple data types, build sophisticated analytical models, visualize information, deliver insights, and ease development of data-driven applications.

Fast cloning

Create fast clones of the entire database or just the metadata, to quickly get started on new projects. Create clones from running database instances or a backup database.

Interoperability with Microsoft Azure

Provides fully supported, multicloud solutions with fast interconnections to Microsoft Azure.

Complete data protection and security

Always-on encryption

Provides automatic encryption for the entire database and for backups with encryption keys that you create and control. This ensures the data is always secure at rest and in motion.

Auto-patching

Patches and upgrades databases for security vulnerabilities with zero downtime. Applications continue to run as patching occurs.

Data privacy

Enables database administrators to perform all administrative tasks without ever seeing customer data. Blocks access to OS or admin privileges to prevent phishing attacks.

Security for sensitive data

Oracle Data Safe, included with Autonomous Transaction Processing, makes it easy to discover sensitive data, evaluate security risks, mask sensitive data, and implement and monitor security controls.

Advanced auditing

Logs all events with minimal impact on performance. You can monitor audits anytime for analysis, forensics, and compliance.

High performance and availability above 99.95%

High performance

Delivers 80% lower latency and more than 5X throughput than other cloud providers by utilizing database-optimized hardware, automated tuning, and indexing.

Always online

Provides more than 99.95% availability using a combination of Oracle’s Gen 2 Cloud Infrastructure, Oracle RAC, Autonomous Data Guard, and daily automatic backups.

Protection from human error

Oracle Flashback, provided with Autonomous Transaction Processing, instantly rewinds accidental changes to application schemas, protecting users from human errors. It supports recovery at all levels including row, transaction, and table—and across the entire database.

See what top industry analysts are saying about us

Wikibon finds Oracle Autonomous Database is 50% lower cost than AWS

Wikibon finds Oracle Autonomous Database is 50% lower cost than AWS

Constellation Research

Constellation Research finds Oracle Database has 32% more capacity than the largest AWS offering

dbInsight finds Oracle the first to deliver a self-driving database in both the cloud and on-premises

dbInsight finds Oracle the first to deliver a self-driving database in both the cloud and on-premises

Autonomous Transaction Processing customer successes

Learn how customers are using Oracle Autonomous Database for faster transaction processing to transform their business.

“With Oracle Autonomous Database, JASCI is revolutionizing logistics so our customers can deliver orders of an ever-expanding product line faster and successfully compete in the age of next-day shipping.”

—Craig Wilensky, CEO, JASCI Software

Autonomous Transaction Processing use cases

Migrate Custom Applications

Optimize and extend your custom and ISV applications for improved performance, availability, and security while reducing management complexity. Reduce total cost of ownership with autonomous operations.

Migrate Oracle Applications

Optimize and extend your Oracle applications such as PeopleSoft, JD Edwards, and Siebel while reducing management complexity. Get more value from your applications while reducing cost.

Build and run no-code or low-code applications with APEX

Build scalable, secure, data-driven applications with minimal coding using APEX, a low-code development tool that is built into Autonomous Transaction Processing.

Build and run cloud native applications

Build microservice applications that utilize multiple database models and separate database containers while maintaining a common security, performance, and availability model.

Deploy mission-critical applications with autonomous services in your data center

Provide secure, governed, and high-performance self-service databases, while IT controls the budgeting, capacity planning, availability, security, and governance of data.

Build real-time mixed workload applications with large-scale IoT data

Deliver billions of inserts and retrievals a second with powerful analytics for key-value transactions such as IoT data, without the operational complexity of single-purpose databases.

Autonomous Transaction Processing pricing

Autonomous Transaction Processing on Shared Infrastructure

Oracle Autonomous Transaction Processing - Exadata Storage

Autonomous Transaction Processing on Dedicated Infrastructure

Oracle Autonomous Transaction Processing - Dedicated Oracle Cloud Infrastructure - Database Exadata Infrastructure - Quarter Rack - X8M Oracle Cloud Infrastructure - Database Exadata Infrastructure - Quarter Rack - X8 Oracle Cloud Infrastructure - Database Exadata Infrastructure - Half Rack - X8 Oracle Cloud Infrastructure - Database Exadata Infrastructure - Full Rack - X8 Oracle Cloud Infrastructure - Database Exadata Infrastructure - Quarter Rack - X7 Oracle Cloud Infrastructure - Database Exadata Infrastructure - Half Rack - X7 Oracle Cloud Infrastructure - Database Exadata Infrastructure - Full Rack - X7

Autonomous Transaction Processing Bring Your Own License (BYOL)

Oracle Autonomous Transaction Processing - Dedicated
  • If you run Oracle Database Enterprise Edition and the required options listed below, then your BYOL requirements are as follows:
  • – For 1-16 OCPUs of Oracle Autonomous Transaction Processing:
  • – For each supported Processor license of Oracle Database Enterprise Edition plus Options: Multitenant, you may activate up to 2 OCPUs of the BYOL Cloud Service.
  • – For every 25 supported Named User Plus licenses of Oracle Database Enterprise Edition plus Options: Multitenant, you may activate 1 OCPU of the BYOL Cloud Service.
  • – For 17 OCPUs or more of Oracle Autonomous Transaction Processing:
  • – For each supported Processor license of Oracle Database Enterprise Edition plus Options: Multitenant and Real Application Clusters, you may activate up to 2 OCPUs of the BYOL Cloud Service.
  • – For every 25 supported Named User Plus licenses of Oracle Database Enterprise Edition plus Options: Multitenant and Real Application Clusters, you may activate 1 OCPU of the BYOL Cloud Service.

*To make it easier to compare pricing across cloud service providers, Oracle web pages show both vCPU (virtual CPUs) prices and OCPU (Oracle CPU) prices for products with compute-based pricing. The products themselves, provisioning in the portal, billing, etc. continue to use OCPU (Oracle CPU) units. OCPUs represent physical CPU cores. Most CPU architectures, including x86, execute two threads per physical core, so 1 OCPU is the equivalent of 2 vCPUs for x86-based compute. The per-hour OCPU rate customers are billed at is therefore twice the vCPU price since they receive two vCPUs of compute power for each OCPU, unless it’s a sub-core instance such as preemptible instances. Additional details supporting the difference between OCPU vs. vCPU can be accessed here.

The future is data-driven

In today’s world, the ability to quickly create value from different types of data increasingly provides businesses with a competitive edge. An excellent example of this is how responsive, personalized and portable a food delivery app might be. But how does a business become data-driven?

Автономные транзакции языка PL/SQL

Определяя блок PL/SQL как автономную транзакцию, вы тем самым изолируете вы­полняемые в нем команды DML от контекста транзакции вызывающего кода. Этот блок определяется как независимая транзакция, начатая другой транзакцией, которая является главной.

В блоке автономной транзакции главная транзакция приостанавливается. Вы выполня­ете SQL -операции, затем производите их фиксацию или откат и возобновляете главную транзакцию (рис. 1).

Последовательность выполнения главной и вложенной (автономной) транзакций

Рис. 1. Последовательность выполнения главной и вложенной (автономной) транзакций

Определение автономной транзакции

Определить блок PL/SQL как автономную транзакцию очень просто. Для этого до­статочно включить в раздел объявлений следующую директиву:

Директива приказывает компилятору PL/SQL назначить блок PL/SQL как автономный (независимый). В контексте автономных транзакций автономным может быть объявлен любой из следующих блоков:

  • Анонимный блок PL/SQL верхнего уровня (не вложенный!).
  • Функция или процедура, определенная в пакете или как отдельная программа.
  • Метод (функция или процедура) объектного типа.
  • Триггер базы данных.

Директива AUTONOMOUS_TRANSACTlON может располагаться в любом места раздела объяв­лений блока PL/SQL. Однако лучше всего разместить ее перед определениями струк­тур данных, чтобы любому программисту сразу было ясно, что программа является анонимной транзакцией. Введение этой директивы — единственное изменение в коде PL/SQL для поддержки анонимных транзакций. Все остальное — команды COMMIT и ROLLBACK , а также команды DML — остается прежним. Автономная транзакция просто изменяет их область действия и видимость при выполнении в контексте автономной транзакции, и вы должны включить команду COMMIT или ROLLBACK в каждую программу автономной транзакции.

Правила и ограничения на использование автономных транзакций

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

  • Если автономная транзакция пытается обратиться к ресурсу, заблокированному главной транзакцией (приостановленной до завершения автономной программы), происходит взаимная блокировка (deadlock). Простой пример: программа обновляет таблицу, а затем, не зафиксировав изменения, вызывает автономную процедуру, которая должна внести изменения в ту же таблицу:

Результат не радует:

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

  • Чтобы выход из программы с автономной транзакцией, выполнившей как минимум одну команду INSERT, UPDATE, MERGE или DELETE, произошел без ошибок, необходимо выполнить явную фиксацию или откат транзакции. Если в программе содержится незавершенная транзакция, то исполняющее ядро инициирует исключение и про­изводит откат незафиксированной транзакции.
  • Команды COMMIT и ROLLBACK завершают активную автономную транзакцию, но не про­грамму, в которой она содержится. Поэтому блок с автономной транзакцией может содержать несколько команд commit и rollback.
  • При выполнении отката до точки сохранения эта точка должна быть определена в те­кущей транзакции. В частности, нельзя выполнить откат из автономной транзакции до точки сохранения, определенной в главной транзакции.
  • Параметр TRANSACTIONS в инициализационном файле Oracle определяет допустимое количество выполняемых одновременно автономных транзакций для одного сеанса. Если в приложении используется множество программ, выполняемых в режиме автономной транзакции, этот предел может быть превышен, что приведет к выдаче исключения. В этом случае значение параметра TRANSACTIONS следует увеличить. По умолчанию оно равно 75.

Область видимости транзакций

После выполнения в автономной транзакции команд COMMIT или ROLLBACK изменения по умолчанию немедленно становятся видимыми в главной транзакции. А если вы предпочитаете скрыть их от последней? Да, изменения должны быть сохранены или отменены, но информация об этом не должна становиться доступной в главной тран­закции. Для этой цели используется следующая модификация команды SET TRANSACTION :

По умолчанию для транзакции устанавливается уровень изоляции READ COMMITTED , при котором зафиксированные изменения тут же становятся видимыми главной транзакции. Как обычно, команда SET TRANSACTION должна выполняться до начала транзакции (то есть перед первой командой SQL). Кроме того, данная установка влияет на весь сеанс, а не только на текущую программу. Сценарий autonserial.sql на сайте книги демонстрирует уровень изоляции SERIALIZABLE в действии.

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

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

  • Механизм протоколирования. Требуется записать информацию об ошибке в та­блицу базы данных, а также выполнить откат внутренней транзакции, приведшей к ошибке. При этом вы не хотите, чтобы из таблицы-журнала были удалены и дру­гие записи об ошибках. Сделайте внутреннюю транзакцию автономной! Вероятно, это самая распространенная причина для использования автономных транзакций в коде PL/SQL .
  • Фиксация и откат в триггерах базы данных. Определив триггер как автономную транзакцию, все выполненные им изменения можно фиксировать или отменять, и это никак не отразится на транзакции, приведшей к срабатыванию триггера. Для чего это может быть нужно? Например, в триггере базы данных можно выполнить действие, которое не зависит от статуса транзакции, вызвавшей срабатывание триг­гера. Предположим, вы хотите отслеживать все действия с таблицей независимо от того, было это действие завершено или нет. А может, вы хотите отслеживать действия, завершившиеся неудачей. Примеры использования этого приема пред­ставлены в сценариях autontrigger*.sql на сайте книги.
  • Многократно используемые компоненты приложения. Для программ этого типа возможность определять автономные транзакции жизненно необходима. В совре­менных системах, особенно в распределенном и многоуровневом мире Интернета, необходимы независимые программные единицы, выполняемые без каких-либо побочных эффектов для среды вызова. Автономные транзакции играют важную роль в этой области.
  • Предотвращение каскадных триггерных ошибок. Такие ошибки возникают в ситу­ации, когда триггер уровня строки таблицы пытается читать или записывать данные в таблицу, из которой он сработал. Но если преобразовать триггер в автономную транзакцию, включив директиву PRAGMA AUTONOMOUS_TRANSACTION и закрепив изменения в теле триггера, код последнего сможет запрашивать содержимое таблицы, но при этом будет видеть только уже закрепленные изменения. Иначе говоря, в таблице не будут видны изменения, внесение которых привело к срабатыванию триггера. Кроме того, код триггера не сможет изменять содержимое таблицы.
  • Вызов пользовательских функций в коде SQL, изменяющем таблицы. Oracle позволяет вызывать в командах SQL пользовательские функции — при условии, что функция не обновляет базу данных (и с некоторыми дополнительными ус­ловиями). Но если функция будет определена как автономная транзакция, вы можете выполнять в ней операции вставки, обновления и удаления в ходе запроса. Данная возможность продемонстрирована в сценарии trcfunc.sql на сайте книги.
  • Счетчик попыток. Допустим, вы хотите предоставить пользователю N попыток обращения к ресурсу, причем количество попыток должно сохраняться между под­ключениями к базе данных. Для этого необходима команда COMMIT , независимая от транзакции. Примеры представлены в файлах retry.pkg и retry.tst на сайте книги.

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

Во многих приложениях возникает необходимость в ведении журнала ошибок, про­исходящих в ходе выполнения транзакций. Самым удобным местом для хранения журнала является таблица базы данных: она всегда доступна и из нее удобно извлекать информацию для анализа средствами SQL .

Но у такого журнала имеется один недостаток: операции записи в журнал становятся частью транзакции. И если будет выполнена команда ROLLBACK , из журнала может быть удалена часть записей об ошибках. Конечно, это нежелательно. Можно попытаться с помощью точек сохранения выполнить откат таким образом, чтобы записи журнала оставались нетронутыми, но это крайне неудобно. Автономные транзакции суще­ственно упрощают протоколирование ошибок, делают его более удобным и надежным. Допустим, таблица-журнал определена следующим образом:

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

Как пользоваться журналом? Прежде всего рассмотрим неправильное решение:

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

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

Наш очень простой пакет протоколирования состоит всего из двух процедур:

Чем putline отличается от saveline? Процедура log.saveline является автономной транзакцией, тогда как log. putline просто вставляет строку в таблицу. Вот тело пакета:

Несколько замечаний по поводу реализации, которые помогут вам лучше понять про­исходящее:

  • Процедура putline выполняет обыкновенную вставку. Вероятно, вы захотите до­бавить в нее раздел обработки исключений, если пакет log будет взят за основу подсистемы протоколирования ошибок в реальном приложении.
  • Процедура saveline вызывает процедуру putline, но делает это в контексте авто­номной транзакции.

При наличии описываемого пакета обработка ошибок значительно упрощается:

Только и всего. Разработчикам не нужно задумываться о структуре таблицы журнала; более того, они могут вообще не знать, что запись производится в таблицу базы данных. А поскольку транзакция автономна, то что бы ни происходило в приложении — журнал останется в целости и сохранности.

Вложенные транзакции Oracle и автономные транзакции

ключевое слово
Концепция вложенных транзакций и автономных транзакций
Использование вложенных транзакций
Использование автономных дел

A. концепция
1. Вложенная транзакция:
Указывает на одну или несколько вложенных транзакций, вложенных в родительскую транзакцию, и основная транзакция влияет на нее. Этот тип транзакции называется вложенной транзакцией. Подтвердить как конец транзакции.
2. Автономная транзакция:
Относится к автономному управлению транзакциями в подпрограммах, таких как функции и процедуры. Когда эти подпрограммы вызываются в других блоках pl / sql, эти подпрограммы не откатываются при сбое родительского блока pl / sql, а управляются сами собой совершить. Подтвердить как конец транзакции. Автономные транзакции часто используются для записи информации LOG или TRAC для облегчения поиска ошибок.
II. Использование вложенных транзакций (Nested Transaction)
1. Подготовить Создать таблицу:

Создайте процедуру вложенной транзакции:
1)

Измените процедуру вложенной транзакции выше, не совершая:

3. Автономная транзакция
1. Ниже приведено описание автономных транзакций от Oracle:
autonomous transactions does not depend on the main transaction. For example, if the main transaction rolls back, nested transactions roll back, but autonomous transactions do not.
autonomous transactions‘ committed changes are visible to other transactions immediately. (A nested transaction's committed changes are not visible to other transactions until the main transaction commits.)

Автономная транзакция (в дальнейшем именуемая AT) является транзакцией, вызываемой основной транзакцией (в дальнейшем именуемой MT), но независимой от MT. Когда автономная транзакция вызывается и выполняется, MT приостанавливается. Внутри автономной транзакции может быть выполнен ряд DML и зафиксирован или откатан. Автономная транзакция предотвращает вложенные фиксации, делая фиксацию транзакции или откат в пределах своей собственной области транзакции. Повлияет на другие дела. Из-за независимости автономных транзакций, их фиксация и откат не влияют на производительность MT. После завершения выполнения автономной транзакции основная транзакция получает контроль и может возобновить выполнение.
Чтобы получить определение автономных транзакций, просто добавьте следующую часть объявления PL / SQL плюс PRAGMA AUTONOMOUS_TRANSACTION.
1). Анонимные блоки PL / SQL верхнего уровня
2). Функции или Процедура.

2. Определите автономную транзакцию:

3 Сводка Авто транзакций:

(1) Роль ключевого слова pragma заключается в информировании компилятора PL / SQL о разбиении блока кода PL / SQL, который объявляет его в автономную или независимую транзакцию. При определении автономной транзакции необходимо соблюдать несколько правил:
1) Если блок PL / SQL является анонимным, анонимный блок PL / SQL должен быть блоком верхнего уровня.
2) Если блок PL / SQL не является анонимным, это должна быть процедура или функция, которая является частью пакета или сохраненной программной единицы. При определении автономных транзакций в пакете только определенные функции или процедуры в пакете могут быть обозначены как автономные.
3) блоки PL / SQL также могут быть способом хранения типов объектов
4) Блок PL / SQL также может быть триггером базы данных
(2) Некоторые ключевые вопросы автономных дел
1) Автономная транзакция с ALTER SESSION
Автономная транзакция должна совместно использовать сеанс с основной транзакцией, поэтому любая модификация сеанса с помощью инструкции ALTER SESSION должна быть видимой как для автономной транзакции, так и для основной транзакции. Но автономные транзакции выполняются в другом контексте, чем основная транзакция. Любой автономный вызов подпрограммы из автономного блока использует тот же контекст транзакции, что и автономная транзакция.

2) Автономные дела и тупик
Автономные транзакции должны быть определены следующим образом:
Взаимные блокировки возникают, когда автономная транзакция пытается получить доступ к ресурсу, который занят основной транзакцией, и в это время основная транзакция приостанавливается до завершения автономной транзакции. Автономные транзакции умирают, а другие основные транзакции освобождают ресурсы, что может привести к взаимоблокировкам.

3) Определить условия для автономных дел
Только анонимные блоки верхнего уровня могут включать PRAGMA AUTONOMOUS_TRANSTRACTION

4) поведение COMMIT или ROLLBACK и автономные транзакции
Автономная транзакция заканчивается оператором commit или rollback. Следовательно, вы должны явно включить оператор подтверждения или отката в программу автономных транзакций. Если этого не сделать, любая ожидающая транзакция будет откатана. Это откат на уровне транзакции, а не откат на уровне выписки.

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

6) Несколько автономных транзакций
В контексте автономной транзакции несколько автономных транзакций инициализируются. Для выполнения этой задачи вы можете определить несколько операторов commit или rollback в автономном блоке. Когда откат включен, он будет принадлежать текущей транзакции, а не основной транзакции.

7) Проблемы параллелизма в автономных делах
Автономные транзакции и основные транзакции выполняются одновременно.Параметр транзакций в файле инициализации init.ora определяет количество одновременных транзакций в каждом сеансе.

8) Вызов пользовательских функций из автономных транзакций и из SQL
Автономные транзакции позволяют вызывать пользовательские функции из SQL для выполнения операций DML. Просто определите пользовательскую функцию как автономную транзакцию, и функция станет вызываемой из SQL.
9) Уровни автономности и изоляции
Команды фиксации или отката должны быть заданы в автономных транзакциях. После выполнения коммита или отката внутри автономной транзакции эти изменения становятся видимыми для основной транзакции. Но Oracle также позволяет скрыть эти изменения от основной транзакции, установив уровень изоляции основной транзакции в значение SERIALIZABLE вместо значения READ COMMITTED по умолчанию. Это можно сделать с помощью оператора Set TRANSCTION, синтаксис которого следующий:
Set transaction isolation level serializable;
Что касается вопроса об уровне изоляции, стоит отметить следующие два момента:
а) Когда автономная транзакция заканчивается фиксацией или откатом, изменения, сделанные автономной транзакцией, видны для транзакций, отличных от основной транзакции.
б) Установите уровень изоляции на сериализуемый, чтобы скрыть изменения автономных транзакций от основной транзакции. До тех пор, пока основная транзакция не завершится, как только основная транзакция будет зафиксирована, изменения в автономной транзакции также будут видны для автономной транзакции.

10) уровень изоляции
Уровень изоляции - это метод работы с изменениями транзакций базы данных, который влияет на видимость изменений в одной транзакции в другой. В SQL92 определено 4 уровня изоляции:

Oracle поддерживает уровни изоляции READ COMMOTTED и SERIALIZABLE
Чтение зафиксировано. Этот параметр используется по умолчанию для Oracle, что позволяет запросу Oracle просматривать данные, переданные перед запросом. Другими словами, транзакции в этом режиме основаны на согласованном наборе транзакций на предложение.
Сериализуемый: этот параметр означает, что все операторы в транзакции находятся в образе базы данных в начале транзакции, что означает, что текущая транзакция не может видеть данные, переданные другими транзакциями перед фиксацией.

На этом завершается исследование вложенных транзакций и автономных транзакций.

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

Реализованы они в СУБД Oracle, и являются очень гибким и удобным средством. Самым популярным (но далеко не единственным) использованием автономных транзакций является логирование. Рассмотрим несложный пример. Представьте себе следующую ситуацию — в вашей БД реализована длинная и сложная хранимая процедура, например ежемесячный биллинг. Важные события вы наверняка хотели бы видеть в таблице логов. Вы, конечно, можете просто писать в нее безо всяких ухищрений. Но есть один серьезный недостаток — если в процедуре происходит необработанная ошибка — транзакция откатывается вместе со всеми записями в таблицу логов. Тут на помощь и приходят автономные транзакции. Они выполняются независимо от родительской транзакции, и вы можете увидеть записи в таблице логов еще до того, как закончилось выполнение логгируемой процедуры биллинга.

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

dblink

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

Пример

Покажу описываемый прием на примере из начала топика. Реализуем логирование на «автономных» транзакциях.

Создаем таблицу логов:

CREATE TABLE " public "."logs" (
"log_id" BIGSERIAL,
"source" TEXT NOT NULL ,
" level " TEXT NOT NULL ,
"message" TEXT NOT NULL ,
"time_added" TIMESTAMP WITHOUT TIME ZONE DEFAULT now() NOT NULL ,
CONSTRAINT "logs_pkey" PRIMARY KEY ("log_id")
) WITH OIDS;

* This source code was highlighted with Source Code Highlighter .

Создадим функцию для логгирования:

CREATE OR REPLACE FUNCTION " public "."log"( IN p_source text, IN p_level text, IN p_message text)
RETURNS void AS
$$
DECLARE
INSERT_SQL text := 'INSERT INTO public.logs (source, level, message) VALUES (' '[SOURCE]' ',' '[LEVEL]' ',' '[MESSAGE]' ')' ;
BEGIN

IF p_level != 'ERROR' AND p_level != 'WARNING'
AND p_level != 'INFO' AND p_level != 'DEBUG' THEN
RAISE EXCEPTION 'Log level should be one of the following types: ERROR, WARNING, INFO, DEBUG' ;
END IF ;

INSERT_SQL := replace(INSERT_SQL, '[SOURCE]' , p_source);
INSERT_SQL := replace(INSERT_SQL, '[LEVEL]' , p_level);
INSERT_SQL := replace(INSERT_SQL, '[MESSAGE]' , p_message);

PERFORM dblink_exec( 'dbname=' || current_database(), INSERT_SQL);
END ;
$$ LANGUAGE 'plpgsql' ;

* This source code was highlighted with Source Code Highlighter .

Теперь в любой момент мы можем вызвать функцию «log» и запись тут же появится в таблице логов независимо от статуса транзакции, в во время которой мы ее вызвали.

PERFORM " public "."log"( 'monthly billing' , 'INFO' , 'Starting monthly billing' );

* This source code was highlighted with Source Code Highlighter .

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

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

421 1 1 золотой знак 5 5 серебряных знаков 13 13 бронзовых знаков Если "каких то откатов", то вам надо изучать само понятие транзакции. А про автономные, надо просто знать, что они есть и как работают. Что бы могли применить когда понадобятся. Применений у них мало. Из чего то не притянутого за уши приходит в голову например логирование ошибок. происходит у вас в процедуре ошибка и вы хотите записать ее в БД. если вы запишите ее просто так, а потом эту же ошибку вернете пользователю, от в БД ничего не запишется, потому что после возврата пользователю текущая транзакция будет откачена. А автономная запишет и зафиксирует это независимо от вызвавшей транзакции Я их использовал только один раз. Мне понадобилось, что бы функция, вызываемая из запроса select писала данные в БД. Это невозможно, потому что из select можно вызывать только WNDS функции, т.е. такие которые ничего не пишут, что бы они не поменяли данные, которые сейчас читает select. Но мне надо было писать в другую таблицу и мне было не важно что select это не увидит. В итоге сделал с автономной транзакцией, такую функцию можно декларировать как WNDS

Классический случай - запись журналов (логов) в БД.

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


140k 10 10 золотых знаков 46 46 серебряных знаков 115 115 бронзовых знаков

Небольшое дополнение к ответу MaxU.

Один из примеров использования. Допустим у вас есть некая функция возвращающая число. Данная функция вызывается в запросе

Вроде все хорошо, но в какой-то момент захотелось что-бы эта функция еще и добавляла/изменяла/удаляла запись в базе (например сохранила в журнал время вызова данной функции). Вы добавляете соответствующий код в функцию и запрос указанный выше перестает работать, т.к. в обычном селекте нельзя изменять данные в базе. В таком случае вы можете указать функции свойство pragma autonomous_transaction. Функция начнет изменять данные в базе и при этом ее можно спокойно вызвать в селекте.

Читайте также: