Re: NT File System

You probably want to check and see if SQL 7 supports RAW before you decide. Conventional wisdom is that RAW won't buy you noticeably improved performance on NT anyway. RAW is sometimes used in UNIX to keep the file system from screwing up DBMS files and I can't remember any postings to NGs where NTFS problems caused DB corruption.

My $.02 - if I/O performance is troubling you 1 - buy more memory, 2 - get lots of really good caching controllers, 3 - use stripe sets judiciously and 4 - look at using segments to balance your workload across your devices intelligently.

HTH Ng K C Paul wrote in message <6s7uc5$hf6$1_at_imsp009a.netvigator.com>...
>I think NT 5.0 should support FAT32, am I right?
>
>Someone said raw partition is better in multi-user environment than
>single user, right?
>
>Neil Pike (100577.553_at_compuserve.com) wrote:
>: > What kind of File System should I install the database software and
>: > data and log to? FAT or NTFS? I know that the security is better in
 NTFS.
>: > Also, there is a compress option in NTFS. In unix, raw device is more
>: > reliable than unix file system which has disk cache that can speed up
>: > certain I/O operations. What about performance on NT?
>:
>: Ng,
>:
>: FAT is marginally better for writes, NTFS for reads, but really there's
 not much
>: difference. You can use raw partitions with SQL 6.x, but I wouldn't
 recommend it - too much
>: of a pain for minimal gain.
>:
>: >
>: > In WIN97/98, there is also FAT32. Should I use it to install
>: > MS-SQLServer 7.0, Personal Oracle8 or Adaptive SQLServer Anywhere
 Studio?
>: > It seems that FAT32 can save more space than FAT but NT4.0 cannot read
>: > files on FAT32, am I right? Also, is there any difference on backup
 and
>: > recovery time on different file system?
>:
>: SQL is file system independent, so FAT32 should work fine. You can read
 FAT32 on NT with a
>: 3rd party driver from www.sysinternals.com
>:
>: Neil Pike MVP/MCSE
>: Protech Computing Ltd
>:
>:

Opinions expressed herein are my own and may not represent those of my employer. Received on Mon Aug 31 1998 - 00:00:00 CDT