Oracle参数系列

、

前言部分

导读和注意事项

各位技术爱好者，看完本文后，你可以掌握如下的技能，也可以学到一些其它你所不知道的知识，\~O(∩_∩)O\~：

① Oracle中的各种参数介绍及其查询方法

② Oracle中V\$PARAMETER及V\$PARAMETER2的区别

③ 隐含参数的查询、重置、清除

④ 会话参数和实例参数的查询

⑤ 静态参数和动态参数、延迟参数

⑥ V\$PARAMETER视图的每列含义（重点）

Oracle参数简介

Oracle数据库根据SPFILE或PFILE中设置的参数来配置数据库的启动。每个数据库实例在启动之前，首先读取这些参数文件中设置的不同参数。Oracle系统中的参数，根据系统使用情况可以简单分为两大类：

• 普通参数：Oracle系统正常使用的一些参数
• 非凡参数：包括3种，过时参数、强调参数和隐含参数。

图 3-8 Oracle参数分类

首先介绍一下参数的设置方法。初始化参数的设置方法有很多种：

• 通过“ALTER SYSTEM/SESSION SET 参数名=参数值 SCOPE = MEMORY;”的方式仅在内存里修改。
• 通过“ALTER SYSTEM SET 参数名=参数值 SCOPE = SPFILE;”的方式只修改SPFILE里的值。
• 通过“ALTER SYSTEM SET 参数名=参数值 DEFERRED SCOPE = SPFILE;”的方式设置延迟生效，也就是说这个修改只对以后连接到数据库的会话生效，而对当前会话以及其它已经连接到Oracle的会话不会生效。
• 通过“ALTER SYSTEM/SESSION SET 参数名=参数值 SCOPE = BOTH;”或省略BOTH这个关键词可以同时修改SPFILE和MEMORY中的值。

ALTER SESSION和ALTER SYSTEM的区别如下：

Oracle参数变更生效范围如下表所示：

在RAC环境中，若想修改所有实例，则可以在ALTER SYSTEM的最后加上“SID='*'”或“SID='实例名'”即可。“*”代表所有实例。

过时参数和强调参数

过时参数（Obsolete Parameters），顾名思义就是在Oracle以前的版本中存在，但在新版本中已经淘汰了的参数，已经不再使用的参数。在视图V\$OBSOLETE_PARAMETER中，包含这些参数的名称和一个列ISSPECIFIED，该列用来指出这个参数是否在参数文件中已实际设置。下面的SQL脚本列出了当前系统中所有的过时参数名称以及它们是否在当前系统中设定。

强调参数（Underscored Parameters），是指那些在新版本中保留了下来，但是除非非常需要否则不希望用户使用的那些参数。强调参数可以通过系统视图X\$KSPPO来查看，该视图中包含一个名为KSPPOFLAG的字段。该字段用来指明该参数在当前版本中是被丢弃还是被强调。若该值为1，则表示该参数已被丢弃，若该值为2，则表明该参数现为强调参数。

可以看到HASH_JOIN_ENABLED这个参数为强调参数，在隐含参数中表现为“_HASH_JOIN_ENABLED”，而JOB_QUEUE_INTERVAL已变为了过时参数。

隐含参数

Oracle系统中还有一类参数称之为隐含参数（Hidden Parameters），在系统中使用，但Oracle官方没有公布的参数，这些参数可能是那些还没有成熟或者是系统开发中使用的参数。这些参数在所有Oracle官方提供的文档中都没有介绍，它们的命名有一个共同特征就是都以“_”作为参数的首字符。下面的查询可以得到当前系统中的所有隐藏参数，需要以SYS用户登陆，查看两个视图：X\$KSPPI和X\$KSPPCV。下面作者给出具体的SQL语句。

举个例子，如果需要查询隐含参数“_LM_DD_INTERVAL”的值，那么执行上面的代码后输入“_LM_DD_INTERVAL”就可以看到该隐含参数的值了，如下所示：

可以看到该隐含参数的值为10。

对于隐含参数而言，修改隐含参数的值的时候需要将隐含参数用双引号括起来。若要清除SPFILE中的隐含参数可以使用RESET命令。

普通用户是不具备查询隐含参数的权限的，可以通过创建视图和同义词的方式来解决这个问题，如下所示：

普通参数（系统当前参数）

1、普通参数

普通参数就是Oracle系统正常使用的一些参数。查询Oracle初始化参数的方式大约有如下几种：

表 3-8 查询Oracle初始化参数的方式

