Chinaunix首页 | 论坛 | 博客
  • 博客访问: 402436
  • 博文数量: 65
  • 博客积分: 2711
  • 博客等级: 少校
  • 技术积分: 745
  • 用 户 组: 普通用户
  • 注册时间: 2008-04-02 10:02
文章分类

全部博文(65)

文章存档

2013年(4)

2012年(3)

2011年(24)

2010年(21)

2009年(11)

2008年(2)

分类: Oracle

2010-07-07 19:05:36

系统环境:
    redhat-as4.7
    oracle10.2.0.4-RAC
 
 
为什么要修改?
最近应用系统有三次出现短暂无法连接数据库问题,检查各个节点alter日志发现每次出现问题时候某个节点都会记录报警日志:
Tue Jul  6 14:44:54 2010
WARNING: inbound connection timed out (ORA-3136)
经awr报告分析,发现出问题时间段share pool中的sql area每次都在做不等量的调整,幅度较大,share pool总量也在调整,top 5事件里面都是latch: library cache和latch: shared pool事件严重,经专家分析原因,极大可能性是由于当时访问量比较大,由于sql语句过多内存竞争激烈,导致对latch争用严重,sga不得不重新自动调整内存,来满足当时的负荷量。而在sga自动调整过程中连接是必然中断的,因此才会出现上述问题现象。
专家建议手动设置share pool和db cache到一个合理值。这里经分析awr报告,认为db cache变化不是很大,暂时不调整。
 

方法:
以sys用户登陆rac,执行以下三条命令:
修改sga最大可使用内存
alter system set sga_max_size=3600M scope=spfile sid='*';
修改sga自动调整的内存数量,不能大于sga_max_size
alter system set sga_target=3600M scope=spfile sid='*';
修改shared_pool_size
alter system set shared_pool_size=1850M scope=spfile sid='*';
然后分别重启各个节点。
 
 
 
 
分析:
1、我的rac各个节点最大sga内存sga_max_size原来是3000M,根据我对几次问题awr报告分析,share pool使用历史最大到1792M,db cache最大使用到1700M,因此需要首先调整最大sga内存sga_max_size。
SQL> show parameter sga;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 3008M
sga_target                           big integer 3008M
SQL>
 
2、调整sga_max_size及sga_target过程中,我先用scope=both或者scope=pfile参数来执行,但是老是报错:
SQL> alter system set sga_max_size=3500M scope=both sid='racdb1';
alter system set sga_max_size=3500M scope=both sid='racdb1'
                 *
ERROR at line 1:
ORA-02095: specified initialization parameter cannot be modified
SQL> alter system set sga_max_size=3500M scope=pfile sid='racdb1';
alter system set sga_max_size=3500M scope=both sid='racdb1'
                 *
ERROR at line 1:
ORA-02095: specified initialization parameter cannot be modified
 
 
 
于是在测试机上进行测试,测试机是单机,三个参数执行都没问题,先用scope=spfile修改,之后使用
create pfile='路径/init名称' from spfile
想通过spfile创建pfile查看一下。
创建pfile之后发现比pfile内容比原来更全面,于是在生产机上在修改sga之前先通过spfile创建一个pfile查看一下生产机的参数配置,可是遇到了问题:
 
SQL> create pfile='/opt/oracle/app/admin/racdb/pfile/init.ora.3102009154459-spfile-create' from spfile;
create pfile='/opt/oracle/app/admin/racdb/pfile/init.ora.3102009154459-spfile-create' from spfile
*
ERROR at line 1:
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
以上是想用一个新的名称定义pfile,报错

SQL> create pfile='/opt/oracle/app/admin/racdb/pfile/init.ora.3102009154459' from spfile;
create pfile='/opt/oracle/app/admin/racdb/pfile/init.ora.3102009154459' from spfile
*
ERROR at line 1:
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
以原来pfile名称创建,覆盖原来pfile报错

SQL> create pfile='/oradata1/racdb/init.racdb1.ora' from spfile;
create pfile='/oradata1/racdb/init.racdb1.ora' from spfile
*
ERROR at line 1:
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
在各个节点的共享磁盘上创建,还是报错

