1

O OR RI IO ON N: : O OR RA AC CL LL L I I/ /O O N NU UM MB BL LR RS S C CA AL LI IB BR RA A1 1I IO ON N 1 1O OO OL L
Oriov i. cvrrevtt, ovt, araitabte a. beta, vv.v¡¡ortea .oftrare. Oracte ritt acce¡t vo tiabitit, for ¡robtev. ari.ivg frov it. v.e, vor aoe.
Oracte rarravt it. fitve.. for av, ¡vr¡o.e. ít. v.e i. ¡vret, ai.cretiovar, at tbe .ote ri./ of tbe v.er.

OVLRVILW
Orion is a tool íor predicting the períormance oí an Oracle database without ha·ing to install Oracle or create a
database. Unlike other I,O calibration tools, Orion is expressly designed íor simulating Oracle database I,O
workloads using the same I,O soítware stack as Oracle. It can also simulate the eííect oí striping períormed by ASM.
1he íollowing types oí I,O workloads are supported:
1. Small Random I,O. OL1P applications typically generate random reads and writes whose size is equi·alent to
the database block size, typically 8 KB. Such applications typically care about the throughput in I,Os Per Second
,IOPS, and about the a·erage latency ,I,O turn-around time, per request. 1hese parameters translate to the
transaction rate and transaction turn-around time at the application layer.
Orion can simulate a random I,O workload with a gi·en percentage oí reads ·s. writes, a gi·en I,O size, and a
gi·en number oí outstanding I,Os. 1he I,Os are distributed across all disks.

2. Large Sequential I,O. Data warehousing applications, data loads, backups, and restores generate sequential read
and write streams composed oí multiple outstanding 1 MB I,Os. Such applications are processing large amounts
oí data, like a whole table or a whole database and they typically care about the o·erall data throughput in
MegaBytes Per Second ,MBPS,.
Orion can simulate a gi·en number oí sequential read or write streams oí a gi·en I,O size with a gi·en number oí
outstanding I,Os. Orion can optionally simulate ASM striping when testing sequential streams.

3. Large Random I,O. A sequential stream typically accesses the disks concurrently with other database traííic.
\ith striping, a sequential stream is spread across many disks. Consequently, at the disk le·el, multiple sequential
streams are seen as random 1 MB I,Os, which we also call Multi-User Sequential I,O.

4. Mixed \orkloads. Orion can simulate 2 simultaneous workloads: Small Random I,O and either Large Sequential
I,O or Large Random I,O. 1his enables you to simulate, íor example, an OL1P workload oí 8 KB random
reads and writes with a backup workload oí 4 sequential read streams oí 1 MB I,Os.

lor each type oí workload, Orion can run tests at diííerent le·els oí I,O load to measure períormance metrics like
MBPS, IOPS and I,O latency. Load is expressed in terms oí the number oí outstanding asynchronous I,Os.
Internally, íor each such load level, the Orion soítware keeps issuing I,O requests as íast as they complete to
maintain the I,O load at that le·el. lor random workloads ,large and small,, the load le·el is the number oí
outstanding I,Os. lor large sequential workloads, the load le·el is a combination oí the number oí sequential streams
and the number oí outstanding I,Os per stream. 1esting a gi·en workload at a range oí load le·els helps the user
understand how períormance is aííected by load.

1LS1 1ARGL1S
Orion can, in theory, be used to test any disk-based character de·ice that supports asynchronous I,O. It has been
tested on the íollowing types oí targets:
1. DAS ,direct-attached, storage: Orion can be used to test the períormance oí one or more local disks or

2
·olumes on the local host.
2. SAN ,storage-area network, storage: Orion can be run on any host that has all or parts oí the SAN storage
mapped as character de·ices. 1he de·ices can correspond to striped or un-striped ·olumes exported by the
storage array,s, or indi·idual disks.
3. Orion has not been extensi·ely tested on NAS ,network-attached storage,, although it may successíully run
on NAS on certain operating systems platíorms. In general, the períormance results on NAS storage are
dependent on the I,O patterns with which the data íiles ha·e been created and updated. 1hereíore, you
should initialize the data íiles appropriately beíore running Orion.

ORION IOR S1ORAGL VLNDORS
Storage ·endors can use Orion to understand how Oracle databases will períorm on their storage arrays. Vendors can
also use Orion to íormulate a recommendation on how to best coníigure their storage arrays íor Oracle databases.

ORION IOR ORACLL ADMINIS1RA1ORS
Oracle administrators can use Orion to e·aluate and compare diííerent storage arrays, based on their expected
workloads. 1hey can also use Orion to determine the optimal number oí network connections, storage arrays, storage
array controllers, and disks íor their peak workloads. Appendix A describes ways oí characterizing a database`s
current I,O workload to iníer its IOPS and MBPS requirements.

GL11ING S1AR1LD WI1H ORION

1. Download Orion. Select the ·ersion oí Orion that corresponds to the operating system oí your host ser·er.
Orion is currently a·ailable íor Linux,x86, Solaris,SPARC and \indows,x86.
2. Install Orion:
a. Linux,Solaris: Unzip the Orion binary into a directory oí your choice and add it to your PA1l, ií
preíerred.
$ gunzip orion10.2_linux.gz
b. \indows: Run the Installer, it will let you choose the directory where Orion and its DLLs will be
installed.
C:\temp> orion10.2_windows.msi

3. Select a test name, a unique identiíier íor this calibration run. \e will use the example test name mytest`
through the rest oí this document.
4. Create a íile named mytest.lun. In the íile, list the raw ·olumes or íiles to test. Put one ·olume name per line.
Do not put comments or anything else in this íile. lor example:

