Capacity Planning With Oracle

5/20/2018 Capacity Planning With Oracle

1/9

Capacity Planning with Oracle

Capacity Planning with OracleCapacity Planning with Oracle

Capacity planning involves two main subject areas, current storage space usage and potential growth.Both current storage and potential growth of a database can be assessed using the same basic tools.

What are those basic tools?

Simple tools for capacity planning can best be explained by starting with the following uestion. !ow dowe accurately assess the current physical si"e of an #racle database? $here are various methods. Somemethods are highly accurate but accuracy will hurt performance. #ther methods are extremely fast butunder some circumstances can be so inaccurate so as to be rendered useless. So how do we assess thecurrent physical si"e of an #racle database? $he various methods are listed below.

Datafile sizes. %et datafile si"es of all data containing datafiles from the operating system. $his

method could be the most inaccurate of all.

Datafile content sizes. $his method reuires a join on the &B'(&'$'()*+S and

&B'()-(S'C performance views. $his method accumulates values based on what #racle

calls xtents. xtents are the physical chun/s that an #racle datafile is increased by when morespace is reuired. $his method is totally inappropriate for an #racle database with poor physicalstorage organi"ation, particularly the storage parameter C$*0C-'S. 1ost commercial #racledatabases are not properly structured in this respect. $his method is more accurate than retrieval ofdatafile si"es from the operating system but can result in very unreliable results.

DBMS_SPACE. $his #racle provided pac/age is utili"ed to sum up space used and space free at the

bloc/ level, by database object name. $his method adds space used at the bloc/ level. $his methodis more accurate than both of the datafile methods already listed above. !owever, if many bloc/shave are partially filled or bloc/ usage parameters are left at #racle installation default values,inaccuracy could be as much as 234 incorrect, smaller or larger. )or a small database this is not anissue but a small database does not really need capacity planning.

Statistics. *nternal #racle optimi"ation statistics can be generated with either a minimal or fairlyheavy performance impact5 the heavier the performance impact the better the uality of the statistics.

'lso generation of si"ing statistics for indexes reuires an extra burden on performance. 6se ofstatistics is probably the all7round most effective method for capacity planning. !owever, some olderversions of #racle databases and applications will use rule7based rather than cost7basedoptimi"ation. $he simple existence of statistics can cause performance problems for rule7based tunedapplications. !owever, the #$*1*8-(1#& parameter can resolve these issues on a databaselevel. *f multiple applications use the same database and these applications used a mix of rule7basedand cost7based applications then rule7based applications could have performance problems.

Exact column ata lengths. 'll column lengths in all rows in all tables in a database can be counted

using length functions for string fields plus fixed /nown lengths for all other basic data types. #bjectdata types could be an issue using this method. $his method would be the most accurate for a purelyrelational database 9no object data types at all:. $his method will also affect performance in theextreme.

Oracle Enterprise Manager Capacity Planner Pac!age. $he Capacity lanner pac/age in #racle

nterprise 1anager does a lot of the wor/ for you. *t also provides lots of very nice graphicalrepresentation, automated warnings and bells and whistles. Be warned though; $his pac/age as with#racle nterprise 1anager in general has had many problems in the past. !owever, the word on thestreet is that #racle nterprise 1anager as released with #racle


2/9


0ow lets go through each of the above listed methods for capacity assessment and planning in detail.

Datafile SizesDatafile Sizes

#n Solaris this would reuire the use of the df kcommand and on 0$@=333 either the dircommand anda erl script or just a erl script using a erl contained pac/age allowing dis/ reads from within erl. $hescript shown in )igure > could be used to validate the existence of an acceptable level of dis/ spaceavailable on a Solaris box. $his script will indicate when dis/ space is reaching critical levels. Somesimple adjustments to this script could be made to chec/ current dis/ space results in the filedis/space.log, with previous executions of the script stored in older log files5 thus estimating growth rateover a period of time.

