Skip to content

Oracle 排障配置与调整 - 18. page

某行维护的一些事,顺便附上自动清除Oracle归档日志的脚本

某银行的数据中心,核心不是Orcale,今年在迁移到Oracle,为此我也做了大量的准备工作,当然这是题外话。这个数据中心可以说是整个行的数据集中地点,从初步搭建到目前的成型,大部分的Oracle数据库以及衍生的相关产品都有我手上实施以及维护的汗水,但是整个中心的配套项目并没有跟上系统的脚步,几十套系统上线,再更新,数据库换平台,性能问题,冗余问题,安全问题,一个个在日常的维护工作中发生。举个例子,有一批的40多套Oracle数据库,10g版本,由行里的工程师安装,在老鸟看来是很简单的工作,但是对于一个赶进度的经理来讲就是一个粗糙的担心过程,在最后一步2个脚本没执行,40多套清一色都没有执行!这在我后期升级数据库的版本工作中,带来不小的麻烦,因为2天之内要升级40多套小系统的Oracle版本!对没错,测试 + 生产!类似这类问题等,还有很多~

配套的设施不完善,比如由于没有备份系统,成型的备份机制,在多次报告(china 的流程)陈述严重性后,经过十多个月,终于要盼来备份系统了~但是这个还只是在招标。为此,我不得不为众多的Oracle Db考虑归档日志的事情(因为我把所有数据库置为归档模式了!TAT!小系统也不放过),客户对一些系统有设置exp的导出备份,由于众多因素,设备也好,人力也好,很多东西不是我们工程师能控制的,所以我都争取保证每个没有备份的db置为归档模式下,采取保留archivelog 最大时间的方式,一般视为空间而定(最多30天吧,也有设置rman备份保留机制,但是只被允许在部分系统上设置),这里就把我把通用的Oracle归档定时清楚脚本粘上来,算是一个小解决方案吧~

步骤一:
在root用户下设置crontab的任务,脚本方式。当然了如果配置了Oracle用户的crontab的执行权限也可以使用oracle相关用户。

0 2 * * * /oracle/delete_arch01.sh >> /oracle/log/`/bin/date +”%Y%m%d”`.log  2>&1

步骤二:
设置脚本delete_arch01.sh,这个脚本的作用是调动oralce用户的归档清除shell脚本,具体如下:

脚本1.
需要注意的是脚本的权限,目录的权限,该脚本为root用户拥有

#delete_arch01.sh
#user:root
#It will excute at am 02:00
#user for delete archivelog of oracle database
su - oracle -c /oracle/delete_arch02.sh

步骤三:
该脚本为oracle用户拥有
设置脚本delete_arch02.sh,这个脚本的作用是登陆rman,使用rman清除7天前的归档日志,
这样做和rm比起来,
一方面可以避开归档日志的刷选问题,
一方面可以将控制文件的相关物理信息更新(以避免dg或者rman中报错)

脚本2.

#delete_arch_02.sh
#user:oracle
#It used by delete_arch_01.sh.
#export ORACLE_SID=xybank
rman target / log=/oracle/log/rman/sxbank_`/bin/date +"%Y%m%d"`_rman.log < <eof
crosscheck archivelog all;
delete noprompt expired archivelog all;
#delete noprompt obsolete; 清除过期的备份
delete noprompt archivelog all completed before 'sysdate - 7';
exit;
EOF

 

重新编译存储过程中遭遇ORA-04021

在今晚的客户现场遭遇了另外一个客户的数据库紧急宕机,处理完毕后这边编译存储过程遭遇ORA-04021,这个错误在编译存储过程的时候比较常遇见,通常这类错误的出现是由于锁的问题导致,一开始运行UTLRP.sql修复整个库的invalid objects,但是修复完后发现还存在1个package body为invalid,
逐用alter方式修复,具体如下:

SQL> @?/rdbms/admin/utlrp.sql

PL/SQL procedure successfully completed.

Table created.

Table created.

Table created.

Index created.

Table created.

Table created.

View created.

View created.

Package created.

No errors.

Package body created.

No errors.

PL/SQL procedure successfully completed.

