在Oracle数据库的世界里，充满了挑战和意外，大到容灾备份，小到安装配置，一个小小的参数就可能引发无穷的麻烦。所以在资深DBA的职业生涯中，总是路走的越多，胆子反而变得更小。如果说回顾一下，我最愿意和大家分享的就是：谨慎、谨慎、再谨慎，哪怕是在最微小的环节，也容不得半点疏忽。在本章中，我就从小小的、最不重要的参数文件入手，和大家探讨一下，这其中可能存在的点点滴滴你可能疏忽的细节，而这样的疏忽又可能在紧要关头对数据库运维造成巨大的威胁。在Oracle数据库中，有一系列的初始化参数用来进行数据库约束和资源限制，这些参数通常存储在一个参数文件中，在数据库实例启动时读取并加载。初始化参数对数据库来说非常重要，很多参数通过合理的调整可以极大地提高数据库性能。而几乎所有的DBA都经历过参数调整错误时，对于参数文件手忙脚乱的修改过程，所以本书的读者一定要掌握对于参数文件的修改备份及恢复过程。
本章撰写的内容，详细描述了参数文件在各个数据库版本中的变化，以帮助读者了解Oracle数据库的演变过程，请读者在阅读的过程中注意相应的版本描述（注意，通常旧版本中的命令在新版本中是完全支持的，这就是向后兼容）
7.1 参数的分类
参数的分类方式有很多，一般按照得出方式不同，可以将其分为三类：推导参数、系统依赖参数和可变参数。另外随着Oracle版本的升级，对参数做出了相应的调整，因此不推荐参数和废弃参数也占了很大一部分。了解这些能够帮助我们更好地理解Oracle管理模式。
7.1.1 推导参数
推导参数通常来自于其他参数的运算，依赖其他参数得出，所以这类参数通常不需要修改。如果强制修改，那么修改值会覆盖推导值。
常见的此类参数有很多，例如SESSIONS参数，在Oracle 12c文档中，该参数按以下公式运算得出：
(1.5 * PROCESSES) + 22
PROCESSES参数代表操作系统上能够并发向Oracle数据库发起的连接进程数量。当PROCESSES被修改时，此参数会自动计算并生效。以下是一个示范数据库中这两个参数的设置：
SQL> select name,value from v$parameter where name in (‘processes’,‘sessions’);
NAME VALUE
processes 200
sessions 322
如果该参数设置过低，则在应用并非高时，超过PROCESSES数量的进程将无法连接到数据库。所以在规划数据库时，合理设置PROCESSES参数是十分重要的。但是很多时候由于应用的异常可能导致业务环境的进程数量激增，所以在生产环境中对进程数量进行必要监控是必需的。
7.1.2 操作系统依赖参数
某些参数的有效值或者取值范围依赖或者受限于操作系统，比如MEMORY_TARGET参数，设置Oracle使用的内存大小，该参数的最大值就要受限于物理内存，而且同时受限于系统设置。
下面的错误是经常会遇到的。
SQL*Plus: Release 11.2.0.3.0 Production on Sat Apr 9 03:42:40 2016
Copyright © 1982, 2011, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup
ORA-00845: MEMORY_TARGET not supported on this system
在Linux平台，这种情况一般情况下意味着/dev/shm设置过小。
SQL> create pfile=’/tmp/pfile.ora11g’ from spfile;
File created.
SQL> !grep -i ‘memory_target’ /tmp/pfile.ora11g
*.memory_target=511705088
SQL> !df -h /dev/shm
Filesystem Size Used Avail Use% Mounted on
tmpfs 400M 0 400M 0% /dev/shm
用root用户增大并remount之后，就可以正常启动实例。
SQL> !df -h /dev/shm
Filesystem Size Used Avail Use% Mounted on
tmpfs 600M 0 600M 0% /dev/shm
SQL> startup
ORACLE instance started.
Database mounted.
Database opened.
需要特别注意的是，如果有多个实例，那么其大小要大于所有实例所需要内存的总和。
这一类参数通常被称为操作系统依赖参数。
7.1.3 可变参数
可变参数包含绝大多数潜在影响系统性能的可调整参数，某些可变参数设置的是限制条件，如OPEN_CURSORS；有的参数是设置容量，如DB_CACHE_SIZE等。这类参数通常可以为DBA或最终用户调整，从而产生限制或性能变化，对Oracle至关重要。
7.1.4 不推荐参数
随着版本的更新和新特性的发布，部分参数已经不再推荐使用。对于这类参数，一般情况下还可以设置并生效，但也有部分参数尽管可以设置，但不会产生效果。
可以通过如下查询获得这些参数（Oracle版本11.2.0.3）。
SQL> select name from v$parameter where ISDEPRECATED=‘TRUE’;
NAME
--------------------------------------------------------------------------------
lock_name_space
instance_groups
resource_manager_cpu_allocation
active_instance_count
buffer_pool_keep
buffer_pool_recycle
log_archive_start
standby_archive_dest
log_archive_local_first
parallel_server
parallel_server_instances
在生产环境下使用这类参数需要非常谨慎，因为随着后续版本的发布，这类参数可能变成废弃参数从而根本无法使用。
7.1.5 废弃参数
由于Oracle数据库的参数众多，在新版本中可能废弃很多旧的参数，了解这些废弃参数，明确废弃原因，是DBA需要关注的内容之一。
在Oracle Database 11gR2中，有大约130个参数被废弃。
SQL> select * from v$version where rownum <2;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
SQL> select count(*) from V$OBSOLETE_PARAMETER;
COUNT(*)
----------
131
SQL> select * from V$OBSOLETE_PARAMETER;
NAME ISSPE
spin_count FALSE
use_ism FALSE
lock_sga_areas FALSE
instance_nodeset FALSE
……
这个视图的创建语句如下：
SQL> select view_definition from v$fixed_view_definition
2 where view_name=‘GV$OBSOLETE_PARAMETER’;
VIEW_DEFINITION
-------------------------------------------------------------------------------------
select inst_id,kspponm,decode(ksppoval,0,‘FALSE’,‘TRUE’) from x$ksppo
底层的X$KSPPO是这些废弃参数的来源。
除了以上参数类别，初始化参数通常还有一些其他分类方式：
- 按照修改方式划分，初始化参数又可以分为静态参数和动态参数。其中静态参数只能在参数文件中修改，在重新启动后方能生效；动态参数可以动态调整，调整后通常可以立即生效。
- 按照获取方式不同，初始化参数又可以分为显式参数和隐含参数。显式参数可以通过V$PARAMETER查询得到；而隐含参数通常以’_'开头，必须通过查询系统表方能获得。
比较常用的几个隐含参数有以下几个。
NAME VALUE PDESC
_allow_resetlogs_corruption FALSE allow resetlogs even if it will cause corruption
_offline_rollback_segments offline undo segment list
_corrupted_rollback_segments corrupted undo segment list
总之，虽然分类方式不同，但是参数都是这些，我们更多需要了解的是这些参数的用途。
7.2 参数文件管理和使用
参数文件是一个包含一系列参数及参数对应值的操作系统文件；参数文件有两种类型。
- 初始化参数文件（Initialization Parameters Files）——Oracle9i之前Oracle一直采用PFILE方式存储初始化参数，该文件为文本文件，可以通过文本编辑器手工修改，但无法通过数据库修改。
- 服务器参数文件（Server Parameter Files）——从Oracle 9i开始，Oracle引入的SPFILE文件，该文件为数据格式，不能通过手工修改，但可以通过数据库直接修改。
从操作系统上我们也可以看到这两者的区别，PFILE为ASCII文本文件，SPFILE为数据文件：
[oracle@jumper oracle]$ cd $ORACLE_HOME/dbs
[oracle@jumper dbs]$ file initconner.ora
initconner.ora: ASCII text
[oracle@jumper dbs]$ file spfileconner.ora
spfileconner.ora: data
SPFILE的引入使得对于参数的修改都可以在命令行完成，我们可以彻底告别手工修改初始化参数文件的历史，这就大大减少了人为错误的发生。
使用startup命令启动数据库时，Oracle将会按照以下顺序在默认目录（Windows默认目录为%ORACLE_HOME%\database；Linux/UNIX下默认目录为$ORACLE_HOME/dbs）中搜索参数文件：spfile<ORACLE_SID>.ora，spfile.ora和init<ORACLE_SID>.ora。
当在默认位置创建了SPFILE并重新启动数据库，Oracle会按顺序搜索以上目录的SPFILE。
如果想使用PFILE启动数据库，可以在启动时指定PFILE或者删除SPFILE。通过指定PFILE启动数据库的命令格式类似如下：
SQL> startup pfile=‘E:\Oracle\admin\eyglen\pfile\init.ora’;
不能以同样的方式指定SPFILE，但是可以创建一个包含SPFILE参数的PFILE文件，指向SPFILE。SPFILE是一个自Oracle 9i引入的初始化参数，类似于IFILE参数，用于定义非默认路径下的SPFILE文件。使用时修改PFILE文件内容如下：
#Pfile link to SPFILE
SPFILE= ‘E:\Oracle\Ora9iR2\database\SPFILEEYGLEN.ORA’
7.2.1 参数文件的创建
SPFILE必须由PFILE创建，其语法如图7-1所示。
图7-1
命令CREATE SPFILE需要SYSDBA或者SYSOPER的权限，注意其中的MEMORY选项是从Oracle 11g引入的。例如：
SQL> create spfile from pfile;
默认的，SPFILE会创建到系统默认目录（$ORACLE_HOME/dbs）。如果SPFILE已经存在，那么创建会返回以下错误，这也可以用来判断当前是否使用了SPFILE文件。
SQL> create spfile from pfile;
ERROR 位于第 1 行:
ORA-32002: 无法创建已由例程使用的 SPFILE
从Oracle 11g开始，为了增强参数文件的恢复，一个新的命令被引入用于从当前运行实例创建参数文件，这个命令如下：
create <spfile|pfile> from memory;
这个命令可以使用当前的参数设置在默认位置创建一个SPFILE文件，当然也可以指定一个不同的位置：
SQL> create spfile=’/tmp/spfile.ora’ from memory;
File created.
这一命令简化了我们在某些条件下的参数文件恢复。
当使用DBCA自定义（不使用模板）创建数据库时，在最后一个步骤，选择生成数据库创建脚本，可以将创建数据库所需要执行的脚本保存下来。通过这些脚本，可以进一步研究Oracle数据库的创建过程（当然也可以通过手工执行这些脚本，手工创建数据库），如图7-2所示。
图7-2
以Windows为例，在scripts目录下，通常可以看到这样一些脚本（根据安装选项不同，脚本可能不同）：
C:\oracle\admin\eygle\scripts>dir
2005-01-06 13:23 918 CreateDB.SQL
2005-01-06 13:23 631 CreateDBCatalog.SQL
2005-01-06 13:23 134 CreateDBFiles.SQL
2005-01-06 13:23 781 eygle.bat
2005-01-06 13:23 2,847 init.ora
2005-01-06 13:24 409 postDBCreation.SQL
手工创建过程通常可以通过eygle.bat批处理文件执行开始，系统会根据脚本自动执行创建过程。在前面的章节已经描述过这个创建过程，和本章内容有关的是，这里存在一个init.ora文件（或init.ora.<时间戳> 文件）。这个文件是根据创建数据库之前定义的参数自动生成的。该参数文件被用来在创建过程中启动数据库，通过CreateDB.SQL可以看到这个引用：
startup nomount pfile=“C:\oracle\admin\eygle\scripts\init.ora”;
CREATE DATABASE eygle
MAXINSTANCES 1 MAXLOGHISTORY 1 MAXLOGFILES 5 MAXLOGMEMBERS 3 MAXDATAFILES 100
DATAFILE ‘d:\oradata\eygle\system01.dbf’ SIZE 250M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL
在数据库创建完成之后，Oracle调用 postDBCreation.SQL 脚本来进行一系列的后续处理，最后Oracle通过init.ora文件创建了SPFILE文件。该脚本的内容大致如下：
set echo on
create spfile=‘D:\Oracle\11.2.0\database\spfileeygle.ora’ FROM pfile=‘D:\Oracle\admin\ eygle\scripts\init.ora’;
shutdown immediate;
这就是数据库创建过程中PFILE和SPFILE的交接。建议每个试图深入学习Oracle的人都仔细研究一下自动建库的脚本，深入了解该过程非常有助于学习与领悟Oracle。
除了第一次启动数据库需要PFILE（然后可以根据PFILE创建SPFILE），数据库可以不再需要PFILE，Oracle强烈推荐使用SPFILE，应用其新特性来存储和维护初始化参数设置。
7.2.2 12c create spfile的警示
在12c中，create spfile命令又有了新的参数变更，这个变化是由于一个Bug引入的。通过以下的测试和验证过程，大家会发现新版本中的这个变化，避免在新版本中遭遇陷阱。以下验证环境为Oracle RAC 12.1.0.2.0，先记录当前DB的资源配置。
[oracle@rac12-node1 ~]$ srvctl config database -db rac12
Database unique name:rac12
Database name:rac12
Oracle home:/u01/app/oracle/product/12.1.0
Oracle user:oracle
Spfile:+DATA/rac12/spfilerac12.ora
Password file:+DATA/RAC12/PASSWORD/pwdrac12.276.902472499
Domain:
Start option:open
Stop option:immediate
Database role:PRIMARY
Management policy:AUTOMATIC
Server pools:racpool
Disk Groups:DATA
Mount point paths:
Services:racdb
Type:RAC
Start concurrency:
Stop concurrency:
OSDBA group:dba
OSOPER group:dba
Database instances:
Configured nodes:
Database is policy managed
对于RAC环境，一般都推荐使用共享的SPFILE，方便维护初始化参数。下面的连续测试主要观察命令执行后对这个参数的影响。
首先测试生成PFILE或者SPFILE，同时指定生成文件的位置，请注意后者直接导致了集群参数文件指向的变更。
SQL>create pfile=’/tmp/ffile.ora’ from spfile=’+DATA/rac12/spfilerac12.ora’;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:+DATA/rac12/spfilerac12.ora
SQL>create spfile=’/tmp/ffile.spfile’ from pfile=’/tmp/ffile.ora’;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:/tmp/ffile.spfile
从内存生成PFILE或者SPFILE，同时指定生成文件的位置，后者对于SPFILE同样更新了集群配置。
SQL> create pfile=’/tmp/fmem.ora’ from memory;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:/tmp/ffile.spfile
SQL>create spfile=’/tmp/fmem.spfile’ from memory;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:/tmp/fmem.spfile
从文件生成PFILE或者SPFILE，不指定生成文件的位置。
SQL> create pfile from spfile=‘DATA/rac12/spfilerac12.ora’;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:/tmp/fmem.spfile
SQL>create spfile from pfile=’/tmp/ffile.ora’;
File created
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:+DATA/spfilerac12_1.ora
指定生成文件位置，但源文件默认使用默认位置。
SQL> create pfile=’/tmp/ffile2.ora’ from spfile;
File created.
SQL>!srvctl config database -db rac12|grep -i ‘spfile’
Spfile:+DATA/spfilerac12_1.ora
SQL>create spfile=’/tmp/ffile2.spfile’ from pfile;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:/tmp/ffile2.spfile
生成文件和源文件均使用默认位置。
SQL>create pfile from spfile;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:/tmp/ffile2.spfile
SQL>create spfile from pfile;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:+DATA/spfilerac12_1.ora
通过测试可见每一次生成SPFILE**，都同时更新了**Database******资源配置里面的**SPFILE****设定！
由于这个命令执行时没有任何提示会更新Database资源设定，所以很容易导致SPFILE的设定被更改到某个节点的本地文件系统，这样有可能会导致其他节点在重启动之后找不到指定的SPFILE，从而启动失败。
幸运的是，通常RAC在安装完成后，在初始化参数的默认位置（$ORACLE_HOME/dbs）一般会创建一个PFILE，里面用SPFILE参数指向了共享的SPFILE。
[oracle@rac12-node3 ~] $ cd $ORACLE_HOME/dbs
[oracle@rac12-node3 dbs] $ ls
hc_rac12_3.dat id_rac12_3.dat init.ora initrac12_3.ora
[oracle@rac12-node3 dbs] $ cat initrac12_3.ora
SPFILE=’+DATA/rac12/spfilerac12.ora’
[oracle@rac12-node3 dbs] $
这会如果不知情地执行了之前的创建操作，这会导致部分节点使用不同的SPFILE：
SQL>select INSTANCE_NAME,NAME,VALUE from gvinstance gi
2 where gp.INST_ID=gi.INST_ID and gp.name=‘spfile’;
INSTANCE_NAME NAME VALUE
rac12_3 spfile +DATA/rac12/spfilerac12.ora
rac12_1 spfile /tmp/ffile.spfile
rac12_4 spfile +DATA/rac12/spfilerac12.ora
在MOS网站上搜索，确认如下Bug，Oracle提供了补丁修正：
Bug 18799993 - CREATE SPFILE updates the DB resource by default as of 12.1 （Doc ID 18799993.8）。
在以下Bug描述中，Oracle详细阐述了这个问题，这是一个仅在RAC环境中出现的问题，并在补丁中提供了AS COPY选项。
As of 12c creating an spfile also updates the spfile location in the cluster. This is different to 11.2 behaviour and can affect scripts that create a local SPFILE that is not accessible to other RAC nodes.
Rediscovery Notes After an spfile is created, the spfile location is updated in the cluster. Other nodes may then be unable to access the new spfile.
Workaround None other than be sure to create SPFILE on a shared disk accessible to all nodes.
Note: This fix extends the CREATE SPFILE syntax to add an “AS COPY” option. If ‘AS COPY’ is specified the cluster wide spfile location is not updated.
安装后进行简单测试。
SQL>create spfile=’/tmp/aferpatch_ffile.spfile’ from pfile=’/tmp/ffile.ora’;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:/tmp/aferpatch_ffile.spfile
SQL>create spfile=’/tmp/aferpatch_fmen.spfile’ from memory;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:/tmp/aferpatch_ffile.spfile
SQL>create spfile=’/tmp/aferpatch_ffile2.spfile’ from pfile;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:/tmp/aferpatch_ffile2.spfile
SQL>create spfile from pfile=’/tmp/ffile.ora’;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:/tmp/aferpatch_ffile2.spfile
SQL>create spfile from memory;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:/tmp/aferpatch_ffile2.spfile
SQL>create spfile from pfile;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:/tmp/aferpatch_ffile2.spfile
可以看到有一些改变，现在create spfile from pfile命令只有在指定生成文件路径才会更新Database资源配置，create spfile from memory不再更新Database资源配置。
继续来检查as copy的使用情况。
SQL>create spfile=’/tmp/aferpatch_ffile.spfile’ from pfile=’/tmp/ffile.ora’ as copy;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:/tmp/aferpatch_ffile2.spfile
SQL>create spfile=’/tmp/aferpatch_ffile.spfile’ from pfile as copy;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:/tmp/aferpatch_ffile2.spfile
SQL>create spfile=’/tmp/aferpatch_ffile.spfile’ from memory as copy;
ERROR at line 1:
ORA-009333:SQL command not properly ended
SQL>create spfile from pfile=’/tmp/ffile.ora’ as copy;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:/tmp/aferpatch_ffile2.spfile
SQL>create spfile from pfile as copy;
File created.
SQL>! srvctl config database -db rac12|grep -i ‘spfile’
Spfile:/tmp/aferpatch_ffile2.spfile
SQL>create spfile from memory as copy;
ERROR at line 1:
ORA-00933:SQL command not properly ended
可以看到from memory不支持as copy选项，同时加了as copy选项后，即使指定了spfile生成文件的路径，也不再更新Database资源配置。
通过以上测试和验证过程，得出以下结论。
 create spfile from memory：不支持as copy选项，但是也不再更新Database资源配置。
 create spfile from pfile：在指定生成文件路径而且不加as copy选项时，仍然会更新Database资源配置。
