Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >小知识:什么叫做workaround?

小知识:什么叫做workaround?

作者头像
Alfred Zhao
发布于 2023-08-24 09:10:48
发布于 2023-08-24 09:10:48
48000
代码可运行
举报
运行总次数:0
代码可运行

技术人当遇到具体问题,能给出的各种解决方案,有一种类型叫做workaround,翻译过来通常为“应变方法”、“变通方法”; 其实这种方式通常是没有找到根本的解决方案,但是为了快速恢复业务而采用的一种巧妙规避/跳过的方式。

举个具体的例子:我有测试需求要在主库创建一个新的PDB:

1.创建新的PDB

创建一个专门存放AWRDUMP的PDB

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
CREATE PLUGGABLE DATABASE awr
  ADMIN USER awr IDENTIFIED BY awr
  ROLES = (dba)
  DEFAULT TABLESPACE tbs_awr
    DATAFILE '/flash/oradata/DEMO/awr/awr01.dbf' SIZE 250M AUTOEXTEND ON maxsize 10G
  FILE_NAME_CONVERT = ('/flash/oradata/DEMO/pdbseed/',
                       '/flash/oradata/DEMO/awr/')
  STORAGE (MAXSIZE 2G)
  PATH_PREFIX = '/flash/oradata/DEMO/awr/';

主库创建成功没问题。

2.发现DG备库出现同步问题

发现备库没有同步,排查alert日志发现因为这个awr的目录不会自动创建,导致报错,最终引发MRP进程终止,详细告警日志如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
2023-03-15T18:03:53.650192+08:00
Recovery of Online Redo Log: Thread 1 Group 11 Seq 446 Reading mem 0
  Mem# 0: +DATADG/DEMORAC/ONLINELOG/group_11.276.1127389115
PR00 (PID:11733): Media Recovery Waiting for T-1.S-447 (in transit)
2023-03-15T18:03:55.023213+08:00
Recovery of Online Redo Log: Thread 1 Group 13 Seq 447 Reading mem 0
  Mem# 0: +DATADG/DEMORAC/ONLINELOG/group_13.278.1127389119
2023-03-15T18:38:28.999341+08:00
Recovery created pluggable database AWR
Automatic Copy of Standby datafiles for create pdb failed with            error - 65169. Files need to be copied manually
2023-03-15T18:38:29.121847+08:00
Errors in file /u01/app/oracle/diag/rdbms/demorac/jydb1/trace/jydb1_pr00_11733.trc:
ORA-65169: error encountered while attempting to copy file +DATADG/DEMORAC/pdbseed/system01.dbf
ORA-19504: failed to create file "+DATADG/DEMORAC/awr/system01.dbf"
ORA-17502: ksfdcre:4 Failed to create file +DATADG/DEMORAC/awr/system01.dbf
ORA-15173: entry 'awr' does not exist in directory 'DEMORAC'
PR00 (PID:11733): MRP0: Background Media Recovery terminated with error 1274
2023-03-15T18:38:29.188919+08:00
Errors in file /u01/app/oracle/diag/rdbms/demorac/jydb1/trace/jydb1_pr00_11733.trc:
ORA-01274: cannot add data file that was originally created as '/flash/oradata/DEMO/awr/system01.dbf'
ORA-01565: error in identifying file '+DATADG/DEMORAC/awr/system01.dbf'
ORA-17503: ksfdopn:2 Failed to open file +DATADG/DEMORAC/awr/system01.dbf
ORA-15173: entry 'awr' does not exist in directory 'DEMORAC'
2023-03-15T18:38:29.195972+08:00
.... (PID:5407): Managed Standby Recovery not using Real Time Apply
2023-03-15T18:38:29.340321+08:00
Recovery interrupted!

IM on ADG: Start of Empty Journal

IM on ADG: End of Empty Journal
Recovered data files to a consistent state at change 23401386
2023-03-15T18:38:29.903857+08:00
Increasing priority of 2 RS
Reconfiguration started (old inc 6, new inc 8)
List of instances (total 2) :
 1 2
My inst 1
 Global Resource Directory frozen
 Communication channels reestablished
 Master broadcasted resource hash value bitmaps
 Non-local Process blocks cleaned out
2023-03-15T18:38:29.983551+08:00
 LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2023-03-15T18:38:29.986436+08:00
 LMS 1: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
 Set master node info
 Dwn-cvts replayed, VALBLKs dubious
 All grantable enqueues granted
