Your eye into the buffer cache

ever asked yourself what is going on in the buffer cache? e.g., does oracle honour my settings for the different buffer cache types, that is, the default, keep and recycle cache? or, does oracle tune the buffer cache nicely, such that the application important database objects are in fact cached?

the latter is, however, not only oracle’s duty. imagine an application where there is an index missing on a large table. on every unindexed select, oracle will have to full scan the table, flooding the buffer cache with unwanted blocks. but how to trap this scenario?

the solution key is v$bh or, internally, x$bh, a system view that allows a blockwise inspection of the buffer cache. some pretend that v$bh has been introduced with oracle parallel server (ops), others relate it to the real application cluster (rac) environment.

Redirecting dbv output to a file

this is a short note for everyone, who is still wondering why a simple shell construct like a redirect operator to a file won’t work for dbv (dbverify).

imagine a situation where you’re about to dbv-scan a good couple of datafiles and want to concatenate the output into a summary file. one approach is, probably, to just redirect/concatenate the output of dbv using >, create or cleanup the file, and >>, append the file, like so (please do not kick me for the weird “>” formatting below, the view plain link will show it correctly):

dbv file=c:\data01.dbf > dbv.log
dbv file=c:\data02.dbf >> dbv.log

however, the resulting file will be empty. the reason is, that for whatever sake, dbv does not write write to channel stdout, as one might expect, but to channel stderr (???). a simple trick to circumvent this issue is to overlay stdout and stderr by writing:

dbv file=c:\data01.dbf > dbv.log 2>&1
dbv file=c:\data02.dbf >> dbv.log 2>&1

here, the channel stdout is denoted by 1 and stderr by 2, respectively. to have it complete, channel stdin is usually identified by 0, if anyone may need to know it.

the same is, by the way, true for loadjava.

regards

The performance trap of acclaimed applications

Stumbled upon the following text lately. It originates from the (german only) book Oracle 10g Hochverfügbarkeit (High Availability) by Andrea Held. Have a try at it, this is real truth.

There exists an ever reoccuring problem that an application has only been sized for a medium amount of data, but, due to an ongoing acceptance on the users side, grows in terms of functionality, load and complexity. It is only a matter of time until defined maintainance windows become to small to load and process all the data. Likewise, selects and reports cumulatively offer worse performance. If there is no early time effort to customize the whole application architecture according to the increasing requirements, sooner or later a massive performance crash will have to be experienced.

Regards and welcome to the club