Assessments - 0, GPA: 0
(
)
)
|
por este dispositivo também tem outras instruções :
Computadores - HP Integrity NonStop H-Series (16.73 mb)
Computadores - HP Integrity NonStop H-Series (957.56 kb)
Computadores - HP Integrity NonStop H-Series (881.66 kb)
Computadores - HP Integrity NonStop H-Series (965.62 kb)
Computadores - HP Integrity NonStop H-Series (676.93 kb)
Computadores - HP Integrity NonStop H-Series (393.72 kb)
Computadores - HP Integrity NonStop H-Series (776.57 kb)
Facilidade de uso
Recovery Strategies
Parallel Considerations
DataLoader/MP process quits. This strategy propagates through the whole multi-
process application, terminating each process. When the error involves data in the
records DataLoader/MP is processing, DataLoader/MP logs the record together with
the error to its error log file specified with the -E parameter.
A common loading scenario is to create multiple DataLoader/MP processes,
configured with a single upstream DataLoader/MP process that reads an input file and
distributes the records to a number of downstream DataLoader/MP processes, which,
in turn, write the data to the database. Which of these processes should maintain the
restart file?
The upstream DataLoader/MP process would seem to be the obvious choice; however,
there are problems with that approach that have nothing to do with recovery. The
upstream DataLoader/MP process does not actually alter the database but only sends
records to each downstream DataLoader/MP process for them to perform the updates.
Suppose the single upstream DataLoader/MP is doing the transaction bracketing and
keeping the restart file. When it comes time to commit a transaction and update the
restart file, the upstream process has no way to determine whether all the work
intended to be in the transaction has actually been done. Furthermore, there is no way
for the upstream process to know how long to wait before the work is done and it is
safe to commit the transaction. If it commits the transaction before all the work is
finished, one or more of the downstream DataLoader/MP processes will receive an
error indicating that it had a stale transaction identifier when it finally tries to perform
work included in the now-committed transaction.
As a result, in a multi-process DataLoader/MP application it is not practical to use
transaction bracketing in the upstream DataLoader/MP processes. If you use
transaction bracketing, it must be done in the downstream DataLoader/MP processes.
Parallel Considerations
It is common to create loading scenarios using parallelism for increased performance.
This is normally done by having an upstream DataLoader/MP process that reads an
input file and distributes records to multiple downstream DataLoader/MP processes.
You can accomplish this in two ways. One is to have the downstream DataLoader/MP
processes read from the upstream DataLoader/MP process. This method is self-
balancing because each process can get another block of records as soon as it has
finished its current block of records. Downstream processes that are running fast
because they are in CPUs with little competition can read as many records as they are
able and are not held up by other downstream DataLoader/MP processes that are
running in a busy CPU.
The second way is for the upstream DataLoader/MP process to write records to the
downstream DataLoader/MP processes. This method is not self-balancing. A slow
downstream DataLoader/MP process can hold up distribution of records to all the other
downstream DataLoader/MP processes. However, this method can be restarted if you
use the method of restarting from a known state that is done using -T.
DataLoader/MP Reference Manual—424148-003
7 -8
... Este manual também é adequado para os modelos :
Computadores - HP Integrity NonStop J-Series (538.24 kb)
Computadores - HP NonStop G-Series (538.24 kb)
Computadores - HP NonStop L-Series (538.24 kb)