通过这个案例可以看出，一个新的版本变化，会改变很多数据库细节上的行为，如果不关注这些细节，就有可能在运维时遭遇困境。所以当我们使用一个新版本时，需要尽可能关注新特性，并保持对于数据库修正的持续跟踪。
7.3 12c 参数与参数文件新特性
在Oracle Database 12c中，由于PDB的引入，对PDB进行独立的参数管理成为一个现实的需求。CDB中的PDB必须允许进行独立的参数配置与管理。
最基本的，每个独立的PDB都可以有独立的参数设置，所以在底层的X$对象中记录的参数也按照CON_ID进行多条独立存储。通过如下的查询，可以看到针对每个独立的PDB都存在独立的参数设置（针对PDB的查询需要对以前的常用SQL进行适当改写）。
SQL> col ksppinm for a30
SQL> select con_id,ksppinm from x$ksppi where ksppinm=’_allow_resetlogs_corruption’;
CON_ID KSPPINM
1 _allow_resetlogs_corruption
2 _allow_resetlogs_corruption
3 _allow_resetlogs_corruption
7.3.1 参数表的引入
12c中的参数文件是针对CDB的设置，对于PDB的参数设置不记录在SPFILE文件，以下测试过程可以验证。
首先修改一个参数设置。
SQL> select banner from v$version where rownum < 2;
BANNER
--------------------------------------------------------------------------------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
SQL> show con_name
CON_NAME
------------------------------
CDB$ROOT
SQL> alter system set open_cursors=500 container=all;
System altered.
SQL> show parameter spfile
NAME TYPE VALUE
spfile string /u01/app/oracle/product/ga/db_2/dbs/spfilemomo.ora
检查此时的参数文件，可以看到其中记录的修改参数。
SQL> ! strings /u01/app/oracle/product/ga/db_2/dbs/spfilemomo.ora
momo.__data_transfer_cache_size=0
momo.__db_cache_size=721420288
momo.__java_pool_size=16777216
momo.__large_pool_size=33554432
momo.__oracle_base=’/u01/app/oracle’#ORACLE_BASE set from environment
momo.__pga_aggregate_target=570425344
momo.__sga_target=1090519040
momo.__shared_io_pool_size=50331648
momo.__shared_pool_size=251658240
momo.__streams_pool_size=0
*.compatible=‘12.1.0.0.0’
*.control_files=’/u01/app/oracle/oradata/MOMO/controlfile/o1_mf_8qs9wxhs_.ctl’
*.db_block_size=8192
*.db_create_file_dest=’/u01/app/oracle/oradata’
*.db_domain=’’
*.db_name=‘momo’
*.db_recovery_file_dest=’/u01/app/oracle/fast_recovery_area’
*.db_recovery_file_dest_size=10737418240
*.diagnostic_dest=’/u01/app/oracle’
*.dispatchers=’(PROTOCOL=TCP) (SERVICE=momoXDB)’
*.enable_pluggable_database=true
*.memory_target=1584m
*.open_cursors=500
.processes=300
*.remote_login_passwordfile=‘EXCLUSIVE’
*.undo_tablespace=‘UNDOTBS1’
如果修改PDB的参数，其修改并不会记录在参数文件中。
SQL> alter session set container=enmo;
Session altered.
SQL> alter system set open_cursors=2000;
System altered.
SQL> ! strings /u01/app/oracle/product/ga/db_2/dbs/spfilemomo.ora |grep open
*.open_cursors=500
那么对于PDB的参数的修改记录在何处呢？通过跟踪修改过程，可以解析12c中的这个变化。以下是跟踪过程。
SQL> show con_name
CON_NAME
------------------------------
ENMO
SQL> oradeBug setmypid
Statement processed.
SQL> oradeBug EVENT 10046 TRACE NAME CONTEXT FOREVER, LEVEL 12
Statement processed.
SQL> oradeBug TRACEFILE_NAME
/u01/app/oracle/diag/rdbms/momo/momo/trace/momo_ora_18582.trc
SQL> alter system set open_cursors=888;
System altered.
SQL> oradeBug EVENT 10046 trace name context off
Statement processed.
检查跟踪文件可以发现，修改参数最终被转化为对于底层参数表PDB_SPFILE$的插入和更新过程。
=====================
PARSING IN CURSOR #140326162677680 len=33 dep=0 uid=0 oct=49 lid=0 tim=174451122363 hv=2037700194 ad=‘0’ SQLid=‘94vufttwr9pm2’
alter system set open_cur
END OF STMT
PARSE #140326162677680:c=0,e=197,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,plh=0,tim=174451122362
WAIT #140326162677680: nam=‘reliable message’ ela= 92 channel context=3265888440 channel handle=3265759608 broadcast message=3268513048 obj#=-1 tim=174451122576
=====================
PARSING IN CURSOR #140326162675256 len=102 dep=1 uid=0 oct=2 lid=0 tim=174451123080 hv=4009187694 ad=‘bbbcf678’ SQLid=‘0h3wm2vrgfqbf’
insert into pdb_spfile, comment$) values (:1,:2,:3,:4,:5,:6)
END OF STMT
PARSE #140326162675256:c=0,e=422,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=174451123079
BINDS #140326162675256:
Bind#0
oacdty=01 mxl=32(04) mxlc=00 mal=00 scl=00 pre=00
oacflg=10 fl2=0001 frm=01 csi=178 siz=32 off=0
kxsbbbfp=7fffc5764742 bln=32 avl=04 flg=09
value=“momo”
Bind#1
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=00 fl2=1000001 frm=00 csi=00 siz=24 off=0
kxsbbbfp=7fa03b070170 bln=22 avl=06 flg=05
value=655250352
Bind#2
oacdty=01 mxl=32(01) mxlc=00 mal=00 scl=00 pre=00
oacflg=10 fl2=0001 frm=01 csi=178 siz=32 off=0
kxsbbbfp=7fffc57635f8 bln=32 avl=01 flg=09
value="*"
Bind#3
oacdty=01 mxl=32(12) mxlc=00 mal=00 scl=00 pre=00
oacflg=10 fl2=0001 frm=01 csi=178 siz=32 off=0
kxsbbbfp=0bb8bad4 bln=32 avl=12 flg=09
value=“open_cursors”
Bind#4
oacdty=01 mxl=32(03) mxlc=00 mal=00 scl=00 pre=00
oacflg=10 fl2=0001 frm=01 csi=178 siz=32 off=0
kxsbbbfp=7fffc576364c bln=32 avl=03 flg=09
value=“888”
Bind#5
oacdty=01 mxl=32(00) mxlc=00 mal=00 scl=00 pre=00
oacflg=10 fl2=0001 frm=01 csi=178 siz=32 off=0
kxsbbbfp=00000000 bln=32 avl=00 flg=09
PARSING IN CURSOR #140326162672080 len=106 dep=1 uid=0 oct=6 lid=0 tim=174451133817 hv=502170820 ad=‘b8a9e008’ SQLid=‘d8cf9hcfyx164’
**update pdb_spfile=:5, comment$=:6 where name=:1 and pdb_uid=:2 and db_uniq_name=:3 and sid=:4
END OF STMT
PARSE #140326162672080:c=0,e=305,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=174451133816
BINDS #140326162672080:
Bind#0
oacdty=01 mxl=32(03) mxlc=00 mal=00 scl=00 pre=00
oacflg=10 fl2=0001 frm=01 csi=178 siz=32 off=0
kxsbbbfp=7fffc576364c bln=32 avl=03 flg=09
value=“888”
Bind#1
oacdty=01 mxl=32(00) mxlc=00 mal=00 scl=00 pre=00
oacflg=10 fl2=0001 frm=01 csi=178 siz=32 off=0
kxsbbbfp=00000000 bln=32 avl=00 flg=09
Bind#2
oacdty=01 mxl=32(12) mxlc=00 mal=00 scl=00 pre=00
oacflg=10 fl2=0001 frm=01 csi=178 siz=32 off=0
kxsbbbfp=0bb8bad4 bln=32 avl=12 flg=09
value=“open_cursors”
Bind#3
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=00 fl2=1000001 frm=00 csi=00 siz=24 off=0
kxsbbbfp=7fa03b109338 bln=22 avl=06 flg=05
value=655250352
Bind#4
oacdty=01 mxl=32(04) mxlc=00 mal=00 scl=00 pre=00
oacflg=10 fl2=0001 frm=01 csi=178 siz=32 off=0
kxsbbbfp=7fffc5764742 bln=32 avl=04 flg=09
value=“momo”
Bind#5
oacdty=01 mxl=32(01) mxlc=00 mal=00 scl=00 pre=00
oacflg=10 fl2=0001 frm=01 csi=178 siz=32 off=0
kxsbbbfp=7fffc57635f8 bln=32 avl=01 flg=09
value="*"
也就是说，在Oracle 12c中，通过增加参数表PDB_SPFILE$，Oracle实现了对于不同PDB的参数设置区分。这些非默认的参数设置被记录在CDB中。
SQL> alter session set container=cdb$root;
Session altered.
SQL> select db_uniq_name,name,value$ from pdb_spfile$;
DB_UNIQ_NAME NAME VALUE$
momo open_cursors 888
7.3.2 参数表在PDB启动中的作用
初始化参数在数据库实例启动时发挥作用，而对于PDB来说，参数表中的参数在PDB打开时发挥作用，跟踪PDB的Open过程，可以从后台看到PDB_SPFILE$的调用过程。
如下步骤实现PDB的打开过程跟踪。
SQL> startup
ORACLE instance started.
Database mounted.
Database opened.
SQL> oradeBug setmypid
Statement processed.
SQL> oradeBug EVENT 10046 trace name context forever,level 12
Statement processed.
SQL> oradeBug tracefile_name
/u01/app/oracle/diag/rdbms/momo/momo/trace/momo_ora_18461.trc
SQL> alter pluggable database all open;
Pluggable database altered.
SQL> oradeBug event 10046 trace name context off;
Statement processed.
检查跟踪文件，可以看到该过程首先执行的即是参数表信息的读取，由此可见，参数表和参数文件发挥了完全类似的功能。
=====================
PARSING IN CURSOR #140418418360024 len=89 dep=1 uid=0 oct=3 lid=0 tim=173430521346 hv=1466406983 ad=‘ba282d08’ SQLid=‘4sbjpw1bqg627’
select name, value, sid from pdb_spfile$ where db_uniq_name=:1 and pdb_uid=:2
END OF STMT
PARSE #140418418360024:c=0,e=255,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=173430521346
BINDS #140418418360024:
Bind#0
oacdty=01 mxl=32(04) mxlc=00 mal=00 scl=00 pre=00
oacflg=10 fl2=0001 frm=01 csi=178 siz=56 off=0
kxsbbbfp=7fb5b6124d60 bln=32 avl=04 flg=05
value=“momo”
Bind#1
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=00 fl2=1000001 frm=00 csi=00 siz=0 off=32
kxsbbbfp=7fb5b6124d80 bln=22 avl=06 flg=01
7.4 参数修改及重置
用户可以通过ALTER SYSTEM或者导入、导出来更改SPFILE的内容。修改参数的完整命令如下：
alter system set <parameter_name> =
SCOPE参数有三个可选值：MEMORY、SPFILE和BOTH。
 MEMORY：只改变当前实例运行（对于动态参数而言），重新启动数据库后失效。
 SPFILE：只改变SPFILE的设置，不改变当前实例运行，重新启动数据库后生效。
 BOTH：同时改变实例及SPFILE，当前更改立即生效，重新启动数据库后仍然有效，对于静态参数不能使用这个选项修改。
