D&C Lug - Home Page
Devon & Cornwall Linux Users' Group

[ Date Index ][ Thread Index ]
[ <= Previous by date / thread ] [ Next by date / thread => ]

Databases and Journaling Re: [LUG] Power Surges & Gnucash



Pete Hatton wrote:

I had a 20meg 12,000 record database to import, whuich had a few fulltext
indexes.  On a ext2 it took about 3 minutes.  On a ext3 system I gave up
waiting (After 30mins)

I can't comment on the specific case, but it is a well known
general case that you only want one layer of journalling for
databases.

Typically on Oracle these days you are using Veritas journal
file systems (on proprietary Unix boxes), Oracle performs it's
own journalling, so you specify mount options for the databases
journals file system(s) that let them do a lazier form of
update.

You ideally want one "blocking write" when someone presses the
"commit" button in a database app. i.e. you only want the user
to have to wait till one copy of the data is safely on disk
before moving on to other stuff, the other changes to the
database can usually be done as needed to minimize disk
activity.

If the database journal log is on a journalled file system, you
can be doing several such actions, with disk seeks chucking in
15ms delays everytime. Even more of a problem on low end systems
where disks consist of real disks, rather than the vaguaries of
hardware RAID systems where sometime you are writing to
redundant cache, rather than disk (Eek).

Fortunately you usually only have to think about this once when
building a database server.

The semantics of file system metadata handling are also worth
thinking about, but that is another story. All such beautiful
low level tuning is of course (frequently) obliterated by one
bad bit of SQL, or poor design of application locking - che sera
sera.

--
The Mailing List for the Devon & Cornwall LUG
Mail majordomo@xxxxxxxxxxxx with "unsubscribe list" in the
message body to unsubscribe.


Lynx friendly