Oracle Заполнение таблицы резервного копирования из первичной таблицы

Question

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

Во время проверки кода, коллега отметил, что

INSERT INTO BACKUP_TABLE 
SELECT * 
FROM PRIMARY_TABLE 

является неоправданно рискованным, так как это возможно для таблицы имеют разные столбцы, и разные порядки столбцов.

Я также не могу создавать/удалять/переименовывать таблицы. ~ Sigh ~

Ожидается, что столбцы в таблице изменятся, поэтому простое кодирование имен столбцов на самом деле не является решением, которое я ищу.

Я ищу идеи по разумному, не рискованному способу выполнения этой работы.

Answer 1

Остается ли резервная таблица? Сохраняет ли данные постоянно, или это просто копия текущих значений?

Слишком плохо, что вы не можете создавать/удалять/переименовывать/копировать. В противном случае, если это короткий срок, используется только в случае, если что-то пойдет не так, то вы могли бы бросить его в начале обработки и сделать что-то вроде

create table backup_table as select * from primary_table; 

Ваших лучшего варианта может быть сделать выбор явно, так как

insert into backup_table (<list of columns>) select <list of columns> from primary_table; 

Вы можете сгенерировать это путем создания строки SQL из словаря данных, а затем выполнить немедленное выполнение. Но вы все равно рискуете, если в backup_table не будут находиться все важные столбцы из primary_table.

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

Answer 2

Вы могли бы попробовать что-то вроде:

CREATE TABLE secondary_table AS SELECT * FROM primary_table; 

Не уверен, что автоматически копирует данные. Если нет:

CREATE TABLE secondary_table AS SELECT * FROM primary_table LIMIT 1; 
INSERT INTO secondary_table SELECT * FROM primary_table; 

Edit:

К сожалению, не читал ваш пост полностью: особенно ограничений части. Боюсь, я не знаю, как это сделать. Мое предположение было бы использовать процедуру, которая сначала описывает обе таблицы и сравнивает их, прежде чем создавать длинный запрос insert/select.

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

Answer 3

Есть ли причина, по которой вы не можете просто перечислить столбцы в таблицах? Так

INSERT INTO backup_table(col1, col2, col3, ... colN) 
    SELECT col1, col2, col3, ..., colN 
    FROM primary_table 

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

Answer 4

Как часто вы меняете структуру своих таблиц? Ваш метод должен работать нормально, если структура не изменится. Лично я думаю, что ваши администраторы баз данных должны предоставить вам механизм для удаления таблицы резервного копирования и ее воссоздания, например, хранимой процедуры. У нас было что-то подобное на моей последней задаче для обрезания определенных таблиц, поскольку усечение часто намного быстрее, чем DELETE FROM TABLE;.

Answer 5

Если бы у меня была такая ситуация, я бы получил определения столбцов для двух таблиц прямо в начале проблемы. Тогда, если бы они были идентичны, я бы приступить к простой:

INSERT INTO BACKUP_TABLE 
SELECT * 
FROM PRIMARY_TABLE 

Если бы они были разные, я бы продолжить, только если не было каких-либо критических столбцов, отсутствующие в таблице резервного копирования. В этом случае я хотел бы использовать эту форму для резервной копии:

INSERT INTO BACKUP_TABLE (<list of columns>) 
SELECT <list of columns> 
FROM PRIMARY_TABLE 

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

Действительно, это признак плохих процессов где-то, на что следует обратить внимание, но защитное программирование может помочь сделать его чужой проблемой, а не вашей. Если они не замечают сообщение об ошибке журнала, которое сообщает им о дампе текста с отсутствующими столбцами, то это не ваша ошибка.

Но если вы не защищаете код, а самое страшное, это будет частично вашей ошибкой.