Re: Oracle 8i for NT work with FAT ?

While I could concede the point about NTFS recoverability (the inner working of NTFS are thinly understood by myself and if you are actually correct, I obviously retract my thoughts on the matter), I was never saying *nor implying* that you couldn't use - for example - raw devices because of no recover capabilities.

You would see from my earlier post that I say you could use FAT which has no recovery abilities so your argument is now dragging mine into an illogical area. It was my understanding that the log replay facilities of NTFS were similar in concept to those of, say, VXFS which does replay file system changes upon crash recovery.

ps. I use raw devices.

"Andrey" <aakit_at_softhome.net> wrote in message news:9c10fm$2uhl$1_at_josh.sovintel.ru...
> To follow your arguments one must tell oracle can not work on raw devices
> because it have no NTFS recover capabilities.
>
> /*it is a fact that NTFS *could* save you from having to recover a
 database
> where FAT could not*/
>
> One more time - NTFS recover capabilities have effect for NTFS FAT
 catalog,
> not for files itself.
>
> Please, refer to NT admin guide.
>
>
>
> "andrew_webby at hotmail" <spam_at_no.thanks.com> wrote in message
> news:988019382.14406.0.nnrp-14.c30bdde2_at_news.demon.co.uk...
> > While I did think I wouldn't bother responding to someone whose main
> > argument is "it's full rubbish" (not the most well reasoned point I've
 ever
> > heard...), it is a fact that NTFS *could* save you from having to
 recover
 a
> > database where FAT could not. Surely your vast technical knowledge can
> > imagine such a scenario.
> >
> > Thanks for re-iterating my point about FAT being faster however.
> >
> > "Andrey" <aakit_at_softhome.net> wrote in message
> > news:9br9hs$2k3n$1_at_josh.sovintel.ru...
> > > It's full rubbish
> > >
> > > FAT is much faster
> > >
> > > NTFS is for file servers, not db servers
> > >
> > > All what is written about NTFS (recoverable, chains/abandoned clusters
 etc)
> > > have no effect on quality of database itself and db files.
> >
> >
> >
>
>
Received on Mon Apr 23 2001 - 06:04:05 CDT