2730100 Oracle Performance With Unix

8/10/2019 2730100 Oracle Performance With Unix

http://slidepdf.com/reader/full/2730100-oracle-performance-with-unix 1/8

Performance Tuning and Capacity Planning for a Large Scale

Oracle OLTP UNIX System - a Case Study

Tim Foxon !i"e #art$

!etron Tec$nology Limited% Taunton% U&'&This paper describes the authors' experiences of performance tuning and prediction in large Oracle OLTP systems.Attendees will learn which performance and resource consumption metrics are really important, where they arefound, and how they are used for performance tuning. The paper then defines the method used for building amathematical model of Oracle performance. The way in which that model was is used for response time predictionand for evaluating tuning and upgrade strategies is described. This paper is of interest to anyone who is responsiblefor the uality of Oracle system performance, or who may be affected by its absence.

(& Introduction

!mbar"ing upon a performance management exercise in an Oracle#$%& environment can be a daunting prospect.(oth Oracle and $%& are blessed )*+ with a plethora of performance metrics and configuration parameters.owever, approaching this topic by listing all the available performance metrics is li"e teaching a language bysupplying a dictionary. &n contrast to the static view provided by a list of metrics, section - of this paper provides an

assessment of the dynamics of an Oracle system. rom this abstraction the areas which should receive attention arederived/0 ma1or 23A structures and their effect on physical resource consumption )section 4+0 dis" storage and fragmentation effects )section 5+0 26L and database navigation )section 7+0 contention for logical resources )section 8+The paper concludes with a discussion on the desirability and methods of modelling Oracle systems.!ach section is illustrated with reference to a particular performance management case study. The application wasimplemented on an 9:processor $%& machine with around -7;3( of striped filestore on over 8; physical devices.The users of the application experienced highly variable response times which, at pea" periods, were limiting theirthroughput. <e were as"ed to assess and remedy the causes of this, and to define the hardware resources reuired toaccommodate the expected increase in end:user wor".<hen assessing the performance of an application it is essential to address the system as a whole, rather than 1ust

from an Oracle or an operating system viewpoint. A recent performance study illustrated the dangers of a restrictedview. <e were as"ed to identify the reasons why a particular Oracle application was performing badly. The Oracleteam had attempted )uite correctly+ to maximise the database buffer cache hit:rate. (y increasing the number of buffer bloc"s they were eventually able to achieve a hit:rate consistently in excess of ==>. $nfortunately thisincreased the si?e of the 23A to the point that $%& started to page to and from dis". This caused considerableamounts of &#O )thus adversely affecting performance+ which was not apparent from any of the Oracle metrics.<hen tuning any Oracle system, the areas to address )in this order+ are/)a+ the design )if it's not too late@+)b+ the application)c+ memory)d+ &#O)e+ contentionThe main goals in Oracle tuning )ta"en from Oracle's own documentation+ are to ma"e sure that/

0 26L statements access the smallest possible number of Oracle bloc"s0 if a bloc" is needed, it is cached in memory0 users share the same code0 when code is needed it is cached in memory0 where physical &#O to dis" is unavoidable, it is performed as uic"ly as possible0 users never have to wait for resources used by othersThe ways in which these goals can be achieved are discussed in sections 4 to 8 of this paper.



)& Oracle *ynamics

igure shows, in a simplified form, the main Oracle dynamics. This picture attempts to establish the relationship between an occurrence of an Oracle wor"load, and the factors which can affect its response time. The oval shapesrepresent application reuirements, the suare shapes indicate physical resources and the round shapes performancemetrics. %ote in particular the feedbac" loop connecting response time )represented by the sum of the activities inthe shaded box on the right hand side+ with concurrency. This can be defined using Little's Law BC which relatesresponse times and the number of in:memory processes in an open system.Duch of this dynamic behaviour is non:linear and cannot therefore be simply extrapolated. or example : theresponse time at each potential delay point is the sum of the busy time and the ueuing time. The ueuing time for a physical device is a non:linear function of its utilisation. A modelling approach which encompasses this behaviour isdiscussed in section E.

+& System #lo,al rea&n order to appreciate the importance of the memory structures contained within the 23A, the algorithms used tomanage them, and their effect on physical resource consumption, we should first consider the seuence of eventscaused when Oracle updates a row of a table. igure - below describes a simplified view.. The row to be updated is first copied to the buffer cache in the 23A and loc"ed.-. A 'before image' )a copy of the original row+ is written to the buffer cache for rollbac". This is written to the

