ORACLE常用参数

1. ORACLE常用参数和意义

1. ORACLE常用参数和意义
- 1.1. 常用参数
- 1.2. oracle pfile/spfile区别
查看参数信息
修改参数

1.1. 常用参数

oracle 查看常用参数的类型和默认值

show parameter;
select name,type,value from v$parameter;

查看参数可以设置的值和默认值
select * from v$parameter_valid_values；
select * from v$parameter_valid_values where name like '%recyclebin%';
VALUE :表示参数可以设置的值
ISDEFAULT ：参数的默认值

Oracle参数

1.2. oracle pfile/spfile区别

pfile 默认的名称为“init+例程名.ora”文件路径：E:\oracle\product\10.2.0\db_1\dbs，这是一个文本文件，可以用任何文本编辑工具打开。
spfile 默认的名称为“spfile+例程名.ora”文件路径：E:\oracle\product\10.2.0\db_1\dbs以二进制文本形式存在，不能用vi编辑器对其中参数进行修改。
两个文件可以用命令 CREATE PFILE FROM SPFILE或CREATE SPFILE FROM PFILE来互相创建

区别：

启动次序 SPfile优先于Pfile。
PFILE是静态文件，修改之后不会马上生效，数据库必须重新启动读取这个文件才行。
SPFILE是动态参数文件，是二进制文件，不可以直接用记事本等等程序做修改，可以用ALTER命令做修改，不用重起数据库也能生效。

修改方法：

查看参数信息

sql>show parameter;

修改参数

sql>alter system set 参数名=值 scope=参数2；

参数2取值有如下三种：
1. scope=spfile: 对参数的修改记录在服务器初始化参数文件中，修改后的参数在下次启动DB时生效。适用于动态和静态初始化参数。
2. scope=memory: 对参数的修改记录在內存中，对于动态初始化参数的修改立即生效。在重启DB后会丟失,会复原为修改前的参数值。
3. scope=both:   对参数的修改会同时记录在服务器参数文件和內存中，对于动态参数立即生效，对静态参数不能用这个选项。

如果使用了服务器参数文件，则在执行alter system语句时，scope=both是default的选项。
如果沒有使用服务器参数文件，而在执行alter system语句时指定scope=spfile|both都会出错。

1.2.1. init.ora文件（E:\oracle\product\10.2.0\db_1\srvm\admin）

该文件的参数说明：

1.2.1.1. 1）db_name = "clustdb"

一个数据库标识符，应与CREATE DATABASE 语句中指定的名称相对应。

1.2.1.2. instance_name = clustdb1

在多个例程使用相同服务名的情况下，用来唯一地标识一个数据库例程；INSTANCE_NAME 不应与 SID 混淆，它实际上是对在一台主机上共享内存的各个例程的唯一标识。

control_files = control_files = ("\.\clustdb_control1", "\.\clustdb_control2")

1.2.1.3. open_cursors =300

库高速缓存 指定一个会话一次可以打开的游标 (环境区域) 的最大数量，并且限制 PL/SQL 使用的 PL/SQL 游标高速缓存的大小，以避免用户再次执行语句时重新进行语法分析。请将该值设置得足够高，这样才能防止应用程序耗尽打开的游标。

alter system set open_cursors=1000 sid='1' scope=spfile;
alter system set open_cursors=1000 sid='2' scope=spfile;

alter system set session_cached_cursors=200 sid='1' scope=spfile;
alter system set session_cached_cursors=200 sid='2' scope=spfile;

oracle数据库参数open_cursors和session_cached_cursor详解！

open_cursors
每个session（会话）最多能同时打开多少个cursor（游标）
session_cached_cursor
每个session（会话）最多可以缓存多少个关闭掉的cursor

SQL> show parameter open_cursors           --每个session（会话）最多能同时打开多少个cursor（游标）  
  
NAME                                 TYPE        VALUE  
------------------------------------ ----------- ------------------------------  
open_cursors                         integer     300  
SQL> show parameter session_cached_cursor  --每个session（会话）最多可以缓存多少个关闭掉的cursor  
  
NAME                                 TYPE        VALUE  
------------------------------------ ----------- ------------------------------  
session_cached_cursors               integer     20  

SQL> select count(*) from v$open_cursor;  --是指当前实例的某个时刻的打开的cursor数目

  COUNT(*)  
----------  
       108
1、open_cursors与session_cached_cursor有什么作用？
open_cursors设置每个会话session最多能同时打开多少个cursor（游标）。session_cached_cursor 设定每个session（会话）最多可以缓存多少个关闭掉的cursor。我们得看看oracle如何执行每个sql语句。

open_cusor

通过分析上图我们可以得出

a、两个参数之间没有任何关系，相互也不会有任何影响。
b、两个参数有着相同的作用：让后续相同的sql语句不在打开游标，从而避免软解析过程来提供应用程序的效率。

