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.

The heavy redo-generating SQL will obviously be some type of DML, like inserts, updates, deletes, or perhaps create statements. If you have ASH licensed, as Figure 8-9 demonstrated, you can easily find the SQL related to the log file parallel write event. If ASH is not an option, two factors complicate identifying the SQL:

* The log writer background process posts the log file parallel write wait event, not a server process. The closest a server process will get to directly feeling the log file parallel write wait is when posting a log file sync or log buffer space wait events.