“Oftentimes, a database administrator (DBA) simply looks at the symptoms and immediately starts changing the system to fix those symptoms”
Op. Cit. Oracle Database Performance Tuning Guide 11g Release 2 (11.2)
Ok, let’s do this 🙂
- Finding Waits on event “log file sync” while performing COMMIT and ROLLBACK operations were consuming significant database time.
- Action Investigate application logic for possible reduction in the number of COMMIT operations by increasing the size of transactions.
If your application is committing too often- maybe Enterprise Manager told you so- you may want to commit less often. Or maybe just do some magic to impress your customer.
As seen on Metalink 857576.1, and if you can afford data loss, and if you cannot change your application, and if you are that kind of dba who cares more on good performing badly written application than on data integrity. just have a quick look …
Ok, ins.sql is 30’000 insert and commits,
insert into scott.t values(1);
commit;
insert into scott.t values(1);
commit;
insert into scott.t values(1);
commit;
Let’s check the time on my old-fashion pc…
SQL> select systimestamp from dual;
SYSTIMESTAMP
---------------------------------------------------------------------------
2011-08-29 20:40:55.881948 +02:00
SQL> @ins
SQL> select systimestamp from dual;
SYSTIMESTAMP
---------------------------------------------------------------------------
2011-08-29 20:41:19.115447 +02:00
23.3 seconds
Now take the risk to lose some commits (but yes it is documented, no hidden parameter) to boost your performance
SQL> alter session set commit_wait=nowait commit_logging=immediate;
SQL> select systimestamp from dual;
SYSTIMESTAMP
---------------------------------------------------------------------------
2011-08-29 20:43:37.284027 +02:00
SQL> @ins
SQL> select systimestamp from dual;
SYSTIMESTAMP
---------------------------------------------------------------------------
2011-08-29 20:43:54.084547 +02:00
Hey hey hey, 16.8 seconds only 🙂
PS: it used to be called commit_write in 10g
Shouldn’t the two select systimestamp statements be included in your “ins” script? Otherwise, the difference between the two times will depend on how quickly you type “@ins” and the last “select systimestamp …”
@jimmyb
You are right ! And I called “select systimestamp”,”@ins”,”select systimestamp” from another script, I did not type that fast 😉
Pingback: Understanding When and Why To Perform Oracle 10g Tuning | CompSights
Pingback: State of Data #65 « Dr Data's Blog