Устранение неполадок при переполнении журнала транзакций (ошибка sql server 9002)troubleshoot a full transaction log (sql server error 9002)

См. также:See Also

ALTER TABLE (Transact-SQL) ALTER TABLE (Transact-SQL) BEGIN TRANSACTION (Transact-SQL) BEGIN TRANSACTION (Transact-SQL) CREATE TABLE (Transact-SQL) CREATE TABLE (Transact-SQL) DELETE (Transact-SQL) DELETE (Transact-SQL) DROP TABLE (Transact-SQL) DROP TABLE (Transact-SQL) FETCH (Transact-SQL) FETCH (Transact-SQL) GRANT (Transact-SQL) GRANT (Transact-SQL) INSERT (Transact-SQL) INSERT (Transact-SQL) OPEN (Transact-SQL) OPEN (Transact-SQL) REVOKE (Transact-SQL) REVOKE (Transact-SQL) SELECT (Transact-SQL) SELECT (Transact-SQL) Инструкции SET (Transact-SQL) SET Statements (Transact-SQL) SET ANSI_DEFAULTS (Transact-SQL) SET ANSI_DEFAULTS (Transact-SQL) @@TRANCOUNT (Transact-SQL) @@TRANCOUNT (Transact-SQL) TRUNCATE TABLE (Transact-SQL) TRUNCATE TABLE (Transact-SQL) UPDATE (Transact-SQL)UPDATE (Transact-SQL)

См. также:See Also

ALTER TABLE (Transact-SQL) ALTER TABLE (Transact-SQL) BEGIN TRANSACTION (Transact-SQL) BEGIN TRANSACTION (Transact-SQL) CREATE TABLE (Transact-SQL) CREATE TABLE (Transact-SQL) DELETE (Transact-SQL) DELETE (Transact-SQL) DROP TABLE (Transact-SQL) DROP TABLE (Transact-SQL) FETCH (Transact-SQL) FETCH (Transact-SQL) GRANT (Transact-SQL) GRANT (Transact-SQL) INSERT (Transact-SQL) INSERT (Transact-SQL) OPEN (Transact-SQL) OPEN (Transact-SQL) REVOKE (Transact-SQL) REVOKE (Transact-SQL) SELECT (Transact-SQL) SELECT (Transact-SQL) Инструкции SET (Transact-SQL) SET Statements (Transact-SQL) SET ANSI_DEFAULTS (Transact-SQL) SET ANSI_DEFAULTS (Transact-SQL) @@TRANCOUNT (Transact-SQL) @@TRANCOUNT (Transact-SQL) TRUNCATE TABLE (Transact-SQL) TRUNCATE TABLE (Transact-SQL) UPDATE (Transact-SQL)UPDATE (Transact-SQL)

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

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

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

Уровни изоляции транзакций

Основная статья: Уровни изолированности транзакций

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

Уровни описаны в порядке увеличения изолированности транзакций и, соответственно, надёжности работы с данными.

• 0 — Чтение неподтверждённых данных (Read Uncommitted) — чтение незафиксированных изменений как своей транзакции, так и параллельных транзакций. Нет гарантии, что данные, изменённые другими транзакциями, не будут в любой момент изменены в результате их отката, поэтому такое чтение является потенциальным источником ошибок. Невозможны потерянные изменения (lost changes), возможны грязное чтение (dirty read), неповторяемое чтение и фантомы.
• 1 — Чтение подтверждённых данных (Read Committed) — чтение всех изменений своей транзакции и зафиксированных изменений параллельных транзакций. Потерянные изменения и грязное чтение не допускается, возможны неповторяемое чтение и фантомы.
• 2 — Повторяемое чтение (Repeatable Read, Snapshot) — чтение всех изменений своей транзакции, любые изменения, внесённые параллельными транзакциями после начала своей, недоступны. Потерянные изменения, грязное и неповторяемое чтение невозможны, возможны фантомы.
• 3 — Сериализуемый (Serializable) — сериализуемые транзакции. Результат параллельного выполнения сериализуемой транзакции с другими транзакциями должен быть логически эквивалентен результату их какого-либо последовательного выполнения. Проблемы синхронизации не возникают.

Чем выше уровень изоляции, тем больше требуется ресурсов, чтобы его обеспечить. Соответственно, повышение изолированности может приводить к снижению скорости выполнения параллельных транзакций, что является «платой» за повышение надёжности.

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

一般备注General Remarks

