The technique briefly depicted above fits in the batch scenario; a population occurs
at night, in the morning O&M operators see the errors, remove the cause,
and rerun the application in recovery mode. All the undo operations are coded in
the recoveryProcessUnit, and, if the causes of failure were transient or have been
removed, the system can recover the failed portion of the ETL job without human
intervention on DBMS.
In the NRT context, where a population cycle occurs every hour or less, the recovery
process needs to be managed in an automatic way as much as possible.
An H24 operator can hardly check the result of every cycle; the solution is to use
a standby recovery application. Therefore, there are two running applications: a
primary application instance that does its job at scheduled intervals and a recovery
application instance that checks the status of the primary and, if required, performs
the recovery, otherwise sleeps until next check. The recovery mechanism and the
status table are the same as we have seen before. Obviously, due to the absence of
human intervention, this mechanism can recover only transient errors (e.g., a lack
in the network).
Future.Trends.and. Conclusion
As the computational power of today??™s equipments grows, the performance constraints
become less strong. That is clear evidence in the whole computer science also valid
for ETL.
Pages:
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225