In general, transaction-oriented applications (such as multiuser systems used for data entry)
judge performance by the time it takes to return the first row of a query. For transaction-oriented
applications, you should focus your tuning efforts on using indexes to reduce the database??™s
response time to the query.
If the application is batch oriented (with large transactions and reports), you should focus on
improving the time it takes to complete the overall transaction instead of the time it takes to return
the first row from the transaction. Improving the overall throughput of the transaction may require
using full table scans in place of index accesses??”and may improve the overall performance of
the application.
If the application is distributed across multiple databases, focus on reducing the number of
times database links are used in queries. If a remote database is frequently accessed during a
query, the cost of accessing that remote database is paid each time the remote data is accessed.
Even if the cost of accessing the remote data is low, accessing it thousands of times will eventually
place a performance burden on your application. See the section ???Reducing Network Traffic???
later in this chapter for additional tuning suggestions for distributed databases.
Tuning Memory Usage
As of Oracle 10g, you can use the Automatic Workload Repository (AWR) toolset to gather and
manage statistical data (as described later in this chapter).
Pages:
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425