I have recently studied how to solve the IO competition problem if the storage level cannot be optimized. Finally, I thought of asynchronous IO.
My redo disk write speed has reached the maximum value, no matter how I adjust the redo size and number of groups, no matter how I adjust the checkpoint frequency is useless. Adjust the redo size and then reduce the redo switching frequency. Increase the number of redo groups only to prevent all redo operations from being used, but the business still needs new logs to record data changes. However, if I/O is not powerful, a bunch of redo operations are still insufficient. Maybe asynchronous I/O is your last trick. Let's try it.
The customer's database IO load is heavy. After checking, it is found that no asynchronous IO is set.
The load of the entire database is concentrated on IO-related WAITS:
Top 5 Timed Foreground Events
Event |
Waits |
Time (s) |
Avg wait (MS) |
% DB time |
Wait Class |
Log file sync |
697,116 |
70,128 |
101 |
36.29 |
Commit |
Db file sequential read |
2,982,135 |
54,498 |
18 |
28.20 |
User I/O |
Db file scattered read |
754,680 |
38,741 |
51 |
20.05 |
User I/O |
Free buffer waits |
35,410 |
20,560 |
581 |
10.64 |
Configuration |
DB CPU |
|
6,172 |
|
3.19 |
|
After checking, it is found that the current system does not use Asynchronous io:
[Oracle @ localhost ~] $ Cat/proc/slabinfo | grep kio
Kioctx 37 140 384 10 1: tunables 54 27 8: slabdata 14 14 0
Kiocb 0 0 256 15 1: tunables 120 60 8: slabdata 0 0 0
The first two items corresponding to kiocp in the returned results are 0, indicating that asynchronous io is not used in the system.
Check the packages that show that oracle has connected to aio:
[Oracle @ localhost ~] $/Usr/bin/ldd $ ORACLE_HOME/bin/oracle | grep libaio
Libaio. so.1 =>/lib64/libaio. so.1 (0x0000003e13000000)
Check in the database and find that the filesystemio_options settings are incorrect:
SQL> show parameter disk_asynch_io
NAME TYPE VALUE
----------------------------------------------------------------------------------------
Disk_asynch_io boolean TRUE
SQL> show parameter filesystemio_options
NAME TYPE VALUE
---------------------------------------------------------------------------------------
Filesystemio_options string none
Currently, the file system is used. Therefore, you must set filesystemio_options to asynch to enable asynchronous io:
SQL> ALTER SYSTEM SET FILESYSTEMIO_OPTIONS = ASYNCH SCOPE = SPFILE;
System altered.
SQL> SHUTDOWN IMMEDIATE
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> STARTUP
ORACLE instance started.
Total System Global Area 6.0264E + 10 bytes
Fixed Size 2242912 bytes
Variable Size 2147485344 bytes
Database Buffers 5.7982E + 10 bytes
Redo Buffers 131960832 bytes
Database mounted.
Database opened.
SQL>
Check the asynchronous io settings on the system again and find that the asynchronous io has been started:
[Oracle @ localhost ~] $ More/proc/slabinfo | grep kio
Kioctx 130 160 384 10 1: tunables 54 27 8: slabdata 16 16 0
Kiocb 16 30 256 15 1: tunables 120 60 8: slabdata 2 2 1
As you can see, asynchronous IO has taken effect now.
On Linux, how does one enable asynchronous IO in Oracle?
For more information about Oracle, see