Reconfiguration complete (total time 0.3 secs)
Decreasing priority of 2 RS
2023-03-15T18:38:30.492490+08:00
Stopping change tracking
2023-03-15T18:38:30.501521+08:00
Errors in file /u01/app/oracle/diag/rdbms/demorac/jydb1/trace/jydb1_pr00_11733.trc:
ORA-01274: cannot add data file that was originally created as '/flash/oradata/DEMO/awr/system01.dbf'
ORA-01565: error in identifying file '+DATADG/DEMORAC/awr/system01.dbf'
ORA-17503: ksfdopn:2 Failed to open file +DATADG/DEMORAC/awr/system01.dbf
ORA-15173: entry 'awr' does not exist in directory 'DEMORAC'
2023-03-15T18:38:30.524601+08:00
Background Media Recovery process shutdown (jydb1)

3.如何解决?

如果是找根本解决方案,那就是要研究为何无法自动创建成功,是否能够自动创建成功,具体的改进方案? 如果一时找不到方案,急于恢复同步,那其实手工创建这个目录,然后重新开启同步,就能快速解决,但这种解决方式就叫做workaround:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
ASMCMD> pwd
+DATADG/DEMORAC
ASMCMD> mkdir AWR


SQL> recover managed standby database disconnect;
Media recovery complete.
SQL> set lines 180
SQL> col name for a22
SQL> col value for a22
SQL> select * from v$dataguard_stats;
SOURCE_DBID SOURCE_DB_ NAME		      VALUE		     UNIT			    TIME_COMPUTED		   DATUM_TIME			      CON_ID
----------- ---------- ---------------------- ---------------------- ------------------------------ ------------------------------ ------------------------------ ----------
	  0	       transport lag	      +00 00:00:00	     day(2) to second(0) interval   03/15/2023 20:23:51 	   03/15/2023 20:23:50			   0
	  0	       apply lag	      +00 00:00:00	     day(2) to second(0) interval   03/15/2023 20:23:51 	   03/15/2023 20:23:50			   0
	  0	       apply finish time      +00 00:00:00.000	     day(2) to second(3) interval   03/15/2023 20:23:51 						   0
	  0	       estimated startup time 18		     second			    03/15/2023 20:23:51 						   0

SQL> !ps -ef|grep mrp
oracle   27472     1  0 20:22 ?        00:00:00 ora_mrp0_jydb1
oracle   27677 27436  0 20:24 pts/2    00:00:00 /bin/bash -c ps -ef|grep mrp
oracle   27679 27677  0 20:24 pts/2    00:00:00 grep mrp

从alert日志也可以看到,快速解决了问题:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
2023-03-15T20:22:38.685163+08:00
ALTER DATABASE RECOVER  managed standby database disconnect
2023-03-15T20:22:38.720205+08:00
Attempt to start background Managed Standby Recovery process (jydb1)
Starting background process MRP0
2023-03-15T20:22:38.745104+08:00
MRP0 started with pid=76, OS id=27472
2023-03-15T20:22:38.747543+08:00
Background Managed Standby Recovery process started (jydb1)
2023-03-15T20:22:43.778604+08:00
Starting single instance redo apply (SIRA)
 Started logmerger process
2023-03-15T20:22:43.859358+08:00

IM on ADG: Start of Empty Journal

IM on ADG: End of Empty Journal
2023-03-15T20:22:43.877044+08:00
.... (PID:5407): Managed Standby Recovery starting Real Time Apply
2023-03-15T20:22:43.940962+08:00
max_pdb is 5
2023-03-15T20:22:44.268320+08:00
Increasing priority of 2 RS
Reconfiguration started (old inc 8, new inc 10)
List of instances (total 2) :
 1 2
My inst 1
 Global Resource Directory frozen
 Communication channels reestablished
 Master broadcasted resource hash value bitmaps
 Non-local Process blocks cleaned out
2023-03-15T20:22:44.337010+08:00
 LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
2023-03-15T20:22:44.337017+08:00
 LMS 1: 0 GCS shadows cancelled, 0 closed, 0 Xw survived, skipped 0
 Set master node info
 Dwn-cvts replayed, VALBLKs dubious
 All grantable enqueues granted
Reconfiguration complete (total time 0.2 secs)
Decreasing priority of 2 RS
2023-03-15T20:22:45.062909+08:00
Parallel Media Recovery started with 4 slaves
2023-03-15T20:22:45.260072+08:00
Stopping change tracking
PR00 (PID:27481): Media Recovery Waiting for T-1.S-447 (in transit)
2023-03-15T20:22:45.456197+08:00
Recovery of Online Redo Log: Thread 1 Group 13 Seq 447 Reading mem 0
  Mem# 0: +DATADG/DEMORAC/ONLINELOG/group_13.278.1127389119