一般在查询初始化参数的时候都习惯性的使用SHOW PARAMETER，也就是查询V\$PARAMETER视图。V\$PARAMETER视图反映的是初始化参数在当前会话中生效的值，而V\$SYSTEM_PARAMETER反映的才是实例级上的初始化参数。有关视图V\$PARAMETER的解释参考下表：

表 3-9 V\$PARAMETER视图解释

V$PARAMETER和V$PARAMETER2

首先看一下V\$PARAMETER和V\$PARAMETER2的区别，这个区别同样适用于V\$SYSTEM_PARAMETER和V\$SYSTEM_PARAMETER2：

SELECT NAME, VALUE FROM V\$PARAMETER

MINUS

SELECT NAME, VALUE FROM V\$PARAMETER2;

SELECT NAME, VALUE FROM V\$PARAMETER2

MINUS

SELECT NAME, VALUE FROM V\$PARAMETER;

现在这两个视图的结果一目了然了。进一步的研究可以看到底层的数据源来自两个不同的位置，V\$PARAMETER来自x\$ksppcv ，V\$PARAMETER2来自x\$ksppcv2，数据源的不同也正是前端的不同。

V$PARAMETER和V$SYSTEM_PARAMETER

一般在查询初始化参数的时候都习惯性的使用SHOW PARAMETER，也就是查询V\$PARAMETER视图。V\$PARAMETER视图反映的是初始化参数在当前会话中生效的值，而V\$SYSTEM_PARAMETER反映的才是实例级上的初始化参数。

我们通过query_rewrite_enabled这个参数来做一个验证。

这时候如果在会话级修改 query_rewrite_enabled 这个初始化参数：

可以看到，show parameter 和查询 v\$parameter 视图的结果都是 FALSE，而刚才做的修改只是会话级，并没有修改系统的初始化参数。我们应该形成的知识常识：V\$PARAMETER 视图反映的是初始化参数在当前会话中生效的值，而 V\$SYSTEM_PARAMETER 反映的才是实例级上的初始化参数。

再来看看延迟参数修改的情况：

结果和前面的恰好反过来，v\$parameter 视图中的结果没有发生变化，而 v\$system_parameter 视图的结果变成了 OFF。

这是因为延迟修改对数据库中当前存在的会话不生效，因此反映当前会话情况的 v\$parameter 视图结果不变，而对于系统而言，初始化参数已经改变，而且所有新建会话的参数也会改变，所以 v\$system_parameter 视图的结果发生了改变。

根据这两个例子可以获得的常识是：利用 V\$PARAMETER 视图获取系统的启动初始化参数是不准确的，因为它获取的是当前会话的参数，应该从 V\$SYSTEM_PARAMETER 视图来获取。

RAC环境下初始化参数的查询

使用 SHOW PARAMETER 查询，看到的是当前会话可以看到的初始化参数，那么这个参数导致是全局设置还是当前实例设置的，是从这个命令中看不到的。虽然 Oracle 提供了 GV\$ 开头的初始化参数，可以用来查询两个实例上的设置，但是情况并不是这么简单的。

一个简单的例子：

现在来看看不同的查询方法得到的结果：

似乎除了看不到全局设置外，GV\$PARAMETER 参数和 V\$SPPARAMETER 没有什么不同，其实不然，如果 alter system set 的时候只修改了 spfile 或只修改了 memory 参数，结果就会不同：

从上面的对比就可以看出，通过 GV\$ 视图访问的结果和 SPFILE 中包含的信息其实是两回事。

除了上面介绍的几种视图之外，CREATE PFILE 其实也是一个不错的选择，在10g 以前只能 CREATE PFILE FROM SPFILE，得到的结果类似于对 VSPPARAMETER 视图的查询，而11g增加了 CREATE PFILE FROM MEMORY 选项，这个得到的结果类似于从 GV\$SYSTEM_PARAMETER 视图获取的查询。

GV$SPPARAMETER参数的必要性

其实这里还有一个问题，就是 GV\$SPPARAMETER 是否有意义。因为 V\$SPPARAMETER 参数本身就包含了 SID 列，SPFILE 中本身就包含了所有实例的设置，那么查询 GV\$SPPARAMETER 视图是否就意义不大呢，其实不然。

因为 RAC 的各个节点可以使用统一的 SPFILE 启动，同样也可以选择不同的 SPFILE 来进行启动，这时 GV\$SPPARAMETER 视图中获取结果，才是真正各个实例 SPFILE 中设置的结果。

可以看到，由于两个实例采用了不同的 SPFILE，导致两个实例上设置的对方实例的初始化参数值，与对方实例上当前设置值不符。

在上面的例子中，两个实例上真正的参数设置查询方式为：