关于SID还需要注意的一点是：如果命令中没有指定SID，那么意味着实例名为’*’。
针对RAC环境，ALTER SYSTEM还可以指定SID参数，对不同实例进行不同设置。但是需要注意的是，即使指定的实例名不存在，系统也不会报任何的错误，这点对单实例同样适用。
[oracle@rac12-node1 ~]$ export ORACLE_SID=rac12_1
[oracle@rac12-node1 ~]$ SQLplus “/as sysdba”
SQL*Plus: Release 12.1.0.2.0 Production on Sun Apr 10 08:30:12 2016
Copyright © 1982, 2014, Oracle. All rights reserved.
SQL> alter system set open_cursors=500 sid=‘noexist’;
System altered.
以下通过简单的例子来看一下SCOPE参数的几个用法。
1．SCOPE=MEMORY
修改当前实例的DB_CACHE_ADVICE参数为OFF：
SQL> show parameter db_cache_ad
NAME TYPE VALUE
db_cache_advice string ON
SQL> alter system set db_cache_advice=off scope=memory;
System altered.
SQL> show parameter db_cache_ad
NAME TYPE VALUE
db_cache_advice string OFF
如果观察alert_
Wed Apr 26 21:18:57 2006
ALTER SYSTEM SET db_cache_advice=‘OFF’ SCOPE=MEMORY;
由于修改的参数没有写入参数文件，如果重新启动数据库，这个更改将会丢失。
SQL> startup force;
SQL> show parameter db_cache_ad
NAME TYPE VALUE
db_cache_advice string ON
也就是说SCOPE=MEMORY的修改影响，不会跨越一次数据库的重新启动。
当使用MEMORY选项时，要明确地知道这样的修改仅对当前实例有效，忽略这一点则可能遭遇后续的故障。以下是实际生产系统中关于SPFILE的一个案例问题，数据库在重新启动时无法正常启动，检查发现UNDO表空间丢失。
此次故障诊断，首先检查告警日志文件，发现其中包含如下错误信息。
Thu Apr 1 11:11:28 2004
Errors in file /oracle/admin/gzhs/udump/gzhs_ora_27781.trc:
ORA-30012: undo tablespace ‘UNDOTBS1’ does not exist or of wrong type
Thu Apr 1 11:11:28 2004
Error 30012 happened during db open, shutting down database
USER: terminating instance due to error 30012
Instance terminated by USER, pid = 27781
ORA-1092 signalled during: alter database open…
在告警日志末尾显示了数据库在OPEN状态因为错误而异常终止。最后出错的错误号是ORA-30012。该错误的含义如下。
[oracle@jumper oracle]$ oerr ora 30012
30012, 00000, “undo tablespace ‘%s’ does not exist or of wrong type”
// *Cause: the specified undo tablespace does not exist or of the
// wrong type.
// *Action: Correct the tablespace name and reissue the statement.
这说明是UNDO表空间不存在导致出现问题。既然是UNDO表空间丢失，接下来需要确认相关数据文件，看UNDO表空间数据文件是否存在。
bash-2.03$ cd /u01/ oradata/gzhs
bash-2.03$ ls –l UNDO
total 55702458
-rw-r----- 1 oracle dba 1073750016 Apr 1 11:44 UNDOTBS2.dbf
通过检查发现存在文件UNDOTBS2.dbf，大小约为1GB。
既然存在一个UNDO表空间文件，用户又没有主动执行删除操作，那么极其可能是参数设置出了问题，将数据库启动到MOUNT状态，检查当前参数设置。
SQL> startup mount;
ORACLE 例程已经启动。
数据库装载完毕。
SQL> show parameter undo
NAME TYPE VALUE
undo_management string AUTO
undo_retention integer 10800
undo_suppress_errors boolean FALSE
undo_tablespace string UNDOTBS1
SQL> show parameter spfile
NAME TYPE VALUE
spfile string
检查发现系统没有使用SPFILE，初始化参数设置的UNDO表空间为UNDOTBS1，数据库中存在的UNDO文件为UNDOTBS2.dbf。由此可以判定，参数设置可能和数据库的实际情况不符。
告警日志文件中记录了对于数据库重要操作的信息，可以从中查找对于UNDO表空间的操作。除了数据库创建时建立的UNDOTBS1，我们发现了创建UNDOTBS2的记录信息。
Wed Mar 24 20:20:58 2004
/* OracleOEM */ CREATE UNDO TABLESPACE “UNDOTBS2” DATAFILE ‘/u01/oradata/gzhs/UNDOTBS2.dbf’ SIZE 1024M AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED
通过修改参数指定了新的UNDO表空间。
Wed Mar 24 20:24:25 2004
ALTER SYSTEM SET undo_tablespace=‘UNDOTBS2’ SCOPE=MEMORY;
问题就在这里，创建了新的UNDO表空间以后，因为使用的是PFILE文件，切换表空间的修改只对当前实例生效，操作人员忘记了修改PFILE文件。
如果使用SPFILE，默认的修改范围是BOTH，会同时修改SPFILE文件，就可以避免以上问题的出现。
随后发现删除UNDOTBS1的信息。
Wed Mar 24 20:25:01 2004
/* OracleOEM */ DROP TABLESPACE “UNDOTBS1” INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS
Wed Mar 24 20:25:03 2004
Deleted file /u01/oradata/gzhs/undotbs01.dbf
Completed: /* OracleOEM */ DROP TABLESPACE “UNDOTBS1” INCLUDI
这样再次重新启动数据库时，问题出现了，PFILE中定义的UNDOTBS1找不到了，而且操作时间较久，没人能回忆起来。对于这个案例，找到了问题的根源，解决起来就简单了，修改PFILE参数文件，就可以启动数据库解决问题。在这里我们可以看到，使用SPFILE可以免去手工修改PFILE文件的麻烦，减少犯错的可能。
2．SCOPE=SPFILE
当指定SCOPE=SPFILE时，当前实例运行不受影响：
SQL> alter system set db_cache_advice=off scope=spfile;
System altered.
SQL> show parameter db_cache_ad
NAME TYPE VALUE
db_cache_advice string ON
同样可以从告警日志文件中看到这个修改：
Wed Apr 26 21:24:02 2006
ALTER SYSTEM SET db_cache_advice=‘OFF’ SCOPE=SPFILE;
这个修改将在下次数据库启动后生效：
SQL> startup force;
SQL> show parameter db_cache_ad
NAME TYPE VALUE
db_cache_advice string OFF
但需要知道的是，对于静态参数，只能指定SCOPE=SPFILE进行修改。通过SCOPE=SPFILE修改的参数，虽然对当前实例无效，但是其参数值可以从V$SPPARAMETER视图中查询得到：
SQL> show parameter db_cache_advice
NAME TYPE VALUE
db_cache_advice string OFF
SQL> alter system set db_cache_advice=on scope=spfile;
System altered.
SQL> select name,value from v$spparameter where name=‘db_cache_advice’;
NAME VALUE
db_cache_advice ON
SQL> show parameter db_cache_ad
NAME TYPE VALUE
db_cache_advice string OFF
3．SCOPE = BOTH
使用BOTH选项实际上等同于不带参数的ALTER SYSTEM语句。
SQL> alter system set db_cache_advice=off scope=both;
System altered.
SQL> alter system set db_cache_advice=off;
System altered.
SQL> show parameter db_cache_ad
NAME TYPE VALUE
db_cache_advice string OFF
在告警日志文件中可以看到如下信息：
Wed Apr 26 21:28:21 2006
ALTER SYSTEM SET db_cache_advice=‘OFF’ SCOPE=BOTH;
Wed Apr 26 21:28:28 2006
ALTER SYSTEM SET db_cache_advice=‘OFF’ SCOPE=BOTH;
注意到不带SCOPE参数和SCOPE=BOTH实际上是等价的。但是如果修改静态参数，那么需要指定SPFILE参数，不能指定BOTH参数，否则数据库将会报错。需要注意的一种情况是，如果数据库以PFILE启动，那么因为SPFILE无法使用，这个时候SCOPE=MEMORY是唯一选项，也意味着静态参数无法通过命令进行修改。
当我们想恢复某个参数为默认值时，可以使用如下命令：
alter system reset parameter <scope=memory|spfile|both> sid=’sid|*’
该命令通常用于RAC环境中。在单实例环境中，在Oracle10g之前，需要指定sid=’*’ 来reset一个参数，Oracle将从SPFILE文件中去除该参数。
[oracle@jumper dbs]$ strings spfileconner.ora |grep open
*.open_cursors=150
[oracle@jumper dbs]$ SQLplus “/ as sysdba”
SQL> alter system reset open_cursors scope=spfile sid=’*’;
System altered.
[oracle@jumper dbs]$ strings spfileconner.ora |grep open
可以看到，reset之后SPFILE文件中不再存在OPEN_CURSORS参数。
对于修改SPFILE，需要清楚地认识到一点：仅仅修改当前实例SPFILE里面对应实例的对应参数（如果不指定实例名则实例名为’*’），如果找不到对应项，则报错。
SQL> alter system reset open_cursors;
System altered.
SQL> alter system reset open_cursors;
ERROR at line 1:
ORA-32010: cannot find entry to delete in SPFILE
7.4.1 解决参数文件的修改错误
在使用SPFILE之后，可能会遇到一些不同以往的错误。比如修改了错误的参数导致数据库无法启动，手工修改SPFILE导致参数文件损坏。
了解参数的优先级和生效原则，就可以就此修改和绕过错误：
 实例级别的参数级别高于数据库层面的参数。即只有当实例级别未做设置时，在数据库级别的同一参数才会生效。
 级别相同，那么后面出现的参数生效。
