1. 捕获增量的底层机制是什么？(例如日志、触发器、LogMiner)
PWX利用Oracle的LogMiner来提取来自于Oracle的增量， LogMiner是由Oracle数据库提供的，如果当前在环境中没有利用那么它的配置似乎很简单的。
2. 能否提供更多关于LogMiner做什么的信息吗？
它的接口允许PWX维持不冲突的链接(non- invasive, code-free)来支持Oracle的不同版本。如果Oracle改变数据结构，LogMiner接口持续地提供实际未改变的数据库连接为了捕获增量。约束或者限制因素是支持的数据类型是有LogMiner支持的数据类型决定的。
用户数据或者数据词典的所有变化都被记录在Oracle Redo Logs里。Oracle提供了通过LogMiner 使用SQL访问重做日志，LogMiner通过固定的视图V$LOGMNR_CONTENTS记录了重做日志里的信息。视图包含了关于数据库变化的历史信息，包含如下：
数据库变化的类型（INSERT, UPDATE, DELETE, or DDL).
SCN column
COMMIT_SCN colum
SEG_NAME and SEG_OWNER columns
使用DDL或者DML语言进行改变用户的名字USERNAME column
3.在我的Oracle环境里实现归档日志的预期消耗是什么？
Oracle必要地启动了额外的归档进程(ARCn)来保证自动处理填写重做日志以保持同步，然而，为了避免任何运行时间调用额外ARCn进程的消耗，在实例运行时你可以使用LOG_ARCHIVE_MAX_PROCESSES初始化参数具体指定进程的数量，最大10个ARCn进程可以启动，一般地来说不需要改变LOG_ARCHIVE_MAX
_PROCESSES的初始化参数2，因为Oracle会根据系统负荷适当调整ARCn进程数。
对于大多数数据库，ARCn在整个系统的性能上没有影响，然而，在一些大型数据库上，归档过程会给系统性能造成影响。一方面，如果ARCn运行的很快，整个系统的性能会被降低当ARCn运行的时候，因为CPU的周期被用于归档了。另一方面来说，如果ARCn运行的相当慢，它对于系统性能几乎没有有害的影响，但是这会花费更长的时间来归档重做日志，这会造成一个瓶颈，因为重做日志组等待归档而导致重做日志组不可用。
多个ARCn可以防止瓶颈的发生，当LGWR交换使用多个重做日志会比一个单一的ARCn进程写一个未激活的日志到多个目标快，每一个ARCn进程一次只会工作在一个未激活的日志上，但必须归档到每一个指定的目标。
4.如果增量日志开启进行CDC的话，磁盘空间的增加百分比是怎么样的？
一个Supplemental Log 组只增加额外的磁盘空间应对DML的操作，额外增加的磁盘空间与当前在你的Oracle环境更新列的数目成正比的。PWX需要Oracle supplemental log 组提供一个完全的历史的和未来变化记录的映像产品。如果在你当前的操作环境里你的应用程序正在更新你数据库表的大多数字段，那么磁盘空间的增加不应该很大
5.就资源占用率而言LogMiner占用多少额外的源？
如果最小化的supplemental logging 启用的话，LogMiner使用对应数据库实例生成重做日志不会有任何大的性能影响。PWX仅仅在抽取的时候利用了LogMiner。PWX使用LogMiner访问日志提取变化数据要比直接进行数据库操作的开销要小得多。
6.PWX（多Logminer）写任何数据到任何Oracle目录文件（例如$Restart 表的Logminer的checkpoints）吗？PWX写到Logminer表么（V$Tables）？
PWX不会写任何数据到V$Tables（vtable$）中，你可能注意到Oracle会写一条‘'dummy'’的记录当PWX进行挖掘时，我们不会要求Oracle去写那些数据的，PWX不需要或者更新那条记录的任何数据。具体的说，Logminer将数据写入logminer表而且也会创建一个临时表lognmr_restart_ckpt$ table，如果它们对你成问题，你可以做任何你想做的为了清洗那些记录，一般来讲不需要考虑这些问题。
7.我们有能力设置Logminer默认内存大小或者检查点频率（或任何其它的设置）
在API里，这个开发工具没有任何选项修改默认设置
8. Logminer使用了多少内存
PowerExchange使用PGA来为它们的内存在OS级别的内存使用的限制范围里面根据需要使用内存
9.对源操作数据库有什么影响？
这是到目前为止值得讨论的问题，Oracle环境有3个主要的Oracle需求，让我们分别描述好当你遇到这些问题是你可以自己定位。
归档模式：大多数用户一般用这个模式运行他们的产品数据库否则如果发成事件失败的话他们会极端冒险的暴露自己。
database/LogMiner的最小化的增量日志 PWX使用LogMiner（Oracle重做日志的API）捕获增量变化LogMiner需要增量日志从日志中来抓有意义的信息，它可以提供：最小化的增量日志记录LogMiner需要识别、分组、合并关联DML变化的REDO操作的最小量信息。它保证了LogMiner有足够的信息支持累计的行和多种存储像簇表，在数据库级别开启最小化增量日志，不会增加数据库的大量消耗，Oracle适配器向导支持这种状态。
这是来自于Oracle Admin Guide：最小化增量日志启用的LogMiner使用不会有很大的性能影响对于数据库实例生成重做日志。已经做过性能测试验用户的用户表示当最小化增量日志开启时对数据库的性能影响不超过1%。
另一种数据库增量日志是识别日志的关键字，这种类型的增量日志有潜在的引起大规模性能消耗的危险。这种级别的增量日志不适合PWX for Oracle RT.
增量日志组（表级别）PWX生成DDL为每一个PWX捕获的表来增加一个增量日志组，这允许PWX查看完全的之前或之后的无论何时更新的记录映像，这存在潜在的可能为更新DML的数据库增加额外的日志。如果增量日志组没有定义，仅仅
特定字段的变化会被记录。有了增量日志组的增加，任何被捕获的字段的变化会产生完全的之前之后的映像然后被记录。如果用户有一个应用程序已经更新表中大多数字段，因为大多数记录已经被记录，那么消耗可能不会被注意到。然而当用户的应用程序在一个50+的表中仅仅有少量字段被更新的话，就磁盘性能而言他们可能会看到日志活动图有一个跳跃。
这里还有一些来自于Oracle 92 Admin guide:的信息：无条件的日志组-之前的映像被记录， Unconditional log groups - The before images of specified columns are logged any time the table is updated, regardless of whether the update affected any of the specified columns. This is sometimes referred to as an ALWAYS log group.
10. LogMiner占用多少资源？
当LogMiner完全初始化然后采集变化，它不会占用数据库太多的资源。
12.PWX CDC与Oracle 9i CDC相比的特点是什么
这个产品比Oracle 9i CDC有更好的性能和精确度，然而这个特点要基于LogMiner，它使用Oracle序列来排序、传递变化。Oracle CDC的组队和拆队列是基于PL/SQL的，实现对PL/SQL的依赖而关联Oracle队列的本身就比直接依赖于LogMiner慢，Oracle当前仅能提供实时传播采用触发器的方式，对性能的影响很大。并且，PWX For Oracle 会对异构型环境更好的适合实时传播。非官方的测试表名1百万条记录读PWX需要13分钟而Oracle需要45分钟。
13. LogMiner现在支持Oracle8和9版本，那为什么不支持更早的版本？
PWX Oracle RT需要9.2+，在9之前的版本不能捕获累积的记录，为什么
不能支持Oracle9.0有几个原因。为了支持自己内在的捕获机制，Oracle在9.0主版本推出了增量日志概念，默认开启，这项功能的开销引起了如此多的抱怨以至于在9.2版本对它进行了重构。为了性能更好，增加了完全之前或之后的版本映像的功能和当捕获变化发生时等待日志捕获的功能
15.PWX 需要 Data Guard配合吗
PWX能捕获来自于逻辑DataGuard实例的数据，但是不能来源于物理的DataGuard实例。
16.PWX CDC当前支持哪些版本？
9.2.0.6 with patches 4061535 and 4091906.
9.2.0.7
10.1.0.4 with patches 4061535 and 4091906
10.1.0.5
10.2.0.1
17.我如何查看我的Oracle数据库版本?
SQL> select banner from v$version;
BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production
PL/SQL Release 9.2.0.3.0 - Production
CORE 9.2.0.3.0 Production
TNS for 32-bit Windows: Version 9.2.0.3.0 - Production
NLSRTL Version 9.2.0.3.0 - Production
18.我如何知道我的Oracle数据库运行在归档模式下？
sqlpuls /nolog
conn sys/sys as sysdba
SQL> connect sys as sysdba
Enter password: *****
Connected.
SQL> ARCHIVE LOG LIST
Database log mode Archive Mode
Automatic archival Enabled
Archive destination C:\oracle\oradata\ORCL\archive
Oldest online log sequence 10942
Next log sequence to archive 10944
Current log sequence 10944
35.如果PWX运行在Server1上，访问Oracle CDC在Server2上而且Server2与Server3之间无法访问后又可以访问，这种情况下PWX会不会继续处理？
没有自动的恢复，然而这个过程确实很简单的。当Oracle访问失败，它会发送一些指定的错误代码给连接的用户，PWX会获得这些代码，你所做的就是重连这个用户，假定你可以共享所有，你所做的就是重启这个会话。
36.Infa CDC如何保证事务的顺序性的？例如，如果源数据库在插入操作后面紧跟着更新操作，如何在目标端保证呢，顺序和源一样么？如果顺序换过来可能结果就是错的，有什么方式能保证呢？
在PWX里增量在提交给数据库后几乎实时的被捕获到，保证获得数据的顺序是没有问题的。LogMiner提供给PWX的记录的顺序与他们记录日志的顺序是一样的。
说明：当穿过表间依赖运行是PC的一个问题，在这个问题上PC for RT使用PWX，没有强制跨越多张表的目标表参照完整性，然而，如果目标表是Oracle 这个限制使用表级别的Oracle延迟约束选项可以被解决，随着一种新的无文档的pmserver选项FullCBLOSupport=Y上述说明已经很多余了，但是延迟约束选项仍然可以使用
37.PWX能保证没有任何数据的丢失么？
是的，当PWX for Oracle RT用PWC和PWX结合起来后，数据丢失保证被智能的PWC缓存机制提供，当增量在PWC中处理时，未提交的增量记录被缓存到本地硬盘文件里以防当处理过程中错误发生，这些缓存的记录会立刻被刷新当当前增量提交到目标数据库，重启标志也会相应的被更新。缓存机制保证了数据不会丢失
38.我能在Windows服务器上运行多个Oracle实例么
如果用户使用了9i，LogMiner会话一定不能运行在“shared server”模式，Oracle DBA会确认是否有问题的实例设置到“shared server”上。如果是这种情况用户一定会在tnsnames.ora设置专用服务器允许他访问实例
HI920DTL.INFORMATICA.COM =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = hind)(PORT = 1521))
)
(CONNECT_DATA = (SID = HI920DTL)
(SERVER = DEDICATED)
)
)
如果用户是10g LogMiner不再必须要运行在专用服务器模式上，如果用户运行在专用服务器模式上或者是10g的版本并且收到了ORA-12157信息，Oracle会生成一个trace文件，这种情况下用户应该打开一个Oracle的TAR来调试。
39.如果当前的源是Oracle CDC，我如何添加一个重写的SQL语句在PC mapping里？
这个重写的语句可以在会话的source 连接中添加，不能在mapping中添加。
40.PWX可以支持多个Oracle实例的CDC吗？如果可以的话如何做？
可以，一个PWX安装版支持多个数据库实例，尽管DBMOVER.CFG定义了安装参数的一个单独结果集，这些可以被重载在注册过程和运行时，你需要为每一个数据库实例配置一个ORACLEID参数，如果你希望使用不同标准的抽取增量你可以有不同的CAPI_CONNECTION 参数，所以你的DBMOVER.CFG可能是这样的：
CAPI_SRC_DFLT=(ORA,CAPORA1A)
CAPI_CONN_NAME=CAPIORA1
/* ------------------------------------------------------------
CAPI_CONNECTION=(NAME=CAPORA1A,
TYPE=(UOWC,
RSTRADV=60,
MEMCACHE=64000,
CAPINAME=CAPORA1B))
CAPI_CONNECTION=(NAME=CAPORA1B,
TYPE=(ORCL,
ARRAYSIZE=100,
BYPASSUF=Y,
ORACOLL=INFA2,
CATINT=120,
CATBEGIN=00:00,
CATEND=23:59,
COMMITINT=5,
REPNODE=LOCAL))
CAPI_CONNECTION=(NAME=CAPORA2A,
TYPE=(UOWC,
MEMCACHE=64000,
CAPINAME=CAPORA2B))
CAPI_CONNECTION=(NAME=CAPORA2B,
TYPE=(ORCL,
BYPASSUF=Y,
ORACOLL=INFA2,
CATINT=300,
CATBEGIN=18:00,
CATEND=23:59,
COMMITINT=5,
REPNODE=LOCAL))
/* ------------------------------------------------------------
/* Define 3 instances that will be captured
ORACLEID=(INFA3,INFAVMWR,INFAVMWR,INFAVMWR)
ORACLEID=(ORAPROD,ORAPROD,ORAPROD.WORLD)
ORACLEID=(OPWX,ORCL,ORCL.LOCALDOMAIN)
/* ------------------------------------------------------------
41.Oracle环境的Condense变化可以吗，如果可以的话能描述一下关键点么？
是的，PWX8.1 Condense不支持，一个重要的优就是Condense job仅仅处理执行LogMiner的工作，这样的话一个单独的LogMine会话要比多个好，多个LogMiner会话会开销很大。
随后的CDC抽取会话会从condense文件中读取数据，这比直接从Oracle LogMiner读数据要好。PWC的吞吐量会提高并且PWC会话不会暴露给LogMiner开销。
Condense能够被控制以至于Condense文件可以再足够的间隔内进行数据交换满足需求的执行时间。
Condense可以提高到允许从不终止CAPX会话
Condense允许分离的Condense文件组产生，这允许PWX CAPX进程不必处理捕获会话不需要的数据，用户可以选择分配不同硬盘设备上的文件组来最小化竞争，又可以提高吞吐量
普通Condense优点—未提交的改变被过滤掉，一旦增量被压缩归档日志不必保持监听
• Condense could run on another box, accessing LogMiner over SQL*Net so that impact on box hosting the transactional system is reduced.
42.PWX CDC版本的区别是什么？
Oracle CDC的演变一直在进行，最初的版本是Oracle实时是PWX V521， V850的持续抽取Continuous CAPX
实时
PWC需要来源于PWX的增量
PWX连接Oracle开启LogMiner会话
开始读取日志增量来源于最新的restart token点的目录拷贝
所有的Oracle CDC资源在相同的PWC mapping里会使用相同的LogMiner连接，不同的mapping会使用自己的连接。
CDC数据是从Oracle日志读取的，然后传递到PWC，最后将增量传递给目标表
改变模式
PWX有一个独立的连接Oracle的任务叫DTLCACON，启动了一个LogMiner会话，DTLCACON是持续运行的，增量在传递给PWC之前先被DTLCACON抽取到。
DTLCACON从上次起始点开始读取归档日志
来源于注册表的CDC数据被抽取，DTLCACON将这些增量写到condense文件里，因此condense包含的信息仅仅与这些表有关
在指定的计划中，当前的condense文件关闭一个新的打开
一旦文件关闭了，它包含的数据可以被PWC关闭，这导致了在CDC进程的一个内在的执行时间因为它必须要等待文件交换
最新的condense 文件被读完以后一个End-of-file生成
所有的Oracle CDC源使用从DTLCACON到Oracle的相同的LogMiner连接处理
CDC数据从Oracle日志读取保存到压缩文件里，在每隔一段时间压缩文件交换到然后可用，一旦可用了PWC可以请求增量应用到目标
持续抽取
PWX有一个独立的连接Oracle的任务叫DTLCACON，启动了一个LogMiner会话，DTLCACON是持续运行的，增量在传递给PWC之前先被DTLCACON抽取到。
DTLCACON从上次起始点开始读取归档日志
来源于注册表的CDC数据被抽取，DTLCACON将这些增量写到condense文件里，因此condense包含的信息仅仅与这些表有关
PWX读取压缩文件一旦DTLCACON写入它们（这是与Change Mode的主要区别）
43.如果某个人以前基于PWX Oracle RT已经建立了一个PWC mapping，转化到新的‘condense’选项有哪些步骤？如何转化为持续抽取的步骤呢？
mapping唯一的变化是将来源数据类型CAPXRT交换为CAPX，新版本的PWXPC将CDC初始化为一样的，不论是CAPXRT还是CAPX，当将新的持续抽取连接类型，CAPI_CONNECTION在DBMOVER.CFG中
45.是否增量日志组名称被PWX需要呢？为什么我们需要增量日志组的名称呢？
全局命令仅仅设置索引列的增量日志，我们的处理需求可能设置为全表列进行捕获所以建立增量日志组是很有必要的。
46.为什么我们使用脚本GRANT EXECUTE ON sys.dbms_flashback TO oracapt;
dbms_flashback has several functions; PWX only uses it to obtain the current SCN number.
48.我们已经在dbmover.cfg文件里设置好了参数，想更好的理解目录拷贝和它对我们的环境的影响，有没有好的建议？
为了Oracle LogMiner API能够格式化你想捕获的增量是很必要的，复制Oracle目录到归档日志可以提供PWX抽取，第二个原因是你想多久复制一次。Oracle init.ora参数“log_checkpoint_timeout” and “log_checkpoint_interval”可以帮助管理当racle写内在的检查点到重做日志时，当调节这些参数可以使大量数据写到重做/归档日志是，改变这些参数也可影响数据库实例多久重启一次，请看Oracle Reference Guide对这些参数的讨论，如果你想最小化写入日志的数据量，你可以需要看一下你的重做日志的大小，设置“archive_lag_target”参数，不管你设置不设置log_checkpoint_timeout and log_checkpoint_interval参数，Oracle都会产生一个内置的检查点在交换重做日志时。
Other than affecting how much data is written to the log, these parameters should not enter into your calculation of how often you should copy the Oracle Catalog to the archive log. 计算仅仅考虑在Oracle Catalog写到归档日志多少额外的增量日志生成和在你重启PWX Oracle CDC会话时你希望花多少时间找到日志里最近一次的检查点，换句话说，Oracle的检查点，DDL或者创建归档日志的数目不应该考虑到你的计算中，只有已经生成的日志数据的量和你希望花多长时间等待重启PWX Oracle CDC会话来获得日志的检查点考虑到你的计算里。
复制Oracle 目录到归档日志创建PWX Oracle CDC捕获的日志数据，随着你每天复杂Oracle目录数目的增多，尽管PWX会话会重启的更快，但你增加了PWX Oracle CDC捕获的日志数据量，相反的，随着你每天复杂Oracle目录数目的减少，尽管PWX会话会重启的更慢但你减少了PWX Oracle CDC捕获的日志数据量。
当你启动PWX Oracle CDC会话时，它一般地会开始读取Oracle 归档/重做日志从最近一次成功执行的复制目录下，例如，如果你每隔一个小时复制Oracle目录到归档日志下，PWX Oracle CDC会话通常会只读最近一个小时得日志数据，当然假定你的会话设置是持续运行状态的，这就意味着你每天要复制24次，既然复制Oracle目录到归档日志也会增加日志数据量的话，正确的负载是很重要的。
49.有没有关于如何配置10gRAC环境文件系统的建议？影响我们进程的是什么？
You need to have a shared file system for at least one of the destinations, so that any instance can host Oracle Capture. If a 10g RAC instance fails, this should not affect Oracle Capture unless the failing instance is the one to which Oracle Capture is currently connected to. If this happens, you can restart Oracle Capture on any of the remaining instances of the RAC.
The Archive logs must be on a file system that is shared by all the instances in the RAC. Also note that the archive file names specified in all the instances must be the same.
53.为什么有时重启PWC CDC会话会话很长时间？为什么不从下一次记录点重启？我能减少启动时间么？
是的，重启点在Oracle日志里做当前位置的指针，但是理解在PWC抽取增量前他需要做什么是很重要的。
当oracapt.sql脚本执行的时候Oracle目录的元数据被复制到归档日志，也可以使用CAPI CATINT=nnnn 参数被PWX复制。
当会话重启时，PWX需要由元数据从目录获得归档日志。
PWX读取目录信息然后读取跳转过最近一次成功执行的日志记录
PWX读取日志将增量传递给PWC
One thing that might help here is to ensure that the catalog is copied at logical intervals. But you do not want to do that too frequently because the catalog is copied onto the archive
logs and will have to be read and processed by PowerExchange, causing it to do more work. A fine balance is needed here, that is usually determined by trial an error, since there aren’t any rules to determine the ideal settings.
54.为了更容易的定位PWX的错误，我是不是应该使用Level 2的trace？如果这样的话在哪里配置？不会对性能造成影响吧？
Here’s an example showing how to include the level 2 trace into the dbmover.cfg file:
TRACE=(ACTIVITY,2,99)
CAPT_XTRA=C:\POWEREXCHANGE_CAPTURE\ORACLE\CAMAPS
CAPT_PATH=C:\POWEREXCHANGE_CAPTURE\ORACLE
CAPI_CONN_NAME=CAPIUOWC
CAPI_CONNECTION=(NAME=CAPIUOWC,
TYPE=(UOWC,CAPINAME=CAPIORA,
MEMCACHE=64000,RSTRADV=300))
CAPI_CONNECTION=(NAME=CAPIORA,
DLLTRACE=ACTIVITY,
TYPE=(ORCL,BYPASSUF=Y,REPNODE=LOCAL,
ORACOLL=ORACAPT,
CATBEGIN=00:00,CATEND=23:00,
CATINT=60,COMMITINT=5))
性能影响可以忽略不计，然而会产生一个verbose log，文档见PWX 8.1.1 Oracle Adapter guide.
PowerExchange for Oracle 提供了一种捕获Oracle数据表改变的方法，它使用Oracle Logminer，CDC解决方法分为“real-time” and “change”
real-time是什么？
一个进程可以几乎实时的访问对Oracle数据库的改变，对Oracle数据库的连接是持续的，一旦对注册的Oracle数据库表做出一些改变后，Logminer可以将这些改变传递给PowerExchange来处理。UOW逻辑嵌入到PowerExchang中。PowerExchange 会立刻将这些改变传递给 PowerCenter
real-time的定位。
频繁且实时的刷新数据、大数据量的数据伴随着小规模或中等规模数据的改变、有些的ETL资源
real-time如何工作？
使用Oracle Logminer来访问Oracle重做日志。需要积极的重做日志或者归档日志。
为优化性能设计。不依赖与Oracle 流技术(PL/SQL和Queues)，不使用触发器
PowerExchange for Oracle Real-Time 的架构
Oracle重做日志包含事务信息，可以在提交以前运行是否回滚。
Logminer捕获来自于重做日志的变化。
PowerExchange Navigator用来注册源表创建一个data extraction map。
CAPI决定那些记录应该从源表注册返回
UOW清洗器保证事务按照提交顺序处理的，回滚的事务被忽略。
PWXPC提供了PowerExchange/PowerCenter的连接。
在PowerCenter中一个持续的工作流将改变应用到目标表中。
有一点很重要，Logminer是Oracle的一部分，不是PWX的一部分，Logminer一定要如下配置：
- LogMiner一定要配置
- 数据库实例要运行在ARCHIVELOG（归档）模式下
- 数据库目录要复制到重做日志下
Condense是什么？
一项根据特定压缩条件定期压缩变化数据的任务。依赖于捕获的注册，被收集的改变被压缩到需求依赖的UOW信息，一旦压缩进程压缩了收集的改变。