Figure 1: A partial script for extracting available disk spaceDatafile Content SizesDatafile Content Sizes

$he uery shown in )igure = is a partial script showing a join between the #racle performance views&B'(&'$'()*+S and &B'()-(S'C. 0ote that this script will not amalgamate datafiles intotablespaces but will show space used for each datafile 9temporary datafiles excluded:. ffectively thisuery will assess database si"e in terms of datafile extents. Whenever an autoextensible datafile runs outof space a new extent is automatically allocated to that datafile. )or a non7autoextensible datafile newextents have to be added manually by resi"ing the datafile using the '+$- &'$'B'S command. $he&B'(&'$'()*+S column BA$S shows the total si"e of a datafile in bytes. $he &B'()-(S'Ccolumn BA$S shows the BA$ si"e of all free extents in a datafile within a tablespace.

$he consistency of extent si"es is largely dependant on settings for the storage parameterC$*0C-'S, for tablespaces and database objects such as tables and indexes. $he important pointto note about the uery in )igure = is that the result of byte values in the &B'()-(S'C view can bevery inaccurate if C$*0C-'S is set anywhere in the database at greater than 34. Why? ' staticdatabase, which has never grown in si"e, would not be affected by C$*0C-'S if C$*0C-'Shas never been applied by the creation of a new extent. $his is probably very unli/ely. *f many newextents are added to a datafile it is uite possible that a new extent added could be much larger thanexpected. $he other issue with setting C$*0C-'S greater than 34 is that empty extents, as a resultof deletions, will not be reused since new extents, created larger than old extents, will not be able to reuse

= of 710 $poner in AarcharD* as

c8rsor cblocks QI2F0;total>b)tes QI2F0;8n8sed>blocks QI2F0;8n8sed>b)tes QI2F0;laste:tf QI2F0;laste:tb QI2F0;last8sedblock QI2F0;8sed>blocks integer defa8lt ;free>blocks integer defa8lt ;

beginfor obUs in cspace.8n8sed>space$poner4obUs.name4obUs.t)pe4total>blocks

4total>b)tes48n8sed>blocks48n8sed>b)tes4laste:tf4laste:tb4last8sedblock*;8sed>blocks V= 8sed>blocks L total>blocks;free>blocks V= free>blocks L 8n8sed>blocks;

end loop;dbms>o8tp8t.p8t>line$Ised = ||to>char$8sed>blocks*||4 (ree = ||to>char$free>blocks**;

e:ception hen others thendbms>o8tp8t.p8t>line$test ||s@lerrm$s@lcode**;

end;/e:ec m)>dbms>space;


5/9


"he A#A$%&E comman. Can be used to collect non7optimi"er statistics and will be deprecated in a

future version of #racle.

"he DBMS_S"A"S Oracle pro'ie pac!age. Collects optimi"er statistics and can be executed in

parallel on a multiple C6 system for better performance.

"he A#A$%&E Comman

$he command shown below will create non7optimi"er statistics for all rows in a specified table.

1Q1NW0 table nameE1E.M1E?0>E1F0>E1E$XownerY4 Xtable nameY*;

0T0 3F2>E1E.M1E?0>RQ30T>E1E$XownerY4 Xindex nameY*;

,!%S$STATS is faster at generating statistics then the ANA"()E cmmand.