/dev/raw/raw1
/dev/raw/raw2
/dev/raw/raw3
/dev/raw/raw4
/dev/raw/raw5
/dev/raw/raw6
/dev/raw/raw7
/dev/raw/raw8

5. Veriíy that all ·olumes are accessible using dd` or other equi·alent data copy tools. A typical sanity-check is to
do something like this ,example: Linux,:

3

$ dd if=/dev/raw/raw1 of=/dev/null bs=32k count=1024

Depending on your platíorm, the data copy tool used and its interíace may be diííerent írom abo·e.
6. Veriíy that your platíorm has the necessary libraries installed to do asynchronous I,Os. 1he Orion test is
completely dependent on asynchronous I,O. On Linux and Solaris, the library libaio needs to be in one oí the
standard lib directories or accessible through the shell en·ironment`s library path ·ariable ,usually
LD_LIBRAR\_PA1l or LIBPA1l, depending on your shell,. \indows has built-in asynchronous I,O
libraries, so this issue doesn`t apply.
¯. As a íirst test, we suggest a simple` test run. 1he simple test measures the períormance oí .vatt ravaov reaa. at
diííerent loads and then ,separately, targe ravaov reaa. at diííerent loads. 1hese results should gi·e an idea as to
how the I,O períormance diííers with I,O type and load. Such a test can be done with this short command line:

$ ./orion -run simple -testname mytest -num_disks 8
ORION: ORacle IO Numbers -- Version 10.2.0.1.0
Test will take approximately 30 minutes
Larger caches may take longer

1he I,O load le·els generated by Orion take into account the number oí disk spindles being tested ,pro·ided by
you in num_disks,. Keep in mind that the number oí spindles va, or va, vot be related to the number oí ·olumes
speciíied in the mytest.lun íile, depending on how these ·olumes are mapped.
8. 1he results oí these tests will be recorded in the output íiles shown below. 1he íile mytest_summary.txt is a good
starting point íor ·eriíying your input parameters and analyzing the output. 1he íiles mytest_.cs· contain
comma-separated ·alues íor se·eral I,O períormance measures ,discussed in detail below,.

OU1PU1 IILLS
Orion creates se·eral output íiles. Continuing the mytest` example, these íiles are explained below:
1. mytest_summary.txt: 1his íile contains:
a. Input parameters
b. Maximum throughput obser·ed íor the Large Random,Sequential workload
c. Maximum I,O rate obser·ed íor the Small Random workload
d. Minimum latency obser·ed íor the Small Random workload
2. mytest_mbps.csv: Comma-separated ·alue íile containing the data transíer rate ,MBPS, results íor the Large
Random,Sequential workload. 1his and all other CSV íiles contain a two-dimensional table. Lach row in the
table corresponds to a large I,O load le·el and each column corresponds to a small I,O load le·el. 1hus, the
column headings are the number oí outstanding small I,Os and the row headings are the number oí outstanding
large I,Os ,íor random large I,O tests, or the number oí sequential streams ,íor sequential large I,O tests,.
1he íirst íew data points oí the Orion MBPS output CSV íile íor mytest` are shown below. 1he simple mytest
command-line gi·en earlier does not test combinations oí large and small I,Os. lence, the MBPS íile has just
one column corresponding to 0 outstanding small I,Os. In the example below, at a load le·el oí 8 outstanding
large reads and no small I,Os, we get a data throughput oí 103.06 MBPS.

Large/Small, 0
1, 19.18
2, 37.59
4, 65.53
6, 87.03
8, 103.06

4
10, 109.67
. . . . .
. . . . .
1he íollowing chart illustrates the data transíer rate measured at diííerent large I,O load le·els. 1his chart can be
generated by loading mytest_mbps.cs· into Microsoít Lxcel or OpenOííice and graphing the data points using the
application. Orion does not directly generate such graphs. 1he x-axis corresponds to the number oí outstanding large
reads and the y-axis corresponds to the throughput obser·ed.