如何正确设置session_cached_cursors参数

a、如果Open_cursors设置太小，对系统性能不会有明显改善，还可能触发ORA-O1000：m~imum open CUrsOrs exceeded．的错误。如果设置太大，则无端消耗系统内存.

正确设置open_cursors和'session_cached_cursors' 可以减少sql解析，提高系统性能，那么，如何正确设置'session_cached_cursors' 这个参数呢？我们可以把握下面的原则：
1、'session_cached_cursors' 数量要小于open_cursor
2、要考虑共享池的大小
使用下面的sql判断'session_cached_cursors' 的使用情况。如果使用率为100%则增大这个参数值。

select 'session_cached_cursors' parameter,
       lpad(value, 5) value,
       decode(value, 0, '  n/a', to_char(100 * used / value, '990') || '%') usage
  from (select max(s.value) used
          from v$statname n, v$sesstat s
         where n.name = 'session cursor cache count'
           and s.statistic# = n.statistic#),
       (select value from v$parameter where name = 'session_cached_cursors')
union all
select 'open_cursors',
       lpad(value, 5),
       to_char(100 * used / value, '990') || '%'
  from (select max(sum(s.value)) used
          from v$statname n, v$sesstat s
         where n.name in
               ('opened cursors current', 'session cursor cache count')
           and s.statistic# = n.statistic#
         group by s.sid),
       (select value from v$parameter where name = 'open_cursors');

对于ORA-O1000：m~imum open CUrsOrs exceeded

SELECT MAX(A.VALUE) HIGHEST_OPEN_CUR, C.VALUE MAX_OPEN_CUR  
    FROM V$SESSTAT A, V$STATNAME B, V$PARAMETER C  
   WHERE A.STATISTIC# = B.STATISTIC#  
     AND B.NAME = 'opened cursors current'  
     AND C.NAME = 'open_cursors'  
   GROUP BY C.VALUE;

HIGHEST_ OPEN CUR是实际打开cursors的最大值，MAX_OPEN_ CUR是参数Open_cursors的设定值，如果二者太接近，甚至触发eRA一01000错误，那么你就应该调大参数Open_cursors的设定值。如果还不能解决问题，盲目增大Open_cursors也是不对的，这时你得检查应用程序的代码是否合理，比如说应用程序是否打开了游标，却没有在它完成工作后没有及时关闭。以下语句可以帮助你确定导致游标漏出的会话：

1.2.1.4. db_block_buffers = 200（9i的参数，之后被db_block_size 参数所代替，详见15条记录）

高速缓存与I/O    缓冲区高速缓存中 Oracle 块的数量。该参数会显著影响一个例程的 SGA 总大小。

1.2.1.5. large_pool_size=1048576

池--指定大存储池的分配堆，它可被多线程服务器 (MTS) 用作会话内存、用作并行执行的消息缓冲区以及用作 RMAN备份和恢复的磁盘 I/O 缓冲区。

1.2.1.6. java_pool_size=67108864

以字节为单位，指定 Java 存储池的大小，它用于存储 Java 的方法和类定义在共享内存中的表示法，以及在调用结束时移植到 Java 会话空间的 Java 对象。

1.2.1.7. log_checkpoint_interval = 10000

指定在出现检查点之前，必须写入重做日志文件中的 OS 块 (而不是数据库块) 的数量。无论该值如何，在切换日志时都会出现检查点。较低的值可以缩短例程恢复所需的时间，但可能导致磁盘操作过量。

1.2.1.8. processes = 220 log_buffer = 8388608

以字节为单位，指定在 LGWR 将重做日志条目写入重做日志文件之前，用于缓存这些条目的内存量。重做条目保留对数据库块所作更改的一份记录。如果该值大于65536，就能减少重做日志文件 I/O，特别是在有长时间事务处理或大量事务处理的系统上  **最大值为 500K 或 128K * CPU_COUNT，两者之中取较大者

1.2.1.9. oracle_trace_enable = true

启动一个默认的 Oracle Trace 集合，直到该值再次设置为 NULL。

1.2.1.10. timed_statistics=true

收集操作系统的计时信息，这些信息可被用来优化数据库和 SQL语句。要防止因从操作系统请求时间而引起的开销，请将该值设置为零。将该值设置为 TRUE 对于查看长时间操作的进度也很有用。

1.2.1.11. background_dump_dest=%ORACLE_HOME%/admin/clustdb/bdump

指定在 Oracle 操作过程中为后台进程 (LGWR，DBW n 等等) 写入跟踪文件的路径名(目录或磁盘)。它还定义记录着重要事件和消息的数据库预警文件的位置。

1.2.1.12. core_dump_dest = /opt/apps/oracle/admin/51cto/cdump

指定核心转储位置的目录名 (用于 UNIX)。

1.2.1.13. user_dump_dest=%ORACLE_HOME%/admin/clustdb/

为服务器将以一个用户进程身份在其中写入调试跟踪文件的目录指定路径名。例如，该目录可这样设置: NT 操作系统上的 C:/ORACLE/UTRC；UNIX 操作系统上的 /oracle/utrc；或 VMS 操作系统上的DISK$UR3:[ORACLE.UTRC]。

1.2.1.14. db_block_size = 8192

一个 Oracle 数据库块的大小 (以字节计)。该值在创建数据库时设置，而且此后无法更改。 1024 - 65536 (根据操作系统而定)。

1.2.1.15. remote_login_passwordfile = exclusive

指定操作系统或一个文件是否检查具有权限的用户的口令。如果设置为 NONE，Oracle 将忽略口令文件。如果设置为EXCLUSIVE，将使用数据库的口令文件对每个具有权限的用户进行验证。如果设置为 SHARED，多个数据库将共享 SYS 和INTERNAL口令文件用户

1.2.1.16. job_queue_processes = 4

只用于复制环境。它指定每个例程的 SNP 作业队列进程的数量 (SNP0, ... SNP9, SNPA, ... SNPZ)。要自动更新表快照或执行由 DBMS_JOB 创建的请求，请将该参数设置为 1 或更大的值。   0 到 36

1.2.1.17. job_queue_interval = 10

作业队列只用于复制环境。它以秒为单位指定该例程的每个 SNPn 后台进程的唤醒频率。  1 到 3600

1.2.1.18. distributed_transactions = 5

一个数据库一次可参与的分布式事务处理的最大数量。如果由于网络故障异常频繁而减少该值，将造成大量未决事务处理。

1.2.1.19. open_links = 4

指定在一次会话中同时打开的与远程数据库的连接的最大数量。该值应等于或超过一个引用多个数据库的单个 SQL 语句中引用的数据库的数量，这样才能打开所有数据库以便执行该语句。

1.2.1.20. compatible = "11.2.0.4.0"

允许使用一个新的发行版，同时保证与先前版本的向后兼容性。

1.2.1.21. sort_area_size = 524288

以字节为单位，指定排序所使用的最大内存量。排序完成后，各行将返回，并且内存将释放。增大该值可以提高大型排序的效率。如果超过了该内存量，将使用临时磁盘段。

相当于 6 个数据库块的值 (最小值) 到操作系统确定的值 (最大值)。

1.2.1.22. db_file_multiblock_read_count

     一次从物理存储中读取的数据块数量 ,数据库默认是一次性读取128个数据块，也就是1M的数据量，数据仓储环境适当的增大这个数据。

 此参数值的设置，需要在实践的基础上，慢慢试验的得出，不可一概而论。

1.2.1.23. db_block_size

数据块的大小，数据库默认是8K的数据库，这个参数在建库后无法调整，设置数据块的大小是依据不同类型的系统的。

  如果数据块设置比较大，那么一次读取的数据行较多，相应对SGA内存消耗比较大，特定查询引发的换入换出可能较多。如果设置的过小，频繁的IO逻辑物理读也会引起性能问题。

1.2.1.24. PRE_PAGE_SGA

oracle实例启动时，会只载入各个内存区最小的大小。而其他SGA内存只作为虚拟内存分配，只有当进程touch到相应的页时，才会置换到物理内存中。但我们也许希望实例一启动后，所有SGA都分配到物理内存。这时就可以通过设置PRE_PAGE_SGA参数来达到目的了。这个参数的默认值为FALSE，即不将全部SGA置入物理内存中。当设置为TRUE时，实例启动会将全部SGA置入物理内存中。它可以使实例启动达到它的最大性能状态，但是，启动时间也会更长（因为为了使所有SGA都置入物理内存中，oracle进程需要touch所有的SGA页）。当参数设置为TRUE时，不仅在实例启动时，需要touch所有的SGA页，并且由于每个oracle进程都会访问SGA区，所以每当一个新进程启动时（在Dedicated Server方式中，每个会话都会启动一个Oracle进程），都会touch一遍该进程需要访问的所有页。因此，每个进程的启动时间页增长了。所以，这个参数的设置需要根据系统的应用情况来设定。

LOCK_SGA RE_PAGA_SGA只是在启动时将物理内存分配给SGA，但并不能保证系统在以后的运行过程不会将SGA中的某些页置换到虚拟内存中，也就是说，尽管设置了这个参数，还是可能出现Page In/Out。如果需要保障SGA不被换出，就需要由另外一个参数LOCK_SGA来控制了。

1.2.1.25. memory_max_target ，memory_target ,SGA_MAX_SIZE ,SGA_TARGET

先解释下这四个参数的决定关系：
memory_max_target >=memory_target >SGA_MAX_SIZE >=SGA_TARGET
memory_max_target oracle 所能使用的内存的总体大小，包括SGA和PGA；
SGA_MAX_SIZE sga所能使用的的全部内存大小，
10g 后oracle使用内存共享自动管理方法，以使内存达到最大限度的利用，
memory_target和SGA_TARGET 这两个参数决定的是是否启用自动内存管理(ASMM），参数默认是为0，一旦设置数值后，将自动启用内存自动管理(ASMM），

例如：SGA_TARGET的默认值为0，我现在修改为452M(SGA_MAX_SIZE为512M),也即是说，sga总内存为512M，其中的的452M属于共享内存，这部分内存oracle会根据实际情况，分配给内存较小的区域，如share_pool,buffer_cache等，但是这个参数的值，永远不可能超过SGA_MAX_SIZE。
oracle可以随时调节各个区域的大小，使之达到系统性能最佳状态的个最合理大小，并且控制他们之和在SGA_TARGET指定的值之内。一旦给SGA_TARGET指定值后（默认为0，即没有启动ASMM），就自动启动了ASMM特性。

1.2.1.26. DB_WRITER_PROCESSES

DB_WRITER_PROCESSES参数配置写进程的个数，各个进程以DBWn区分，其中n>=0，是进程序号。一般情况下，DB_WRITER_PROCESSES = MAX(1, TRUNC(CPU数/8))。也就是说，CPU数小于8时，DB_WRITER_PROCESSES为1，即只有一个写进程DBW0。这对于一般的系统来说也是足够用。当你的系统的修改数据的任务很重，并且已经影响到性能时，可以调整这个参数。这个参数不要超过CPU数，否则多出的进程也不会起作用，另外，它的最大值不能超过20。

undo_retention

1.2.2. alert.log文件（e:\oracle\product\10.2.0/admin/fgisdb/bdump\alert_fgisdb.log）

告警日志，在产生错误时，启动和关闭实例时，都会记录信息到告警日志中，此外还记录了不同于默认值的初始参数的列表，alter

system，alter database命令，对表空间，数据文件的操作，空间不足，损坏的文件等。
告警日志也会变得很大，可在任意时间重命名或删除告警日志，但是告警日志记录了数据库的各种安全信息，维护和恢复等信息，因此可
根据时间先后来选择性删除。

1.2.3. DB_FILES参数

在Oracle11G maxdatafiles这个参数是会自动扩展的，所以我们没有必要对该文件进行设置（发现有网友因为db_files的文件问题重新创建了控制文件，经过本人测试确实没有必要）。
只是要注意系统对文件数的限制：
open files

【前言】
Oracle数据库创建是的默认参数一般是够大部分的数据库使用了，但是在一些情况下有写参数是需要进行变更的。

【问题背景】
公司有个Oracle的数据库仓库，整个数据库大小5TB+，但是整个空间也快满了。在进行添加表空间的时候就报了ORA-59的错误。

【问题分析】
1、错误分析

[oracle@ekpjdbtest trace]$ oerr ora 59
00059, 00000,  "maximum number of DB_FILES exceeded"
// *Cause:  The value of the DB_FILES initialization parameter was exceeded.
// *Action: Increase the value of the DB_FILES parameter and warm start.

以上报错显示DB_FILES参数值已经达到最大。

SQL>   select   count(1)  from   dba_data_files;
 
   COUNT(1)
----------
        200
SQL> show parameter db_files;
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_files                             integer     200

2、db_files的oracle文档说明

Property	Description
Parameter type	Integer
Default value	200
Modifiable	No
Range of values	Minimum: the largest among the absolute file numbers of the datafiles in the database
Maximum: operating system-dependent

Basic	No
Oracle RAC	Multiple instances must have the same value.
DB_FILES specifies the maximum number of database files that can be opened for this database. The maximum valid value is the maximum number of files, subject to operating system constraint, that will ever be specified for the database, including files to be added by ADD DATAFILE statements.

If you increase the value of DB_FILES , then you must shut down and restart all instances accessing the database before the new value can take effect. If you have a primary and standby database, then they should have the same value for this parameter.

【解决方法】
知道了整个问题的来龙去脉，解决方法也就很简单了。

SQL> alter system  set   db_files=500 scope=spfile;

Shutdown the database with immediate option and restart so that the  new   value  for   db_files can be read.
SQL> shutdown immediate
SQL> startup
 
Check the  new   value  for   db_files parameter
SQL> show parameter db_files;
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_files                             integer     500

【其他】
1、 DB_FILES 参数涉及到要打开操作系统的数据文件的个数，所以如果还有问题也要查看下操作系统的一些参数情况

[oracle@test trace]$ ulimit -a
open files                      (-n) 65536

2、db_files和maxdatafiles参数的关系

The db_files parameter is a "soft limit " parameter that controls the maximum number of physical OS files that can map to an Oracle instance. Historically (before Oracle8i) you need to be careful not to set db_files too high, else you would have DBWR (database writer) issues.

The maxdatafiles parameter is a different "hard limit" parameter.  When you issue a"create database" command, the value you specify for maxdatafiles is stored in your Oracle control files.  The default value of 32 is usually sufficient, but after Oracle8i there is no downside to using a larger value.

在Oracle11G maxdatafiles这个参数是会自动扩展的，所以我们没有必要对该文件进行设置（发现有网友因为db_files的文件问题重新创建了控制文件，经过本人测试确实没有必要）。

我在测试环境中进行了操作，maxdatafiles的大小是8，然后增加数据文件的方式来进行表空间，发现数据库的alert log里面就记录了整个maxdatafiles扩展的操作记录。

1、alert log显示控制文件进行了Expanded的操作

Expanded controlfile section 4  from   10 to 40 records
Requested to grow  by   30 records; added 1 blocks of records

2、alter database backup controlfile to trace resetlogs; 查看控制文件的参数情况

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE  "WZQ"   RESETLOGS  NOARCHIVELOG
     MAXLOGFILES 16
     MAXLOGMEMBERS 3
     MAXDATAFILES 40
     MAXINSTANCES 8
     MAXLOGHISTORY 292
显示MAXDATAFILES文件已经修改成40了。

1.3. ORACLE 11GR2常用参数(含隐含参数)设置如下：

alter system set "_PX_use_large_pool" = true scope=spfile;
alter system set "_clusterwide_global_transactions" = false scope=spfile;#RAC环境 https://www.sohu.com/a/152628320_505827
alter system set "_gc_defer_time" = 3 scope=spfile;
alter system set "_resource_manager_always_off" = true scope=spfile;
alter system set "_resource_manager_always_on" = false scope=spfile;
alter system set "_serial_direct_read" = never scope=spfile;
alter system set "_cleanup_rollback_entries" = 400 scope=spfile;
alter system set "_optimizer_use_feedback" = false scope=spfile;
alter system set "_dbms_sql_security_level" =0 scope=spfile;
alter system set "_bloom_pruning_enabled" = false scope=spfile;
修改DRM（有bug，易导致RAC 实例崩溃）
alter system set "_gc_policy_time" = 0 scope=spfile sid='*';
alter system set "_bloom_filter_enabled" = false scope=spfile;
alter system set "_gc_read_mostly_locking" = false scope=spfile;
alter system set "_gc_undo_affinity" = false scope=spfile;
#alter system set "_smu_debug_mode" = 134217728 scope=spfile;#http://www.laoxiong.net/how-to-drop-undo-segment.html
alter system set "_undo_autotune" = false scope=spfile;
alter system set deferred_segment_creation = false scope=spfile;
alter system set audit_trail = none scope=spfile;
alter system set event='28401 trace name context forever,level 1' scope=spfile;
关闭11g新特性自适应游标共享（Adaptive Cursor Sharing）
alter system set "_optimizer_extended_cursor_sharing_rel"=none;
alter system set "_optimizer_extended_cursor_sharing"=none;
alter system set "_optimizer_adaptive_cursor_sharing"=false;
alter system set "_memory_imm_mode_without_autosga"=false sid='*';关闭 _memory_imm_mode_without_autosga http://blog.itpub.net/27243841/viewspace-1147107/ 避免ORA4031
alter system set "_b_tree_bitmap_plans"=false sid='*';修改_b_tree_bitmap_plans，https://www.cnblogs.com/archersun/p/3173141.html
alter system set "_partition_large_extents"='FALSE' sid='*';
alter system set "parallel_force_local"=TRUE scope=spfile sid='*';
alter system set "parallel_max_servers"=64 scope=spfile sid='*';
alter system set "_use_adaptive_log_file_sync"='FALSE' sid='*'; _use_adaptive_log_file_sync 降低log_file_sync等待 http://blog.itpub.net/28572479/viewspace-2130627/

1.3.1. _PX_use_large_pool

并行执行从属进程一起工作时会交换数据和信息，所以我们需要从shared pool或large pool中分配内存，
这个取决于PARALLEL_AUTOMATIC_TUNING参数值的设置，_PX_use_large_pool所起的作用跟PARALLEL_AUTOMATIC_TUNING参数差不多。
当PARALLEL_AUTOMATIC_TUNING=TRUE时从large pool中分配内存，否则从shared pool分配。
10g中,PX信息缓存在large pool中分配，如果：

a.) parallel_automatic_tuning = true (弃用) or
b.) _PX_use_large_pool = true or
c.) sga_target is set

