备份脚本执行失败一例

 

随着技术环境的不断发展和增加，运维部门面对的运行环境呈现大规模和复杂两个趋势。一两个运维人员管理公司成百上千台服务器的情况将来会是常见的事情。这个时候，集中监控、自动运维平台是解决问题最好的方法。本篇我们就介绍一个切换到集中备份环境中出现的小问题。

 

1、问题说明

 

一个原先在Windows环境上运行的Oracle服务器，原来是使用服务器上自己编写的脚本进行备份。执行脚本通过windows的计划任务调用执行，长期没有任何问题。

有一天负责服务器的同事突然联系，说连续几天备份过程失败。在日志上，明确显示失败。
  一般情况下，生产环境各种配置是比较稳定的，不会有特别的变更。笔者要来了错误日志查看。

 

 

恢复管理器: Release 10.2.0.1.0 - Production on 星期六 1月 4 22:13:05 2014

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

RMAN> connect target *

2> run{

3> backup database plus archivelog delete input;

4> crosscheck archivelog all;

5> delete noprompt expired backupset;

6> delete noprompt obsolete;

7> }

8>

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

ORA-01031: insufficient privileges

 

恢复管理器完成。

 

 

 

报错内容不存在语句命令的情况，而是执行权限错误。而之前的日志显示，相同的备份执行一直没有问题，脚本也没有修改。

 

2、问题分析

 

调用脚本是两个文件，Windows的BAT和RMAN的txt文件。Rman_bk.bat是主要的执行对象，脚本如下：

 

rman nocatalog @backup_command.txt Log=rman_log1.log append

 

命令脚本backup_command.txt如下：

 

connect target /

run{

backup database plus archivelog delete input;

crosscheck archivelog all;

delete noprompt expired backupset;

delete noprompt obsolete;

}

 

执行报错权限错误，最大的可能是在操作系统用户匿名登录时候，被拒绝。此时可以试验一下用操作系统用户是不是可以用sqlplus登录。

 

 

默认登录没有什么问题，说明匿名登录机制没有被修改。手工执行bat文件，实验结果如下：

 

 

执行过程看似正常，备份日志信息如下：

 

恢复管理器: Release 10.2.0.1.0 - Production on 星期三 1月 8 17:12:47 2014

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

 

RMAN> connect target *

2> run{

3> backup database plus archivelog delete input;

4> crosscheck archivelog all;

5> delete noprompt expired backupset;

6> delete noprompt obsolete;

7> }

8>

连接到目标数据库: OTSTEST (DBID=2884314031)

使用目标数据库控制文件替代恢复目录

 

启动 backup 于 08-1月 -14

当前日志已存档

分配的通道: ORA_DISK_1

通道 ORA_DISK_1: sid=132 devtype=DISK

通道 ORA_DISK_1: 正在启动存档日志备份集

（篇幅原因，有省略……）

输入存档日志线程 =1 序列 =4151 记录 ID=1144 时间戳=835178418

 

手工执行脚本没有问题。看似很诡异的问题~

 

3、猜想与解决

 

询问同事最近的环境变化情况，了解到一个细节：运维部门同意将服务器纳入到集中备份环境。由于环境的差异，运维部门只是负责调用各自的备份程序（自己编写），之后将备份拷贝到集中磁带上。

 

这样引起的笔者的一个猜想：手工执行和报错执行一个很大的差异就是登陆权限。不同的操作系统用户登录，在权限上是有所不同的。

 

对Oracle而言，操作系统因素有两个方面，一个是环境变量（$ORACLE_SID等），另一个是系统角色。在Linux/AIX下，环境变量我们通常设置在用户的层面，使用oracle登录之后，环境变量自动设置。角色上，我们也创建了dba组进行配比。

 

在Windows上，相同的设置也是存在的。环境变量是以注册表键值的方式保存在全局。而管理员角色是以组策略的方式设置，名称为ora_dba。

 

对Oracle本机上的匿名登录，如果我们没有将操作系统用户设置在dba组里面，是可能登录失败的。

 

解决问题的思路有两个：一种策略是分析出集中备份环境的登录用户，将其加入到dba操作系统用户组里面。另一种方法是进行密码登陆，不使用/登陆。

 

笔者建议使用第二个方法，修改脚本如下：

 

connect target sys/oracle

run{

backup database plus archivelog delete input;

crosscheck archivelog all;

delete noprompt expired backupset;

delete noprompt obsolete;

}

 

转到第二天再次执行备份脚本，执行日志如下：

 

 

恢复管理器: Release 10.2.0.1.0 - Production on 星期三 1月 8 20:00:01 2014

 

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

 

RMAN> connect target *

2> run{

3> backup database plus archivelog delete input;

4> crosscheck archivelog all;

5> delete noprompt expired backupset;

6> delete noprompt obsolete;

7> }

8>

连接到目标数据库: OTSTEST (DBID=2884314031)

使用目标数据库控制文件替代恢复目录

 

启动 backup 于 08-1月 -14

当前日志已存档

分配的通道: ORA_DISK_1

 

存档日志文件名 =D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\OTSTEST\ARCHIVELOG\2014_01_08\O1_MF_1_4181_9DTHG3N5_.ARC 记录 ID=1174 时间戳 =836337603

完成 backup 于 08-1月 -14

 

备份成功，问题解决。

 

4、结论

 

我们在实际工作中，会遇到各种各样的问题。这也就是为什么实践是成长的关键原因。综合各种知识能力，层层剥离，合理假设，可以帮助我们解决问题。

 

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/17203031/viewspace-1068929/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/17203031/viewspace-1068929/