Author: mac

本文永久地址：https://www.askmac.cn/archives/goldengate-ogg-回切方案.html GoldenGate OGG 回切方案   回切步骤 1.恢复生产系统数据库服务，如果数据库可以直接恢复，只需要处理数据增量同步，如果数据库本身不可恢复，需要从应急系统向生产系统进行全量数据初始化 2.在生产数据库上禁用触发器和数据约束 3.启动生产数据库的数据投递进程，从应急数据库向上产数据库同步数据 4.应急系统积压的数据处理完毕，生产系统数据实现与应急数据库的同步 5.停止应用运行，确认数据已经完全同步回生产系统（数据对比见下文) 6.启动生产系统的数据捕获进程 7.启用生产系统数据库的触发器和数据约束 8.重置生产系统数据库的Sequence 9.修改应用的数据源配置到生产系统数据库 10.启动应用 11.禁用应急数据库的触发器和数据约束 12.确认应急数据库的数据同步配置包含Sequence，启动应急数据库的数据投递进程 13.监控数据同步情况和系统运行情况。     应急系统向生产系统回切（https://www.askmac.cn/） 6.1 回切条件 原有生产系统恢复运行，如果原生产系统数据可以恢复，首先完成从生产向应急的剩余数据 同步过程，然后启用生产系统的投递进程，把应急系统运行期间处理的数据同步回生产系统， 应急系统的积压数据处理完成后即具备向生产系统回切的条件。 6.2 回切操作 如果生产系统中存在强制性自增列则： 应急系统向生产系统进行全量数据初始化，并开始捕获应急系统的增量数据 在生产数据库上禁用触发器和数据约束 启动生产数据库的数据投递进程，从应急数据库向上产数据库同步数据 应急系统积压的数据处理完毕，生产系统数据实现与应急数据库的同步 停止应用运行，确认数据已经完全同步回生产系统 启动生产系统的数据捕获进程 启用生产系统数据库的触发器和数据约束 修改应用的数据源配置到生产系统数据库 启动应用 禁用应急数据库的触发器和数据约束 确认应急数据库的数据同步配置，启动应急数据库的数据投递进程 监控数据同步情况和系统运行情况。 如果生产系统中不存在强制性自增列则： 恢复生产系统数据库服务，如果数据库可以直接恢复，只需要处理数据增量同步，如果数据 库本身不可恢复，需要从应急系统向生产系统进行全量数据初始化 在生产数据库上禁用触发器和数据约束 启动生产数据库的数据投递进程，从应急数据库向上产数据库同步数据 应急系统积压的数据处理完毕，生产系统数据实现与应急数据库的同步 停止应用运行，确认数据已经完全同步回生产系统 启动生产系统的数据捕获进程 启用生产系统数据库的触发器和数据约束 修改应用的数据源配置到生产系统数据库 启动应用 禁用应急数据库的触发器和数据约束 确认应急数据库的数据同步配置，启动应急数据库的数据投递进程…

本文永久链接： https://www.askmac.cn/archives/goldengate-ogg-issues.html ‎ GoldenGate OGG Extract常见问题 Extract: Application failded to initialize（Win） 错误描述： run ggsci command but the Alert window report “Application failded to initialize(0xc000026e)” 错误分析： –GoldenGate在Windows平台上需要安装Microsoft Visual C ++ 2005 SP1 Redistributable Package –如果是Microsoft Itanium平台,需要安装vcredist_IA64.exe –Windows 2008需以下额外操作 右击‘cmd‘ (DOS), 选择’run as administrator’，然后在该命令行窗口中启动mgr和extract才能够读取数据库日志； 将OGG安装为服务 时(即运行“install ADDSERVICE”)，需要使用管理员权限.这样启动服务后即能访问日志。 通过以下方法为运行mgr和extract的用户添加读取日志文件的权限. 右键点击文件 ->property->security->Edit->add   Extract: Cannot load program ./ggsci .…