11g中,PX信息缓存在large pool中分配，如果：

a.) parallel_automatic_tuning = true (弃用) or
b.) _PX_use_large_pool = true or
c.) SGA memory is auto tuned (sga_target or memory_target)

设置：

alter system set "_PX_use_large_pool"=true sid='1' scope=spfile;
alter system set "_PX_use_large_pool"=true sid='2' scope=spfile;

1.3.2. _gc_defer_time

how long to defer pings for hot buffers in milliseconds
用于确定服务器在将频繁使用的块写入磁盘之前要等待的时间长度 (以 1/1000 秒为单位)，以减少进程对热块的争用，默认为0。
用于确定将buffer的数据写入磁盘之前要等待的时间长度，这样可减少实例的gc争用，优化实例对块的访问

默认值1 建议设置为3

alter system set "_gc_defer_time" = 3 scope=spfile;

1.3.3. _serial_direct_read

在Oracle 11g中，全表扫描可能使用direct path read方式(无论表大小)，而不是buffer cache，这样的全表扫描就是物理读了。
_serial_direct_read = false 禁用direct path read
_serial_direct_read = true 启用direct path read
_serial_direct_read = never 可以显著地减少direct path read

默认值为auto，建议设置为never

alter system set "_serial_direct_read" = never scope=spfile;

