06.14.08
Posted in Oracle管理 at 3:31 am by David.Guo
最近的怪事蛮多。
首先是那天我晚班，下午去公司，同事说下午2点左右地震了，我靠，那可是6月12日，难道是汶川地震1个月的纪念，再问下去，原来是那个时候一台伟大的DS8300可能是站着太累了，居然在机房去睡了会，1.4吨的家伙，这么一睡，那动作和地震差不多。晚饭后去机房看望了下这哥们，嗯，这是第一次我有意识的去看8300，结果还是刚睡醒的，这种看8300倒地的机会还真不多，可惜我去看望的时候8300已经站起来了，不过没人敢给它上电了。有多少人见过8300倒地呀？
今天晚上在家值班的时候，收到电话，晚上要重新起停一个rac库。不是很重要的系统，所以服务器也不是很好，IBM P560Q而已，也没怎么在意，这种活已经习惯了，都不会紧张了，先把库拉掉，很正常，然后IBM的哥们在机房给加内存，装好了，HA起来，正常，然后我拉库。拉呀，第一个节点起来正常，拉第二个节点呗，启动到nomount就不动了，检查alert.log
at Jun 14 02:46:52 2008
lmon registered with NM - instance id 2 (internal mem no 1)
Sat Jun 14 02:52:41 2008
Reconfiguration started (old inc 0, new inc 1)
List of nodes:
1
Global Resource Directory frozen
one node partition
Communication channels reestablished
Master broadcasted resource hash value bitmaps
Non-local Process blocks cleaned out
Resources and enqueues cleaned out
Resources remastered 0
0 GCS shadows traversed, 0 cancelled, 0 closed
0 GCS resources traversed, 0 cancelled
set master node info
Submitted all remote-enqueue requests
Update rdomain variables
Dwn-cvts replayed, VALBLKs dubious
All grantable enqueues granted
0 GCS shadows traversed, 0 replayed, 0 unopened
Submitted all GCS remote-cache requests
0 write requests issued in 0 GCS resources
0 PIs marked suspect, 0 flush PI msgs
也没啥好看的，把先拉起来的节点down掉，2号节点就立刻起来了。这问题好像以前见过，我记得好像是如果参数cluster_interconnects不对的话，会有这种问题，嗯，那就整呗，这个参数也正常，每个instance单独起来都会对。难道是，莫非是见鬼了，ok，再想想，似乎两个主机交换的hacmp的网络会引起这种问题，先检查tty0，正常，再检查网卡的参数MTU，也正常。
无论如何，我一定坚信，这个是HA的问题或者是网络的问题，明显资源有问题。再看看metalink，发现也是这些东西，但是metalink说的这些都没有问题的，继续折磨IBM的哥们，让他们去查网络，终于，10分钟后，有好消息了，RAC的网络光纤出现了问题，我靠，不就是下个电吗，有这么麻烦的加内存动的是前面，又不是后面，光纤，你咋坏了列。赶紧的兄弟们换光纤线，重新拉库。正常了。
不是8300倒地，就是光纤不行，是我该去烧香，还是IBM的哥们该去了列？
Permalink
03.31.08
Posted in Oracle管理 at 3:01 pm by David.Guo
相信很多DBA会在系统中来个LOGON_AUDIT,目的就是避免某些未经过授权的机器登陆了数据库.
这事在我们这也有.为了防止从办公网络试用生产账号登陆生产主机非法获取用户信息(因为我们的生产账号是不作审计的,个人账号作审计,因此要避免生产账号从办公网络登陆主机),我们写了个LOGON_AUDIT的触发器,如下:
CREATE OR REPLACE TRIGGER sys.LOGON_AUDIT
AFTER LOGON ON DATABASE
declare
lv_user varchar2(100);
lv_host varchar2(100);
lv_schema varchar2(100);
lv_suser varchar2(100);
lv_ip varchar2(100);
BEGIN
select sys_context(‘USERENV’, ‘HOST’),
sys_context(‘USERENV’, ‘CURRENT_USER’),
sys_context(‘USERENV’, ‘CURRENT_SCHEMA’),
sys_context(‘USERENV’, ‘SESSION_USER’),
sys_context(‘USERENV’, ‘IP_ADDRESS’)
into lv_host, lv_user, lv_schema, lv_suser, lv_ip
from dual;
if lv_suser = ‘USERNAME’ then
if substr(lv_ip, 1, 
in (‘xx.xx.xx’)
or lv_ip is null
then
null ;
else
RAISE_APPLICATION_ERROR(-20001, ‘CONNECTIION REFUSED’||lv_ip);
end if;
end if;
END;
测试的时候,通过,可是在正式使用中,却发现有的生产主机没有办法拒绝办公网络的登陆.那就查问题呗.
查来查去,发现似乎应该是权限的问题.在检查,发现凡是不能拒绝办公网络登陆的数据库用户有一个IMP_FULL_DATABASE的角色.这个角色的权限非常的高,仔细检查这个角色的权限,发现其中有一个权限为:ADMINISTER DATABASE TRIGGER,将这个权限从用户上revoke后,登陆就会被拒绝,如果将这个权限授予用户,就会避开系统的LOGON_AUDIT触发器,能继续登陆,问题是找到了,啥时候能重新授权列,只能等待,慢慢的等到系统上线或者例行维护的时候了,这个权限的重新授予风险还是很高的.不过问题找到了就ok.
Permalink
03.11.08
Posted in Oracle管理 at 5:56 am by David.Guo
alert日志应该所有的dba都很熟悉了,不过有多少人见过alert日志中报这个玩意的吗?
Completed checkpoint up to RBA [0×1e4ec.2.10], SCN: 0×0795.503eefc3
Tue Mar 11 01:28:29 2008
WARNING! CONTROLFILE SEQUENCE NUMBER TOO OLD, RE-READING…
WARNING! CONTROLFILE SEQUENCE NUMBER TOO OLD, RE-READING…
WARNING! CONTROLFILE SEQUENCE NUMBER TOO OLD, RE-READING…
********************* ATTENTION: ********************
The controlfile header block returned by the OS
has a sequence number that is too old.
The controlfile might be corrupted.
PLEASE DO NOT ATTEMPT TO START UP THE INSTANCE
without following the steps below.
RE-STARTING THE INSTANCE CAN CAUSE SERIOUS DAMAGE
TO THE DATABASE, if the controlfile is truly corrupted.
In order to re-start the instance safely,
please do the following:
(1) Save all copies of the controlfile for later
analysis and contact your OS vendor and Oracle support.
(2) Mount the instance and issue:
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
(3) Unmount the instance.
(4) Use the script in the trace file to
RE-CREATE THE CONTROLFILE and open the database.
*****************************************************
Instance terminated by ARC0, pid = 20705
反正是我第一次见到alert中报这个的,oracle还是很友好的,在alert中已经明确的告诉我们该怎么处理这种情况.
Permalink
03.10.08
Posted in Oracle管理 at 2:18 am by David.Guo
作一次系统的容灾切换,需要多长时间,统计了下
准备工作部分:
检查容灾数据库的listener.ora,init.ora,tnsnames.ora,耗时10分钟;
检查应用服务器的tnsnames.ora,耗时60分钟;
检查容灾数据库的参数,耗时30分钟;
切换前最后一次数据BC,耗时90分钟;
正式切换部分:
停止数据库实例,3分钟/node,可并行;
停止监听,30s/node,可并行;
停止CA,3分钟;
网络切换域名,1分钟;
拉起备机HA,10分钟;
拉起容灾数据库实例,10分钟/node,可并行;
拉起容灾数据库监听,30s/node,可并行;
切换后工作:
等待应用测试完毕(测试不通过则重新拉起原来的主机),180分钟++.
由此可见,一次容灾切换,最消耗时间的部分,并不是真正执行的时候,而是准备工作和配合应用测试,对于数据库来说,最重要的是保证其他外部文件,什么参数文件,监听文件,tns文件正常,真正停止和启动数据库,时间很短,可见作好准备工作多么重要.
Permalink
01.23.08
Posted in Oracle管理 at 10:19 am by David.Guo
上午收到一个task,要在下周重建一个数据库的控制文件,生产系统,非常非常大的生产系统,好不容易等到一个停机的机会.
task的内容很简单,要求将控制文件中的参数maxdatafiles修改到4000,目前是1238.这个值很奇怪.一般应该没有人会设置这么个值来玩的,1024,2048这些值还有可能是创建的时候整的,1238,这个值真奇怪,难道是创建数据库的人认为这个是幸运数字?
检查该数据库,发现确实数据文件已经快到这个数目了.重建控制文件,风险太高.其实在生产系统上,改啥风险都很高的.检查了兄弟们发过来的邮件,似乎确实要调整了.
ok,说实话,以前还真没在生产系统上去重建控制文件修改这些玩意,在自己的Laptop上先测试一下.修改到是没有问题.但是还是要想想,这玩意是不是有风险.
搜索metalink,找到doc 101020.1以及119507.1,根据101020.1上的说法,在oracle8以后,maxdatafiles参数会自动扩展,一直会扩展到初始化参数db_files为止.而依据119507.1的说法,为什么要有这个玩意的限制,是因为OS平台的存储导致的,文档中也有说明限制,反正在我的平台上,每个tablespace可以到1022个,每个数据库可以到65534个,也就是说,都是2^N-2个.
不过在两个文档中都提到数据库中最大的文件数,是不可以超过初始化参数db_files的.
在101020.1中是如此描述的:
The routine that performs the expansion writes this message to the alert log.
The messages specifies the section that was expanded and the amount of
the expansion. Please note that this message cannot be turned off.The automatic expansion only occurs up to the limit of the “init.ora” parameter
“DB_FILES”.
在119507.1中是如此描述的:
3. Especially for Oracle8+ you should make sure that you do not encounter an
error against the maximum number of open database files (DB_FILES). It is
more likely that the value for DB_FILES is too low since the controlfile in
Oracle8 expands automatically as long as the number of the added datafile is
lower then the value for DB_FILES. Normally the error message should
indicate this: ORA-00059 : maximum number of DB_FILES exceeded
检查该系统的alert_.log,果然发现了如下类似的记录: Fri Aug 17 13:52:35 2007
kccrsz: expanded controlfile section 4 from 1024 to 1126 records
requested to grow by 102 record(s); added 1 block(s) of records
Mon Dec 31 11:17:18 2007
kccrsz: expanded controlfile section 4 from 1126 to 1238 records
requested to grow by 112 record(s); added 1 block(s) of records
那么,就是说,我的系统已经自动扩展过两次,才扩展到这么个奇怪的值的,也就是说没有问题了,不用重建控制文件了.生产系统,还是不整我比较能睡的着.
Permalink
« Previous entries ·