Monthly Archives: 八月 2011

The value (30) of MAXTRANS parameter ignored

Posted on by

1、现象
Mon Aug 8 08:16:07 2011
The value (30) of MAXTRANS parameter ignored.
kupprdp: master process DM00 started with pid=91, OS id=21125
to execute – SYS.KUPM$MCP.MAIN(‘SYS_EXPORT_TABLE_01’, ‘YDZJ’, ‘KUPC$C_1_20110808081609’, ‘KUPC$S_1_20110808081609’, 0);
kupprdp: worker process DW01 started with worker id=1, pid=57, OS id=21127
to execute – SYS.KUPW$WORKER.MAIN(‘SYS_EXPORT_TABLE_01’, ‘YDZJ’);
kupprdp: worker process DW02 started with worker id=2, pid=95, OS id=21502
to execute – SYS.KUPW$WORKER.MAIN(‘SYS_EXPORT_TABLE_01’, ‘YDZJ’);

2、原因
这个时间段正在使用expdp进行数据库导出，当然从错误描述也可以看出和导出操作有关，不过当时导出是成功，没有报任何错误。 在metalink查询 ，发现这是Version: 10.1.0.2 to 11.1.0.7 (任何平台) 的一个bug，Bug号为：6347775
这是由于在创建备份主表时使用了如下语句：
CREATE TABLE table_name (columns_list) INITRANS 10 MAXTRANS 30
而Maxtrans参数在10gR1时已经废弃，所以在告警日志中就提示：
The value (30) of MAXTRANS parameter ignored. ， 此bug没有什么影响，所以可以忽略。

3、重现
SQL> create table xff(xifenfei varchar2(100)) initrans 10 maxtrans 20;

Table created.

查看alert日志
Mon Aug 8 16:11:28 2011
The value (20) of MAXTRANS parameter ignored.

利用DNSPod域名解析实现blog高可用

Posted on by

因为blog的服务器不太稳定，经常有异常断网或者关机现象发生，今天采用了利用一些基本资源，使用了高可用，整体思路采用DNSPod域名解析提供的免费检测服务器状态，如果主服务器发生宕机，自动切换到备机功能（监控功能）实现高可用。

1、配置备用服务器和主服务器一致，使用相同的域名均可以访问（修改电脑的hosts文件测试）
在本次配置中，主要是固定url的功能
1.1）apache中启用该模块mod_rewrite

1.2）.htaccess文件中内容

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

1.3）启用FollowSymLinks功能
“Options Indexes FollowSymLinks
… …
AllowOverride None”
改为
“Options Indexes FollowSymLinks
… …
AllowOverride All”

2、配置DNSPod监控功能，添加备机ip到域名解析中

3、既然思路是当一台服务器发生故障时，域名解析自动切换到备用服务器，那么问题就是主服务器和备服务器的数据要一致，因为是网站，涉及的数据一致主要就是数据库内容一致，网站上传编辑附件一致即可

3.1）mysql数据库同步（因为这个是个人blog，对数据的实时性，一致要求不是异常的高，所以采用crontab实现同步，如果要求高，可以采用mysql 主主复制实现）

#!/bin/bash
#目标数据库
target_db=*******
target_user=*******
target_pwd=*******
target_host=*******

#源数据库
source_db=*******
source_user=*******
source_pwd=*******
source_host=*******

#其他配置
dumptime=$(date +%y%m%d%H%M)
dumpfile=/home/chengfei/backup/mysql/${dumptime}.sql
logfile=/home/chengfei/backup/log/syc_mysql.log

#开始操作
echo "开始数据库同步……`date`……">>${logfile}
#导出数据库
 /usr/bin/mysqldump -u${source_user} -p${source_pwd} -h${source_host} ${source_db} >${dumpfile} 2>> ${logfile}

#导入数据库
mysql -u${target_user} -p${target_pwd} -h${target_host}<<XFF>> ${logfile}
drop database ${target_db};
create database ${target_db};
use ${target_db};
source ${dumpfile}
exit
XFF
#操作结束
echo "数据库同步结束……`date`……">>${logfile}
echo ''>>${logfile}

--crontab 
00 2,12,14,16,18,20,22,24 * * * /home/chengfei/backup/script/sysc_mysql.sh

3.2)因为我这个blog上传编辑图片类的内容非常少，暂时没有考虑网站文件同步功能，以后可以考虑实现。目前初步方案是采用scp或者ftp结合crontab功能实现定时同步

V$LOCK视图相关知识

Posted on by

1、V$LOCK视图结构

