Hello,
Some nice comments were posted here already.
I recently did a presentation on Oracle ASM versus HP-UX LVM. I used collective knowledge I found on the net so I cannot claim full glory for it.
Extracts from my slides:
ASM Pros:
* ASM provides some file system and volume
management capabilities for Oracle database
files only. These include DB control files,
redo logs, archived redo logs, data files,
spfiles and Oracle Recovery Manager (RMAN)
backup files.
* File-level striping/mirroring.
* Ease of manageability. Instead of running
LVM software, run an ASM instance, a new
type of "instance" that largely consists of
processes and memory and stores its
information in the ASM disks it is managing.
* Attempts to identify the configuration
errors.
* Gives Oracle Corporation control over the
storage system, so they promote it heavily.
* No large Unix-level administration needed.
* Provides a single point of support
(Oracle) so there is no ├в finger-pointing├в .
* Provides easy management of block devices
(raw partitions).
* Automatically moves hot blocks to the
outside of the disk.
* Vendor and operating system neutral.
* Included in the Oracle license so no
additional cost for the software or its
support.
* Supports very large disk groups and
datafiles.
* Database File System with performance of
RAW I/O.
* Supports clustering (RAC) and single
instance.
* Automatic data distribution.
* Memory requirements for an ASM instance
are small. 100 MB of RAM is typically all
that is required to run an ASM instance on a
production server.
* On-line add/drop/resize disk with minimum data relocation.
* Automatic file management.
* Flexible mirror protection.
* Inode locks not applicable to ASM.
* Ability to grow diskgroup capacity on the
fly.
* Supports multiple database instances
running on a single host, and does not have
its own data dictionary.
And in Oracle 11g, extra features:
* Fast mirror resynchronization.
* Preferred mirror read in a cluster.
* Support for large ALU.
* Variable size extents.
* Rolling upgrade and patching.
* Table level migration wizard in EM.
* New ASMCMD commands.
* New SYSADM privilege ├в separate from the
SYSDNA privilege.
* More flexible FORCE options to MOUNT or
DROP disk groups.
and so on.
ASM Cons:
* ASM cannot be used for Oracle executables
and non-database files.
* ASM files can only be managed through an
Oracle application such as RMAN. This can be
a weakness if you prefer third-party backup
software or simple backup scripts. Cannot
store CRS files or database software. Cannot
manage ASM through standard Unix tools.
* Potentially disrupts the balance of power
between the Unix Systems Administration
groups, and the Database/DBA groups.
Traditionally the former group manages
disks, hardware, and the operating system
level, leaving the DBAs to coordinate with
them for new resources. This would change
that balance, which could cause some
resistance.
* ASM does not have multi-pathing
capability. It assumes the underlying O/S
will provide this functionality. In HP-UX,
multi-pathing is provided by a Volume
Manager feature such as PVLinks in the HP-UX
Logical Volume Manager (LVM), native
multipathing in HP-UX 11.31, or DMP in
Veritas Volume Manager from Symantec (VxVM),
or by other third-party software such as
Securepath or Powerpath.
* ASM is still in the enterprise computing,
relatively new. There are a number of
vendors whose core business has been in the
logical volume manager/file system space for
years. Often, maturity matters a lot when it
comes to software systems, reliability, and
proven success rates.
* New technology to get familiar with.
* Automatic Storage Management load balances
file activity by uniformly distributing file
extents across all disks in a disk group.
For this technique to be effective it is
important that the disks used in a disk
group be of similar performance
characteristics.
There may be situations where it is
acceptable to temporarily have disks of
different sizes and performance co-existing
in a disk group (for example, when migrating
from an old set of disks to a new set of
disks). The new disks would be added and the
old disks dropped. As the old disks are
dropped, their storage is migrated to the
new disks while the disk group in online.
* There is no shared awareness of LUN use between ASM and LVM or VxVM. It means that the system administrator must be careful not to accidentally allocate a LUN already allocated for LVM or VxVM use to ASM use (or vice-versa). ON the positive side, pvcreate(1M) recognises ASM disk and will not
overwrite them unless force flag is used.
* ASM is not an enterprise-class file system
(not for all type of data).
* ASM is a proprietary solution.
* The customer is dependant on the
reliability of the new ASM code stack.
* Does not offer network monitoring.
* Be careful about ASM hidden parameters.
* Everything is single threaded through one process at a very low level (I found this claim somewhere and am trying to verify it).
* If one uses Oracle ASM and CRS, they will
still require a 3rd party clustering
solution to support the non-Oracle data.
They will then have to manage multiple
clustering solutions.
* DBAs must still watch and then perform the
task of adding and removing disks to an ASM
disk group when needed. This leads back to
the problem of DBAs under allocating, and
worse yet, over allocating disk storage,
just to be safe, which recreates the problem
of wasted space and leads to higher than
needed storage costs.
This is where thin provisioning comes into
play. Thin provisioning will automatically
allocate on a just-enough and just-in-time
basis which relieves the DBA from both
having to watch and then add or remove disk
to a disk group. Oracle's ASM and thin
provisioning could be combined to offer a
complete, end-to-end, storage solution.
Oracle's ASM feature would create, allocate,
place, and rebalance data files for
performance and thin provisioning would
dedicate disk space on the fly and only when
needed.
* Configuration details and performance
metrics are exposed via V$ views. Other
possibilities are the command line
interface, asmcmd and the graphical
interface of OEM.
Metadata are however partially hidden to the
end user. That is the mapping between
physical storage, ASM allocation units, and
database files is not completely exposed via
V$ views. It was found that is possible to
query such information via undocumented X$
tables. For example, it is possible to
determine the exact physical location on
disk of each extent (or mirror copies of
extents) for each file allocated on ASM (and
if needed access the data directly via the
O/S). This can be used by Oracle DBAs
wanting to extend their knowledge of the
inner workings of the ASM or wanting to
diagnose hotspots and ASM rebalancing issues.
and so on.
I hope it helps,
VK2COT
VK2COT - Dusan Baljevic
