FW: RAC & limited SSD available on each node

to fit
As K said, Oracle RAC is shared everything, so local storage can’t be used.
X-archive-position: 18812
X-ecartis-version: Ecartis v1.0.0
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
X-original-sender: mwf@rsiz.com
Precedence: normal
Reply-to: mwf@rsiz.com
List-help:
List-unsubscribe:
List-software: Ecartis version 1.0.0
List-Id: oracle-l
X-List-ID: oracle-l
List-subscribe:
List-owner:
List-post:
List-archive:
X-list: oracle-l
Now depending on how much you want to complicate your life and the details
of your SSD, there are some things you can do.
Start by thinking of things that are used by only one instance at a time.
diagnostic_dest is an example. (for those pre-11g think alert logs, bdump,
udump, cdump, etc.)
reporting output
program binaries and dynamic libraries
temp space (unfortunately oracle does not yet support the idea of temporary
by instance tablespaces which could support non-TAF single instance queries
on local storage in theory, so I’m talking here about the temp space used by
programs as in c:\windows\tmp on windows or /tmp on UNIX.)
I am *not* making an argument here for purchasing SSD for these purposes,
but you seem to already own it, and anything you can do to “de-heat” the
cache of your storage array without negative side effects usually helps.
Since you are in the process of setting up and have no actual most important
process that is too slow to check against bottlenecks, the presumption that
your i/o complex will be a stressed resource is a good one unless you doing
something like calculating the digits of pi. And we know you’re running
databases.
Now we need to know something about the details of your SSD to assess the
negative side effects.
Is your SSD a board that is plugged directly into one particular node or is
your SSD in its own box with wires of some sort to several boxes?
If your SSD is a board in a particular node, does it have onboard power?
Some SSD boards can be trivially removed from one box and be shoved into
another without losing anything. Now you might need to see stuff in the
diag_dest real soon now to evaluate any problems from a node going down. So
if your SSD is in a single box with wires to the other boxes or if you can
trivially unplug it from a box and put it in another, and have operations
staff to make that possible, then it might be operationally okay for you.
Now if you SSD is in its own box, is robust (at least duplex and has its own
power for long enough to persist its memory data or it is flash and
therefore self persistent), then you can use it for some more stuff IF a
little sleight of hand. (No sleight of hand required if it is shareable, but
I take it that is not your case). This is also true if you have staff
physically present and a no-dataloss board movement is practical, but I’d
think thrice before I made that part of my life.
Several releases of UNIX and its rebuilt copy have the characteristic that
even without a shared storage manager, if you have a “wire” to a device then
one node can mount it read/write and several nodes can mount it read only
with no unexpected results. So you can  use that type of storage for online
redo logs (and archived redo logs for that matter). Where you need to move
the board for instance recovery by another node I think this would be too
complicated. Where your SSD is in a multi-wireable box it is a real
possibility.
For a multi-SAN environment, especially where one SAN is your shared
database storage and another SAN is a backup box, a local SSD can be used
for archive log destination and then the archived redo logs are shuffled
directly to the backup SAN. This decouples arch from SAN throughput and the
secondary copy can be done on a “whole file” basis with OS utilities. This
may complicate RMAN cataloging and/or dataguard environments unduly, so
beware the negative side effect potential. If the board is not losslessly
swappable then you have a potential vulnerability if you need an archived
redo log from the window between arch finishing and the SAN copy.
That’s all I can think of right now. Whether I would actually do any of them
would depend highly on the exact situation. You would certainly need to
write up site procedures and make sure the operational DBAs and non-DBA
coverage staff knew exactly what to do in the various failure modes.
mwf
--
http://www.freelists.org/webpage/oracle-l