Yesterday, I did a couple of performance tests using Java/JDBC and
C++/OTL/ODBC to test INSERTs and DB PROC calls against a SAB DB 7.4
instance (OLTP) on Windows 2000.
I found that I can INSERT into a narrow table at more than
600 records/sec - even when committing after _every single_ INSERT
(Java/JDBC, unprepared SQL, autocommit off).
I wonder, this cannot be the case if log entries were written
fully synchronous. If the Log writer UKT would flush it's log
queue on every COMMIT, the performance could be at max. :
7.200 RPM / 60 = 120 records / sec
My harddisk does 7.200 rpms. Best case if the disk head does not
move at all, but log pages are written out just as the location
on disk passes the head. This is the case excatly 120 times/sec.
That is: Is the Log writer laszy by default? E.g. does it wait
until log pages are full to flush them to disk? Or is this a
Win32 specifica where Windows plainly ignores requests for
syncing file writes? How does SAP DB force a sync on Win32?
I know other RDBMS where there is stuff to activate like
"delayed commit" and "write combining" which trades in durability
(possibly integrity) for performance.
I've read through the manuals and sources and found the following
kernel options:
#define PAN_DELAY_LW "_DELAY_LOGWRITER"
#define PAN_DELAY_COMMIT "_DELAY_COMMIT"
typedef struct rte_xparam_record
{
...
tsp00_Int lDelayLW;
tsp00_Bool fDelayCommit;
However, those options are only used on 2 functions (with identical
signature):
VOID vdelay_lw ( PROCESS_ID pid )
but the functions seems to be unused (never called). Any hints from the
insiders?
Greets,
Tobias
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general
