Let??™s take a simple example. Select the current time from DUAL. If you select down to the
second level, the value will change 86,400 times per day. Yet there are application designers who
repeatedly perform this query, executing it millions of times per day. Such a query likely performs
few physical reads throughout the day. Therefore, if you are focused solely on tuning the physical
I/O, you would likely disregard it. However, it can significantly impact the performance of the
application. How? By using the CPU resources available. Each execution of the query will force
Oracle to perform work, using processing power to find and return the correct data. As more and
more users execute the command repeatedly, you may find that the number of logical reads used
by the query exceeds all other queries. In some cases, multiple processors on the server are
dedicated to servicing repeated small queries of this sort. If multiple users need to read the
same data, you should store it in a table or in a package variable.
NOTE
As of Oracle Database 10g, the DUAL table is an internal table, not a
physical table, and therefore does not generate consistent gets as long
as you don??™t use * as the column list in a query referencing DUAL.
Consider the following real-world example. A programmer wanted to implement a pause
in a program, forcing it to wait 30 seconds between two steps. Because the performance of
the environment would not be consistent over time, the programmer coded the routine in the
following format (shown in pseudocode):
perform Step 1
select SysDate from DUAL into a StartTime variable
begin loop
select SysDate from DUAL in a CurrentTime variable;
Compare CurrentTime with the StartTime variable value.
Pages:
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