2023-03-15T20:22:45.548608+08:00
ALTER SYSTEM SET remote_listener='db01rac-scan:1521' SCOPE=MEMORY SID='jydb1';
2023-03-15T20:22:45.550060+08:00
ALTER SYSTEM SET listener_networks='' SCOPE=MEMORY SID='jydb1';
2023-03-15T20:22:45.765532+08:00
Completed: ALTER DATABASE RECOVER  managed standby database disconnect
2023-03-15T20:22:49.050096+08:00
Recovery copied files for tablespace SYSTEM
Recovery successfully copied file +DATADG/DEMORAC/awr/system01.dbf from +DATADG/DEMORAC/pdbseed/system01.dbf
AWR(5):Recovery created file +DATADG/DEMORAC/awr/system01.dbf
AWR(5):Successfully added datafile 21 to media recovery
AWR(5):Datafile #21: '+DATADG/DEMORAC/awr/system01.dbf'
2023-03-15T20:22:55.588650+08:00
Recovery copied files for tablespace SYSAUX
Recovery successfully copied file +DATADG/DEMORAC/awr/sysaux01.dbf from +DATADG/DEMORAC/pdbseed/sysaux01.dbf
AWR(5):Recovery created file +DATADG/DEMORAC/awr/sysaux01.dbf
AWR(5):Successfully added datafile 22 to media recovery
AWR(5):Datafile #22: '+DATADG/DEMORAC/awr/sysaux01.dbf'
2023-03-15T20:22:58.602144+08:00
Recovery copied files for tablespace UNDOTBS1
Recovery successfully copied file +DATADG/DEMORAC/awr/undotbs01.dbf from +DATADG/DEMORAC/pdbseed/undotbs01.dbf
AWR(5):Recovery created file +DATADG/DEMORAC/awr/undotbs01.dbf
AWR(5):Successfully added datafile 23 to media recovery
AWR(5):Datafile #23: '+DATADG/DEMORAC/awr/undotbs01.dbf'
2023-03-15T20:23:00.926349+08:00
AWR(5):Recovery created file +DATADG/DEMORAC/awr/awr01.dbf
AWR(5):Successfully added datafile 24 to media recovery
AWR(5):Datafile #24: '+DATADG/DEMORAC/awr/awr01.dbf'

