Design considerations

You have already seen the different solutions GoldenGate has to offer at the beginning of this chapter. You need to choose the most appropriate architecture based on the business requirements. To do this, it is necessary to first understand the scope and what the system has to achieve. These requirements are both functional and non-functional. The examples of non-functional requirements are performance and scalability.

To address the functional requirements, you need to know:

For the non-functional requirements, you need to know:

These are all the important factors you need to know while considering a design. In the earlier section 12c new features, we learned that the Replicat process can dynamically spawn multiple slave processes to increase data throughput. The maximum number of parallel threads configured is largely dependent on the hardware footprint that must also be considered. For example: How many CPU cores shall I have? How much server memory should I choose? What network bandwidth is available?

Other areas to consider are the network and database schema design. Starting with the network, this is fundamental to a data replication solution. If you have a slow network, you will not be able to replicate high volumes of data in real time. Furthermore, should your network be unreliable, you will need to consider the cost of retransmission or transmitting a backlog of trail files. Redundant networks are very important too and can help to alleviate this problem. If you can avoid the network outage altogether by routing data over a backup network, it will save a number of problems.

Database schema design is another important consideration. Imagine a schema where every table is related to nearly every other table, and the cascading referential constraints are so complex that it would be impossible to logically separate groups of related tables for data extract. GoldenGate does provide a solution to this problem. However, this solution is not ideal. GoldenGate has to spend more CPU time processing the incoming data stream and coordinating the delivery across multiple parallel slaves. A good schema design would be to ensure that logical separation exists between table groups, allowing a simple, effective configuration that performs well; the number of table groups being directly proportional to the number of Extract processes configured.