下面介绍参数修改错误常见问题的处理办法。比如修改SGA_MAX_SIZE超过系统最大内存数量：
SQL> alter system set sga_max_size=5G scope=spfile;
System altered.
那么下次启动，内存不足，数据库是无法启动的，数据库出现ORA-27102号错误：
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORA-27102: out of memory
如果是在Linux/UNIX上，可以在实例未启动时连接，创建PFILE，然后手工修改PFILE，用PFILE启动数据库即可。
[oracle@jumper oracle]$ SQLplus “/ as sysdba”
Connected to an idle instance.
SQL> create pfile from spfile;
File created.
也可以编辑一个参数文件，位置在$ORACLE_HOM/dbs（Windows为database目录）下，包含如下两行。
[oracle@test126 dbs]$ cat initeygle.ora
SPFILE=’/opt/oracle/product/10.2.0/dbs/spfileeygle.ora’
sga_max_size=1073741824
第一行指向SPFILE，第二行写上出错的参数，给一个正确的值。这个值在实例启动时会覆盖之前错误的设置，然后就可以使用这个文件启动数据库实例了。
SQL> startup pfile=$ORACLE_HOME/dbs/initeygle.ora
ORACLE instance started.
Database mounted.
Database opened.
7.4.2 通过event事件来跟踪对参数文件的修改
Events事件是Oracle的重要诊断工具及问题解决办法，通常需要通过Events设置来屏蔽或者更改Oracle的行为。下面我们来看一下怎样修改SPFILE，增加Events事件设置。
SQL> alter system set event=‘10841 trace name context forever’ scope=spfile;
System altered.
SQL> startup force;
SQL> show parameter event
NAME TYPE VALUE
event string 10841 trace name context forever
10841事件是用于解决Oracle 9i中JDBC Thin Driver问题的一个方法，如果你的alert.log文件中出现以下错误提示。
Wed Jan 7 17:17:08 2004
Errors in file /opt/oracle/admin/phsdb/udump/phsdb_ora_1775.trc:
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
Wed Jan 7 17:17:18 2004
Errors in file /opt/oracle/admin/phsdb/udump/phsdb_ora_1777.trc:
ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
那么你很可能是遇到了Bug: 1725012。通过设置以上事件，可以屏蔽和解决这个ORA-00600错误，具体你可以参考Metalink相关文档。
如果想取消event参数设置，同样可以采用reset参数的方法。
SQL> show parameter event
NAME TYPE VALUE
event string 10046 trace name context forever,level 12
SQL> alter system reset event scope=spfile sid=’*’;
System altered.
SQL> startup force;
SQL> show parameter event
NAME TYPE VALUE
event string
7.5 参数的查询
对于数据库设置的初始化参数，有很多查询和获取方法，以下由简入繁重点阐述查询和获得参数设置的方法。
7.5.1 参数查询的基本方式
Oracle提供了多种可以查询初始化参数的方法，例如在SQL*Plus中通过show parameters，show spparameters查看，或者查询vparameter等。其中，show spparameters是11g中的新特性，直观地显示vspparameter中参数的值，show parameters的结果来自于v$parameter。
SQL> show parameters sga
NAME TYPE VALUE
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 900M
sga_target big integer 900M
SQL> select name,value from v$parameter where name like ’%SGA%’;
NAME TYPE VALUE
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 900M
sga_target big integer 900M
使用SQL_TRACE跟踪当前会话，可以获得show parameters的内部操作，跟踪大致步骤如下。
alter session set SQL_trace=true;
show parameters sga
alter session set SQL_trace=false
找到跟踪文件，可以发现SQL*Plus的show parameters命令的本质是通过如下一条SQL查询得到的数据库参数。
SELECT NAME NAME_COL_PLUS_SHOW_PARAM,DECODE(TYPE,1,‘boolean’,2,‘string’,3,
‘integer’,4,‘file’,5,‘number’, 6,‘big integer’, ‘unknown’) TYPE,
DISPLAY_VALUE VALUE_COL_PLUS_SHOW_PARAM
FROM V$PARAMETER
WHERE UPPER(NAME) LIKE UPPER(’%sga%’) ORDER BY NAME_COL_PLUS_SHOW_PARAM,ROWNUM
show parameters既然是从VPARAMETER视图来查询参数设置，那么对应视图GVPARAMETER的定义就决定了能够获得的内容输出。
通过GVPARAMETER视图的创建语句，我们可以观察到，这个视图实际上是建立在两个底层数据字典表XKSPPI和X$KSPPCV之上的。
通过以下查询我们可以从内部表直接获得所有参数及其描述信息：
SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.KSPPDESC PDESC
FROM SYS.xksppcv y
WHERE x.indx = y.indx
AND x.ksppinm LIKE ‘%&par%’;
汇总Oracle获取初始化参数方法：SHOW PARAMETERS、SHOW SPPARAMETERS、CREATE PFILE、VPARAMETER、VPARAMETER2、VSYSTEM_PARAMETER、VSYSTEM_ PARAMETER2、V$SPPARAMETER。
（1）SHOW PARAMETERS是SQL*Plus工具提供的查询初始化参数的方法，用于查询当前会话生效的初始化参数。
（2）SHOW SPPARAMETERS也是SQL*Plus工具提供的方法，用于查询当前会话生效的SPFILE参数包含的初始化参数，这个命令在11g以后SQLplus版本中有效。
（3）CREATE PFILE命令可以将SPFILE中或当前内存中设置的初始化文件保存到PFILE文件中，然后可以通过文本编辑工具直观地看到SPFILE中或当前内存中设置了哪些初始化参数。这种方法虽然看上去比较麻烦，但是列出的参数都是用户设置的参数，所有默认值的参数并不会列出来，因此看到的结果更直观。在11g以后的版本允许CREATE PFILE FROM MEMORY。
（4）V$PARAMETER视图提供了当前会话可见的初始化参数的设置，可以像查询RAC数据库的所有实例的设置。
 VPARAMETER2视图和VPARAMETER相似，唯一的区别在于对于包括多值的初始化参数，从这个视图会返回多条记录，每条记录对应一个值。同样的，对于RAC环境可以查询GV$PARAMETER2视图。
