Chapter 8. Managing Oracle GoldenGate

Managing your Enterprise can be a real challenge, especially when there are multiple sites and distributed databases. We need to keep a close eye on things, ensuring that systems remain operational and efficient by checking whether the databases are open, data replication is running with minimal lag, and adequate space is available in both the databases and filesystems, the list goes on.

Oracle offers a web-based product called Oracle GoldenGate Monitor 12c to manage and configure GoldenGate instances, but we will focus on the management features already built-in GoldenGate and implement a number of options and utilities, including how to leverage Oracle Enterprise Manager 12c Cloud Control. Here, you will learn how to develop a metric extension to monitor your GoldenGate environment effectively at no additional OEM license cost.

This chapter includes discussion on the following topics:

• Command-level security

• Managing the trail file

• Managing the process startup...

The Oracle Management Pack for GoldenGate

The Oracle Management Pack for GoldenGate comprises of the following three software products, each of which requires a license in addition to the Oracle GoldenGate 12c license:

• Oracle Enterprise Manager 12c Plug-in: This provides management, monitoring, and alerting on GoldenGate components

• Oracle GoldenGate Monitor 12c: This is a standalone product dedicated to managing, monitoring, and alerting on GoldenGate components

• Oracle GoldenGate Director 12c: This is a standalone product that provides basic management, monitoring, and alerting on legacy GoldenGate deployments

We will focus on the GoldenGate Monitor product because this has received a number of new features in the 12c version that enhance, manage, and monitor Oracle GoldenGate.

Oracle GoldenGate Monitor 12c

Oracle GoldenGate Monitor was first released by Oracle Corporation in the 11g Release 1 version to replace the aging Oracle GoldenGate Director product. However, Oracle GoldenGate Director...

Command-level security

In the previous chapters, we discussed GoldenGate's command-line interface (GGSCI) in detail, conveying many useful commands, some of which are information only, while others change or add to the configuration. This could be deemed as a security risk, allowing users to misconfigure or even delete valid processes, potentially breaking your GoldenGate environment.

To avoid this risk, GoldenGate has a security feature that protects the environment at the command level. Here, users are restricted in the commands that they can execute from GGSCI.

The CMDSEC file

To enable Command-level security (CLS), we must first create a CMDSEC file in the GoldenGate Home directory. This text file should be created by the user responsible for the central administration of GoldenGate (normally oracle). It contains the security rules and controls that allow users to have access to certain GGSCI commands. Secondly, we must create additional OS users that wish to access GGSCI, such as the ogg_user...

Managing the trail file

In a busy database environment, redo data generation can increase significantly, particularly with the required supplemental logging enabled on your source tables. As we know, an Oracle database will recycle its redo logs in a round-robin fashion, switching to the next log when full. GoldenGate scans the redo logs and writes its own trail files to the dirdat subdirectory. Although the trail file data is typically a quarter the size of its equivalent redo data, if left unmanaged, the volume of files in dirdat can be significant. In the worst case scenario, filling the filesystem to 100 percent utilized. Obviously, this is not ideal, so GoldenGate has provided its own automated mechanism to purge trail files from this area.

This is achieved by configuring the PURGEOLDEXTRACTS parameter in the GoldenGate Manager parameter file as follows:

-- GoldenGate Manager parameter file
PORT 7809
PURGEOLDEXTRACTS ./dirdat/sa*, USECHECKPOINTS, MINKEEPHOURS 1

The USECHECKPOINTS option...

Managing the process startup

In a near real-time data replication environment, we don't want to incur high latencies or outages due to a process failure. GoldenGate has a mechanism to automatically restart Extract or Replicat processes, should they fail. The AUTORESTART parameter of the Manager process governs this and provides additional options on retry attempts.

-- GoldenGate Manager parameter file
PORT 7809
AUTORESTART EXTRACT *, RETRIES 3, WAITMINUTES 1, RESETMINUTES 60

• RETRIES: This option sets the maximum number of times the Manager process attempts to restart a process.

• WAITMINUTES : This option sets the delay in minutes between restart attempts.

• RESETMINUTES: This option sets a window of time that retry attempts are counted. After the time expires, the retry count returns to zero.

In addition, the AUTOSTART parameter enables automatic startup of either the Extract or Replicat processes when the Manager process starts.

The following is the code for the Manager process parameter file...

Managing TCP/IP errors

GoldenGate automatically handles TCP/IP network-related errors. The actual response, the delay in responding, and the maximum number of retries are configured in a text parameter file named tcperrs. This file can be found in the GoldenGate Home directory.

Any errors occurring at the network layer are written to the ggserr.log GoldenGate log file, which is also located in the GoldenGate Home directory. These errors are categorized as WARNINGS.

The following code lists the default configuration in the tcperrs file:

# Error         Response    Delay (csecs)    Max Retries

ECONNABORTED     RETRY        1000               10
#ECONNREFUSED    ABEND           0                0
ECONNREFUSED     RETRY        1000               12
ECONNRESET       RETRY         500               10
ENETDOWN         RETRY        3000               50
ENETRESET        RETRY        1000               10
ENOBUFS          RETRY         100               60
ENOTCONN         RETRY         100      ...

Reporting and statistics

An important feature of any computer system is its ability to report and provide statistics on its availability and performance. GoldenGate offers a number of options to monitor status, latency, and throughput using its command-line interface.

To monitor errors and warnings, we can look beyond the GGSCI tool and in the log files, which we will discuss in the following sections.

Monitoring errors

It is important to note that errors detected by GoldenGate are not automatically alerted to network managers, sms gateways, or e-mail servers. Therefore, the GoldenGate administrator must proactively monitor the logs generated by GoldenGate, the OS, and the database.

This includes the following log file list (Linux):

• <GoldenGate_Home>/ggserr.log: This provides all GoldenGate INFO, WARNING, and ERROR messages

• /var/log/messages: This provides all Operating System INFO, WARNING, and ERROR messages, including GoldenGate processes

• $ORACLE_BASE/diag/rdbms/$ORACLE_SID/trace/alert_...

Summary

Having installed and configured your GoldenGate environment, this chapter has taught us how to manage, monitor, and secure its command-line interface. You learned the configuration options that enable historic and real-time reporting and statistics, providing the necessary information to fully support and manage your GoldenGate environment.

This chapter has also provided bespoke solutions to enhance GoldenGate monitoring and reporting through OEM 12c Metric Extensions.

The next chapter is dedicated to performance tuning, where you will learn how to use the configuration options and techniques described in this book in order to enable and maintain real-time data synchronization.