经搜索,找到一片文章:http://space.itpub.net/519536/viewspace-666453
 
*******************************************************************
在RAC环境中轻易不要使用“create pfile from spfile;”命令创建PFILE。
因为在RAC环境,默认情况下的SPFILE会放到共享存储上(裸设备或ASM磁盘组上),RAC的每台主机上是使用PFILE指向SPFILE的方法来完成SPFILE的定位的。
一旦使用“create pfile from spfile;”命令创建PFILE后,新生成的PFILE将覆盖原有dbs目录下的PFILE,此后数据库实例启动时读取的将不再是共享存储上的SPFILE,转而读取本地的PFILE文件的内容。
1.默认情况下$ORACLE_HOME/dbs目录下的PFILE initracdb.ora中只有一行记录,记录着SPFILE的路径指向。
/oracle/app/oracle/product/10.2.0/db_1/dbs$ cat initracdb1.ora
spfile=+DATA/racdb/spfileracdb.ora
2.此时可以从数据库参数得到目前使用的是SPFILE启动的数据库
SQL> show parameter spfile
NAME            TYPE        VALUE
--------------- ----------- ------------------------------
spfile          string      +DATA/racdb/spfileracdb.ora
3.此时如果使用“create pfile from spfile;”命令创建PFILE,原有PFIEL中的SPFILE指向将被具体的数据库参数所取代。
当数据库再次启动时,因为无法找到SPFILE的位置,将使用PFILE文件中记录的具体参数值完成数据库的启动,这样将会给数据库的管理带来比较大的影响,不再享受到SPFILE参数的便捷。
4.小结
本文描述的是一个常识性的问题,希望大家在对RAC数据库进行维护和管理的过程中不要因此给自己带来不必要的麻烦。
如果出现了这样的问题该如何处理呢?方法比较简单,将PFILE的内容恢复为具有SPFILE指向的内容即可,也许在具体场景中需要重新创建SPFILE。
******************************************************************
 
原来如此,查看我的db1节点(以上操作都是在db1上执行):
SQL> show parameter spfile;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
spfile                               string
果然已经使用了自己节点上的pfile文件,这是我想起来以前好像改过类似的设置,但是通过spfile创建pfile一直报错,想不通是什么原因,可能是10G的限制?
之后根据该文章方法修改$ORACLE_HOME/dbs/initracdb1.ora,参照db2上的对应文件修改之后:
SQL> show parameter spfile;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
spfile                               string      /oradata1/racdb/spfileracdb.or
                                                 a
 
 
 

一切妥当,以sys用户登陆rac,执行修改share pool方法的三条命令,无报错,然后分别重启各节点,完成。
重启后查询:
SQL> show parameter sga;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 3600M
sga_target                           big integer 3600M
SQL> show parameter size;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
bitmap_merge_area_size               integer     1048576
create_bitmap_area_size              integer     8388608
db_16k_cache_size                    big integer 0
db_2k_cache_size                     big integer 0
db_32k_cache_size                    big integer 0
db_4k_cache_size                     big integer 0
db_8k_cache_size                     big integer 0
db_block_size                        integer     8192
db_cache_size                        big integer 0
db_keep_cache_size                   big integer 0
db_recovery_file_dest_size           big integer 0
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recycle_cache_size                big integer 0
global_context_pool_size             string
hash_area_size                       integer     131072
java_max_sessionspace_size           integer     0
java_pool_size                       big integer 0
large_pool_size                      big integer 0
max_dump_file_size                   string      UNLIMITED
object_cache_max_size_percent        integer     10
object_cache_optimal_size            integer     102400
olap_page_pool_size                  big integer 0
parallel_execution_message_size      integer     2152
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
sga_max_size                         big integer 3600M
shared_pool_reserved_size            big integer 97307852
shared_pool_size                     big integer 1856M
sort_area_retained_size              integer     0
sort_area_size                       integer     65536
streams_pool_size                    big integer 0
workarea_size_policy                 string      AUTO
SQL>
SQL> exit
 
 
在次过程中解决了一个问题:
启动数据库时候报错:ORA-32004: obsolete and/or deprecated parameter(s) specified