列名 类型 字段说明
ADDR RAW（4 | 8） Address of lock state object
KADDR RAW（4|8） Address of lock
SID NUMBER 会话的sid，可以和v$session 关联
TYPE VARCHAR2(2) 区分该锁保护对象的类型（表4）
TM – DML enqueue
TX – Transaction enqueue
UL – User supplied
–我们主要关注TX和TM两种类型的锁
–UL锁用户自己定义的，一般很少会定义，基本不用关注
–其它均为系统锁，会很快自动释放，不用关注
ID1
ID2		 NUMBER ID1,ID2的取值含义根据type的取值而有所不同
对于TM 锁
ID1表示被锁定表的object_id 可以和dba_objects视图关联取得具体表信息，ID2 值为0
对于TX 锁
ID1以十进制数值表示该事务所占用的回滚段号和事务槽slot number号,其组形式:
0xRRRRSSSS,RRRR=RBS/UNDO NUMBER,SSSS=SLOT NUMBER
ID2 以十进制数值表示环绕wrap的次数，即事务槽被重用的次数
LMODE NUMBER
  • 0 – none
  • 1 – null (NULL)
  • 2 – row-S (SS)
  • 3 – row-X (SX)
  • 4 – share (S)
  • 5 – S/Row-X (SSX)
  • 6 – exclusive (X)
  • 具体见表3
REQUEST NUMBER 同LMODE
–大于0时，表示当前会话被阻塞，其它会话占有改锁的模式
CTIME NUMBER
  • 已持有或者等待锁的时间
BLOCK NUMBER
  • 是否阻塞其他会话锁申请 1:阻塞 0:不阻塞


2、其它相关视图说明

视图名 描述 主要字段说明
v$session 查询会话的信息和锁的信息。 sid,serial#：表示会话信息。
program：表示会话的应用程序信息。
row_wait_obj#：表示等待的对象,和dba_objects中的object_id相对应。
lockwait :该会话等待的锁的地址,与v$lock的kaddr对应.
v$session_wait 查询等待的会话信息。 sid：表示持有锁的会话信息。
Seconds_in_wait：表示等待持续的时间信息
Event：表示会话等待的事件，锁等于enqueue
dba_locks 对v$lock的格式化视图。 Session_id：和v$lock中的Sid对应。
Lock_type：和v$lock中的type对应。
Lock_ID1： 和v$lock中的ID1对应。
Mode_held,mode_requested：和v$lock中的lmode,request相对应。
v$locked_object 只包含DML的锁信息，包括回滚段和会话信息。 Xidusn,xidslot,xidsqn：表示回滚段信息。和v$transaction相关联。
Object_id：表示被锁对象标识。
Session_id：表示持有锁的会话信息。
Locked_mode：表示会话等待的锁模式的信息，和v$lock中的lmode一致。

表3

锁模式 锁描述 解释 SQL操作
0 none
1 NULL 空 Select
2 SS(Row-S) 行级共享锁，其他对象只能查询这些数据行 Select for update
Lock for update
Lock row share
3 SX(Row-X) 行级排它锁,在提交前不允许做DML操作 Insert/update/Delete
Lock row share
4 S(Share) 共享锁 Create index
Lock share
5 SSX(S/Row-X) 共享行级排它锁 Lock share row exclusive
6 X(Exclusive) 排它锁 Alter table
Drop able
Drop index
Truncate table
Lock exclusive

表4

System Type Description System Type Description
BL Buffer hash table instance NA..NZ Library cache pin instance (A..Z = namespace)
CF Control file schema global enqueue PF Password File
CI Cross-instance function invocation instance PI, PS Parallel operation
CU Cursor bind PR Process startup
DF datafile instance QA..QZ Row cache instance (A..Z = cache)
DL Direct loader parallel index create RT Redo thread global enqueue
DM Mount/startup db primary/secondary instance SC System change number instance
DR Distributed recovery process SM SMON
DX Distributed transaction entry SN Sequence number instance
FS File set SQ Sequence number enqueue
HW Space management operations on a specific segment SS Sort segment
IN Instance number ST Space transaction enqueue
IR Instance recovery serialization global enqueue SV Sequence number value
IS Instance state TA Generic enqueue
IV Library cache invalidation instance TS Temporary segment enqueue (ID2=0)
JQ Job queue TS New block allocation enqueue (ID2=1)
KK Thread kick TT Temporary table enqueue
LA .. LP Library cache lock instance lock (A..P = namespace) UN User name
MM Mount definition global enqueue US Undo segment DDL
MR Media recovery WL Being-written redo log instance

Total insert collisions (ogg)

Posted on by

1、错误现象
Replicating from ECP.TAB_UUM_PACKAGE to RWGL.TAB_UUM_USER:
*** Total statistics since 2011-08-05 10:34:10 ***

Total inserts                               20.00
Total updates                                0.00
Total deletes                                0.00
Total discards                               0.00
Total operations                            20.00
Total insert collisions                     20.00

2、错误原因
RWGL.TAB_UUM_USER表上有insert触发器，导致失败。因为触发器使得插入操作为插入和触发器中的操作绑定为了一个整体，现在因为触发器失败，导致插入失败，而且还会丢失该条插入记录，需要查找出该条记录比较困难。

3、解决方案
采用自治事件结合异常捕获
自治事件使得触发器和插入操作相互分离，异常捕获记录触发器失败的原因，插入到日志表中，通过该表，可以查询查失败的记录，然后人工干预，触发器实例：

