By default, Fallback creates two additional copies of each row and keeps in different AMPs, Is there any option if I want increase the number of copies ie., for example if I want to create 10 copies of each row and keep it on 10 different AMPs. Please advise.
Thanks in advance.
Fallback is an optional, and make one aditional copy of each row.
You must remember that these records doubling with RAID 1.
Space is not infinite.
Can you share what you are trying to accomplish?
fallback today can make a single additional copy of the data which will be placed on a different part of the configuration such that it it protected from multiple HW failures.
The exact requirement is as following:
In the UDF we test two data sets against each other.
Dataset A – The materialized decision tree. (security rules)
Dataset B – The transaction data.
For example we've 4 AMP system.
For example dataset A looks like:
So data distributed over 3 AMPS
The transaction data looks like
D, B, D
So 9 records, 1 amp with 3 record; 3 amps with 2 records.
The yellow marked records should be matched, however does not happen.
The bold underlined record should be matched, and are matched.
The yellow marked records are not matched as the relevant rule is not on the same amp as the transactional record.
Due to this we want to have the rule set (the three records) fully distributed over all amps. E.g. all rules available on all amps.
This is important as the UDF logic runs on the AMP… and only uses the data that is available within the AMP. So if a rule set record is not available, than we get incomplete result sets.
Sorry colour is not visible, yellow marked records are 'B' from first row (D,B,D)of transactional data and 'C' from last row (G, C) of transactional data.
Bold undelined record is 'B' from second row (F, B) of transactional data.
The records are storage in the AMPs by the hash of the columns selected for Primary Index, then the same PI = same AMP
You no has independent access to the Fallback table, there is an object of exclusive use of TD engine.
A UDF in Teradata operates on the parameters provided to it rather than doing any local reads on their AMPs.
think in terms of creating an appropriate join and applying the UDF to the result of the join. In this case, you want an unconstrained join to the rules table. The optimizer will duplicate the rules table dynamically an do the join, then you can execute the UDF with parameters from both tables.