搜索文章:
************************************************************
今天在学习管理archivelog时遇到了ORA-32004错误,下面是解决方案:
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORA-32004: obsolete and/or deprecated parameter(s) specified
ORACLE instance started.
Total System Global Area  167772160 bytes
Fixed Size                  1218316 bytes
Variable Size              71305460 bytes
Database Buffers           92274688 bytes
Redo Buffers                2973696 bytes
Database mounted.
Database opened.

    查看oracle给出的问题描述:
SQL> host oerr ora 32004;
32004, 00000, "obsolete and/or deprecated parameter(s) specified"
// *Cause:  One or more obsolete and/or parameters were specified in
//          the SPFILE or the PFILE on the server side.
// *Action: See alert log for a list of parameters that are obsolete.
//          or deprecated. Remove them from the SPFILE or the server
//          side PFILE.

    去看看spfile:
*.log_archive_format='%t_%s_%r.dbf'
*.log_archive_max_processes=3
*.log_archive_start=FALSE
*.log_archive_trace=4096
    然后在看看alert log文件,里面会出现以下信息:
Deprecated system parameters with specified values:
  log_archive_start
End of deprecated system parameter listing
    查了查资料说是oracle 10G已经不支持该参数了,当打开归档模式(archive log mode) ,则 ARCH 进程被隐性的自动设定。10g 中也就不会出现 9i 以前那种数据库已经在归档模式,但是自动归档没有被设定的情况了。要解决该问题需要重置 log_archive_start 参数。
SQL> alter system reset log_archive_start SCOPE=SPFILE SID='*';
System altered.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area  167772160 bytes
Fixed Size                  1218316 bytes
Variable Size              75499764 bytes
Database Buffers           88080384 bytes
Redo Buffers                2973696 bytes
Database mounted.
Database opened.
    重启后再不报ORA-32004错误了!
    查看10g中都有那些参数是 deprecated 的:
SQL>select name,description from v$parameter where isdeprecated = 'TRUE';
    上面提到的alert log文件位于%ORACLE_BASE%\admin\%ORACLE_SID%\bdump里
 
*********************************************************************
 
于是仔细检查alter日志文件,在启动过程中确有痕迹:
  db_name                  = racdb
  open_cursors             = 300
  sql_trace                = FALSE
  pga_aggregate_target     = 1073741824
Deprecated system parameters with specified values:
  sql_trace
End of deprecated system parameter listing

检查rac的spfile文件:
[oracle@db1 racdb]$ cat spfileracdb.ora
        KK5#+racdb2.__db_cache_size=1577058304
racdb1.__db_cache_size=1543503872
racdb2.__java_pool_size=16777216
racdb1.__java_pool_size=16777216
racdb2.__large_pool_size=16777216
racdb1.__large_pool_size=16777216
racdb2.__shared_pool_size=1509949440
racdb1.__shared_pool_size=1543503872
racdb2.__streams_pool_size=16777216
racdb1.__streams_pool_size=16777216
*.archive_lag_target=1800
*.audit_file_dest='/opt/oracle/app/admin/racdb/adump'
*.background_dump_dest='/opt/oracle/app/admin/racdb/bdump'
*.cluster_database_instances=2
*.cluster_database=true
*.compatible='10.2.0.3.0'
*.control_files='/oradata1/racdb/control01.ctl','/oradata1/racdb/control02.ctl','/oradata1/racdb/control03.ctl'
*.core_dump_dest='/opt/oracle/app/admin/racdb/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='racdb'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=racdbXDB)'
racdb2.instance_number=2
racdb1.instance_number=1
*.job_queue_processes=10
*.log_archive_dest_1='LOCATION=/arch/racdb1'
racdb2.log_archive_dest_1='LOCATION=/arch/racdb2'
racdb1.log_archive_dest_1='LOCATION=/arch/racdb1'
racdb1.log_archive_dest_2='service=standby lgwr async noaffirm'
racdb2.log_archive_dest_2='service=standby lgwr async noaffirm'
*.log_archive_dest_state_2='enable'
*.log_archive_format='%t_%s_%r.dbf'
*.nls_territory='CHINA'
*.open_cursors=300
*.pga_aggregate_target=1073741824
*.processes=1000
*.remote_listener='LISTENERS_RACDB'
*.remote_login_passwordfile='exclusive'
*.resource_limit=TRUE
*.sessions=1105
*.sga_target=3145728000
*.sql_trace=FALSE
racdb1.standby_file_management='AUTO'
racdb2.standby_file_management='AUTO'
racdb2.thread=2
racdb1.thread=1
*.timed_statistics=TRUE
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
racdb1.undo_tablespace='UNDOTBS1'
racdb2.undo_tablespace='UNDOTBS2'
*.user_dump_dest='/oradata1//trace'
*.utl_file_dir='/oradata1/logmnr'