rollbac" segments on dis" by the database writer asynchronously.4. The row is modified in the buffer cache.5. The changed row is copied to the redo log buffer.7. The update is committed and flagged in the redo log buffer.8. The committed row is written to the redo log by the log writer )L3<F+.E. The modified row is written to dis" by the database writer )G(<F+Hlearly any contention for resources relating to the buffer cache, redo or rollbac" mechanism will have a seriouseffect on throughput and response times. Any contention for the Library Hache )used to store shared 26L+ and theGictionary Hache )used to store ob1ect definitions+ will also affect response times. !ach of these areas is consideredseparately below.3.1 Buffer Cache The buffer cache is used to store database bloc"s that contain tables, indexes, clusters, rollbac" segments and sortdata. !ach buffer holds a single database bloc". The number of buffers is defined in the &%&T.OFA parameterG(I(LOHJI ($!F2. The important metric here is the probability that Oracle finds the bloc" that it needsalready in the cache, rather than having to get the bloc" from dis". This is referred to as the buffer cache hit:ratio. &tis calculated from the &#O data provided in the dynamic performance view K2M22TAT using the formula/

hit:ratio N ):physical#logical+;;.The number of physical reads is provided directly in K2!22TAT. Logical reads are calculated from the sum of'consistent gets' and 'db bloc" gets'. &ndividual user session hit:ratios are calculated using the K2!22TAT view.The usual recommendation is that the hit:ratio should be above =7> for OLTP and above 97> for batchapplications. The interaction between the available physical memory and the wor"ing set si?e will have a non:lineareffect on the buffer cache hit:ratio. The effect that increasing the number of buffers will have on the cache hit:ratiocan be assessed by setting the &%&T.OFA parameter G(I(LOHJILF$I2TAT&2T&H2 to 'TF$!'. This will placestatistics in the JH(H( table which will show the hits that would have been achieved had more buffers beenavailable. Femember that this procedure should be used on a temporary and controlled basis due to the overheadwhich it places on the system. &f you are only able to loo" at one aspect of Oracle performance, the database buffercache hit:ratio should be your choice.

A word of caution is appropriate here. Femember that, when Oracle records a 'physical read' what it means is thatOracle has issued a data reuest to the operating system. This may or may not result in an actual &#O to dis",depending upon the $%& buffer cache hit:ratio. &t is possible, on certain environments, to use raw &#O to dis"s, inwhich case Oracle bypasses the $%& buffer cache. $sing raw &#O ma"es managing dis" space much more difficult,and many systems do not support it.3.2 Rollback The rollbac" segments are used for read:consistency )enabling Oracle to avoid the need for read loc"s+ rollbac" andrecovery. The "ey metric here is the rollbac" segment get hit:ratio which is calculated from data provided inKFOLL2TAT using the formula /:



get hit:ratio N ):waits#gets+;;.Any figure less than ==> for the get hit:ratio is indicative of rollbac" contention : possible causes are too fewrollbac" segments or rollbac" segments that are too small in proportion to the volume of updates.3.3 Redo Log Buffers The Fedo Log buffers are used to hold changed data prior to writing them to the on:line Fedo Logs. An update:intensive application can cause contention for access to the redo log buffer and this can be diagnosed by using datafrom the KLATH view. KLATH gives the number of gets, misses, immediate gets and immediate misses. &f theratio of misses to gets, or of immediate misses to immediate gets is greater than >, then the Fedo Log buffer si?eshould be increased. One can also monitor time spent waiting for Fedo Log space using K<A&T2TAT. This provides direct input to response time analysis.3.4 Shared Buffer Pool The 2hared (uffer Pool contains two vitally:important memory structures : the Library Hache and the GictionaryHache. A single &%&T.OFA parameter )2AF!GIPOOLI2&!+ controls the total si?e of the 2hared (uffer Poolincluding both the Library Hache and the Gictionary Hache. The main 1ob of the Library Hache is to hold shared26L statements that have been parsed. Hlearly a significant performance gain can be obtained if Oracle can re:use a26L statement that has already been parsed.The "ey metrics are available from the KL&(FAFMHAH! view/0 number of gets0 the Library Hache get hit:ratio0 number of P&%s

