CurrentPerm different after restore

Database
Enthusiast

CurrentPerm different after restore

Hi there,
I'm hoping this will be an easy answer for somebody but I just have a question about CurrentPerm differences before and after a restore.

We are noticing instances where the CurrentPerm being used by databases/tables seems to be different after we restore them onto our backup machine.The DDL is the same,the data is the same,there are no changes to the tables.But we can still see instances where the table(once restored into the backup box) is either taking up more (or less) space than before.The machine we are restoring to is the same as the prod machine.
Are there some system settings that might not be matched?

Any help appreciated.
Marcus
2 REPLIES
Enthusiast

Re: CurrentPerm different after restore

How large of a discrepancy are you finding? Are you doing any journaling on or online archiving of the tables in question

The first thing that comes to mind is fragmentation from cylinder splits. Secondly, are the default datablock sizes the consistent between environments either at the table definition or DBSControl level?
Enthusiast

Re: CurrentPerm different after restore

It is very common. Restore essentially does a row (not block) level restore - because the system you are restoring to may not have the same hardware config or hashmap.
So when it restores, you get a perfectly "clean" copy of the table with best case blocksizes. Even though Teradata cleans up after itself really well, there can be some unused space in blocks over time which does not occur after a restore.
It is not a problem, and there are no system settings which will affect it.
In my experience, the restored table is usually smaller. The only instance I can think of where it will be bigger is of the freespace percent on the table is increased and then a restore is done.