Oracle闪回原理测试(三)(r12笔记第16天)

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:  对于Oracle的闪回,很多朋友也问过问,到底是怎么玩的?如果自己做过一些闪回数据库的操作,就会发现这个功能非常强悍。   Flashback DML的操作其实还蛮容易理解的,但是Flashback DDDL那可就是另外一个level了,我们大概了解一下MySQL里面的闪回就会发现,真要实现无缝的全闪回,确实有很多的细节和场景需要考虑。

 对于Oracle的闪回,很多朋友也问过问,到底是怎么玩的?如果自己做过一些闪回数据库的操作,就会发现这个功能非常强悍。

  Flashback DML的操作其实还蛮容易理解的,但是Flashback DDDL那可就是另外一个level了,我们大概了解一下MySQL里面的闪回就会发现,真要实现无缝的全闪回,确实有很多的细节和场景需要考虑。而Oracle作为一个成熟的商业软件,是不希望我们了解很多底层的细节的,用着好就行,所以如果你想得到一些闪回更细节的东西,这个渠道就非常的窄,我们之前也测试了两期,做了一些简单的对比,这一期就做一些基本的突破,对闪回原理做出进一步的解读。

    这个尝试来源于今天的一个维护更新,今天早间的时候,会按照季度的业务要求DBA做一个统一的批量查询,得到一些数据供审计和策划的同学分析,提前给出一些解决方案,这个事情是大概一周前提的了,而悲剧的是今天到了公司才想起了有这么一回事。而这个时候数据已经被当日的数据更新了,想要得到早间指定时间段的数据就尤为关键,当然我还算是胸有成竹,因为这个备库我开了闪回。所以我可以很快闪回到指定的近期任意时间点,也算是闪回化解了这样一次尴尬的境地。

   当然我在处理问题的时候,还不忘看看闪回的原理,记录日志,其实主要是我对闪回特性的充分自信,要不手心里早都冒汗了。 

   首先确认数据库角色和状态之后,我关闭数据库,准备从mount状态闪回,避免重启数据库。

  下面的错误值得注意,在close这个操作时,还是需要保证数据库的日志应用是终止的,即MRP为停止状态。

SQL> alter database close;
alter database close
*
ERROR at line 1:
ORA-10457: cannot close standby database due to active media recovery我们选择快捷的命令方式,直接关闭日志应用,然后关闭数据库。

SQL> recover managed standby database cancel;
Media recovery complete.
SQL> alter database close;
Database altered.这个操作完成之后,扫了一眼redo和控制文件,已经更新了时间,闪回工作迫在眉睫。我把数据库闪回到了几个小时之前的一个时间点。

SQL> flashback database to timestamp to_timestamp('2017-03-27 07:20:00','yyyy-mm-dd hh24:mi:ss');
Flashback complete.这个过程持续时间很短,所有数据文件的时间戳都更新到了当前的时间点,而其实数据已经闪回到了几个小时之前。

  当然下面的一段日志吸引了我。

Mon Mar 27 10:19:24 2017
flashback database to timestamp to_timestamp('2017-03-27 07:20:00','yyyy-mm-dd hh24:mi:ss')
Flashback Restore Start
Flashback Restore Complete
Flashback Media Recovery Start

 started logmerger process
