关于 十月, 2009 的文章

Oracle9i与10g SGA及PGA参数调优设置

关于Oracle的参数调优的文章很多,但是对于初学者来说要弄明白还是不容易的,下面是前辈提供的调优参数,让我们这些菜鸟们可以直接拿来用。

1.Oracle 10g上的调优参数:将PGA_aggreate_target 设一下,其它让它自己分配,一般就是内存的40%-60%之间。

2.Oracle9i上的调优参数:物理内存是4G Oracle优化,共享池200M(10% * 1024M*4),高速缓存1638M (40% * 1024M*4),大型池16M,java池128M,PGA 256M。SGA最大2500M (注:32位操作系统只能支持到1.7G)

3.Oracle9i上的调优参数:物理内存是8G oracle优化,共享池512M,高速缓存4G,大型池16M,JAVA池256M,PGA512M。SGA最大2500M (注:32位操作系统只能支持到1.7G)

另外,提供一个思路,通过配合压力测试,使用spotlight on Oracle工具来调整参数,一直调到全部为稳定运行为绿色,不出现红色告警,一个小时内黄色告警不超过2-3次,基本上就很不错了。

还有要明确的是,平台和硬件的调优是必要的,但绝非最关键的,最关键的是数据库的软件调优,数据库的设计,一个好的数据库设计能够极大的改善数据库的性能。

No Comments

在Linux上基于源地址路由实现电信网通双线

想要通过普通的静态策略路由来实现电信网通双线基本上是不可能的,因为那将需要维护相当大的一个IP段的数据库,而且还需要随时更新才能保证效果。
后来听前辈们说,可以采用基于源地址路由的方式来处理,让进来的数据,从哪个IP进来就从哪个IP返回。
下面就是一个在生产中得到了实际应用的脚本:

 #!/bin/bash
##
## CNC_RULE AND CTC_RULE from /etc/iproute2/rt_tables
## echo 200 cnc >> /etc/iproute2/rt_tables
## echo 201 ctc >> /etc/iproute2/rt_tables
##

CTC_DEVICE="eth0"
CTC_RULE="ctc"
CTC_NETWORK="10.10.10.0"
CTC_GATEWAY="10.10.10.1"
CTC_IPADDR="10.10.10.2"

CNC_DEVICE="eth1"
CNC_RULE="cnc"
CNC_NETWORK="20.20.20.0"
CNC_GATEWAY="20.20.20.1"
CNC_IPADDR="20.20.20.2"

ACTION="add"

