[ Date Index ][
Thread Index ]
[ <= Previous by date /
thread ]
[ Next by date /
thread => ]
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.