3. mytest_iops.csv: Comma-separated ·alue íile containing the I,O throughput ,in IOPS, results íor the Small
Random workload. Like in the MBPS íile, the column headings are the number oí outstanding small I,Os and
the row headings are the number oí outstanding large I,Os ,when testing large random, or the number oí
sequential streams ,íor large sequential,.
In the general case, this CSV íile contains a two-dimensional table. lowe·er, íor the simple mytest command-line
gi·en earlier, we aren`t testing combinations oí large and small I,Os. lence, the IOPS results íile just has one
row with 0 large I,Os. In the example below, with 12 outstanding small reads and no large I,Os, we get a
throughput oí 951 IOPS.


Large/Small, 1, 2, 3, 6, 9, 12 . . . .
0, 105, 208, 309, 569, 782, 951 . . . .


1he graph below ,generated by loading mytest_iops.cs· into Lxcel and charting the data, illustrates the IOPS
throughput seen at diííerent small I,O load le·els.
Large MBPS
1 19.18
2 37.59
4 65.53
6 87.03
8 103.06
10 109.67
12 117.7
14 127.06
16 130.55
20 138.42
24 141.21
28 145.5
0
20
40
60
80
100
120
140
160
0 5 10 15 20 25 30

5

4. mytest_lat.csv: Comma-separated ·alue íile containing the latency results íor the Small Random workload. Like
in the MBPS and IOPS íiles, the column headings are the number oí outstanding small I,Os and the row
headings are the number oí outstanding large I,Os ,when testing large random I,Os, or the number oí sequential
streams.
In the general case, this CSV íile contains a two-dimensional table. lowe·er, íor the simple mytest command-line
gi·en earlier, we don`t test combinations oí large and small I,Os. lence, the IOPS results íile just has one row
with 0 large I,Os, as shown below. In the example below, at a sustained load le·el oí 12 outstanding small reads
and no large I,Os, we get an I,O turn-around latency oí milliseconds.

Large/Small, 1, 2, 3, 6, 9, 12 . . . .
0, 14.22, 14.69, 15.09, 16.98, 18.91, 21.25 . . . .

1he íollowing graph ,generated by loading mytest_lat.cs· into Lxcel and charting the data, illustrates the small
I,O latency at diííerent small I,O load le·els íor mytest.


1 14.22
2 14.69
3 15.09
6 16.98
9 18.91
12 21.25
18 25.92
24 30.2
30 34.8
36 39.04
48 47.68
60 56.3
69 62.16
0
10
20
30
40
50
60
70
0 20 40 60 80


5. mytest_trace.txt: Contains extended, unprocessed test output.
SmaII IOPS
1 105
2 208
3 309
6 569
9 782
12 951
18 1189
24 1369
30 1521
36 1638
48 1815
60 1941
69 2013 0
500
1000
1500
2000
2500
0 20 40 60 80

6
Lxcept íor mytest_trace.txt, ií any oí these íiles already exist, they will be o·erwritten. Lach run oí Orion appends to
mytest_trace.txt ,or the equi·alent trace íile name íor your test name,.
NO1L: II ANY LRROR OCCURS DURING 1HL 1LS1, I1 WILL BL PRIN1LD 1O S1ANDARD
OU1PU1.

INPU1 PARAML1LRS
Orion can be used to test any oí the workloads described in the o·er·iew using its ·arious command-line options. In
this section, we describe these options and the output íiles.

MANDA1OR\ INPU1 PARAML1LRS
run: 1est run le·el. 1his option pro·ides simple command lines at the simple and normal run le·els and allows
complex commands to be speciíied at the ad·anced le·el. Ií not set as -run advanced, then setting any other non-
mandatory parameter ,besides -cache_size or -verbose, will result in an error.
simple: Generates the Small Random I,O and the Large Random I,O workloads íor a range oí load le·els.
In this option, small and large I,Os are tested in isolation. 1he only optional parameters that can be speciíied
at this run le·el are -cache_size and -·erbose. 1his parameter corresponds to the íollowing in·ocation oí
Orion:
%> ./orion -run advanced -testname mytest \
-num_disks NUM_DISKS \
-size_small 8 -size_large 1024 -type rand \
-simulate concat -write 0 -duration 60 \
-matrix basic
normal: Same as -simple, but also generates combinations oí the small random I,O and large random
I,O workloads íor a range oí loads. 1he only optional parameters that can be speciíied at this run le·el are -
cache_size and -·erbose. 1his parameter corresponds to the íollowing in·ocation oí Orion:
%> ./orion -run advanced -testname mytest \
-num_disks NUM_DISKS \
-size_small 8 -size_large 1024 -type rand \
-simulate concat -write 0 -duration 60 \
-matrix detailed
advanced: Indicates that the test parameters will be speciíied by the user. Any oí the optional parameters
can be speciíied at this run le·el.
testname: Identiíier íor the test. 1he input íile containing the disk or íile names must be named ·testname·.lun.
1he output íiles will be named with the preíix ·testname·_.
num_disks: Actual number oí physical disks used by the test. Used to generate a range íor the load.

OP1IONAL INPU1 PARAML1LRS
help: Prints Orion help iníormation. All other options are ignored when help is speciíied.
size_small: Size oí the I,Os ,in KB, íor the Small Random I,O workload. ,Deíault is 8,.
size_large: Size oí the I,Os ,in KB, íor the Large Random or Sequential I,O workload. ,Deíault is 1024,.
type: 1ype oí the Large I,O workload. ,Deíault is rand,:
rand: Large Random I,O workload.
seq: Large Sequential I,O workload.
num_streamIO: Number oí outstanding I,Os per sequential stream. Only ·alid íor -type seq. ,Deíault is 1,.

7
simulate: Data layout to simulate íor Large Sequential I,O workload.
1

