说明:本文汇总Oracle安装部署,版本升级,应用补丁等相关内容,方便快速查阅。 其中参考随笔是汇总我自己总结的原创作品,参考文章是汇总其他作者的相关优秀作品。
客户的一套生产环境采用的架构是Oracle ADG + Keepalived,近期需要进行切换演练,要求我这边保障。ADG本身切换倒没啥可说的,但引入keepalived软件,就需要提前研究下这个架构。其实看了下环境配置,整体思路也非常简单,说白了就是利用keepalived软件引入一个VIP,应用侧只需配置连接这个VIP即可。 依据当前生产环境架构模拟了一套自己的测试环境。
之前已经整理出: 1.【DG】DataGuard搭建-11gR2单主单备 2.【DG】DataGuard架构和部分概念整理 下面继续整理DataGuard相关动态性能视图,用于查看物理DG状态,以及日志传输/应用服务简单说明,要结合架构和概念篇看
这篇文章的动力来自于一个朋友的提问,他问我备库的密码文件直接重建可以吗,我说最好还是复制,如果重建可能会有一些潜在的问题,当然这个所谓潜在问题也是自己给自己打的马虎眼,到底哪里有问题,脑海里搜索了一番似乎没有找到什么有效的信息,但是隐隐之中感觉搭建dataguard好像还从来没有直接重建密码文件的时候,似乎是一种非常规的方式,但是转眼一想一旦发生这种情况的时候,或者密码文件出现了一些潜在问题的时候,怎么有效防范,这个问题就又上升了一个高度,所以我对这个问题做了一些初步的分析,然后在网上竟然看到还真有一些技术
对于dataguard说,switchover,failover是一种互补可选的容灾解决方案。但是对于这种容灾思路还是存在着一些实践中的细节需 要,从数据层面而言,只能是最大程度保证了数据的不丢失,但是数据切换过去了,权限,配置这些信息还是需要考虑的,如果切换过程很快,收尾的补充工作很 慢,那么总体来看切换的时间就被拉长了。 在提出准备的需求之前,容我花一点时间来简单吐槽一下10g中的dataguard. 10g中的状态切换 10g中的dataguard没有adg的特性,在使用中还是有很大的限制,很多时候备
DataGuard,数据卫士,一种数据库级别的高可用性(HA)方案,用作数据容灾解决方案。对于联机事务处理(OLTP,数据量不太大)非常合适,对于联机分析处理(OLAP,数据量太大),只能选择关键数据创建DG,常规数据,选择其他方式备份。
Oracle DataGuard;简称DG。是由一个Primary Database(主库)和一个或者多个Standby Database(备库)组成。对Oracle来说;本身不能提高性能。通过数据冗余来保护数据。由Primary Database对外提供服务;用户操作在Primary Database上操作;其操作的数据库Redo Log或者Archive log通过网络传输到Standby Database。Standby Database在重做这些日志。从而实现Primary Database和Standby Database数据同步。
保险行业升级测试工作较多,此为行业背景。从客户甲了解到,他所在的DBA团队一方面要承担数据库日常维护工作,另一方面也要为业务部门提供测试数据库。除去生产环境的日常维护,以下几项工作耗费较多精力:
Oracle 数据库闪回通常设置在 DataGuard 备库,如果主库误删数据,可用备库闪回至删除点之前,获取丢失数据,然后再自动同步回来!
在OOW 2015大会上,Oracle已经发布了12.2的Beta版本,其中的很多亮点新特性引人瞩目,包括在IMO和Multitenant方面,以及在Sharding分布式方面的增强。 但是除了这些大的改进,Oracle在细节上的不断增强,同样温暖人心。在寒冷的季节里,介绍一些小的改变给大家。 第一季请看: Oracle 12.2中那些温暖人心的特性 6. 12.2 DataGuard中并行日志应用 要知道在12.2之前,DG的备库只能由一个实例通过MRP进程进行应用,现在可以在多实例并行进行。 在8节点
在2015年旧金山的Oracle OpenWorld大会上,Oracle发布了Database 12.2的Beta版本,虽然Beta版本只对部分用户开放,但是大会上已经公布了12.2的很多重要的新特性,云和恩墨是Oracle的Beta用户,已经开始测试这一产品。在刚刚结束的“Oracle技术嘉年华”大会上,更详细的主题分享披露了更多内容。在这篇文章中,我将和大家一一来细数Oracle Database 12.2的新特性。 Oracle Sharding的实现 简单来说,Oracle的Sharding技术就是
编辑手记:前文我们分享了DG 中Far Sync Instance的创建和配置,今天一起来学习当Far Sync Instance出现问题时,日志传输的情况,并介绍在配置Far Sync Instance的情况下,switchover的过程。 上文中Oracle12c DataGuard Far Sync的配置和使用简介(上)提到了Far Sync Instance的配置,配置在参数中配置了max_failure=1 alternate=log_archive_dest_3 参数。当dest_2出现问题时会
时至今日,“虚拟化”,“云”等名词早已耳熟能详,其提供的特性:将服务器物理资源抽象成逻辑资源,可以将一台服务器变成几台甚至上百台虚拟服务器;将CPU、内存、磁盘、I/O硬件抽象化,变成可以动态管理的“资源池”,可以提高硬件资源整合密度, 减低成本,简化系统管理,提升工作效率。
最近有时候看官方文档,感觉11g里面已经有了很多的变化,无论是使用还是安装上的细节上,11g似乎总是能够带给我更多的惊喜。而从以往的使用情况中感 觉10g已经足够了,但是越多的使用11g,逐渐的改变了自己的固有思维,很多原来不好,不方便的操作习惯都得到了很大的改善。我就从10g和11g共有 的一些细节之处来一窥两个版本中的差别。细节还是太多,我就扒出小部门。 大体会从下面几个部分进行对比和说明,有一些部分已经写了一些文章了,所以突然回顾一下会发现原来这些看似清汤寡水的文章里面还是有值得推敲的东西。
随着这几天Oracle OpenWorld大会的召开,Oracle11g的新特性越来越多的被展现出来。
rman catalog database是11.2.0.3,rman catalog schema升级12.2版本,主要是兼容11g和12c版本.
在OOW 2015大会上,Oracle已经发布了12.2的Beta版本,其中的很多亮点新特性引人瞩目,包括在IMO和Multitenant方面,以及在Sharding分布式方面的增强。 但是除了这些大的改进,Oracle在细节上的不断增强,同样温暖人心。在寒冷的季节里,介绍一些小的改变给大家。 DBCA备库创建 - 在备库主机安装软件启动监听,则可以通过DBCA来创建备库,指向主库来获取文件; 以前DataGuard的创建已经非常简化,RMAN的操作也很精简,现在DBCA也被利用起来,更方便容易了,够体贴
原本dataguard中日志应用和数据库只读查询是一个互斥的关系,两者不能并存。如果需要应用日志,则数据库只能在Mount状态下 使用recover managed standby database disconnect from session来不断地从后台进行日志应用。 如果想查看备库中的数据情况,则只能使用recover managed standby database cancel来取消日志应用,然后把数据库启动到read only 状态下。这种情况从道理上也讲也是有理有据,但是终归还是感觉不够方便
对昨天提出的问题做了一个简单的分析和排查,也算是有了一个交代,上一篇文章在 dg broker校验失败的一个奇怪问题 我查看了最近的日志,发现在半个月以前有一行日志引起了我的注意。 Thu Mar 03 17:32:12 2016 ALTER SYSTEM SET log_archive_dest_state_2='DEFER' SCOPE=BOTH; 关于这个DEFER的设置,让我想起了之前的一个设置。 原来的主库发生了硬件电源故障,启用备用电源之后,勉强撑了几个小时,因为数据库之前使用的异机逻辑备份,
随着Oracle的普遍应用,DataGuard这个成员基本成为了数据库容灾环境的标配。当需要升级Oracle数据库的同时,也需要考虑同时升级DataGuard数据库版本,那么如何快捷安全的升级?
环境:Linux + Oracle 11.2.0.1 ADG 现象:发现备库没有应用日志
实验证明: 11g snapshot standby的确可以很方便的实现读写测试;之后也可以方便的切换回测试前的状态继续做为physical standby使用。
在zabbix中有了orabbix的辅助,监控效率大大提高,但是因为orabbix是基于jdbc的方式,有些监控还是有一些限制。 比如dataguard的检查,如果采用dg broker来检查,效果就更直观也更可信。 DGMGRL> show configuration; Configuration - csdb Protection Mode: MaxPerformance Databases: test- Primary database stest- Physical stan
前几天碰到一个看起来有些奇怪的例子,今天抽空把分析过程整理了一下。 有一主一备的一套测试环境,之前环境在我手里,交给另外一个同事之后,重新搭建了dataguard,我检查了一圈,发现都没有问题,然后过了一个星期的 样子,无意中再次查看的时候,发现这个备库竟然在dg broker中的状态是disable,当然我也不能看到这个现象就反问同事,说当时dataguard怎么有这种低级操作问题。我想了想,根据我的印 象,当时也确实是搭建成功了。这些天这个主库也从来没有任何的操作,zabbix也一直没有相关的报警,这
SQL Tuning Health-Check Script (SQLHC)是SQLT的一个简化版本,同样用于诊断SQL问题,检查单条 SQL 语句运行的环境,包括基于成本的优化器(CBO)的统计数据,用户对象的元数据定义,配置参数和其他可能影响到待分析 SQL 性能的因素。
第一期就从基本的初始化参数讲起,一篇一个参数,会尽可能的具体. 如无特殊说明数据库版本为11g
11g的dataguard相比于10g来说,最优越的特性应该算就是active dataguard了,这一点改进在很大意义上促使用户需要把数据库从10g升级到11g,读写分离在这个时候得到了升华,而且在后台会根据需要进行数据的同步,相比于使用10g,想读数据的时候把数据库启动到read only 阶段,但这个时候不接受日志同步数据,如果需要同步数据还需要把数据库再启动到mount阶段,感觉还是比较繁琐的。 11g的active dataurad功能很强大,同时搭建的时候使用rman 的duplicate选项
环境: RHEL6.4 + Oracle 11.2.0.4 Primary RAC + Standby RAC
引言 数据库构架设计中主要有 Shared Everthting、Shared Nothing 和 Shared Disk: Shared Everthting:一般是针对单个主机,完全透明共享 CPU/MEMORY/IO,并行处理能力是最差的,例如 Oracle 的单机模式。 Shared Disk:各个处理单元使用自己的私有 CPU和 Memory,共享磁盘系统。典型的代表 Oracle RAC, 它是数据共享,可通过增加节点来提高并行处理的能力,扩展能力较好。其类似于 SMP(对称多处理)模式,但是当
数据库构架设计中主要有 Shared Everthting、Shared Nothing 和 Shared Disk:
这里按照整个表空间的I/O情况来排序,可以看到DCWIP_ODS_IDX表空间的I/O负载最高
最近准备给一个生产项目上oracle 11g DataGuard,主备均为oracle 11.2.0.4软件,并在备库安装软件。这篇不讲述 DataGuard 的原理,只是oracle 11g DataGuard 搭建的详细过程。这次是生产库的RAC需要做一个DG,由于不知道SYS 用户密码,需要取回密码太麻烦,故不能使用 duplicate 方式,使用rman 全备 -->还原控制文件--> mount数据库还原数据文件 --> 追加日志 --> 主备同步。搭建过程中只需要修改部分参数以及网络监听,故不需要停机可白天完成,下面开始进入主题。
何剑敏 Oracle ACS华南区售后团队,首席技术工程师 曾供职于中国联通信息计费部、卓望数码,系统支撑部首席DBA,负责中国移动全网梦网业务和移动应用商城数据库维护。后供职于IBM,负责米其林项目和澳洲电信(Telstra)项目数据库管理。现供职于Oracle ACS华南区售后团队,首席技术工程师。多年从事第一线的数据库运维工作,有丰富项目经验、维护经验和调优经验,专注于数据库的整体运维。 1 Oracle 12.2的重磅特性及发布时间 2016年2月,Oracle出了12.2的beta2版本,并
很多时候,大家工作中都会有一种被动的思维,那就是能不动就不动,从求稳的角度来看无可厚非,但是从风险的角度来说,还是有待商榷的。如果存在风险,还保持原样很可能就是一个不定时炸弹。 这不手头有一套环境,按照以前的标准是根本入不了我的法眼的,但是因为是测试环境,小问题比较多,存在容灾风险,但是这么多年一直这样,也就默然接受了。 这套环境硬件配置很低,基本上和我的笔记本配置差不多,可能还略差一些,在上面跑着3个数据库实例,其中一个是11g的,2个是10g的。两个10g的数据库实例数据量都不大,几十G而已。 看起来是
昨天接到了同事的一个电话,说有一个数据库无法访问了,希望能够让我来看看,赶紧连过去,发现错误还是一个看似很简单的ora错误。 $ sqlplus / as sysdba Copyright (c) 1982, 2011, Oracle. All rights reserved. ERROR: ORA-09817: Write to audit file failed. Linux-x86_64 Error: 28: No space left on device Additional informatio
这是一个比较细节的知识点,但必须要理解这个才能准确判断Oracle ADG的延迟情况。
最近随着学习PostgreSQL 的深入,越发的喜欢这个数据库,之前曾经写过关于PostgreSQL 关于模糊查询的文字,在我使用的时候,的确是惊艳到了,ORACLE ,SQL SERVER 这样的收费数据库不能做的,PG轻易的化解,无愧是世界上最好的开源数据库了(其实去掉开源那两个字也不是担当不起)。
针对Oracle迁移上云项目,云提供给用户的物理机上加载有三张网卡供用户使用,一张用于跑业务,另外两张可以用于心跳线网络。另外,存储网络是单独的网口,在建设时已由服务商做好配置,不含在这三张网卡内。基于公有云技术,为了组建资源池内部管理控制专网,因此现市面上公有云提供商的IPMI端口,均不能提供出来用于对外访问。
本篇梳理DG的架构和一些概念知识,重新梳理的目的是加强理解,也方便复习,基于11gR2版本写的,不包含12c新特性。如果能帮助到新接触DG的朋友,那就再好不过。
UNDO_TABLESPACE 该参数指定数据库启动时的undo表空间名称 参数类型:字符串 语法:UNDO_TABLESPACE = undoname 默认值:数据库中第一个可用的undo表空间 此
1.3.2 备库切换到open状态,启用Real-time query A physical standby database instance cannot be opened if Redo Apply is active on a mounted instance of that database. Use the following SQL statements to stop Redo Apply, open a standby instance read-only, and restart Redo Apply:
第一期就从基本的初始化参数讲起,一篇一个参数,会尽可能的具体. 如无特殊说明数据库版本为11.2.0.4
Oracle 数据库通常建议开启归档模式,记录数据库操作的记录归档到本地日志文件!
前两个部分尝试了一下neo4j和py2neo的基本语法,证实了图库在运维实体中实现的可行性,先对数据结构做了一下调整,在服务器节点上增加了label,主要用来区别数据库还是应用服务器,在访问关系中也增加了源和目标的label值,主要是考虑到数据库和应用还是有很大区别的,数据库可以是多个业务系统的数据库,数据库本省也存在RAC、Dataguard、VIP、物理IP、ScanIP等多个概念,目前还没完全构思好,暂且只是简单分一下类。
本文通过手工冷备+pfile文件的方式,搭建oracle11g dataguard 物理备库。在搭建前的规划中,特意将主库的数据库名和服务名、备库的文件存放位置等等做了差异处理。 在进行初始化参数文件的配置时,也进行了最小化处理。这样能够更好的理解DataGuard搭建所需要的的日志传输、应用所需参数配置。
通常情况下习惯使用sqlplus命令对数据库primary以及dataguard进行switchover、failover.虽然oracle很早在10g时候就推出dg broker命令行进行快速切换,由dgmgrl对数据库状态检查、延迟检查、是否可以切换进行封装命令输出,所以可以很快捷简单检查整个主从配置和切换,个人觉得dg broker报错排除之类不是太友好,,另外dataguard切换2条命令,dgmgrl封装成一条命令,整体切换相对简单,使用dgmgrl需要配置静态监听、standby log、延迟等要求比较多,另外broker可以配合em操作,实现web化操作数据库切换。总的来dg broker操作简单,配置相对复杂(对于sqlplus进行切换来说)下面跟大家分享下dg broker以及12c一些新的变化。
今天碰到了一个dataguard在10gR2的bug,不管怎么样确实是在特定的时间做了特定的操作结果碰到了特定的问题。 这个问题是在10gR2的版本10.2.0.4.0的一个库中出现的,在做巡检的时候发现表空间使用率已经很高了,就准备加一些数据文件把这个问题给修复了,按理说这也是一个常规操作,没有什么可圈圈点点的地方。 但是添加完数据文件之后,过了一会,就收到报警说备库出了点问题,自己还纳闷到底是什么原因导致的,带着疑问使用dgmgrl来查看了一下。 DGMGRL> show configuration;
领取专属 10元无门槛券
手把手带您无忧上云