0 the P&% hit:ratio0 number of reloadsThe number of P&%2 represents executions of an item in the library cache. (oth the Library Hache get hit:ratio andthe P&% hit:ratio should be greater than =;>. The number of reloads gives the number of times that a cache entry ismissed due to the fact that it has been 'aged out' through lac" of space. The number of reloads should never be morethan > of the number of P&%s. &f it is, then the 2AF!GIPOOLI2&! parameter should be increased.The Gictionary Hache is used to hold definitions of dictionary ob1ects in memory. Gictionary Hache gets and missesare reported in the KFO<HAH! view. The hit:ratio )once the database has been loaded and used for a littlewhile+ should be better than =;>.3.5 Case Study As recommended above, one of the first metrics that we loo"ed at was the buffer cache hit:ratio, the table belowshows a sample from the pea" period );; : -4;+.Start Time Hit-ratio

11:00:02 99.211:15:02 98.6

11:30:01 97.3

11:45:02 96.9

12:00:00 97.3

12:15:01 95.8

12:30:01 97.5

This shows a very high hit:ratio, well in excess of the usual targets. <e also loo"ed at the individual session buffercache hit:ratios which, for the users which used the ma1ority of the resources, showed average cache hit:ratios inexcess of =9>. The other hit:ratios referred to earlier in this section were also chec"ed and found to be withinacceptable limits. Hlearly from an Oracle point of view, contention for 23A resources was not the source of the problem.<e had been informed that the live Oracle instance was the ma1or user of HP$ resources on the system. This wechec"ed by correlating the HP$ consumption reported by $%& with the HP$ consumption reported by Oracle.This is shown graphically in figure 4.The x:axis on this graph covers the period ;9;; : 4;;. The HP$ usage reported for the Oracle 'Live' instance is asignificant proportion of the total HP$ for the ma1ority of this period. %ote that pea" )O#2+ HP$ is over 9;> at themorning pea" time of ;;. HP$ utilisations at this level will cause significant HP$ ueuing with a conseuenteffect on response times.The next area which we loo"ed at was the way in which $%& memory resources were being used. The graph infigure 5 shows a correlation between the amount of free $%& memory and one of the "ey paging metrics : thenumber of physical page:outs per second.



This dramatic picture shows the effect of increasing main memory pressure. As the amount of free memory fallsduring the first half of the day, the pageout rate stays very low : until free memory becomes critical, at which point physical pageouts start to increase rapidly. As demand for $%& memory decreases later in the day the pageout rateonce again drops bac" to very low levels. This heavy &#O load, and the HP$ reuired to service it, will damageapplication response times during the critical pea" period.Oracle's 'rule:of:thumb' for $%& systems )and this should be used with caution since different application mixeswill have different reuirements+ is that the total 23A si?e for all instances should not be more than one third of thetotal physical memory. This is necessary to provide enough space for $%& to manage the whole environment.&n this case it was possible to reduce the 23A si?e, by reducing the number of database bloc" buffers, without anysignificant effect on database buffer cache hit:ratios. This, in turn, reduced the pressure on $%& memory resourcesand virtually eliminated the paging activity shown above.

.& *is" Storage

This section concentrates on the physical organisation of data and the ways in which contention can cause performance problems. The advice provided by Oracle on tablespace allocation should be followed closely. &t issummarised here for completenessQ each site should chec" that the Oracle recommendations for their platform have been followed.4.1 Tablespace Cof!gurat!o The tablespace is the largest logical unit of space in an Oracle database. All databases should have at least sixtablespaces as follows, although many more may be reuired in order to separate data of different types and withdifferent uses.0 2M2T!D0 F(20 T!DP0 $2!F20 xxxIGATA0 xxxI&%G!The 2M2T!D tablespace should contain only data dictionary ob1ects. A separate tablespace )F(2+ should beallocated for rollbac" segments. A temporary tablespace should be used for sorts etc. The $2!F2 tablespace is forthose )few+ users who need to create ob1ects.4.2 "atabase #!les Gata on file usage is obtained from the K&L!2TAT view. The primary ob1ective should be to spread the Oraclefiles across the available physical devices in order to distribute the &#O evenly, and to prevent any single device from

