记一次备份发起时间延后问题

下午接到某业务DBA电话，某某业务资源比较繁忙，说备份发起时间由原来的12点延迟到13点半了。

经过查询确实备份时间一般在中午12点就发起，结果今天在1点半发起，1点半为上班时间再加上备份资源占用肯定高。经过业务组同意暂时先停掉该业务的job和策略。后接到反馈资源使用下来了。

问题暂时解决但需要查明原因为啥备份发起时间延后1.5小时。

查询备份发起时间结束时间等相关信息：

COL STATUS FORMAT a9

COL hours FORMAT 999.999

COL START_TIME for a20

COL END_TIME for a20

set linesize 200

SELECT SESSION_KEY, INPUT_TYPE, STATUS,

TO_CHAR(START_TIME,‘yyyy-mm-dd hh24:mi‘) start_time,

TO_CHAR(END_TIME,‘yyyy-mm-dd hh24:mi‘)   end_time,

ELAPSED_SECONDS/3600                   hours

FROM V$RMAN_BACKUP_JOB_DETAILS

ORDER BY SESSION_KEY;

查出如下：

仔细检查看原来在12点钟发起备份，备份到13点18分备份异常，查看备份STATUS发现状态是FAILED。

接下来就明了了，该业务确实在12点钟发起，但是在13点18分备份失败，由于该业务的备份时间窗口为12点-16点。业务备份失败后还在时间窗口内故在13点29分继续发起备份操作。至于开始时间是13点29的备份那是手动取消的job关掉备份策略引起的所以备份是失败的。至于12点备份失败的原因由于备份脚本输出日志被覆盖，无法定位，怀疑可能就是该业务设备资源繁忙导致rman备份进程异常终止。

同样有个业务也是如此：

时间： 2024-08-24 22:44:08

记一次备份发起时间延后问题的相关文章

《Effective C++》之条款26：尽可能延后变量定义式的出现时间

<Effective C++> 条款26:尽可能延后变量定义式的出现时间 只要你定义了一个变量而其类型带有一个构造函数和析构函数,那么当程序的控制流到达这个变量定义式时,你便得承受构造成本:当这个变量离开作用域时,你便得承受析构成本.即使这个变量最终并未被使用,仍需耗费这些成本,所以你应该尽量避免这种情形. 对于"尽可能延后"的理解: 不只应该延后变量多的定义,直到非得使用该变量的前一刻为止,甚至应该尝试延后这份定义直到能够给它初始实参为止.如果这样,不仅能够避免构造(析构

Effective C++ Item 26 尽可能延后变量定义式的出现时间

本文为senlie原创,转载请保留此地址:http://blog.csdn.net/zhengsenlie 经验:尽可能延后变量定义式的出现.这样做可增加程序的清晰度并改善程序效率. 示例: //这个函数过早定义变量"encrypted" std::string encryptPassword(const std::string &password){ using namespace std; string encrypted; if(password.length() <

Effective C++：条款26：尽可能延后变量定义式的出现时间

(一) 那么当程序的控制流到达这个变量定义时,变承受构造成本:当变量离开作用域时,便承受析构成本. string encryptPassword(const std::string& password) { using namespace std; string encrypted; if(password.length() < MinimumPasswordLengt) { throw logic_error("Password is too short") } -//

C++(Qt)之尽可能延后定义式的出现时间

最近在看Scott Meyers的<Effective C++>改善程序与设计的55个具体做法(第三版),水平有限,有些东西没能完全理解,捡一些自己能理解的并很容易记住的点来分享下!有的是原文的内容的直接摘抄,敬请谅解! 这条建议是:尽可能地延后定义式的出现时间.这么做的意义在于:可增加程序的清晰度并改善程序的效率.这对小程序来说可能体会的不深或者说影响不大,但是我们依然要保持良好的代码习惯和提高代码段的质量,不是吗? 作者给的解释是:只要你定义了一个变量而其类型带有一个构造函数或者析构函数,

[Effective C++ --026]尽可能延后变量定义式的出现时间

引言 每一次构造和析构都需要成本,因此我们在设计代码的时候,应该尽可能考虑到构造和析构的成本. 第一节 延后实现 考虑有以下的代码: 1 void encrypt(string& s); 2 string encryptPassword(const sting& password) { 3 string encrypted; 4 if (xxxxx) { 5 throw logic_error("xxxxxx"); 6 } 7 encrypted = password;

泛函编程（11）－延后计算－lazy evaluation

延后计算(lazy evaluation)是指将一个表达式的值计算向后拖延直到这个表达式真正被使用的时候.在讨论lazy-evaluation之前,先对泛函编程中比较特别的一个语言属性”计算时机“(strict-ness)做些介绍.strict-ness是指系统对一个表达式计算值的时间点模式:即时计算的(strict),或者延后计算的(non-strict or lazy).non-strict或者lazy的意思是在使用一个表达式时才对它进行计值.用个简单直观的例子说明吧: 1 def lazy

支付宝推“移动花卡”：花呗账单延后还

近日,支付宝APP中放出预告,近日将推出一款互联网SIM卡套餐,能够实现花呗账单延后还. 据了解,这款SIM卡套餐是中国移动与花呗联合推出的,名叫“移动花卡”,既可以办新卡,也可以换套餐,每月48元,目前流量及免流APP未知. 支付宝推“移动花卡”:花呗账单延后还 其提供6大生活福利: 1.花呗延后至少5天,每月15号再还款 2.花呗便利店月卡满10减2,每天可享受一次. 3.虾米音乐会员180天 4.饿了么红包,满35减3,每月8张. 5.花呗短信提醒服务,花呗交易金额超50元以上时会收到短信

记一次Oracle Clusterware成功安装后的故障处理

记一次Oracle Clusterware安装成功后的故障处理 1. 环境 [[email protected] rac1]$ cat /etc/issue Red Hat Enterprise Linux Server release 5.8 (Tikanga) Kernel \r on an \m 2. 问题描述在安装RAC的过程中, 成功安装好grid (clusterware) 后关闭了各节点. 在下次开启各节点后, 检查crs资源状态, 出现如下错误: [[email protecte

java 根据当天时间 获取前7天之间的时间 和后多少天的查询时间

java 根据当天时间 获取前7天之间的时间  和后多少天的查询时间 package com.kugou.schedu.service; import java.text.ParseException; import java.text.SimpleDateFormat; import java.util.Calendar; import java.util.Date; import java.util.GregorianCalendar; import org.springframework.