I compared the system statistics we got before with the current one: the first one is the metric before, the second is the metric we have now, and the third value is the percentage increased. redo blocks written 66,777,507 45,417,168 -32% in our previous test, the application TPM is higher, thus the redo blocks written is higher, this is reasonable. however, the following metrics seems abnormal: redo blocks checksummed by FG (exclusive) 4,122,706 8,741,271 112% redo synch long waits 9,759 106,017 986% redo synch time 26,950,595 35,266,236 31% redo synch time (usec) 269,505,943,171 352,662,539,336 31% redo write broadcast ack count 39,923 96,618 142% redo write broadcast ack time 254,688,838 686,018,713 169% redo write broadcast lgwr post count 1 1,142 114100% anyone has any clue about what does the above metrics mean and where is the bottleneck of a LGWR SYNC wait? 2012/11/26 Suya <suya.huang@xxxxxxxxx> > Hi, > > I have a four-node RAC system, the workload runs against the database > waits on log file sync heavily, average wait time is 82.41 ms, account for > 75% DB time. The system CPU resource is rich enough, average 70% idle time. > > similar testing was done previously, which has log file sync wait with > average 40 ms, and because the CPU resource shortage, this time, we added > two logical CPU to the system. but see that the log file sync wait event > was even worse. > > any ideas on what else I should check in the AWR report? > > Thanks! > Suya > -- //www.freelists.org/webpage/oracle-l