X

Best Practices from Oracle Development's A‑Team

Oracle GoldenGate Best Practices: Testing Maximum Performance of Disks in UNIX

Introduction

This document will detail how to calculate maximum disk read and write rates for a single process using the UNIX "dd" and "time" commands. Not covered in this document are performance differences using different RAID (redundantly arrayed independent disks) configurations, limitations of the system bus speeds and limitations of controller buffer speeds.

Main Article

Perhaps the most common bottleneck for replication is the speed at which data can be read from and written to disk. Therefore it is helpful to know a method for testing maximum read and write rates and match the IO chunks to what GoldenGate processes are doing. This will help to communicate with disk managers using empirical data and help set customer expectations doing load tests. For example, if a customer wishes to load test with 100GB of transaction logs per hour and the disk read rate is less than 100GB/hour then it becomes physically impossible based on hardware limitations.

Regardless of other factors not covered in this document, using a single process to get a baseline for IO keeps it simple and is acceptable for understanding a system's basic IO capabilities.

It is important to note here that once a read test has completed the input file is likely in cache and subsequent tests on the same file will be faster because the read is coming not from disk but from the IO cache. Therefore back-to-back read tests should be done using different input files. While it is nearly impossible to determine what is in the IO cache, the older an input file is the better the chance it has not been cached.

This author of this document is Joe DeBuzna, Product Manager for Oracle GoldenGate

The complete document can be found on the Oracle Support site under the document ID:1356855.1

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Recent Content