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没有知名的数据库是个很大的缺憾，很多地方要受制于人