Parallel Media Recovery started with 24 slaves
Flashback Media Recovery Log /U01/app/oracle/fast_recovery_area/SGCDB2/archivelog/2017_03_27/o1_mf_1_10600_dfjjm98t_.arc
Flashback Media Recovery Log /U01/app/oracle/fast_recovery_area/SGCDB2/archivelog/2017_03_27/o1_mf_1_10601_dfjonfly_.arc
Mon Mar 27 10:19:43 2017
Incomplete Recovery applied until change 234220253426 time 03/27/2017 07:20:01
Mon Mar 27 10:19:43 2017
Flashback Media Recovery Complete
Completed: flashback database to timestamp to_timestamp('2017-03-27 07:20:00','yyyy-mm-dd hh24:mi:ss')上面的几处红字需要格外注意,里面出现了归档日志文件,这个就需要再提一下。我们可以通过日志看出,整个闪回的工作其实分为两大部分,restore和recover,这个和正常恢复数据如出一辙。但是差别也很明显,因为闪回日志是记录的数据变化的逆操作,所以从10:30闪回到7:20,那么这个过程就是10:30-> 7:20左右。

   注意我提到的这个7:20是左右,当然要偏左一些,偏右证明数据还太新了。Restore的这个过程会应用到闪回日志。其实在Oracle中存在一个概念叫做Flashback barrier interval,默认是是30分钟会往闪回日志里写入SCN的标示纪录。所以10:30->7:20的操作你也可以理解为大体是按照10:30->10:00->9:30->9:00->8:30->8:00->7:30->7:00这样的过程。

    完成了基本的还原之后,我们要到达指定时间点的状态,这就需要使用归档文件或者重做日志了,这里的重点就是Flashback Recover的过程了。我们可以通过上面的日志看到,其实应用了两个日志文件,序列号为10600和10601,这个过程该如何更好的验证呢。可以通过如下的SQL来做一个基本的分析,当然这个语句还不够严谨。主要思路就是根据v$archived_log来确定一个边界范围。

