Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Enable Recovery

Status
Not open for further replies.

cognos11

MIS
Nov 19, 2003
40
US
Can anyone of you share your experiences as to how to proceed further when your session fails inbetween after having comitted data.

Informatica docs says that you can choose ENABLE RECOVERY option before runnnig the session so that when the session fails after committing thte data, informatica remembers the last rowid that was committed before the session failure.
Next time when you run the session agai, it starts reading data from next row.

But what if there no time stamps on the target table to identify the rows that were written since the last session run.


Also if you have done some updates and some deletes, how do know which rows have been updated and which have been deleted.




Is taking a copy of the target table before every session run is a viable solution for this?


Please share your thoughts on this.





 
I'd say that the 'enable recovery' option is a rarely used functionality. It would be usefull when you are loading data into a table that has no key, cause you could avoid loading duplicates.
Since you are performing updates / deletions your target will have a primary key. So, rerunning the entire session will have the same nett result, though it will take more time to process all records.

T. Blom
Information analyst
tbl@shimano-eu.com
 
You could use source rather than target based commit in order to synchronise the updates of your target tables. If your source is a table, you could create a status column on it and update this for each row which is processed. This would mean that that the source and target updates are kept in sync so that your job is re-runnable from a particular point.

If you want even more control, you could use transaction control (6.x onwards) to define exactly when commits take place.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top