Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!ukma!husc6!hscfvax!pavlov
From: pavlov@hscfvax.harvard.edu (G.Pavlov)
Newsgroups: comp.databases
Subject: Re: Corrupted database in Oracle
Keywords: Oracle HP-UX crash
Message-ID: <740@hscfvax.harvard.edu>
Date: 11 Mar 89 06:13:23 GMT
References: <115@geysir.os.is> <735@hscfvax.harvard.edu> <3242@sybase.sybase.com>
Organization: Health Sciences Computing Facility, Harvard University
Lines: 33

In article <3242@sybase.sybase.com>, tim@phobos.sybase.com (Tim Wood) writes:
> 
  Re why vendors implement their own file systems for dbms:

> Because most O/S file systems are not optimal for database operation, 
> especially not for on-line transaction processing.
> 
> It's expensive for the user to use a software package that incurs substantial
> overhead with every database access.  

  I don't have any experience with OLTP, so I won't argue on that score.  

  As I am sure you know much better than I do, there are a very large number of
  factors, many unique to an application, that affect the performance of a dbms.
  I have seen "slow" dbms's that utilize their own file management and "fast"
  ones that don't.

  While I won't argue that there is an overhead penalty, I haven't seen anything
  that supports the statement that it is "substantial".  

  I know that Sybase is a good solid product with excellent performance.  But I
  have been subjected to the "we use our own file system so therefore we are 
  better/faster than Brand X who doesn't" hype from second-rate dbms's often
  enough that I seriously doubt that it makes a significant difference.  On the
  contrary, it leads me to suspect that there are serious shortcomings (e.g.,
  second-rate optimizer) elsewhere in such a product.

> The point is not to rely on O/S
> files because the DBMS recovery features are lacking, the point is
> to install a DBMS with complete and robust recovery features.  Then,
> the optimization features do not increase the user's risk.
> 
  greg pavlov, fstrf, amherst, ny