set linesize 150 pagesize 100
with maxlogchg as
(select max(first_change#) c1 from v$archived_log where first_change#<=234220253426)     
select name,sequence#,first_change#,next_change# from v$archived_log,maxlogchg where first_change#>=maxlogchg.c1 and first_change#<=234220253426;   整个数据闪回之后,我们就穿越到了之前的一个时间点,可以做我们需要的操作了。

   整个查询的过程持续时间很短,但是得到的这个数据就尤为重要了。根据业务运行一些查询脚本,此处省略查询的SQL语句。

    完成之后,我们只需要alter database close,然后正常open就会更新到最新的一个时间点的数据状态。

SQL>alter database close;
SQL>alter database open
SQL> recover managed standby database disconnect from session;
Media recovery complete.
这个过程的日志其实省略了一些东西,我想也是为了避免给用户带来困扰,因为在日志里反反复复recover,可能会让用户有些疑惑,而我们也可以通过另外一个隐含参数(_flashback_verbose_info)来得到更加详细的日志信息。

  默认得到的正常日志如下:

Mon Mar 27 10:40:06 2017
ALTER DATABASE RECOVER  managed standby database disconnect from session  
Attempt to start background Managed Standby Recovery process (gcdb)
Mon Mar 27 10:40:06 2017
MRP0 started with pid=28, OS id=139822
MRP0: Background Managed Standby Recovery process started (gcdb)
 started logmerger process
Mon Mar 27 10:40:11 2017
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 24 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Delayed for 180 minute(s) (thread 1 sequence 10601)
Completed: ALTER DATABASE RECOVER  managed standby database disconnect from session 通过如上的日志,你看不到很多潜在的recover操作。而整个过程而言却又是必须的。

   通过这个过程我们可以大体看出,整个闪回的过程不是孤立,完全依赖于闪回日志,而同时也是一个Flashback Restore和Flashback Recover的过程。



相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
23天前
|
机器学习/深度学习 JSON 算法
实例分割笔记(一): 使用YOLOv5-Seg对图像进行分割检测完整版(从自定义数据集到测试验证的完整流程)
本文详细介绍了使用YOLOv5-Seg模型进行图像分割的完整流程,包括图像分割的基础知识、YOLOv5-Seg模型的特点、环境搭建、数据集准备、模型训练、验证、测试以及评价指标。通过实例代码,指导读者从自定义数据集开始,直至模型的测试验证,适合深度学习领域的研究者和开发者参考。
179 2
实例分割笔记(一): 使用YOLOv5-Seg对图像进行分割检测完整版(从自定义数据集到测试验证的完整流程)
|
19天前
|
机器学习/深度学习 弹性计算 自然语言处理
前端大模型应用笔记(二):最新llama3.2小参数版本1B的古董机测试 - 支持128K上下文,表现优异,和移动端更配
llama3.1支持128K上下文,6万字+输入,适用于多种场景。模型能力超出预期,但处理中文时需加中英翻译。测试显示,其英文支持较好,中文则需改进。llama3.2 1B参数量小,适合移动端和资源受限环境,可在阿里云2vCPU和4G ECS上运行。
|
23天前
|
JSON 算法 数据可视化
测试专项笔记(一): 通过算法能力接口返回的检测结果完成相关指标的计算(目标检测)
这篇文章是关于如何通过算法接口返回的目标检测结果来计算性能指标的笔记。它涵盖了任务描述、指标分析(包括TP、FP、FN、TN、精准率和召回率),接口处理,数据集处理,以及如何使用实用工具进行文件操作和数据可视化。文章还提供了一些Python代码示例,用于处理图像文件、转换数据格式以及计算目标检测的性能指标。
43 0
测试专项笔记(一): 通过算法能力接口返回的检测结果完成相关指标的计算(目标检测)
|
23天前
|
机器学习/深度学习 并行计算 数据可视化
目标分类笔记(二): 利用PaddleClas的框架来完成多标签分类任务(从数据准备到训练测试部署的完整流程)
这篇文章介绍了如何使用PaddleClas框架完成多标签分类任务,包括数据准备、环境搭建、模型训练、预测、评估等完整流程。
66 0
目标分类笔记(二): 利用PaddleClas的框架来完成多标签分类任务(从数据准备到训练测试部署的完整流程)
|
23天前
|
机器学习/深度学习 JSON 算法
语义分割笔记(二):DeepLab V3对图像进行分割(自定义数据集从零到一进行训练、验证和测试)
本文介绍了DeepLab V3在语义分割中的应用,包括数据集准备、模型训练、测试和评估,提供了代码和资源链接。
129 0
语义分割笔记(二):DeepLab V3对图像进行分割(自定义数据集从零到一进行训练、验证和测试)
|
23天前
|
机器学习/深度学习 数据采集 算法
目标分类笔记(一): 利用包含多个网络多种训练策略的框架来完成多目标分类任务(从数据准备到训练测试部署的完整流程)
这篇博客文章介绍了如何使用包含多个网络和多种训练策略的框架来完成多目标分类任务,涵盖了从数据准备到训练、测试和部署的完整流程,并提供了相关代码和配置文件。
40 0
目标分类笔记(一): 利用包含多个网络多种训练策略的框架来完成多目标分类任务(从数据准备到训练测试部署的完整流程)
|
23天前
|
测试技术 数据安全/隐私保护 Python
自动化测试项目实战笔记(四):测试用户登录(账号密码错误,成功,出现弹框等情况)
本文介绍了使用Selenium进行自动化测试时如何测试用户登录的不同情况,包括账号密码错误、登录成功以及处理登录时出现的弹框,并提供了相应的Python代码实现。
39 0
自动化测试项目实战笔记(四):测试用户登录(账号密码错误,成功,出现弹框等情况)
|
2月前
|
移动开发 JSON Java
Jmeter实现WebSocket协议的接口测试方法
WebSocket协议是HTML5的一种新协议,实现了浏览器与服务器之间的全双工通信。通过简单的握手动作,双方可直接传输数据。其优势包括极小的头部开销和服务器推送功能。使用JMeter进行WebSocket接口和性能测试时,需安装特定插件并配置相关参数,如服务器地址、端口号等,还可通过CSV文件实现参数化,以满足不同测试需求。
201 7
Jmeter实现WebSocket协议的接口测试方法
|
2月前
|
JSON 移动开发 监控
快速上手|HTTP 接口功能自动化测试
HTTP接口功能测试对于确保Web应用和H5应用的数据正确性至关重要。这类测试主要针对后台HTTP接口,通过构造不同参数输入值并获取JSON格式的输出结果来进行验证。HTTP协议基于TCP连接,包括请求与响应模式。请求由请求行、消息报头和请求正文组成,响应则包含状态行、消息报头及响应正文。常用的请求方法有GET、POST等,而响应状态码如2xx代表成功。测试过程使用Python语言和pycurl模块调用接口,并通过断言机制比对实际与预期结果,确保功能正确性。
219 3
快速上手|HTTP 接口功能自动化测试
|
1月前
|
JavaScript 前端开发 API
vue尚品汇商城项目-day02【9.Home组件拆分+10.postman测试接口】
vue尚品汇商城项目-day02【9.Home组件拆分+10.postman测试接口】
37 0

推荐镜像

更多