BEGIN TRANSACTION 使 @@TRANCOUNT 按 1 递增。BEGIN TRANSACTION increments @@TRANCOUNT by 1.

BEGIN TRANSACTION 代表一点，由连接引用的数据在该点逻辑和物理上都一致的。BEGIN TRANSACTION represents a point at which the data referenced by a connection is logically and physically consistent. 如果遇上错误，在 BEGIN TRANSACTION 之后的所有数据改动都能进行回滚，以将数据返回到已知的一致状态。If errors are encountered, all data modifications made after the BEGIN TRANSACTION can be rolled back to return the data to this known state of consistency. 每个事务继续执行直到它无误地完成并且用 COMMIT TRANSACTION 对数据库作永久的改动，或者遇上错误并且用 ROLLBACK TRANSACTION 语句擦除所有改动。Each transaction lasts until either it completes without errors and COMMIT TRANSACTION is issued to make the modifications a permanent part of the database, or errors are encountered and all modifications are erased with a ROLLBACK TRANSACTION statement.

BEGIN TRANSACTION 为发出本语句的连接启动一个本地事务。BEGIN TRANSACTION starts a local transaction for the connection issuing the statement. 根据当前事务隔离级别的设置，为支持该连接所发出的 Transact-SQLTransact-SQL 语句而获取的许多资源被该事务锁定，直到使用 COMMIT TRANSACTION 或 ROLLBACK TRANSACTION 语句完成该事务为止。Depending on the current transaction isolation level settings, many resources acquired to support the Transact-SQLTransact-SQL statements issued by the connection are locked by the transaction until it is completed with either a COMMIT TRANSACTION or ROLLBACK TRANSACTION statement. 长时间处于未完成状态的事务会阻止其他用户访问这些锁定的资源，也会阻止日志截断。Transactions left outstanding for long periods of time can prevent other users from accessing these locked resources, and also can prevent log truncation.

虽然 BEGIN TRANSACTION 启动一个本地事务，但是在应用程序接下来执行一个必须记录的操作（如执行 INSERT、UPDATE 或 DELETE 语句）之前，它并不被记录在事务日志中。Although BEGIN TRANSACTION starts a local transaction, it is not recorded in the transaction log until the application subsequently performs an action that must be recorded in the log, such as executing an INSERT, UPDATE, or DELETE statement. 应用程序能执行一些操作，例如为了保护 SELECT 语句的事务隔离级别而获取锁，但是直到应用程序执行一个修改操作后日志中才有记录。An application can perform actions such as acquiring locks to protect the transaction isolation level of SELECT statements, but nothing is recorded in the log until the application performs a modification action.

在一系列嵌套的事务中用一个事务名给多个事务命名对该事务没有什么影响。Naming multiple transactions in a series of nested transactions with a transaction name has little effect on the transaction. 系统仅登记第一个（最外部的）事务名。Only the first (outermost) transaction name is registered with the system. 回滚到其他任何名称（有效的保存点名除外）都会产生错误。A rollback to any other name (other than a valid savepoint name) generates an error. 事实上，回滚之前执行的任何语句都不会在错误发生时回滚。None of the statements executed before the rollback is, in fact, rolled back at the time this error occurs. 这些语句仅当外层的事务回滚时才会进行回滚。The statements are rolled back only when the outer transaction is rolled back.

如果在语句提交或回滚之前执行了如下操作，由 BEGIN TRANSACTION 语句启动的本地事务将升级为分布式事务：The local transaction started by the BEGIN TRANSACTION statement is escalated to a distributed transaction if the following actions are performed before the statement is committed or rolled back:

• 执行一个引用链接服务器上的远程表的 INSERT、DELETE 或 UPDATE 语句。An INSERT, DELETE, or UPDATE statement that references a remote table on a linked server is executed. 如果用于访问链接服务器的 OLE DB 访问接口不支持 ITransactionJoin 接口，则 INSERT、UPDATE 或 DELETE 语句会失败。The INSERT, UPDATE, or DELETE statement fails if the OLE DB provider used to access the linked server does not support the ITransactionJoin interface.

• 当启用了 REMOTE_PROC_TRANSACTIONS 选项时，将调用远程存储过程。A call is made to a remote stored procedure when the REMOTE_PROC_TRANSACTIONS option is set to ON.

