All Forums General
yiannish 13 posts Joined 06/14
30 Sep 2015
How to calculate the space of a database that data will be copied using arcmain

Hello Guys
I have a Teradata 14.10 on a TD 2690 appliance with BLC enabled on all tables.
I am using the TD Appliance backup Utility to copy backed up data from backup files into a new database.
I know the size of the backup files is the size before BLC is applied and it is 7551855 bytes. 
So i create a new database with double the space 15103710 bytes.
When i run the copy operation using the Teradata Appliance Backup Utility 14.10 i get a No more spool space error.
Why is that happening?
How much more space should i give to the database that the data will be copied?
Thanks in advance.

Glass 225 posts Joined 04/10
30 Sep 2015

Check the spool space for the user running the job, you should receive a "no more room in Database"  error if the issue is database space.

Fred 1096 posts Joined 08/04
30 Sep 2015

The user running the COPY needs enough spool space to rebuild secondary indexes after base rows have been copied.

yiannish 13 posts Joined 06/14
01 Oct 2015

Hello again and thanks for aswering.
SOrry I have made a mistake. The actual error i get is Failure 2843:No more room in database. 
The no more spool space error is refering to the database that the data are being copied not the users Spool space as Glass correctly pointed out.
The problem is why do i get this error since i already gave enoung space(double the space of the backup files) for the data to be copied
See my attachment from the arcmain log.

seven11 26 posts Joined 12/09
05 Oct 2015

There are a couple of variables that someone with better database knowledge might be able to answer.
If you are just copying tables within the same system I would have thought an insert-select would be way faster/easier
Taking the worst case senario which is you are restoring to a database/table that is not applying compression (BLC) at the target hence you are running out of free space.  I was under the impression with the default DBS Control settings and as long as you aren't overriding the default settings a copy/restore will try to keep the same compression state as the original.
When ARC requests data from the database the node will uncompress the data before handing it over.  You should be able to do a rough calculation by adding up the byte count in the logs or just look at the size of the dump file(s) from ABU if sitting on an uncompressed filesystem, you can take either of these numbers and add another 20% for BUILD and spool space.
Once you have everything restored and settled you can reduce/remove the permspace down again if required
I think the median compression ratio for BLC is 3:1 for standard data but I have heard in some cases this can be magnatudes higher, looking at the partial screenshot it looks like you only got up the "E" since ARC usually does thing alphabetically and assuming the bulk of the object/data is not between A - E it is likely to be higher than 3:1.

ToddAWalter 316 posts Joined 10/11
06 Oct 2015

The files shown in your log sample are all very small. If the space you have allocated is also small and close to the size of the data of the tables, then you could get this error due to having to place a table header on every AMP and/or because one or more of the tables is skewed. It is often true that very small tables are skewed and since space is allocated per AMP, that skew can cause the out of space error even though other AMPs have space available and the total space is greater than the bytes for the table.

yiannish 13 posts Joined 06/14
12 Oct 2015

Indeed the database was very small thus it required more space. 
My database is 7MBs after decompressions but in order to restore(COPY) it back i needed a space 7MBs * 15.
I have done a backup and restore of a larger database (about 5GB) and i gave the database that the data would be restored a space of 5GB * 3 and the error of no more space didn't occured.
Thanks a lot

You must sign in to leave a comment.