1.3.4. _resource_manager_always_off、_resource_manager_always_on

将_resource_manager_always_off = true、_resource_manager_always_on = false
即为禁用Oracle缺省启用的资源调度,
避免可能产生resmgr:cpu quantum等待事件情况。由于在11g中资源调度存在诸多BUG，故选择关闭。
部分官档：
'resmgr:cpu quantum' wait event in 11g when VKRM process is not present (文档 ID 1603996.1)
Awr Reports hang, MMon slaves are waiting on resmgr:cpu quantum (文档 ID 1530676.1)

默认FALSE、TRUE，其默认是启用资源调度。
建议关闭

1.3.5. _clusterwide_global_transactions

集群范围全局性事务(Clusterwide global transactions)是11g的新特性，其容许XA事务(XA分布式事务)在RAC中更透明。基本上，
一个集群范围全局性事务是一个在RAC中的每个节点均有一个本地事务的分布式事务，当_clusterwide_global_transactions=true(默认)时，
ORACLE会把这些本地事务当做一个事务对待，当_clusterwide_global_transactions=false时，ORACLE会将这些本地事务当做单独的事务
通过多阶段提交协调处理。设置该参数为false不会有任何性能影响。

设置该参数值为FALSE可以解决如下等问题：

Bug 13605839 ORA-600 [ktbsdp1] ORA-600 [kghfrempty:ds] ORA-600 [kdBlkCheckError]. Corruption in Rollback with Clusterwide Global Transactions in RAC
ORA-00600: [kjuscl:!free]