（5）VSYSTEM_PARAMETER视图记录当前实例生效的初始化参数设置。注意这里是实例生效而不是会话生效。同样，GVSYSTEM_PARAMETER则包含了所有实例生效的初始化参数信息。
 VSYSTEM_PARAMETER2视图与VSYSTEM_PARAMETER视图的关系类似于VPARAMETER2视图与VPARAMETER视图的关系，都是对于包含多个值的参数采用了分行处理的方式。
（6）V$SPPARAMETER记录了来自SPFILE文件中初始化参数。如果SPFILE文件中没有设置参数，则字段ISSPECIFIED对应的值为FALSE。同样可以查询GVSPPARAMETER参数来显示RAC环境所有实例的设置。
按照参数的生效级别分类
按照参数的生效级别分类，可以将参数分为：当前session级别参数、当前system参数和重启生效参数。
（1）session级别的视图：vparameter、gvparameter. vparameter2和gvparameter2。
 vparameter显示的是当前session级的参数。如果没有使用alter session单独设置当前session的参数值，每一个新Session都是从 vsystem_parameter上取得系统的当前值而产生Session的vparameter view。与vparameter之间的区别则在于v$parameter2把LIST的值分开来了，一行变多行数据，用ORDINAL来指示相对的位置。
 session级别的参数的优先级最高，可以通过alter session改变当前会话的动态初始化参数值。
