点击此处--->
群内免费提供SAP练习系统（在群公告中）
加入QQ群：457200227（SAP S4 HANA技术交流） 群内免费提供SAP练习系统（在群公告中）
您好，专家，我们想使用此SDI Oracle Log Reader功能对BW4/HANA中源Oracle数据库的某些表执行实时数据加载，而又不对该源数据库添加任何额外负载 ，并且我们正在就此进行概念验证。
事实上，我们已经在HANA端安装了Data Provisioning Server和Data Provisioning Agent（在我们的示例中， 源Oracle数据库位于中间，而不是分开放置），设置Oracle Log Reader。
我们已经完成了设置，并且看起来工作正常，因此，只要我们更新该源Oracle中的记录， 数据库中，我们看到了Hana Virtual表级别的更改，如果创建了提取请求，我们将看到提取检索到一条数据记录。
但是，我们的疑问是该Oracle Log Reader在技术上到底有多准确 作品; 它如何从重做日志中读取信息，将其保存到启动BW提取之前，因为我们无法确定在Oracle级别创建的LogReader用户实际上不是在读取自己的数据库，也不是在读取重做日志（因为 必须授予我们要捕获的表的"选择"权限），并且我们在任何地方都找不到此过程的确切工作方式。
我个人的观点是Oracle Log Reader实际上正在检查 Oracle数据库的联机重做日志，并且当它检测到影响我们在BW4/HANA中选择的表的更改时，会将更改信息保存到其他位置，可能在我们看到代理在/下创建的文件结构中 usr/sap/dataprovagent/ds-lite/sqla/tmp/dslite_repo_
有人可以确认如何操作吗？ 的工作？
然后，我们又产生了另一个疑问：HANA虚拟表的初始满负荷是如何发生的？ 因为可以肯定的是，我们选择的表的所有现有更改记录都不属于重做日志的一部分（当我们有一个脚本来压缩脱机重做日志文件时，每小时将其移动到另一个位置就更是如此）。
也许是通过在Oracle级别的实际表上使用直接的"选择"语句来完成初始加载的？ 还是完全正确？
非常感谢您，最好的问候！
Jose Sanz
{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','http://www.easysap.com/data/attach/logo/logo.png', '推荐 淡笑 的问题《智能数据集成-Oracle Log Reader适配器-确切的技术工作方法？》','https://www.easysap.com/q-32379.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
您好，何塞，我认为我无法达到所需的全部详细信息，但可能是日志读取器适配器的中高级解释。 我是从所谓的"本地" SDI的角度来编写本文的，这意味着我对直接在HANA（而不是BW4/HANA）中配置复制有经验。 因此某些特定的BW4/HANA功能或工作流程可能会让我逃脱。
至少对于初始加载，肯定需要select特权。 但是实时不仅会不断查询表，这对于更改数据捕获来说不是可行的选择。 一些客户一次复制了数百个表，这些查询的成本非常高。
适配器改为使用不同的方法（用于Oracle的LogMiner，用于MSSQL的sybfilter和用于DB2的本机日志读取器）来 查询重做日志，丢弃未跟踪的表信息，并将"已标记"更改传递给代理以返回HANA。 通过将表添加到源边表来进行标记，这些表通常是由安装脚本在初始化过程中创建的。 在撰写本文时，我引用的是MSSQL实现，其中一个表是ra_marked_object，其中包含我所有已预订表的object_id。 我认为在Oracle上这将是ORACLEMARKEDOBJECT表。 我们使用LogMiner来检查每个LSN的每个SCN，并对照已标记对象表中的对象ID进行引用。
要进行更多的跟踪，以证明SDI实际上是日志读取，可以在中启用该进程的跟踪。 ../dataprovagent/configuration/com.sap.hana.dp.adapterframework/OracleLogReaderAdapter/OracleLogReaderAdapter.ini。 添加以下行，保存，然后重新启动dpagent。 然后，在实时复制期间，跟踪消息将出现在远程源实例日志中，.../dataprovagent/log//
使用预订使用的相同SQL或虚拟表定义（如果要复制整个Oracle表），通过JDBC非常简单地完成初始加载。 HANA使用从任务设计中生成的SQL，将其发送到代理，然后代理使用远程源的适配器将其应用于远程源。 如果任务具有分区，则对每个分区执行一次此选择。 如果您想自己证明这一点，请将dpagent日志级别设置为ALL并运行初始加载。 您应该在framework.trc中看到一行包含" STREAMING_SET_STATEMENT"或" FEDERATION_SET_STATEMENT"的行，这将告诉您用于初始加载的SQL，它将是可以在Oracle中执行的有效SQL语句。
关于从Oracle返回数据之后数据存储的位置，它将存储在dpagent内存中，而不是在代理端的任何文件中。 代理程序的ds-lite和sqla组件用于文件数据存储适配器，它们与Oracle复制无关。 相反，通过在framework.trc中观察内存池/队列的增长和收缩，您可以看到数据在dpagent中移动。 您将看到这样的一行：
池设置描述了所有响应队列可以使用的共享内存量，最多 在我的情况下为682 MB。 队列设置描述了这种特定的复制，因此我的单个测试表当前在dpagent端的内存为10.46kb，正等待发送到HANA。 根据要复制的表的数量，将创建多个甚至多个队列。 在这里，我们有接收器响应队列" RCRQ 10712"，其中的数字是标识信息，您应该能够通过framework.trc文件跟踪此数字，直到初始加载或CDC的第一部分开始 行在特定时间范围内移动。
希望这可以清除您的一些问题。
最诚挚的问候，
Jeff
PS：如果要避免给Oracle计算机造成压力，建议将dpagent放在单独的硬件上。 dpagent的内存占用非常小，尤其是在高容量复制的情况下。
要在Jeff的广泛回答上有所扩展...
您需要选择特权 在Oracle表上主要用于初始负载，这只是一个select-from-table这样的语句。
更改实际上是使用Oracle的日志读取器api从Oracle事务日志中读取的。 日志读取器api的请求为"我想从系统更改号xyz开始获取所有更改"，并使用日志信息数据字典表来知道该交易将在何处找到。 它可以在联机重做日志中，也可以在存档日志中（如果较旧）。 您可以通过从Oracle数据库的访问范围中删除归档日志并要求更旧的系统更改来轻松证明这一点。 该请求将失败，并显示"无法访问包含更改数据的存档日志文件<..>"。
另一个证明是，增量仅从事务日志中读取，这是在安装过程中针对Oracle数据库执行的语句。 启用了一些补充日志记录以向重做日志添加更多信息。 例如，当删除一条记录时，至少应将其主键数据保存在重做日志中。
我上面所说的并不是100％正确，但足够精确。 日志读取器必须在表上选择privs才能检查当前具有哪些列。 想象一下添加了一个列。 较旧的重做日志条目将不知道该列。 日志挖掘者必须调和这两个信息，例如 为您提供宽表，但在这种情况下，此列返回null。
一周热门 更多>