XA释义：
XA是X/Open DTP组织(X/Open DTP group)定义的两阶段提交协议，XA被许多数据库(如Oracle和DB2)和中间件等工具(如CICS 和 Tuxedo).本地支持。
X/Open DTP模型(1994)包括应用程序(AP)、事务管理器(TM)、资源管理器(RM)、通信资源管理器(CRM)四部分。在这个模型中，
通常事务管理器(TM)是交易中间件，资源管理器(RM)是数据库，通信资源管理器(CRM)是消息中间件。
一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个DTP环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。
而一个数据库只将其自己所做的操作(可恢复)影射到全局事务中。
XA就是X/Open DTP定义的交易中间件与数据库之间的接口规范(即接口函数)，交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。
XA接口函数由数据库厂商提供。通常情况下，交易中间件与数据库通过XA接口规范，使用两阶段提交来完成一个全局事务。

XA规范的基础是两阶段提交协议：
在第一阶段，交易中间件请求所有相关数据库准备提交(预提交)各自的事务分支，以确认是否所有相关数据库都可以提交各自的事务分支。
当某一数据库收到预提交后，如果可以提交属于自己的事务分支，则将自己在该事务分支中所做的操作固定记录下来，并给交易中间件一个同意提交的应答，
此时数据库将不能再在该事务分支中加入任何操作，但此时数据库并没有真正提交该事务，数据库对共享资源的操作还未释放(处于锁定状态)。
如果由于某种原因数据库无法提交属于自己的事务分支，它将回滚自己的所有操作，释放对共享资源上的锁，并返回给交易中间件失败应答。

