对昨天提出的问题做了一个简单的分析和排查,也算是有了一个交代,上一篇文章在 dg broker校验失败的一个奇怪问题 我查看了最近的日志,发现在半个月以前有一行日志引起了我的注意。 Thu Mar 03 17:32:12 2016 ALTER SYSTEM SET log_archive_dest_state_2='DEFER' SCOPE=BOTH; 关于这个DEFER的设置,让我想起了之前的一个设置。 原来的主库发生了硬件电源故障,启用备用电源之后,勉强撑了几个小时,因为数据库之前使用的异机逻辑备份,
今天在琢磨几件事情,也是和工作相关。 数据灾难切换的几点认识: 在unix中可能会碰到在处理网络问题时,超时时间会远远高于linux的情况,这个时候如果尝试做failover是非常消耗时间的,而且日志没有任何输出,看不到进展,相比于linux的处理,我感觉要更简洁一些。 鉴于unix中的处理方式,我还是建议直接使用命令行来做failover,使用下面两个命令即可。 alter database recover managed standby database finish force; alter data
说明:本文汇总Oracle安装部署,版本升级,应用补丁等相关内容,方便快速查阅。 其中参考随笔是汇总我自己总结的原创作品,参考文章是汇总其他作者的相关优秀作品。
对于使用12c的PDB,如果想尽快熟悉,掌握,那就是和业务挂钩,让它跑在业务上。当然是在能够基本驾驭它的前提下,要不就真成了甩手掌柜。11g可以玩得很好,12c里面也差不到哪里去。 摆在我面前的一个选择就是字符集,尽管有大量的PDB需要整合进来,但是我在分析了几套需要整合的数据库之后,发现字符集还是一个很重要的考量。比如几个已有的旧版本的数据库字符集为UTF-8 US7ASCII ZHS16GBK ZHS16GBK,折中一些,根据实际情况还是选用ZHS16GBK,如果是个跨国企业,我可
对于从事IT技术行业的我们,大家对VMware虚拟机应该都比较熟悉,平时自己搭个学习、测试、开发环境啥的,还真离不开它。
一直以来搭建Data Guard是一件看起来还蛮有含量的工作,因为这其中涉及的工作比较琐碎,比较细,况且手工搭建起来都会碰到各种各样的问题,如果中途碰到一点儿小问题,那可能需要花点时间来排查,如果想要脚本自动化,那简直寸步难行。所以搭建Data Guard一方面会需要很多的提前准备和配置,另一方面这个工作自动化的驱动力不够,毕竟环境不会像MySQL业务一样动辄几十成百上千的规模,所以由此而来,好像搭建一个套环境的成本也值了,如果尝试自动化,半自动化,那花费的时间估计够搭建10套环境了。所以目前来看,
说起虚拟机工具大家最熟悉的自然是 VMware,功能很多很强大,最让我认可的地方就是可以非常方便的修改虚拟机的配置,让虚拟机达到自己想要的性能~~
11g的dataguard相比于10g来说,最优越的特性应该算就是active dataguard了,这一点改进在很大意义上促使用户需要把数据库从10g升级到11g,读写分离在这个时候得到了升华,而且在后台会根据需要进行数据的同步,相比于使用10g,想读数据的时候把数据库启动到read only 阶段,但这个时候不接受日志同步数据,如果需要同步数据还需要把数据库再启动到mount阶段,感觉还是比较繁琐的。 11g的active dataurad功能很强大,同时搭建的时候使用rman 的duplicate选项
随着Oracle ADG技术的逐渐成熟,大多数数据库环境都使用ADG作为灾备和报表数据库,可以说是标配。
Oracle Data Guard是Oracle MAA (Maximum Availability Architecture)中的成员之一。从Oracle 7i版本开始推出STANDBY DATABASE的概念,慢慢受到大家的欢迎。随着Oracle数据库版本的更迭,搭建备库的方式多种多样。今天介绍一种创建物理备库的新方式,从12C版本开始推出:使用 DBCA 命令行。
点击上方“芋道源码”,选择“设为星标” 管她前浪,还是后浪? 能浪的浪,才是好浪! 每天 10:33 更新文章,每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路,很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
Oracle 11g DG搭建方法参考:【DB宝29】使用Docker搭建Oracle 11g的DG环境
回忆起来也是有些年没亲自动手搭建ADG了,今天正好有个机会重温,客户环境是19.16,恍惚记得上一次搭ADG还是在11.2.0.4的时代,时光荏苒啊。 正好看下19c的ADG和11g的ADG在部署方面有啥不同? 主备库都是RAC架构,数据库是CDB架构,包含有4个PDB,整个搭建过程还是遇到很多小问题,但基本也都知道原因并能快速解决,也有个别折腾了很久的,蛮有意思,所以记录下本次遇到的问题供日后参考,客户信息已脱敏。
本文通过手工冷备+pfile文件的方式,搭建oracle11g dataguard 物理备库。在搭建前的规划中,特意将主库的数据库名和服务名、备库的文件存放位置等等做了差异处理。 在进行初始化参数文件的配置时,也进行了最小化处理。这样能够更好的理解DataGuard搭建所需要的的日志传输、应用所需参数配置。
关于半自动化搭建Data Guard,自己花了一些时间,总算是把这件事情继续推进了一下,还是再啰嗦一句,为什么不自动化,因为安全。主库就是主库,任何变更都要手工检查审核, 自动化的工作在备库和中控端来完成。我希望自己的脚本能够只知道主库的IP,不用一次又一次连过去配置和检查,当然要完成自动化还是半自动化,有些网友也提醒的极是,那就是规范和标准。 预先条件: 1.目前的设计是基于11.2.0.4的版本,当然这个很容易定制,在此是作为一个基本的标准,作为环境的初始化和Data Guard对的搭建的基线。 2.
本文介绍一下,在DG环境中,若主库做了闪回数据库的操作后,备库如何通过flashback操作,继续和主库保持同步,而不用重新搭建DG。
记得之前在《一半技术一半生活》中分享过一个设计,因为业务的需求,为了提高业务的处理效率,采用了根据业务的拆库拆表的方式,类似下面的图示。 开发团队也很给力,帮我们协调了好的机器,加了内存,也在新业
Data Guard作为Oracle提供的一个高可用及灾备解决方案,理解并可以实施它对于DBA来说是非常重要套的技能
OracleRac ASM+DG前任搭建时偷懒随手埋下的雷,后任接手最易踩爆的那声响
DG Broker是Oracle为Data Guard维护提供的一个很不错的工具,从我的实际使用来看,早期的版本中似乎大家都还是存在一定的思维定式,认为手工维护已经足够了。这个工具就不那么需要了,我们完全可以脱离开这些工具来直观的使用命令行的方式来维护,这个观点也没错,不过从与时俱进的角度来看,本来能够让你更轻松的一个工具,如果不用实在是太可惜了。 DG Broker在数据库端需要启用一个后台进程dmon来维护,这个后台进程启动,需要设置dg_broker_start为true即可,如果要停止,只需
最近的工作中需要基于Oracle连接到SQLserver2014,我们可以通过配置Gateway的方式来实现这个功能。这个Gateway的实质是透过dblink来实现的。即把SQLserver模拟成一个远端的Oracle实例,这个实例由Gateway来负责进行接收,转发等等。本文简要描述其配置过程。
对于将物理备库切换到逻辑备库,需要在主库构建LogMiner字典及启用补充日志,因此应先停用备库的MRP进程,避免产生额外的Redo Apply。如果正在使用Broker管理现有的物理备库,应先在Broker中禁用目标数据库。
如何将一个物理DG转换为一个快照DG呢?如果备库正处于Redo Apply过程,那么需要先取消日志应用,并且关闭数据库所有节点到MOUNT阶段:
前几天碰到一个看起来有些奇怪的例子,今天抽空把分析过程整理了一下。 有一主一备的一套测试环境,之前环境在我手里,交给另外一个同事之后,重新搭建了dataguard,我检查了一圈,发现都没有问题,然后过了一个星期的 样子,无意中再次查看的时候,发现这个备库竟然在dg broker中的状态是disable,当然我也不能看到这个现象就反问同事,说当时dataguard怎么有这种低级操作问题。我想了想,根据我的印 象,当时也确实是搭建成功了。这些天这个主库也从来没有任何的操作,zabbix也一直没有相关的报警,这
DG搭建时,官方文档手册有明确提到要设置数据库为force_logging,防止有nologging操作日志记录不全导致备库应用时出现问题。 虽然是老生常谈的安装规范,但现实中总会遇到不遵守规范的场景,最近就在某客户现场遇到一则这样的案例,因为DG主库设置force_logging晚于DG搭建,导致备库出现坏块,使用dbv检查就表现为DBV-201错误。
DG根据备库(Standby Database)重演日志方式的不同,可以分为物理DG(Physical DG)、逻辑DG(Logical DG)和快照DG(Snapshot DG),它们对应的数据库分别可以称为Physical Standby、Logical Standby和Snapshot Standby。
环境:RAC+单机 Dataguard 问题:启动备库到ADG模式时,发现后台归档日志并不同步
整理一份DG的搭建流程,参考了一些教程及文档,环境是Oracle 11gR2 1+1。DG计划整理三篇:搭建、概念、维护。
本篇梳理DG的架构和一些概念知识,重新梳理的目的是加强理解,也方便复习,基于11gR2版本写的,不包含12c新特性。如果能帮助到新接触DG的朋友,那就再好不过。
3、主库必须添加Standby Redo Log Files,其大小应该和Online Redo Log Files的大小一致。另外,Standby日志组的个数应满足以下条件:
Oracle 11g RAC中crs_stat命令较之前的版本多出了很多新的不同的资源类型,缺省情况下,使用crs_stat -t来查看资源是密密麻麻一大片,看起来着实费力。作者Paul Elbow, Enkitec为我们提供了一个crsstat脚本以更清晰的格式来展现Oracle 11g RAC下的所有资源类型,见本文下面的描述。
之前已经整理出: 1.【DG】DataGuard搭建-11gR2单主单备 2.【DG】DataGuard架构和部分概念整理 下面继续整理DataGuard相关动态性能视图,用于查看物理DG状态,以及日志传输/应用服务简单说明,要结合架构和概念篇看
oracle@Linux:~> lsnrctl stop oracle@Linux:~> sqlplus / as sysdba SQL> shutdown immediate; SQL> exit
经过交流群中朋友的多次要求,这次给大家分享一下 RAC to Single 的 ADG 搭建教程!
对于备库的使用,尤其是一主多备的环境,一直以来有一点感觉不大给力,那就是主备库的关系,总是感觉会少一点什么。 尤其是在做月度404审计的时候,总是要反复确认备库的IP。如果是手工管理的场景中,基本就是查看log_archive_config的配置,也还需要解析里面的TNS配置。如果配置了DG Broker,可能情况会好些,输出的关系是还是比较清楚的。 Configuration - dg_test Protection Mode: MaxPerformance Databases: test
Oracle 12c中DBCA有一个特性看起来蛮有意思,就是直接通过DBCA来搭建Data Guard,当然这么说也有点噱头,我们来实际看看。 Oracle提供的官方命令结构如下: dbca -createDuplicateDB -gdbName global_database_name -primaryDBConnectionString easy_connect_string_to_primary -sid database_s
在Oracle DataGuard部署过程中,如果操作不规范,可能遇到很多想不到的问题。有些问题是配置参数不到位,有些是操作不规范遗漏导致。
一个DG环境中只有两种角色:Primary和Standby。所谓角色转换就是让数据库在这两种角色中切换,切换也分两种:Switchover和Failover,关于角色切换需要注意以下几点:
对于dataguard说,switchover,failover是一种互补可选的容灾解决方案。但是对于这种容灾思路还是存在着一些实践中的细节需 要,从数据层面而言,只能是最大程度保证了数据的不丢失,但是数据切换过去了,权限,配置这些信息还是需要考虑的,如果切换过程很快,收尾的补充工作很 慢,那么总体来看切换的时间就被拉长了。 在提出准备的需求之前,容我花一点时间来简单吐槽一下10g中的dataguard. 10g中的状态切换 10g中的dataguard没有adg的特性,在使用中还是有很大的限制,很多时候备
这篇文章计划了一段时间,本来想写篇心情文字,还是留到周末再放飞心情吧。 今天的内容是关于数据库的备库的思考,当然我们可以自己问自己,我们的备库准备工作做好了吗?扪心自问,其实有些工作我也没有准备好,这是我的建议,其实一个备库的思考点还是有很多值得考量和斟酌的地方。自己也需要后续完善 备库总是在容灾中有着举足轻重的作用,但是故障难免,我们的备机备库是否能够在危机降临的时候顶住压力,这个需要打上一个问号,我会从硬件配置,系统层面,数据库层面,架构层面和网络层面进行一些分析。 硬件配置 备库硬件配置更差
近期我们在DBASK小程序新关联了韩锋频道、互联网侦察、数据库SQL、SQL数据库开发、跨界架构师、石杉的架构笔记等数据领域的公众号,聚合更新展示,欢迎大家阅读分享。
OCM,Oracle Certification,Oracle Certified Master,11g,12c
可能平时下载、安装Oracle,未必十分关注版本的问题,有时惯性思维,就选择一个最大的安装包,肯定是功能最丰富的,接着就装上用了。
今天写了个脚本,虽然实现的功能不多,但是个人感觉是一个好的开始,架子出来了,后面要补充的细节加进来就逐步完善了。 这个脚本的运行效果如下: OS Version is :[ RHEL_6.3 ] Oracle Version is :[ 11.2.0.3.0] Oracle Instance is :[ dgtest ] dgtest ORACLE_HOME is :[ /U01/app/oracle/product/11.2.0.2/db_1 ] Oracle status is
dataguard broker是在dataguard使用基础上提供的一个工具,可以把原本复杂的命令控制语句集成起来,比如switchover,failover等等,可能在多个备库的情况下需要敲不少的命令,这个dg broker的优越性就显示出来了。 当然dg broker需要启用还是需要预备一些条件的,比如需要设置local_listener,需要在spfile的基础上,需要在网络配置中进行dgmgrl相关的标示。 应该是在内部实现中默认拥有这些配置。 我们先来看看一个简单的配置情况。 首先启用dg br
Oracle在11g中推出的新特性ADR,即Automatic Diagnostic Repository 个人理解这个工具就是能够高效的把一些日志文件轻松管理起来。比如查看数据库alert日志就不必麻烦去到对应的路径下去找一圈,直接使用show alert即可,比如查看现在数据库中出现了哪些错误,直接通过show problem命令即可。 命令的使用也很方便。直接输入adrci就开启了专门的窗口来使用。如果不知道该使用哪些命令,直接使用help即可。 $ adrci ADRCI: Release 11.2
问题二还是比較好写,一的话可能须要细致想想,可是假如是面试的话。可能我一时也说不出来。
领取专属 10元无门槛券
手把手带您无忧上云