Question

Why should I use an agent installation?

Environment

Local Data Processing

Answer

In a data movement setup using Local Data Processing's hub and spoke architecture there is always an installation that plays the role of the hub. Local Data Processing installations that don't play the role of the hub are generally referred to as Agent installations. An agent installation always runs the remote listener to allow a hub to communicate with the agent. Refer to chapter 3 of the User Manual to set up the remote listener as a service to automatically start when the system (re)boots.
Even though Local Data Processing supports an agent-less setup for almost all database sources we recommend the use of agents:

• Through the hub and spoke architecture Local Data Processing implements a distributed setup. The agent offloads work that would otherwise have to be performed by the hub (often at the cost of additional resource consumption). The agent architecture makes the setup a lot more scalable.
• Communication between multiple Local Data Processing installations is optimized using densely compressed data and optimized large block transfer. Agent installations allow Local Data Processing to minimize latency despite relatively low bandwidth, and high latency connections (for example a connection across a Wide Area Network (WAN) into or out of the Cloud). An alternative to using an agent installation may be to use a remote database connection that is typically a lot more sensitive to low network bandwidth and/or high latency. Even if an agent installation on the database server is not possible then across a WAN it is still better to use an agent with a remote database connection to a database in the same data center.
• An agent installation is sometimes unavoidable in order for Local Data Processing to access database transaction logs with sufficient performance. High-volume environments may generate such large volumes of transaction logs that access to a database-stored procedure or function is simply not fast enough to read the logs over a SQL connection. Note Local Data Processing supports capture from standby systems on Oracle and SQL Server, and transaction log backup-only environments on Oracle, SQL Server, and SAP HANA.
• Source machine agent installations eliminate data at its origin to minimize data transfer across the wire. Databases always write more information to the transaction log than should be replicated, and in many cases, only a subset of the application tables is replicated to another system.

Note that generally Local Data Processing installations are both upwards and backward compatible so there is no mandate to always upgrade all Local Data Processing installations in order to benefit from new features or to get bug fixes. The Local Data Processing release notes always clearly specify what Local Data Processing installation(s) must be updated in order to take advantage of a new feature or implement a fix.