|The parsing numbers are high||The SHARED_POOL_SIZE may need to be increased|
|The disk reads are very high||Indexes are not being used or may not exist|
|The query and/or current (memory reads) are very high||
Indexes may be on columns with
(columns where an individual value generally
makes up a large percentage of the table; like a y/n
field). Removing/suppressing the index or using
histograms or a bitmap index may increase
performance. A poor join order of tables or bad
order in a concatenated index may also cause this.
|The parse elapse time is high||There may be a problem with the number of open cursors|
number of rows processed by a
row in the EXPLAIN PLAN is high
compared to the other rows.
This could be a sign of an index
with a poor
distribution of distinct keys (unique values for a
column). This could also be a sign of a poorly
number of misses in the library cache
during parse is greater than 1.
This indicates that the
statement had to be
reloaded. You may need to increase the
SHARED_POOL_SIZE in the init.ora file or do a
better job of sharing SQL.
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22621861/viewspace-1279733/，如需转载，请注明出处，否则将追究法律责任。
Oracle 12c的DG自动同步密码文件--ASM 新特性：共享密码文件lhrbest
Oracle 18c orapwd 命令 OPW-00029: Password complexity failedlhrbest
ORA-27300: OS system dependent operation:fork failed with statuswuweilong
ORA-01455: converting column overflows integer datatype甲骨文技术支持