<?xml version="1.0" encoding="UTF-8"?><rss version="0.92">
<channel>
	<title>TTA -- when you believe</title>
	<link>http://www.easyora.net</link>
	<description>想到达明天现在就要启程...</description>
	<lastBuildDate>Thu, 03 Nov 2011 12:28:02 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	<!-- generator="WordPress/3.1.1" -->

	<item>
		<title>RAC环境中threads变更后如何确保goldengate继续正常复制</title>
		<description><![CDATA[&#160;&#160;&#160;&#160;&#160;&#160;&#160; 当rac节点变更的时候，比如我们添加或者删除了集群中的节点，理所当然会对节点对应的log threads进行添加或者删除，但会造成goldengate的map log threads的顺序发生紊乱。在进行这一类行为变更的时候，特别需要注意goldengate端也需要进行特别处理。 &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; 比如，在节点添加之前，goldengate map log threads顺序如下(数据库log thread在后，下同)： &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; 1—&#62;1 (假设是sequence 100，rba 1001) &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; 2&#8212;&#62;2(假设是sequence 88，rba 3009） &#160;&#160;&#160;&#160;&#160;&#160;&#160; 当添加节点后，map log threads的顺序会变成： &#160;&#160;&#160;&#160;&#160;&#160;&#160; 1&#8212;-&#62;3(sequence 88，rba 3009） &#160;&#160;&#160;&#160;&#160;&#160;&#160; 2&#8212;-&#62;1(sequence 100，rba 1001) &#160;&#160;&#160;&#160;&#160;&#160;&#160; 3&#8212;-&#62;2(new) &#160;&#160;&#160;&#160;&#160;&#160;&#160; 当ogg重新工作的时候，因为此时map的顺序发生了变化，因此会造成抽取进度出现问题。 &#160; &#160;&#160;&#160;&#160;&#160;&#160;&#160; 如果有足够的处理时间，简单而又安全的做法是停止源端应用，删除extract进程后，重新配置新的extract进程并从当前开始抽取。但在这段时间内，所有的操作需确保在应用已经停止服务的前提下，否则数据将造成丢失或者不一致，需要手工处理或者重新初始化。 &#160;&#160;&#160;&#160;&#160;&#160;&#160; 如果应用无法停机呢？我们可以将新建的extract进度修改成停止之前的进度状态，从而避免操作过程中应用的停机行为。 &#160;&#160;&#160;&#160;&#160;&#160;&#160; 需要我们特别记录的checkpoint有：Current Checkpoint、Recovery Checkpoint以及Write Checkpoint 1.正常停止extract(略) 2.获得extract的checkpoint记录 &#160; GGSCI (node1) 21&#62; info ext_r1 showch [...]]]></description>
		<link>http://www.easyora.net/blog/goldengate_rac_threads_remap.html</link>
			</item>
	<item>
		<title>goldengate&#8211;使用filter+@GETENV在线重新初始化指定的table</title>
		<description><![CDATA[&#160;&#160;&#160;&#160;&#160;&#160;&#160; 在oracle-oracle goldengate的复制环境中，有时候会碰到一些紧急的问题一时无法修复，为了避免影响整个复制环境的复制进度，采取跳过错误事务或者跳过特定对象的办法使得goldengate继续同步；如果后续某个表不得不需要重新同步，而且应用是不间断进行事务操作的，在不停止应用和重建整个复制环境的情况下，为了保证数据的一致性，如何在线对特定的问题对象重新初始化和继续同步呢？ &#160;&#160;&#160;&#160;&#160;&#160;&#160; 处理的办法还是不少的，下面给出一个在replicat端过滤SCN事务的办法，来实现数据的一致同步。 &#160;&#160;&#160;&#160;&#160;&#160;&#160; 处理的思路就是首先在target上获得该表上某个特定SCN版本上的数据(比如使用导入导出或者数据泵)，然后通过filter功能来筛选出该表上大于该commit scn的事务，从而确保事务的一致性。在goldengate v10之后，可以通过@GETENV函数直接获得事务的CSN。&#160; &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; 简单看一下处理步骤，假设目前gg环境中hr.translog表需要重新初始化，由source端hr用户同步到target端hr2用户下。 &#160;&#160;&#160;&#160;&#160;&#160; &#160; 1.停止target上的replicat进程 GGSCI (sh) 44&#62; stop rep_hr2 Sending STOP request to REPLICAT REP_HR2 &#8230; Request processed. &#160;&#160;&#160;&#160;&#160;&#160;&#160; 2.获得source上hr.translog表的特定SCN一致性版本 SQL&#62; select dbms_flashback.get_system_change_number from dual; 9543774 &#160;&#160;&#160;&#160;&#160;&#160;&#160; 使用exp进行一致性版本导出 [oracle@gz ~]$ exp hr/hr tables=translog file=translog.dmp flashback_scn=9543774 Export: Release 10.2.0.1.0 &#8211; Production on Tue Aug 9 00:27:42 [...]]]></description>
		<link>http://www.easyora.net/blog/using_filter_getenv_function_to_initialize_special_table.html</link>
			</item>
	<item>
		<title>oracle-oracle goldengate零停机初始化的技巧</title>
		<description><![CDATA[&#160;&#160;&#160;&#160;&#160; 在实施goldengate过程中，初始化的方案选择是一个重要的环节，尤其对一个7*24小时的系统环境来讲。一个出色的&#160;&#160;&#160; goldengate的实施不应该以停机时间作为代价，合适的初始化方法完全可以做到零停机。&#160; &#160;&#160;&#160;&#160;&#160; 如果事务不间断进行，如何保证初始化过程中事务的完整性和数据的准确性呢(静态的初始化环境无需多讲)？实现方法还是多样的，从工作机制上来讲，归纳起来主要有2种。 &#160;&#160;&#160;&#160; 1. 利用 Keys + Handlecollisions &#160;&#160;&#160;&#160; 2.利用 commit SCN/CSN &#160;&#160;&#160;&#160;&#160;&#160;&#160; Handlecollisions参数依赖于表上的Key(Primary key/Unique key)来对数据进行重复行和缺失行的处理，常在数据初始化过程中保证数据的一致性，gg文档上的初始化办法，比如initial load，都是用的这种办法。但是这种办法在实际的工程实施中是有相当大的限制。 &#160;&#160;&#160;&#160;&#160;&#160;&#160; 首先，该初始化办法性能比较糟糕，对于大型数据库来讲，并不合适。更严重的是，它有很大的缺陷性。(引自metalink doc)： 1. When there is primary key update (PKUpdate), the HANDLECOLLISIONS method may lose data. The solution in the case of a primary key update is for Extract to fetch whole row by [...]]]></description>
		<link>http://www.easyora.net/blog/goldengate_initialization.html</link>
			</item>
	<item>
		<title>goldengate培训提纲&lt;一&gt;</title>
		<description><![CDATA[&#160;&#160;&#160;&#160; Blog一晃半年没有更新了，还真对不起每年交的空间和域名费。 &#160;&#160;&#160;&#160; 一连实施了好几个goldengate的项目,关注ogg也有好些时日了。这是前不久应客户要求做的goldengate的培训，share一下。因为用户只是应急容灾的应用，因此ogg上的很多功能当时并没有提及。接下来的blog会持续整理goldengate的一些问题和技巧。 第一篇 Oracle Goldengate基础技巧 第一节 Goldengate体系介绍 1. Goldengate架构 2. Goldengate工作原理 3. Goldengate使用场景 第二节 安装配置Goldengate 1. 安装Goldengate软件 2. 配置和管理进程 3. Goldengate的安全加固手段 第三节 Goldengate数据初始化 1. 基于keys+HANDLECOLLISIONS初始化 (1) keys+HANDLECOLLISIONS的工作原理和缺点 (2) direct load的局限性和操作步骤 2. 基于SCN consistent初始化 (1) 基于SCN初始化的工作原理和特点 (2) 基于Exp/imp和expdp/impdp一致性初始化使用场景和步骤 (3) 基于transport tablespace with backupset初始化使用场景和步骤 (4) 基于Dataguard模式的初始化使用场景和步骤 第四节 DML常规复制 1. DML复制的工作原理 (1) Keys对rows复制处理的影响 (2) 追加Column日志对rows复制处理的影响 (3) [...]]]></description>
		<link>http://www.easyora.net/blog/goldengate_trainning_1.html</link>
			</item>
	<item>
		<title>When you Believe-2011，怡然前行</title>
		<description><![CDATA[&#160;&#160;&#160;&#160;&#160;&#160; 曾期许做一个舞文泼墨者，将或喜或悲点缀到跳动的字里行间，洒脱自得；然而，不经意的却走向了it这个湖潭，逐流随波，几近五载。 &#160;&#160;&#160;&#160;&#160;&#160; 成长会让理性变成习惯，但感性亦不会荡然无存。 &#160;&#160;&#160;&#160;&#160; 恋上了随遇而安，却总爱奢华的瞻望。当踮起脚尖的时候，已然望不到尽头，剩下了就是不安与惶恐。这种惶恐近来愈发强烈，却着实不得不面对。岔路口上，或左或右需要是睿智；而坡路上，迎面总好过退缩。瓶颈虽不会无处不在，但却很难让它无处遁形。惶恐之由，想罢是生性中最脆弱的一面又蠢蠢欲动，夹杂着诸多不尽人意，难免碰触到最敏感的神经。 &#160;&#160;&#160;&#160;&#160; 漂泊了4个半年头后，在广州算是有了个尚未交付的栖息之所。心情沉重了很多，决非释然。想来这是一种微妙的感觉，诸如我们这般琐居的外乡人，独自飘零，兀自找寻。即便有了归属，心又归于何处。 &#160;&#160;&#160;&#160;&#160; 好好对待身边的人，朋友，亲人。谢谢陪伴自己一路走过的人。 &#160;&#160;&#160;&#160;&#160; 责任当是种爱的感知和传递。花自漂零，怡然前行。 &#160; &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; &#8212;&#8212;2011.3.22 广州 No Related Post]]></description>
		<link>http://www.easyora.net/blog/2011_life_continue.html</link>
			</item>
	<item>
		<title>Cascaded Destinations/Cascaded Standby Databases</title>
		<description><![CDATA[Cascaded Destinations，简单的讲，就是为了避免主库的压力和干扰，将主库产生的redo通过一个standby传送到另外一个standby上，而不是直接通过primary到另外一个standby。在Oracle各版本的在线文档上，对此界定也并不一致。比如这样一个组合方式：Primary Database > Logical Standby Database  > Physical Standby Database，因为最后一层的standby并不和第一层的priamry database有直接关系，1-2和2-3分别自成体系，这并不是一个真正意义上的Cascaded Destination。但在10g和9i在线文档中，依然将这种模式列为cascaded destinations，这一点在相关联机文档和metelink Doc也有所提及。]]></description>
		<link>http://www.easyora.net/blog/oracle_cascaded_destinations.html</link>
			</item>
	<item>
		<title>Oracle读写分离架构</title>
		<description><![CDATA[oracle 读写分离]]></description>
		<link>http://www.easyora.net/blog/oracle_read_write_separated_architecture.html</link>
			</item>
	<item>
		<title>Undocumented Way&#8211;通过手工创建sql profiles固定执行计划进行SQL调优</title>
		<description><![CDATA[&#160;&#160;&#160;&#160;&#160;&#160;&#160; 一直以来对SQL profiles都是爱恨有加。SQL profiles的灵活和一些特性(比如对SQL语句级的类似cursor_sharing功能，对非绑定变量环境非常实用)，在不很多不能修改应用代码的场景下最小风险的对SQL语句进行调优，是传统的outline无法比拟的;但是用过SQL profile的朋友应该都清楚，按官方的SQL tuning Advisor提供的sql profies生成办法，由于包含了太多了nodirective Hints(比如OPT_ESTIMATE/COLUMN_STATS/TABLE_STATS等),并不能保证执行计划的稳定性，会随着外界的因素发生改变(比如表和索引的信息，柱状图等信息的变化) 。尽管二者都是依靠hints来提示或者指挥优化器完成执行计划的解析，但却不尽相同。通过SQL Tuning Advisor 生成的hints更多是为执行计划的生成提供评估和参考信息，而Outlinie Hints，倾向于指挥命令。 &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; 前几天在查阅新书&#60;Pro Oracle SQL&#62;介绍的时候，看到作者blog上有提出了undocmented way手工构造SQL profile的例子，确实能像outline一样，强制固定住执行计划，这顿时让我觉得柳暗花明，因为我之前一直对SQL profiles的稳定性大伤脑筋。结合最近的几次项目调优，使用这种办法固定SQL计划，效果相当不错。 &#160;&#160;&#160;&#160;&#160;&#160;&#160; 手工构造SQL Profiles，可以使用oracle提供的dbms_sqltune.import_sql_profile过程。 SQL&#62; desc dbms_sqltune.import_sql_profile Parameter&#160;&#160; Type&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; Mode Default? &#8212;&#8212;&#8212;&#8211; &#8212;&#8212;&#8212;&#8212;&#8212;- &#8212;- &#8212;&#8212;&#8211; SQL_TEXT&#160;&#160;&#160; CLOB&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; IN&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; &#8212;-sql文本 PROFILE&#160;&#160;&#160;&#160; SYS.SQLPROF_ATTR IN&#160;&#160;&#160;&#160;&#160; &#8212;-profile info NAME&#160;&#160;&#160;&#160;&#160;&#160;&#160; VARCHAR2&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; IN&#160;&#160; Y&#160;&#160;&#160;&#160; &#8212;profile名称 DESCRIPTION VARCHAR2&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; IN&#160;&#160; Y CATEGORY&#160;&#160;&#160; VARCHAR2&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; [...]]]></description>
		<link>http://www.easyora.net/blog/manual_create_sql_profile_lock_sqlplan.html</link>
			</item>
	<item>
		<title>完全手工重构ASM Disk Header &lt;二&gt;</title>
		<description><![CDATA[&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; ASM disk header 相关信息如何获取，可参考 完全手工重构ASM Disk Header &#60;一&#62; &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; 以下是一个ASM diskgroup中disk文件头全部损坏重构的例子。 &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; 启动asm实例，diskgroup TEST无法挂载。 &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; 以下是alert.log错误信息： &#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;-&#160; NOTE: cache registered group TEST number=2 incarn=0xc868c69a Sun Dec 19 14:44:38 2010 ERROR: no PST quorum in group 2: required 2, found 0 Sun Dec 19 14:44:38 2010 NOTE: cache dismounting group 2/0xC868C69A (TEST) NOTE: dbwr not [...]]]></description>
		<link>http://www.easyora.net/blog/manual_fix_asm_disk_header2.html</link>
			</item>
	<item>
		<title>完全手工重构ASM Disk Header &lt;一&gt;</title>
		<description><![CDATA[完全手工重构ASM Disk Header]]></description>
		<link>http://www.easyora.net/blog/manual_fix_asm_disk_header1.html</link>
			</item>
</channel>
</rss>

