关于跨resetlog恢复

本文详细解析了在 Oracle 10.2.0.4.0 库下,通过全备份在 logsequence 为 3 和 4 之间的特定时间点进行不完全恢复,并在后续进行更改和归档操作后,如何通过全备份进行完全恢复,直至 resetlogs 后更改的部分。重点在于恢复过程中的细节与逻辑。
Oracle  10.2.0.4.0     Windows 2003  


假设10.2.0.4.0 库 test  生成的log sequence 分别是 1,2,3,4,5,6,7,8,9  ,
在log sequence 为 3,4之间的时间点做了一个全备份(RMAN),  现在我们做不完全恢复到
log sequence 为 5 的地方,  将数据库open resetlogs ,  同时做一些更改并做两次归档(log
日志被重置为1,2),这时我们再通过前面的全备份对系统做一次完全恢复,   系统恢复到上一个
前一个数据库resetlogs部分后, 继续向后恢复resetlogs新库产生的归档 (sequence 1, 2 )  ,  
恢复后可以看到resetlogs之后更改的部分,   大概的图示如下(使用非catalog备份):



原库log sequence(在3,4之间做了全备) :  
1            2            3                 4            5            6            7             8           9   
--------------------------- fullbak   



用fullbak恢复到sequence 5 时间点 :   
---------------------------------------------resetlogs
-------------------------------------------------------------1         2    (做更改并归档2次)  



再次使用前面的fullbak做完全恢复:
--------------------------fullbak     4                           1          2      (跨resetlogs恢复 1,2)   




有一个疑问,  最后一次做完全恢复的时候, 备份恢复不是应用 4, 5, 6, 7, 8, 9 归档, 而是
应用  4, 1, 2  。   是因为 目标库控制文件记录了第二次不完全恢复 resetlogs , 这次记录或更新
主要是做了什么动作,  可以让RMAN恢复的时候应用 4, 1, 2  这样的恢复  ?  


这个恢复过程和使用   reset database to incation  xxnum ;   实现跨resetlogs 恢复是一样的 ?

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

转载于:http://blog.itpub.net/35489/viewspace-706116/

【SCI复现】基于纳什博弈的多微网主体电热双层共享策略研究(Matlab代码实现)内容概要:本文围绕“基于纳什博弈的多微网主体电热双层共享策略研究”展开,结合Matlab代码实现,复现了SCI级别的科研成果。研究聚焦于多个微网主体之间的能源共享问题,引入纳什博弈理论构建双层优化模型,上层为各微网间的非合作博弈策略,下层为各微网内部电热联合优化调度,实现能源高效利用与经济性目标的平衡。文中详细阐述了模型构建、博弈均衡求解、约束处理及算法实现过程,并通过Matlab编程进行仿真验证,展示了多微网在电热耦合条件下的运行特性和共享效益。; 适合人群:具备一定电力系统、优化理论和博弈论基础知识的研究生、科研人员及从事能源互联网、微电网优化等相关领域的工程师。; 使用场景及目标:① 学习如何将纳什博弈应用于多主体能源系统优化;② 掌握双层优化模型的建模与求解方法;③ 复现SCI论文中的仿真案例,提升科研实践能力;④ 为微电网集群协同调度、能源共享机制设计提供技术参考。; 阅读建议:建议读者结合Matlab代码逐行理解模型实现细节,重点关注博弈均衡的求解过程与双层结构的迭代逻辑,同时可尝试修改参数或扩展模型以适应不同应用场景,深化对多主体协同优化机制的理解。
03-17
### 关于DTC和DCO的概念及其技术实现 #### 什么是分布式事务协调器(Distributed Transaction Coordinator, DTC) Microsoft Distributed Transaction Coordinator (MS DTC) 是一种用于管理多个资源管理器(如数据库、文件系统或其他支持事务的组件)之间的分布式事务的技术。如果某个事务涉及多个数据源的操作,则 MS DTC 负责确保这些操作要么全部成功提交,要么完全回滚[^1]。 当遇到诸如 `The Microsoft Distributed Transaction Coordinator (MS DTC) has cancelled the distributed transaction` 这样的错误时,通常表明 DTC 配置不正确或服务未正常运行[^2]。在这种情况下,可以尝试手动启动 DTC 服务或将计算机重新启动来解决问题[^3]。 #### 实现细节和技术背景 为了使分布式事务能够顺利执行,DTC 使用两阶段提交协议(Two-phase Commit Protocol)。该协议分为准备阶段和提交阶段: - **准备阶段**: 所有的参与者被询问是否准备好完成它们的任务,并锁定必要的资源。 - **提交阶段**: 如果所有参与者都同意继续,则通知它们正式提交更改;如果有任何一个失败,则整个过程会被撤销。 这种机制保证了一致性和原子性——即使在网络中断的情况下也能维持系统的完整性[^4]。 #### 常见问题及解决方案 有时会碰到无法启动 DISTRIBUTED TRANSACTION COORDINATOR 的情况。这可能是因为缺少某些关键的日志文件所致。通过以下步骤可恢复其功能: 1. 打开命令提示符窗口; 2. 输入 `msdtc -resetlog` 来重建日志记录; 3. 接着用 `net start msdtc` 启动服务即可恢复正常运作[^5]。 #### DCO 技术概述 虽然这里提到的是 DTC,但实际上还存在另一种称为 DCO (Data Control Object) 的技术框架,主要用于简化应用程序访问远程对象的方式。然而,在实际应用领域中,“DCO”这一术语并不像 “DTC”那样广泛普及,因此具体差异需依据上下文环境进一步探讨。 ```python import os os.system('msdtc -resetlog') os.system('net start msdtc') print("DTC service restarted successfully.") ``` 上述脚本展示了如何利用 Python 自动化处理重设 DTC 日志以及重启服务的过程。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值