（2）system级别的视图：vsystem_parameter、vsystem_parameter、vsystem_parameter4、gvsystem_parameter、gvsystem_parameter2和gvsystem_parameter4。
 system级别即当前实例生效的参数。修改system/实例级别的参数一般使用alter system set scope=memory/both命令。同样，当只用scope=memory时，只能修改动态初始化参数。
 通常情况下，vparameter与vsystem_parameter查询的的值相同，但若使用了延迟参数defer修改参数，则vparameter的查询结果为当前会话的值，而vsystem_parameter查询的结果则针对所有新建的连接生效。另外vsystem_parameter4记录的是当前数据库级别所有用户设置的初始化参数。当使用create pfile/spfile from memory生成参数文件时，此时参数来源于vsystem_parameter4。
（3）重启生效参数视图：vspparameter，gvspparameter。
 vspparameter显示的就是保存在spfile中的参数值（scope=both或者spfile），记录了来自SPFILE文件中初始化参数。如果在SPFILE文件中没有设置参数，则字段ISSPECIFIED对应的值为FALSE。同样可以查询GVSPPARAMETER参数来显示RAC环境所有实例的设置。
7.5.2 参数值的可选项
Oracle的很多参数具有多个不同的可选值，可以通过V$PARAMETER_VALID_VALUES来查询，例如以下查询获得CURSOR_SHARING参数的3 个可选设置。
SQL> select * from V$PARAMETER_VALID_VALUES where name like ‘%cursor%’;
NUM NAME ORDINAL VALUE ISDEFAULT
901 cursor_sharing 1 FORCE FALSE
901 cursor_sharing 2 EXACT TRUE
901 cursor_sharing 3 SIMILAR FALSE
这个视图是基于XKSPVLD_VALUES建立起来的，可以通过查询X视图直接获得这些设置选项。
SQL> SELECT
2 INST_ID,
3 PARNO_KSPVLD_VALUES pvalid_par#,
4 NAME_KSPVLD_VALUES pvalid_name,
5 VALUE_KSPVLD_VALUES pvalid_value,
6 DECODE(ISDEFAULT_KSPVLD_VALUES, ‘FALSE’, ‘’, ‘DEFAULT’ ) pvalid_default
7 FROM X$KSPVLD_VALUES
8 WHERE LOWER(NAME_KSPVLD_VALUES) LIKE LOWER(’%&1%’)
9 ORDER BY
10 pvalid_par#,pvalid_default,pvalid_Value；
Enter value for 1: cursor
INST_ID PAR# PARAMETER VALUE DEFAULT
1 901 cursor_sharing EXACT DEFAULT
1 cursor_sharing FORCE
1 cursor_sharing SIMILAR
1 1003 _optimizer_extended_cursor_sharing NONE
1 _optimizer_extended_cursor_sharing UDO
当修改某些参数提供的参数值出现错误时，数据库会将可选的正确参数值抛出，也可以使用这个方法获得参数的可选值，以下测试返回了两个常见参数的设置值。
SQL> alter system set optimizer_features_enable=’’;
ERROR at line 1:
ORA-00096: invalid value for parameter optimizer_features_enable, must be from
among 12.1.0.1.1, 12.1.0.1, 11.2.0.4, 11.2.0.3, 11.2.0.2, 11.2.0.1, 11.1.0.7,
11.1.0.6, 10.2.0.5, 10.2.0.4, 10.2.0.3, 10.2.0.2, 10.2.0.1, 10.1.0.5, 10.1.0.4,
10.1.0.3, 10.1.0, 9.2.0.8, 9.2.0, 9.0.1, 9.0.0, 8.1.7, 8.1.6, 8.1.5, 8.1.4,
8.1.3, 8.1.0, 8.0.7, 8.0.6, 8.0.5, 8.0.4, 8.0.3, 8.0.0
SQL> alter system set cursor_sharing=’’;
ERROR at line 1:
ORA-00096: invalid value for parameter cursor_sharing, must be from among SIMILAR, EXACT, FORCE
7.6 不同查询方法之间的区别
获取参数的方法很多，但各种方法之间有很大的区别。
7.6.1 VPARAMETER和VPARAMETER2的区别
首先看一下VPARAMETER和VPARAMETER2的区别，这个区别同样适用于VSYSTEM_ PARAMETER和VSYSTEM_PARAMETER2。
SQL> SELECT NAME, VALUE FROM V$PARAMETER
2 MINUS
3 SELECT NAME, VALUE FROM V$PARAMETER2;
NAME VALUE
control_files E:\ORACLE\ORADATA\YTK102\CONTROL01.CTL, E:\ORACLE\
ORADATA\YTK102\CONTROL02.CTL, E:\ORACLE\ORADATA\YTK102\CONTROL03.CTL
SQL> SELECT NAME, VALUE FROM V$PARAMETER2
2 MINUS
3 SELECT NAME, VALUE FROM V$PARAMETER;
NAME VALUE
control_files E:\ORACLE\ORADATA\YTK102\CONTROL01.CTL
control_files E:\ORACLE\ORADATA\YTK102\CONTROL02.CTL
control_files E:\ORACLE\ORADATA\YTK102\CONTROL03.CTL
7.6.2 VPARAMETER和VSYSTEM_PARAMETER的区别
一般在查询初始化参数的时候都习惯性地使用SHOW PARAMETER，也就是查询V$PARAMETER视图，但有时这样得到的结果并不准确。
SQL> show parameter query_rewrite_enabled
NAME TYPE VALUE
query_rewrite_enabled string TRUE
SQL> select name, value
2 from v$parameter where name = ‘query_rewrite_enabled’;
NAME VALUE
query_rewrite_enabled TRUE
SQL> select name, value
2 from v$system_parameter where name = ‘query_rewrite_enabled’;
NAME VALUE
query_rewrite_enabled TRUE
此时如果在会话级修改初始化参数query_rewrite_enabled。
SQL> alter session set query_rewrite_enabled = false;
会话已更改。
SQL> show parameter query_rewrite_enabled
NAME TYPE VALUE
query_rewrite_enabled string FALSE
SQL> select name, value
2 from v$parameter where name = ‘query_rewrite_enabled’;
NAME VALUE
query_rewrite_enabled FALSE
SQL> select name, value
2 from v$system_parameter where name = ‘query_rewrite_enabled’;
NAME VALUE
query_rewrite_enabled TRUE
可以看到，show parameter和查询vparameter视图的结果都是FALSE，而刚才做的修改只是会话级，并没有修改系统的初始化参数。VPARAMETER视图反映的是初始化参数在当前会话中生效的值，而V$SYSTEM_PARAMETER反映的才是实例级上的初始化参数。
再来看延迟参数修改的情况。
SQL> select name, value from v$parameter where name = ‘recyclebin’;
NAME VALUE
recyclebin on
SQL> select name, value from v$system_parameter where name = ‘recyclebin’;
NAME VALUE
recyclebin on
SQL> alter system set recyclebin = off deferred scope = memory;
系统已更改。
SQL> select name, value from v$parameter where name = ‘recyclebin’;
NAME VALUE
recyclebin on
SQL> select name, value from v$system_parameter where name = ‘recyclebin’;
NAME VALUE
recyclebin OFF
结果和前面的恰好反过来，vparameter视图中的结果没有改变，而vsystem_parameter视图的结果变成了OFF。这是因为延迟修改对数据库中当前存在的会话不生效，因此反映当前会话情况的vparameter视图结果不变。而对于系统而言，初始化参数已经改变，所有新建会话的参数也会改变，所以vsystem_parameter视图的结果发生了改变。
SQL> CONN YANGTK/YANGTK@YTK111
已连接。
SQL> select name, value from v$parameter where name = ‘recyclebin’;
NAME VALUE
recyclebin OFF
SQL> select name, value from v$system_parameter where name = ‘recyclebin’;
NAME VALUE
recyclebin OFF
根据这两个例子，利用VPARAMETER视图获取系统的启动初始化参数是不准确的，应该从VSYSTEM_PARAMETER视图来获取。Oracle在视图V$SYSTEM_PARAMETER中提供了一个列ISDEFAULT，表示当前设置的值是否是数据库的默认值。
SQL> select name, value, isdefault
2 from v$system_parameter where name = ‘open_cursors’;
NAME VALUE ISDEFAULT
open_cursors 400 FALSE
SQL> select isdefault, count(*)
2 from v$system_parameter group by isdefault;
ISDEFAULT COUNT(*)
TRUE 267
FALSE 22
根据这个结果可以看到，数据库中绝大部分的初始化参数设置都是默认值。
SQL> select name, value, isdefault
2 from v$system_parameter where name = ‘undo_retention’;
NAME VALUE ISDEFAULT
undo_retention 900 TRUE
SQL> select sid, name, value
2 from v$spparameter where name = ‘undo_retention’;
SID NAME VALUE
* undo_retention
SQL> alter system set undo_retention = 900;
系统已更改。
SQL> select name, value, isdefault
2 from v$system_parameter where name = ‘undo_retention’;
NAME VALUE ISDEFAULT
undo_retention 900 TRUE
SQL> select sid, name, value
2 from v$spparameter where name = ‘undo_retention’;
SID NAME VALUE
* undo_retention 900
对于手工设置的初始化参数与系统默认值相同的情况，通过vsystem_parameter视图是无法区分的。实际上查询VSYSTEM_PARAMETER4视图就可以获取到所有用户设置的初始化参数。
当数据库执行CREATE PFILE FROM MEMORY命令时，Oracle创建PFILE的数据源是V$SYSTEM_PARAMETER4视图。
7.6.3 GVSPPARAMETER和VSPPARAMETER的区别
这里有一个问题：GVSPPARAMETER是否有意义。因为VSPPARAMETER参数本身包含了SID列，SPFILE中本身包含了所有实例的设置，那么查询GV$SPPARAMETER视图是否意义不大呢？其实不然。
因为RAC的各个节点可以使用统一的SPFILE启动，同样也可以选择不同的SPFILE进行启动，这时GV$SPPARAMETER视图中获取的结果，才是各个实例SPFILE中设置的结果。
这样说比较难以理解，下面来看一个简单的例子。
SQL> select inst_id, name, value
2 from gv$system_parameter where name = ‘open_cursors’;
INST_ID NAME VALUE
1 open_cursors 600
2 open_cursors 400
SQL> select sid, name, value
2 from v$spparameter where name = ‘open_cursors’;
SID NAME VALUE
* open_cursors 300
test1 open_cursors 500
test2 open_cursors 700
SQL> select inst_id, sid, name, value
2 from gv$spparameter where name = ‘open_cursors’;
INST_ID SID NAME VALUE
1 * open_cursors 300
1 test1 open_cursors 500
1 test2 open_cursors 700
2 * open_cursors 300
2 test1 open_cursors 500
2 test2 open_cursors 700
SQL> select inst_id, name, value
2 from gv$system_parameter where name = ‘spfile’;
INST_ID NAME VALUE
1 spfile +DATA/test/spfiletest.ora
2 spfile +DATA/test/spfiletest.ora
由内存中参数创建SPFILE，并利用新建的SPFILE启动当前实例。
SQL> create spfile=’/export/home/oracle/spfiletest1.ora’ from memory;
文件已创建。
SQL> host
$ vi /export/home/oracle/inittest1.ora
“/export/home/oracle/inittest1.ora” [New file]
spfile=/export/home/oracle/spfiletest1.ora
“/export/home/oracle/inittest1.ora” [New file] 2 lines, 44 characters
$ exit
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup pfile=/export/home/oracle/inittest1.ora
ORACLE 例程已经启动。
数据库装载完毕。
数据库已经打开。
检查spfile中的设置。
SQL> select inst_id, name, value
2 from gv$system_parameter where name = ‘spfile’;
INST_ID NAME VALUE
1 spfile /export/home/oracle/spfiletest1.ora
2 spfile +DATA/test/spfiletest.ora
SQL> select inst_id, name, value
2 from gv$system_parameter where name = ‘open_cursors’;
INST_ID NAME VALUE
1 open_cursors 600
2 open_cursors 400
SQL> select sid, name, value
2 from v$spparameter where name = ‘open_cursors’;
SID NAME VALUE
test1 open_cursors 600
test2 open_cursors 400
SQL> select inst_id, sid, name, value
2 from gv$spparameter where name = ‘open_cursors’;
INST_ID SID NAME VALUE
2 * open_cursors 300
2 test1 open_cursors 500
2 test2 open_cursors 700
1 test1 open_cursors 600
1 test2 open_cursors 400
可以看到，由于两个实例采用了不同的SPFILE，导致两个实例上设置的对方实例的初始化参数值，与对方实例上当前设置值不符。
在上面的例子中，两个实例上真正的参数设置查询方式如下：
SQL> select inst_id, sid, name, value
2 from gv$spparameter
3 where name = ‘open_cursors’ and substr(sid, -1) = to_char(inst_id);
INST_ID SID NAME VALUE
2 test2 open_cursors 700
1 test1 open_cursors 600
7.7 RAC 下参数的维护
在RAC环境下，由于多节点不同实例在启动时都需要依赖参数文件，所以其管理更加复杂。本节就RAC下参数文件管理进行阐述。
7.7.1 RAC下共享spfile
RAC环境下数据库在启动时，首先尝试寻找Cluster里面Database资源的Spfile配置选项。如果找不到对应的文件，那么继续按照单实例的寻找顺序在默认位置查找。
建议在RAC环境下使用共享的SPFILE，并在默认位置保留一个PFILE，里面通过SPFILE参数指向共享的SPFILE。默认在RAC安装配置完成，就自动生成了一个PFILE文件。
下面是RAC环境中一个参数文件的设置范例。
[oracle@raclinux1 ~]$ cd $ORACLE_HOME/dbs
[oracle@raclinux1 dbs]$ more initRACDB1.ora
SPFILE=’+MY_DG2/RACDB/spfileRACDB.ora’
在此环境中，需要谨慎使用create spfile from pfile的命令，很多朋友因为草率地执行这样的操作而导致数据库故障。
在ASM或RAC环境中，通常的init
7.7.2 使用ASM存储参数文件
在ASM环境中，参数文件可以存储在ASM磁盘组上，而在Oracle RAC环境中，默认使用存储在ASM上的参数文件，在维护RAC环境的参数文件时要格外谨慎。
以下是一个测试过程，用于指导大家如何将参数文件转移到ASM存储并使之生效。
首先检查参数文件的位置，并通过SPFILE创建一个PFILE文件，进而在ASM磁盘上创建SPFILE文件。
SQL> connect / as sysdba
SQL> show parameter spfile
NAME TYPE VALUE
spfile string /oracle/product/11.2.0/db_1/dbs/spfileracdb11.ora
SQL> create pfile from spfile
File created.
SQL> create spfile=’+RACDB_DATA’ from pfile=’/oracle/product/11.2.0/db_1/dbs/initracdb11.ora’;
File created.
检查ASM上的参数文件。
[grid@rac1 ~]$ asmcmd
ASMCMD> ls RACDB_DATA/racdb1/spfile*
spfileracdb1.ora
同步RAC两个节点上的参数文件，更改其内容，设置SPFILE参数指向ASM中的参数文件。
[oracle@rac1 dbs]$ echo “SPFILE=’+RACDB_DATA/racdb1/spfileracdb1.ora’” > /oracle/product/11.2.0/db_1/dbs/initracdb11.ora
[oracle@rac1 dbs]$ ssh rac2 “echo “SPFILE=’+RACDB_DATA/racdb1/spfileracdb1.ora’” > /oracle/product/11.2.0/db_1/dbs/initracdb12.ora”
通过srvctl修改OCR中关于参数文件的配置。
[oracle@rac1 dbs]$ srvctl modify database -d racdb1 -p +RACDB_DATA/racdb1/spfileracdb1.ora
现在通过CRS启动数据库，将不再需要dbs目录下的参数文件，可以将其移除。
[oracle@rac1 dbs]$ mv /oracle/product/11.2.0/db_1/dbs/spfileracdb11.ora /oracle/product/ 11.2.0/db_1/dbs/spfileracdb11.ora_bak
[oracle@rac1 dbs]$ ssh rac2 “mv /oracle/product/11.2.0/db_1/dbs/spfileracdb12.ora /oracle/product/11.2.0/db_1/dbs/spfileracdb12.ora_bak”
在下次重新启动数据库时，新的配置将会生效。
[oracle@rac1 dbs]$ srvctl stop database -d racdb1
[oracle@rac1 dbs]$ srvctl start database -d racdb1
[oracle@rac1 dbs]$ srvctl status database -d racdb1
Instance racdb11 is running on node rac1
Instance racdb12 is running on node rac2
检查数据库，新的参数文件已经被使用和生效。
SQL> SHOW parameter spfile
NAME TYPE VALUE
spfile string +RACDB_DATA/racdb1/spfileracdb1.ora
7.7.3 谨慎修改RAC参数
在RAC环境中，即使按照正常的方式修改参数，也有可能因为遭遇Bug而导致事故，所以在进行重要的环境变更前，一定要进行测试，并详细检查与变更有关的文件，确保变更不会引起错误。
在Oracle 10.1的版本中，会遇到这样的问题，在RAC环境下修改UNDO_RETENTION参数，使用如下命令：
alter system set undo_retention=18000 sid=’*’;
这条命令直接导致了RAC的其他节点挂起，Oracle记录了一个相关Bug，Bug号为：4220405（这个Bug在Oracle 10gR2中修正），其Workaround就是分别修改不同实例。
alter system set undo_retention=18000 sid=‘RAC1’;
alter system set undo_retention=18000 sid=‘RAC2’;
alter system set undo_retention=18000 sid=‘RAC3’;
这个案例告诉我们，Bug无处不在，数据库调整应当极其谨慎，最好在测试环境中测试过再应用到生产环境。
再次重申，在RAC环境中，每一个维护操作都要相当谨慎！
7.7.4 RAC环境下初始化参数的查询方法
下面介绍RAC环境下初始化参数的查询方法。
一个简单的例子：
SQL> show parameter open_cursors
NAME TYPE VALUE
open_cursors integer 300
SQL> alter system set open_cursors = 500 scope = both sid = ‘test1’;
系统已更改。
SQL> disc
从 Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining and Real Application Testing options 断开
SQL> set instance test2
Oracle Database 11g Release 11.1.0.0.0 - Production
SQL> conn sys as sysdba
输入口令:
已连接。
SQL> alter system set open_cursors = 400 scope = both sid = ‘test2’;
系统已更改。
SQL> disc
从 Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options 断开
SQL> set instance local
Oracle Database 11g Release 11.1.0.0.0 - Production
SQL> conn / as sysdba
已连接。
不同的查询方法得到的结果。
SQL> select name, value
2 from v$parameter where name = ‘open_cursors’;
NAME VALUE
open_cursors 500
SQL> select inst_id, name, value
2 from gv$parameter where name = ‘open_cursors’;
INST_ID NAME VALUE
1 open_cursors 500
2 open_cursors 400
SQL> show parameter open_cursors
NAME TYPE VALUE
open_cursors integer 500
SQL> select sid, name, value
2 from v$spparameter where name = ‘open_cursors’;
SID NAME VALUE
* open_cursors 300
test1 open_cursors 500
test2 open_cursors 400
SQL> show spparameter open_cursors
SID NAME TYPE VALUE
* open_cursors integer 300
test2 open_cursors integer 400
test1 open_cursors integer 500
似乎除了看不到全局设置外，GVPARAMETER参数和VSPPARAMETER没有什么不同，其实不然，如果alter system set的时候只修改了spfile或者memory参数，结果就会不同。
SQL> alter system set open_cursors = 600 scope = memory sid = ‘test1’;
系统已更改。
SQL> alter system set open_cursors = 700 scope = spfile sid = ‘test2’;
系统已更改。
SQL> select name, value
2 from v$parameter where name = ‘open_cursors’;
NAME VALUE
open_cursors 600
SQL> select inst_id, name, value
2 from gv$parameter where name = ‘open_cursors’;
INST_ID NAME VALUE
1 open_cursors 600
2 open_cursors 400
SQL> select sid, name, value
2 from v$spparameter where name = ‘open_cursors’;
SID NAME VALUE
* open_cursors 300
test1 open_cursors 500
test2 open_cursors 700
从上面的对比可以看出，通过GV$视图访问的结果和SPFILE中包含的信息完全不同。除了上面介绍的几种视图之外，CREATE PFILE也是一个不错的选择。
参数文件备份与恢复
Oracle把SPFILE也纳入到RMAN的备份恢复策略当中，如果你配置了控制文件自动备份（AUTOBACKUP），那么Oracle会在数据库发生重大变化（如增减表空间）时自动进行控制文件及SPFILE文件的备份。
7.8 参数文件备份
（1）在RMAN命令行，通过show all检查备份的默认设置。
[oracle@enmoedu backup]$ rman target /
Recovery Manager: Release 12.1.0.2.0 - Production on Wed Sep 21 14:03:02 2016
Copyright © 1982, 2014, Oracle and/or its affiliates. All rights reserved.
connected to target database: PROD1 (DBID=2137673358)
RMAN> SHOW ALL;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name PROD1 are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘/oracle/app/oracle/product/12.1.0/prod_1/dbs/ snapcf_PROD1.f’; # default
这个设置可以在数据库中通过以下方式查询得到。
SQL> select * from v$rman_configuration;
CONF# NAME VALU CON_ID
1 CONTROLFILE AUTOBACKUP OFF 0
（2）默认是没有开启自动备份，现在进行设置。
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored
（3）指定自动备份的位置。
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘/backup/rman_ test/control_%F’;
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘/backup/ rman_test/control_%F’;
new RMAN configuration parameters are successfully stored
（4）检查自动备份。
自动备份的参数文件或控制文件，可以通过视图v$backup_spfile来检查。
SQL> select * from v$backup_spfile;
RECID STAMP SET_STAMP SET_COUNT MODIFICAT BYTES COMPLETIO DB_UNIQUE_NAME CON_ID
1 923149162 923149162 2 21-SEP-16 32768 21-SEP-16 PROD1 0
（5）列出备份集。也可以利用查看备份集的形式，查看spfile自动备份情况。
RMAN> list backup of spfile;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
2 Full 9.64M DISK 00:00:00 21-SEP-16
BP Key: 2 Status: AVAILABLE Compressed: NO Tag: TAG20160921T141922
Piece Name: /backup/rman_test/control_c-2137673358-20160921-00
SPFILE Included: Modification time: 21-SEP-16
SPFILE db_unique_name: PROD1
（6）备份包含。如果使用RMAN进行备份，在提示中可以看到以下信息。
RMAN> backup database;
Starting backup at 21-SEP-16
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=25 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00005 name=/oracle/oradata/PROD1/example01.dbf
input datafile file number=00001 name=/oracle/oradata/PROD1/system01.dbf
input datafile file number=00003 name=/oracle/oradata/PROD1/sysaux01.dbf
input datafile file number=00004 name=/oracle/oradata/PROD1/undotbs01.dbf
input datafile file number=00006 name=/oracle/oradata/PROD1/users01.dbf
。。。。
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:15
Finished backup at 21-SEP-16
Starting Control File and SPFILE Autobackup at 21-SEP-16
piece handle=/backup/rman_test/control_c-2137673358-20160921-00 comment=NONE
Finished Control File and SPFILE Autobackup at 21-SEP-16
7.9 参数文件恢复
使用自动备份恢复spfile文件。
RMAN> restore spfile to ‘/tmp/spfile_bak.ora’ from autobackup;
Starting restore at 21-SEP-16
using channel ORA_DISK_1
recovery area destination: /oracle/fast_recovery_area
database name (or database unique name) used for search: PROD1
channel ORA_DISK_1: no AUTOBACKUPS found in the recovery area
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20160921
channel ORA_DISK_1: AUTOBACKUP found: /backup/rman_test/control_c-2137673358-20160921-00
channel ORA_DISK_1: restoring spfile from AUTOBACKUP /backup/rman_test/control_c- 2137673358-20160921-00
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 21-SEP-16
检查一下，恢复的SPFILE文件自动生成到了指定位置。
[oracle@enmoedu tmp]$ ls -l /tmp/spfile_bak.ora
-rw-r----- 1 oracle oinstall 2560 Sep 21 14:30 /tmp/spfile_bak.ora
同样可以通过这种方法重建控制文件，如下所示。
RMAN> restore controlfile to ‘/tmp/controfile_bak.ctl’ from autobackup;
Starting restore at 21-SEP-16
using channel ORA_DISK_1
recovery area destination: /oracle/fast_recovery_area
database name (or database unique name) used for search: PROD1
channel ORA_DISK_1: no AUTOBACKUPS found in the recovery area
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20160921
channel ORA_DISK_1: AUTOBACKUP found: /backup/rman_test/control_c-2137673358-20160921-01
channel ORA_DISK_1: restoring control file from AUTOBACKUP /backup/rman_test/control_ c-2137673358-20160921-01
channel ORA_DISK_1: control file restore from AUTOBACKUP complete
Finished restore at 21-SEP-16
[oracle@enmoedu tmp]$ ls -l /tmp/controfile_bak.ctl
-rw-r----- 1 oracle oinstall 10043392 Sep 21 14:32 /tmp/controfile_bak.ctl
自动备份控制文件的功能给我们带来了极大的收益。通过自动备份，在数据库出现紧急状况的时候，用户可能从这个自动备份中获得更为有效、及时的控制文件。
随着ASM的增强，Oracle也提供了基于ASM的参数文件备份和恢复命令。在ASMCMD中，可以通过spbackup命令对参数文件进行备份。
ASMCMD> spbackup +DATA/asm/asmparameterfile/registry.253.721810181 +DATA/spfileBackASM.bak
ASMCMD> spbackup +DATA/asm/asmparameterfile/registry.253.721810181 +FRA/spfileBackASM.bak
新增的命令还包括 spcopy和spmove等。
评论
0 点赞
0 点赞
