RE: Looking for a Script to list tables,its indexes and sizing info

> Now the real question. Would you trust Microsoft to sell you
version one of your engine management system for
>your car or version one guidance systems for a plane? . So why would
you put your enterprise data on a Version one of >the filesystem from a database vendor?         

> Would i use it? Yes and I have but I dont recommend it for your
enterprise data (yet).

...I don't want to turn this into ASM bashing, but I have another take.

What I find bizarre is that anyone would consider changing the fundamental
way Oracle has been doing databases for over 20 years. That is, Oracle databases
have always been contained in files, not in Oracle-managed OS containers. The
difference is not subtle. Back in the days when Oracle had competition, most
of the other players, most notably Informix, had space management and no file-per-tablespace association. Those were the days when there was actually
a problem to solve since filesystems really got in the way a lot (not on Sequent though) and volume managers were pretty shaky. The current implementation
of ASM solves a non-problem. That is not a way to say don't use it. I simply don't
care. It is a non-problem because you (Oracle customers) didn't ask for it,
so you don't need it. When was the last time anyone asked for a way to put their databases out in some vacuous space in raw partitions with an interface that requires a database instance just to gander at "files"? No
libC interface to your data?

   ASM is a marketing term for code that originated in osm.h. The osm.h spec had original helpful intent. Early on, osm (Oracle Storage Manager) was going to do one major thing--striping and mirroring within oracle datafiles at the block level. If it would have stopped there and got that
right it would have been really helpful technology. That would have given
you Oracle-level raid between storage arrays, and other such elegance.

   If you're still with me, I'd be pleasently surprised because Oracle marketing has a bit of a hypnotic effect on folks. Let me explain one major way that ASM is really just overhead.

   Can anyone argue that Oracle is very keen on Network Attached Storage?
NAS is very very strategic for Oracle. Grid is important to Oracle. Try to make a "grid" (e.g., 96 RAC nodes) where every node has to attach to a
fibre channel SAN. It is unrealistic. What the heck does NAS have to do with the ASM topic?

Well, on NAS, you have an internal volume manager and an internal filesystem. The most popular example by far is NetApp volumes and WAFL filesystem. OK, so you create the volume (RAID), create the filesystem and then put ASM "disk groups" in the NAS filesystem. Yes, ASM on NAS consists of large pre-allocated files in the filesystem, on top of the volume manager. Like I said, I don't care if Oracle customers choose ASM or not. I think choice is an important ingredient in running an Oracle shop. SQL*Calc could be a reasonable tool for all I care :-)

   So, somebody, explain to me like I'm six years old what possible value there is in obscuring your data out into a "storage managment system" that cinsists of files residing in a filesystem on top of a volume manager, but that storage management system has no libC interface. Why not just use files? Oh, I know, someone is going to chime in with that old red herring about OS active file descriptors when your database consists of individual datafiles. I hope so because I'm running out of stuff to rant about on this acpect of the topic :-)

--
http://www.freelists.org/webpage/oracle-l