在第二阶段，交易中间件审查所有数据库返回的预提交结果，如所有数据库都可以提交，交易中间件将要求所有数据库做正式提交，这样该全局事务被提交。
而如果有任一数据库预提交返回失败，交易中间件将要求所有其它数据库回滚其操作，这样该全局事务被回滚。

1.3.6. _cleanup_rollback_entries

该参数指定回滚时每次回滚的ENTRIES个数，默认为100，设置成400加快回滚速度。

1.3.7. _optimizer_use_feedback

11.2开始Oracle有了一种新的特性Cardinality Feedback，Cardinality Feedback是一个优化器自动优化的过程，
优化器会自动修正重复执行的查询的执行计划。对于一些复杂的查询，比如多字段条件，字符串范围比较，数据SKEW等等，
以及缺乏统计信息，优化器可能不能够产生一个完全准确的基数估计, 如丢失或统计数据不准确，或复杂的谓词的基数估计。
cardinality feedback 就是基于这一原因而产生的。
_optimizer_use_feedback参数默认是TRUE，即开启Cardinality Feedback，FALSE为关闭Cardinality feedback。
由于在11GR2中Cardinality feedback生效存在很多限制且BUG较多，故没必要启用。

1.3.8. _dbms_sql_security_level

该参数有0,1,2共3个值(默认值为1)，0关闭dbms_sql包的安全检查，打开光标级别为1的要求执行/绑定和解析用户id是相同的。
2级是更严格的和需要id和角色是相同的所有操作,如绑定、描述、执行、提取等。如果出现ORA-29471的错误之后，只有断开当前这个session，
然后重新连接数据库才可以正常调用DBMS_SQL包。若是想封闭security check，须要将一个隐含参数_dbms_sql_security_level设置成0，
重启数据库生效。