最近高层给全员开会时提到要向前走一步,如果是落到技术岗位上,那就是要不满足workaround的解决方式,去找根本的解决方案。 实际情况当然要灵活变通,比如当生产环境需要快速恢复业务/功能时,可以使用各种workaround去应对确保快速恢复,但事后排查根本原因时还是要找到根本的解决方案。 所以,文中举的这个问题根本解决方案是?先留给大家一起思考吧。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2023-03-15,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
Oracle DG环境中的gap处理办法总结
当主库的某些日志没有成功传送到备库,那么这时候就发生了归档裂缝(Archive Gap)。目前Oracle提供了两种日志GAP的检测和处理机制,分别是自动GAP处理(Automatic Gap Resolution)和FAL进程GAP处理(FAL Gap Resolution)。自动GAP处理即主库上的ARCn进程会每分钟检查备库上的日志GAP情况并做相应处理。FAL(Fetch Archive Log)是通过配置FAL_SERVER和FAL_CLIENT实现GAP检测的一种机制,它是备库主动发起的“取”日志的过程。备库就是FAL_CLIENT,它从FAL_SERVER中取这些GAP。Oracle会首先尝试使用FAL进程处理GAP,当发现FAL机制并没有配置生效的时候,进而尝试使用自动GAP处理。FAL进程只在物理备库存在。FAL进程提供了一个CLIENT/SERVER的机制,用来解决检测在主库产生的连续的归档日志,而在备库接受的归档日志不连续的问题。该进程只有在需要的时候才会启动,而当工作完成后就关闭了,因此在正常情况下,该进程是无法看见的。
AiDBA宝典
2023/04/27
2.4K0
Oracle DG环境中的gap处理办法总结
单实例Primary快速搭建Standby RAC参考手册(19.16 ADG)
上述为这里我做为演示环境的基本规划。 本文作为step by step的快速指导手册,方便快速部署此类ADG环境。
Alfred Zhao
2023/03/06
3920
【DB宝27】在Oracle 19c中创建容器数据库(4)--Duplicating a CDB(从18c开始)
【DB宝24】在Oracle 19c中创建容器数据库(1)--DBCA静默创建CDB
AiDBA宝典
2021/05/06
1.4K0
【DB宝27】在Oracle 19c中创建容器数据库(4)--Duplicating a CDB(从18c开始)
备库跳归档恢复的有趣案例(r9笔记第19天)
在Data Guard环境中,主备库基本都是使用归档来传递数据的变化。如果主备的归档传输中断,同时主库的归档被删除或者损坏,这种情况下备库是没法开始继续接收归档,应用新的数据变更了。 看到网友paulyibin的文章中提到了SCN恢复的想法,感觉非常有意思,明白了思路,自己在本地也测试了一把,发现真是有趣。 一般来说,主库的归档丢失,常规的思路只能是重建备库了。其实我们可以换一个角度来看这个问题,数据的变化在归档中是一个连续的过程,而在日志文件,数据 文件中则是一个状态。我们可以
jeanron100
2018/03/19
6360
11g备库无法开启ADG的原因分析 (r7笔记第62天)
今天碰到一个有些奇怪的问题,但是奇怪的现象背后都是有本质的因果。 下午在做一个环境的检查时,发现备库是在mount阶段,这可是一个11gR2的库,没有ADG实在是太浪费了,对于这种情况感觉太不应该了。 所以尝试启动至open阶段,发现状态一直是read only,在ADG中应该是READ ONLY WITH APPLY才对啊。 使用dg broker设置为READ-ONLY,备库的数据库日志如下: Standby Database: stestdb3, Enabled Phys
jeanron100
2018/03/16
1.3K0
实战篇:Oracle DataGuard 出现 GAP 修复完整步骤
DG GAP 顾名思义就是:DG不同步,当备库不能接受到一个或多个主库的归档日志文件时候,就发生了 GAP。
Lucifer三思而后行
2022/01/08
4.1K0
实战篇:Oracle DataGuard 出现 GAP 修复完整步骤
dataguard中需要注意的一些数据文件操作(r8笔记第21天)
因为最近需要做一个测试,就顺手搭建了一套简单的dg环境。不过碰到了一些小问题。 数据库环境是11gR2,备库是开在open状态,配置了dg broker,一切都很快完成了。备库状态为"READ ONLY WITH APPLY"当然这是期望之中ADG的状态。 然后在主库需要做一些配置,准备创建几个表空间 先创建了一个表空间 create tablespace testdata datafile '/DATA/app/oracle/oradata/test04/testdata01.dbf' size 100
jeanron100
2018/03/19
1K0
手工搭建Data Guard
Data Guard的搭建可以使用GC图形化安装,优缺点很明显,优点就是图形化操作,符合国人的习惯(据secooler介绍外国程序员能用图形化做的事就一定用图形做,因为boss看得懂,和国人正相反。。。),缺点就是如同Windows一样,宛如黑盒,换句话说,要时刻祈祷不要出问题,否则有时很难知道他为什么挂了。。。
bisal
2019/01/29
7620
问题:Duplicate报错RMAN-03009, ORA-17628, ORA-19505
前面文章提到,这周末帮一个客户测试报错场景: 客户通过duplicate生产备库的方式创建cascade备库。 发现每次都会遇到两个文件报错,ORA-17628: Oracle error 19505错误,且每一次跑,报错文件不一样。 现在想帮客户验证,这属于是正常现象还是bug。
Alfred Zhao
2023/05/23
1K0
备库查询导致的ORA-01110错误及修复(r8笔记第67天)
最近帮助业务部门解决了一个技术问题,因为发现有数据问题需要对存在问题的数据做分析。当然一个难点就是把数据给筛选出来,当我看到他们提供的语句,在备 库做了简单的数据评估之后,发现数据量比想象的要多,大概有200万条左右的数据,而业务部门手头有一个excel文件,需要和这些数据做一些比对,当然 停了下筛选逻辑还蛮复杂,最开始建议他们数据量太大,使用excel还是可能出问题,但是业务部门认为应该没有太大的问题,他们会有excel中的公式等 来处理,想想也有道理,就提供给了他们一个近40M的文件。 等到快中
jeanron100
2018/03/19
1.2K0
dataguard中MRP无法启动的问题分析和解决(r5笔记第82天)
自己手头有一套dataguard环境,因为也有些日子没有用了,结果突然心血来潮准备启动起来学习一下,突然发现在敲了命令 recover managed standby database disconnect from session之后,命令运行正常,但是后台却报了ora错误。 Sat Jun 27 23:16:39 2015 Recovery Slave PR00 previously exited with exception 1157 Errors in file /u02/dg11g/diag/rd
jeanron100
2018/03/16
1.1K0
挽救DG中主库的nologging操作的块
众所周知我们的Data Guard数据同步是基于日志流的。所以在主库执行nologging操作是不被允许的。这也就是为什么我们需要在配置Data Guard阶段需要使用Force Logging。但是这也会带来很多问题(SQL执行效率),例如:当我们使用数据泵进行迁移时我们希望最少停机时间完成,这时候我们就可能会考虑到以最小日志导入的方式以加快导入速度,然后重新同步备库。
沃趣科技
2018/05/15
8350
挽救DG中主库的nologging操作的块
【DB宝22】使用DG环境的物理备库进行备份还原的备份一致性问题
之前发过一篇类似的文章,请参考: 【DB宝15】生产环境中,如何利用DG的备库来异机还原一个新库? 连接地址为: https://mp.weixin.qq.com/s/ptB9D3sDzwNyHyHujTwKbQ
AiDBA宝典
2021/05/06
1.4K0
【DB宝22】使用DG环境的物理备库进行备份还原的备份一致性问题
【DB宝31】Oracle DG环境中主库使用rman做不完全恢复后,备库如何修复继续同步
本文介绍一下,在DG环境中,主库使用rman做不完全恢复后,备库如何通过flashback操作,继续和主库保持同步,而不用重新搭建DG。
AiDBA宝典
2020/12/08
9360
Dataguard配置Step by Step
http://www.eygle.com/ha/dataguard-step-by-step.htm
数据和云01
2018/09/05
5800
Oracle 12c DBCA浅析(r12笔记第48天)
我们知道在11g的环境中我们可以通过一些分析来得到DBCA的一些后台处理工作,有一点需要说明的是,如果一个12c的单实例数据库需要转换为12c的容器数据库,你去查看官方文档,会发现这是一个空白,不是做不了,而是里面有一些地方会干扰到你。 所以在11g手工探究脚本过程的基础上,12c的部分你需要再进一步。常规来说,我们可以通过如下的命令得到一个12c的数据库创建的脚本。 dbca -silent -templateName $ORACLE_HOME/assistants/dbca/templat
jeanron100
2018/03/21
9180
使用RMAN增量备份处理Dataguard因归档丢失造成的gap
Thu Mar 29 11:21:45 2018 FAL[client]: Failed to request gap sequence  GAP - thread 1 sequence 184-185  DBID 1484954774 branch 960494131 FAL[client]: All defined FAL servers have been attempted. ------------------------------------------------------------ Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization parameter is defined to a value that's sufficiently large enough to maintain adequate log switch information to resolve archivelog gaps.
星哥玩云
2022/08/16
5600
一个Oracle bug的手工修复(r6笔记第59天)
在上周五的时候,本来一个例行巡检,想扩充一些表空间,结果弄巧成拙,因为一个drop datafile的操作直接导致了一主两备的两个备库MRP直接抛出了ORA-600错误。 在尝试了一些方法和查看了MOS之后,除了重建备库,暂时还没有找到其它相对更快捷的方法。 因为是10.2.0.4.0的环境,为了先修复问题,自己先使用rman在主库做了备份,然后在备库直接做duplicate操作还原恢复。先搭好了一个备库,另外一个备库则先留下来,观察一下,看看有没有其它的方法,如果还是没有找到,就继续重新搭建备库。 结果在
jeanron100
2018/03/16
6260
ORACLE数据文件名导致的奇怪问题 (51天)
今天创建了一些表空间,准备做data guard来看看效果。 为了方便起见,我用gridcontrol来做,主库也开了Omf,省去了好多步骤。 一路点下来,就等gc的那个状态变成对号了,结果装了近20分钟,alert日志开始报错。 ******************** WARNING *************************** The errors during Server autobackup are not fatal, as it is attempted after sucess
jeanron100
2018/03/13
9740
ADG无法同步:TT00进程报错 Error 12514
环境: Oracle 19.16 ADG (Single Instance -> RAC) 在配置ADG的场景,发现ADG不能同步。
Alfred Zhao
2023/02/10
9760
推荐阅读
相关推荐
Oracle DG环境中的gap处理办法总结
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验