The first thing to consider (and probably one of the most important steps in any IT project) is the design. If you get this wrong, your system will neither perform nor be scalable and ultimately the project will fail. The last thing you want to do is to start again from scratch!
So, how do you design your GoldenGate implementation? Where do you start? What is important in the design? What features should you include? There are obviously a lot of questions, so let's try and answer them.
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:
The overall system architecture and all of its components and interfaces. Ask yourself the question: "What data do we need to replicate and where does it need to be replicated?".
For the non-functional requirements, you need to know:
The maximum latency that is acceptable. Again, ask yourself the question: "How far behind the source can the target system(s) be?".
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.