Instruction Manual
SN0451405-00 Rev. B 07/13 5
WHITE PAPER
• The benefit of this shared cache becomes apparent when full table
scans occur (Oracle does not cache this in the block buffer). Any
repeated full table scans on any of the nodes may benefit from the
information cached in the 10000 Series Adapter in the cluster.
NOTE: Because the I/O behavior is in-band, it is not visible to the database
or even the driver. Also, if a node is “evicted” (that is, ejected from the
cluster by Oracle’s I/O fencing, causing a reboot) and the 10000 Series
Adapter is not available, the other nodes immediately and directly access
the LUN by means of the storage array. Although the performance gain
from the cache is not realized, the application continues to perform without
interruption. In Figure 4, if OraServer3 is evicted from the cluster, the other
nodes directly access Data03 until OraServer3 has rebooted and the 10000
Series Adapter is active on the SAN. The 10000 Series Adapter then begins
managing the I/O for Data03 and rewarming the cache.
Testing the QLogic 10000 Series Fibre Channel Adapter
QLogic set up a test environment based on a four-node RAC cluster,
with four 10000 Series Adapters clustered together. The load generator,
SwingBench, is configured on four nodes to provide a significant load on the
database. The SwingBench nodes are coordinated as one load-generation
tool. Follow best practices to get better performance. The results of the
cache versus non-cached runs reflect an improvement of approximately
40 to 70 percent.
Performance Testing—SwingBench Results
QLogic used SwingBench—a database load generator from Oracle that is
designed to provide load to an Oracle RAC database—to demonstrate the
significant performance gains. The largest gain occurs when running large,
complex queries:
• The sales history set online analytical processing (OLAP) achieved
approximately 3.25 × more transactions in a one hour run when the
10000 Series Adapter caching was enabled at a maximum of one
megabyte, versus when the cache was not enabled. The average
response times were about 75 percent faster.
• The order entry set online transaction processing (OLTP) performance
increase was approximately 95 percent more transactions completed
in the one hour run with 10000 Series caching enabled at default
maximum size compared to cache not enabled. The average response
time was also about 45 percent faster.
Your results will vary depending on machine load, query composition, and
Oracle RAC configuration (number of nodes). SwingBench is designed
to stress the entire database environment and this stress testing is not
focused specifically on the storage access. The largest gains are observed
where the storage access is heaviest, as in sales history reporting.
Figure 5. Performance Gains with Cache Enabled over Cache Disabled
Figure 6. Response Time Improvement with Cache Enabled over Cache Disabled
Test Scenarios
QLogic set up two test scenarios with the following workload types:
• Decision support system (DSS) and OLAP workload. This workload
depends on reading and analyzing large amounts of data from the
database. Analysis shows a marked benefit from the caching that is
shared between all the nodes in the Oracle RAC cluster. The OLAP I/O
pattern reads large blocks of data for the queries, and the LUN cache
was enabled to accept up to a 1MB block.
• OLTP workload. This workload contains less massive amounts of data,
resulting in more targeted reads and showing less caching benefit. The
OLTP I/O pattern reads and writes 8KB blocks of data, and the LUN
cache was enabled at the default size of 128KB.
Each test scenario was run with the following cache patterns:
• Cache not enabled on the 10000 Series Adapter
• Cache enabled for all LUNs and distributed to different 10000
Series Adapters
The cache patterns support the best practice definition of matching the
LUNs in a disk across the nodes in the RAC cluster. That is, the LUNs
supporting an ASM disk group are a multiple of the nodes in the cluster.