Fallback

Database
Enthusiast

Fallback

HI ALL,
Can anyone explain difference bwn down amp and fallback amp.
How fallback and journals are used in teradata?

Cheers,
9 REPLIES
Enthusiast

Re: Fallback

Hi Smilever,

Down amp is the one which is not in use(or temporary breakdown) because of hardware or software failure.

Fallback Amp is a feature of teradata through which it retains the data in breakdown amp. Through fallback mechanism the data of one amp will be stored on other amps inorder for recovery as well as to provide the user uninterrupted service.

For more details on fallback and journals check out the teradata documentation available online. (not sure where u can get, may be in TERADATA.COM/EDUCATION)
Enthusiast

Re: Fallback

As mentioned by Jagdish, Down AMP is the Vproc that is not operational due to some hardware and software failure.

Fallback is the mechanism to maintain a duplicate copy of data managed by a different amp.When a Vproc(AMP) goes down during a load process the data is written to Fallback AMP.Once the down AMP comes online the Data is rebuilt using the FallBack AMP.

Journaling is another important feature in teradata.During a transaction teradata would maintain a copy of before or after images of table data .If the transaction fails due to any reason the table is restored back to the point from where the data images have been maintained.

However,Fallback and Journaling are expensive in terms of storage and maintenance.

rgs
Enthusiast

Re: Fallback

Hmm, so far the explanations are only partially correct concerning fallback. Fallback is a mechanism which keeps two copies of rows for a table where the second copy is kept on different AMP(s) in a cluster. AMPs are logically organized in clusters. If a cluster consists of 4 AMPs each of those AMPs exist on a different node. It would make no sense for the all of the AMPs to be on the same node. When all AMPs are up and a table is updated the primary row is updated and that primary row change is sent to one of the fallback AMPs in the cluster (one of three if a 4 AMP cluster). I am going to leave out some detail here on how it is organized exactly, but all AMPs send their primary rows to one of the other 3 AMPs. So with 4 AMPs in the cluster each sending updated rows we end up with a total duplicate of the rows in the table but spread out among the 4 other AMPs in the cluster. Now if a node goes down, one of those AMPs would not be available anymore. But with fallback 3 AMPs in the cluster can handles the rows for the AMP that is down, since they all have copies of rows in their fallback copy of the table for the AMP that is down. So data can still be selected and it can be updated. If there is an update to one of the rows that belongs to the AMP that is down it skips updating the primary row and updates the fallback copy and it writes what is called a change row journal (contains the row id only, not data of the changed row) to let the system know that that row was changed and when the AMP comes back up to have it transfer the data that is missing on the AMP that was down. That missing data includes primary rows that are missing and fallback rows that that AMP is responsible for.

As far as journaling goes, there is Transient Journaling (TJ) and Permanent Journaling (PJ). TJ journaling is automatic and is only relevant for an in progress update transaction. It keeps track of the changes made by a transaction, so that if the transaction aborts or the system restarts the changes for the transaction can be undone (rolled back). If the transactions commits the data in the TJ for that transaction is no longer relevant and will be deleted from the TJ.

PJ processing is a user selectable option on a database which allows the user to select extra journaling for changes made to a table. There are more options and the data can be rolled forward or backward (depending if you selected the correct options) at points of the customers choosing. They are permanent because the changes are kept until the customer deletes them or unloads them to a backup tape. They are usually kept in conjunction with backups of the database and allow partial rollback or roll forward for some corrupted data or operational error like someone deleted a months worth of data because they messed up the where clause, for example. That is a very brief overview and there is a lot more to it than that.

Fallback costs disk space and processing time as well as PJ rows, so one has to weigh the options carefully. The options are selectable individually per table. So you might use those options on the most critical data. Best to read the Administrator and Database Design documentation to figure out the options, because there is a lot more to it than described here.
Enthusiast

Re: Fallback

So If I am to differentiate between Fallback and Journal, It can be ...
"Fallback just contains the current copy of the original row while journal maintains a complete history of the changes for that row by storing rowid and the change that took place"

Kindly let me know if i am view is correct or not

Regards
Enthusiast

Re: Fallback

You are essentially correct, but I would amend "complete history" to "some history, depending on the kind of journal". Teradata has several kinds of journals, each serving a different purpose. For a complete answer, you should specify which kind of journal you mean.
Enthusiast

Re: Fallback

@Jim
I was considering just a general case of difference between fallback and Journal.
As for my understanding.
Transient Journaling == Some History
Permanent Journaling == Complete History
Fallback == Current Copy

Regards
Enthusiast

Re: Fallback

Hi  all,

Based on the discusson above...I understand  that Permanent Journals and Fallback are independent of each other .There is no dependency as such on each other.... i.e

a) we can have P.J with out fallback..

b)similarly  Fallback with out a P.J ..

Please correct me if i am wrong or add some thing here.

Cheers!

Nishant

Junior Contributor

Re: Fallback

Hi Nishant,

yes, you're correct :-)

Dieter

Enthusiast

Re: Fallback

Hi Dieter,

I am using TD 12. When i created a user via TD Administrator, i saw in the create user script fallback and permanent journal options are available. This means that all the fallback, PJ  are applicable to user level also. Are these the data integrity measures at user levels? Please advise.