concat: A ·irtual ·olume is simulated by serially chaining the speciíied LUNs. A sequential test o·er this
·irtual ·olume will go írom some point to the end oí one LUN, íollowed by the beginning to end oí the next
LUN, etc.
raid0: A ·irtual ·olume is simulated by striping across the speciíied LUNs. 1he stripe depth is 1M by deíault
,to match the Oracle ASM stripe depth, and can be changed by the -stripe parameter.
write: Percentage oí I,Os that are writes, the rest being reads. 1his parameter applies to both the Large and Small
I,O workloads. lor Large Sequential I,Os, each stream is either read-only or write-only, the parameter speciíies the
percentage oí streams that are write-only. 1he data written to disk is garbage and unrelated to any existing data on
the disk. WARNING: WRI1L 1LS1S WILL OBLI1LRA1L ALL DA1A ON 1HL SPLCIIILD LUNS.
cache_size: Size oí the storage array`s read or write cache ,in MB,. lor Large Sequential I,O workloads, Orion will
warm the cache by doing random large I,Os beíore each data point. It uses the cache size to determine the duration
íor this cache warming operation. Ií not speciíied, warming will occur íor a deíault amount oí time. Ií set to 0, no
cache warming will be done. ,Deíault is not speciíied, which means warming íor a deíault amount oí time,.
duration: Duration to test each data point in seconds. ,Deíault is 60,.
matrix: 1ype oí mixed workloads to test o·er a range oí loads. ,Deíault is detailed,.
basic: No mixed workload. 1he Small Random and Large Random,Sequential workloads will be tested
separately.
detailed: Small Random and Large Random,Sequential workloads will be tested in combination.
point: A single data point with ´ outstanding Small Random I,Os and í outstanding Large Random I,Os
or sequential streams. ´ is set by the num_small parameter. í is set by the num_large parameter.
col: Large Random,Sequential workloads only.
row: Small Random workloads only.
max: Same as detailed, but only tests the workload at the maximum load, speciíied by the num_small
and num_large parameters.
num_small: Maximum number oí outstanding I,Os íor the Small Random I,O workload. Can only be speciíied
when matrix is col, point, or max.
num_large: Maximum number oí outstanding I,Os íor the Large Random I,O workload or number oí concurrent
large I,Os per stream. Can only be speciíied when matrix is row, point, or max.
verbose: Prints progress and status iníormation to standard output.


1
1he oíísets íor I,Os are determined as íollows:
lor Small Random and Large Random workloads:
• 1he LUNs are concatenated into a single ·irtual LUN ,VLUN, and random oíísets are chosen within the VLUN.
lor Large Sequential workloads:
• \ith striping ,-simulate raid0,. 1he LUNs are used to create a single striped VLUN. \ith no concurrent Small
Random workload, the sequential streams start at íixed oíísets within the striped VLUN. lor v streams, stream i will
start at oííset VLUNsize ,i - 1, , ,v - 1,, except when v is 1, in which case the single stream will start at oííset 0.
\ith a concurrent Small Random workload, streams start at random oíísets within the striped VLUN.
• \ithout striping ,-simulate CONCAT,. 1he LUNs are concatenated into a single VLUN. 1he streams start at
random oíísets within the single VLUN.


8
COMMAND-LINL LXAMPLLS

• For a preliminary run to understand your storage perIormance with read-only, small and large random I/O
workloads:
$ orion -run simple -testname mytest -num_disks 8
• Similar to the above, but with a mixed small and large random I/O workload:
$ orion -run normal -testname mytest -num_disks 12
• To generate combinations oI 32KB and 1MB reads to random locations:
$ orion -run advanced -testname mytest -num_disks 6 -size_small 32 \
-size_large 1024 -type rand -matrix detailed
• To generate multiple sequential 1MB write streams, simulating 1MB RAID-0 stripes:
$ orion -run advanced -testname mytest -num_disks 15 -simulate raid0 \
-stripe 1024 -write 100 -type seq -matrix col -num_small 0

1ROUBLL-SHOO1ING
• Ií you are getting an I,O error on one or more oí the ·olumes speciíied in the ·testname·.lun íile:
o Veriíy that you can access it in the same mode as the test ,read or write, using a íile copy program such as
dd.
o Veriíy that your host operating system ·ersion is capable oí doing asynchronous I,O.
o On Linux and Solaris, the library libaio needs to be in one oí the standard lib directories or accessible
through the shell en·ironment`s library path ·ariable ,usually LD_LIBRAR\_PA1l or LIBPA1l,
depending on your shell,.
• Ií you are running on NAS storage:
o 1he íile system must be properly mounted íor Orion to run. Please consult your Oracle Installation
Guide íor directions ,íor example, Appendix B Using NAS De·ices` in the Database Installation Guide
íor Linux x86,.
o 1he mytest.lun íile should contain one or more paths oí existing íiles. Orion will not work on directories
or mount points. 1he íile has to be large enough íor a meaningíul test. 1he size oí this íile should
represent the e·entual expected size oí your dataíiles ,say, aíter a íew years oí use,.
o \ou may see poor períormance doing asynchronous I,O o·er NlS on Linux ,including 2.6 kernels,.
o Ií you`re doing read tests and the reads are hitting blocks oí the íile that were not initialized or pre·iously
written to, some smart NAS systems may íake` the read by returning you zeroed-out blocks. 1he
workaround is to write all blocks ,using a tool like dd, beíore doing the read test.
• Ií you are running Orion on \indows:
o 1esting on raw partitions requires temporarily mapping the partitions to dri·e letters and speciíying these
dri·e letters ,like ``.`x: ,in the test.lun íile.
• Ií you are running an Orion 32-bit Linux,x86 binary on an x86_64 machine:
o Please copy a 32-bit libaio.so íile írom a 32-bit machine running the same Linux ·ersion.
• 1he mytestIí you are testing with a lot oí disks ,num_disks greater than around 30,:
o \ou should use the -duration option ,see the optional parameters section íor more details, to speciíy a
long duration ,like 120 seconds or more, íor each data point. Since Orion tries to keep all spindles
running at a particular load le·el, each data point requires a ramp-up time , which implies a longer
duration íor the test.