SQL ServerSQL Server 的本地副本成为事务控制器并且使用 MicrosoftMicrosoft 分布式事务处理协调器 (MS DTC) 来管理分布式事务。The local copy of SQL ServerSQL Server becomes the transaction controller and uses MicrosoftMicrosoft Distributed Transaction Coordinator (MS DTC) to manage the distributed transaction.

使用 BEGIN DISTRIBUTED TRANSACTION 可以将事务作为分布式事务显式执行。A transaction can be explicitly executed as a distributed transaction by using BEGIN DISTRIBUTED TRANSACTION. 有关详细信息，请参阅 BEGIN DISTRIBUTED TRANSACTION (Transact-SQL)。For more information, see BEGIN DISTRIBUTED TRANSACTION (Transact-SQL).

SET IMPLICIT_TRANSACTIONS 设置为 ON 时，BEGIN TRANSACTION 语句创建两个嵌套的事务。When SET IMPLICIT_TRANSACTIONS is set to ON, a BEGIN TRANSACTION statement creates two nested transactions. 有关详细信息，请参阅 SET IMPLICIT_TRANSACTIONS (Transact-SQL)For more information see, SET IMPLICIT_TRANSACTIONS (Transact-SQL)

Транзакции с MySQL

MySQL предоставляет пользователям две транзакционные подсистемы хранения данных: InnoDB и NDB Cluster. Существует также несколько подсистем сторонних разработчиков. Наиболее известны сейчас XtraDB и РВХТ. В следующем разделе мы обсудим некоторые свойства каждой из них.

AUTOCOMMIT

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

Значения и эквивалентны, так же как и . После отправки запроса в режиме вы оказываетесь в транзакции, пока не выполните команду или . После этого MySQL немедленно начинает новую транзакцию. Изменение значения переменной не влияет на нетранзакционные таблицы, такие как MyISAM или Memory, которые не имеют понятия о подтверждении или отмене транзакций.

Некоторые команды, будучи запущенными во время начатой транзакции, застав­ляют MySQL подтвердить транзакцию до их выполнения. Обычно это команды языка определения данных (Data Definition Language, DDL), которые вносят изменения в структуру таблиц, например , но и другие директивы также обладают этим свойством. В документации к своей версии MySQL вы можете найти полный список команд, автоматически фиксирующих транзакцию.

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

MySQL распознает все четыре стандартных уровня изоляции ANSI, a InnoDB все их поддерживает.

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

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

Если вы используете транзакционные и нетранзакционные таблицы (например, та­блицы InnoDB и MyISAM) в одной транзакции, то все будет работать хорошо, пока не произойдет что-то неожиданное.

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

Вот почему так важно выбирать для каждой таблицы подходящую подсистему хранения

MySQL обычно не предупреждает и не выдает сообщений об ошибках, если вы вы­полняете транзакционные операции над нетранзакционной таблицей. Иногда при откате транзакции может быть сгенерировано предупреждение Some nontransactional changed tables couldn’t be rolled back (Откат некоторых измененных нетранзакционных таблиц невозможен), но большую часть времени вы не будете знать о том, что рабо­таете с нетранзакционными таблицами.

Явные и неявные блокировки

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

Однако InnoDB поддерживает и явную блокировку, которая в стандарте SQL вообще не упоминается:

• ;
• .

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

Нам часто попадаются приложения, которые были перенесены из MyISAM в InnoDB, но в которых по-прежнему используется команда . В этой команде боль­ше нет необходимости, так как применяются построчные блокировки, а проблемы с производительностью она может вызывать серьезные. 

Модель развития базы данных My… 519 просмотров Ирина Светлова Thu, 10 Jan 2019, 12:29:03

Выбор оптимальных типов данных… 1624 просмотров Валерий Павлюков Sun, 27 Oct 2019, 15:24:19

Подсистемы хранения в MySQL 1062 просмотров Ирина Светлова Wed, 09 Jan 2019, 04:26:23

Обзор версий MySQL — какой рел… 2392 просмотров Ирина Светлова Thu, 10 Jan 2019, 08:02:16

Author: Ирина Светлова

Другие статьи автора:

注解Remarks

执行 BEGIN DISTRIBUTED TRANSACTION 语句的 SQL Server 数据库引擎SQL Server Database Engine的实例是事务创建者，并控制事务的完成。The instance of the SQL Server 数据库引擎SQL Server Database Engine executing the BEGIN DISTRIBUTED TRANSACTION statement is the transaction originator and controls the completion of the transaction. 当为会话发出后续 COMMIT TRANSACTION 或 ROLLBACK TRANSACTION 语句时，控制实例请求 MS DTC 在所涉及的所有实例间管理分布式事务的完成。When a subsequent COMMIT TRANSACTION or ROLLBACK TRANSACTION statement is issued for the session, the controlling instance requests that MS DTC manage the completion of the distributed transaction across all of the instances involved.

事务级别的快照隔离不支持分布式事务。Transaction-level snapshot isolation does not support distributed transactions.

数据库引擎Database Engine的远程实例登记到分布式事务中的主要方法是当已在分布式事务中登记的会话执行引用链接服务器的分布式查询时。The primary way remote instances of the 数据库引擎Database Engine are enlisted in a distributed transaction is when a session already enlisted in the distributed transaction executes a distributed query referencing a linked server.

例如，如果在服务器 A 上发出 BEGIN DISTRIBUTED TRANSACTION，则该会话将调用服务器 B 上的一个存储过程和服务器 C 上的另一个存储过程。For example, if BEGIN DISTRIBUTED TRANSACTION is issued on ServerA, the session calls a stored procedure on ServerB and another stored procedure on ServerC. 服务器 C 上的存储过程执行针对服务器 D 的分布式查询，这样该分布式事务将涉及所有四台计算机。The stored procedure on ServerC executes a distributed query against ServerD, and then all four computers are involved in the distributed transaction. 服务器 A 上的数据库引擎Database Engine的实例是该事务的初始控制实例。The instance of the 数据库引擎Database Engine on ServerA is the originating controlling instance for the transaction.

Transact-SQLTransact-SQL 分布式事务涉及的会话并不获取可以传递给另一个会话的事务对象，从而也不能将其显式登记在分布式事务中。The sessions involved in Transact-SQLTransact-SQL distributed transactions do not get a transaction object they can pass to another session for it to explicitly enlist in the distributed transaction. 远程服务器登记到事务中的唯一方法是成为分布式查询或远程存储过程调用的目标。The only way for a remote server to enlist in the transaction is to be the target of a distributed query or a remote stored procedure call.

在本地事务中执行分布式查询时，如果目标 OLE DB 数据源支持 ITransactionLocal，则该事务被自动提升为分布式事务。When a distributed query is executed in a local transaction, the transaction is automatically promoted to a distributed transaction if the target OLE DB data source supports ITransactionLocal. 如果目标 OLE DB 数据源不支持 ITransactionLocal，则只允许在分布式查询中执行只读操作。If the target OLE DB data source does not support ITransactionLocal, only read-only operations are allowed in the distributed query.

已在分布式事务中登记的会话执行一个引用远程服务器的远程存储过程调用。A session already enlisted in the distributed transaction performs a remote stored procedure call referencing a remote server.

sp_configure remote proc trans 选项控制对本地事务中的远程存储过程调用是否自动使本地事务被提升为由 MS DTC 管理的分布式事务****。The sp_configure remote proc trans option controls whether calls to remote stored procedures in a local transaction automatically cause the local transaction to be promoted to a distributed transaction managed by MS DTC. 连接级别 SET 选项 REMOTE_PROC_TRANSACTIONS 可用于覆盖由 sp_configure remote proc trans 建立的实例默认值。启用此选项后，远程存储过程调用会导致一个本地事务提升为分布式事务。The connection-level SET option REMOTE_PROC_TRANSACTIONS can be used to override the instance default established by sp_configure remote proc trans. With this option set on, a remote stored procedure call causes a local transaction to be promoted to a distributed transaction. 创建 MS DTC 事务的连接成为该事务的创建者。The connection that creates the MS DTC transaction becomes the originator for the transaction. COMMIT TRANSACTION 初始化一个 MS DTC 协调的提交。COMMIT TRANSACTION initiates an MS DTC coordinated commit. 如果启用了 sp_configure remote proc trans 选项，本地事务中的远程存储过程调用将被自动保护，成为分布式事务的一部分，而不需要重写应用程序以便专门发出 BEGIN DISTRIBUTED TRANSACTION 而不是 BEGIN TRANSACTION****。If the sp_configure remote proc trans option is ON, remote stored procedure calls in local transactions are automatically protected as part of distributed transactions without having to rewrite applications to specifically issue BEGIN DISTRIBUTED TRANSACTION instead of BEGIN TRANSACTION.

有关分布式事务环境和处理的详细信息，请参阅 MicrosoftMicrosoft 分布式事务处理协调器文档。For more information about the distributed transaction environment and process, see the MicrosoftMicrosoft Distributed Transaction Coordinator documentation.

