Performance Tuning for Oracle Database

oracle is a high-performance database software. Users can optimize the performance by adjusting the parameters. Performance optimization is mainly divided into two parts: one is that the database administrator achieves the purpose of optimization by adjusting the system parameters, and the other is that the developer achieves the purpose of adjusting by optimizing the application.

　　Here, only the adjustment of the system parameters is discussed, and the optimization of the application program is not involved. The adjustment of system parameters can be divided into the following parts:

　　(1) Adjustment of memory allocation The

　　system global area (SGA) is a memory segment allocated to ORACLE that contains control information of the ORACLE database instance. The size of SGA has a great impact on system performance, and its default parameter settings are only suitable for computers with very low configuration, and are not suitable for the needs of existing equipment in the income system. If these parameters are not adjusted, it will cause a huge waste of system resources. As far as the Alpha 1200 of the income system is concerned, the size of the SGA is about 160 megabytes.

　　Some parameters in the initialization parameter file have a decisive influence on the size of the SGA. The parameter DB-BLOCK-BUFFERS (the number of buffers in the storage area cache in the SGA) and the parameter SHARED-POOL-SIZE (the number of bytes allocated to the shared SQL area) are the main influencers of the size of the SGA.

　　The DB-BLOCK-BUFFERS parameter is the most important determinant of SGA size and database performance. A higher value can improve the hit rate of the system and reduce I/O. The size of each buffer is equal to the size of the parameter DB-BLOCK-SIZE. ORACLE database block size in bytes.

　　The shared pool part of the Oracle SGA area consists of the library cache, dictionary cache and some other user and server session information, and the shared pool is the largest consumption component. Adjusting the size of each structure in the SGA area can greatly improve the performance of the system.

　　.Adjust Library Cache

　　The library cache (Library Cache) contains private and shared SQL areas and PL/SQL areas. An important issue in adjusting SGA is to ensure that the library cache is large enough so that ORACLE can keep analyzing and executing statements in the shared pool, improve the efficiency of statement analysis and execution, and reduce resource consumption. Determine its size by comparing the hit rate of the Library Cache. Query V$LIBRARYCACHE data dictionary view (where pins represent cache hit rate, reloads represent cache failure)

　　SQL>SELECT SUM(pins), SUM(reloads) FROM v$librarycache;

　　if sum(reload)/sum(pins) ≈0, indicating that the hit rate of the Library Cache is appropriate. If it is greater than 1, the size of the shared pool (SHARED-POOL-SIZE) needs to be increased (in the initialization parameter file).

　　.Adjust the data dictionary cache (Dictionary Cache)

　　The data dictionary cache includes the structure, user, entity information about the database. The hit rate of the data dictionary has a great impact on the system. In the calculation of the hit rate, getmisses represents the number of failures, and gets represents the number of successes.

　　Query the V$ROWCACHE table:

　　SQL>SELECT (1-(SUM(getmisses)/(SUM(gets)+SUM(getmisses))))*100 FROM v$rowcache;

　　if the value is >90%, the hit rate is appropriate. Otherwise, the size of the shared pool should be increased.

　　.tune the database buffer cache

　　Oracle reads and writes data to the database cache during operation. A cache hit means that the information is already in memory, and a cache failure means that ORACLE must perform disk I/O. The key to keeping the cache failure rate to a minimum is to ensure the size of the cache. The initialization parameter DB-BLOCK-BUFFERS controls the size of the database buffer cache. You can query the V$SYSSTAT hit rate to determine whether you should increase the value of DB-BLOCK-BUFFERS.

　　SQL>SELECT name,value FROM V$SYSSTAT WHERE name IN ('dbblock gets','consistent gets','physical reads');

　　by query result

　　Hit rate=1-physical reads/(dbblock gets+consistent gets)

　　if hit If the ratio is less than 0.6 to 0.7, DB-BLOCK-BUFFERS should be increased.


　　(2) Adjusting Disk I/O

　　Disk I/O is the bottleneck of system performance. Solving the disk I/O can significantly improve performance. By querying V$FILESTAT, you can know the usage frequency of each physical file (phyrds represents the number of reads of each data file, and phywrts represents the number of writes of each data file)

　　SQL>SELECT name,phyrds,phywrts FROM v$datafile df,v $filestat fs WHERE df.file# =fs.file#;

　　For frequently used physical files, the following strategies can be used:

　　. Distribute I/O on as many disks as possible as evenly as possible.

　　. Create separate tablespaces for tables and indexes.

　　.

　　.Reduce disk I/O without oracle SERVER.


　　(3) Adjust the competition

　　When multiple processes apply for the same resource, competition occurs.

　　.Modify the process parameter

　　This parameter defines the maximum number of processes that can connect to the Oracle database at the same time. The default value is 50. Note that the background process of oracle is also included in this number, it is recommended to change the value to 200. 　　.Reduce the competition of the scheduling process To reduce

　　the competition of the scheduling process, determine the competition of the scheduling process by querying the v$dispatcher table 　　SQL>SELECT network ,sum(busy)/sum(busy)+sum(idle) FROM v$dispatcher GROUP BY network ; 　　If the busy ratio of a certain protocol exceeds 50%, the value of MTS-DISPATCHERS should be increased. 　　.Reduce competition between multi-threaded service processes 　　First query the V$SYSSTAT table to determine whether multi-threaded service process competition occurs: 　　SQL>SELECT DECODE(totalq,0,'No request',wait/totalq||'hunderths of seconds') FROM v$ sysstat WHERE type='common'; 　　If the number of shared service processes has reached the maximum value specified by MTS-MAX-SERVERS in the initialization parameter file, but the average request waiting time continues to increase when the application is running, then MTS-MAX should be increased. - The value of SERVERS. 　　.Reduce redo log buffer contention Determine whether the redo log file buffer is sufficient 　　by querying the V$SYSSTAT table.



















　　SQL>SELECT name,value FROM v$sysstat WHERE name='redo log space request';

　　the value of value here should be close to 0, otherwise, the value of LOG-BUFFEQS of the initialization parameter file should be increased.

　　.Reduce competition for

　　rollback The rollback segment also has an impact on performance, and the appropriate rollback segment is allocated according to the size of the transaction.

　　First determine whether the number of rollback segments can meet the needs of system operation:

　　query V$WAITSTAT table and V$SYSSTAT table


　　SQL>SELECT class,count FROM v$waitstat WHERE class IN ('system undo header','system undo block' ,'undo header','undo block');

　　SQL>SELECT sum(value) FROM v$sysstat WHERE name IN ('db block gets','consistent gets');

　　if any class/sum(value)>10 %, then consider adding a rollback segment. The number of rollback segments is generally set as follows:

　　Number of users Number of

　　rollback segments
　　n<16

　　4

　　16<n<32

　　8

　　32<=n

　　n/4 but not more than 50

　　.

　　Free List competition occurs when multiple processes insert data into a table at the same time.

　　SQL>SELECT class,count FROM v$waitstat WHERE class='free list';

　　SQL>SELECT sum(value) FROM v$sysstat WHERE name IN ('db block gets','consistent gets');

　　If class/sum( value)>1%, the value of the Free List of the table should be increased.