A short post after a tweet of Johannes Ahrends (@carajandb on twitter). He brought to our attention that he was worried: SE2 doesn’t include RAC anymore in 19c. Is it a documentation bug? Unfortunately not… his worries appeared to be ligitimate. He made a blogpost about it – in the German language. Tried to summarize some in this blogpost.
This post has already been published in the past on the AMIS-blog.
To build an Oracle 12C RAC database – on Virtual Boxes – there’s at least shared storage needed for ASM, and a DNS-server for the SCAN-addresses. Several methods can be used for this, but for the storage in my private project I chose Openfiler, an open source management storage tool, on a separate Virtual Box. It’s like a SAN in real life (the complete system will be three Virtual Boxes: two RAC-nodes and 1 storage Virtual Box). Version Openfiler: 2.99.
But what I want is a separate DNS-server, just as in real life. The perfect candidate is to use the separate Openfiler Virtual Box
A while ago, but worth mentioning it for those customers with a roadmap based on Red Hat Linux. The status regarding RHEL 6 is the following:
– Oracle has indeed certified RHEL 6 for the Oracle database, see also the comments in this article, and my seperate blogpost about it.
– Red Hat announced recently an extended lifecyle (support) of version 5 and 6, from 7 to 10 years.
– Red Hat is making things harder by shipping its RHEL 6 kernel source as one big tarball, without breaking out the patches. Distribution in this form satisfies the GPL, but it makes life hard for anybody else wanting to see what has been done with this kernel
Maybe as a result of this: regarding ASMLIB Oracle mentioned in note 1089399.1 :
For RHEL 6, Oracle will provide ASMLib software and updates only when configured with a kernel distributed by Oracle. Oracle will not provide ASMLib packages for kernels distributed by Red Hat as part of RHEL 6. ASMLib updates will be delivered via Unbreakable Linux Network (ULN), which is available to customers with Oracle Linux support. ULN works with both Oracle Linux or Red Hat Linux installations, but ASMLib usage will require replacing any Red Hat kernel with a kernel provided by Oracle.
First I mentioned in this post that you could not use ASM with RHEL 6, but Tim Hall corrected me on this, read his comment on this post. Thanks (and cheers… ) !
Hope it helps somebody.
The second and final post about an issue with a RAC-configuration with two SAN’s. Problem was a i/o-freeze of minutes when crashing one of the two SAN’s. The first post I ended with a ‘cliffhanger’ because we had a solution, but not tested it yet. Now we tested it.
Start with a mockup of the first post.
3 HP DL380 G6 systems with a basic RHEL 5u5 x86_64 installation (2 x RAC clusternodes, 1 x NFS-voting-node)
2 SAN’s HP EVA 6400 systems with 2 controllers each (resulting in 8 paths per device)
Test: power off 1 SAN. Default result / problem: i/o freeze of minutes, Oracle didn’t like it, started to evict, shutdown, startup = expected behaviour after such a long i/o freeze. But this is not the intention when installing a RAC with two SAN’s….
Remember the old days. You had just a few processes to watch. Something has changed along the way. A lot of processes should be running on your database system (with infrastructure), but how are they connected to eachother and what is the startup sequence ? Or.. what processes I can kill without any other proces starting it up… 🙂
Since 188.8.131.52 there’s a new parameter, “_datafile_write_errors_crash_instance” to prevent the intance to crash when a write error on a datafile occurs . But.. should I use this or not. The official text of this parameter:
This fix introduces a notable change in behaviour in that
from 184.108.40.206 onwards an I/O write error to a datafile will
now crash the instance.
Before this fix I/O errors to datafiles not in the system tablespace
offline the respective datafiles when the database is in archivelog mode.
This behavior is not always desirable. Some customers would prefer
that the instance crash due to a datafile write error.