🗄️ SQL и базы данных · 20 вопросов · ~38 мин · ⏱ Таймер 38:00 · Средний · 👥 1 прошёл

Транзакции и свойства ACID

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

Отвечено: 0 из 20

⏱ --:--

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

Вопрос 1 из 20

Какой результат атомарной транзакции перевода допустим после ошибки?

BEGIN;
UPDATE accounts SET balance=balance-100 WHERE id=1;
UPDATE accounts SET balance=balance+100 WHERE id=2;
COMMIT;

Либо обе записи зафиксированы, либо обе отменены Зачисление прошло, списание нет Списание прошло, зачисление нет Каждая команда фиксируется отдельно независимо от BEGIN

Вопрос 2 из 20

Что произойдёт после ROLLBACK?

BEGIN;
UPDATE products SET price=0;
ROLLBACK;

Незафиксированные изменения текущей транзакции будут отменены COMMIT выполнится автоматически Все изменения текущей транзакции до BEGIN сохранятся Удалится таблица транзакций

Вопрос 3 из 20

Почему два UPDATE без явной транзакции могут дать половинчатый перевод?

UPDATE accounts SET balance=balance-100 WHERE id=1;
-- здесь соединение оборвалось
UPDATE accounts SET balance=balance+100 WHERE id=2;

Обе команды откатятся как неявная общая транзакция Первый UPDATE останется незавершённым до следующего запроса Ошибка второй команды отменит первую на уровне соединения Автокоммит может зафиксировать первый UPDATE отдельно

Вопрос 4 из 20

Для чего нужен SAVEPOINT?

BEGIN;
INSERT INTO orders ...;
SAVEPOINT before_optional_log;
INSERT INTO audit_log ...;
ROLLBACK TO before_optional_log;
COMMIT;

Чтобы повысить уровень изоляции только для команд после точки сохранения Чтобы откатить часть работы, не отменяя всё до BEGIN Чтобы откатывать последний оператор без заранее созданной именованной точки Чтобы окончательно зафиксировать изменения до точки, оставив более позднюю часть обратимой

Вопрос 5 из 20

После нарушения ограничения транзакция PostgreSQL остаётся открытой в состоянии ошибки. Что нужно сделать, прежде чем продолжать?

После ошибки можно продолжить с следующей команды, а неудачный оператор просто не войдёт в COMMIT COMMIT исправляет данные Ограничение отключается Выполнить ROLLBACK либо откатиться к заранее созданному savepoint

Вопрос 6 из 20

Что в большей степени обеспечивает CHECK (balance >= 0)?

balance numeric NOT NULL CHECK (balance >= 0)

Сортировку Атомарность Долговечность Согласованность значения

Вопрос 7 из 20

Гарантирует ли BEGIN само по себе, что сумма двух счетов не изменится при переводе?

Да, если balance имеет integer: тип данных сам сохраняет общую сумму Нет, команды и конкурентный доступ должны быть спроектированы так, чтобы сохранять инвариант Да: BEGIN автоматически проверяет все бизнес-инварианты после каждой команды Нет: внутри транзакции нельзя выполнить два UPDATE разных счетов

Вопрос 8 из 20

Какое ограничение защищает от двух заказов с одним внешним номером внутри магазина?

INDEX (external_no) UNIQUE (store_id, external_no) CHECK (external_no IS NOT NULL) FOREIGN KEY (external_no) REFERENCES stores(id)

Вопрос 9 из 20

Почему проверка «SELECT остаток, затем INSERT брони» может нарушить лимит при конкуренции?

Параллельный SELECT возвращает NULL и поэтому вторая бронь не создаётся Предложение LIMIT автоматически блокирует все строки, участвующие в расчёте остатка После чтения остатка PostgreSQL удерживает его значение для этой транзакции и отклоняет вторую бронь Две транзакции могут одновременно увидеть один и тот же свободный остаток и обе записать бронь

Вопрос 10 из 20

Что относится к согласованности схемы?

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

Вопрос 11 из 20

Видит ли другая транзакция незакоммиченный UPDATE обычным чтением в PostgreSQL?

-- T1
BEGIN;
UPDATE accounts SET balance=0 WHERE id=1;
-- COMMIT ещё не выполнен

-- T2
SELECT balance FROM accounts WHERE id=1;

Чужое изменение станет видимым после SAVEPOINT читающей транзакции, даже без COMMIT Нет: обычное чтение другой транзакции не видит незавершённую версию Незакоммиченное значение видно только чтению через тот же индекс, который использовал UPDATE Обычный SELECT видит последнюю физическую версию, но помечает незакоммиченное значение как временное

Вопрос 12 из 20

Что может произойти, если две транзакции одновременно обновляют одну строку?

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

Вопрос 13 из 20

Почему схема «прочитать balance, вычислить в приложении, записать новое число» опасна?

SELECT balance FROM accounts WHERE id=1;
-- приложение вычисляет новое значение
UPDATE accounts SET balance=:new_balance WHERE id=1;

Опасность связана только с тем, что приложение может неверно сложить числа Первый SELECT автоматически фиксирует транзакцию перед вычислением в приложении Повторный UPDATE с параметром использует значение первого SELECT из серверного кеша и защищён от гонки Параллельная запись может затереть обновление

Вопрос 14 из 20

Как уменьшить риск потерянного обновления для простого приращения?

UPDATE accounts SET balance=balance+10 WHERE id=1; COMMIT; UPDATE accounts SET balance=10; DELETE account; INSERT account; SELECT balance; UPDATE balance=:calculated;

Вопрос 15 из 20

Означает ли изоляция, что транзакции всегда выполняются строго одна за другой?

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

Вопрос 16 из 20

Когда изменение считается зафиксированным для приложения?

BEGIN;
INSERT INTO payments ...;
COMMIT;

После BEGIN После создания SAVEPOINT После успешного COMMIT После первого SELECT

Вопрос 17 из 20

Что означает долговечность после успешного COMMIT?

Подтверждённые данные переживут физическую потерю всех носителей даже без другой копии После COMMIT никакая следующая транзакция не сможет изменить или удалить эту строку К моменту ответа COMMIT изменение уже гарантированно попало во все реплики и резервные копии Изменение должно пережить обычный системный сбой согласно гарантиям СУБД и настройкам

Вопрос 18 из 20

Почему реплика не заменяет резервную копию от ошибочного DELETE?

Репликация переносит INSERT и UPDATE, но не передаёт подтверждённые удаления Асинхронная реплика автоматически пропускает разрушительные DELETE, пришедшие с основного узла DELETE обычно быстро повторится на реплике Реплика сохраняет прежнюю версию каждой удалённой строки и позволяет выбрать её обычным SELECT

Вопрос 19 из 20

Что помогает восстановить зафиксированные изменения после сбоя процесса базы?

Синхронная репликация без журнала предзаписи Журнал предзаписи и механизмы восстановления СУБД Последний checkpoint без журнала предзаписи восстанавливает все изменения, подтверждённые после него Запись всех изменённых страниц напрямую на диск до каждого оператора

Вопрос 20 из 20

Как проверить реальную защиту резервных копий?

Проверять доступность основной базы командой SELECT 1 после создания копии Сравнивать только размер файлов копии с размером рабочей базы Добавлять индексы в рабочую базу, чтобы копирование проходило быстрее Регулярно выполнять пробное восстановление и проверять целостность и целевое время

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу