探讨一个SAP Dynpro编程的问题: Dynpro切换时，貌似会做隐式数据库Commit，原因何在?
本帖最后由 雪候鸟 于 2012-9-12 23:03 编辑虽然可以通过其他方法延迟提交增删改的数据，但是为什么不从根本上取消这个隐含的DB Commit? 问了些单位搞了多年ABAP开发的同事居然说没听说过, 难道是我理解错了?{:5_339:} 不懂SAP的帮顶 这是SAP的Standardverhältnis，一个Datenbank-LUW结束的时候自动执行隐式DB Commit，这标志着一个Workprozess的结束。不需要也不要试图取消。 adgjl 发表于 2012-9-12 23:21 static/image/common/back.gif
这是SAP的Standardverhältnis，一个Datenbank-LUW结束的时候自动执行隐式DB Commit，这标志着一个Work ...
大部分情况下一套Dynpro序列是完成的一件事情, 如果在每个Dynpro之间切换就发出一个DB Commit, 很容易破坏整个事务的完整性. Workprocess这个概念我也读到过,感觉是个很重量级的资源, 所以需要赶快释放掉. 但是SAP在设计的时候为什么不把这个workprocess搞成轻量级, 其实频繁的DB Commit在一些数据库上容易引发很多性能问题. 借贴问一下，SAP中HANA In-Memory Datenbank是什么东东？求给扫盲一下呗 本帖最后由 adgjl 于 2012-9-12 22:51 编辑
你可能有误解，以为在Dynpro 100上的每个改动都立刻update到DB，然后切换Dynpro到200的时候通过隐式Commit就已经被写入DB了。其实改动不是被立刻执行update的，只是在内存中保存更改的字段，这时候你切换Dynpro根本没有任何DB数据被修改，你可以随意切换Dynpro直到点保存为止，这时候数据改动同步或者异步写入DB。
没有数据更改的情况下，隐式Commit根本不触发DBMS，所以不会引起数据库性能问题。 sbtree 发表于 2012-9-12 22:44 static/image/common/back.gif
借贴问一下，SAP中HANA In-Memory Datenbank是什么东东？求给扫盲一下呗
是个软硬件结合的数据库性能优化技术。说白了就是，硬件上保证把潜在要读的数据提前读到Memory里。对于程序员来说，他的程序基本不变（其实也要针对HANA做一定的改动），本应该从DB读取的数据由SAP从Memory里读出。由于Memory读取速度比DB高N个数量级，所以数据访问会大大加快。 adgjl 发表于 2012-9-12 23:45 static/image/common/back.gif
你可能有误解，以为在Dynpro 100上的每个改动都立刻update到DB，然后切换Dynpro的时候通过隐式Commit就被写 ...
Sollen Datenbankänderungen direkt aus dem Dialogprogramm heraus
(Inline-Änderungen) durchgeführt werden, müssen Sie alle zusammengehörigen
Änderungen auf einen Dialogschritt (i. A. der letzte Dialogschritt) beschränken.
Nur dann ist die Durchführung der Datenbankänderungen als Ganzes (mit dem
Alles-oder-Nichts-Prinzip) gewährleistet.
我当时的理解就是在Bildwechsel的时候会自动提交, 当时还作了一个两个Dynpro切换的实验,发现修改进数据库了. 可能测试的有错误,我回来再看看 adgjl 发表于 2012-9-12 23:45 static/image/common/back.gif
你可能有误解，以为在Dynpro 100上的每个改动都立刻update到DB，然后切换Dynpro到200的时候通过隐式Commit就 ...
如果不是在内存中的修改呢,
如果我在第一个dynpro中执行一个update语句,然后切换到下一个dynpro. 这时候这个update修改的应该会被提交吧 本帖最后由 adgjl 于 2012-9-12 23:02 编辑
你如果Bildwechsel之前执行了Insert，Update之类的当然会被提交。关键在于，你不应该把每个更改都直接提交修改。而应该把所有的改动都在内存中的全局字段中保存，在用户点保存的时候再提交。重要的是你理解SAP的工作方式之后遵循同样的流程编程。 adgjl 发表于 2012-9-12 23:50 static/image/common/back.gif
是个软硬件结合的数据库性能优化技术。说白了就是，硬件上保证把潜在要读的数据提前读到Memory里。对于程 ...
我觉得可能为了给BW加速, 如果真是OLTP的话应该用出不大, 不然在内存数据库和物理数据库之间同步的开销更大. 本帖最后由 雪候鸟 于 2012-9-13 00:14 编辑
adgjl 发表于 2012-9-12 23:59 static/image/common/back.gif
你如果Bildwechsel之前执行了Insert，Update之类的当然会被提交。关键在于，你不应该把每个更改都直接提交修 ...
这个就是我开始提到的问题,我知道有其他的办法可以延迟提交,例如在内存做修改或者使用verbuchung. 但是如果SAP取消了这个bildwechsel之间的db commit, 就不需要把insert和update本应该对数据库的修改, 先保存到内存中这么麻烦了. 另外如果作者1开发dynpro100作者2开发dynpro200, 那么作者2一定要看作者1的代码是如何修改数据的,是内存修改还是对物理数据库的DML, 不利于模块化开发. 一个项目组的还好说, 如果是彼此独立的项目组很麻烦阿 adgjl 发表于 2012-9-12 23:59 static/image/common/back.gif
你如果Bildwechsel之前执行了Insert，Update之类的当然会被提交。关键在于，你不应该把每个更改都直接提交修 ...
另外这种先写入内存的做法会造成修改丢失, 不能重复读的情况. 例如用户1调用Dynpro100, 如果使用数据库update 修改表A的记录1, 那么这个update会阻止其他的用户2在调用Dynpro100时候同样对表A的记录1修改,因为记录1上有锁. 如果先修改内存的办法用户1就不能阻止用户2对同样记录的操作 火星人都是 O的故事 发表于 2012-9-13 00:41 static/image/common/back.gif
火星人都是
我们探讨的只是很基础的问题, 还不需要用到火星人的智慧{:5_332:} sbtree 发表于 2012-9-12 23:44 static/image/common/back.gif
借贴问一下，SAP中HANA In-Memory Datenbank是什么东东？求给扫盲一下呗
你研究内存数据库马 本帖最后由 adgjl 于 2012-9-13 08:41 编辑
SAP的这种策略决策不是可有可无或者画蛇添足，否则SAP费那个劲添加一个步骤（不做不是更省事）做什么？你的想法在开发的时候（对开发员）更快捷方便。但是其他人维护起来就太麻烦了。
1，如果数据库变更不是在某处Zentral进行的话，你必须把整个程序从头到尾通读，找到每一个Insert，Update，再分析有没有重复的，多余的，Overwrite的。这就像以前的Go to语句一样。
2，Debug的时候，内存变量可以直接看到变更过程，但是Update的数据实际上是被保存到特定无法访问的区域等待Commit的，你怎么排错？
3，用户输入的数据是可能在保存之前被某个Enhancement修改之后再保存的，你已经登记录入DB了，这个Enhancement怎么办？
4，如果所有变更都已经登记录入，一旦程序通过某个客户自己的Enhancement决定某个数据错误不应该被保存，必须执行Rollback Work，可是这样一来所有的其它变更都被取消了。如果是变更保存在内存变量里，只要简单修改这个变量就可以了。
原因还有很多，不一一细说。
至于你说的锁机制当然SAP不可能想不到。
1，不同用户的Workprozess是隔离的，不能互相访问，也就是说，别人无法覆盖你的内存变量。
2，你说的是物理锁，锁住单个DB表格的某条记录。SAP用的是逻辑锁（Sperrobjekt），比如你在进入修改事务码修改订单，那么所有相关表格被逻辑锁全部锁住，其他用户根本就无法进入修改状态，SAP会显示给该用户订单正在被某其他用户处理无法修改，就谈不上修改变量了。
你先别急着抱怨，因为你只从一个局部而不是从SAP这样一个复杂庞大的系统全局考量的，而SAP的流程是经过很多比我们更优秀的人的设计和全球用户的实践检验的。举个简单例子，实现特定需求最简单直接的方式是通过Modifikation直接修改SAP源代码，那SAP还费那么大劲搞BaDI，Enhancement干啥？相比之下，维护方便显然要比开发方便优先级要高，不是么？我甚至建议你尽量不要怀疑SAP流程（当然SAP的代码也会有错，我不是让你放弃质疑精神，应该去质疑的是Coding而不是流程），而要试着去理解和适应。即使有我们不理解的，肯定SAP有自己的原因，只是我们暂时不知道而已。 雪候鸟 发表于 2012-9-12 23:02 static/image/common/back.gif
我觉得可能为了给BW加速, 如果真是OLTP的话应该用出不大, 不然在内存数据库和物理数据库之间同步的开销更 ...
使用HANA的用户应该预见到HANA的开销很大，使用它的目的也不是为了节省开销。你低估了ERP表格的数据量了，当你从几十个Million数据的表格中试图通过未索引字段作为条件顺序遍历访问数据的时候就知道HANA的作用了。也许你要问为什么不索引该字段，SAP表格也许有几百个字段，处于资源考量，SAP建议不要超过5个Index，否则会造成效率下降，因为每个变更都要修改全部索引表格。 本帖最后由 雪候鸟 于 2012-9-13 10:51 编辑
adgjl 发表于 2012-9-13 09:47 static/image/common/back.gif
使用HANA的用户应该预见到HANA的开销很大，使用它的目的也不是为了节省开销。你低估了ERP表格的数据量了， ...
具体到数据库,如果只是修改一个被索引的字段并不会造成其他索引也被更新。只有插入或者删除才会造成表上这5个索引都更新。sap这么建议5个索引应该是给出的grobe schätzung。在一个频繁修改更新的表上创建索引确实效率会大打折扣，但是如果在这种表上使用hana, 估计效率也不会好到哪里，虽然select快了，但是物理表和内存表的对dml操作的同步的开销会更大。所以我觉得加速BW是可以的，给OLTP用不合适。 本帖最后由 雪候鸟 于 2012-9-13 10:58 编辑
adgjl 发表于 2012-9-13 09:31 static/image/common/back.gif
SAP的这种策略决策不是可有可无或者画蛇添足，否则SAP费那个劲添加一个步骤（不做不是更省事）做什么？你的 ...
谢谢兄弟写了这么多，你说的都在理。我觉得这个隐含的DB Commit可能有些历史原因。以前大多数数据库写会阻赛读操作，而且锁是表锁或者页锁，这种锁的代价很高，所以那个时候提倡频繁的commit, 先在内存里做修改，或者使用sperrobjekt, 都是为了减少表锁和页锁的开销. 现在大部分数据库写不在阻塞读了，例如oracle其实很早就是, DB2从9开始这样了，锁轻量级了，反而提倡不要频繁commit. 数据库对一个erp产品来说是很重要的一块，我一直觉得sap没有知名的数据库是个很大的缺憾，很多地方要受制于人 你说的对，这当然是Grobe Einschätzung。HANA作为BW-Accelerator的后续产品（最初的）主要目的是为了加速BW而设计。但是HANA是一个很复杂的系统，并不只是预读数据到内存而已，它有自己的relational engine和通过Row Store和Column Store可以进行数据的压缩，Delta write等完整的机制。通过效率和功能的平衡（同步和加速的平衡），HANA也是Offiziell用于ERP的。你的这种担心肯定不仅仅是你自己有，而是希望引入HANA的所有IT Leiter都有的，SAP当然也是通过无数次的试验用可以证明的数据证明了整体数据访问速度（而不是某个单独的表格）可以有数量级的提高才推向市场的。 adgjl 发表于 2012-9-13 10:58 static/image/common/back.gif
你说的对，这当然是Grobe Einschätzung。HANA作为BW-Accelerator的后续产品（最初的）主要目的是为了加 ...
要是真能这样当然很好，那hana的意义不是战术级别的了，而是战略。看来sap想通过hana屏蔽物理数据库，来避免自己这方面的短板 本帖最后由 adgjl 于 2012-9-13 12:05 编辑
雪候鸟 发表于 2012-9-13 09:41 static/image/common/back.gif
谢谢兄弟写了这么多，你说的都在理。我觉得这个隐含的DB Commit可能有些历史原因。以前大多数数据库写会阻赛读操作，而且锁是表锁或者页锁，这种锁的代价很高，所以那个时候提倡频繁的commit, 先在内存里做修改，或者使用sperrobjekt, 都是为了减少表锁和页锁的开销. 现在大部分数据库写不在阻塞读了，例如oracle其实很早就是, DB2从9开始这样了，锁轻量级了，反而提倡不要频繁commit. 数据库对一个erp产品来说是很重要的一块，我一直觉得sap没有知名的数据库是个很大的缺憾，很多地方要受制于人
成熟的数据库技术不是一镞而就的，我相信SAP肯定有团队在搞自己的数据库，只是还未成熟而已，事实上HANA就是这种尝试的一大步前进。
企业都想完全独立，不受制于人，可是强大如苹果，不也得依赖于硬件生产商，甚至竞争对手三星生产屏幕和CPU么？我们不用替SAP担心，人家也不傻，不会看不到这种依赖性和它的后果，慢慢SAP会尽量摆脱这种依赖的，就像苹果摆脱三星一样。 adgjl 发表于 2012-9-12 23:50 static/image/common/back.gif
是个软硬件结合的数据库性能优化技术。说白了就是，硬件上保证把潜在要读的数据提前读到Memory里。对于程 ...
多谢adgjl的讲解，想问个问题是，如何知道哪些数据是潜在要读取的？还有数据库系统就我的理解来说还仅仅限于应用层上，如何做到物理层上去了？是我落后了？实在不太了解新技术了 adgjl 发表于 2012-9-13 11:10 static/image/common/back.gif
成熟的数据库技术不是一镞而就的，我相信SAP肯定有团队在搞自己的数据库，只是还未成熟而已，事实上HAN ...
数据库这东西，基本就是绑定，一旦上了贼船就很难下来在。对了问个问题，以前听说可口可乐是迁移到db2上了，现在跑在db2的sap多不多 看来当初我不碰dynpro开发是正确的，根本看不懂在说什么{:5_387:} kleinlin 发表于 2012-9-13 11:35 static/image/common/back.gif
看来当初我不碰dynpro开发是正确的，根本看不懂在说什么
dynpro ist nicht ganz schlecht. 雪候鸟 发表于 2012-9-13 10:41 static/image/common/back.gif
谢谢兄弟写了这么多，你说的都在理。我觉得这个隐含的DB Commit可能有些历史原因。以前大多数数据库写会 ...
SAP 跟Oracle 的关系很复杂，一方面给人家赔很多钱，一方面是最大的竞争对手之一，另一方面又是最大的合作伙伴之一。
两年前买了Sybase，当时还有很多人以为他们是要提高自身核心竞争力跟Oracle 数据库竞争，但是其实更多是为了Mobile 和HANA
现在HANA 技术还没有竞争对手 HANA有哪些技术亮点？与数据库系统本身的性能方面的技术相比有什么优势？继续接受扫盲 雪候鸟 发表于 2012-9-13 11:41 static/image/common/back.gif
dynpro ist nicht ganz schlecht.
ABAP只是我的hobby{:5_363:}