如何判断一个初始化参数的来源？

检查当前的数据库设置可以发现，虽然当前 SPFILE 中 open_cursors 是明确设置的，但是由于 pfile 中设置了实例级的初始化参数覆盖了数据库级的初始化参数，导致系统当前的参数设置和 SPFILE 中的设置并不相同。

CREATE PFILE的方法检查初始化参数

使用了这个语句，所有的 SPFILE 中设置的初始化参数设置都一目了然。

除了 CREATE PFILE FROM SPFILE 外，11g 还增加了 CREATE PFILE FROM MEMORY 选项，使得用户可以直接从数据库当前生效的参数来生成 PFILE 文件，利用这个方法，就可以解决上一篇文章最后介绍的 PFILE 中设置的实例级参数覆盖 SPFILE 中数据库级参数的情况：

但是这种方法显然也存在问题，首先从得到的结果看，里面除了包含用户设置的初始化参数外，还包含了大量的隐含参数。如果这些隐患参数是 Oracle 用于自动调整的双下划线参数也不奇怪，问题是大部分都是 Oracle 不推荐设置的单下划线隐含参数。不过这倒是一个查看 Oracle 隐患参数的好办法。

另外一个问题是，这个方法只对当前实例设置的参数有效，而无法合并多个实例的设置，对比上面的 OPEN_CURSORS 参数的设置和下面查询的结果就可以发现这个问题：

从这个结果可以看到，CREATE PFILE 获取的 PFILE 只对当前实例有效，虽然获取的结果包含多个实例的设置，但是这些设置可能和其他实例上的真正设置并不相符。

如何判断一个初始化参数是否是默认参数值?

如何判断一个初始化参数的值是否是默认参数值？Oracle在视图V\$SYSTEM_PARAMETER或V\$PARAMETER中提供了一个列ISDEFAULT，表示当前设置的值是否是数据库的默认值。

Oracle 在视图 V\$SYSTEM_PARAMETER 中提供了一个列 ISDEFAULT，表示当前设置的值是否是数据库的默认值：

根据这个结果可以看到，数据库中绝大部分的初始化参数设置都是默认值。

对于手工设置的初始化参数与系统默认值相同的情况，通过 v\$system_parameter 视图是无法区分的。

同样通过查询 V\$SPPARAMETER 视图检查 SPFILE 的设置也不准确，因为初始化参赛可能是通过 PFILE 设置的，或者是实例启动后由 ALTER SYSTEM 命令进行过修改。

对于这种情况，其实上一篇文章中介绍的 CREATE PFILE FROM MEMORY 或 CREATE 的方式是可以看到的，不过既然这种方法能够查询得到，那么数据库中一定是在默写地方进行了记录。

实际上查询 V\$SYSTEM_PARAMETER4 视图就可以获取到所有用户设置的初始化参数。

而事实上，当数据库执行 CREATE PFILE FROM MEMORY 命令时，Oracle 创建 PFILE 的数据源就是 V\$SYSTEM_PARAMETER4 这个视图。

前面介绍了很多种查询初始化参数的方法，其实还有一个方法也是很有用的，就是通过 alert 文件检查数据库加载的所有非默认值的初始化参数。

检查 alert 文件的方法不但可以获取当前实例所有非默认初始化参数的信息，还是初始化参数文件丢失后用来恢复初始化参数文件的一种方法。

静态参数和动态参数

如何判断一个初始化参数的值是否是延迟生效、是否是动态参数？动态参数指的是可以使用ALTER SESSION或ALTER SYSTEM在数据库运行时进行修改并能立即生效的参数。静态参数指的是只能通过修改参数文件且数据库必须要重启才能生效的参数。Oracle在视图V\$PARAMETER中提供了一个列ISSYS_MODIFIABLE，若值为IMMEDIATE代表参数可用ALTER SYSTEM更改，且立刻生效，该参数属于动态参数；若值为DEFERRED代表参数可以用ALTER SYSTEM更改，但是在新连接的会话中生效，该参数属于动态参数；若值为FALSE代表参数不能使用ALTER SYSTEM更改，但是若当前参数文件使用的是SPFILE，则可以使用ALTER SYSTEM更改，且下次实例启动生效，该参数属于静态参数。

静态参数举例：

动态参数举例：

动态延迟（DEFERRED）参数举例。DEFERRED指定系统修改是否只对以后的会话生效（对当前建立的会话无效，包括执行此修改的会话）。默认情况下，ALTER SYSTEM命令会立即生效，但是有些参数不能“立即”修改，只能为新建立的会话修改这些参数。