Archives of the TeradataForum
Message Posted: Tue, 01 Jan 2002 @ 12:51:02 GMT
We fixed this in 4.1. :) We added an If to make sure we didn't lower the amount of space allocated to crashdumps on an upgrade.
Since you are migrating you tables from one System to another I assume this means you are going to start with a FULL backup of your v2r3 system and then restore those tapes to your v2r4 system.
Now if you didn't add anything system specific to SYS_CALENDAR, or SystemFE, then there isn't any problem. You can always rerun DIP and select just these 2 scripts after the migration is complete.
the GSC has Change Control Instructions on how to do this procedure. Typically it involves running the v2r4 DIPALL after the migration is completed.
I would be more worried about DIPACR (ACCESS RIGHTS) as when you run DIPALL after the migration is complete, it will grant to PUBLIC access to all of the system tables and views that Teradata deems PUBLIC.
This doesn't always jive with the Site DBA's and they remove access from some of the tables. DIPACR put these rights back and your DBA's will have to remove them again.
|Copyright 2016 - All Rights Reserved|
|Last Modified: 28 Jun 2020|