PL/SQL procedure successfully completed.

SQL> select owner,object_name,object_type from dba_objects where status=’INVALID’ order by owner;

OWNER OBJECT_NAME OBJECT_TYPE
—————————— —————————————- ——————
SYS DBMS_AQ PACKAGE BODY

SQL> alter package DBMS_AQ compile;
alter package DBMS_AQ compile
*
ERROR at line 1:
ORA-04021: timeout occurred while waiting to lock object SYS.DBMS_AQ

遇见这个问题基本上判断是由锁造成,而查锁时候并未发现由锁引起的等待,倒是发现了锁未释放的情况,重启数据库后,再次查询,此对象为valid的状态,由此可见是因为utlrp修复完之后,DBMS_AQ上的锁未释放,导致重新申请修复的时候引发04021

粗心大意的DBA还有SA导致OCR initialization failed accessing OCR device

一个比较大的升级项目,临时发现lv镜像问题,对程序进行Tar包调整相关目录做LV镜像,最后tar解压CRS和DATABASE的程序完成后,发现node1的CRS无法启动了,停止在 /etc/init.d/init.cssd startcheck上,在/tmp目录下找到最新生产的CRS相关的日志发现如下报错:

OCR initialization failed accessing OCR device: PROC-26: Error while accessing the physical storage Operating System error [No such device or address] [6]

通过查找/crs/log/client/xhdb1/alert.log也能够找到相关的日志,要更详细点.到了这一步其中的一个DBA就慌了,又是查RAW权限,又是查系统问题,再确认RAW的权限没问题之后,打算用DD导出OCR的信息进行查看,到这一步被我中止,在加班了将近13个小时情况下大家都已经疲惫了,生怕不小心把数据文件给dd掉了,我便登陆这个节点检测问题,一般碰到此类问题无非几个原因,如下:

1)RAW权限被改,没有读的权限
2)RAW的相关信息被变动过(查看最近的更改时间)
3)RAW所在的VG并未varyonvg
4)bug

按照这上面1个个检测去检测,基本都能找到问题,经过lspv的方式查看了节点1的时候,发现datavg处于inactive状态,问题已经发现了.经过一翻查询发现节点1在重启后HA并没有跟随OS的重启而重启,此时节点2正在运行集群,datavg在节点二上出于并发状态,节点1的HA并未启动也就意味着DATAVG处于OFF状态,最终导致CRS无法读取DATAVG上的OCR信息引起报错。

DD在生产库上,在没有准备的情况下突然要使用,这是对自己和客户的不负责,使用时候需三思。

11.1.0.6升级11.1.0.7遭遇错误“ dtexec dtfile dtsession dtterm dtwm java ksh rpc.ttdbserver ttsession”

平台:AIX 61006
版本:ORACLE 11.1.0.6 REAL APPLICATION CLUSTER and DATABASE
目标升级版本
ORACLE CRS 11.1.0.7.7
ORACLE DATABASE 11.1.0.12

遭遇错误信息
安装过程遭遇错误,错误信息如下

dtexec dtfile dtsession dtterm dtwm java ksh rpc.ttdbserver ttsession.

日志信息如下

639014: execve(“/usr/sbin/fuser”, 0x0000000112BA7DD0, 0x000000011000E0D0) argc: 6
639014: argv: /usr/sbin/fuser -f -x -f -x
639014: /ora/oracle/product/11.1/db_1/bin/oracle

经过查询检验为AIX系统bug,补丁
IZ67400: FUSER GIVES INCORRECT PIDS WITH -X OPTION
APAR is a duplicate of IZ71207

△其次在不打系统补丁的情况下可以通过以下方式解决此类问题

在root用户下操作:
1) 重命名 fuser
mv /usr/sbin/fuser /usr/sbin/fuser_renamed
2) touch /usr/sbin/fuser
3) chmod +x /usr/sbin/fuser

在oracle用户下操作:
1) 在图形界面中点击“try again”重试安装

安装成功后,登陆root用户执行以下操作:
1) rename fuser back to its original name
mv /usr/sbin/fuser_renamed /usr/sbin/fuser