Teradata: как создать резервную копию таблицы, в которой используется столбец идентификаторов?

В Teradata я делал резервные копии таблиц следующим образом:

create table xxx_bak as xxx with data

Отлично работает, но я только что обнаружил, что это не работает для таблиц со столбцами идентификаторов.

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


person oscilatingcretin    schedule 30.04.2012    source источник


Ответы (3)


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

Способ сделать резервную копию, которую впоследствии можно будет восстановить с теми же ключами, — использовать инструмент архивирования/восстановления ARCMAIN.

Бэкап такой:

logon my_server/my_user, my_password;
archive data tables (my_database.my_table), release lock, file=backup_file;

Восстановить так:

logon my_server/my_user, my_password;
restore data tables (my_database.my_table), release lock, file=backup_file;
person lins314159    schedule 31.05.2012

Спустя более полутора лет я, наконец, нашел гладкое решение этой проблемы:

create table mydb.mytablebackup as 
(select * from (select * from mydb.mytable) x) 
with data;

Обязательно определите самый внутренний подзапрос, иначе он не будет работать.

person oscilatingcretin    schedule 06.12.2013
comment
Осторожность. Это изменит PI таблицы на первый столбец, что может привести к перекосу таблицы и медленной обработке. Вам также следует скопировать определение PI и секционирования исходной таблицы. Тогда это будет быстрое слияние AMP-local. - person dnoeth; 07.12.2013
comment
@dnoeth Доброе слово. Однако на самом деле новая таблица никогда не будет использоваться, единственное исключение — простое хранение резервных данных. В случае, если что-то пойдет не так с исходной таблицей (например, вы выполните массовое обновление не того столбца, удалите неправильные записи и т. д.), вы можете просто очистить исходную таблицу и вставить обратно в нее все данные из исходной таблицы. резервная таблица. Тем не менее, ваше замечание полезно знать на случай, если кто-то когда-либо удалит исходную таблицу и переименует резервную таблицу в имя исходной таблицы, чтобы она фактически стала новым домом для оперативных данных. - person oscilatingcretin; 07.12.2013
comment
Даже если вы не используете эту копию, ее создание все равно может быть намного медленнее из-за буферизации и перераспределения. И вы никогда не должны использовать эту копию в качестве замены исходной таблицы, так как не только индексы и идентификаторы будут потеряны, но и все ограничения NOT NULL и CHECK, просто сравните результаты обеих таблиц SHOW TABLE. - person dnoeth; 07.12.2013
comment
@dnoeth Все дело в удобстве и поиске самого быстрого и простого метода создания одноразовой резервной копии таблицы, поэтому производительность на самом деле не имеет значения. Также не имеет значения, если ограничения не будут скопированы в резервную копию, поскольку это не повлияет на данные. Если мне нужно скопировать данные из резервной копии обратно в исходную таблицу, данные сразу же вернутся на прежнее место. Выполнение всех этих действий с SHOW TABLE и добавление большего количества SQL в сценарий резервного копирования сводит на нет цель удобства, которого я пытаюсь достичь. - person oscilatingcretin; 07.12.2013
comment
Однако, как я сказал в предыдущем комментарии, если вы действительно заинтересованы в создании точной копии DDL, мой метод действительно не будет работать, и вам было бы более разумно получить DDL исходной таблицы, изменить столбец идентификатора на простое целое число, создайте резервную таблицу с измененным DDL и вставьте * из исходной таблицы в резервную таблицу. - person oscilatingcretin; 07.12.2013

Это включает в себя 3 шага:

 1. SHOW TABLE orig_Table; (*Get the DDL*)

 2.  Replace orig_Table with bkp_Table name

 3.  INSERT INTO bkp_Table SELECT * FROM orig_Table;
person Lenin Raj Rajasekaran    schedule 01.05.2012
comment
Что мне делать, если мне нужно откатить таблицу? Не приведет ли вставка в резервную таблицу к новой последовательности чисел для столбца идентификаторов? Если это так, я не могу выполнить обновление, потому что первичные ключи не совпадают. - person oscilatingcretin; 02.05.2012
comment
В этом случае для резервной таблицы не используйте столбец идентификаторов. Используйте десятичную дробь. Таким образом, значение из столбца идентификаторов переходит в обычный столбец с теми же значениями. - person Lenin Raj Rajasekaran; 05.05.2012