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

Question

Это связано с принятым ответом для Какой ваш # 1 способ быть осторожным с живой базой данных ?

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

Какой лучший способ справиться с этим

Answer 1

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

BEGIN TRANSACTION

-- SQL CODE

В конце, если все в порядке, сделайте мои ВЫБОРЫ и еще много чего

COMMIT 

в противном случае

ROLLBACK

Answer 2

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

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

или

2.- Найти разницу в данных, как это

SELECT * FROM faultyTable 
EXCEPT 
SELECT * FROM backupTable

Вы должны настроить столбцы, которые будут выбраны, на общее подмножество курса. И КРОМЕ иногда называют МИНУС.

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

Answer 3

Ваша база данных может обеспечить эту функциональность. Например в Oracle:

Export (Your options) consistent = y

Конечно, создание согласованного резервного копирования в производственной онлайн-среде приведет к снижению производительности системы.