Поддержание согласованности при использовании таблиц резервного копирования temp

Question

Это связано с принятым ответом на What’s your #1 way to be careful with a live database?

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

Что лучший способ решения этой

Answer 1

Я не думаю, что это желательно, я бы проверить сложнее, прежде чем положить на стол в производстве, но предположим, что это случилось так или иначе, вы бы два варианта:

1.- Создать ON ВСТАВИТЬ триггер, который обновляет временную таблицу для резервного копирования с вставленными строками в новую таблицу, массируя данные, чтобы вписаться в старую таблицу

или

2.- Найти разницу такие данные

SELECT * FROM faultyTable 
EXCEPT 
SELECT * FROM backupTable 

Вам необходимо будет отрегулировать столбцы, которые должны быть выбраны для общего подмножества, конечно. И ЗА ИСКЛЮЧЕНИЕМ иногда называют MINUS.

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

Answer 2

Я обычно делаю

BEGIN TRANSACTION 

-- SQL CODE 

В конце концов, если все в порядке, делать свои ВЫБИРАЕТ и этажерки

COMMIT 

иначе

ROLLBACK 

Answer 3

Ваша база данных может предоставить эту funcionality. Например, в Oracle:

Export (Your options) consistent = y 

Конечно, выполнение последовательной резервной копии в производственной онлайн-среде будет иметь штраф за производительность системы.