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

Уровни изоляции

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

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

⏱ --:--

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

Вопрос 1 из 20

Как называется чтение данных, которые другая транзакция ещё не зафиксировала?

Фантом Сериализация Неповторяемое чтение Грязное чтение

Вопрос 2 из 20

T1 дважды читает одну строку, а между чтениями T2 меняет её и фиксирует. Второе значение отличается. Что это?

-- T1: SELECT balance FROM accounts WHERE id=1;
-- T2: UPDATE accounts SET balance=200 WHERE id=1; COMMIT;
-- T1: SELECT balance FROM accounts WHERE id=1;

Грязное чтение Deadlock Неповторяемое чтение Фантом только

Вопрос 3 из 20

T1 повторяет запрос WHERE status='new', а T2 между ними вставляет новую подходящую строку. Как называется эффект?

-- T1: SELECT * FROM orders WHERE status='new';
-- T2: INSERT INTO orders(status) VALUES ('new'); COMMIT;
-- T1: SELECT * FROM orders WHERE status='new';

Фантомная строка Потерянное обновление Грязная запись Каскад

Вопрос 4 из 20

Две транзакции читают balance=100, затем записывают 110 и 120. Что потеряно?

-- T1 и T2 читают одно значение
SELECT balance FROM accounts WHERE id=1;
-- затем записывают 110 и 120

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

Вопрос 5 из 20

Чем write skew отличается от потерянного обновления?

Обе транзакции записывают одну и ту же строку, но разными значениями Это два названия одной аномалии, различающиеся только уровнем изоляции Write skew возможен только без явного BEGIN, а потерянное обновление — внутри транзакции Транзакции меняют разные строки, но совместно нарушают инвариант

Вопрос 6 из 20

Какой снимок использует обычный SELECT на Read Committed в PostgreSQL?

BEGIN ISOLATION LEVEL READ COMMITTED;
SELECT status FROM orders WHERE id=7;
-- другая транзакция выполняет COMMIT
SELECT status FROM orders WHERE id=7;

Один снимок на всё соединение Незакоммиченные строки всех транзакций Снимок на начало каждого оператора Снимок на момент создания таблицы

Вопрос 7 из 20

Допускает ли PostgreSQL грязное чтение при Read Committed?

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

Вопрос 8 из 20

Что может увидеть второй SELECT T1 на Read Committed после COMMIT T2?

-- T1 (READ COMMITTED)
SELECT balance FROM accounts WHERE id=1;
-- T2 изменяет строку и COMMIT
SELECT balance FROM accounts WHERE id=1;

NULL: повторное чтение той же строки на Read Committed не возвращает значение Незакоммиченное значение T2, если оно новее снимка первого SELECT Новое значение: второй оператор получает новый снимок Обязательно старое значение, потому что снимок фиксируется на всю транзакцию

Вопрос 9 из 20

Почему UPDATE на Read Committed может ждать?

-- T1
UPDATE accounts SET balance=90 WHERE id=1;
-- T2 до завершения T1
UPDATE accounts SET balance=80 WHERE id=1;

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

Вопрос 10 из 20

Подходит ли последовательность SELECT свободной задачи → UPDATE без блокировки для двух работников?

SELECT id FROM jobs WHERE status='new' ORDER BY id LIMIT 1;
UPDATE jobs SET status='running' WHERE id=:id;

Да, если id имеет integer: одинаковый тип не допускает одновременный выбор Нет, потому что UPDATE нельзя использовать в транзакции Нет: два работника могут выбрать одну задачу Да, снимок сам назначит разные задачи

Вопрос 11 из 20

Какой снимок использует PostgreSQL Repeatable Read?

BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT count(*) FROM orders;
-- параллельный INSERT и COMMIT
SELECT count(*) FROM orders;

Снимок содержит только незакоммиченные строки текущего сеанса Новый снимок для каждой прочитанной строки внутри одного SELECT Физическую копию каждой таблицы, созданную при BEGIN Стабильный снимок на время транзакции

Вопрос 12 из 20

Увидит ли повторный SELECT в Repeatable Read строку, которую T2 вставила и зафиксировала после начала снимка T1?

BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT COUNT(*) FROM orders WHERE status='new';
-- T2 INSERT + COMMIT
SELECT COUNT(*) FROM orders WHERE status='new';

Нет, она не входит в снимок T1 Только если строка имеет меньший id Да, сразу после COMMIT T2, потому что повторный SELECT получает новый снимок Увидит только при наличии ORDER BY по первичному ключу

Вопрос 13 из 20

Блокирует ли обычный SELECT все прочитанные строки до конца Repeatable Read?

Да, Repeatable Read удерживает блокировки чтения на всех просмотренных строках Только строки, участвующие в агрегате, получают блокировку чтения Нет, стабильность обеспечивается версиями; блокировки чтения нужны отдельными командами Только строки, найденные через индекс, остаются заблокированными до COMMIT

Вопрос 14 из 20

Что может произойти, если T1 Repeatable Read пытается обновить строку, которую T2 изменила после снимка?

Уровень автоматически станет Serializable T1 дождётся T2 и затем без проверки снимка перезапишет её значение PostgreSQL создаст вторую строку с тем же первичным ключом вместо конфликта обновления T1 может получить ошибку конкурентного обновления и должна откатиться/повториться

Вопрос 15 из 20

Защищает ли Repeatable Read PostgreSQL от любого write skew по разным строкам?

Нет, потому что он допускает грязное чтение Да, если у каждой изменяемой таблицы есть PRIMARY KEY Да: Repeatable Read PostgreSQL полностью эквивалентен Serializable для любых инвариантов Нет, общий инвариант по нескольким строкам может быть нарушен

Вопрос 16 из 20

Какой результат обещает Serializable?

Эффект, эквивалентный некоторому последовательному порядку успешно завершённых транзакций Полное отсутствие откатов, ожиданий и конфликтов при любой конкурентной нагрузке Физическое выполнение строго по одной транзакции Автоматическое исправление ошибок приложения

Вопрос 17 из 20

Почему приложение должно уметь повторять Serializable-транзакцию?

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

Вопрос 18 из 20

Что нужно повторять после serialization failure?

BEGIN ISOLATION LEVEL SERIALIZABLE;
-- чтения и изменения
COMMIT; -- может вернуть serialization failure

Нужно повторить только COMMIT, потому что все предыдущие команды уже сохранены Следует пересоздать таблицу, на которой возник serialization failure Достаточно повторить последний UPDATE, оставив прежние результаты чтения Всю транзакцию с нового BEGIN на свежих данных

Вопрос 19 из 20

Почему отправку внешнего письма опасно выполнять до успешного COMMIT внутри повторяемой логики?

COMMIT автоматически отменяет внешнее письмо, если запись в базе конфликтует Внешний вызов будет отменён вместе с транзакцией, только если выполнен до COMMIT Повтор транзакции восстанавливает письмо и поэтому не создаёт дублей При откате и повторе необратимый внешний эффект может случиться дважды

Вопрос 20 из 20

Всегда ли стоит ставить Serializable для каждого запроса?

Нет, потому что Serializable применим только к SELECT, но не к INSERT и UPDATE Да, этот уровень снижает число конфликтов, потому что заранее выстраивает все записи в очередь Да, этот уровень устраняет необходимость в повторе транзакций приложением Нет, уровень выбирают по инвариантам и нагрузке, закладывая обработку конфликтов

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

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

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

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