Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Применяется к:✅ аналитической конечной точке SQL и хранилищу данных в Microsoft Fabric
Аналогично их поведению в SQL Server транзакции позволяют управлять фиксацией или откатом запросов на чтение и запись.
Fabric Data Warehouse поддерживает транзакции, совместимые с ACID. Каждая транзакция является атомарной, согласованной, изолированной и устойчивой (ACID). Все операции в одной транзакции обрабатываются атомарно, либо все успешно, либо все неудачно. Если любая инструкция в транзакции завершается ошибкой, откат всей транзакции выполняется.
Явные транзакции
Вы можете изменить данные, хранящиеся в таблицах в хранилище, с помощью явных транзакций для объединения изменений.
Например, можно зафиксировать вставки в несколько таблиц или ни в одну из таблиц, если возникает ошибка. Если вы изменяете сведения о заказе на покупку, затрагивающем три таблицы, можно сгруппировать эти изменения в одну транзакцию. Это означает, что при запросе этих таблиц они либо все содержат изменения, либо ни одна из них не содержит. Транзакции являются распространенной практикой, когда необходимо убедиться, что данные согласованы в нескольких таблицах.
Стандартные механизмы управления синтаксисом T-SQL (BEGIN TRAN, COMMIT TRANи ROLLBACK TRAN) можно использовать для явных транзакций. Дополнительные сведения см. в статье BEGIN TRANSACTION
- COMMIT TRANSACTION
- ROLLBACK TRANSACTION
Например, Fabric Data Warehouse будет рассматривать эти изменения схемы как одну атомарную единицу:
-- Sample Syntax---
BEGIN TRAN;
ALTER TABLE <table_name> ADD <column_name> <type>;
ALTER TABLE <table_name> DROP COLUMN <column_name>;
COMMIT;
Если любая операция в транзакции выполняется с ошибкой, все изменения схемы автоматически откатываются.
Fabric Data Warehouse поддерживает выполнение следующих действий внутри явной транзакции:
CREATE TABLEDROP TABLETRUNCATE TABLECTASsp_rename-
ALTER TABLEдобавить столбцы, допускающие значение NULL -
ALTER TABLEУдаление столбцов -
ALTER TABLEдобавьте или удалитеPRIMARY KEY,UNIQUE, иFOREIGN KEYограничения с ключевым словомNOT ENFORCED - Несколько
ALTER TABLEоператоров -
ALTER TABLEв распределенных временных таблицах
Поддержка транзакций запросов между базами данных
Хранилище в Microsoft Fabric поддерживает транзакции, которые охватывают несколько хранилищ в рамках одной и той же рабочей области, включая возможность чтения из конечной точки аналитики SQL для Lakehouse. Пример см. в статье "Запись межбазового SQL-запроса".
Понимание блокировки и взаимодействие с ней в Fabric Data Warehouse
Fabric Data Warehouse использует блокировку на уровне таблицы независимо от того, касается ли запрос одной строки или нескольких. В следующей таблице приведен список блокировок, используемых для различных операций T-SQL.
| Тип утверждения | Блокировка взята |
|---|---|
| DML | |
| SELECT | Schema-Stability (Sch-S) |
| INSERT | Исключительное намерение (IX) |
| DELETE | Исключительное намерение (IX) |
| UPDATE | Исключительное намерение (IX) |
| MERGE | Исключительное намерение (IX) |
| COPY INTO; | Исключительное намерение (IX) |
| DDL | |
| СОЗДАТЬ ТАБЛИЦУ | Изменение схемы (Sch-M) |
| ALTER TABLE | Изменение схемы (Sch-M) |
| DROP TABLE | Изменение схемы (Sch-M) |
| TRUNCATE TABLE | Изменение схемы (Sch-M) |
| CREATE TABLE AS SELECT (Создать таблицу как SELECT) | Изменение схемы (Sch-M) |
| СОЗДАТЬ ТАБЛИЦУ КАК КЛОН | Изменение схемы (Sch-M) |
В настоящее время блокировки можно запрашивать с помощью динамического административного представления (DMV) sys.dm_tran_locks.
Дополнительные сведения о блокировках, эскалации блокировки и совместимости блокировки см. в руководстве по блокировке транзакций и настройке версий строк.
Изоляция моментальных снимков
Fabric Data Warehouse обеспечивает изоляцию моментальных снимков для всех транзакций. Изоляция моментальных снимков — это уровень изоляции на основе строк, обеспечивающий согласованность данных на уровне транзакций и использующий версии строк, хранящиеся в tempdb для выбора строк на обновление. Транзакция использует версии строк данных, которые существуют при запуске транзакции. Это гарантирует, что каждая транзакция работает на согласованной моментной копии данных, как они существовали в начале транзакции.
В изоляции снимков (snapshot isolation), запросы в транзакции видят ту же версию, или моментальный снимок, который соответствует состоянию базы данных на момент начала транзакции. В режиме изоляции моментальных снимков транзакции, изменяющие данные, не блокируют транзакции, считывающие данные, и наоборот, считывающие данные транзакции не блокируют изменяющие данные транзакции. Это оптимистичное, неблокирующее поведение также значительно снижает вероятность развивок при выполнении сложных транзакций.
Если вы используете T-SQL для изменения уровня изоляции, изменение игнорируется во время выполнения запроса и применяется изоляция моментальных снимков.
В изоляции моментальных снимков возможны конфликты записи-записи или обновления; дополнительные сведения смотрите в разделе Понимание конфликтов записи-записи в Fabric Data Warehouse.
Блокировки схемы
Блокировки схемы предотвращают конфликты в инструкциях DDL, таких как схема таблицы, изменяемая во время обновления строк в транзакции. Имейте в виду, что операции DDL, такие как изменения схемы и миграции данных, могут блокировать или быть заблокированы активными задачами чтения.
- Во время операций языка определения данных (DDL) ядро СУБД использует блокировки изменения схемы (
Sch-M). Во время ее проведенияSch-Mблокировка предотвращает весь одновременный доступ к таблице, пока блокировка не будет снята. - Во время операций языка обработки данных (DML) ядро СУБД использует блокировки стабильности схемы (
Sch-S). Операции, которые получаютSch-Mблокировки, блокируютсяSch-Sблокировками. Другие транзакции продолжают выполняться во время компиляции запроса, но операции DDL блокируются, пока они не смогут получить монопольный доступ к схеме. - Операции DDL также получают монопольную (
X) блокировку строк в системных представлениях, напримерsys.tablesиsys.objectsсвязанных с целевой таблицей, в течение длительности транзакции. Это блокирует одновременныеSELECTинструкции вsys.tablesиsys.objects.
Рекомендации по предотвращению блокировки
- Избегайте длительных транзакций или запланируйте их в периоды низкой или отсутствия активности.
- Запланируйте операции DDL только во время периодов обслуживания, чтобы свести к минимуму блокировку.
- Хотя инструкции DDL можно выполнять внутри явных транзакций пользователей (
BEGIN TRAN), их следует использовать с осторожностью в параллельных рабочих нагрузках. Из-за блокировки DDL в транзакции может блокировать одновременные операции DML или SELECT в затронутых таблицах, а также запросы SELECT для представлений системного каталога, напримерsys.tablessys.objects. Чтобы отслеживать и устранять потенциальные конфликты блокировки, используйтеsys.dm_tran_locks. - Отслеживайте блокировки и конфликты в хранилище.
- Используйте sys.dm_tran_locks для проверки текущих блокировок.
Понимание конфликтов записи-записи в Fabric Data Warehouse
Могут возникать конфликты записи, когда две транзакции пытаются UPDATE, DELETE, MERGE или TRUNCATE одну и ту же таблицу.
Конфликты записи или конфликты обновлений возможны на уровне таблицы, так как Fabric Data Warehouse использует блокировку на уровне таблицы. Если две транзакции пытаются изменить разные строки в одной таблице, они по-прежнему могут конфликтовать.
Конфликты записи в основном возникают из двух сценариев:
- Конфликты рабочей нагрузки, вызванные пользователем
- Несколько пользователей или процессов одновременно изменяют одну и ту же таблицу.
- Может возникать в конвейерах ETL, пакетных обновлениях или перекрывающихся транзакциях.
- Системные конфликты
- Фоновые системные задачи, такие как автоматическое сжатие данных, перезаписывают файлы с низким качеством.
- Они могут конфликтовать с транзакциями пользователей, хотя предварительное сжатие данных активно предотвращает конфликты записи этого типа.
Если возникает конфликт записи, могут появиться такие сообщения об ошибках, как:
- Ошибка 24556: транзакция изоляции моментальных снимков прервана из-за конфликта обновления. Использование моментальной изоляции для прямого или косвенного доступа к таблице "%.*ls" в базе данных "%.*ls" может вызвать конфликты обновления, если строки в этой таблице были удалены или обновлены другой параллельной транзакцией. Повторите транзакцию.
- Ошибка 24706: транзакция с изоляцией на уровне снимков прервана из-за конфликта при обновлении. Вы не можете использовать изоляцию моментальных снимков для доступа к таблице "%.*ls" непосредственно или косвенно в базе данных "%.*ls" для обновления, удаления или вставки строки, которая была изменена или удалена другой транзакцией. Повторите транзакцию.
Если вы столкнулись с этими сообщениями об ошибках, произошла ошибка одного или нескольких транзакций, и произошел сбой одного или нескольких конфликтующих транзакций. Повторите транзакции, которые не удалось выполнить.
Замечание
Даже если MERGE транзакции приводят только к изменениям, которые добавляют данные, они по-прежнему создают конфликт записи данных. Если транзакция MERGE затрагивает строки, отличные от тех, которые затронуты другими параллельными DML-транзакциями, может возникнуть эта ошибка, если MERGE не первая транзакция, которая выполнит фиксацию: "Транзакция с изоляцией моментальных снимков прервана из-за конфликта обновления".
Лучшие рекомендации по предотвращению конфликтов записи-записи
Чтобы избежать конфликтов одновременной записи:
- Избегайте одновременных
UPDATE,DELETE,MERGEопераций на той же таблице.- Обратите особое внимание на операции
UPDATE,DELETE,MERGE, выполняемые в рамках многоступенчатых транзакций.
- Обратите особое внимание на операции
- Используйте логику повторных попыток во всех приложениях и запросах.
- Реализуйте логику повторных попыток в хранимых процедурах и конвейерах ETL.
- Добавьте логику повторных попыток с задержкой в конвейерах или приложениях для обработки временно возникающих конфликтов.
- Используйте экспоненциальную задержку, чтобы избежать массовых повторных попыток, вызывающих ухудшение временных прерываний сети. Дополнительные сведения см. в шаблоне повторных попыток.
- Конфликты записи с фоновой службой сжатия данных Fabric Data Warehouse возможны, но обычно предотвращаются функцией Data compaction preemption.
Блокировка файлов таблиц и parquet
Конфликты из двух или нескольких параллельных транзакций, которые обновляют одну или несколько строк в таблице, оцениваются в конце транзакции. Первая транзакция, которая подтверждается, завершается успешно, а остальные транзакции откатываются с сообщением о ошибке. Эти конфликты оцениваются на уровне таблицы, а не на уровне отдельных паркетных файлов.
Инструкции INSERT всегда создают новые файлы Parquet, что приводит к меньшему количеству конфликтов с другими транзакциями, за исключением транзакций DDL, поскольку схема таблицы может изменяться.
Ограничения
- Распределенные транзакции не поддерживаются, например
BEGIN DISTRIBUTED TRANSACTION. - Точки сохранения не поддерживаются.
- Именованные транзакции не поддерживаются.
- Помеченные транзакции не поддерживаются.
- В настоящее время в хранилище есть ограниченные функциональные возможности T-SQL. См. область T-SQL в Fabric Data Warehouse для получения списка команд T-SQL, которые в настоящее время недоступны.
- Если транзакция содержит вставку данных в пустую таблицу и выдает команду SELECT перед откатом, автоматически созданная статистика по-прежнему может отражать незафиксированные данные, вызывая неточные статистические данные. Неточная статистика может привести к неоптимизированным планам запросов и времени выполнения. Если вы откатите транзакцию с операторами SELECT после крупных вставок, обновите статистику столбцов, упомянутых в ваших операторах SELECT.