This content has been marked as final. Show 8 replies
Your question is probably more suitable for the ASM forum. One of the common misconceptions about ASM is that it was some sort of a software RAID, which it is not. ASM is specifically designed to deal with the requirements and needs of an Oracle database. It provides the best options in regard to performance, reliability and manageability. There are no reasonable arguments not to use ASM in a production system. The same applies to RMAN. Database recovery is a lot easier using RMAN than SQL. You cannot do incremental backups of database files using conventional OS tools.
ASM and RMAN are complex and you will have to study how to use it if you want to take any advantage. There is no way around it. In case you are planning to do SAN snapshots, you might want to keep in mind that it is generally useful for undoing data changes, but not suitable for backup as it cannot restore data from scratch.
Thread moved from the Generic Linux forum to the ASM forum, for closer topic alignment.
some of the benefits of ASM are:
- better performance
- ability to manage (resize, rebalance a diskgroup online)
And you are rigt, you'll have to find a new way to monitor space and perform backups. The memory and cpu requirements for the extra instance are only marginal.
ASM means you stop wasting a ridiculous amount of time moving files around because your files grow and your filesystems are fixed. Take time to learn ASM. If properly configured it can give you as much as 10-15% performance improvement over all of the FS options out there...
user5969983 wrote:ASM provides a host of new features ito data management, and performance - to the extent that you can rip out the entire existing storage system, replace it with a brand new storage system, without a single second of database downtime.
We will install 2 sets of Oracle 188.8.131.52 on Redhat Linix 5.6 and configure Data Guard for them further -- one will be a primary DB server, the other will be a physical standby DB server. The Oracle DB stoage is based on SAN Array Disk with 6TB size. Now there are two options to manage the DB datafiles:
1. Install Oracle ASM
2. Create the tranditional OS filesystem
Which is better? in the past, our 10g data guard environment is not based on Oracle ASM.
Someone think if we adopt the oracle ASM, the shortcomings are :Not really relevant on 64bit h/w architecture that removes limitations such a 4GB of addressable memory. On the CPU side... heck, my game PC at home has a 8 core 64bit CPU. Single die and dual core CPUs belong to the distant past.
1. as there is one more instance that will consume more memory and resource.
Arguing that an ASM instance has overheads would be silly. And totally ignores the wide range of real and tangible benefits that ASM provides.
2. as the ASM file system cannot be shown out on the OS level directly such as "df" command, the disk utilization monitor job will be more difficult. at least it cannot be supervised at OS level.That is a A Very Good Thing (tm). Managing database storage from o/s level is flawed in many ways.
3. as the DB bshoule be done the daily incremental backup (Mon-Sat) to Local Backup Drive. the bakup job must be done by RMAN rather than user-managed script.rman supports ASM fully.
I have stopped using cooked file systems for Oracle - I prefer ASM first and foremost. The only exceptions are tiny servers with a single root disk that needs to be used for kernel, database s/w, and database datafiles. (currently these are mostly Oracle XE systems in my case, and configured that way as XE does not support ASM and is used as a pure cost decision).
Thank very much for your replies. I knew Oracle and you strong recommend us to adopt the ASM, but one of my friends told me one scenario.
The storage engineer had allocated 1TB SAN disk for 2 databases in one server. He asked the Unix Engineer to create 10 LVs. Every LV has 100GB. Then he created 4 diskgroups. One for FR with 200GB, one for ARCH with 200GB, one named as DATA1 with 300GB for the first database, one named as DATA2 with 300GB for the second database. After running one year, he found there were not any free disk spaces in diskgroup of DATA1, but there were many free spaces in diskgroups of FR, ARCH and DATA2. He had to add new datafiles in other diskgroups and restricted the auto extend of datafiles in DATA1, but there were too many tablespaces, it was difficult to maintain them. Moreover, the management rejected to purchase more disks, there were not these issues if he just created one filesystem mounts such as “/u01” for the two databases.
I don’t confirm whether we will encounter the same issues if we adopt the ASM, especially we need to configure the data guard further.
The scenario you described, does not exist on ASM, when ASM is used as per best practises.
I would say that he mis-configured his system. One of the things I always do is to create ALL LUNS on the system using the same size (100G, 250G, 500G) - whatever. So in his case, he could have more than likely removed a 100G device for FR and add it to DATA1. I also recommend using ASM on SAN. Any system that is small enough to still use discrete local devices is not going to be that big. Also depends on how you manage redundancy. There are LOTS of different methodologies that can be employed. Your environment may be different. Read and understand the concepts manual as well as "Automatic Storage Management - Under-the-Hood" a very good reference book. I even used it once as the course material for a brief class I taught on ASM. How it works, how to configure it etc... A good reference book even if you are using 10g or 11g.
I also recommend that if you are going to be a RAC or ASM admin, I would also recommend learning SYS, SAN and NETWORK Admin duties.