Are two different things;
1 - Remove ASMDISK from ASM
2 - ASMLib renaming Disk
First of All:
If ASM DISK (LUN) is assigned to a Diskgroup you must drop that ASM DISK or Drop DISKGROUP.
After removed that ASMDISK the status will be FORMER. Which means:
"Disk was once part of a disk group but has been dropped cleanly from the group. It may be added to a new disk group with the ALTER DISKGROUP statement."
If you want rename LUN used by ASMLib just issue command below;
/etc/init.d/oracleasm force-renamedisk RECO_D7 DATA78
You don't need use dd command in any step.
Please avoid to use dd command.
1 person found this helpful
I agree with the assessment of the previous response. There is no need to use the dd command in your situation.
There is also nothing wrong with ASMLib and it addresses various Linux specific advantages. The fact that it only exists for Linux and not for any commercial Unix distribution does not mean ASMLib is obsolete or useless. A Linux and Unix kernel do not work the same way. If you want to learn about the advantages of ASMLib, see https://blogs.oracle.com/wim/entry/asmlib
1 person found this helpful
Just as there is nothing wrong with NOT using AsmLib.
And that using Multipath is the standard with ALL enterprise/server kernels (unlike ASMLib).
Explanation of architecture - Linux Multipathing (Linux Symposium 2005).
Usage. Critical as this shows how robust and scalable the architecture is. From National Center for Supercomputing Applications at the University of Illinois, the following presentation on the sizes of cluster being build and use, amount of cluster storage addressed, and most important - detailed info on how udev and multipath are used to make it work - SAN Persistent Binding and Multipathing in the 2.6 Kernel.
Question. If the NCSA, an authority on supercomputing clusters, use the STANDARD multipath feature of the 2.6 Linux Kernel, on 100x the SAN space most Oracle RACs would use - WHY WOULD YOU WANT TO USE ASMLIB??????
And no - I am not saying AsmLib is bad. It is not about AsmLib specifically. It is about the reasons behind NOT using PROVEN architecture for addressing the issue of persistent naming, device and multiple I/O path management - and instead adding an ADDITIONAL kernel driver (not part of the standard 2.6 kernel). It just happens to be AsmLib in this case. Could as well have been EMC's PowerPath. Or something else.
Multipath and EMC Powerpath are addressing a different purpose than ASMLib.
Removing as many software layers as possible does not necessarily make any system faster or more secure, but can make it more difficulty to manage, which can lead to configuration conflicts or errors. Usability is a human factor, which depends on the sysadmin and I consider it a very important factor.
I do not consider NCSA an "authority", nor any other big installation for that matter, and do not believe that the size of an installation or it's popularity is a valid criteria to assume a certain standard; if I did, I would have to say that MS Windows was the best product ever invented. Big corporations often make the biggest mistakes.
The ASMLib kernel driver ships with every version of the Oracle UEK kernel distribution and has been tested by Oracle. If anyone feels uncomfortable with ASMLib and wants to rely on udev instead, by all means, but I see no good reason to play mind games with it.
You dragging of MS Windows in as analogy is ill placed and biased - and kind of insulting to the guys and gals at NCSA that are building, running and administrating some of the fastest computer clusters on this planet.
I'm sure they do a good job and I have no reason to insult them. I really don't care what they do though. But sorry, just because you use them as an example for setting what you call a standard not using ASMLib and thereby putting yourself on the same line of expertise, does not mean I have to that too. If you bring on the argument that of one of the biggest installation is not using ASMLib, and thereby setting any standard, then I can bring in the argument that some of the biggest installations also use MS Windows. Perhaps your view of ASMLib is biased based on some past bad experience, if I remember correctly from a previous discussion, however, things change.
Not sure what you mean by "line of expertise".
I look at what the "Big Boys" (members of top500.org, running the fastest 500 supercomputer clusters in the world), do. Look at the infrastructure, s/w and h/w used. And use that as a baseline for deciding and choosing the infrastructure to build our clusters. This includes taking into serious consideration what NCSA does with their clusters.
That to me is more meaningful than blindly installing s/w, without having actual technical justification for that, just because it gets warm fuzzies from some on OTN, and is an option provided by Oracle.
What I meant was that doing what NCSA does, does not automatically promote someone's technical expertise, nor is it a valid argument considering the use of ASMLib.
I think by saying that you look at what the "Big Boys" do and finding it more meaningful than blindly installing some system without having a technical justification, is a common but also a silly argument. Many people follow this logic and end up setting a system, giving them some comfort or confidence, without knowing the technical implications. What if these Fortune 500 businesses actually use MS Windows? Do you still consider that meaningful information, or do you just filter out the information that support your arguments?
There is certainly nothing wrong in considering what the big players do, but I do not see it as a universal guideline or technical authority. I rather suggest to evaluate the problems and requirements and also evaluate current solutions. Past experience is not necessarily a good adviser, not in IT.
Whatever NCSA did might be the best solution for their environment, but can also be the result of other circumstances. Perhaps NCSA does not use the Oracle UEK kernel, or did not know about ASMLib when they setup the system in the first place, and would be happy to use it, in particular for their large installation.