1.3.9. 九、_bloom_pruning_enabled、_bloom_filter_enabled

布隆过滤器(Bloom Filter)算法在Oracle Database 10gR2中被引入到Oracle数据库中,
布隆过滤能够使用极低的存储空间，存储海量数据的映射，从而可以提供快速的过滤机制。
11R2会遇到一个BLOOM过滤器导致的BUG 9124206和BUG 8361126，出现ORA-00060 ORA-10387错误，
_bloom_pruning_enabled、_bloom_filter_enabled均设为FALSE避免BUG
详细错误如下：
ORA-00060: deadlock detected while waiting for resource
ORA-10387: parallel query server interrupt (normal)

1.3.10. 十、_gc_policy_time

参数默认值是10，0是关闭DRM特性,DRM在11G中不稳定，存在众多BUG

1.3.11. 十一、_gc_read_mostly_locking

参数默认是TRUE，即开启read mostly locking，
FALSE即为禁用read mostly的特性，read mostly locking机制，能减少读访问的消息传递和CPU消耗，
但是写访问就会比传统的cache fusion locking机制消耗更多的IO。read-mostly的特性是给那些读很多，写很少的系统来启用比较合适。

1.3.12. 十二、_gc_undo_affinity

参数默认是TRUE，设置为FALSE用于关闭DRM。

1.3.13. 十三、_smu_debug_mode

默认为0，会有部分性能故障及BUG需要设置"_smu_debug_mode" = 134217728来避免，
另通过设置_smu_debug_mode值可以很好的实现在undo自动管理模式下,指定事务在特定的回滚段,
在某些极限情况下,可以通过该操作来减少回滚段争用。
例如：
(1)当undo自动管理分配undo时，某些情况下有些undo段很很忙，有些则比较空闲，这个时候我们需将事务使用的回滚段从忙的回滚段
修改成闲的回滚段。

select segment_name,owner,tablespace_name from DBA_ROLLBACK_SEGS; <<==查询回滚段
set transaction use rollback segment "_SYSSMU8_517538920$"; <<==执行回滚段
select XIDUSN from V$TRANSACTION; <<==查询事务回滚段

2)在11.2.0.2及以后版本，可能会遇到BUG 9272671，现象是每隔5分钟在alert日志中会输出
minact-scn: Slave 1 discarding message for out-of-order msg，该信息可以忽略，
亦可设置"_smu_debug_mode" = 134217728来避免该信息输出值alert日志。

3)当一个大事务被kill后，SMON进行事务回滚时会被MMON进程堵塞

select usn, state, undoblockstotal "Total", undoblocksdone "Done", undoblockstotal-undoblocksdone "ToDo",
decode(cputime,0,'unknown',sysdate+(((undoblockstotal-undoblocksdone) / (undoblocksdone / cputime)) / 86400)) "Estimated time to complete"
from v$fast_start_transactions;
USN STATE Total Done ToDo Estimated time to complete
---------- ---------------- ---------- ---------- ---------- -----------------------------
90 RECOVERED 15669 15669 0 01-OCT-2012 05:52:35
15 RECOVERING 174954 8137 166817 17-OCT-2012 12:32:07 <<<<<<<<<<
GNTOUN35>/
USN STATE Total Done ToDo Estimated time to complete
---------- ---------------- ---------- ---------- ---------- -----------------------------
90 RECOVERED 15669 15669 0 01-OCT-2012 05:52:39
15 RECOVERING 174954 8137 166817 17-OCT-2012 12:33:33 <<<<<<<<<<<<<<<
GNTOUN35>/
USN STATE Total Done ToDo Estimated time to complete
---------- ---------------- ---------- ---------- ---------- -----------------------------
90 RECOVERED 15669 15669 0 01-OCT-2012 05:52:40
15 RECOVERING 174954 8137 166817 17-OCT-2012 12:33:54 <<<<< see no movement for this

