Hately, Mike (NESL-IT) wrote:
Yes, the lessons I took from that presentation were to use a shorter piece of string and buy larger bottles of gin though I'm willing to admit that I may have got the wrong end of the stick.=) Cheers, Mike -----Original Message----- Sent: 02 January 2003 09:24 To: Multiple recipients of list ORACLE-L First of all I'd like to have the full picture of your performance: Log file sync might be 57% of the wait time, but how much of the response time is wait time? Second, Log File Sync means Commit; So if your system is waiting a lot for commits there are two things you can do: Fewer commits (changes to applications) or faster commits (hardware striping, etc.). No changes to the log buffer will help here (except perhaps making it smaller, as Connor McDonald so brilliantly showed during the funniest presentation I've ever seen in my life at UKOUG in Birmingham). If the log buffer is being flushed constantly, it's better to make it small so that it doesn't have to go through the whole thing every time. Mogens VIVEK_SHARMA wrote:What ALL may be Done to Address the Following ? Any /etc/system , init.ora parameter Changes too ? Moving the Online Redo Logfiles onto RAID 1 NOT possible as that maywarrant Additional Hardware . Moreover T3+ does NOT Support RAID 1 (Only RAID 1+ )Concurrent Oracle processes = 1500 Approx. Statspack Taken during Mostly OLTP Operations :- Top 5 Wait Events ~~~~~~~~~~~~~~~~~ Wait %TotalEvent Waits Time (cs) WtTime-------------------------------------------- ------------ -------------------log file sync 970,563 2,597,83157.46log file parallel write 831,141 484,94810.73log_buffer = 2MB Online Redo Logfiles Exist on RAID 1+ Storage Box is T3+ File System = UFS Application = Banking (Hybrid ) Oracle 8.1.7.4 Solaris 8 Machine Box = SF6800