(sing Statistics for Capacity Planning

Calculating the number of bloc/s or byte si"e for a table using statistics is simple. 'fter statistics havebeen generated uery the 6S-($'B+S #racle performance view with the uery as shown below.

00E E1F0>Q1204 QI2>


6/9


So now we /now how to utili"e statistics to find the si"e of all your data. #ther objects that could beanaly"ed and summed up would be objects such as indexes and clusters. Since clusters are rarely usedwe will ignore them. *ndexes on the other hand are generally more numerous in number than tables. *t isoften found that the total byte si"e of all indexes in a schema can be larger than that of all tables. Wecould estimate the si"e of indexes based on an assumed table to index ratio but that would be inaccurate.

$he *0&G(S$'$S #racle performance view is the only view that can be used to calculate an exact si"efor an index. %eneration of data into the *0&G(S$'$S view reuires used of the '0'+A8 *0&G indexname H'+*&'$ S$-6C$6-5 command. $his command can cause problems and it will containstatistics for only a single index at a time.

' simple method of assessing index si"e is to use index statistics generated by the '0'+A8 *0&Gcommand or the &B1S(S$'$S.%'$!-(*0&G(S$'$S procedure5 the 6S-(*0&GS view willcontain the resulting statistics. $he uery shown below will retrieve a good estimate of si"e for an index.

00E RQ30T>Q120401(>Fblock>siBe/F00 1 FNE0(RQ30T0;

's with the 6S-($'B+S view, obtain the total si"e of all indexes in a schema by executing a uery li/ethis one.

00E I2$01(>Fblock>siBe/F00* 1 FNE04I2$01(>Fblock>siBe/F00*/&DJ/&DJ 1 2F

(RQ30T0;

&ividing the number of leaf bloc/s in an index by its branch level value is a bit of a guess as far asassessing si"e. )or very large indexes it would be sensible to validate this by executing the '0'+A8*0&G index nameH'+*&'$ S$-6C$6-5 command for that particular index and then executing theuery shown below to get a better perspective on the actual si"e of that index.

00E Q1204F>FZL(>FZ4I03>710 1 FNE0 (E1E;

)our ueries are shown below in succession. ach uery progressively produces a summary of current

database storage capacity for objects within a schema. 'll of the four ueries list byte, megabyte andgigabyte si"es.

$he first uery lists si"es for all tables in a schema.

00E E1F0>Q1204F


7/9


00E t.E1F0>Q1204$t.FF


8/9


types of environments usually expect unimaginable growth. Sometimes these companies are correct.'dmittedly not very often but it does happen. *n a situation li/e this a method such as this would apply.

*n describing this approach to capacity planning it is best to /eep things simple. $hus we will stic/ tosimple datatypes5 thus no binary objects or other such nasty, unpredictable things. *f non7simpledatatypes have to be included then they have to be included, and factored into the calculations.

$he simple data types in an #racle database and their respective lengths are as follows. 0ote that somedatatypes ma/e things simple for use because their actual physical lengths are fixed. 'lso somedatatypes are automatically converted to more general datatypes when applied to columns in tables. 0otvery efficient use of space but that is something inventedby relational database vendors such as #raclemany years ago.

$his method may seem complicated but is actually very simple. $he only variable length simple datatypesin #racle are the H'-C!'-= datatypes. $hus H'-C!'-= datatypes are the only columns reuiringapplication of the +0%$! function to the column to find the length of the data in the column. 'll otherdatatypes will have fixed lengths.

*f you want you can execute the scripts following in a tool such as S+Jlus Wor/sheet and you will seewhat * mean. Create the table shown below and insert a single row as shown. $his table is deliberately

created with a very large mix of simple datatypes.

01E0 E1F0 1E1F0$rn8m RQE0M04Ac& 1?1D$J* 30(1IE &DCJ5P\94AcD 1?1D$J* 30(1IE &D4c& ?1$D* 30(1IE ab4cD ?1$&* 30(1IE abc4n& QI2F0 30(1IE &4nD QI2F0$&* 30(1IE &&4nC QI2F0$&D4J* 30(1IE &C.&DCJ4f& (


9/9


null values not being stored in indexes in some cases. !owever, most modern databases use object front7end applications. $hese types of applications tend to avoid use of composite /eys for anything but many7to7many join resolution entities5 these entities usually contain integers in their /ey values which are nevernull.

$

Figure : !uer.ing t0e )'%A#%&L)$* vie4

$hats it;

Disclaimer Notice: This information is available !" #"$% # am in no way responsible or liable for any mishaps as a res&lt of &sing thisinformation%

< of

Documents

Capacity Planning With Oracle