解决方法：
设置参数

alter system set "_smu_debug_mode"=134217728;
kill MMON进程(注：kill MMOM进程不会终止实例，AWR主要的进程，kill之后一个新的MMON进程会自动使用_smu_debug_mode=134217728启动)
kill -9

官档：
Minact-Scn Master-Status: Grec-Scn Messages In Trace File (文档 ID 1361567.1)
SMON Is Waiting On Latch High CPU Resource consumption MMON blocking SMON (文档 ID 1496453.1)

1.3.14. 十四、_undo_autotune

默认TRUE，设置FALSE即关闭undo retention自动调整。
该参数用于自动调整undo retention时间，对于自动扩展(autoextend on)的undo表空间，参数undo_retention设置成为Oracle自动
调节undo retention的最低阀值。对于非自动扩展(autoextend off)，非guarantee的undo表空间，Oracle会根据undo表空间大小
和v$undostat的历史信息(是否统计undo信息是由隐含参数_collect_undo_stats决定的，默认情况为TRUE)最大可能性保留undo信息。

1.3.15. 十五、deferred_segment_creation

段延迟创建，默认是true，也就是新建一个表，并且没有向其中插入数据，那么这个表不会立即分配extent，也就是不占数据空间，
只有当insert数据后才会分配空间，这会导致在exp时，没有segment的对象不会导出。设置成false即禁用段延迟创建。

1.3.16. 十六、audit_trail

用于控制数据库审计，默认是DB，设置成none即关闭审计。

1.3.17. 十七、_optimizer_extended_cursor_sharing_rel、_optimizer_extended_cursor_sharing、_optimizer_adaptive_cursor_sharing

自适应游标共享(Adaptive Cursor Sharing： ACS)

alter system set "_optimizer_extended_cursor_sharing_rel"=none;
alter system set "_optimizer_extended_cursor_sharing"=none;
alter system set "_optimizer_adaptive_cursor_sharing"=false;

即为关闭ACS，避免众多Bug，例如Bug 11657468，Bug 12333007等。
官档：
Bug 11657468 - Excessive mutex waits with adaptive cursor sharing (文档 ID 11657468.8)
Bug 12333007 - Dump on kkocscopycolstats (文档 ID 12333007.8)

1.3.18. 十八、event='28401 trace name context forever,level 1'

在10.2.0.5及以后版本，使用错误密码登陆尝试会导致很高的Library Cache Locks或row cache lock,
可以设置该event来避免。

shared_pool_size

share_pool_size(共享池)的作用:
1、SQL共享缓冲池
2、该参数是库高速缓存和数据字典的高速缓存。
查看:

  SQL>SHOW PARAMETERS SHARED_POOL_SIZE

更改:

  SQL>ALTER SYSTEM SET SHARED_POOL_SIZE='50M' SCOPE=BOTH

shared pool主要包括library cache和dictionary cache。
library cache用来存储最近解析（或编译）后SQL、PL/SQL和Java classes等。
dictionary cache用来存储最近引用的数据字典。
发生在library cache或dictionary cache的cache miss代价要比发生在buffer cache的代价高得多。
因此shared pool的设置要确保最近使用的数据都能被cache。

默认值

如果设置了 SGA_TARGET：如果未指定参数，则默认为 0（由 Oracle 数据库内部确定）。 如果指定了该参数，则用户指定的值表示内存池的最小值。
如果未设置 SGA_TARGET（32 位平台）：64 MB，四舍五入到最接近的粒度。
如果未设置 SGA_TARGET（64 位平台）：128 MB，四舍五入到最接近的粒度。

remote_login_passwordfile

oracle 通过初始化参数 remote_login_passwordfile 来限制口令文件的使用，
通过这个参数可以设置用户登录时是否检查口令文件，以及有多少个数据库可以使用口令文件，
这个参数有三个选项EXCLUSIVE、SHARED、NONE.

alter system set remote_login_passwordfile=exclusive scope=spfile;

当把remote.......设置为none 远程用户不可以通过sysdba/sysoper身份登录数据库
也就是如果远程无法登录数据库时把值设置为EXCLUSIVE即可。

sql>show parameter pass

sql>connect sys/密码 as dba

sql>alter system set remote_login_passwordfile=exclusive scope=spfile;
system altered.
修改后重启就能够生效了

posted @ 2023-06-21 15:49 数据库小白（专注）阅读(249) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

数据库小白（专注）