定位到*.sql_trace=FALSE,进行如下操作:
[oracle@db1 racdb]$ sqlplus '/as sysdba'
SQL*Plus: Release 10.2.0.4.0 - Production on Wed Jul 7 11:37:07 2010
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
SQL> alter system reset sql_trace scope=spfile sid='*';
System altered.
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
 
 
检查*.sql_trace=FALSE已经更改:
[oracle@db1 racdb]$ cat spfileracdb.ora
        9?#+racdb2.__db_cache_size=1577058304
racdb1.__db_cache_size=1543503872
racdb2.__java_pool_size=16777216
racdb1.__java_pool_size=16777216
racdb2.__large_pool_size=16777216
racdb1.__large_pool_size=16777216
racdb2.__shared_pool_size=1509949440
racdb1.__shared_pool_size=1543503872
racdb2.__streams_pool_size=16777216
racdb1.__streams_pool_size=16777216
*.archive_lag_target=1800
*.audit_file_dest='/opt/oracle/app/admin/racdb/adump'
*.background_dump_dest='/opt/oracle/app/admin/racdb/bdump'
*.cluster_database_instances=2
*.cluster_database=true
*.compatible='10.2.0.3.0'
*.control_files='/oradata1/racdb/control01.ctl','/oradata1/racdb/control02.ctl','/oradata1/racdb/control03.ctl'
*.core_dump_dest='/opt/oracle/app/admin/racdb/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='racdb'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=racdbXDB)'
racdb2.instance_number=2
racdb1.instance_number=1
*.job_queue_processes=10
*.log_archive_dest_1='LOCATION=/arch/racdb1'
racdb2.log_archive_dest_1='LOCATION=/arch/racdb2'
racdb1.log_archive_dest_1='LOCATION=/arch/racdb1'
racdb1.log_archive_dest_2='service=standby lgwr async noaffirm'
racdb2.log_archive_dest_2='service=standby lgwr async noaffirm'
*.log_archive_dest_state_2='enable'
*.log_archive_format='%t_%s_%r.dbf'
*.nls_territory='CHINA'
*.open_cursors=300
*.pga_aggregate_target=1073741824
*.processes=1000
*.remote_listener='LISTENERS_RACDB'
*.remote_login_passwordfile='exclusive'
*.resource_limit=TRUE
*.sessions=1105
*.sga_target=3145728000
racdb1.standby_file_management='AUTO'
racdb2.standby_file_management='AUTO'
racdb2.thread=2
racdb1.thread=1
*.timed_statistics=TRUE
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
racdb1.undo_tablespace='UNDOTBS1'
racdb2.undo_tablespace='UNDOTBS2'
*.user_dump_dest='/oradata1//trace'
*.utl_file_dir='/oradata1/logmnr'
 
 

总结:对于rac,调整系统参数时候尽量使用scope=spfile,然后重启各个节点。这种方法要比先修改pfile,在通过pfile创建spfile,在启动数据库方法要简单的多,而且不易出问题。这种方法就是各个节点共同使用一个spfile,管理上确实方便,不过某些时候也可能不太灵活,如果这个共享spfile损坏,那么rac各个节点都会收到影响,有利必有弊,要灵活掌握。
阅读(7446) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~