示例Examples

该示例从AdventureWorks2012AdventureWorks2012的本地实例和远程服务器的实例上的 数据库引擎Database Engine 数据库中同时删除候选项。This example deletes a candidate from the AdventureWorks2012AdventureWorks2012 database on both the local instance of the 数据库引擎Database Engine and an instance on a remote server. 本地和远程数据库都将提交或回滚本事务。Both the local and remote databases will either commit or roll back the transaction.

备注

除非正在运行数据库引擎Database Engine的实例的计算机中当前安装了 MS DTC，否则本示例会产生错误消息。Unless MS DTC is currently installed on the computer running the instance of the 数据库引擎Database Engine, this example produces an error message. 有关安装 MS DTC 的详细信息，请参见 Microsoft 分布式事务处理协调器文档。For more information about installing MS DTC, see the Microsoft Distributed Transaction Coordinator documentation.

Manually rollback SQL transactions

In the previous section, you saw how transactions automatically rollback themselves if one of the queries cannot be executed successfully. However, you may want to rollback a query based on certain conditions as well. For example, you may want to rollback a transaction that inserts a record in the books table if a book with the same name already exists.

In that case, you can use the rollback SQL statement.

Look at the following example:

In the script above, we declare a variable @BookCount. Next, we create a transaction named AddBook. To create a named transaction, you simply have to pass any string name for the transaction after the BEGIN TRANSACTION statement.

Inside the transaction, a book with id 20 and name Book15 is inserted in the Books table. After that, the COUNT function is used to count the Books with the name Book15.

If the count is greater than 1, that means a book already exists with the name Book15. In this case, the rollback SQL statement is used to rollback the AddBook transaction manually; otherwise, the transaction will be committed and an appropriate message is displayed to the reader.

You can see that the syntax of the rollback SQL statement is simple. You just have to write the statement ROLLBACK TRANSACTION, followed by the name of the transaction that you want to rollback.

Now, try to run the AddBook transaction to insert the record where the name is Book15 (make sure that no book with this name already exists in the Books table).

You will see that the transaction will execute successfully, and the following message will be displayed to the reader:

Now, again try to run the AddBook transaction. You will see that this time the transaction will fail since a book with the name Book15 already exists in the database. Therefore the transaction will be rolled back with the following message displayed to the user:

Уровень изоляции Read Committed

По умолчанию в PostgreSQL уровень изоляции Read Committed. Такой уровень изоляции всегда позволяет видеть изменения внесённые успешно завершёнными транзакциями в оставшихся параллельно открытых транзакциях. В транзакции, работающей на этом уровне, запрос SELECT (без предложения FOR UPDATE/SHARE) видит только те данные, которые были зафиксированы до начала запроса; он никогда не увидит незафиксированных данных или изменений, внесённых в процессе выполнения запроса параллельными транзакциями. По сути запрос SELECT видит снимок базы данных в момент начала выполнения запроса. Однако SELECT видит результаты изменений, внесённых ранее в этой же транзакции, даже если они ещё не зафиксированы. Также заметьте, что два последовательных оператора SELECT могут видеть разные данные даже в рамках одной транзакции, если какие-то другие транзакции зафиксируют изменения после выполнения первого SELECT.

Суть уровня изоляции Read Committed показана на диаграмме 1.

Примечание: В таблице уже находится запись с первой версией данных (v1). Прошу воспринимать команды SELECT v1; — как команду возвращающую данные версии v1, а UPDATE v1 to v2; — как команду обновления данных с первой версии до второй.

Примечание. На диаграмме не показано действие запроса INSERT. В рамках данного уровня изоляции, строки добавленные, например в шаге 3, в Первой транзакции, были бы ВИДНЫ остальным транзакциям после завершения Первой транзакции.

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

参数Arguments

transaction_name**transaction_name用户定义的事务名，用于跟踪 MS DTC 实用工具中的分布式事务。Is a user-defined transaction name used to track the distributed transaction within MS DTC utilities. transaction_name 必须符合标识符规则，字符数必须 <= 32**。transaction_name must conform to the rules for identifiers and must be <= 32 characters.

@tran_name_variable@tran_name_variable用户定义的一个变量名，它含有一个事务名，该事务名用于跟踪 MS DTC 实用工具中的分布式事务。Is the name of a user-defined variable containing a transaction name used to track the distributed transaction within MS DTC utilities. 必须使用 char、varchar、nchar 或 nvarchar 数据类型声明该变量 。The variable must be declared with a char, varchar, nchar, or nvarchar data type.