原帖《【性能调优】Oracle AWR报告指标全解析》 地址：https://www.askmac.cn/archives/performance-tuning-oracle-awr.html 由于是整理自帖子的文档，目前还没加目录，今后争取进一步完善并加入目录，敬请期待。   【AskMaclean技术分享Oracle数据库优化】   AWR鹰眼系列AWR报告全面指标分析文档下载：   地址:https://www.askmac.cn/wp-content/uploads/2013/10/【AskMaclean技术分享Oracle数据库优化】AWR鹰眼系列AWR报告全面指标分析.pdf

  X$mutex_sleep.location 的官方解释是 Location that attempted to acquire the latch (Mutex’s code location (where field)  ，这个解释看上去还是有些模糊，我们来做个试验看看   我们简单地使用 gdb来模拟一个Curosr : Pin S on X等待事件，并以此事件来解释X$mutex_sleep.location 的真实含义 我们会打开3个session 分别为A、B、C ， 一个gdb ， 和一个sqlplus 用以oradebug   Session A:     [oracle@mlab2 ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Tue Oct 8 21:40:19 2013 Copyright (c)…

【Oracle RAC调优】RAC多节点使用不同的gcs_server_processes参数可能导致gc cr multi block request等待事件;  例如一个RAC实例 的 gcs_server_processes=5   而另一个实例为gcs_server_processes=4  就可能引起额外的gc cr multi block request等待事件， 该问题在RAC 11.2.0.3 中仍存在。 建议是使用相同的gcs_server_processes。   遇到该gc cr multi block request等待事件，在参数方面建议检查： show parameter gcs_server_process show parameter cpu_count show parameter db_file_multiblock_read_count OS参数 ：udp_recvspace 、 udp_sendspace NUM_CPUS NUM_CPU_CORE   Yes, it is supported/allowed to set different GCS_SERVER_PROCESSES for RAC instances. This is confirmed…

在这个1小时的网上研讨会中，我们会对性能调优的基本概念和术语进行介绍，带您了解AWR的结构和其中的内容。另外，我们也会通过一些具体例子对如何使用AWR进行性能调优进行讲解。 本次网上研讨会包括以下议题 : + 能调优的基本概念和术语进行 + 了解AWR的结构和其中的内容 + 使用AWR进行性能调优案例演示 WebEx会议注册方法（含音频） 时间和日期：2013年10月16日14:00（北京时间） 会议号码: 594 196 915 如何注册本次会议 1. 点击会议地址：https://oracleaw.webex.com/oracleaw/onstage/g.php?d=594196915&t=a 2. 注册本次会议 在确认了您的请求之后，您将会收到确认电子邮件，与参加会议的说明。 InterCall音频使用说明 如果Webex的音频效果不佳，您也可以拨打下面的电话，加入电话会议： – 电话会议ID: 25257883 – 中国南方免费电话: 108001201870 – 中国北方区免费电话: 108007121869 – 香港地区: 8009 661 55 – 台湾地区: 00801044259 – 全球各地免费接入电话可以从下面的MOS文档 1148600.1 中查到。 请注意：上述电话会接通英文接线员，请用英文告知会议编号（25257883）及您的名和姓（First Name and Last Name） 想了解更多的数据库网上讲座？请访问 MOS 文档 1456176.1。 本次讲座问题提问环节的问题回答及后续的讨论，请访问中文论坛帖子。 下载本次讲座的录音和文档，请访问MOS…

em process consuming large memory suspected 中建议在AIX平台上监控多个目标时设置LDR_CNTRL和 AIX_THREADSCOPE 这2个参数。     实际在12c的官方文档Oracle® Enterprise Manager Cloud Control Administrator’s Guide 12c Release 2 (12.1.0.2)中也提到了http://docs.oracle.com/cd/E24628_01/doc.121/e24473/emctl.htm#CBHCDGCD：     On IBM AIX environment with a large memory configuration where the Management Agent is monitoring a large number of targets, the Agent may not start. To prevent this issue, prior to starting the Management Agent, add the following…

11g的asmca图形化工具启动后可能存在问题， 对于已经启动的ASM实例无法识别， 报是否需要启动asm实例。 asmca的日志位于 ASMCA logs from $ORACLE_BASE/cfgtoollogs/asmca/* 日志显示：   [main] [ 2013-09-26 15:53:29.906 GMT+08:00 ] [InventoryUtil.getOUIInvSession:336] oracleHome is null. Leaving OUI properties to defaults [Finalizer thread] [ 2013-09-26 15:53:29.912 GMT+08:00 ] [Util.finalize:126] Util: finalized called for oracle.ops.mgmt.has.Util@32523252 [main] [ 2013-09-26 15:53:29.917 GMT+08:00 ] [InventoryUtil.getOUIInvSession:347] setting OUI READ level to ACCESSLEVEL_READ_LOCKLESS [main] [ 2013-09-26 15:53:29.917 GMT+08:00…

    SQL> select count(*) from abc; select count(*) from abc * 第 1 行出现错误: ORA-01578: ORACLE 数据块损坏 (文件号 17, 块号 131) ORA-01110: 数据文件 17: ‘C:\APP\XIANGBLI\ORADATA\MACLEAN\DATAFILE\O1_MF_NLOGGING_9475OCS5_.DBF’ ORA-26040: 数据块是使用 NOLOGGING 选项加载的   SQL> select UNRECOVERABLE_CHANGE# , UNRECOVERABLE_time from v$datafile where file#=17; UNRECOVERABLE_CHANGE# UNRECOVERABLE_ ——————— ————– 6486756 26-9月 -13   把 (文件号 17, 块号 131) dump出来看一下  …

今天我想展示可以从Oracle数据库机得到哪种IO性能。在这一部分，我会着重于硬盘。就是那些很好的又有些年头的棕色旋转磁盘。 我经常使用Oracle ORION工具压力测试一个IO子系统并找到它的范围。这是一个非常简单又便利的工具，也会经常提供我需要的大部分的IO模拟。 我通常标杆小型随机IO和大型顺序读取。这给了我一个好想法，我可以从这个IO子系统期待OLTP工作负载以及批量数据处理的工作负载包括数据仓库，备份和批量活动。我通常不进行压力测试的混合工作负载，直到我知道什么是应用程序的配置文件，我才会在此平台上运行。 今天，让我们谈谈OLTP工作负载的属性小型随机IO。我感兴趣的是单一的IO响应时间以及每秒的IO（IOPS）。 当我压力测试一个IO子系统时我通常处理平均数，但我永远记住，平均数是平均值。因为我的人工的ORION工作量是相当随机分布的并且我用相当少的时间间隔，结果给我很好的信心，但在某些情况下，我想进一步挖掘和收集IO延迟的一些直方图。尽管对Oracle数据库机我还没有做到，但我知道后面期望的响应时间是相当一致的，但仍没有使响应时间磁盘缓存或类似的东西有偏差。 我要指出，在这里我使用的术语IO响应时间和IO延迟互换以防你正在使用不同的这些术语。这可能是一个坏习惯，但是这就是我所做的。 在我压力测试一个IO子系统之前，我通常会设置一些期望值，在这里我们也这样做。ODA有20个磁盘 – 15K RPM SAS磁盘。我的经验告诉我，非常好的一个IO延迟（低于10ms），这些磁盘提供每次至少100 IOPS。我也希望这些磁盘仍然会提供合理的响应时间，如果你提高工作量到大约200 IOPS，但是我会看到进入20ms的范围内更高的响应时间。 我尝试执行与写入不同的百分比进行IO压力测试，看看写活动的影响。当我评估一个特定的应用程序时，我可以预测IO模式或测量现有格局IO能力，这非常有用。同样，我有一些期待。对于RAID 5，RAID-DP，以及不管怎样使用校验的各种其他RAID-F的水平，我预计，随着写活动变得更占优势可持续的IOPS水平显著下降。至少目前为止，在我看来无论供应商实现什么神奇的解决方案， IOPS仍会始终持续下降。 直到ASM执行基于主机的镜像，ODA磁盘才进行镜像，但我收集在ASM 下面的IO数字，所以我期待从写活动，乃至正面影响中很小的IOPS退化，即减少“平均”响应时间和提高IOPS吞吐量。这通常发生在RAID控制器或SAN阵列具有合理写高速缓存，它不是饱和的时候。 但是更多的话…还是让我们跳转来看我最爱的数字和他们的视觉表现——图！ 我已经注意到在ORION中一个新的运行选项——“run oltp”，因此我决定试一试。这个选项似乎触发大量并行IO线（比限定磁盘的“正常”数量的数目多很多）。我认为这种方式成本太高，但它确实对写入的IO影响有很好的迹象。我仍然会重新做不同的写入百分比测试使用一个更传统的ORION选项。 回到上面的图表——你从图中看出了什么？我看到，我们从每个磁盘获取平均100-150左右IOPS（我们有其中的20），而平均IO响应为10毫秒之内。这是完全正确的。我还可以看到，随机的IO吞吐量可扩展到200-250 IOPS，而IO的响应时间仍然是在20毫秒范围内。我们甚至可以看到磁盘能够提供持续的300随机IOPS，但是平均的IO响应时间成本却很高。需要注意的是，写开销最小是在我的期望之内的。 总之，你可以期望ODA提供方便地3000 IOPS，无论读或写的平均IO响应时间可达到10ms，如果你能买得起，那么平均随机IO响应时间会提高到20毫秒，几乎增加一倍。而更高的吞吐量是可能的，实用的可用性是有限的，除非你已经高度并行批处理作业做大量的小型随机的IO。不过，你可能有非常低效的数据处理应用程序中的设计即可。我们也可以得出结论，写活动对整个你期待的非RAID5系统预期的影响微乎其微。 关于写IO报告和规划与ASM镜像需要注意的地方。ORION报告非镜像写入的数量。如果使用的是正常的冗余，您需要为您的容量加倍刨写入数和三重他们具有高冗余创建ASM磁盘组。例如，如果您的容量规划要求，你需要1000个随机IOPS和200写入IOPS和你正在使用的ASM高冗余，您将需要为1600 IOPS与写IO的37.5％计划。如果你的镜像水平下面的ORION做到，那么你的号码已经占到镜像写入。 让我来比较这与一些写缓存RAID控制器，一个小规模的直接附加存储： 上面的图表是不是来自ODA，但我把它作为比较。这四个15K RPM SAS直接连接的内部磁盘。注意：当您添加写的IO进入混合和平均IO响应时间下降时吞吐量略有增加。如果我增加写入百分比，那么我的吞吐量进一步增加（图表上没有显示），如果我考虑平均响应时间的读取和写入，会看到，平均写入延迟会低得多，然后读取延迟，我相信这是RAID阵列缓存在这种情况下产生了影响。请注意，我提到RAID阵列，但它的配置为目前磁盘作为JBOD，这样ASM负责镜像和条带化。   我要用更多的时刻，证明为什么Oracle的ASM中只决定使用RAID1，例如在ASM中的镜像比奇偶镜像更好（请注意对于硬盘，SSD可能是一个不同的存储，但我们不要现在去那里）。下面是一个小3Par的SAN阵列RAID5配置的组（一年多前做过的基准）： 你可以看到，即使引入10％的写入（紫色）展品吞吐量和平均响应时间明显下降。成长写入活动高达40％（蓝色）和我们的随机读取（绿色），你会得到吞吐量下降3-4倍。你也可以看到，3Par的缓存有助于在降低吞吐量的水平，但它很快得到饱和，写IO拖动整个子系统下来表现。 现在，让我们来看看在同一阵列3Par公司，但使用RAID 1+0的配置——同样的物理磁盘和相同的SAN，FC基础架构： 仅在达到2500 IOPS良好的水平之后写入的40％开始有明显的影响，但这时如果你计算附加镜在SAN上写入，你会看到，我们只是达到了物理磁盘IOPS能力。进一步说，如果所有的IO活动用100％写入（红色）表示，IO退化仍然是合理的（记得要双数去，由于在SAN箱镜像随机写入将磁盘的实数）。 这里还有一个有趣的现象——在较低的活动级别，写操作实际执行快得多。我相信这是因为支持写操作的cache的电池容量足够在这个工作量水平，从而写入重新排列，并且更高效地完成。所以，同样的写高速缓存更有效地适用于RAID1，而不是RAID5。我觉得很有意思的是存储厂商仍然让我们用RAID5，理由是因为他们写高速缓存诀窍技术，基于奇偶校验的RAID阵列神奇地表现比很好很旧的RAID1还要更好。 好。现在是时候回到ODA这个话题了。我想重新运行我的测试：使用较小程度的并发度直观地看到它是如何扩展的。目前为止，我很满意我的写入IO影响分析，但我想衡量我们可以从开始使用磁盘的内外区得到多少好处。盘的外部部分普遍被认为比内部区更快——由于外部数据更密集，并且有读出速度更快的外部轨道，头移动更短:因为它仅需要在较少数量的外磁道之间移动。 我运行标准检查程序并且使用三个测试案例——使用整个磁盘、使用磁盘容量的第一个40%（意思是它应当是在外侧磁道）然后使用磁盘剩下的60%（意味着它的内部轨道）。结果如下，在相同的熟悉的格式下IOPS吞吐量和平均IO延迟/响应时间。 人们可能预期该磁盘外部是最快的，内部是最慢的，而整个磁盘性能会是平均的。实际上，反应时间最大的节省是来自磁盘头部不需要移动那么远而不是限制数据放置到一组外轨道或一组内轨道。被减少的是当旋转延迟保持相同的，更密集的数据放置在外磁道，而不影响IO响应时间的头部移动延迟组件的延迟。   这就是我们看到的最快的外部40%加最慢的内部60%和整个磁盘区域更慢，因为头部需要移动的更远，会考虑到较长的轨道之间的头部位置。 对于在外部磁盘空间40%的纵轴数据，让我们可以从大约2900 IOPS吞吐量增加到4500 IOPS，同时保持平均响应时间10毫秒时的水平。如果我把它表现成增长50%——我认为在这个图表上就不能很好的被展现出来。因此在写这个报告时，我认为存在一个更好的表现这个信息的方法——作为对于这个分析更相关的，我们可以去掉IO的并发数: 这个图表把当保持平均响应时间在同一水平上时你可以通过磁盘的外磁道数据增加多少的IOPS表现得更好。 基于这个很好的笔记，我完成了这个博客的帖子。敬请关注ODA的连续的大IO和SSD基准的分析。