When focusing on the application, identify the redo-producing SQL, and then find ways to reduce the volume of redo generated over the period of concern. The metric we are interested in is the redo generated per second; that is, the redo generation rate. When focused on the application, we are more interested in the bytes of redo generated, rather than the number of redo entries or the number of log writer writes.

The redo generation rate in bytes can be gathered from both v$sesstat and v$sysstat looking at the statistic redo size. Gather a beginning and an interval ending value to calculate the redo generated over an interval and then dividing that by the interval time to calculate the redo generation rate. Both Statspack and AWR show the redo generation rate in their workload sections, labeling it simply "redo size." And the raw v$sysstat redo bytes generated during the reporting interval can be found in the Instance Statistics section. The number of redo writes (occurrences) is the instance statistic redo writes.

Reducing redo generation by directly altering the application is rarely practical, but can produce amazing performance gains. When an application needs to change data, it simply must change the data. Some developers tend to update every column, even though only one column was actually changed. But typically, a gain in this area is usually a batch processing-focused change, using Oracle's global temporary tables (discussed earlier in this chapter) during interim processing, or workload balancing. These types of changes nearly always result in long and cumbersome meetings, but the payoff can be dramatic and what may be needed to solve the problem.