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
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 126.96.36.199 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 188.8.131.52 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.