create or replace trigger ogg_t
  before insert on t_1
  for each row
declare
   tid NUMBER;
   err VARCHAR2(100);
   PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
  SELECT t.id2 INTO tid FROM t_2 t WHERE NAME=:new.Name;
  INSERT INTO t_3 VALUES(tid,:new.name);
  COMMIT;
EXCEPTION
       WHEN TOO_MANY_ROWS THEN
         INSERT INTO t_error VALUES(:new.id,'TOO_MANY_ROWS');
         COMMIT;
        WHEN NO_DATA_FOUND THEN
           INSERT INTO t_error VALUES(:new.id,'NO_DATA_FOUND');
           COMMIT;
         WHEN OTHERS THEN
           err:=SUBSTR(SQLERRM(SQLCODE),1,100);
           INSERT INTO t_error VALUES(:new.id,err);
           COMMIT;
end ogg_t;

1)PRAGMA AUTONOMOUS_TRANSACTION;
自治事务，就是说触发器不管是成功，还是失败，数据库同步程序都能够同步成功数据到目标端

2)COMMIT;
因为采用了自治事件，所以begin end中的操作是独立与数据库中数据，需要单独提交

3)EXCEPTION
添加异常处理

4)INSERT INTO t_error VALUES(:new.id,’TOO_MANY_ROWS’);（类此语句，注意commit）
建立一张错误日志表（根据具体情况决定），如果触发器失败，把错误记录到该表中，以后出现问题查找很方便（要求：通过该表能够查询到那条语句的触发器执行失败。失败原因，失败时间，额外列（用于确定对应记录））

ORA-01012: not logged on

Posted on by

今天接到现场反馈，数据库出现ORA-01012: not logged on错误提示，这个问题上次也出现过一次，当时按照网上说的方法，直接重启数据库了，问题解决了，同时也导致因为数据库重启，现场破坏，而alert日志中无任何异常信息，所以不知从何处下手分析。这次我上数据库准备查看时，发现数据库已经正常，监控也显示正常，说明数据库已经恢复正常。从此我推理这个问题应该是外部因素导致，而不是数据库本身的bug，从而决定要找出该问题的原因来。有个重要的因素，该数据库是我几个月前因为undo损坏做过恢复的，查看相关参数，发现processes是默认值150，是不是该值导致的不敢肯定，因为一般process超了会报ORA-00020错误，而这次只有ORA-01012。但是心中还是没有底，总感觉这个的可能性最大，于是想通过试验来证实下自己的想法
1、数据库版本（10g结果相同）
SQL> select * from v$version where rownum=1;

BANNER
—————————————————————-
Oracle9i Enterprise Edition Release 9.2.0.4.0 – Production

2、创建pfile，修改processes，重启数据库，查看processes值
SQL> select name,value from v$parameter where name=’processes’;

NAME VALUE
——————– ——————–
processes 30

3、查看系统processes数量
SQL> select count(*) from v$process;

COUNT(*)
———-
13

4、添加数据库连接数（为了增加process数目）
[oracle@localhost ~]$ sqlplus chf/xifenfei

SQL*Plus: Release 9.2.0.4.0 – Production on Wed Jul 27 23:11:50 2011

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 – Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 – Production

SQL> !

5、重复3和4，发现当process数量为29时出现激动人心一幕
5.1)继续访问数据库
[oracle@localhost ~]$ sqlplus system/xifenfei

SQL*Plus: Release 9.2.0.4.0 – Production on Wed Jul 27 23:12:06 2011

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

ERROR:
ORA-00020: maximum number of processes (%s) exceeded

Enter user-name:

5.2)使用其他用户访问
[oracle@localhost ~]$ sqlplus /nolog

SQL*Plus: Release 9.2.0.4.0 – Production on Wed Jul 27 23:12:49 2011

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

SQL> conn / as sysdba
Connected to an idle instance.
SQL> select * from dual;
select * from dual
*
ERROR at line 1:
ORA-01012: not logged on

SQL> conn chf/xifenfei
ERROR:
ORA-00020: maximum number of processes (%s) exceeded

[oracle@localhost ~]$ sqlplus “/ as sysdba”

SQL*Plus: Release 9.2.0.4.0 – Production on Wed Jul 27 23:29:52 2011

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected.
SQL> select * from dual;
select * from dual
*
ERROR at line 1:
ORA-01012: not logged on
现象说明：
1)终于发现了ORA-01012错误，期待了很久。发现只有当sys登录系统，对数据库进行查询或者操作之时才会出现ORA-01012，其他用户只要一登录数据库就会提示ORA-00020错误。

2)当process达到数据库最大限时，sysdba登录系统是也显示不正常
2.1）当使用sqlplus “/ as sysdba”登录时，缺少：
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 – Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 – Production
2.2）当使用conn / as sysdba登录时，提示为：
Connected to an idle instance.