Just want to add my $0.03 on that. single file DB has some benefits as: 1. ability to allocate one continues chunk on disk, significantly reduces disk seeks, mostly ancestral but still true today ( I still see DB living on none arrays ) 2. And of cause countless design considerations.
Saying that corruption in single file DB more severe probably not true cause one way or another you have to restore from backup, unless you can yank corrupted table/index/etc. file from some place else. And more important, I have no idea how Oracle does it, but for MS SQL transaction log is a separate file, so if you lost transaction log... this is another story, but nothing to do with single/multi file dbs. And as for SQL Server, DB is usually 2 files db and log, very very useful in handling I can just copy, zip one file or attach/detach db. Anyway there is no black and white here, different designs and different limitations, like On Windows it is very reasonable and I would say correct to have single db file. On *nix it is difficult ( using POSIX calls ), to have single file due to 2GB limit on 32 bit CPUs and so on... Choices, choices... -----Original Message----- From: Josh Berkus [mailto:[EMAIL PROTECTED] Sent: Friday, August 22, 2003 1:05 PM To: Jan Wieck Cc: Andrew Dunstan; PostgreSQL-development Subject: Re: [HACKERS] Single-file DBs WAS: Need concrete "Why Postgres <....> Yes, but you've just added a significant amount to the work the DB system needs to do in recovery. PostgreSQL just needs to check for, and recover from, issues with LSN headers and transactions. Single-file DBs, like SQL Server, need to also check and audit the internal file partitioning. In my experience (a lot of MS SQL, more MS Access than I want to talk about, and a little Oracle) corruption failures on single-file databases are more frequent than databases which depend on the host OS, and such failures are much more severe when the occur. -- -Josh Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
