Is there any advantages of using file system on Oracle 10g DB as against ASM? Is it safe to start using ASM and forget the "file system" database set-up in my future Database Installations?
Thanks a lot
Behind The Success And Failure Of A Man Is A Woman
The Oracle notes itself saying that it is safe....
With ASM, you don't have to create anything on the OS side; the feature will group a set of physical disks to a logical entity known as a diskgroup. A diskgroup is analogous to a striped (and optionally mirrored) filesystem, with important differences: it's not a general-purpose filesystem for storing user files and it's not buffered. Because of the latter, a diskgroup offers the advantage of direct access to this space as a raw device yet provides the convenience and flexibility of a filesystem.
Logical volume managers typically use a function, such as hashing to map the logical address of the blocks to the physical blocks. This computation uses CPU cycles. Furthermore, when a new disk (or RAID-5 set of disks) is added, this typical striping function requires each bit of the entire data set to be relocated.
In contrast, ASM uses a special Oracle Instance to address the mapping of the file extents to the physical disk blocks. This design, in addition to being fast in locating the file extents, helps while adding or removing disks because the locations of file extents need not be coordinated. This special ASM instance is similar to other filesystems in that it must be running for ASM to work and can't be modified by the user. One ASM instance can service a number of Oracle databases instances on the same server.
This special instance is just that: an instance, not a database where users can create objects. All the metadata about the disks are stored in the diskgroups themselves, making them as self-describing as possible.
So in a nutshell, what are the advantages of ASM?
Disk Addition—Adding a disk becomes very easy. No downtime is required and file extents are redistributed automatically.
I/O Distribution—I/O is spread over all the available disks automatically, without manual intervention, reducing chances of a hot spot.
Stripe Width—Striping can be fine grained as in Redo Log Files (128K for faster transfer rate) and coarse for datafiles (1MB for transfer of a large number of blocks at one time).
Buffering—The ASM filesystem is not buffered, making it direct I/O capable by design.
Kernelized Asynch I/O—There is no special setup necessary to enable kernelized asynchronous I/O, without using raw or third-party filesystems such as Veritas Quick I/O.
Mirroring—Software mirroring can be set up easily, if hardware mirroring is not available
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
best practice is to avoid double buffering so you are recommended to use Direct I/O and bypass filesystem buffer, instead you assign a larger Database Cache
Reply With Quote
Originally Posted by tamilselvan
huh? I'll be damned if I understand what you mean man; not your fault, your post got so close to gopu_g's posting that probably got infected 
Bookmarks