becoming a performance bottlenec". &n particular it is worth chec"ing for any heavy &#O activity to the 2M2T!Dtablespace files, which could cause significant response time problems. This &#O could be caused by the 2hared(uffer Pool being too small, or by data and#or sort segments being written to the 2M2T!D tablespace.Although it is possible to stripe files across physical dis"s by hand, many $%& implementations support stripingdirectly and this should be used if possible. The Oracle literature itself states that striping by hand is labour:intensiveand offers few advantages. Hhec", using the $%& commands sar or iostat )depending upon which $%&implementation you are using+ that striping is in effect and that dis" &#O load is evenly distributed.4.3 "atabase Blocks One of the goals of any tuning exercise is to minimise the number of database bloc"s which are read in order toretrieve the reuired data. This can be achieved in a number of ways/0 using a larger bloc" si?e0 pac"ing rows as closely as possible0 preventing row migration

0 tuning 26L statements&t may be possible to use a larger bloc" si?e. This will be constrained by the operating system implementation thatyou are using. %ote that the database will need to be re:built if you change the bloc" si?e )which is specified in the&%&T.OFA parameter G(I(LOHJI2&!+. (loc"s can be monitored using the A%ALM! command which populates the G(AITA(L! view.4.4 #rag$etat!o ad Cotet!o Gata fragmentation occurs in a number of different ways /:0 internal fragmentation : caused by deletions or updates within a bloc"0 external fragmentation : where a table is stored on multiple )non:contiguous+ extents



0 row migration : where an updated row will no longer fit in its original bloc", the entire row is 'migrated' to a new bloc" and pointed to from the original bloc"0 row chaining : where a row is too large to fit in a single bloc"All of these cause additional &#O in order to satisfy each logical reuest. The G(AITA(L!2 view can be used todetect this behaviour.Another possible cause for contention is freelist processing. At least one freelist is maintained in each segmentheader. Processes that are loo"ing for bloc"s to insert into, search the freelist. &n a busy system where there isconsiderable insert and delete activity, processes may contend for segment freelists. Any freelist waits are logged inK<A&T2TAT.4.5 Case Study An analysis of traffic by Oracle file for the application system, during the pea" period, provided the followingresults/File Name Reads Writes

o!ta"#$%&1.d"' 1436141 4316

o!id(#$%&3.d"' 713839 6361

o!id(#$%&1.d"' 197294 1155

o!ta"#$%&3.d"' 195373 1643

r"s#$%&1.d"' 158966 7200

o!ta"#$%&2.d"' 84086 249

s)s#$%&1.d"' 25470 1184

o!id(#$%&2.d"' 12488 278tools#$%&1.d"' 12383 5

This list is sorted on the total number of reads for each file and shows that &#O activity is concentrated on a smallnumber of files. Dore than half the total number of reads was to the file 'houtabL&K!.dbf'. A chec" on the physical&#O by $%& dis" revealed the following picture/*)si+al ,is tilisatio/

/03sd01" 14.6

/02sd001 10.2

/01sd01a 7.2

/02sd029 4.5

/03sd01a 4.3

/02sd03" 2.9

/02sd002 2.8

00sd006 2.7This table is sorted on the total utilisation of each device and does not show the even distribution of &#O that onewould normally expect on a striped filesystem. A chec" uic"ly revealed that none of the Oracle database files werestriped, which resulted in the uneual distribution shown above.

/& S0L and *ata,ase Na1igation

5.1 S%L Stadards As already mentioned in section 4.5 above, significant performance gains can be obtained by exploiting Oracle'sability to re:use parsed 26L statements. or 26L to be re:used it must be identical. This is much more li"ely to bethe case if all 26L code is written to an enforced set of standards, and bind variables are used instead of literals.5.2 Trac!g S%L The Oracle 26LITFAH! function can be used to analyse 26L statements. 26LITFAH! can be enabled for theentire instance )this is not practical due to the performance hit and volume of data that would be produced+ or for

specific sessions. The output is written to a trace file which must be processed using another Oracle utility :TJPFO. TJPFO produces resource consumption and performance details for each 26L statement and)optionally+ an !PLA&% PLA% which shows the way in which the optimiser will process the 26L and theoptimiser mode used. The 26L optimiser examines each 26L statement and chooses an optimal execution plan.Oracle E gives the choice of two optimisers : the old rule:based optimiser and the newer, more intelligent cost:basedoptimiser. The optimiser mode can be set at instance level, session level or statement level )using &%T2+.5.3 "atabase &a'!gat!o <hen reading rows from a short table, or when the ma1ority of rows are reuired from a long table, a table scan isusually the most efficient method. <hen only a few rows are reuired from a long table, it is usually more efficientto use an indexed read. Hlearly this is only possible when an index has been defined on the table using the reuired



"ey. The output from TJPFO and !PLA&% PLA% can be used to identify missing )or mis:used+ table indexes byshowing the number of rows scanned, number of rows retrieved, and the access method used.5.4 Case Study An analysis of the HP$ consumption of Oracle sessions for the pea" period gave/S$, Serial ra+le ser * se+o/ds

103 89 *SSW&ST01 2584.41

80 173 *SRN01 2583.93

53 579 *SSW&ST01 1224.62

34 487 *SSW&ST01 1215.47

39 33 *SSW&ST01 1179.52

32 137 *SSW&ST01 1129.08

107 385 *STS#01 938.11

109 297 H&R 912.87

98 81 *SN*S01 907.28

84 563 *S,R01 393.84

105 49 *S,R01 270.79

119 411 *S,NN01 263.55

This list is sorted on the total HP$ consumption of each session. %ote the predominance of user 2<!2T;. urtheranalysis showed significant numbers of long table scans for this user. 26LITFAH! was then enabled for all activesessions where user name was 2<!2T;, followed by TJPFO including the explain plan option. This showed

that, of the 5= 26L statements analysed, 1ust 5 )=>+ were responsible for =E> of the HP$ time. !ach one of these5 included a full table scan of the same table. !ach time ,9- rows were scanned and less than -; rows werereturned. A simple addition of an index to this table reduced total &#O by more than -;>.

2& Contention for Logical 3esources

(.1 Locks Oracle KE uses automatic row level loc"ing to maintain the consistency of the database when it is updated. Loc"sare only applied to database updates, and in the ma1ority of on:line systems loc"ing activity will probably affect onlya small number of users or transactions. A loc" is set by a process when it wishes to change a row in the database. &fa concurrent process also wishes to change the same row while the first process is implementing its update, then thesecond process has to ueue to obtain possession of the loc". Oracle does not enforce read loc"s, althoughapplications can loc" data if they wish. <here reuired, the rollbac" segments are used to provide read:consistency.The probability of loc" contention affecting performance depends on the locality of updates, which is a function of

the application design and the transaction mix at any time. Getails on loc"ing activity are provided by the KLOHJview although any loc" contention will only be reported in real time. The Oracle utlloc"t.sl script can be used to provide information on loc" 'waiters' and the loc" modes reuested and held.(.2 Latches A latch is an internal mechanism which is used by Oracle to ensure the consistency of shared data structures. !achma1or data structure is protected by one or more latches. Latches should only be held for very brief )micro:second+ periods. Any latch waits are indicative of very serious problems. A complete list of latches is provided inKLATH%AD!. KLATHOLG!F gives details of all processes holding latches and KLATH providesoverall latch summary statistics.

4& !odelling Oracle Systems

).1 The &eed for *odell!g Duch of the dynamic behaviour of an Oracle system is non:linear and cannot therefore be simply extrapolated. The

Oracle environment itself is sub1ect to the constraints placed upon it by its operating system environment. There arealso a number of significant feedbac" loops which will affect performance as identified in section - above.Analytical modelling, based on ueuing networ" theory, has been used for some time now to model the performanceof computer systems, including the non:linearities that contention for resources causesB-C. 2uch techniues haverecently been extended to encompass the behaviour of application environments built using FG(D2s such asOracleB4C. &t is impossible to characterise their behaviour without using a model : observations are meaninglessunless they can be interpreted, and related by reference to some conceptual framewor".The "ey contribution that using such a model ma"es is its ability to translate an end:user wor"load into the resources)both physical and logical+ that the wor"load will both use and contend for, and derive the response time that will be



provided. Once built and validated from actual baseline observations, the model can be used to explore theconseuences of changes in wor"load and#or hardware configuration.All analytical models represent service centres )resources which provide a service to the wor"load and#or maycontribute a delay+ and wor"loads. !ach wor"load is described by its reuirement for service at each of the servicecentres. !stablished modelling methods are adeuate to model contention for physical resources and the conseuenteffect on response times. Duch of the recent wor" B5C has been aimed at modelling contention for logical resourcessuch as loc"s and latches.A full explanation of the modelling techniues reuired to represent the behaviour of loc"ing mechanisms is outsidethe scope of this paper but, for example, a loc" can be considered as a service centre. Hlearly when a wor"load doesnot experience loc" contention, its delay time at the loc" service centre )to acuire the loc" that it needs+ is veryshort. &f it encounters a loc" it will wait until the loc" holder releases it.$sing a combination of the data available from $%&, and the data available from Oracle )primarily from the Kviews+ it is possible to construct uite detailed models of the behaviour of Oracle applications. One should alwaysremember however, that the model should only be sufficiently detailed to answer the specific planning uestions. Amodel is, by definition, a simplification of reality, built for a specific purpose.).2 Case Study $sing the data from $%& and from Oracle, we built a model of the system referred to earlier. The main decisionswhich had to be made were the choice of the modelling 'window' )the period of time whose wor"load the model isreuired to represent+ and the way in which the wor"load should be bro"en down into wor"load components.The modelling window chosen was the pea" morning hour, ;; : -;;. This was chosen on the basis of the overall

HP$ consumption and &#O rates reported for both the Oracle instance and from $%&. The primary uestion that themodelling exercise was to address was RHan the system cope with the expected increase in the number of concurrentOracle maintenance sessions and, if not, what actions are reuired to ma"e sure that it can*R The wor"load wastherefore bro"en down into components which represented/0 the Oracle maintenance sessions in the 'L&K!' instance0 the remainder of the wor" in the 'L&K!' instance0 the wor" from other Oracle instances0 the wor" generated by $%& itself in order to manage the environmentThe initial or 'baseline' model was calibrated against the observations of device utilisation and ueue lengths. &t wasnot possible to perform a response time calibration due to the absence of any meaningful response timemeasurements either from $%& or from Oracle. This does not invalidate the model that is produced. The modelwill define relative changes in response times, rather than absolute values, for the wor"load components which wereselected.

A pro1ection )or 'scenario'+ model was then built to show the way in which maintenance response times wouldchange as the overall loading increased. The non:linear effect referred to earlier is clearly seen in the response timescenario report shown below.The first vertical bar represents the current )baseline+ response time, and each subseuent bar represents the additionof five more concurrent maintenance sessions. A second scenario model was then built incorporating two changesfrom the model shown above/)a+ The HP$ was upgraded from an 9:way to a -:way at pro1ection point 7)b+ An index was added )to the table referred to in section 7.5 above+ at pro1ection point EThe effect on maintenance response times is shown in figure 8 below/The advantage of this approach is that a large number of alternative wor"load and configuration combinations can be assessed, from the point of view of their impact on end:user response times.Dany of the options that are available for changing Oracle and $%& configuration parameters are only effective atstartup time. The ability to assess the li"ely impact of those changes in advance saves both time and money, and is a

