Sample Configurations with SGeRAC and Oracle RAC 10gR2, March 2009

5
Memory
Sufficient physical memory should be available for all processes. Insufficient memory may result in
swapping activities that affect the CPU processor availability to components that have timed heartbeat
communications. Generally, one should consider sufficient memory to reduce paging activities, fit
Oracle System Global Area (SGA) into main memory, and allow for user processes.
Network: clients
Insufficient bandwidth on the client network affects availability to the client.
Network: cluster interconnect
Insufficient bandwidth from the cluster interconnect affects communication between cluster
components.
Storage
Sufficient storage bandwidth and storage space are required to maintain optimal database service.
Additionally, sufficient space should be allocated for database archives for recovery purposes.
Failover time requirements
In a RAC configuration with SGeRAC, each node may have concurrent access to the database. The
database service is accessible from all nodes and each node provides a client connection endpoint
(IP address, port, and listener). When one node fails, clients can connect to another node for services.
The client connection endpoint does not need to failover for the clients to continue service. However,
even though an alternate connection endpoint is available, upon certain failures (for example node or
network) and until failure detection and recovery, new client connections may not connect or the
database service may be unavailable while the cluster goes through reconfiguration and/or recovery.
The failover time is the time between when a failure occurs to when the service is once again
available to the client. A failover time requirement is important for the following reasons:
How fast the clients reconnect.
On local LAN failover, this depends on detection time and the local LAN failover scheme.
On remote failover, this depends on whether clients are enabled with Oracle Fast Application
Notification (FAN), how fast cluster reconfiguration happens, how soon the VIP address fails
over, and how soon the client connection times out.
How fast the cluster and RAC go through reconfiguration before database service resumes.
On node failure, the reconfiguration time depends on the Serviceguard heartbeat timeout, the
number of nodes, and the type of quorum device used.
On cluster network interconnect failures, the database service availability depends on how
soon the interconnect failure is discovered, speed of recovery actions by affected components
(for example SG, GMS, SLVM, CVM, CFS, CSS, and/or RAC), and database recovery.
o On a complete SG cluster interconnect failure, SG sees the failure within the SG
heartbeat timeout.
o With SG/CFS, GAB/LLT and SG shared the same networks and SG sees the
interconnect failure within SG heartbeat timeout.
o With CSS traffic, on configurations where CSS and SG share the same interconnect
network, SG sees the failure within the SG heartbeat timeout. If CSS traffic is on a
SG monitored network, SG can be configured to take actions via SG packages and
optionally use Cluster Interconnect Subnet Monitoring
1
. If CSS traffic is on a non-SG
monitored network, CSS sees the interconnect failure within the CSS timeout.
1
Cluster Interconnect Subnet Monitoring is available starting SGeRAC A.11.18.