9
o \ou may get the íollowing error message, instructing you to increase the duration time, but we suggest
doing it proacti·ely:

Specify a longer -duration value.

A duration oí 2x the number oí spindles seems to be a good rule oí thumb. Depending on your disk
technology, your platíorm may need more or less time.
• Ií you get an error about libraries being used by Orion:
o Linux,Solaris: See I,O error troubleshooting abo·e.
o N1-Only: Do not mo·e,remo·e the Oracle libraries included in the distribution. 1hese need to be in
the same directory as orion.exe.
• Ií you are seeing períormance numbers that are unbelie·ably good`:
o \ou may ha·e a large read and,or write cache somewhere between the Orion program and the disk
spindles. 1ypically, the storage array controller has the biggest eííect. lind out the size oí this cache and
use the -cache_size ad·anced option to speciíy it to Orion ,see the optional parameters section íor more
details,.
o 1he total size oí your ·olumes may be really small compared to one or more caches along the way. 1ry
to turn oíí the cache. 1his is needed ií the other ·olumes sharing your storage will see signiíicant I,O
acti·ity in a production en·ironment ,and end up using large parts oí the shared cache,.
• Ií Orion is reporting a long estimated run time:
o 1he run time increases when -num_disks is high. Orion internally uses a linear íormula to determine
how long it will take to saturate the gi·en number oí disks.
o 1he -cache_size parameter aííects the run time, e·en when it`s not speciíied. Orion does cache warming
íor two minutes per data point by deíault. Ií you ha·e turned oíí your cache ,which we recommend íor
read caches where possible,, speciíy -cache_size 0.
o 1he run time increases when a long -duration ·alue is speciíied, as expected.



10
APPLNDIX A: CHARAC1LRIZING 1HL DA1ABASL I/O LOAD
2

1o properly coníigure your database storage, you must understand your database`s períormance requirements. In
particular, you must answer the íollowing questions:
J. Will the I/O requests be primarily single-block or multi-block?
Databases issue multi-block I,Os when períorming the íollowing types oí operations: parallel queries, queries
on large tables that require table scans, direct data loads, backups, and restores. In general, DSS and data
warehouse en·ironments issue large amounts oí multi-block I,Os whereas OL1P databases primarily issue
single-block I,Os.
2. What is your average and peak I/Os per second (IOPS) requirement? What percentage of this traffic
are writes?
3. What is your average and peak throughput (in MBPS) requirement? What percentage of this traffic
are writes?
Ií your database`s I,O requests are primarily single-block, then you should íocus on ensuring that the storage can
accommodate your I,O request rate ,IOPS,. Ií they are primarily multi-block, then you should íocus on the storage`s
throughput capacity ,MBPS,.
Ior an existing J0gR2 database, you can characterize your I,O traííic by looking at the database statistics in the
V>S\SS1A1 ·iew, as reíerenced by the names gi·en below. 1hese statistics are cumulati·e ·alues that should be
sampled during both the typical and peak periods.
• single-block reads: physical read total IO requests` - physical read total multi block requests`
• multi-block reads: physical read total multi block requests`
• bytes read: physical read total bytes`
• single-block writes: physical write total IO requests` - physical write total multi block requests`
• multi-block writes: physical write total multi block requests`
• bytes written: physical write total bytes`
Ior an existing pre-J0gR2 database, the I,O statistics are speciíied in multiple ·iews. 1he bulk oí the I,O traííic is
described as íollows:
• single-block data íile reads: V>lILLS1A1.SINGLLBLKRDS speciíies the number oí such I,O requests.
• multi-block data íile reads: V>lILLS1A1.Pl\RDS - V>lILLS1A1.SINGLLBLKRDS speciíies the
number oí such I,O requests.
• single-block data íile writes: V>lILLS1A1.Pl\\R1S speciíies the number oí such I,O requests.
• multi-block data íile writes: V>lILLS1A1.Pl\BLK\R1 speciíies the number oí DB\R writes plus the
number oí direct I,O blocks written. Uníortunately, there isn`t a way to deri·e the number oí multi-block
I,O requests, but in general, direct I,Os are multi-block I,Os. 1he number oí direct I,O blocks written is
V>lILLS1A1.Pl\BLK\R1 - V>lILLS1A1.Pl\\R1S.
• redo log writes: in V>S\SS1A1, redo blocks written` speciíies the number oí blocks written and redo
writes` speciíies the number oí I,O requests.
• backup I,Os: in V>BACKUP_AS\NC_IO and V>BACKUP_S\NC_IO, the IO_COUN1 íield speciíies the
number oí I,O requests and the 1O1AL_B\1LS íield speciíies the number oí bytes read or written. Note
that each row oí this ·iew corresponds to a data íile, the aggregate o·er all data íiles, or the output backup
piece.