good deal safer than the experimental approach@

5& Summary Conclusions

The main message of this paper is that we should not allow ourselves to be put off by the apparent complexities ofOracle system behaviour. (y selecting and concentrating on a small number of "ey metrics, significant performanceimprovements can often be gained.The paper includes definitions of the sources of the important metrics. These are accessible through standard 26L or $%& commands. One of the main problems with the raw metrics is that they are often snapshots at a single instant: and the important thing for characterising system behaviour is not the absolute values, but the way in which thosevalues change over time.



2oftware tools are now available to assist in the process of capturing and storing this data. 2uch tools also speed upthe process of identifying patterns, trends and interrelationships between the observations.Dodelling techniues are available which will allow us to predict the future behaviour and performance of Oraclesystems. This will enable accurate forecasts to be made of the resource implications of changing wor"loads :enabling systems to be managed in a proactive, rather than a reactive way.

36F636NC6S

. A proof of the ueuing formula LNl<, S.H. Little, Operations Fesearch Kol. =, =8, pp. 494:49E.-. Performance Danagement of Hlient:server 2ystems, Adam 3rummitt, HD3 Proceedings, ==54. Hapacity Planning in Hlient#2erver 2ystems, T. oxon, D. 3arth and P. arrison, Sournal of Gistributed 2ystems!ngineering, Kol. 4, ==8, pp 4- :49.5. Hapacity Planning for Parallel &T 2ystems, D. 3arth, Homputer (ulletin, Kol 9, part 7, %ovember ==8, pp 8:9.

Documents

2730100 Oracle Performance With Unix