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
truetoday ( 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:josh@agliodbs.com]
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 BerkusAglio Database SolutionsSan Francisco