АргументыArguments

BEGIN TRANSACTIONBEGIN TRANSACTIONОтмечает начальную точку явной транзакции.Marks the starting point of an explicit transaction.

COMMIT COMMIT Отмечает завершение явной транзакции или транзакции с автофиксацией.Marks the end of an explicit or autocommit transaction. Эта инструкция вызывает изменения в транзакции, чтобы всегда быть зафиксированной в базе данных.This statement causes the changes in the transaction to be permanently committed to the database. Инструкция COMMIT идентична инструкциям COMMIT WORK, COMMIT TRAN и COMMIT TRANSACTION.The statement COMMIT is identical to COMMIT WORK, COMMIT TRAN, and COMMIT TRANSACTION.

ROLLBACK ROLLBACK Выполняет откат транзакции на начало транзакции.Rolls back a transaction to the beginning of the transaction. Никакие изменения транзакции не фиксируются в базе данных.No changes for the transaction are committed to the database. Инструкция ROLLBACK идентична инструкциям ROLLBACK WORK, ROLLBACK TRAN и ROLLBACK TRANSACTION.The statement ROLLBACK is identical to ROLLBACK WORK, ROLLBACK TRAN, and ROLLBACK TRANSACTION.

SET AUTOCOMMIT { ON | OFF }SET AUTOCOMMIT { ON | OFF }Определяет метод запуска и завершения транзакций.Determines how transactions can start and end.

ONONКаждая инструкция выполняется в своей транзакции, явные инструкции COMMIT или ROLLBACK не требуются.Each statement runs under its own transaction and no explicit COMMIT or ROLLBACK statement is necessary. Явные транзакции разрешены, когда для параметра AUTOCOMMIT установлено значение ON.Explicit transactions are allowed when AUTOCOMMIT is ON.

OFFOFFХранилище данных SQLSQL Data Warehouse автоматически запускает транзакцию, если транзакция уже не выполняется.automatically initiates a transaction when a transaction is not already in progress. Все последующие инструкции выполняются в рамках транзакции, и инструкции COMMIT или ROLLBACK необходимы для определения результата транзакции.Any subsequent statements are run as part of the transaction and a COMMIT or ROLLBACK is necessary to determine the outcome of the transaction. Как только транзакция фиксируется или откатывается в этом режиме, значение OFF сохраняется, а Хранилище данных SQLSQL Data Warehouse запускает новую транзакцию.As soon as a transaction commits or rolls back under this mode of operation, the mode remains OFF, and Хранилище данных SQLSQL Data Warehouse initiates a new transaction. Явные транзакции не разрешены, если AUTOCOMMIT имеет значение OFF.Explicit transactions are not allowed when AUTOCOMMIT is OFF.

Если изменить параметр AUTOCOMMIT в активной транзакции, этот параметр не повлияет на текущую транзакцию и вступит в силу только после завершения транзакции.If you change the AUTOCOMMIT setting within an active transaction, the setting does affect the current transaction and does not take affect until the transaction is completed.

Если для параметра AUTOCOMMIT установлено значение ON, выполнение другой инструкции SET AUTOCOMMIT ON не будет иметь результата.If AUTOCOMMIT is ON, running another SET AUTOCOMMIT ON statement has no effect. Подобным образом, если для параметра AUTOCOMMIT установлено значение OFF, выполнение другой инструкции SET AUTOCOMMIT OFF не будет иметь результата.Likewise, if AUTOCOMMIT is OFF, running another SET AUTOCOMMIT OFF has no effect.

SET IMPLICIT_TRANSACTIONS { ON | OFF }SET IMPLICIT_TRANSACTIONS { ON | OFF }Включает те же режимы, что и SET AUTOCOMMIT.This toggles the same modes as SET AUTOCOMMIT. Присвоение параметру SET IMPLICIT_TRANSACTIONS значения ON устанавливает для соединения режим неявных транзакций.When ON, SET IMPLICIT_TRANSACTIONS sets the connection into implicit transaction mode. Значение OFF возвращает подключение в режим автофиксации.When OFF, it returns the connection to autocommit mode. Дополнительные сведения см. в разделе SET IMPLICIT_TRANSACTIONS (Transact-SQL).For more information, see SET IMPLICIT_TRANSACTIONS (Transact-SQL).