2
1his section is taken írom the Oracle white paper Best Practices íor a Low-Cost Storage Grid íor Oracle Databases`. \e
recommend that you reíerence this paper íor the latest ·ersion oí this iníormation.

11
• ílashback log I,Os: In V>lLASlBACK_DA1ABASL_S1A1, lLASlBACK_DA1A, DB_DA1A, and
RLDO_DA1A show the number oí bytes read or written írom the ílashback logs, data íiles, and redo logs,
respecti·ely, in the gi·en time inter·al. In V>S\SS1A1, the ílashback log writes` statistic speciíies the
number oí write I,O requests to the ílashback log.
Using this data, you can estimate the read and write IOPS requirement írom the number oí physical reads and writes
issued in a gi·en duration oí time, both at peak and normal loads. \ou can estimate the read and write MBPS
requirement írom the number oí bytes read and written per second, again at both peak and normal loads. 1he
number oí writes compared to the number oí reads indicates the write percentage` to be speciíied to Orion. lor
example, ií your applications typically do 600 writes and 200 reads in a gi·en duration, your write percentage would be
¯5° ,-write ¯5,. Please read the warnings in the ÷write option description before doing write tests.
Note that these statistics do not include all I,O traííic, such as control íile and archi·er-generated I,Os.

APPLNDIX B: NO1LS IOR DA1A WARLHOUSING

I,O períormance should always be a key consideration íor data warehouse designers and administrators. 1he typical
workload in a data warehouse is especially I,O intensi·e, with operations such as queries o·er large ·olumes oí data,
large data loads and index builds and creation oí materialized ·iews. 1he underlying I,O system íor a data warehouse
should be designed to meet these hea·y requirements.
Storage coníigurations íor a data warehouse should be chosen based on the I,O bandwidth that they can pro·ide, and
not necessarily on their o·erall storage capacity. 1he capacity oí indi·idual disk dri·es is growing íaster than the I,O
throughput rates pro·ided by those disks, leading to a situation in which a small number oí disks can store a large
·olume oí data, but cannot pro·ide the same I,O throughput as a larger number oí small disks. \ou get maximal I,O
bandwidth by ha·ing multiple disks and channels contribute to the hea·y database operations. Striping data íiles across
de·ices ,ideally, all de·ices, is a way to achie·e this. Implement a large stripe size ,1 MB, in order to ensure that the
time to position the disk is a small percentage oí the time to transíer the data.
1he workload íor a data warehouse is typically characterized by sequential I,O throughput, issued by multiple
processes. \ou can simulate this type oí workload with Orion. Depending on the type oí system you plan to build,
you should run multiple diííerent I,O simulations. lor example,
• Daily workload when end-users and,or other applications query the system: read-only workload with possibly
many indi·idual parallel I,Os.
• 1he data load, when end-users may or may not access the system: write workload with possibly parallel reads
,by the load programs and,or by end-users,.
• Index and materialized ·iew builds, when end-users may or may not access the system: read,write workload.
• Backups: read workload with likely íew other processes, but a possibly high degree oí parallelism.
Use the íollowing options in the ad·anced user mode oí Orion to simulate the diííerent data warehouse-like workload
types:
• run: use 'ad·anced' in order to simulate only large sequential I,Os.
• large: the I,O size in KB íor large sequential loads. Set this parameter to a multiple oí the operating system
I,O size. lor a data warehouse, you should plan íor single I,O requests that are as large as possible. On
most platíorms, this size is 1 MB.
• type: use 'seq' to simulate a large sequential I,O workload.
• num_streamIO: increase this parameter in order to simulate parallel execution íor indi·idual operations.
Speciíy a degree oí parallelism that you plan to use íor your database operations. A good starting point íor the
degree oí parallelism is the number oí CPUs on your system multiplied by the number oí parallel threads per
CPU.

12
• simulate: use 'CONCA1' ií the de·ices are already striped as they are presented to the database, e.g. ií
striping takes place on the hardware le·el or through a ·olume manager. Use 'raid0' íor de·ices that ha·e yet
to be striped, íor example by Oracle Automatic Storage Manager. 1he stripe size íor 'raid0' deíaults to 1 MB.
• write: speciíy the percentage oí I,Os that you want to be writes. 1ake your data load programs into account
and the access to the system during the load window in order to set the percentage. \ARNING: \RI1L
1LS1S \ILL OBLI1LRA1L ALL DA1A ON 1lL LUNS.
• matrix: use 'point' to simulate an indi·idual sequential workload, or use 'col' to simulate an increasing number
oí large sequential workloads.
• num_large: speciíy the maximum number oí large I,Os.
In a clustered en·ironment, you will ha·e to in·oke Orion in parallel on all nodes in order to simulate a clustered
workload. lor example, the íollowing example is an Orion run íor a typical data warehouse workload. 1o get started,
a íile orion14.lun was created, with the íollowing contents:

/dev/vx/rdsk/asm_vol1_1500m
/dev/vx/rdsk/asm_vol2_1500m
/dev/vx/rdsk/asm_vol3_1500m
/dev/vx/rdsk/asm_vol4_1500m

1hese 4 disks are indi·idual ·olumes that are not striped on the hardware le·el, nor on a ·olume manager le·el. ASM
would be used to stripe data íiles across these 4 ·olumes. 1he íollowing command in·okes Orion:

./orion -run advanced \
-testname orion14 \
-matrix point \
-num_small 0 \
-num_large 4 \
-size_large 1024 \
-num_disks 4 \
-type seq \
-num_streamIO 8 \
-simulate raid0 \
-cache_size 0 \
-verbose

1he run simulates 4 parallel sessions ,-num_large 4, running a statement with a degree oí parallelism oí 8 ,-
num_streamIO 8,. Orion simulates a raid0 striping. 1he internal disks in this case do not ha·e cache. As a result oí
running this command, the íile orion14_summary.txt is generated with the íollowing contents:

ORION VERSION 10.2

Command line:
-run advanced -testname orion14 -matrix point -num_large 4 -size_large 1024 -
num_disks 4 -type seq -num_streamIO 8 -simulate raid0 -cache_size 0 -verbose

This maps to this test:
Test: orion14
Small IO size: 8 KB
Large IO size: 1024 KB
IO Types: Small Random IOs, Large Sequential Streams
Number of Concurrent IOs Per Stream: 8
Force streams to separate disks: No
Simulated Array Type: RAID 0

13
Stripe Depth: 1024 KB
Write: 0%
Cache Size: 0 MB
Duration for each Data Point: 60 seconds
Small Columns:, 0
Large Columns:, 4
Total Data Points: 1

Name: /dev/vx/rdsk/asm_vol1_1500m Size: 1572864000
Name: /dev/vx/rdsk/asm_vol2_1500m Size: 1573912576
Name: /dev/vx/rdsk/asm_vol3_1500m Size: 1573912576
Name: /dev/vx/rdsk/asm_vol4_1500m Size: 1573912576
4 FILEs found.

Maximum Large MBPS=57.30 @ Small=0 and Large=4

In other words, the maximum throughput íor this speciíic case with that workload is 5¯.30 MBps. In ideal conditions,
Oracle will be able to achie·e up to about 95° oí that number. lor this particular case, ha·ing 4 parallel sessions
running the íollowing statement would approach the same throughput:

select /*+ NO_MERGE(sales) */ count(*) from
(select /*+ FULL(s) PARALLEL (s,8) */ * from all_sales s) sales

Note that the Oracle database has se·eral optimizations that would make a statement like this run íaster in case it
wasn't íorced to read the entire table.
In a well-balanced data warehouse hardware coníiguration, there is suííicient I,O bandwidth to íeed the CPUs. As a
starting point, you can use the basic rule that e·ery Glz oí CPU power can dri·e at least 100 MBps. I.e., íor a single
ser·er coníiguration with íour 3 Glz CPUs, your storage coníiguration should at least be able to pro·ide 4 3 100
~ 1200 MBps throughput. 1his number should be multiplied by the number oí nodes in a RAC coníiguration.

7 " 7 2 7 ( 8 " ( ' !. .0 7- / -. " # / 7 / . *: ' %4 3 *: 3 #% 1&& 2 5 4 1 ) 3 ' 6 # < = ! " # $ > 8 #& .' ) 9 $ 0 1 & # & # ( ' ".# < = ) / .

-. ? ?B - 4 $ ! "!# $ %&# " # < = # 0 % ! ! ! ! " '(!%)! ) - & % % 4 / " .%& %& ' & ( ) & : 1 8 & &1?& . / ) " !.' * C " & ./ 2 3 " ? * " ( / .' .' E % ) -!.' ".) ( ) )4 + ( * ... D " / 3 5 6 6 6 6 "6 $6 .% %@?' ". + " " . 9 < = .. & . 4 8 ) 4 8 < $E2 E: !. !.' = . 3 " " / " - A # * . 9 . / ' 00 1 + + * $ .

' - ' .' ) 4 8 .6 " ? / ! C " / " 2 % ) ! "* (!%)! 4 & - / !. / $0 . ' . / ' D 9 E F>$ 3 5 6 6 6 6 "6 76 " - ? C . . .

5 ! " %)! !. .' 4 ' / 4 8 9 / / . % ) & / ' $0 D E 3 6 5 6 6 6 6 "76 ! 6 76 "6 " 7$6 76 $ 7 6 ! " - ? C . > !"$ ) %& 4 . .

& % ! 2 & ) -# "! $ 7 .5<5 $ * ) ) * -) !" -# " *!. ) 0 + = -1 $.. & % " ? ( H " + * + * " ) * /9: . .+.5<5 $ * ) ) * ." " 0 ) / !* ( # 8 0 * * * * /) )4 % / ( / ' G . -1 $E05. ... -1 & % % ..$ ? ( 8 0 * * * 0 " H * ( / # + * + * " " ) * /9: . C / ! 71 " %@ 7' " ' % !C"C% $#.# -1 ) *. .C ? % + ? ) .! '" 7 & 7' " ' % !C"C% " I J? I J / ( ' !*0 "! ( !*0 " $1 ( ( " & $ .+.

. -1 " % & % % ) :E.L $.!. ) % % % ) & % % & 4 % 4 ! $ " % • " 3 % 3 • 3 & 7 ) -0 ) 8& 7 ( B .L $. " / / K 0 ) " & $! 4$* % ) )/ "!*0 ( -1 #$ * ./ >2. " .!* # 1 ) -) & 7 $ * 3 ' 6 & ) / & ) $ & 7 & 7 & 7 ! K " . & 7 & 7 $ 8& 7 8& 7 " 8& 7 3 8& 7 6 E 8& 7 6 6 .. -1 & % .1 $*& " ' !*) 7 * ( *) ) & $ 4 & -# "! -# " $1 $' ! ' ! ) 9 . % -0 # & • & % # # & 7 -8& 7. " 8& 7 . 6 & ) ( E .

I . 7 # . • " G & " " ( @ 9 7 • " • ' • " @ H $0E . & .# . 20/ & *: 20/ ? *:?:5 # & 2E.5 • 0 • 0 • " 0 0 • " 0 0 6 0 ! 0 #$%& ) 0 0 + '(& ) 0 0 0 + '(& + + + 0 0 0 0 ( ( $ ( " 0 ) '(& *+ . ( / 76 & " ( . *:. 0: ( " . + = 0 0 ) ( 0 ! 0 5 • 8 8 & 9 . ) / 20/ MM M # .% %@?' ".< 7 ' 1 = 1 G &1?& . 3 ) # < = .' ". J # .

" ( " • " " H ? ( .@ # 5 ) %+ 0 0 • & 5 • @ " H . - . " H H ? ( E H ? 9 # ? ( 6 1 < =# # # 1 " ( " .

&*! *-1 ($ 5931 8 # • • / / " ) 7G&C.@3%" • = • # # 8N @ " " < ) 8N.( .&+%1 ) =H< ) = =H< ) = . $ .@%1 H 8N6 &C " " < ?4 7" 7 0 " <.1 ( $) .@"C = " 7G&C.@.( . ' & /4 G 1 = 3 .1 = /*! $ ==*) = /*! $ ==*) . /$ #1/(# .@. !( $! ) .6 " 9% 1 / / *! #$ $ 4$* !: / *! #$ $ 4$* !: 9 * / 7 ) # $* !*-1 5' ). ( " ) = #< #< = ' ! # 8N6 &C " " ) • • / / # 8N6 &C " " '.3% / # 8N6 &C " " '. $ 8 9 $ 2# ! ! ' ($* / ) # *5' ). 4+ '? @74? ) " " &?.&+%1 ) 1.*/ ) -!.@3%" # 8N6 &C " " '.. < $ 2#*$ < $ 2#*$ -: -: &"' / / ( $) .' . 4+ '? @74? 8N.&*! *-1 931 8 ' ! 8N @ " " • • • • • • / / / / #< #< #< / 9 ) = ) = #< $ .: # ) ) 1 ) / 8% 2 $ 1 $ 1 ) ' .&+3%" 9 ) / 8N6 &C " " '.&+3%" / 8N6 &C " " '.

• %C1 ?1 " # 8N6& ) .?1 " 8N @ " " ' ) A>O -/ 7 A>.. 4+?1 " . / # / ) # # / . # / 1 " ( / / ./ >4$* ( * - !.. 4+?1 " = 1.. ) ) ) .' " = 6 ! $ !)$*( * . ( 1 ) ( -$ !.' = $ / *-1 4$* ! !% 6 " ) ( ) " @ " @ 6 • • • • # • • $#$1 ( 6 ( • • ( -# "! $ 4' 4' P )P $ !. " . ) P ( P +. ) @ < :EE 0EE / 4 $-*-1! *. C? " " 6& < .

/ 1?-5. $ 0 0 0 0) )4 0 0 ' = 0 .. 5 = $ / 5 0 . $ " ? *.C & 7 ) P P ( EP P EP $ !. • 4$* "C " 3 && • • $*& ) -# " $1 6 $5 ( ( ( ( P " # ! ! ! ! " 5 5 0 ) ! " # 0 0 0 0 0 0 0 + 0 0 0) )4 0 ' ( = .. 6 3 ./ 0 ( 24 2 5 .... ...• !* # P4 74 "P P ! " " 3 %7 7G# 3% "C .& "C% "C && 1 " P 7 "... 3 . 5 -/ E $5? ? 5. A 5 ( ->. 2+ 5 / ' % B ) 5 > ) 0 0 + 4 $ <@ <@ ) + 2+ .-.. " # * -/ .

3? : % 3 :@A5&!# F>O 6 # >A 2E !. A <@ :@ )4 . 5 ) H EF /. . 5 3 2 / / / / . :?-G?H I E ) HEI % ) EF B933H I A>->33?3 H 6$I E E % I 7 P / ( 4' G. 4 8 5 % . 5 B 2 B $EE % 4 " Q $0EE !.( 4' 4' $EE !. 6 6 ( ( ( ( A " ) ! ! ! ! D 5 & 5 5 5 5 3 & !# !# !# !# $" 7 !#" 7 !#" 7 !#" B.( 2 G.5 C )4 .

Sign up to vote on this title
UsefulNot useful