In this case, the invocation of the trigger can be used to save changed records of interest to a persistent storage area for retrieval. One drawback to this approach is that it should only be used in cases where the number of events captured is within the system's performance limits. For example, if all updates to a table are captured, this method creates twice the workload for the database. An additional problem with this approach is that it requires that the granularity of the information in the target database match that of the source database. One benefit to this approach is that data capture occurs at the source of the data and, therefore, both the before and after image are available.
Transaction log capture takes a slightly different approach to capturing the changed information.
This technique leverages the logging and recovery capabilities of a DBMS and, therefore, sequential and indexed files cannot take advantage of this method. Since the transaction logs are utilized by the DBMS as a place to store transaction information for logging and recovery, it is the ideal location to capture changed information without directly impeding the performance of the database. When reading the transaction logs, particular care must be taken to obtain only information that has been committed by the database. This technique limits the amount of work that the DBMS must perform, but an application must be written to monitor the log files and capture the data of interest. This technique is popular in some of the database replication techniques that are available today.