if [ $# -ne 0 ]; then
if [ "$1" != "add" -a "$1" != "del" ]; then
echo "error"
else
ACTION="$1"
fi
fi

ip route ${ACTION} ${CNC_NETWORK} dev ${CNC_DEVICE} src ${CNC_IPADDR} table ${CNC_RULE}
ip route ${ACTION} default via ${CNC_GATEWAY} table ${CNC_RULE}

ip route ${ACTION} ${CTC_NETWORK} dev ${CTC_DEVICE} src ${CTC_IPADDR} table ${CTC_RULE}
ip route ${ACTION} default via ${CTC_GATEWAY} table ${CTC_RULE}

ip rule ${ACTION} from ${CNC_IPADDR} table ${CNC_RULE}

ip rule ${ACTION} from ${CTC_IPADDR} table ${CTC_RULE}

ip route add default via ${CTC_GATEWAY}

ip rule add to 200.200.0.0/16 table cnc

在执行脚本之前,先执行以下命令:
echo 200 cnc >> /etc/iproute2/rt_tables
echo 201 ctc >> /etc/iproute2/rt_tables

最后的 ip rule add to 200.200.0.0/16 table cnc 相当于是添加了一个例外,让200.200.0.0/16这个段的直接从cnc出去。

No Comments

各种linux发行版时间轴

linuxtimeline_2

No Comments

一次 ORA-03113: end-of-file on communication channel 错误定位过程

手动关闭Oracle之后打算再次启动Oracle:
$sqlplus ‘/as sysdba’
SQL> startup

ORA-03113: end-of-file on communication channel
结果便出现了以上错误。

通过上网查询出错原因,常见的原因有以下几个:
1、Unix核心参数设置不当
2、Oracle执行文件权限不正确/环境变量问题
3、客户端通信不能正确处理
4、数据库服务器崩溃/操作系统崩溃/进程被kill
5、Oracle 内部错误
6、特定SQL、PL/SQL引起的错误
7、空间不够
8、防火墙的问题

因为oracle已经正常运行了一个月,因此unix参数不对、权限环境变量、防火墙这些在首次启动就会发现的问题不应该现在才出现;而对于客户端通信、特定的SQL引起的错误,因为在启动过程中就已经报错,所以也排除。

由此判断,数据库服务崩溃/系统崩溃/进程被kill、Oracle内部错误、空间不够可能是原凶。

首先从最容易查起的原因开始,查询磁盘空间,结果磁盘空间利用不到30%,剩余空间足够;

于是检查Oracle内部错误:
$cd $ORACLE_HOME/admin/SID/cdump

发现大量的core,看来原因找到了。但所有的core目录都是空的,没有任何文件。

使用ulimit –a查看,原因core的文件大小为0,这是什么原因导致的core呢?

现在原因不明,于是检查bdump目录下的日志。
$cd $ORACLE_HOME/admin/SID/bdump
$cat alert_SID.log

发现日志量很大,满屏的都是同一个错误,扩展表空间失败:
ORA-1654: unable to extend index SID.INDEX by 128 in tablespace TABLESPACE
ORA-1653: unable to extend table SID.TABLE by 1024 in tablespace TABLESPACE

看来表空间已经满了并且无法扩展导致oracle出现core的。
$cd $ORACLE_BASE/oradada/SID
$ls –lh
-rw-r----- 1 oracle oinstall 2.1G Oct 14 15:10 SID_DATA01.DBF
-rw-r----- 1 oracle oinstall 201M Oct 14 12:28 SID_INDEX01.DBF

原来是空间已经达到2G,但应该触发扩展才对。
安装数据库时并没有限制SID_DATA01.DBF文件大小。

查看创建表空间的脚本,发现在脚本中对该文件有限制。脚本如下:
CREATE TABLESPACE SID_DATA DATAFILE
‘/data/oracle/oradata/SID/SID_DATA01.DBF' SIZE 200M AUTOEXTEND ON NEXT 200M MAXSIZE 2048M’
MAXSIZE UNLIMITED
LOGGING
ONLINE
PERMANENT
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
BLOCKSIZE 8K
SEGMENT SPACE MANAGEMENT MANUAL;

原来是在创建表空间时人为限制了表空间大小最大为2G,这是优化导致的问题,今后在新建数据库时都要记住,数据库要根据用户的使用场景来变更表空间。

很多程序只支持2G大小的文件,所以才定为2G,以避免此类问题,虽然使用的是ext3的文件系统,为了方便解决问题才定为2G。但数据库文件为2.1G,难道是文件太大导致的不能启动?

似乎问题找到了,只需要修改表空间即可解决问题。

但要修改表空间,首先要启动数据库,才能够修改表空间的参数,问题又绕回来了,数据库启不动。

于是再次在网上搜索资料,表空间满导致数据库启动不了的,还没有人遇见这样的问题,看来我们碰到的问题并不是前面所列出的八种原因,而是一种特殊原因。

尝试过多种启动方式:
Startup 直接启动
Startup mount 加载数据库
Startup unmount 不加载数据库
Startup force 强行启动

全是报同一个错误提示:ORA-03113: end-of-file on communication channel

经过几个小时,总结了一下,表空间满应用程序不停向数据库写数据,oracle出现异常,之后无法启动。但要解决数据库空间问题必须先启动。

于是在网上查询是否有办法在不启动数据库的情况下修改表空间,但找了很久没有此类方法。

难道真的要用删除数据库的方法才能够解决?

细心的人可能发现了我们问题解决过程,startup mount 和startup unmount执行结果都是相同的。或许是启动过程中碰到了什么问题导致无法启动,难道和数据库的文件大小根本没关系?是不是oracle启动时还需要其它文件,而这些文件也增大了?

于是使用find命令查询大于2G文件
$cd $ORACLE_BASE
$find . -size +2097160192c
./product/9.2.0.4/admin/SID/bdump/alert_SID.log
./oradata/SID/SID_DATA01.DBF

真的还有一个,清空该日志文件,启动….成功,再次修改oracle的表空间属性,日志中错误消失。

总结
1、经查询资料,了解到Oracle对自身日志文件有一个限制就是每个日志文件不能大于2G,大于2G以后会出现各种问题。且同样对日志文件有这样限制的软件还有不少,如Squid,RoseHA等。因此以后我们在今后要实际生产环境中部署的时候,一定要针对这一特点手工对Oracle做自动日志切割和清理。

2、千万不要删除oracle的数据库文件,即使备份后恢复数据也会丢掉,因为Oracle的数据文件是与磁盘物理位置有关联的,不像mysql那样。

No Comments