Some ORAs (32001, 00106)

因为参数sessions / processes 关系到能连接到instance的并发session数，因此想尝试增大这些参数的值，但是杯具之旅就此开始了...

尝试修改下参数sessions

SQL> alter system set sessions=150 scope=spfile;
alter system set sessions=150 scope=spfile
*
ERROR at line 1:
ORA-32001: write to SPFILE requested but no SPFILE specified at startup

居然发现当前的instance不是通过spfile方式启动的！God...我用的可是10.2的数据库啊，没道理还是用pfile方式启动的吧。但是通过如下SQL可以验证当前instance确实不是通过spfile启动的...

SQL> select count(*) from v$spparameter where value is not null;

  COUNT(*)
----------
         0

因为如果是用spfile来启动instance的话，视图v$spparameter中的值不会都是NULL. 

好吧，查看下数据库相关文件吧，因为是在windows操作系统上，初始化参数有文件是放在%ORACLE_HOME%\database目录下，而不是%ORACLE_HOME%\dbs下面。10g默认的情况是database目录下放的是pfile-- init<sid>.ora, database目录下放的是spfile -- spfile<sid>.ora, 而init<sid>.ora中其实是没有参数信息的，放置的是spfile的路径信息，比如

SPFILE='C:\oracle\product\10.2.0\db_1/dbs/spfileorcl.ora'

这样虽然instance启动的时候是到database目录下查找参数文件，最后用到的还是dbs目录下的spfile， 最后用的就是spfile来启动instance。

但是杯具的是，我查看了下我访问的数据的相关信息，database目录下的init<sid>.ora文件中就是实实在在的参数信息，而不是spfile的路径信息，也就难怪用的不算spfile来启动instance了。  解决这个问题很简单，可以通过create spfile from pfile把pfile的内容写到spfile中，然后把spfile放到database目录下，也就是跟pfile放到同一个目录下，那么oracle会优先使用spfile了。

做了相关修改，我决定来检验下效果如何，首先shutdown数据库...

SQL> shutdown immediate
ORA-00106: cannot startup/shutdown database when connected to a dispatcher

结果居然遇到这么一个错误，很是奇怪，我怎么会以shared server的方式连接到数据呢，数据库连接不是用dedicated server方式的吗？神马个情况！

我当前是以EZCONNECT方式连接到数据的，我决定先通过tnsname方式连上看一下，因为tnsname中可以设置连接方式为dedicated， 如下...

ORCL_VM =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 10.80.15.117)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl)
    )
  )

SQL> conn sys/a@ORCL_VM as sysdba
Connected.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  612368384 bytes
Fixed Size                  1298208 bytes
Variable Size             171966688 bytes
Database Buffers          432013312 bytes
Redo Buffers                7090176 bytes
Database mounted.
Database opened.

 可以看到数据库成功重启了，现在再来检查下当前instance是不是以spfile来启动的...

SQL> select count(*) from v$spparameter where value is not null;

  COUNT(*)
----------
        32

 从查询结果来看，当前的instance应该是以spfile来启动的。

现在再回头看看shared server的问题，从alert文件中刚才数据库启动的日志可以看到如下内容...

Thu Apr 07 14:33:16 2011
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started with pid=12, OS id=1284
Thu Apr 07 14:33:16 2011
starting up 1 shared server(s) ...

 居然真的有shared server 和 dispatcher存在，这个又是在啥时候设置的，一点印象都没有, 可能是很早之前做的测试:(

关于dispatcher也可以从listener的services信息看到...

Instance "orcl", status READY, has 2 handler(s) for this service...
  Handler(s):
    "DEDICATED" established:6 refused:0 state:ready
       LOCAL SERVER
    "D000" established:132 refused:0 current:66 max:1002 state:ready
       DISPATCHER <machine: SZV-DEV-RF-002, pid: 1200>
       (ADDRESS=(PROTOCOL=tcp)(HOST=szv-dev-rf-002)(PORT=3814))

看一下相关参数shared_server, dispatcher的设置情况...

SQL> show parameter shared_server;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
max_shared_servers                   integer     20
shared_server_sessions               integer
shared_servers                       integer     1
SQL> show parameter dispatcher

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
dispatchers                          string      (protocol=TCP)
max_dispatchers                      integer     20

 通过设置参数shared_servers为0来禁止掉shared server...

SQL> alter system set shared_servers=0;
System altered.
SQL> alter system set dispatchers='';
System altered.

 重启instance之后会发现shared server和dispatcher不会启动了...

SQL> select count(*) from v$shared_server;

  COUNT(*)
----------
         0

SQL> select count(*) from v$dispatcher;

  COUNT(*)
----------
         0