How Fallback actually works?

The Teradata Database channel includes discussions around advanced Teradata features such as high-performance parallel database technology, the optimizer, mixed workload management solutions, and other related technologies.
New Member

How Fallback actually works?

Hello Experts,

I got a question on how does physical access actually happens in Teradata for Fallback protected table. For expample lets consider that a perticular row for a fallback protected table is stored in Amp#1 and fallback row is stored in Amp#4 . Now when we fire a query on that table for that record , after passing though hasing algorithm it will find the amp# where the row is actually stored through Hashmap entry(i.e. Amp#1 for our example), but now lets consider at that point of time Amp#1 went down, hence now it has to access the fallback row.


Now the question is how does optimizer get to know that the fallback row is stored in Amp#4? As hashmap will only contain the Amp# where the primary row is stored. Who gives the address about the fallback row to the optimizer?

Teradata Employee

Re: How Fallback actually works?

The hashmap actually has two maps, the fallback map and the primary map. The optimizer does not need to know. It just hashes the PI and sends it. The hashmap maps the rowhash to a bucket which is mapped to an AMP and the lookup process knows which amps are online and whether it should look in the primary or fallback map.

This gets more complex with the Multiple hash Map feature. Each of the multiple hash maps has two maps - primary and fallback. But the hash algorithm is unchanged. The optimizer needs only to hash and the lookup process figures out which map to look in and whether to use primary or fallback.