1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
|
<HTML>
<HEAD>
<TITLE></TITLE>
<LINK REL="ToC" HREF="httoc.htm">
<LINK REL="Index" HREF="htindex.htm">
<LINK REL="Next" HREF="aguide09.htm">
<LINK REL="Previous" HREF="aguide07.htm"></HEAD>
<BODY BGCOLOR="#FFFFFF">
<P ALIGN=CENTER>
<A HREF="aguide07.htm" TARGET="_self"><IMG SRC="gaguide/graprev.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Previous Page"></A>
<A HREF="httoc.htm" TARGET="_self"><IMG SRC="gaguide/gratop.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="TOC"></A>
<A HREF="htindex.htm" TARGET="_self"><IMG SRC="gaguide/graindex.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Index"></A>
<A HREF="aguide09.htm" TARGET="_self"><IMG SRC="gaguide/granext.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Next Page"></A>
<A NAME="E9E8"></A>
<H1>
<FONT FACE="Arial"><B>PERFORMANCE TUNING</B></FONT></H1>
<BR>
<BLOCKQUOTE>
<P>This chapter discusses techniques that you can use to improve the performance of SOLID <I>Server</I>.
</BLOCKQUOTE>
<A NAME="E10E40"></A>
<P>
<FONT FACE="Arial"><B>Tuning SQL Statements and Applications</B><A NAME="I2"></A><A NAME="I3"></A></FONT>
<BLOCKQUOTE>
<P>Tuning the SQL statements, especially in applications where complex queries are involved, is generally the most efficient means of improving the database performance.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>You should tune your application before tuning the RDBMS because:
</BLOCKQUOTE>
<UL>
<BLOCKQUOTE>
<LI>during application design you have control over the SQL statements and data to be processed
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>you can improve performance even if you are not familiar with the internal working of the RDBMS you are going to use
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>if your application is not tuned well, it will not run well even on a well-tuned RDBMS
</BLOCKQUOTE></UL>
<BLOCKQUOTE>
<P>So, find out what data your application processes, what are the SQL statements used and what operations the application performs on the data.
</BLOCKQUOTE>
<P>
<FONT FACE="Arial"><A NAME="I4"></A><A NAME="I5"></A><A NAME="I6"></A><A NAME="I7"></A><A NAME="I8"></A><A NAME="I9"></A><A NAME="I10"></A><A NAME="I11"></A><A NAME="I12"></A><A NAME="I13"></A><A NAME="I14"></A><A NAME="I15"></A><A NAME="I16"></A><A NAME="I17"></A><A NAME="I18"></A><A NAME="I19"></A><A NAME="I20"></A><A NAME="I21"></A><A NAME="I22"></A><A NAME="I23"></A>Using SOLID Server Diagnostic Tools</FONT>
<BLOCKQUOTE>
<P>SOLID <I>Server</I> provides the following tools that may be helpful in tuning applications:
</BLOCKQUOTE>
<UL>
<BLOCKQUOTE>
<LI>the SQL info facility
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>the EXPLAIN PLAN statement
</BLOCKQUOTE></UL>
<BLOCKQUOTE>
<P>For additional information on how to use these tools, refer to chapter <I>SOLID </I><I>Server Diagnostic Tools</I>.
</BLOCKQUOTE>
<P>
<FONT FACE="Arial"><A NAME="I24"></A><A NAME="I25"></A><A NAME="I26"></A><A NAME="I27"></A><A NAME="I28"></A><A NAME="I29"></A><A NAME="I30"></A><A NAME="I31"></A><A NAME="I32"></A><A NAME="I33"></A><A NAME="I34"></A><A NAME="I35"></A><A NAME="I36"></A><A NAME="I37"></A><A NAME="I38"></A><A NAME="I39"></A><A NAME="I40"></A><A NAME="I41"></A>Indexes<A NAME="I42"></A><A NAME="I43"></A></FONT>
<BLOCKQUOTE>
<P>Indexes can be used to improve the performance of queries. A query that references an indexed column in its WHERE clause can use the index. If the query selects only the indexed column, the query can read the indexed column value directly from the index, rather than from the table.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>If a table has a primary key, SOLID <I>Server</I> orders the rows on disk in the order of the values of the primary key. Otherwise the rows are ordered using the ROWID, i.e. the rows are stored on disk in the order they are inserted into the database.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Indexes improve the performance of queries that select a small percentage of rows from a table. You should consider using indexes for queries that select less than 15% of table rows.
</BLOCKQUOTE>
<P>Full table scan
<BLOCKQUOTE>
<P>If a query does not use an index, SOLID <I>Server</I> must perform a full table scan to execute the query. This involves reading all rows of a table sequentially. Each row is examined to determine whether it meets the criteria of the query’s WHERE clause. Finding a single row with an indexed query can be substantially faster than finding the row with a full table scan. On the other hand, a query that selects more than 15% of a table’s rows may be performed faster by a full table scan than by an indexed query.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>To perform a full table scan, every block in the table is read. For each block every row stored in the block is read. To perform an indexed query the rows are read in the order in which they appear in the index, regardless of which blocks contain them. If a block contains more than one selected row it may be read more than once. So, there are cases when a full table scan requires less I/O than an indexed query.
</BLOCKQUOTE>
<P>Concatenated indexes<A NAME="I44"></A><A NAME="I45"></A>
<BLOCKQUOTE>
<P>An index can be made up of more than one column. Such an index is called a concatenated index. It is recommended to use concatenated indexes when possible.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Whether or not a SQL statement uses a concatenated index is determined by the columns contained in the WHERE clause of the SQL statement. A query can use a concatenated index if it references a leading portion of the index in the WHERE clause. A leading portion of an index refers to the first column or columns specified in the CREATE INDEX statement.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Example:
</BLOCKQUOTE>
<BLOCKQUOTE>
<PRE>create index job_sal_deptno on emp(job, sal, deptno);</PRE></BLOCKQUOTE>
<BLOCKQUOTE>
<P>This index can be used by these queries:
</BLOCKQUOTE>
<BLOCKQUOTE>
<PRE>select * from emp where job = ‘clerk’ and sal = 800 and deptno = 20;
<BR>select * from emp where sal = 1250 and job = salesman;
<BR>select job, sal from emp where job = ‘manager’ ;</PRE></BLOCKQUOTE>
<BLOCKQUOTE>
<P>The following query does not contain the first column of the index in its WHERE clause and cannot use the index:
</BLOCKQUOTE>
<BLOCKQUOTE>
<PRE>select * from emp where sal = 6000;</PRE></BLOCKQUOTE>
<P>Choosing columns to index
<BLOCKQUOTE>
<P>The following list gives guidelines choosing columns to index:
</BLOCKQUOTE>
<UL>
<BLOCKQUOTE>
<LI>index columns that are used frequently in WHERE clauses
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>index columns that are used frequently to join tables
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>index columns that are used frequently in ORDER BY clauses
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>index columns that have few of the same values or unique values in the table.
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>do not index small tables (tables that use only a few blocks) because a full table scan may be faster than an indexed query
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>if possible choose a primary key that orders the rows in the most appropriate order
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>if only one column of the concatenated index is used frequently in WHERE clauses, place that column first in the CREATE INDEX statement
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>if more than one column in concatenated index is used frequently in WHERE clauses, place the most selective column first in the CREATE INDEX statement
</BLOCKQUOTE></UL>
<A NAME="E10E41"></A>
<P>
<FONT FACE="Arial"><B>Tuning Memory Allocation</B><A NAME="I46"></A></FONT>
<P>
<FONT FACE="Arial"><A NAME="I47"></A><A NAME="I48"></A><A NAME="I49"></A><A NAME="I50"></A><A NAME="I51"></A><A NAME="I52"></A><A NAME="I53"></A><A NAME="I54"></A><A NAME="I55"></A><A NAME="I56"></A><A NAME="I57"></A><A NAME="I58"></A><A NAME="I59"></A><A NAME="I60"></A><A NAME="I61"></A><A NAME="I62"></A><A NAME="I63"></A>Tuning Your Operating System</FONT>
<BLOCKQUOTE>
<P>Your operating system may store information in
</BLOCKQUOTE>
<UL>
<BLOCKQUOTE>
<LI>real memory
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>virtual memory
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>expanded storage
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>disk
</BLOCKQUOTE></UL>
<BLOCKQUOTE>
<P>Your operating system may also move information from one location to another. Depending on your operating system, this movement is called paging or swapping. Many operating systems page and swap to accommodate large amounts of information that do not fit into real memory. However, this takes time. Excessive paging or swapping can reduce the performance of your operating system and indicates that your system’s total memory may not be large enough to hold everything for which you have allocated memory. You should either increase the amount of total memory or decrease the amount of database cache memory allocated.
</BLOCKQUOTE>
<P>
<FONT FACE="Arial"><A NAME="I64"></A><A NAME="I65"></A><A NAME="I66"></A><A NAME="I67"></A><A NAME="I68"></A><A NAME="I69"></A><A NAME="I70"></A><A NAME="I71"></A><A NAME="I72"></A><A NAME="I73"></A><A NAME="I74"></A><A NAME="I75"></A><A NAME="I76"></A><A NAME="I77"></A><A NAME="I78"></A><A NAME="I79"></A><A NAME="I80"></A>Database Cache<A NAME="I81"></A></FONT>
<BLOCKQUOTE>
<P>The information used by SOLID <I>Server</I> is stored either in memory or on disk. Since memory access is faster than disk access, it is desirable for data requests to be satisfied by access to memory rather than access to disk.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>The basic element of the database server memory management system is a pool of central memory buffers of equal size. The size of the memory buffers and their amount can be configured to meet the demands of different application environments.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Database cache uses available memory to store information that is read from the hard disk. When an application next time requests this information, the data is read from memory instead of from the hard disk. The default value of cache depends on the platform used and can be changed by changing the CacheSize parameter. Increasing the value is recommended when there are several concurrent users.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>The following values can be used as a starting point:
</BLOCKQUOTE>
<UL>
<BLOCKQUOTE>
<LI>a dedicated server with 16 MB RAM: Cachesize 4 MB
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>a dedicated server with 32 MB RAM: Cachesize 10 MB
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>a dedicated server with 64 MB RAM: Cachesize 30 MB
</BLOCKQUOTE></UL>
<BLOCKQUOTE>
<HR ALIGN=CENTER>
<P>NOTE. You should increase the value of Cachesize very carefully. Too large a value leads to very poor performance.
<HR ALIGN=CENTER>
</BLOCKQUOTE>
<A NAME="E10E42"></A>
<P>
<FONT FACE="Arial"><B>Tuning I/O</B></FONT>
<BLOCKQUOTE>
<P>The performance of many software systems is inherently limited by disk I/O. Often CPU activity must be suspended while I/O activity completes.
</BLOCKQUOTE>
<BLOCKQUOTE>
<H4>
<FONT FACE="Arial"><B>Distributing I/O</B></FONT></H4>
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Disk contention occurs when multiple processes try to access the same disk simultaneously. To avoid this, move files from heavily accessed disks to less active disks until they all have roughly the same amount of I/O.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Follow these guidelines:
</BLOCKQUOTE>
<UL>
<BLOCKQUOTE>
<LI>use a separate disk for log files
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>divide your database into several files and place each of these database files on a separate disk
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>consider using a separate disk for the external sorter
</BLOCKQUOTE></UL>
<A NAME="E10E43"></A>
<P>
<FONT FACE="Arial"><B>Sorting</B><A NAME="I82"></A><A NAME="I83"></A></FONT>
<BLOCKQUOTE>
<P>SOLID <I>Server</I> does all sorting by default in memory. The amount of memory used for sorting is determined by the parameter SORTARRAYSIZE in the [SQL] section. If the amount of data to be sorted does not fit into the allocated memory, you may want to increase the value of the parameter SORTARRAYSIZE. If there is not enough memory to increase the value of SORTARRAYSIZE you should activate external sort that stores intermediate information to disk.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>The external disk sort is activated by adding the following section and parameters in the configuration file solid.ini:
</BLOCKQUOTE>
<BLOCKQUOTE>
<PRE>[sorter]
<BR>TmpDir_1 = c:\tmp</PRE></BLOCKQUOTE>
<BLOCKQUOTE>
<P>Additional sort directories are added with similar definitions:
</BLOCKQUOTE>
<BLOCKQUOTE>
<PRE>[sorter]
<BR>TmpDir_1 = c:\tmp
<BR>TmpDir_2 = d:\tmp
<BR>TmpDir_3 = e:\tmp</PRE></BLOCKQUOTE>
<A NAME="E10E44"></A>
<P>
<FONT FACE="Arial"><B>Tuning Checkpoints</B></FONT>
<BLOCKQUOTE>
<P>Checkpoints affect:
</BLOCKQUOTE>
<UL>
<BLOCKQUOTE>
<LI>recovery time performance
</BLOCKQUOTE>
<BLOCKQUOTE>
<LI>runtime performance
</BLOCKQUOTE></UL>
<BLOCKQUOTE>
<P>Frequent checkpoints can reduce the recovery time in the event of a system failure. If the checkpoint interval is small, then relatively few changes to the database are made between checkpoints and relatively few changes must be recovered.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P>Checkpoints cause SOLID <I>Server</I> to perform I/O, so they momentarily reduce the runtime performance. This overhead is usually small.
</BLOCKQUOTE>
<BLOCKQUOTE>
<P><A NAME="I84"></A><A NAME="I85"></A><A NAME="I86"></A><A NAME="I87"></A><A NAME="I88"></A><A NAME="I89"></A><A NAME="I90"></A><A NAME="I91"></A><A NAME="I92"></A><A NAME="I93"></A><A NAME="I94"></A><A NAME="I95"></A><A NAME="I96"></A><A NAME="I97"></A><A NAME="I98"></A><A NAME="I99"></A><A NAME="I100"></A><A NAME="I101"></A><A NAME="I102"></A>
</BLOCKQUOTE><P ALIGN=CENTER>
<A HREF="aguide07.htm" TARGET="_self"><IMG SRC="gaguide/graprev.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Previous Page"></A>
<A HREF="httoc.htm" TARGET="_self"><IMG SRC="gaguide/gratop.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="TOC"></A>
<A HREF="htindex.htm" TARGET="_self"><IMG SRC="gaguide/graindex.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Index"></A>
<A HREF="aguide09.htm" TARGET="_self"><IMG SRC="gaguide/granext.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Next Page"></A>
<center><p><font SIZE=-2>Copyright © 1992-1997 Solid Information Technology Ltd All rights reserved.</font></p></center>
</BODY></HTML>
|
