 |
 |
Archives of the TeradataForum
Message Posted: Tue, 29 Oct 2002 @ 17:03:34 GMT
| Subj: | | Re: When to archive dictionary tables |
| |
| From: | | Anomy Anom |
<-- Anonymously Posted: Tuesday, October 29, 2002 11:31 -->
| | We want to move data via MVS ARCMAIN to another Teradata system with different configuration. | |
| | The question: If we are NOT using cluster archives to move the data (i.e. we are to do any dictionary table archive? | |
| | You can get away with it, if you create a script to recreate all databases (including space allocation), users (including space and
spool allocations), and access rights. A DBC restore will create all of these automatically. | |
Just to clarify... a DBC data dump and restore will recreate all databases, users and access rights, i.e. ARCHIVE DATA TABLES
(DBC)
There is no need for "dictionary" dumps if you are not dumping clusters, i.e. ARCHIVE DICTIONARY TABLES (databasename). But you need to
do database level data dumps & restores rather than table level data dumps & restores, in order to restore the dictionary for your
tables.
Ideally, you need to be able to restore all your tables on the new machine before creating any tables there, or you'll likely run into
duplicate table ids on your restores and be forced to change them to "copies" instead. These create tables with new tableids, losing any
accessrights that existed at a table level.
If you use permanent journals, you need to empty them and dump them on the old machine: i.e. ARCHIVE JOURNAL TABLES (databasename), and
then restore the dictionary from the journal dump on the new machine: i.e. RESTORE DICTIONARY TABLES (databasename), in order to get the
definitions back so that you can then restore the tables that use journaling.
| |
