Also your times for “commit wait” are twice as much compared to mine. And we’re both fiber channel.

This is an active box, so there are a few stray waits showing up.

SQL> DECLARE
2 PROCEDURE do_loop (p_type IN VARCHAR2) AS
3 l_start NUMBER;
4 l_loops NUMBER := 10000;
5 v1 NUMBER;
6 v2 NUMBER;
7 BEGIN
8 EXECUTE IMMEDIATE ‘ALTER SESSION SET COMMIT_WRITE=”’ || p_type || ””;
9 EXECUTE IMMEDIATE ‘TRUNCATE TABLE commit_test’;
10 EXECUTE IMMEDIATE ‘select TOTAL_WAITS from v$system_event where event like ”log file sync%”’ into v1;
11
12 l_start := DBMS_UTILITY.get_time;
13 FOR i IN 1 .. l_loops LOOP
14 INSERT INTO commit_test (id, description)
15 VALUES (i, ‘Description for ‘ || i);
16 COMMIT;
17 END LOOP;
18 EXECUTE IMMEDIATE ‘select TOTAL_WAITS – ‘ || v1 || ‘ from v$system_event where event like ”log file sync%”’ into v2;
19 DBMS_OUTPUT.put_line(RPAD(‘COMMIT_WRITE=’ || p_type, 30) || ‘: ‘ || (DBMS_UTILITY.get_time – l_start) || ‘ — TOTAL WAITS: ‘ || v2 );
20 END;
21 BEGIN
22 do_loop(‘WAIT’);
23 do_loop(‘NOWAIT’);
24 do_loop(‘BATCH’);
25 do_loop(‘IMMEDIATE’);
26 do_loop(‘BATCH,WAIT’);
27 do_loop(‘BATCH,NOWAIT’);
28 do_loop(‘IMMEDIATE,WAIT’);
29 do_loop(‘IMMEDIATE,NOWAIT’);
30 END;
31 /
COMMIT_WRITE=WAIT : 934 — TOTAL WAITS: 10022
COMMIT_WRITE=NOWAIT : 131 — TOTAL WAITS: 1
COMMIT_WRITE=BATCH : 132 — TOTAL WAITS: 0
COMMIT_WRITE=IMMEDIATE : 148 — TOTAL WAITS: 0
COMMIT_WRITE=BATCH,WAIT : 1035 — TOTAL WAITS: 10008
COMMIT_WRITE=BATCH,NOWAIT : 128 — TOTAL WAITS: 7
COMMIT_WRITE=IMMEDIATE,WAIT : 1070 — TOTAL WAITS: 10012
COMMIT_WRITE=IMMEDIATE,NOWAIT : 135 — TOTAL WAITS: 0

PL/SQL procedure successfully completed.

Elapsed: 00:00:37.84
SQL> /
COMMIT_WRITE=WAIT : 1137 — TOTAL WAITS: 10020
COMMIT_WRITE=NOWAIT : 130 — TOTAL WAITS: 1
COMMIT_WRITE=BATCH : 126 — TOTAL WAITS: 0
COMMIT_WRITE=IMMEDIATE : 132 — TOTAL WAITS: 0
COMMIT_WRITE=BATCH,WAIT : 1049 — TOTAL WAITS: 10019
COMMIT_WRITE=BATCH,NOWAIT : 126 — TOTAL WAITS: 2
COMMIT_WRITE=IMMEDIATE,WAIT : 1041 — TOTAL WAITS: 10013
COMMIT_WRITE=IMMEDIATE,NOWAIT : 131 — TOTAL WAITS: 6

PL/SQL procedure successfully completed.

Elapsed: 00:00:39.70
SQL> /
COMMIT_WRITE=WAIT : 945 — TOTAL WAITS: 10001
COMMIT_WRITE=NOWAIT : 144 — TOTAL WAITS: 0
COMMIT_WRITE=BATCH : 127 — TOTAL WAITS: 4
COMMIT_WRITE=IMMEDIATE : 130 — TOTAL WAITS: 4
COMMIT_WRITE=BATCH,WAIT : 962 — TOTAL WAITS: 10016
COMMIT_WRITE=BATCH,NOWAIT : 126 — TOTAL WAITS: 0
COMMIT_WRITE=IMMEDIATE,WAIT : 998 — TOTAL WAITS: 10021
COMMIT_WRITE=IMMEDIATE,NOWAIT : 145 — TOTAL WAITS: 0

PL/SQL procedure successfully completed.
Elapsed: 00:00:41.58

There is a lot of internals that we dont know about and only overhear from rumors. Such as
- per cpu pools – redo buffer is split in multiple latches based on number of CPUs
- private redo – a session will get it’s own region in the redo buffer for “private” use
- redo reservation – similar to above feature
- commit extra options – now you can “commit” in memory, without even telling log writer to flush. (commit batch nowait)

For these reasons, it’s always good to have a larger buffer to allow these optimizations to take place.

The worst that can happen is that this memory “is wasted” and never used. There’s other negative impacts, but we’re comparing 3 mb vs 30 mb, not < 3 mb.

So in my opinion, just set it large and dont worry about it. I set it to 32-64 mb.

I’m interested in your thoughts.

The disk rotation is 5400 rpm. Thats 60 / 5400 = 0.01111 sec per rotation. This means, if the heads are in position, it could still take up to 11 ms before they can write. On the data sheet (the pdf on the link you gave me) it sais “Average Latency (msec) 5.6″. Which is exactly half the rotation latency, so it makes sense.

Your commit latency: 0.3 ms
Your HDD’s average latency: 5.6 ms

The data is been cached somewhere. Most likelly it’s the HDD’s cache. Check this article:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-disk.html

Section 11.12.1.5.

“….The problem is that IDE drives lie about when a write completes. With IDE write caching turned on, IDE hard drives not only write data to disk out of order, but will sometimes delay writing some blocks indefinitely when under heavy disk loads….”

You can try turning off write caching from the device manager, rebooting and retrying the same test.

Properties on my computer
hardware tab
device manager button
open Disk drives tree
double click your drive
one of the tabs will have a “write caching” checkbox.

On my windows XP laptop (single ide 5400rpm disk – (details at seagate) and 1gb ram) 10.2.0.1 gets the following results

SQL> set timing on
SQL> set autotrace on statistics
SQL> declare i number;
2 begin
3 for i in 1..10000 loop
4 insert into c_test values (55);
5 commit;
6 end loop;
7 end;
8 /PL/SQL procedure successfully completed.Elapsed: 00:00:01.16
SQL> declare i number;
2 begin
3 for i in 1..10000 loop
4 insert into c_test values (55);
5 commit write wait;
6 end loop;
7 end;
8 / PL/SQL procedure successfully completed.Elapsed: 00:00:03.03
SQL>
I don't have 10.2 on a SAN anywhere (and commit write nowait/wait is a 10.2 thing I think not a 10g thing).I don't have 10.2 on a SAN anywhere (and commit write nowait/wait is a 10.2 thing I think not a 10g thing).

I don’t have 10.2 on a SAN anywhere (and commit write nowait/wait is a 10.2 thing I think not a 10g thing).