you Asked :
Hi, 老商 ， 我的IE原来访问EBS Form一直是正常的，但从IE10自动升级到IE11后，就无法正常打开EBS R12.1.3 的Form了，提示我未安装JRE，要安装java 1.6.0_07 ;但 我机器上的JRE 已经是1.6.0_25了，比它要求的还新，理论上应该是满足要求的。
而且我把1.6.0_25卸载后，按它的要求重新安装1.6.0_07 后还是没有解决问题，请问我该怎么办呢？
We Said：
请检查IE11的兼容性视图设置，把你当前的站点加到兼容性视图站点可解决此问题。
热点块的定义
数据库的热点块，从简单了讲，就是极短的时间内对少量数据块进行了过于频繁的访问。定义看起来总是很简单的，但实际在数据库中，我们要去观察或者确定热点 块的问题，却不是那么简单了。要深刻地理解数据库是怎么通过一些数据特征来表示热点块的，我们需要了解一些数据库在这方面处理机制的特性。
数据缓冲区的结构
我们都知道，当查询开始的时候，进程首先去数据缓冲区中查找是否存在查询所需要的数据块，如果没有，就去磁盘上把数据块读到内存中来。在这个过程中，涉及 到数据缓冲区中LRU链的管理（8i开始以接触点计数为标准衡量buffer冷热从而决定buffer是在LRU的冷端还是热端），关于这部分内容，从 oracle concepts 中就能得到详尽的文档，我不准备去论述这部分内容，这也不是本文的重点。现在我们的重点是，到底进程是如何地去快速定位到自己所想要的block的，或者 如何快速确定想要的block不在内存中而去进行物理读的。
我们仔细想一想，随着硬件的发展，内存越来越大，cache buffer也越来越大，我们如何才能在大量的内存中迅速定位到自己想要的block？总不能去所有buffer中遍历吧！在此数据库引出了hash的概 念（oracle中快速定位信息总是通过hash算法的，比如快速定位sql是否在shared pool size中存在就是通过hash value来定位的，也就是说shared pool size中对象也是通过hash table来管理的），了解一点数据结构的基本知识就知道，hash 的一大重要功能就是快速地查找。举个最简单的例子，假设我们有一个hash table 就是一个二维数组a[200][100],现在有1000个无序数字，我们要从这1000个数字里面查找某个值是否存在，或者说当我们接收到某个数字的时 候必须判断是否已经存在，当然，我们可以遍历这1000个数字，但这样的效率就很低。但现在我们考虑这样一种方法，那就是把1000个数字除以200，根 据其余数，放在a[200][100]里面(假设相同余数的最大数量不超过100)，余数就是数组的下标。这样，平均来说一个数组a[i]里面可能有5个 左右的数字。当我们要去判别一个数字是否存在的时候，对这个数字除以200(这就是一个最简单的hash算法)，根据余数i作为下标去数组a[i]中查 找，大约进行5次查找就能判别是否已经存在，这样通过开辟内存空间a[200][100]来换取了时间(当然hash 算法的选取和hash table的大小是一个很关键的问题)。
明白了基本的hash原理之后，我们再来看oracle的block的管理。数据库为这些block也开辟了hash table，假设是a,则在一维上的数量是由参数_db_block_hash_buckets 来决定的，也就是存在hash table a[_db_block_hash_buckets ],从oracle8i开始，_db_block_hash_buckets =db_block_buffers*2。而一个block被放到哪个buckets里面，则是由block的文件编号、块号(x$bh.dbarfl、 x$bh.dbablk对应了block的文件属于表空间中的相关编号和block在文件中的编号，x$bh是所有cache buffer的header信息，通过表格的形式可以查询)做hash 算法决定放到哪个bucket的，而bucket里面就存放了这些buffers的地址。这样当我们要访问数据的时候，可以获得segment的 extent(可以通过dba_extents查到看，详细的信息来源这里不做探讨)，自然知道要访问的文件编号和block编号，根据文件和block 编号可以通过hash算法计算出hash bucket,然后就可以去hash bucket里面去找block对应的buffer。
除此之外，为了维护对这些block的访问和更改，oracle还提供了一种latch来保护这些block。因为要避免不同的进程随意地径直并发修改和 访问这些block，这样很可能会破坏block的结构的。latch是数据库内部提供的一种维护内部结构的一种低级锁，latch的生存周期极短(微秒 以下级别)，进程加latch后快速的进行某个访问或者修改动作然后释放latch(关于latch不再过多的阐述，那可能又是需要另一篇文章才能阐述清 楚)。这种latch数量是通过参数_db_block_hash_latches 来定义的，一个latch对应的保护了多个buckets。从8i开始，这个参数的default规则为:
当cache buffers 少于2052 buffers
_db_block_hash_latches = power(2,trunc(log(2, db_block_buffers – 4) – 1))
当cache buffers多于131075 buffers
_db_block_hash_latches = power(2,trunc(log(2, db_block_buffers – 4) – 6))
当cache buffers位于2052与131075 buffers之间
_db_block_hash_latches = 1024
通过这个规则我们可以看出，一个latch大约可以维护128个左右的buffers。由于latch使得对block的操作的串行化(9i中有改进，读 与读可以并行，但读与写、写与写依然要串行)，很显然我们可以想到一个道理，如果大量进程对相同的block进程进行操作，必然在这些latch上造成竞 争，也就是说必然形成latch的等待。这在宏观上就表现为系统级的等待。明白了这些原理，为我们下面的在数据库中的诊断奠定了基础。
如何确定热点对象
如果我们经常关注statspack报告，会发现有时候出现cache buffer chains的等待。这个cache buffer chains就是_db_block_hash_latches所定义的latch的总称，通过查询v$latch也可得到：
select”>sys@OCN>select latch#,name,gets,misses,sleeps from v$latch where name like ‘cache buffer%’;
LATCH# NAME GETS MISSES SLEEPS
———- —————————— ———- ———- ———-
93 cache buffers lru chain 54360446 21025 238
98 cache buffers chains 6760354603 1680007 27085
99 cache buffer handles 554532 6 0
在这个查询结果里我们可以看到记录了数据库启动以来的所有cahce buffer chains的latch的状况，gets表示总共有这么多次请求，misses表示请求失败的次数(加锁不成功)，而sleeps 表示请求失败休眠的次数，通过sleeps我们可以大体知道数据库中latch的竞争是否严重，这也间接的表征了热点块的问题是否严重。由于 v$latch是一个聚合信息，我们并不能获得哪些块可能存在频繁访问。那我们要来看另一个view信息，那就是 v$latch_children,v$latch_children.addr记录的就是这个latch的地址。
select”>sys@OCN>select addr,LATCH#,CHILD#,gets,misses,sleeps from v$latch_children
2 where name = ‘cache buffers chains’ and rownum < 21;
ADDR LATCH# CHILD# GETS MISSES SLEEPS
——– ———- ———- ———- ———- ———-
91B23B74 98 1024 10365583 3957 33
91B23374 98 1023 5458174 964 25
91B22B74 98 1022 4855668 868 15
91B22374 98 1021 5767706 923 22
91B21B74 98 1020 5607116 934 31
91B21374 98 1019 9389325 1111 25
91B20B74 98 1018 5060207 994 31
91B20374 98 1017 18204581 1145 18
91B1FB74 98 1016 7157081 920 23
91B1F374 98 1015 4660774 922 22
91B1EB74 98 1014 6954644 976 32
91B1E374 98 1013 4881891 970 19
91B1DB74 98 1012 5371135 971 28
91B1D374 98 1011 5154497 990 26
91B1CB74 98 1010 5013796 936 18
91B1C374 98 1009 5667446 939 25
91B1BB74 98 1008 4673421 883 14
91B1B374 98 1007 4589646 986 17
91B1AB74 98 1006 10380781 1020 20
91B1A374 98 1005 5142009 1110 19
20 rows selected.
到此我们可以根据v$latch_child.addr关联到对应的x$bh.hladdr(这是buffer header中记录的当前buffer所处的latch地址)，通过x$bh可以获得块的文件编号和block编号。
select”>sys@OCN>select dbarfil,dbablk
from x$bh
where hladdr in
(select addr
from (select addr
from v$latch_children
order by sleeps desc)
where rownum < 11);
DBARFIL DBABLK
———- ———-
4 6498
40 14915
15 65564
28 34909
40 17987
1 24554
8 21404
39 29669
28 46173
28 48221
……………………
由此我们就打通了cache buffers chains和具体block之间的关系，那再继续下来，知道了block，我们需要知道究竟是哪些segment。这个可以通过dba_extents来获得。
select distinct a.owner,a.segment_name from
dba_extents a,
(select dbarfil,dbablk
from x$bh
where hladdr in
(select addr
from (select addr
from v$latch_children
order by sleeps desc)
where rownum < 11)) b
where a.RELATIVE_FNO = b.dbarfil
and a.BLOCK_ID <= b.dbablk and a.block_id + a.blocks > b.dbablk;
OWNER SEGMENT_NAME SEGMENT_TYPE
—————————— —————————— ——————
ALIBABA BIZ_SEARCHER TABLE
ALIBABA CMNTY_USER_MESSAGE TABLE
ALIBABA CMNTY_VISITOR_INFO_PK INDEX
ALIBABA COMPANY_AMID_IND INDEX
ALIBABA COMPANY_DRAFT TABLE
ALIBABA FEEDBACK_POST TABLE
ALIBABA IM_BLACKLIST_PK INDEX
ALIBABA IM_GROUP TABLE
ALIBABA IM_GROUP_LID_IND INDEX
ALIBABA MEMBER TABLE
ALIBABA MEMBER_PK INDEX
ALIBABA MLOG$_SAMPLE TABLE
……………………
我们还有另外一种方式
select object_name
from dba_objects
where data_object_id in
(select obj
from x$bh
where hladdr in
(select addr
from (select addr
from v$latch_children
order by sleeps desc)
where rownum < 11)) ;
OBJECT_NAME
————————————
I_CCOL2
RESOURCE_PLAN$
DUAL
FGA_LOG$
AV_TRANSACTION
COMPANY_DRAFT
MEMBER
SAMPLE
SAMPLE_GROUP
VERTICAL_COMPONENT
MEMBER_PK
SAMPLE_GROUP_PK
IM_BLACKLIST_PK
IM_CONTACT
IM_GROUP
CMNTY_USER_MESSAGE
CMNTY_VISITOR_INFO_PK
IM_OFFLINEMSG_TID_IND
OFFER
OFFER_PK
OFFER_EMAIL_IND
OFFER_DRAFT
CMNTY_USER_MESSAGE_TD_BSM_IND
CMNTY_MESSAGE_NUM_PK
BIZ_EXPRESS_MEMBER_ID_IND
……………………
到这里我们基本能找到热点块对对应的对象。但实际上还有另外一个途径来获取这些信息，那就是和x$bh.tch 相关的一种方法。对于8i开始oracle提供了接触点(touch count)来作为block是冷热的标志，在一定条件满足的情况下block被进程访问一次touch count 增加一，到某个标准之后被移动到LRU热端(关于touch count 在这里不做详细介绍，那又将是一大篇文章)。那在短时间内从某种意义上讲，touch count 大的block可能暗示着在当前某个周期内被访问次数比较多。
select distinct a.owner,a.segment_name,a.segment_type from
dba_extents a,
(select dbarfil,dbablk
from (select dbarfil,dbablk
from x$bh order by tch desc) where rownum < 11) b
where a.RELATIVE_FNO = b.dbarfil
and a.BLOCK_ID <= b.dbablk and a.block_id + a.blocks > b.dbablk;
OWNER SEGMENT_NAME SEGMENT_TYPE
—————————— —————————— ——————
ALIBABA CMNTY_USER_MESSAGE TABLE
ALIBABA MEMBER_PK INDEX
ALIBABA OFFER_DRAFT_GMDFY_IND INDEX
同上面一样还有这个方法
select object_name
from dba_objects
where data_object_id in
(select obj
from (select obj
from x$bh order by tch desc) where rownum < 11) ;
OBJECT_NAME
—————————————————
DUAL
MEMBER_PK
SAMPLE_GROUP_PK
CMNTY_USER_MESSAGE_TD_BSM_IND
OFFER_DRAFT_MID_GMDFY_IND
OFFER_MID_GPOST_IND
OFFER_DRAFT_PK
MEMBER_GLLOGIN_IND
OFFER_MID_STAT_GEXPIRE_IND
SAMPLE_MID_STAT_IND
10 rows selected.
到这里，我们寻找热点块和热点对象的工作算是完成了，但我们还并没有解决问题。
热点问题的解决
热点块和热点对象我们都找到了，但是我们该怎么来解决这个问题呢？一般来说，热点块会导致cache buffers chains竞争等待，但并不是说cache buffer chains一定是因为热点块而起，在特别情况下有可能是因为latch数量的问题导致的，也就是一个latch管理的buffers数量太多而导致竞争 激烈。但是latch数量我们一般是不会轻易去设置的，这是oracle的隐藏参数。
实际上最有效的办法，是从优化sql入手，不良的sql往往带来大量的不必要的访问，这是造成热点块的根源。比如本该通过全表扫描的查询却走了索引的 range scan，这样将带来大量的对块的重复访问。从而形成热点问题。再或者比如不当地走了nested loops的表连接，也可能对非驱动表造成大量的重复访问。那么在这个时候，我们的目标就是找出这些sql来并尝试优化。在statspack报告中，根 据报告中sql列表，我们如果是通过dba_extents确定的热点对象而不是通过dba_objects确定的，则可以通过查找出的热点 segment转换为对应的表，对于非分区的索引，index_name就是segment_name,通过dba_indexes很容易的找到对应的 table_name,对于分区表和分区索引也能通过和dba_tab_partition和dba_ind_partitions找到segment和 table的对应关系。通过这些table到statspack报告中去找相关的sql。
select sql_text
from stats$sqltext a,
(select distinct a.owner,a.segment_name,a.segment_type from
dba_extents a,
(select dbarfil,dbablk
from (select dbarfil,dbablk
from x$bh order by tch desc) where rownum < 11) b
where a.RELATIVE_FNO = b.dbarfil
and a.BLOCK_ID <= b.dbablk and a.block_id + a.blocks > b.dbablk) b
where a.sql_text like ‘%’||b.segment_name||’%’ and b.segment_type = ‘TABLE’
order by a.hash_value,a.address,a.piece;
SQL_TEXT
—————————————————————-
SELECT SEQ_SMS_TRANSACTION.nextval FROM DUAL
SELECT SEQ_BIZ_EXPRESS.nextval FROM DUAL
SELECT bizgroup.seq_grp_post.NextVal FROM DUAL
SELECT SEQ_SAMPLE.nextval FROM DUAL
SELECT bizgroup.seq_grp_user.NextVal FROM DUAL
SELECT SEQ_BIZ_SEARCHER.nextval FROM DUAL
SELECT SEQ_OFFER_DRAFT.nextval FROM DUAL
select seq_Company_Draft.NextVal from DUAL
SELECT SEQ_SAMPLE_GROUP.nextval FROM DUAL
SELECT SEQ_CMNTY_USER_MESSAGE.nextval FROM DUAL
SELECT SYSDATE FROM DUAL
select seq_News_Forum.NextVal from DUAL
SELECT SEQ_SMS_USER.nextval FROM DUAL
select seq_Biz_Member.NextVal from DUAL
select seq_Pymt_Managing.NextVal from DUAL
E= ‘+08:00’ NLS_DUAL_CURRENCY = ‘$’ NLS_TIME_FORMAT = ‘HH.MI.SSX
SELECT SEQ_COMPANY_DRAFT.nextval FROM DUAL
SELECT 1 FROM DUAL
select seq_offer_draft.NextVal from DUAL
select seq_Biz_Express_Category.NextVal from DUAL
20 rows selected.
当然这里是从statspack搜集的stats$sqltext中去找的(你可以在statspack的文本报告中去找)，实际上，我们可以直接在当前数据库中的v$sqlarea或者v$sqltext里面去找到这些sql，然后来尝试优化。
select sql_text
from v$sqltext a,
(select distinct a.owner,a.segment_name,a.segment_type from
dba_extents a,
(select dbarfil,dbablk
from (select dbarfil,dbablk
from x$bh order by tch desc) where rownum < 11) b
where a.RELATIVE_FNO = b.dbarfil
and a.BLOCK_ID <= b.dbablk and a.block_id + a.blocks > b.dbablk) b
where a.sql_text like ‘%’||b.segment_name||’%’ and b.segment_type = ‘TABLE’
order by a.hash_value,a.address,a.piece;
SQL_TEXT
—————————————————————-
SELECT NULL FROM DUAL FOR UPDATE NOWAIT
SELECT SEQ_SMS_TRANSACTION.nextval FROM DUAL
SELECT SEQ_BIZ_EXPRESS.nextval FROM DUAL
SELECT SEQ_IM_GROUP.nextval FROM DUAL
SELECT SEQ_SAMPLE.nextval FROM DUAL
=’DD-MON-RR HH.MI.SSXFF AM TZR’ NLS_DUAL_CURRENCY=’$’ NLS_COMP=’
SELECT SEQ_BIZ_SEARCHER.nextval FROM DUAL
SELECT SEQ_OFFER_DRAFT.nextval FROM DUAL
SELECT SEQ_SAMPLE_GROUP.nextval FROM DUAL
DD-MON-RR HH.MI.SSXFF AM TZR’ NLS_DUAL_CURRENCY=’$’ NLS_COMP=’BI
SELECT SEQ_CMNTY_USER_MESSAGE.nextval FROM DUAL
SELECT SYSDATE FROM DUAL
SELECT SEQ_SMS_USER.nextval FROM DUAL
IMESTAMP_TZ_FORMAT=’DD-MON-RR HH.MI.SSXFF AM TZR’ NLS_DUAL_CURRE
SELECT SEQ_COMPANY_DRAFT.nextval FROM DUAL
SELECT 1 FROM DUAL
SELECT USER FROM DUAL
SELECT DECODE(‘A’,’A’,’1′,’2′) FROM DUAL
18 rows selected.
除了优化sql外，当然对于热点的表或者索引来说，如果小的话，我们可以考虑cache在内存中，这样可能降低物理读提高sql运行速度(这并不会减少 cache buffer chains的访问次数)，对于序列，我们可以对序列多设置一些cache。如果是并行服务器环境中的索引对象，并且这个索引是系列递增类型，我们可以考 虑反向索引(关于反向索引这里就不过多地做介绍了)。
热点块的其他相关症状
在数据库中还可能存在一些其他方面的热点块症状，通过v$waitstat的等待可以看出一些端倪,v$waitstat是根据数据缓冲区中各种block的类型(x$bh.class)而分类统计的等待状况。
select”>sys@OCN>select * from v$waitstat;
CLASS COUNT TIME
—————— ———- ———-
data block 1726977 452542
sort block 0 0
save undo block 0 0
segment header 40 11
save undo header 0 0
free list 0 0
extent map 0 0
1st level bmb 611 112
2nd level bmb 42 13
3rd level bmb 0 0
bitmap block 0 0
bitmap index block 0 0
file header block 13 92
unused 0 0
system undo header 111 28
system undo block 7 0
undo header 2765 187
undo block 633 156
比 如在ASSM表空间出现之前，由于freelist的存在，如果表经常被并发的进程DML，则可能存在大量的data block的等待，或者有free list的等待。那么这个时候我们发现这样的segment之后需要考虑增加freelist数量。再比如经常发生长时间的DML的表被频繁地访问，这样 将会造成过多的对回滚段中块的访问，这时可能undo block 的等待会比较多。那么我们可能需要控制DML的时间长度或者想办法从应用程序入手来解决问题。如果是undo header的等待比较多，没使用undo tablespace 之前，可能需要考虑增加回滚段的数量。
总结
本文从热点块的原理入手，详细地由oracle的内部结构特征开始介绍了热点块的产生和表现特征。进而阐述了诊断热点对象和找出造成热点对象的sql的方法。并从解决热点问题方面提供了解决方向。
文章来源：http://blog.csdn.net/biti_rainy/article/details/35188
报表练习题：销售订单打印
一、此练习的目的在于帮助同学们掌握：
1.1、如何从界面查数据来源（表或视图）
1.2、如何从界面查“界面字段对应的数据库字段”
1.3、初步掌握EBs标准Form代码的分析方法
1.4、进一步巩固基础报表开发能力
二、说明：
2.1、此练习的功能设计文档 参考doc/Md060/ 下的文档：
2.2、此练习的技术设计文档 参考doc/Md070/ 下的文档：
2.3、此练习的参考代码 参考doc/program/ 下的文档：
警告：参考代码是有问题的，直接照搬照抄是不行的，只有在弄懂了销售订单的表结构关系以后才能正确的更正并完成报表开发。
三、提示：
3.1、附件中提供的rdf中的ＳＱＬ语句可能存在问题 ：
比如：
3.1.1 附件中rdf中的SQL语句的where条件对session的语言环境有依赖，这是不对的。(比如以状态的中文名称作为条件就是不对的，如果用户切换到英文环境就完蛋了，应该以一个跟语言环境无关的状态代码作为条件）
况且where 条件中使用函数（没有建函数索引）将严重影响性能，因此就错的更离谱了。
3.1.2 原来的 sql语句是针对特定项目环境的，我能练习是针对Demo环境的，需要自己弄清楚销售订单的表结构和数据逻辑关系后加以修改。
四、常见问题：
4.1 如何从销售订单的界面查找到销售订单的数据源？
答：一般说到数据源即指： View->synonym->Table
针对销售订单：
销售订单的导航路径在：operations/welcome登录 Nav: Order Management Super User, Vision Operations (USA)-》Ordders,Return -》销售订单
查询：客户名称= ABC Corporation Asia 的订单
查历史记录可看到界面对应的View , 对View进行分析可获得其来源表信息;
所以销售订单对应的视图就是：OE_ORDER_HEADERS_V
在PLSQL Developer中打开该视图的定义，在定义中最主要的一张表一般就是主表
对销售订单头而言：oe_order_headers 看上去就是主表，但实际上，它是个同义词：
该同义词指向：ONT.OE_ORDER_HEADERS_ALL
对我们开发人员来说，在R12版本中我们客户化的程序中一般也是要使用同意词，而不是同义词指向的最终表，原因是R12的VPD策略一般都是建立在同义词上，而不是最终的表上，请看：
我们写的程序在访问数据时理应受VPD控制，所以我能对数据源的追踪也是追到同意词即可；
同理：光标停到订单行上，查看历史记录可看到订单行对应的View, 对View进行分析可获得其来源表信息.
4.2 报表中的参数：订单类型参数需要用LOV输入，如何实现？
答：订单类型的定义在
Nav:Order Management Super User, Vision Operations (USA)-》Setup-》事务处理类型-》定义
OE_transaction_types_V 的定义如下：
可见该视图主要来源是OE_TRANSACTION_TYPES_VL, 对VL进一步分析可见其最终来源于TL和同意词，因此到VL可不在往下追了，直接使用VL作为值列表的数据来源不会造成多余的查询而导致性能浪费；
在销售订单头的数据源里面，保存的是订单类型的ID， 也就是对应OE_TRANSACTION_TYPES_VL.TRANSACTION_TYPE_ID , 界面上的订单类型名称也就对应OE_TRANSACTION_TYPES_VL.name ; 所以，对于销售订单类型的值列表而言可以把SQL写成：
select TRANSACTION_TYPE_ID,name from OE_TRANSACTION_TYPES_VL; 考虑到要对OU进行屏蔽，再加一个条件：
select TRANSACTION_TYPE_ID,name from OE_TRANSACTION_TYPES_VL where org_id =fnd_profile.value(‘ORG_ID’)
可把值集定义成如下样子：
Nav：Application Developer->应用产品->验证->请求集：
编辑信息：
值集定义好以后，再把该值集赋给参数即可：
在并发程序的参数定义界面：
提交并发程序时可能出现订单类型值列表没有值的情况：
详细资料：
此现象的原因分析：
因为VL视图来源于：OE_TRANSACTION_TYPES_TL T, OE_TRANSACTION_TYPES_SYN B ，其中OE_TRANSACTION_TYPES_SYN 上面是有VPD策略的：
倘若在Form中访问VL，肯定是没有问题的，因为用户登录后，上下文环境已经存在了；但对于并发程序而言，并发程序的参数值列表是通过fdlfch(）来获取的，该程序是个C写的编译后的二进制文件，我们估计它获取上下文的逻辑与form不太一致；
我们猜测：它需要并发程序必须定义业务模式后才能正确获取到用户登录上下文：
因此需要定义并发程序的业务模式：
Nav：系统管理->并发->程序
点击 更新 按钮，一定要选择一个业务模式，然后保存；
这样再次提交报表时，参数就可以选到了：
4.3 报表中的参数：订单状态需要用LOV输入，如何实现？
答：报表参数使用LOV输入，只需要给参数定义一个值集即可，这个在上文已经讲过，对订单状态而言，关键是找到订单状态的内部Code 和 外部名称的Mapping定义来源：
光标停到状态字段，选择 帮助-》诊断-》检查 ，可知道界面上的状态对应哪个block的哪个item，一般来说，item名称与数据表中的字段一致。
如果不一致，需要打开form源代码分析，这个例子中界面上看到的Status这个字段，在View里面不存在，所以要对form进行分析，知道status的具体来源， 首先要知道当前Form的名称，这可以通过帮助->关于oracle Applications 找到：
这里的表单路径中的，OEXOEORD.fmx就是编译后的form名称，其源代码对应于OEXOEORD.fmb , 源代码一般存在于$AU_TOP/forms/US 和 $AU_TOP/forms/ZHS目录下，我们这下载中文版的Form源代码就应该从
$AU_TOP/forms/ZHS中找：
下载下来，打开时提示：此Form引用了很多其他Form， 则其他Form 也需要下载：
此例中可能需要下载的被引用的Form包括：
打开后，找到order块，打开post-query Trigger， 里面有代码OE_ORDERS.Post_Query
查找，OE_ORDERS ,可知这个Api 在OEXOEHDR 这个pll 中；
打开： OEXOEHDR 这个pll
在导航对象查找：OE_ORDERS
打开 OE_ORDERS， 找到Post-query() , Ctrl+F 在编辑器中查找 “STATUS” , 可以找到这么一段代码：
IF Name_In(l_orders_block||’.flow_status_code’) IS NOT NULL THEN
x_lookup_value:=null;
l_count:=0;
l_count:=OE_Cache_Values.IS_Value_In_Cache(
p_code =>Name_In(l_orders_block||’.flow_status_code’),
p_rg_name =>’FLOWSTATUS_CACHE’,
x_value => x_lookup_value
);
IF l_count <>0 AND x_lookup_value IS NOT NULL THEN
Copy(x_lookup_value,l_orders_block||’.status’);
ELSE
p_header_rec.flow_status_code := Name_In(l_orders_block||’.flow_status_code’);
END IF;
END IF;
从代码可知： Block 上的status 字段是根据flow_status_code 而显示出来的，所以该字段实际对应数据库表中的Flow_status_code 字段；
而且，从代码我们基本猜测到：flow_status_code 的 Code 和名称的mapping关系是在record Gruop FLOWSTATUS_CACHE 中，如果我们找到FLOWSTATUS_CACHE这个record group的定义，自然就知道其SQL来源了，因此我能查找对象FLOWSTATUS_CACHE：
可惜我们没找到，因为form中不存在FLOWSTATUS_CACHE 这个记录组的定义，既然如此，那么这个记录组有可能是在程序中动态的populate出来的，因此PLSQL检索FLOWSTATUS_CACHE ：
共找到两处代码：另外一处指向 write_value_in_cache, 是向FLOWSTATUS_CACHE记录组中写内容，看来这个记录组不是从sql语句populate出来的；那么我们要最终是谁从哪里把数据读出来，然后写进去的
我们在所有代码中查找：write_value_in_cache， 我们发现数据来源于x_header_val_rec.status
于是我们在继续全代码搜索：x_header_val_rec.status
我们发现是由：Oe_Oe_Form_Header.POPULATE_CONTROL_FIELDS 获取的：
在对象中搜索：Oe_Oe_Form_Header
什么也没有搜索到，说明这不是一个Form Pll 的package ,而是一个数据库package ,因此转到PLSQL Developer中查看其定义：
从PLsQL 程序中我们可以看到Flow_status的Code和名称的Mapping定义是在Fnd_lookup_Values表中，因此状态的值列表Sql语句我们可以写成：
SELECT lookup_code,meaning
FROM FND_LOOKUP_VALUES LV
WHERE LANGUAGE = userenv(‘LANG’)
and VIEW_APPLICATION_ID = 660
and lookup_type=’FLOW_STATUS’
定义值集并赋个报表参数的步骤此处就省略了。
答： 每次挑库都会有个挑库单报表，可以通过这个来追踪订单行与发运、库存表之间的关系
首先我们看清楚并发程序的名称：
然后我们切换到 Application Developer责任 ，
查找并发程序定义和可执行定义：
确定要到WHS模块下去找rdf 文件：
使用Report Builder 打开这个文件，查看SQL：
从SQL的From和Where 条件可以看到订单行表与各表之间的关系：
如果你不知道这里面有些表是干什么用的，可以查询Oracle 的在线TRM 表信息文档，比如，你想知道wsh_delivery_details 表是干什么的，可以登录：
EBS.R12表结构文档路径：
http://etrm.oracle.com/pls/etrm/etrm_search.search
查询这张表：
可以得到这张表的详细信息：
如果你想知道挑库单号是来自哪张表的哪个字段：可以看报表的布局，然后点挑库单号对应的框，可以追溯到其在数据模型中的字段名：
回过头来，做一张订单
挑库：
查看挑库报表： 生成了类型=挑库通知的 物料搬运单（3905075）、交货（3773389）
这个物料搬运单可以在库存模块的物料搬运单界面找到： 其对应的视图就是MTL_TXN_REQUES_LINES_V
而交货号可以在发运模块的发运事务处理界面找到
然后做延交发运（由于某种原因，当前没有商品可发运，所以就延迟交货，意味着本次交货作废）
已延交
进一步发放已延交的部分：
重新生成性的物料搬运单和交货号
重新针对新的交货，进行发运事务处理：
我们可以看到交货号是新的的交货号，但是详细信息字段还是一样的。
全部发运掉：
通过对挑库单报表的SQL和这些表、视图进行分析，可以知道：
1）交货号=wsh_new_deliveries.delivery_id=wsh_delivery_assignments_v.delivery_id
2) 详细信息的这个字段=wsh_delivery_details.delivery_detail_id
3) wsh_delivery_details 与 订单行oe_order_lines_all是一对一关系，通过
wsh_delivery_details.source_line_id =oe_order_lines_all.line_id 关联；
4）wsh_delivery_details 与 wsh_delivery_assignments_v 是一对一关系，而wsh_delivery_assignments_v 与 wsh_new_deliveries 是一对多关系，因为在发运延交的情况下，wsh_new_deliveries 就会有多条记录。
5）物料搬运单行与 wsh_delivery_details 表是通过这个关联的 mtrl.line_id = wdd.move_order_line_id
6）物料搬运单行 与 物料事务处理临时表 是一对一关系 ，关联条件是： wpsv.move_order_line_id = mtrl.line_id
7）挑库报表完成后如果显示成功挑库，就意味着已经生成了两条库存事务处理，可以根据挑库单号查询出来，比如：
加密：使用oracle提供的wrap工具：
举例：
D:\mytest> c:\devsuitehome_1\bin\wrap iname=mypackage.pck
输出:在当前目录下生成一个同名的.plb文件 mypackage.plb
编译加密文件：
登录plsqldeveloper ,打开commond窗口 ，编译加密文件：
SQL>@d:\mytest\mypackage.plb;
编译成功；
解密：使用“好事者”提供的解密工具：
base (来源：http://www.itpub.net/thread-1175718-8-1.html)
用法：base <加密文件名> <解密文件名>
可把加密的plsql 进行解密：
举例：把dbms_output的加密的部分另存为dbms_output.plb文件
d:\mytest>base dbms_output.plb dbms_output.txt
即可成功解密；
Folder查询结果不对的问题：
问题：在一次项目UAT时，一个用户测试时发现她总是查询不出结果，这个FORM是我们客户化一个标准的FORM。
解决过程：因为是标准FORM，而且我们之前自己测试时也没有遇到这个问题，所以以为系统对用户权限有什么控制，我们查看FORM源代码，但是找了很久还是没有找到问题的所在，打印DEFAULT_WHERE发现每一次查询后，DEFAULT_WHERE会增加一段相同的我们很费解的条件，就是这个条件导致查询不出结果。
问题原因：最后多亏吴前进提醒，最终我们找到问题所在。原来该用户在操作时，保存了FOLDER，在保存时勾选了”包括查询”，结果就把当时的查询条件给保存了下来，所以该用户在每一次查询是都会带上该条件，导致查询不出结果。对于保存的FOLDER，点击 文件夹-》查看查询，查看保存的查询。
总结：在用户培训时，对于FOLDER的FORM，要提醒用户此类问题，如果保存FORM时，要慎重勾选“包括查询”，除非确实需要保存的条件。对于FOLDER FORM，如果碰到某种情况加查询结果不准确，要首先考虑是不是FOLDER保存查询的原因。
FOLDER修改多堆叠画布问题
问题：在做一个Tab FOLDER FORM时，由于需要变化每一个Tab页上的ITEM，重新分配，将原来在第一个画布上的ITEM放到第三个画布上面，我直接修改的画布属性。结果导致第一个画布的ITEM布局乱了，出现了一部分ITEM堆到了另一部分ITEM上面。
解决过程：因为修改ITEM比较多，我以为是ITEM没有对应上或者Promt与内容字段顺序没有对应上的问题，结果比对了好久，发现没有问题。
问题原因：多谢徐晓晓同学提醒，原来是我直接修改ITEM属性，而没有去调整ITEM的顺序。对于这种多堆叠画布的FOLDER，需要把属于同一个画布的ITEM都放在一起，如果交叉放的话会导致一个画布上的ITEM堆起来。
思考：FOLDER将ITEM放到画布上时，应该是按照ITEM的顺序去填到画布上去的，而从一个画布到另一个画布上时，都会把ITEM从画布的最左边开始摆放，所以导致了ITEM堆起来的结果。
FORM 中LOV使用别名问题
问题：在一个LOV的记录组中SELECT nvl(p.full_name, fu.user_name) FULL_NAME
,fu.user_name
,fu.user_id
FROM fnd_user fu
,per_all_people_f p
WHERE fu.employee_id = p.person_id(+)
ORDER BY 1
LOV选择在显示之前过滤
发现查询的结果中，总是没有取到user_name的情况。
解决&总结：通过做TRACE发现，在显示之前过滤时，会自动在后面拼上一段条件FULL_NAME like :1 …..实际上执行的时候，FULL_NAME指向的是per_all_people_f里面的 FULL_NAME，所以没有出现user_name的值（其实这样使用别名是会报错，这是一个巧合）；而当把别名修改成为其他（非数据库字段名）NAME时，会报NAME标识符无效错误。这是肯定的，应为SQL就是不能用别名来作为查询条件的。解决方法有两个：1，将显示之前过滤设为否，这样就会把所有记录先查出来，然后在查询出来的记录组里再筛选。不会在之前拼SQL了。
2，如果一定要在显示之前过滤的话，使用嵌套查询。
帮助》历史记录灰掉问题
问题：在一个FORM中发现历史记录菜单灰掉
解决：这个跟块查询灰掉一样，块查询是把块级触发器WHEN-NEW-RECORD-INSTANCE触发器层级修改为BEFORE，
这个问题需要将WHEN-NEW-BLOCK-INSTANCE触发器层级修改为BEFORE，因为这两个的可用与否，是FORM级触发器判断的，如果覆盖，就不可用了。
PS：使用历史记录时 报“历史记录不可用”，是由于在该块中没有5个数据库WHO字段的原因，添加上就行了。
1、图表刷新问题：
现象：使用BI publisher在Word中插入图表以后，右键单击图表没有“BI Publisher 图表…”菜单项，且预览时，不会因为xml数据变化而使得图表跟着变化，感觉是一幅静态图片。
分析：在把文档另存为97-2003的兼容格式后，再另存为RTF格式文档后，发现在图片上右键菜单有“BI Publisher 图表…”菜单项了，预览时图形也确实会跟着xml数据变化而变化。
解决方法：按照分析中的方法创建RTF文档 ，这可能是一个兼容性问题。
2、模板文档属性问题：
现象：在RTF模版的Advanced例子中有一个需要通过设置文档属性来控制的例子 Properties， 但很难找到自定义文档属性的地方。
分析与解决：word2010设置自定义属性的地方确实够隐蔽，但也很容易找到，看下图：
在文件->信息->属性->高级属性
FROM批量处理界面效果
当遇到对ＦＯＲＭ上记录进行批量处理时，一般情况下都会选择在记录前面加上复选框，然后勾选上需要处理的数据，最后获取勾选的记录数据进行业务处理：
如果只是添加复选框，显得界面效果太单调，勾选结果显示也不够明显，将勾选的行进行特殊显示，会使得勾选效果更好。
通过在标准界面查找类似业务，找到对应ＡＰＩ：
app_record.highlight(‘SELECTED_DATA’);高亮显示当前行所有ITEM
app_record.highlight(”);取消高亮显示当前行所有ITEM
效果如下图：
这样看起来用户会更明确的看到选择的行。
效果已经做出来，但是在操作上，用户会有一些不便，选择几行或者全选还好。但是如果一次连续选择50条，100条用户需要点击100次？用户会疯掉。
解决方法：
在我们用电脑选择多个对象时，习惯性使用CTRL或者SHIFT键来多选记录，可以考虑使用这个方法来处理。
通过查找标准FORM的库代码，找到了解决方法。
核心在一个SYSTEM属性
name_in(‘SYSTEM.MOUSE_BUTTON_MODIFIERS’);
返回varchar2。
在WHEN-MOUSE-CLICK触发器时，这个属性会返回在你点击鼠标时，同时按住的那些按键名称用’+’拼接起来，如：同时按住Ctrl和Shift时返回Shift+Control+。有了这个后面问题就好解决了，只需要判断返回值是否包含Control或者Shift即可。
处理逻辑:
1. 按住Ctrl点击左键，如果原来勾选高亮显示，则变成取消勾选高亮显示，反之，则变成勾选高亮。
2. 按住Shift时需要增加一个变量记录上一次点击行Last_record
然后再根据当前点击行，循环中间所有行，勾选高亮显示，按住Shift的优先级应该高于Ctrl。
注意：因为勾选复选框时会触发WHEN-CHECKBOX-CHANGED，然后也触发WHEN-MOUSE-CLICK事件，这样按住CTRL会导致做两次事件，此时需要判断去跳过其中一个事件。
这样，就有多种操作方式选择记录了，使用户操作更加个性化，同时节省操作时间。
附：批量处理界面数据获取的心得：
对于这种勾选批量处理界面数据获取，首先想到的就是去循环界面所有记录去检查是否勾选，从而获取数据。这种方法简单，代码也很好写。但是当在界面操作时，问题就会出现：只勾选一条记录，却要去循环整个界面所有数据，还包含没有fetch到界面的数据。使得处理速度大大增加。“想尽办法去避免循环界面“这是我在做这个功能一个的体会（全选是不可避免的要循环界面了）。所以这种勾选模式要提前去获取数据。首先定义一个全局Table类型的变量，当勾选某一条记录时，将值存在Table(:SYSTEM.CURSOR_RECORD)里，取消勾选时Table.delete(:SYSTEM.CURSOR_RECORD)。这样在最后处理逻辑是只需要循环Table就行了。避免去Fetch不需要的数据（处理过程中，Table中间delete掉的记录在获取时会报No_data_found异常，只需要抛出异常跳过就行了）。即使勾选第一条和最后一条，虽然循环Table和循环界面次数一样，但是速度却有很大差别。
Oracle EBS 用户配置文件使用举例：
用户配置文件相当于系统参数，可以在不同层级（Site层、应用模块层、责任层、用户层）设置不同的值； 作用范围小的覆盖范围大的层，系统已经预设了很多user profile; 开发人员也可以定义User profile;
对开发人员如果要新定义user profile 并使用之，步骤一般包括三步
第一步：定义user profile （Nav:应用开发员责任->配置文件）
上例中定义了一个User profile : ORG_ID， SQL验证用于提供用户在设置该Profile值的时候提供LOV数据来源； 开发者只需要依葫芦画瓢即可。
如果LOV来源不是系统原有表中的数据，而是需要自己定义的，那么可使用值集定义好数据源，然后在这里的SQL中使用，下面的例子就是这样的：
上述例子中，lov数据来源于fnd_flex_values_vl视图，该视图中的内容是用户可以在界面上定义增加的，一般步骤是：
a) 先定义一个值集（Nav: 系统管理员责任->应用产品->验证->请求集：
值集名将用在上面的sql中，验证类型为独立。
b) 为新定义的值集添加值(NAV: 系统管理员责任->应用产品->验证->值）
在名称处输入刚才定义的值集名作为查询条件，然后点查找
在该界面可以为上面定义的值集添加值。
第二步：设置User Profile的值（Nav：系统管理员责任-> 配置文件-> 系统）
如果需要同时设置责任层和用户层的值，则把两者都勾选上。
上例中，责任 order Management user,… 和 用户Operations 层都设置了值； 且值是不一样的。 由于用户层的值可以覆盖责任层的值，当operations 用户以 order Management user,..责任登录系统是，Form中取到的值是： Vision ADB;
三、 程序中获取User profile 值：
在程序中可以使用fnd_profile.value(‘ORG_ID’) 来获取 ORG_ID这个user profile的值； 有关用户配置文件的详细概念和API，请参考120devg.pdf 第249页。
各位请把自己Form练习过程中遇到的各种问题上报到这里。
回帖格式：
问题现象描述：
问题分析：
解决方法：
/*
Media : Oracle EBS virtual machine
Version : Oracle EBS 12.1.3 (Demo)
vm Release date : 2010-08-13
Language : English & Chinese
Pourpose : Only use for Training and SelfStudy
patchs have been applied on this vm:
2010-07-26 Create EBS 12.1.1(Demo) English version
2010-08-08 p8576725_12.1.0_R12_GENERIC This is an AD Patch ,use to Faster Language patching Process;
2010-08-13 V16181-01.zip ZHS language Patch
2010-08-15 p8502056_R12.AD.B_R12_LINUX.zip AD Patch Which Must be applied Before R12.1.2 RUP2 Patch
2010-08-15 7303033,7303033_ZHS R12.1.X RUP2 patch( know as 12.1.2) (比较耗时 大约16小时)
2010-09-23 解决系统使用中的有些问题(包括中文登陆及OM界面及INV模块授权等,详情:http://blog.retailsolution.cn/archives/2585)
2010-11-27 p9239089_R12.AD.B_R12_LINUX.zip AD Patch Which Must be applied Before R12.1.3 RUP3 Patch
2010-11-27 9239090,9239090_ZHS R12.1.X RUP3 patch( know as 12.1.3) (比较耗时 大约16小时)
2011-03-06 对虚拟硬盘进行重新整理，去掉未用空间，总大小从312G缩小到240G（依然保留10G可用空间）
If you have any Problem ,please contact yunfang.shang@hand-china.com
*/
使用指南:
1 使用vmware 7.1打开(如果你的机器配置不高,请打开后调整虚拟机的内存和CPU配置,默认是分配4G内存,4个逻辑CPU)
2 打开vmx时询问 move 还是 copy ,选择move
3 Linux 用户名/密码: root/rootroot
4 起数据库和应用服务器
切换到oracle用户,在/home/oracle 目录下有起停数据库的脚本,执行即可.
su – oracle
./startdb.sh
切换到applmgr用户,在/home/applmgr 目录下有起停应用的脚本,执行即可.
su – applmgr
./startapp.sh
5 停应用服务器和数据库
切换到applmgr用户,在/home/applmgr 目录下有起停应用的脚本,执行即可.
su – applmgr
./stopapp.sh
切换到oracle用户,在/home/oracle 目录下有起停数据库的脚本,执行即可.
su – oracle
./stopdb.sh
6 若要执行应用层的adadmin,adpatch等工具,请切换到applmgr用户 su – applmgr (将自动执行环境变量 . /home/applmgr/.bash_profile)
7 若要执行dB层的工具,请先执行环境变量,请切换到oracle用户 su – oracle(将自动执行环境变量 . /home/oracle/.bash_profile)
8 访问: http://syfdemo.ml.com:8000
用户名/密码: sysadmin/sysadmin
operations/welcome
备注:
1 你需要在windos/system32/drivers/etc/hosts 中添加域名解析(假设你的主机中的vmnet8网卡的网段是192.168.15.1,虚拟网络上vmnet8的网关设置为192.168.15.2)
192.168.15.23 syfdemo.ml.com syfdemo
2 此虚拟机采用Nat 方式,IP地址为192.168.15.23, 你需要更改你的虚拟环境nat网卡的设置
1）在Win7 控制面板\网络和 Internet\网络连接 把VMnet8的ip地址改成192.168.15.1
2) 在vmware 菜单 edit\virtural network edit\ 吧VMnet8的Subnet IP 地址设置为 192.168.15.0 ,nat Setting 中 网关设置为192.168.15.2;
3) 重启vmware.
OK了。
若你不想改变自己的nat网络设置，那么可以改变虚拟服务器的IP地址，但注意IP变更后请运行autofig($INST_TOP/admin/scripts/adautocfg.sh),否则会出现oc4j连接不上数据库而出现http 500错误.
3 关于诊断：已经在站点层把系统配置文件 Utilities:Diagnostics 设置为Yes,因此通过菜单 帮助->诊断-检查，不需要输入密码（http://forums.oracle.com/forums/thread.jspa?messageID=9247656）
4 使用过程中有任何问题，可到这里讨论：http://spaces.hand-china.com/home/space.php?uid=1497&do=blog&id=2037
常见问题：
1、现象：有同学启动虚拟机的时候选择了复制，结果在启动linux的时候被询问是否要重新配置的时候选择了Skip忽略，导致无法启动数据库。
原因：网络状态无效。
解决：在linux->系统设置->网络管理-> 网卡eth0的硬件配置处重新探测MAC地址，然后保存，重启网络 service network restart
停止数据库：./stopdb.sh
如果侦听还没被停掉，使用lsnrctl stop停止它。
重启数据库 ./startdb.sh
2、现象：有同学自行运行了autoconfig ,但不知道apps密码，于是随便给了一个密码运行了一段出问题了，启动数据库没问题，但启动应用服务的时候报用户名或密码错。
原因：非正常运行autoconfig 导致 Apps用户被锁定，
解决：使用system登陆数据库，把apps用户解锁 alter user apps account unlock;
再次运行autoconfig ,使用正确的apps密码（apps)
autoconfig成功完成后，再次启动应用服务器。
3、现象：有同学不小心使用root用户启动应用服务器，结果不成功，切换到applmgr后再次启动应用服务器也不成功；
原因：使用root用户启动导致opmn的log文件的所有者被改成root, applmgr启动时因为权限不够无法成功启动。
更改错误提示中提及的log文件的权限的所有者为applmgr, 再次以applmgr启动服务可以成功.
此问题也会导致autoconfig失败，原因也是有2个文件的所有者被改成root,根据autoconfig的log信息可以找到这两个文件，更改权限为applmgr所有后可以成功完成autoconfig.
但 数据库、应用服务启动均正常，但访问时出现 无法找到OA_HTML/appslogin的情况；把$INST目录递归更改成applmgr:dba后解决。
解决：在应用目录下找出user是root的文件
[root@syfdemo opmn]# find /d01/oracle/VIS/inst/apps -type f -user root -exec ls -ls {} \;
将找到的文件的所有者和组改为应用的用户.
例如：chown -R applmgr:dba /d01/oracle/VIS/inst/apps/VIS_syfdemo/logs
chown -R applmgr:dba /d01/oracle/VIS/inst/apps/VIS_syfdemo/ora/10.1.3/j2ee
然后停应用,重启服务器!!
4、现象：有同学回到寝室使用虚拟机，启动服务器正常，但访问时卡了，很长时间后出现http 500错误。
原因：目前实验发现虚拟机中的oracle db11g 的侦听服务对主机网卡状态敏感，主机网卡没联网的情况会导致反应很慢的情况。
解决：使用EBS R12虚拟机时请保志主机网卡状态处于连接状态（比如可以两个人电脑互联，并设置一个固定IP,使主机网卡状态有效);或者把网络改成host only方式（这种方式不需要保持网络连接状态)
或者如果你很想使用nat方式，但又无法联网，则把虚拟机中的DNS去掉也可以。
测试说明:
1、磁盘IO速度：
在光驱位或者esata接口的7200转笔记本硬盘上hdparm测试为78M/S；
在usb2.0接口的5400转笔记本硬盘上的hdparm测试为11M/S；
2、只要内存分配足够大（比如3个G），那么usb2.0接口的硬盘上使用效果也还可以，响应速度并不慢。
如果内存不够大，使用比较慢，请自行优化相关参数配置（比如DB层（DB的Init Parameter）和应用层（SID_host.xml))
现象：主机不连网的情况下，EBS虚拟机(NAT方式）的数据库及应用服务器启动正常，访问虚拟机http://syfdemo.ml.com:8000,第一个html页面能出来
，但在转http://syfdemo.ml.com:8000/OA_HTML/AppsLogin的时候就卡住了。一段时间后报如下错误：
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, ohs_admin@ml.com and inform them of the time the error occurred, and anything you
might have done that may have caused the error.
More information about this error may be available in the server error log.
查：/d01/oracle/VIS/inst/apps/VIS_syfdemo/logs/ora/10.1.3/j2ee/oacore/oacore_default_group_1/application.log可以发现网络错误和sql连接错误。
在applmgr用户下，直接sqlplus连接数据库也没有反应，从另一个虚拟机中ping EBS虚拟机正常，但连接数据库也没有反应，netstat 查数据库侦听进程在运行中，但就是没有反应。
把网线插到主机网口上，等待的数据库连接马上就连上了。 但应用服务器的访问会报http 500错误， 重启应用服务器后访问正常。再次拔掉主机网卡上的网线（并把无线网卡也关掉），数据库需要很长时间才能再连上，而且即使连上，进去执行sql的时间也比正常情况下要长。数据库的响应性能大大降低。在win7中，即使给本地连接设置固定ip地址，使用ipconfig看到的也是无ip,仅显示媒体已断开。设置一个与主机桥接网络网段不一致的无效固定IP,然后连上网线，虚拟网络中plsql登陆数据库依然很慢。只有在主机网卡状态正常有效地情况下，虚拟网络中plsql登陆速度和sql查询速度才正常。（在主机网卡断开的情况下，虚拟网络内部ping是没有问题的。）
继续拿ebs11i的虚拟机做实验，我们发现即使在主机网卡断开的情况下，访问数据库的速度都很正常。也就是说oracle 9i的侦听响应不依赖主机网卡状态。
综上：从实验来看，EBS 虚拟机中 oracle 11g的数据库侦听难道依赖主机的网卡状态。
Action：win7 使用EBS R12的虚拟机时,请保持主机网卡处于连接状态。（更好的方法请等待以后发布。。。）
或者 换成host方式的网络（有同学说host方式的网络在主机网卡断开的情况下使用正常）
Creation Time: 2011-03-05
LastUpdate Date: 2011-03-05
Author: 商云方
—————————————————————————————-
EBS R12 Demo版安装后有236G（linux显示这么大，那么在windows下需要创建约260G 左右的虚拟硬盘），尝试进行瘦身操作，稍微压缩掉一些空间占用。
一 、Demo版中有很多历史数据
2.2 利用 Joanne S. Davis 对EBS数据清理方面的总结，对历史数据进行清理：
2.2.1 FA模块的清理
FA 模块有两类归档和清理程序：
1）批量添加（Mass Additions）
2）折旧和调整事务处理记录（Depreciation and Adjustment Transaction records ）
批量添加：
Delete Mass Additions 程序把成批添加信息归档到一个归档表，然后就可以被清除。
标准：Delete Mass Additions 程序会删除”已经删除或已过帐队列“中的成批传输信息，归档到审计跟踪表。
操作指导：
1. (B) Archive
2. Export the archive tables
3. Requery the archive
4. (B) Purge
5. Drop temporary archive tables
这个并发程序实际就是删除 FA.FA_DELETED_MASS_ADDITIONS 表中的数据；
select count(*) from FA_DELETED_MASS_ADDITIONS –507条
select blocks from dba_segments where segment_name=’FA_DELETED_MASS_ADDITIONS’; –16个block
–没必要进一步做碎片整理。因为即便把这些数据全部删除，并做Move, 索引重建后该表占用的block也不会少于16个；
2.2.n) 总帐模块的数据清理
–GL_CONSOLIDATION_AUDIT 表碎片整理
由于该表空间APPS_TS_INTERFACE的空间管理模式不是ASSM，无法做Shrink，只能用Move tablespace+索引rebuild的方式进行碎片整理：
select count(*) from GL_CONSOLIDATION_AUDIT –0条
select blocks from dba_segments where segment_name=’GL_CONSOLIDATION_AUDIT’; –16个block
alter table GL.Gl_Consolidation_Audit move tablespace user_data;
alter table GL.Gl_Consolidation_Audit move tablespace APPS_TS_INTERFACE;
alter index GL.GL_CONSOLIDATION_AUDIT_N1 rebuild;
alter index GL.GL_CONSOLIDATION_AUDIT_N2 rebuild;
select blocks from dba_segments where segment_name=’GL_CONSOLIDATION_AUDIT’; –16个Block 这16个block是表初始化就有的吗？
2.2.n) OM模块清除订单和报价单
先运行Order Purge Selection ,选择要清除的订单，比如这里选择条件是2007-12-31 前订单，产生一个订单集。然后再运行purge Set清除这个订单集。
–销售订单
select count(*) from oe_order_headers_all –10923
select blocks from dba_segments where segment_name=’OE_ORDER_HEADERS_ALL’; –560
点【Submit Purge】提交请求，进行删除：
–Puge后
select count(*) from oe_order_headers_all –8408
select blocks from dba_segments where segment_name=’OE_ORDER_HEADERS_ALL’; –560
select * from oe_order_headers_all oh where oh.order_number=’207260′ –无记录，说明确实被删除了
select * from oe_order_headers_all oh where oh.order_number=’777809′ –有记录，说明puge set中非“Closed"状态的记录是不会被删除的。
–碎片整理前APPS_TS_TX_DATA的Free Mb=1868:
–进行Order表碎片整理
alter table ONT.OE_ORDER_LINES_ALL shrink space;
alter table ONT.OE_ORDER_HEADERS_ALL shrink space;
–整理后：FreeMB=1879; 释放了11M空间；
select blocks from dba_segments where segment_name=’SO_LINE_APPROVALS’; –16 ,无需整理
select blocks from dba_segments where segment_name=’SO_PICKING_LINES_ALL’; –80，需要整理一下
–进行 SO_PICKING_LINES_ALL 表的碎片整理
整理前：
APPS_TS_ARCHIVE 是ASSM模式的，可以用Shrink整理：
整理：
alter table OE.SO_PICKING_LINES_ALL enable row movement;
alter table OE.SO_PICKING_LINES_ALL shrink space;
alter table OE.SO_PICKING_HEADERS_ALL enable row movement;
alter table OE.SO_PICKING_HEADERS_ALL shrink space;
alter table OE.SO_PICKING_LINE_DETAILS enable row movement;
alter table OE.SO_PICKING_LINE_DETAILS shrink space;
alter table OE.SO_PICKING_BATCHES_ALL enable row movement;
alter table OE.SO_PICKING_BATCHES_ALL shrink space;
整理后：没啥变化，看来原来就没啥碎片；
在订单清除程序中，还有一些跟订单相关的表中数据也会被清除，但估计数据量较小，也没啥碎片。此处略，想了解还有哪些表中的数据被清除可查看OEXPURGE这个package;
总结：本次销售订单清除了2500多条已经Closed的记录，碎片整理后节省11M空间；
如果想进一步清除，就要把系统中现有的可以关闭的销售订单都关闭掉，然后才能进一步清除。
=============
报价单清除：
生成puge set:
只有一条可清除：
submit purge , 成功puge了一条记录：
2.2.n) OM模块清除导入的信贷风险记录
此程序实际是删除 OE_CREDIT_SUMMARIES 表中balance_type =18的记录，目前不存在这样的记录。
2.2.n) OM模块清除订单处理过程中的历史消息
alter table ONT.OE_PROCESSING_MSGS enable row movement;
alter table ONT.OE_PROCESSING_MSGS shrink space;
alter table ONT.OE_PROCESSING_MSGS_TL enable row movement;
alter table ONT.OE_PROCESSING_MSGS_TL shrink space;
整理前：
整理后：
释放了3M空间；
2.2.n) Shipping模块清除例外日志信息
先close 再purge; Purge了7条记录
select blocks from dba_segments where segment_name=’WSH_EXCEPTIONS’ –86 可以整理一下
alter table WSH.WSH_EXCEPTIONS enable row movement;
alter table WSH.WSH_EXCEPTIONS shrink space;
整理后 FreeMB 从1881变成1882，节省了1M空间；
2.2.n) INV模块清除 Transaction(逐个切换一次库存组织运行一次）
此程序删除已经关闭的库存会计期的如下表中的记录：
MTL_MATERIAL_TRANSACTIONS
MTL_MATERIAL_TXN_ALLOCATIONS
MTL_TRANSACTION_LOT_NUMBERS
MTL_UNIT_TRANSACTIONS
MTL_TRANSACTION_ACCOUNTS
查询数据库发现，在已经关闭的会计期中，相应的库存组织中的记录甚少，可能oracle 自己清除过。
清理碎片
alter table INV.MTL_MATERIAL_TRANSACTIONS enable row movement;
alter table INV.MTL_MATERIAL_TRANSACTIONS shrink space;
耗时60分钟：
整理后FreeMB从 1882 M 变成 2179M ，节省空间297M；
select blocks from dba_segments where segment_name=’MTL_UNIT_TRANSACTIONS’; –1344
alter table INV.MTL_UNIT_TRANSACTIONS enable row movement;
alter table INV.MTL_UNIT_TRANSACTIONS shrink space;
MTL_UNIT_TRANSACTIONS 整理后节省5M空间；
MTL_MATERIAL_TXN_ALLOCATIONS 无需整理 ， MTL_TRANSACTION_LOT_NUMBERS整理后没有节省空间；
select blocks from dba_segments where segment_name=’MTL_TRANSACTION_ACCOUNTS’; –63408
alter table INV.MTL_TRANSACTION_ACCOUNTS enable row movement;
alter table INV.MTL_TRANSACTION_ACCOUNTS shrink space;
select blocks from dba_segments where segment_name=’MTL_TRANSACTION_ACCOUNTS’; –23440
MTL_TRANSACTION_ACCOUNTS 整理后节省了2496-2184=312M空间；
2.2.n) INV模块清除标准成本历史记录
此程序需要逐个组织运行，比较麻烦；可考虑直接参考清除程序，以脚本清除：
declare
I_UPDATE_ID number;
begin
select max(cost_update_id) into I_UPDATE_ID from cst_cost_updates;
DELETE FROM cst_std_cost_adj_values
WHERE cost_update_id <= I_UPDATE_ID;
DELETE FROM cst_standard_costs C
WHERE cost_update_id <= I_UPDATE_ID;
DELETE FROM cst_elemental_costs
WHERE cost_update_id <= I_UPDATE_ID;
DELETE FROM cst_cost_updates C
WHERE cost_update_id <= I_UPDATE_ID
AND NOT EXISTS (
SELECT ‘X’
FROM cst_standard_costs
WHERE cost_update_id = C.cost_update_id
);
end;
commit;
alter table BOM.CST_STD_COST_ADJ_VALUES move tablespace user_data;
alter table BOM.CST_STD_COST_ADJ_VALUES move tablespace APPS_TS_INTERFACE;
alter index BOM.CST_STD_COST_ADJ_VALUES_N1 rebuild;
alter index BOM.CST_STD_COST_ADJ_VALUES_N2 rebuild;
alter index BOM.CST_STD_COST_ADJ_VALUES_N3 rebuild;
alter index BOM.CST_STD_COST_ADJ_VALUES_N4 rebuild;
节省 368-295=73M
alter table BOM.CST_STANDARD_COSTS enable row movement;
alter table BOM.CST_STANDARD_COSTS shrink space;
节省 2M
alter table BOM.CST_ELEMENTAL_COSTS enable row movement;
alter table BOM.CST_ELEMENTAL_COSTS shrink space;
节省 3M
alter table BOM.CST_COST_UPDATES enable row movement;
alter table BOM.CST_COST_UPDATES shrink space;
节省0M
2.2.n) INV模块清除成本信息
比较麻烦，几十个库存组织，每个组织都有几十种成本类型，全部清除得提交几百次请求，太麻烦了，搞了一个库存组织后就买有再继续搞。
sql>select count(1) from CST_ITEM_COST_DETAILS
sql>158230
===============================
下面这段代码可以清除，所以用户定义的成本类型及其成本信息：
declare
l_sysadmin_userid number;
begin
select fu.user_id into l_sysadmin_userid from fnd_user fu where fu.user_name=’SYSADMIN’;
for cur_cost_type in (select cost_type_id
from CST_COST_TYPES
where FROZEN_STANDARD_FLAG != 1
and created_by != 1
) loop
begin
DELETE FROM CST_RESOURCE_COSTS
WHERE COST_TYPE_ID = cur_cost_type.cost_type_id ;
DELETE FROM CST_RESOURCE_OVERHEADS
WHERE COST_TYPE_ID = cur_cost_type.cost_type_id;
DELETE FROM CST_DEPARTMENT_OVERHEADS
WHERE COST_TYPE_ID = cur_cost_type.cost_type_id;
DELETE FROM CST_COST_TYPE_HISTORY
WHERE COST_TYPE_ID = cur_cost_type.cost_type_id;
DELETE FROM CST_ITEM_COST_DETAILS
WHERE COST_TYPE_ID = cur_cost_type.cost_type_id;
DELETE FROM CST_ITEM_COSTS
WHERE COST_TYPE_ID = cur_cost_type.cost_type_id;
UPDATE CST_COST_TYPES
SET DISABLE_DATE = SYSDATE,
LAST_UPDATE_DATE = SYSDATE,
LAST_UPDATED_BY = l_sysadmin_userid
WHERE COST_TYPE_ID = cur_cost_type.cost_type_id;
end;
end loop;
end;
===========================
数据量比较小，不用清除；
这里有篇文章对成本信息清除讲得比较详细：http://erplife.blog.sohu.com/79729842.html
2.2.n) 系统管理员：删除工作流运行时历史记录:
select count(1) from WF_ACTIVITY_ATTR_VALUES –66725
select count(1) from WF_ACTIVITY_TRANSITIONS –86098
select count(1) from WF_PROCESS_ACTIVITIES –72976
select count(1) from WF_ACTIVITY_ATTRIBUTES_TL –64658
select count(1) from WF_ACTIVITY_ATTRIBUTES –32329
select count(1) from WF_ACTIVITIES_TL –70072
select count(1) from WF_ACTIVITIES –35036
select count(1) from WF_NOTIFICATION_ATTRIBUTES –1592550
select count(1) from wf_comments –145244
select count(1) from WF_NOTIFICATIONS –143924
select count(1) from WF_ITEM_ACTIVITY_STATUSES_H –175769
select count(1) from WF_ITEM_ACTIVITY_STATUSES –902070
select count(1) from WF_ITEM_ATTRIBUTE_VALUES –6232267
select count(1) from WF_ITEMS –171932
select count(1) from WF_LOCAL_USER_ROLES –99055
select count(1) from WF_USER_ROLE_ASSIGNMENTS –99424
select count(1) from WF_LOCAL_USER_ROLES –99055
select count(1) from WF_USER_ROLE_ASSIGNMENTS –99424
select count(1) from WF_LOCAL_ROLES –79131
挑几个大的做shrink:
select blocks from dba_segments where segment_name=’WF_NOTIFICATION_ATTRIBUTES’; –25776
alter table APPLSYS.WF_NOTIFICATION_ATTRIBUTES enable row movement;
alter table APPLSYS.WF_NOTIFICATION_ATTRIBUTES shrink space;
select blocks from dba_segments where segment_name=’WF_NOTIFICATION_ATTRIBUTES’; –23680
select blocks from dba_segments where segment_name=’WF_ITEM_ATTRIBUTE_VALUES’; –100336
alter table APPLSYS.WF_ITEM_ATTRIBUTE_VALUES enable row movement;
alter table APPLSYS.WF_ITEM_ATTRIBUTE_VALUES shrink space;
select blocks from dba_segments where segment_name=’WF_ITEM_ATTRIBUTE_VALUES’; –79408
select blocks from dba_segments where segment_name=’WF_ITEMS’; –1968
alter table APPLSYS.WF_ITEMS enable row movement;
alter table APPLSYS.WF_ITEMS shrink space;
select blocks from dba_segments where segment_name=’WF_ITEMS’; –1536
节省了130M
alter table APPLSYS.WF_ITEM_ACTIVITY_STATUSES enable row movement;
alter table APPLSYS.WF_ITEM_ACTIVITY_STATUSES shrink space;
节省80M
其他小表节省10M
2.2.n)系统管理员：清除并发程序和并发管理器的日志
二、Demo版安装后有些表空间的利用率很低，先查处利用率小于80%的数据文件，进行Resize, Resize后的大小为：已使用大小+ 原大小×10%;
1.1 使用此语句查询后发现，大约有15G的空间可以释放掉。
select sum(大小M),sum(Resizeto) from
(
select 物理文件名,大小M,已使用M, 已使用M/大小M 利用率，已使用M + 大小M*0.1 Resizeto from
(
select
b.file_name 物理文件名,
b.tablespace_name 表空间,
b.bytes/1024/1024 大小M,
(b.bytes-sum(nvl(a.bytes,0)))/1024/1024 已使用M
from dba_free_space a,dba_data_files b
where a.file_id=b.file_id
group by b.tablespace_name,b.file_name,b.bytes
)
where 已使用M/大小M <0.8
)
–生成批量resize的脚本：
select ‘alter database datafile ”’ || 物理文件名 ||”’ resize ‘ || ceil(RESIZEto) || ‘M;’ from
(
select 物理文件名,大小M,已使用M, 已使用M/大小M 利用率，已使用M + 大小M*0.1 Resizeto from
(
select
b.file_name 物理文件名,
b.tablespace_name 表空间,
b.bytes/1024/1024 大小M,
(b.bytes-sum(nvl(a.bytes,0)))/1024/1024 已使用M
from dba_free_space a,dba_data_files b
where a.file_id=b.file_id
group by b.tablespace_name,b.file_name,b.bytes
)
where 已使用M/大小M <0.8
)
Resize 后linux下显示为 209G， windows下 新建虚拟硬盘 220G，把oracle目录复制到新硬盘，复制完成没有错误；但新硬盘可用空间为0；没办法，把虚拟硬盘expand到230G,然后在linux下重新调整分区大小。
[root@syfdemo ~]# fdisk /dev/sdc
The number of cylinders for this disk is set to 30024.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/sdc: 246.9 GB, 246960619520 bytes
255 heads, 63 sectors/track, 30024 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 1 28719 230685336 83 Linux
Command (m for help): m
Command action
a toggle a bootable flag
b edit bsd disklabel
c toggle the dos compatibility flag
d delete a partition
l list known partition types
m print this menu
n add a new partition
o create a new empty DOS partition table
p print the partition table
q quit without saving changes
s create a new empty Sun disklabel
t change a partition’s system id
u change display/entry units
v verify the partition table
w write table to disk and exit
x extra functionality (experts only)
Command (m for help): p
Disk /dev/sdc: 246.9 GB, 246960619520 bytes
255 heads, 63 sectors/track, 30024 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 1 28719 230685336 83 Linux
Command (m for help): d
Selected partition 1
Command (m for help): p
Disk /dev/sdc: 246.9 GB, 246960619520 bytes
255 heads, 63 sectors/track, 30024 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-30024, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-30024, default 30024): 30024
Command (m for help): p
Disk /dev/sdc: 246.9 GB, 246960619520 bytes
255 heads, 63 sectors/track, 30024 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 1 30024 241167748+ 83 Linux
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
[root@syfdemo ~]# fdisk /dev/sdc
The number of cylinders for this disk is set to 30024.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/sdc: 246.9 GB, 246960619520 bytes
255 heads, 63 sectors/track, 30024 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 1 30024 241167748+ 83 Linux
Command (m for help): q
[root@syfdemo ~]#
[root@syfdemo ~]# resize2fs -p /dev/sdc1 241167748
resize2fs 1.35 (28-Feb-2004)
The containing partition (or device) is only 60291937 (4k) blocks.
You requested a new size of 241167748 blocks.
[root@syfdemo ~]# e2fsck -f /dev/sdc1
e2fsck 1.35 (28-Feb-2004)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdc1: 800563/28835840 files (0.4% non-contiguous), 54814204/57671334 blocks[root@syfdemo ~]# resize2fs -p /dev/sdc1
resize2fs 1.35 (28-Feb-2004)
Resizing the filesystem on /dev/sdc1 to 60291937 (4k) blocks.
Begin pass 1 (max = 80)
Extending the inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/sdc1 is now 60291937 blocks long.
[root@syfdemo ~]# mount /dev/sdc1 /d02
[root@syfdemo ~]#
调整完毕后， EBSR12.1.3 中英文版的vmdk为230G (里面还留有可用空间为大约10G，足以支持并发程序产生的日志之类的需求了，另外有些特殊试验需要扩展表空间也是可以的）。
这样子瘦身其实也就是减小了大约20G，效果并不理想，以后有时间再搞，待续。。。。
其他参考：
1、（如果要看哪些表使用了比较大的空间，可以先进行分析后从数据字典统计）：
对所有表和索引进行一次分析收集（过程比较长，大约15小时，试验结果表明即便不分析对于统计所有表和索引所占的空间大小差异也不大，所以也可以不统计）
begin
–分析所有表：analyze table TABLENAME compute statistics
for cur_item in (select owner, table_name from dba_tables where owner<>’SYS’ and last_analyzed < sysdate -1) loop
begin
dbms_stats.gather_table_stats(cur_item.owner,cur_item.table_name);
exception
when others then
dbms_output.put_line(‘Analyze Table Exception：’||sqlerrm);
end;
end loop;
–分析所有索引：analyze index INDEXNAME estimate statistics
for cur_item in (select owner, index_name from dba_indexes where owner<>’SYS’ and last_analyzed < sysdate -1) loop
begin
dbms_stats.gather_index_stats(cur_item.owner,cur_item.index_name);
exception
when others then
dbms_output.put_line(‘Analyze Index Exception：’||sqlerrm);
end;
end loop;
end;
2、Joanne S. Davis 的EBS清理总结文档附件 achieve_and_purge
3、清理后进行碎片整理，方有效果；
整理前：
APPS_TS_TX_DATA
SIZE=58669M
Free=1705M
Userd Mb=56963MB
对销售订单行表碎片整理：
alter table ONT.OE_ORDER_LINES_ALL enable row movement;
alter table ONT.OE_ORDER_LINES_ALL shrink space;
整理后
APPS_TS_TX_DATA
SIZE=58669M
Free=1852M
Userd Mb=56816MB
销售订单行表占用空间自由几十M，但由于以前删除了很多数据，碎片多，整理效果还是很明显的。
alter table GL.GL_BALANCES enable row movement;
alter table GL.GL_BALANCES shrink space;
这个Shrink要900多秒，时间很长；
整理后
APPS_TS_TX_DATA
SIZE=58669M
Free=1869M
Userd Mb=56800MB
GL_BALANCES 表本身很大，占用空间1G多，但由于删除很少，碎片很少，虽然话了15分钟整理，但整理后效果不明显。
总结：瘦身的基本思路是：
1、进行EBS清理，删除不需要的数据。
2、进行表的碎片整理，为Resize做准备。
3、对数据库文件做Resize，缩减空间。
vmware虚拟机中的oracle数据库侦听性能问题
最近发现一件怪事情：vmware虚拟机中的oracle数据库在更改到另一网段的IP后性能暴降，简直低到不能忍受。
背景：vmware 7.1软件运行于64位 win7平台。新建一个32位置 linux（redhat 5.x) 虚拟机，数据库oracle11g 运行于此虚拟机上。
问题重现步骤（nat方式）：
1、假设你的虚拟机的vmnet8 （nat) 是192.168.15.X 网段，设置虚拟机网络为nat方式，并设置虚拟机的ip地址为192.168.15.10 ; 这种情况下，在虚拟机的本机上使用sqlplus username/passwrod@Tnsname 链接数据库，速度很快，基本在1秒以内肯定链接上了。
2、更改你的数据库的 IP地址到其他网段，比如192.168.188.10 , 重启inxu网络服务，再重启数据库，再测试，在虚拟机本机上 使用sqlplus username/passwrod@Tnsname 连接数据库，速度很慢，大概有10秒以上。
或者，你使用桥接方式测试也是这样的：
问题重现步骤（桥接方式）：
假设你的虚拟机使用桥接方式：在家庭网络中，你的桥接网段是192.168.1.x , 你的数据库ip 是：192.168.1.10 , 这时候速度正常。 然后你到了公司，网段是10.X.X.X ; 这时候发现在公司网段中数据库测试：在虚拟机本机上使用 sqlplus username/passwrod@Tnsname 连接数据库，速度很慢，大概有10秒以上。
按道理说：我在虚拟机本机上使用sqlplus又没有跨什么网络。使用traceroute都是一跳就到了。这是什么原因导致oracle 的侦听响应特别慢呢？
本文的上一篇文章是：从 R12.1.1 升级到 R12.1.2 中文语言 Patch问题
1、访问主组织物料提示：你必须至少允许访问一组物料属性。
原因：INV模块没有被授权
解决方法：system administration ->License Manager ->Product 把INV 产品授权，即可。
2、打开order 界面 报ORA-04062错误 of state changed,且中文语言进入的Form上还都是英文的。
解决方法：adadmin 重新编译数据库对象、重新编译菜单（这个还算快，不太费时）。 没用！
adadmin 重新编译Form（比较耗时间，准备1晚上吧，9000多个Form，Pll任务要编译 US 和 ZHS） ，ORA-04062 在新建订单时不出现了，中文Form进入也是显示中文label了。
3、中文模式进入OM模块 编辑订单时还提示CCID未找到，订单行上的Item显示为空。但英文模式进入没有上述问题。
查 ： select distinct language from mtl_system_items_tl 只有 US ,没有中文。
select * from fnd_lookup_values where language =’ZHS’ 有中文。
说明只是部分表的多语言没有被初始化。
解决方法：停应用；
想使用adadmin 中的 Maintain multi-lingual tables 功能来把item的中文给初始化一下，但又担心把其他好的表中的中文内容给“冲”掉。于是查Maintain multi-lingual tables究竟干了什么？ 查metalink [ID 981868.1] 发现在执行Maintain multi-lingual tables 时，实际就是执行inv模块下面的 sql/INVNLINS.sql ;打开这个sql看，其实针对item执行的是INV_ITEM_PVT.add_language; 查看INV_ITEM_PVT.add_language的代码，发现其逻辑是：不会重复“覆盖”原来已经有其他语言的记录。所以多次执行也没有问题，但为什么为什么Item的中文信息会丢失呢？难道是以前没有运行Maintain multi-lingual tables，不可能啊，ORG_FREIGHT_TL中是有中文的记录的，ORG_FREIGHT_TL的中文信息也是在sql/INVNLINS.sql执行的。
不管它，先在plsqldeveloper中直接运行 INV_ITEM_PVT.add_language，把中文item给生成了。
再起应用，中文环境，进入OM,打开一张订单 item已经有了，但是新建一行时，计量单位还是没有，在英文环境是好的。
停应用，使用adadmin Maintain multi-lingual tables, 再启应用,在中文下问题依旧，查MTL_UNITS_OF_MEASURE_TL 确实缺少中文记录，查adadmin的log INVNLINS.sql已执行。在plsqldeveloper中单独执行 INVNLINS.sql ，发现例外：
LANGUAGE = AMERICAN
PACKAGE= MTL_UNITS_OF_MEASURE_TL_PKG
SQLERRM= ORA-00001: unique constraint (INV.MTL_UNITS_OF_MEASURE_TL_U2) violated
是这个原因导致 INVNLINS.sql执行中断的。
这些记录比较怪，Source_lang =’ZHS’,这是不对的，source_lang 应该都是’US’才对。
| Period | N | 2010/8/13 22:38 | 0 | 2005/5/5 | 120 | 0 | 每半年 | 每半年 | ZHS | ZHS | |
| Period | N | 2010/8/13 22:38 | 0 | 2005/5/5 | 120 | 0 | 每周 | 每周 | ZHS | ZHS | |
| Period | N | 2010/8/13 22:38 | 0 | 2005/5/5 | 120 | 0 | 每月 | 每月 | ZHS | ZHS | |
| Period | N | 2010/8/13 22:38 | 0 | 2005/5/5 | 120 | 0 | 每季 | 每季 | ZHS | ZHS | |
| Period | Y | 2010/8/13 22:38 | 0 | 2005/5/5 | 120 | 0 | 每两周 | 每两周 | ZHS | ZHS | |
经查是 patch/6678700_ZHS/inv/patch/115/import/ZHS/invuomcl.ldt 给导入进来的。想不通为啥中文语言包要单独insert这几条数据。
删除这5条记录 delete from mtl_units_of_measure_tl where source_lang=’ZHS’
再次单独执行 INVNLINS.sql 返回：
ORA-0000: normal, successful completion 成功完成。 再次以中文环境登录，Ok了。
一、背景：
1) Demo环境
2）从 R12.1.1 升级到 R12.1.2 Patch顺利完成
3）从 R12.1.1 升级到 R12.1.2 中文语言 Patch 过程中有部分ldt 任务failue , adctrl retry多次未果，就Skip 过去了。
二、现象
IE打开R12的时候报错(http://syfdemo.ml.com:8000)：
Oracle error 6519: java.sql.SQLException: ORA-06519: 检测到活动的独立的事务处理, 已经回退 ORA-06512: 在 "APPS.FND_FUNCTION", line 2155 ORA-06512: 在 "APPS.FND_FUNCTION", line 1090 ORA-06512: 在 "APPS.FND_FUNCTION", line 1018 ORA-06512: 在 "APPS.FND_FUNCTION", line 1304 ORA-06512: 在 "APPS.FND_FUNCTION", line 1592 ORA-06512: 在 "APPS.FND_FUNCTION", line 1674 ORA-06512: 在 "APPS.FND_SESSION_MANAGEMENT", line 1321 ORA-06512: 在 "APPS.FND_AOLJ_UTIL", line 421 ORA-06512: 在 line 1 has been detected in FND_AOLJ_UTIL.is_Valid_ICX.
Servlet error: An exception occurred. The current application deployment descriptors do not allow for including it in this response. Please consult the application log for details.
解决过程：
1）使用“Oracle error 6519: java.sql.SQLException: ORA-06519: 检测到活动的独立的事务处理, 已经回退”
“ ORA-06512 在 “APPS.FND_FUNCTION”, line 2155”
“ ORA-06512: 在 line 1 has been detected in FND_AOLJ_UTIL.is_Valid_ICX”
等关键短语在google, metalink检索 能查到少量信息，也即别人也遇到这样类似的问题，但未有答案。
这一步耗时10分钟，但未有成果。
2）查看程序 FND_FUNCTION, line 2155，发现对应程序为：FND_FUNCTION.FAST_COMPILE 过程。意思是这个过程用于重新编译那些需要被编译的菜单，该过程使用了自治事务。在注释中提到，管理员可以直接在sqlplus中运行FND_FUNCTION.FAST_COMPILE;
于是在plsqldeveloper 的 command 窗口中直接运行
SQL> execute FND_FUNCTION.FAST_COMPILE;
begin FND_FUNCTION.FAST_COMPILE; end;
ORA-06519: active autonomous transaction detected and rolled back
ORA-06512: at “APPS.FND_FUNCTION”, line 2155
ORA-06512: at line 2
SQL>
结果报上述错误。
Metalink 搜索 ORA-06519: active autonomous transaction detected and rolled back
20条结果发现 有一条比较接近，因为它同时含有“get_icx_ticket” 与我IE中报出的“FND_AOLJ_UTIL.is_Valid_ICX”相关。于是没有看其他19条结果，直接看这条结果：
这条结果的标题是：APP-FND-01564: ORACLE error 6519 in get_icx_ticket [ID 1088834.1]
查看具体内容，说因为表空间不足。
3）根据 数据库初始化参数 diagnostic_dest 找到 alert.log 的位置，打开看 :
ORA-1691: unable to extend lobsegment APPLSYS.SYS_LOB0001935853C00024$$ by 16 in tablespace APPS_TS_SEED
client_id=” type=’UNKNOWN’ level=’16’
host_id=’syfdemo.ml.com’ host_addr=’192.168.1.23′ module=’FNDIRLPP’
pid=’19142′>
ORA-1653: unable to extend table APPLSYS.FND_OBJECTS by 16 in tablespace APPS_TS_SEED
client_id=” type=’UNKNOWN’ level=’16’
host_id=’syfdemo.ml.com’ host_addr=’192.168.1.23′ module=’FNDIRLPP’
pid=’19142′>
ORA-1653: unable to extend table APPLSYS.FND_OBJECTS by 16 in tablespace APPS_TS_SEED
确实是APPS_TS_SEED用完了，至少metalink指出的原因在我这里也发生了，也许不仅仅是这个原因，也许仅仅是这个原因，不管怎样，先把这个问题解决试试看:
4) 扩展APPS_TS_SEED表空间：
找到它的数据问题文件
select * from dba_data_files t where t.tablespace_name = ‘APPS_TS_SEED’
扩大其中一个数据文件，由原来的400多M 扩展到2个G:
alter database datafile ‘/d01/oracle/VIS/db/apps_st/data/reference1.dbf’ resize 2000M
5) 再次测试：
在PLSQL DEVELOPER Command窗口中运行
SQL> execute FND_FUNCTION.FAST_COMPILE;
PL/SQL procedure successfully completed
SQL>
成功。
再次在IE中打开R12, 错误消失，可正常登录。
讨论：
若把这个问题解决当作是猜题游戏（根据现象 猜测真实原因），那么本次猜题游戏能得多少分呢(满分100分制）?
自评：
a) 解决过程中第一步，完全是浪费，扣20分；
b) 解决过程中第二步，直接从20多条Metalink结果中，找到一条吻合的，运气成分太高了，虽然不错，但逻辑性不强，扣10分；
得分：100-30 = 70分
思考，这个问题，基于怎样的思维方式，可以在更准，更快的定位问题原因呢？
后续：因为前面的R12.1.2 中文语言 Patch 遇到表空间不足，有2252个ldt任务被我用adctrl skip过去了，所以虽然adpatch complete ,但打得不成功，在扩展表空间以后再打了一次R12.1.2 中文语言 Patch，发现这次的ldt任务就是针对剩下的2252个的，它自动接着上次skip的那些ldt任务开始的（之所以这么说是因为我查上一次的R12.1.2 中文语言 Patch的log发现ldt任务有3600多个，在剩余2252多个的时候因为表空间不足被skip）；这次没有报什么错误，顺利把剩余部分的ldt给打上去了。
客户：达芙妮
现象：1 并发节点文件系统满，导致并发管理器挂起
2用户删除了部分日志和输出文件，并重新启动管理器，所有管理器都正常启动，只有库存管理器actual=0, target=10
分析&解决
一、灏明（Oracle) 10日去现场看了下，发现后台库存管理器进程状态为defunct，mtl_tranasctions_interface中有大量待处理数据（从出故障到现在的所有库存事物处理），并采取了一次处理少量数据来解决问题，下面是他的脚本
——————————————–
/*******************************************************************************
date : 2007-05-08
处理者: yunfang.shang
*******************************************************************************/
select * from rcv_transactions_interface
–查接收接口中来自销售订单退货的记录(error_message是错误信息提示)
SELECT rti.processing_request_id,
rti.creation_date,
rti.transaction_date,
rti.group_id,
oeh.order_number,
rti.item_id,
item_description,
rti.unit_of_measure,
rti.quantity,
rti.source_document_code,
rti.subinventory,
oel.flow_status_code,
pie.error_message
FROM rcv_transactions_interface rti,
oe_order_headers_all oeh,
oe_order_lines_all oel,
PO_INTERFACE_ERRORS pie
WHERE rti.oe_order_header_id = oeh.header_id
AND rti.oe_order_line_id = oel.line_id
AND rti.oe_order_header_id = oel.header_id
AND rti.interface_transaction_id = pie.interface_line_id(+)
ORDER BY oeh.order_number
—
继续阅读“接收事务处理接口错误处理日志1例”
/*******************************************************************************
date : 2007-04-25
处理者: yunfang.shang
*******************************************************************************/
现象：
在 INV-〉SETUP-〉Transactions ->Interface Manager 中把Material transaction启动
Material transaction 变成有效状态
但是 Material transaction 在运行一次后又自动失效了。
由于 Material transaction 未能始终处于有效状态，所以导致很多接口数据未能被处理。
用户需要在启动Material transaction时，让并发请求处于周期运行的方式。
用户觉得比较怪。因为正常情况是启动管理器以后，管理器就应该始终处于有效状态。不需要人为的把并发请求设置为周期运行的。
分析：
查Metalink, 关键词： Material transaction inactive
所查到的都是2004年及以前的与此类似的现象，都是说要打个patch 1734240 解决此问题。
但现在是11.5.10.2版本，这个patch肯定早已经包含在某个patch set中了，故肯定不是这个问题。
物料事务处理接口日志一例
/*******************************************************************************
date : 2007-05-06
处理者: yunfang.shang
*******************************************************************************/
现象：库存事务处理接口中堆积了大量记录未被处理
现象：接口表中很多记录处理结果为Error;原因是组织层不允许负库存，而库存现有量不足，导致无法扣减库存成功
大量出库记录由此被堵塞在接口表。
处理日志：
select count(*) from MTL_TRANSACTIONS_INTERFACE
select count(*) from Mtl_Material_Transactions_Temp
–事务处理数量
SELECT
— *
–transaction_quantity
–distinct transaction_source_type_id
FROM MTL_TRANSACTIONS_INTERFACE
WHERE transaction_interface_id = 321706
AND error_code IS NOT NULL
SELECT *
–transaction_quantity
FROM Mtl_Material_Transactions_Temp where trx_source_line_id =22964
–保留
select * from mtl_demand_v a where a.demand_id = 22964
–现有量
SELECT sum(transaction_quantity)
FROM mtl_onhand_quantities moq
WHERE moq.INVENTORY_ITEM_ID = 3489
AND moq.ORGANIZATION_ID =108
AND moq.SUBINVENTORY_CODE =111215001
–物料编码
SELECT segment1
FROM mtl_system_items_b
WHERE organization_id = 108
AND inventory_item_id = 3489
— 查找错误记录的现有量
SELECT a.transaction_interface_id,
msi.segment1,
a.organization_id,
a.subinventory_code,
a.transaction_quantity,
XH_COMMON_UTL.get_onhand_qty(a.inventory_item_id,
a.organization_id,
a.subinventory_code) on_hand_qty
FROM mtl_transactions_interface a,
mtl_system_items_b msi
WHERE a.inventory_item_id = msi.inventory_item_id
and a.organization_id = msi.organization_id
and a.error_explanation IS NOT NULL
/*******************************************************************************
date : 2007-05-08
处理者: yunfang.shang
*******************************************************************************/
/*
现象： 顾问做了一张订单，在登记并完成“后台工作流程序” 后，订单及订单行关闭；
但是有一行 在AR中未找到对应的发票行（总共有6行，5行到了AR，有一行没有到AR）
*/
— 查订单行（由于订单行及发票行的attribute2 都用于存放 POS小票号，所以可以根据POS小票号来查
select * from oe_order_lines_all where attribute2 = ‘ZCXSS111202800000035’
–返回6条记录
–查发票接口
select * from RA_INTERFACE_LINES_ALL where attribute2 = ‘ZCXSS111202800000035’
–返回 0 条记录，说明已经全部被处理
–查发票行
select * from RA_CUSTOMER_TRX_LINES_ALL where attribute2 = ‘ZCXSS111202800000035’
–返回 5 条记录
–说明肯定有一条根本就没有生成到AR接口表中
— AR 行 和订单行的差异，发现没有过来的一条记录，其发票接口状态字段异常 INVOICE_INTERFACE_STATUS_CODE = NOT_ELIGIBLE
— 所以直接原因是 因为订单行不合法导致未能开票。 那么具体是什么原因呢？
— 打开 OM 行流 工作流定义 ，根据返回状态为NOT_ELIGIBLE 进行代码追踪 ；
— 从 行开票接口节点开始 OE_INVOICE_WF.INVOICE_INTERFACE->OE_Invoice_PUB.Interface_Line – >OE_Invoice_PUB.Interface_Single_Line->OE_Invoice_PUB.Line_Invoiceable
— Line_Invoiceable 这个函数是最终的可能提供详细原因的函数。看代码后发现 导致行不可开票的原因有很多种，究竟是哪一种呢？
— 启用Debug ，准备做一次调试，看具体的debug原因就可以确定了明确的不可开票原因了。
— 在用户层设置 系统配置文件 “OM： 调试级别” 把值设置为5
— 在用户层设置 系统配置文件 OM：调试日志目录” 把值设置为 /usr/tmp
— demo 环境应用服务器：
— 删除 usr/tmp/ *.dbg 文件
— 再作一张订单，登记，运行工作流后台程序 ，直到订单关闭
— 在usr/tmp 目录下去看日志文件。
— 郁闷，这里的日志文件 只是跟踪到订单界面上的操作。根本就未能跟到 Line_Invoiceable 这个函数。所以从这个日志文件也看不出什么名堂。
— 那么是否信息被debug 到 fnd_log_message 表中去了呢？ 去找了一把也没有找到。
— 再去读 oe_debug_pub 程序，也就是记录日志的那个程序包。 发现它会判断：如果从系统配置文件中获取的当前 并发请求Id 不是 -1 ，
— 并且不是在 UI模式的话则会把日志的输出文件输出到 并发程序的log中去
— 想想，虽然我们是在界面上录入，登记订单。 但是真正启动 Line_Invoiceable 这个函数 的人应该是” 工作流后台流程” 这个并发程序。
— 是不是log信息被记录到这个” 工作流后台流程” 的log中了呢？
— 看刚才运行的 ” 工作流后台流程” 的log ，果来是这样。其中有句log 应该是 Line_Invoiceable 输出的
— 日志 ENTERING LINE_INVOICEABLE 应该是进入 Line_Invoiceable 函数的 标志性的日志语句
/*
ENTERING LINE_INVOICEABLE
。。。。。。
ITEM NOT INVOICEABLE ( 2 )
l_freight_count: 0
Handling non-invoiceable lines with no freight or automatic numbering*/
— 根据错误日志 “Handling non-invoiceable lines with no freight or automatic numbering” 到OE_Invoice_PUB 包中查找，，发现这个错误是由
— Interface_Line 函数抛出的，而且这句话是在调用line_invoiceabel 返回结果 false 并且
— 在 FND_PROFILE.VALUE(‘WSH_INVOICE_NUMBERING_METHOD’) = ‘A’ 的情况下设置的。
— ITEM NOT INVOICEABLE(2) 是 Line_Invoiceable 函数抛出的日志，在程序中有如下判断：
IF (l_invoiceable_item_flag = ‘N’) OR
(l_invoice_enabled_flag = ‘N’) OR
(p_line_rec.item_type_code = ‘SERVICE’ AND l_serviceable_product_flag = ‘N’) THEN
IF l_debug_level > 0 THEN
oe_debug_pub.add( ‘ITEM NOT INVOICEABLE ( 2 ) ‘ , 1 ) ;
END IF;
RETURN FALSE;
END IF;
— 而l_invoiceable_item_flag 和 l_invoice_enabled_flag 都是从物料信息表获取的：
SELECT INVOICEABLE_ITEM_FLAG, INVOICE_ENABLED_FLAG
INTO l_invoiceable_item_flag, l_invoice_enabled_flag
FROM mtl_system_items
WHERE inventory_item_id = p_line_rec.inventory_item_id
AND organization_id = nvl(p_line_rec.ship_from_org_id, oe_sys_parameters.value(‘MASTER_ORGANIZATION_ID’, p_line_rec.org_id));
— 可见本次问题发生的真正原因就找到了： 就是物料属性设置不对，不可开票阿！！！。
/*******************************************************************************
date : 2007-07-06
处理者: yunfang.shang
*******************************************************************************/
/*
现象： 现在有几张订单传到库存了之后传不到应收接口了
订单号：1000002895
*/
select * from oe_order_headers_all where order_number = ‘1000002895’
— 查订单的 POS小票号
select oel.attribute2
from oe_order_lines_all oel, oe_order_headers_all oeh
where oeh.header_id = oel.header_id
and oeh. order_number = ‘1000002895’
–查发票接口
select * from RA_INTERFACE_LINES_ALL where attribute2 in (select oel.attribute2
from oe_order_lines_all oel, oe_order_headers_all oeh
where oeh.header_id = oel.header_id
and oeh. order_number = ‘1000002895’)
–返回 0 条记录，说明已经全部被处理
–查发票行
select * from RA_CUSTOMER_TRX_LINES_ALL where attribute2 in (select oel.attribute2
from oe_order_lines_all oel, oe_order_headers_all oeh
where oeh.header_id = oel.header_id
and oeh. order_number = ‘1000002895’)
–返回 0条记录
–说明根本就没有生成到AR接口表中
–查订单行的开票状态字段
select oel.INVOICE_INTERFACE_STATUS_CODE,oel.*,oel.lock_control
from oe_order_lines_all oel, oe_order_headers_all oeh
where oeh.header_id = oel.header_id
and oeh. order_number = ‘1000002895’
— INVOICE_INTERFACE_STATUS_CODE是空的 NULL, 正常情况下开票完成的应该是 YES
–从界面查该订单，订单头 已登记 状态；订单行 实施 状态。 从菜单 工具/工作流状态 看到
— 开票接口出现例外。 看错误信息是表空间扩展问题。
–查数据库日志，表空间不足。 DBA扩展表空间后。
— 客户方 IT 人员 在出错的订单行界面按右键 选择 重试出错的活动。就 retry 过去了。
–但是这种记录很多，有700多条，如果手工retry的话，工作量很大。用户希望能用程序retry.
–首先找出这些记录
select count(1) from
(
select oeh.order_number,oel.INVOICE_INTERFACE_STATUS_CODE,oel.*,oel.lock_control
from oe_order_lines_all oel, oe_order_headers_all oeh
where oeh.header_id = oel.header_id
and oel.INVOICE_INTERFACE_STATUS_CODE is null and oel.attribute2 is not null and line_category_code =’ORDER’
and oel.flow_status_code =’FULFILLED’
)
–707 条
— 获取其中一条的 activity , item_key 就是line_id
SELECT was.item_type,
was.item_key,
wpa.process_name || ‘:’ || wpa.instance_label activity,
was.activity_status,
was.activity_result_code,
was.assigned_user,
was.notification_id,
was.begin_date,
pro.display_name process_name,
act.display_name activity_name
FROM wf_item_activity_statuses was,
wf_process_activities wpa,
wf_activities_vl pro,
wf_activities_vl act,
wf_items wi
WHERE was.process_activity = wpa.instance_id
AND wpa.process_item_type = pro.item_type
AND wpa.process_name = pro.NAME
AND wpa.process_version = pro.version
AND wpa.activity_item_type = act.item_type
AND wpa.activity_name = act.NAME
AND was.item_type = wi.item_type
AND was.item_key = wi.item_key
AND wi.begin_date >= act.begin_date
AND wi.begin_date < nvl(act.end_date, wi.begin_date + 1)
AND was.item_type = ‘OEOL’
AND was.item_key = ‘106458’
AND was.end_date IS NULL
AND was.activity_status =’ERROR’ ;
— 执行retry 比如单个记录的retry :
BEGIN
— 初始化，根据实际环境修改，这样可以获得环境变量，主要是Org_id，一般不需要
fnd_global.apps_initialize(user_id => 1111,
resp_id => 50260,
resp_appl_id => 660);
— Call the procedure
wf_engine.handleerror(itemtype => ‘OEOL’,
itemkey => ‘106457’,
activity => ‘LINE_DEF_INVOICE_INTERFACE_SUB:INVOICE_INTERFACE’,
command => wf_engine.eng_retry);
END;
–成功执行，再去界面看，行已经Close了。
/********************************************************************************
— 批量Retry 执行 这些出错的节点：
********************************************************************************/
begin
— 注意把当前Sql窗口中的 “输出” tab页中的缓冲区大小设置大一点，至少 100000
— 初始化
fnd_global.apps_initialize(user_id => 1111, resp_id => 50260,
resp_appl_id => 660);
for c1 in (select oel.line_id
from oe_order_lines_all oel
where oel.INVOICE_INTERFACE_STATUS_CODE is null
and oel.attribute2 is not null
and line_category_code = ‘ORDER’
and oel.flow_status_code = ‘FULFILLED’) loop
for c2 in (SELECT was.item_type, was.item_key,
wpa.process_name || ‘:’ || wpa.instance_label activity,
was.activity_status, was.activity_result_code,
was.assigned_user, was.notification_id,
was.begin_date, pro.display_name process_name,
act.display_name activity_name
FROM wf_item_activity_statuses was,
wf_process_activities wpa, wf_activities_vl pro,
wf_activities_vl act, wf_items wi
WHERE was.process_activity = wpa.instance_id
AND wpa.process_item_type = pro.item_type
AND wpa.process_name = pro.NAME
AND wpa.process_version = pro.version
AND wpa.activity_item_type = act.item_type
AND wpa.activity_name = act.NAME
AND was.item_type = wi.item_type
AND was.item_key = wi.item_key
AND wi.begin_date >= act.begin_date
AND wi.begin_date < nvl(act.end_date, wi.begin_date + 1)
AND was.item_type = ‘OEOL’
AND was.item_key = c1.line_id
AND was.end_date IS NULL
AND was.activity_status = ‘ERROR’) loop
— Call the procedure
wf_engine.handleerror(itemtype => ‘OEOL’, itemkey => c1.line_id,
activity => c2.activity,
command => wf_engine.eng_retry);
dbms_output.put_line(‘c.line_id=’ || to_char(c1.line_id) || ‘ c2.activity=’ || c2.activity || ‘ be processed’ );
exit ;
end loop;
end loop;
–commit;
end;
/********************************************************************************
— 成功执行完毕后检查
********************************************************************************/
–再次检查
select oeh.order_number,oel.INVOICE_INTERFACE_STATUS_CODE,oel.*,oel.lock_control
from oe_order_lines_all oel, oe_order_headers_all oeh
where oeh.header_id = oel.header_id
and oel.INVOICE_INTERFACE_STATUS_CODE is null and oel.attribute2 is not null and line_category_code =’ORDER’
and oel.flow_status_code =’FULFILLED’
— 返回0条记录。 说明全部被处理了。
— 自动开票程序运行后 再运行
— 下面这句话可以证明 程序处理过的订单行均已开票成功
select b.order_number, b.line_id, a.*
from RA_CUSTOMER_TRX_LINES_ALL a,
(select oeh.order_number, oel.INVOICE_INTERFACE_STATUS_CODE,
oel.line_id, oel.lock_control
from oe_order_lines_all oel, oe_order_headers_all oeh
where oeh.header_id = oel.header_id
and oel.last_update_date between
to_date(‘2007-7-6 23:24:00’, ‘YYYY-MM-DD HH24:MI:SS’) and
to_date(‘2007-7-6 23:27:00’, ‘YYYY-MM-DD HH24:MI:SS’)) b
where a.interface_line_attribute6 = to_char(b.line_id)
— 被处理的订单行是706条。对应的发票行也是706条。全部开票成功。
/***********************************************************************************************************
概述：
问题： AR 会计分录传到总帐接口以后，用户在总帐中，没有导入这批日记帐之前，利用删除接口的程序把接口中的某一批数据给删除了。
导致一批凭证丢失。
当时场景是这样的：
1）客户的财务人员提交AR的过账程序，确实勾选了运行日记帐导入。
但是由于某些原因导致：AR传总帐接口这一步是正常完成了。但是日记帐导入这一步没有正常完成。
2）客户看到并发请求列表中有个红色的出错请求，就以为整个AR过账过程都错了，当然在总帐也没有查到相关日记帐。
于是就再次运行AR过账程序，但是因为原来的数据已经被打上“已过账”标记，所以是过不去了。
3）客户就以为是接口表中有错误数据所以导致不能再过账的（她的这个想法当然是错误的，但当时她确实就是这么以为的）
于是她就删除接口的程序把接口中的某一批数据给删除了。
4）这下可就完蛋了。接口中也没数据了，系统又不能再过账。到了这一步，客户就无能为力了。
***********************************************************************************************************/
怎么办？
/***********************************************************************************************************
1 根据用户 提交的 删除日记帐导入来源 的请求 来知道用户删除了哪一批数据
***********************************************************************************************************/
— 运行 总帐的 删除 接口程序 输入参数 request_id ,group_id
— 如果不输入group_id 则，group_id 会被默认设置为-1 ，也就无法删除
— 并发请求 名称 = 删除日记帐导入来源
— 并发请求ID = 550089
— 请求完成后查 接口表
— 查德当时的运行参数：Receivables, 549291, 4427, 1
/*
GLLDEL module: 删除日记帐导入来源
+—————————————————————————+
当前的系统时间为 06-06-2007 13:58:17
+—————————————————————————+
>> glldel() 06-06-2007 13:58:17
SHRD0084: 从 GL_INTERFACE 中删除
SHRD0119: 从 GL_INTERFACE 中删除 147 记录。
SHRD0019: GLLDEL – 成功执行后退出处理。
*/
–查接口表
select * from gl.gl_interface where group_id = 4427
— 0 行
–确实被删除
select * from gl.gl_interface
–1 POSTED -99 2005-4-30 Y 2005-4-30 10:28:31 -9999 A @#$% do not delete this record
–只有一条 OU屏蔽 而保留的记录
–发现数据确实被删除了。
–再查 AR_POSTING_CONTROL 表
select * from AR_POSTING_CONTROL where posting_control_id = 4427
–状态为Done 说明 AR传总帐接口是成功完成的
–查找被删除的记录
select * from ar_adjustments_all where posting_control_id = 4427
— 0 行
select * from ar_misc_cash_distributions_all where posting_control_id = 4427
— 0 行
select * from ar_receivable_applications_all where posting_control_id = 4427
— 61 行
— 备份到Excel 文件
select * from ar_cash_receipt_history_all where posting_control_id = 4427
— 0 行
select * from RA_CUST_TRX_LINE_GL_DIST_ALL where posting_control_id = 4427
— 83行
— 备份到Excel文件
select * from ar_transaction_history_all where posting_control_id = 4427
–0行
–select * from AR_PAYMENT_SCHEDULES_ALL where posting_control_id = 4427
select * from AR_CASH_BASIS_DISTS_ALL where posting_control_id = 4427
— 0 行
–select * from AR_DISTRIBUTIONS_ALL where posting_control_id = 4427
–select * from AR_DISTRIBUTION_SETS_ALL where posting_control_id = 4427
–select * from AR_DISTRIBUTION_SET_LINES_ALL where posting_control_id = 4427
–select * from RA_INTERFACE_DISTRIBUTIONS_ALL where posting_control_id = 4427
/***********************************************************************************************************
2 使用 ARGCGP 来对这批数据进行 unpost 操作
***********************************************************************************************************/
— AR过帐标志重置程序 ：ARGCGP
— Note:219307.1 对此程序的使用有明确的说明
–1 确保受影响的纪录的AR会计期是打开的
–2 确保受影响的记录未过到总帐
–查总帐日记帐是否存在来自AR的Posting_control_id =8000的纪录
select jb.name,jh.*,jl.*
from gl_je_lines jl, gl_je_headers jh, gl_je_batches jb
where jl.je_header_id = jh.je_header_id
and jh.je_batch_id = jb.je_batch_id
and jb.name like ‘%4427%’
select jb.name
from gl_je_lines jl, gl_je_headers jh, gl_je_batches jb
where jl.je_header_id = jh.je_header_id
and jh.je_batch_id = jb.je_batch_id
and jb.name like ‘%4427%’
group by jb.name
— 发现没有来自 应收的 含 4427的批
–3 确保当前没有正在运行日记帐导入
–4 再次检查Posting_Control_id 的正确性，否则可能导致重复过帐。
— 按照 Note:219307.1 定义了并发程序 ： ARGCGP_SD
–名称：SD AR Unposting
–提交了请求；
–参数 1, 4427, Y, N, N 4427
–请求运行出错
–检查发现 ar_receivable_applications_all 已经被重置。
–RA_CUST_TRX_LINE_GL_DIST_ALL 没有改变。
/*日志如下
=======================================
Parameters passed in:
Set of Books Id: 1
Posting Control Id: 4427
Reset GL Posted Date: Y
Delete from GL_INTERFACE: N
Debug Mode On: Y
========================================
当前的系统时间为 07-06-2007 16:23:37
*****************************************************
***** argurs *****
BEGIN TO RESET THE GL_POSTED_DATE
-> POSTING_CONTROL_ID = 4427
Resetting ar_adjustments…
Committed the reset – 0 lines
Resetting ar_misc_cash_distributions…
Committed the reset – 0 lines
Resetting ar_receivable_applications…
Committed the reset – 61 lines
Resetting ar_cash_receipt_history…
Committed the reset – 0 lines
Committed the reset – 0 lines
Resetting ra_cust_trx_line_gl_dist…
Oracle error in function ‘argurs’
AR-ARGLTP: -20001 ORA-20001: 您无法删除已过帐记录。
ORA-06512: 在”APPS.RA_CU
AR-ARGCGP: Error from argurs
========================================
| Cannot delete records from gl_interface.
| Please delete records from gl_interface with group id of 4427
| DO NOT submit any posting program until these records are deleted.
=======================================*/
— 到界面查看 ，发现 被重置的收款已经变成“未核销状态”
— 从备份的Excel文件中获取 第一条记录的 receivable_application_id ，检查这条记录
select * from ar_receivable_applications_all where receivable_application_id = 178374
— 把重置后的记录与重置前的记录相比较：发现 ：重置的动作在于：
–就某一条AR中的会计分录而言：系统的这个重置程序 只是把POSTING_CONTROL_ID 改成 -3 并把GL_POSTED_DATE 设置为空
/***********************************************************************************************************
3 把重置成功的部分 再一次传总帐
***********************************************************************************************************/
— 用户再次运行 AR ->传总帐的程序
— 传输程序成功完成
— 日记帐导入失败
–日志的关键部分
— request_id = 551614
/*Error in: gllccl
Function return status: 0
Function Err Message: failure to get cross currency account
Function warning number: -1
*****************************************************
sqlcaid: sqlabc: 0 sqlcode: 1403 sqlerrml: 27
sqlerrmc:
ORA-01403: 未找到数据
sqlerrp: sqlerrd: 0 2 0 0 0 538976288
sqlwarn: sqltext: */
— 问 赵丰干
–答：总账/设置/账户/暂记 定义类别为“交叉币种”的账户 ； 这里没有设置暂记帐户
— 也就是说 要添加一条 来源=应收。类别=交叉币种 的帐户
— 相关讨论如下：
–=========================================
/*商云方 说:
老赵，汇兑损益 在AR 作不同币种的收款核销发票的时候 产不产生？也就是说在AR中是否要产生汇兑损益的会计分录？
赵丰干 说:
产生
赵丰干 说:
只要在AR中作跨币种收款核销，这个科目是必须的，无论是否有汇差产生
商云方 说:
哦，那么为什么在总帐导入日记帐的时候才报错呢？ 在AR做核销的时候怎么不报错？
赵丰干 说:
因为GL中的凭证都是单币种的，因此跨币种核销业务会产生两张凭证，这个科目就是用来作中转的
赵丰干 说:
如果不设置的话，总账凭证就无法生成*/
恰好,老马也在县,就顺便跟老马也讨论了一下:
–=======================
/*商云方 说:
他们财务经理说不想做交叉币种核销，要求撤销核销。撤销港币发票。重新作人民币发票，然后再核销。
ma 说:
撤销核销不代表原来的交叉核销不存在了，只是系统产生出两笔正负相抵的交叉核销而已
商云方 说:
那怎么办呢？
ma 说:
那就追设一下，让凭证导入吗
商云方 说:
也就是说正负相抵消得交叉核销还是会传到总帐接口表吗？
ma 说:
会的
ma 说:
正负相抵不等于没有
商云方 说:
那要这么说，就只能在总帐中去设置那个暂挂帐户楼。
ma 说:
如果是一并导入的话，有可能可以导入的。
商云方 说:
准不准阿？
商云方 说:
老马，我们现在已经取消了人民币收款对港币发票的核销。
ma 说:
如正凭证：借：应收款未核销（RMB） 贷：应收款（HKD）；这个凭证RMB和HKD的借贷都不平；再产生负凭证后：借：应收款（HKD） 贷：应收款未核销（RMB），那么导入的凭证会是：
商云方 说:
那么下一步，如何把那个港币发票作废掉？
商云方 说:
怎么操作？
ma 说:
借：应收款（HKD） 贷：应收款（HKD）
ma 说:
借：应收款未核销（RMB） 贷：应收款未核销（RMB）
ma 说:
你可以再传总帐，然后一起导
ma 说:
要求核销和取消核销的日期一定要一样
商云方 说:
那肯定不一样，
商云方 说:
核销是前几天进行的。取消核销时今天进行的。
ma 说:
或设上暂挂账户和选项，导入再取消此选项也可以
ma 说:
你在现场吗
商云方 说:
对，在
把问题给用户方反映了.
— 用户方 财务部经过讨论后 认为 目前还没想好要进行交叉币种核销的业务。
— 用户方决定 把 不同币种核销取消，然后对 外币发票 作贷项操作，然后再重做人民币发票，再核销。再传总帐
/***********************************************************************************************************
4 把刚才重置未成功的部分 再一次重置
***********************************************************************************************************/
— 由于刚才 ARGCGP_SD 只是重置了 ar_receivable_applications_all 表中的记录 ，而且经过再一次的调用AR->GL 的传输程序后
— ar_receivable_applications_all 表中被重置的记录的 posting_control_id已经变成了另一个值.
— 现在需要想再次运行 ARGCGP_SD 来重置 RA_CUST_TRX_LINE_GL_DIST_ALL 中的记录
— 运行 SD AR Unposting
–参数 1, 4427, Y, N, N 4427
–log
/*===============================================================
***************************************************************
BEGIN TO RESET THE GL_POSTED_DATE
-> POSTING_CONTROL_ID = 4427
Resetting ar_adjustments…
Committed the reset – 0 lines
Resetting ar_misc_cash_distributions…
Committed the reset – 0 lines
Resetting ar_receivable_applications…
Committed the reset – 0 lines
Resetting ar_cash_receipt_history…
Committed the reset – 0 lines
Committed the reset – 0 lines
Resetting ra_cust_trx_line_gl_dist…
Oracle error in function ‘argurs’
AR-ARGLTP: -20001 ORA-20001: 您无法删除已过帐记录。
ORA-06512: 在”APPS.RA_CU
AR-ARGCGP: Error from argurs
===============================================================
| Cannot delete records from gl_interface.
| Please delete records from gl_interface with group id of 4427
| DO NOT submit any posting program until these records are deleted.
===============================================================
*/
— 系统标准程序重置未成功 ，手工重置
begin
fnd_global.APPS_INITIALIZE(user_id =>1059 ,resp_id =>50330 ,resp_appl_id => 222);
update RA_CUST_TRX_LINE_GL_DIST_ALL
set GL_POSTED_DATE = NULL, POSTING_CONTROL_ID = -3
where posting_control_id = 4427;
end ;
— 上述过程执行失败，现象和并发程序执行失败是一样的
— 出错的时候会跳出 错误堆栈 ，根据错误堆栈，看源代码 知道有个Bug与此有关
— Metlink Note:272844.1 对此有说明
–措施：
— 暂时失效 触发器：ra_cust_trx_line_gl_dist_bri
— 重置请求运行完后再 启用
— 再次运行– 运行 SD AR Unposting
–参数 1, 4427, Y, N, N 4427
— 成功完成
–log
/*===============================================================
Parameters passed in:
Set of Books Id: 1
Posting Control Id: 4427
Reset GL Posted Date: Y
Delete from GL_INTERFACE: N
Debug Mode On: Y
===============================================================
当前的系统时间为 07-06-2007 18:50:05
***************************************************************
***** argurs *****
BEGIN TO RESET THE GL_POSTED_DATE
-> POSTING_CONTROL_ID = 4427
Resetting ar_adjustments…
Committed the reset – 0 lines
Resetting ar_misc_cash_distributions…
Committed the reset – 0 lines
Resetting ar_receivable_applications…
Committed the reset – 0 lines
Resetting ar_cash_receipt_history…
Committed the reset – 0 lines
Committed the reset – 0 lines
Resetting ra_cust_trx_line_gl_dist…
Committed the reset – 83 lines
Resetting ar_transaction_history…
Committed the reset – 0 lines
SUCCESSFUL.
****************************************************************/
— 到界面查发票的会计方法，已经变成 “未过帐” 状态。
/***********************************************************************************************************
5 用户操作
***********************************************************************************************************/
— 用户取消了收款与发票的核销
— 用户对此发票 作贷项操作
— 用户再做人民币发票
— 人民币收款 核销 人民币发票
— 在总帐设置暂挂帐户
–总账/设置/账户/暂记 定义类别为“交叉币种”的账户
— 来源=应收款管理系统
— 类别 = 交叉币种
— 帐户 = 0003.00000.7201030101.00000000.000000.000000.000.000000.00
— 再次运行 AR->GL 的过帐程序
— 用户报告 一切OK (暂记帐户是有内容的)
/***********************************************************************************************************
6 总结
***********************************************************************************************************/
解决方法: 利用系统提供的隐藏并发程序 ARGCGP 对这一批数据进行AR反过帐. 然后再重新过帐. 因为交叉币种核销问题，添加了暂记帐户。
注意点: ARGCGP 反过帐时, 由于ra_cust_trx_line_gl_dist_all 上有个数据库触发器会阻止ARGCGP 对表的修改,所以会导致失败.
解决方法有两种
1是 临时实效此触发器. 待 ARGCGP运行完以后再恢复生效.
2 Oracle 说这是一个Bug, 可以打个patch 解决。打patch以后ARGCGP 就不会出现运行失败的情况了。
我选择的是方法1，对于临时解决问题而言，比较简单。因为毕竟在很少的情况下用户需要进行反过帐操作。
采购组织接收选项清算帐户公司段设置错误，已经产生相关凭证，并且已经传总帐，要求做DataFix
===================
Issue 1 DataFix_RCV_Clearing_Account_Change_For_CAN
===================
现象
现象1：加拿大公司的总帐日记帐界面：接收清算帐户，日记帐不平，无法过帐。如下图:
现象2：加拿大库存组织上CC1上的，清算帐户的公司段设置错误,应该设置成801，实际设置成了801,如下图：
事实1： ORG_ID=801是美国公司，ORG_ID=802是加拿大公司，加拿大只有一个库存组织：CC1
事实2： 加拿大采购模块的相关凭证已经Transfer到总帐日记帐（已经完成日记帐导入，但尚未过帐）
事实3：加拿大和美国使用不同的帐套。
事实4：子模块到总帐是汇总传的，目前在总帐看到两笔出错的不能过帐的日记帐存在此问题。Journal_head_id 分别是：25418 ，25337 事实5：此前曾发生过CC1库存组织接收选项上的接收帐户设置错误的情况。也是错误的设置成801
事实6：接收帐户与清算帐户的科目是一样的。
事实7：接收选项上的Clearing Account在11.5.10开始出现，在11.5.9版本上没有。
事实8：加拿大启用了多币种，美元为本位币，加元帐套为报告帐套，帐套ID分别为1002(USD) 和 1003(CAD)
分析:
受影响的业务：
1) 当采购组织与接收组织不一致时，会使用到此帐户。
2) 使用Drop-Ship，其接收帐户使用的也是Clearing Account. 而加拿大使用的全部是Drop-Ship.
解决方法：
1) 在后台更改CC1采购接收组织的Clearing Account 的公司段为：802 ;
2) 更改子模块（采购模块和库存模块）的所有错误的凭证
3) 更改总帐中（接口和日记帐）所有错误的凭证
4) 如果存在相关汇总帐户，再更新相关汇总帐户。
分析SQL:
1 获取801.1244010000.000000.000.00000000 的CCID Select code_combination_id From gl_code_combinations Where segment1 = '801' And segment2 = '1244010000' And segment3 = '000000' And segment4 = '000' And segment5 = '00000000' #返回：1051 2获取802.1244010000.000000.000.00000000 的CCID Select code_combination_id From gl_code_combinations Where segment1 = '802' And segment2 = '1244010000' And segment3 = '000000' And segment4 = '000' And segment5 = '00000000' #返回：2316 获取 科目= '1244010000' 的所有帐户 Select code_combination_id From gl_code_combinations And segment2 = '1244010000' #返回： 2316 1051 说明该科目相关的帐户只有两个明细帐户，无汇总帐户。 3 获取加拿大帐套的ID Select set_of_books_id From gl_sets_of_books Where Name = 'GiTi Canada Set of Books' #返回1002 4 获取帐户错误的日记帐头 Select Distinct gl.je_header_id From gl_je_lines gl, gl_je_headers gh Where gl.je_header_id = gh.je_header_id And gh.set_of_books_id = 1002 And gl.code_combination_id = 1051; #返回两笔： 25418 25337 5 获取加拿大OU的org_id Select organization_id from hr_operating_units where Name =’某客户(Canada),LTD. #返回127 6 获取CC1的组织ID Select organization_id From mtl_parameters Where organization_code = 'CC1' #返回：126 6 获取库存模块错误的会计分录的所有事务来源类型 SELECT DISTINCT mta.transaction_source_type_id FROM inv.mtl_transaction_accounts mta WHERE mta.organization_id = 126 AND mta.reference_account = 1051 #返回：1 |
相关检查：
--rcv_accounting_events Select Count(1) From po.rcv_accounting_events a Where a.org_id = 127 And a.debit_account_id = 1051; 返回：18 --rcv_receiving_sub_ledger Select Count(1) From rcv_receiving_sub_ledger a Where a.set_of_books_id = 1002 And a.code_combination_id = 1051; 返回：18 Select Count(1) From rcv_receiving_sub_ledger a Where a.set_of_books_id = 1003 And a.code_combination_id = 1051; 返回：0 -- mtl_transaction_accounts Select Count(1) From inv.mtl_transaction_accounts mta Where mta.organization_id = 126 And mta.reference_account = 1051 And mta.transaction_source_type_id = 1; 返回：18 -- gl_interface Select Count(1) From gl.gl_interface gi Where gi.code_combination_id = 1051 And gi.set_of_books_id = 1002; 返回：0 Select Count(1) From gl.gl_interface gi Where gi.code_combination_id = 1051 And gi.set_of_books_id = 1003; 返回：18 --gl_je_lines Select Distinct gl.je_header_id From gl_je_lines gl, gl_je_headers gh Where gl.je_header_id = gh.je_header_id And gh.set_of_books_id = 1002 And gl.code_combination_id = 1051; 返回： 25337 25418 Select Distinct gl.je_header_id From gl_je_lines gl, gl_je_headers gh Where gl.je_header_id = gh.je_header_id And gh.set_of_books_id = 1003 And gl.code_combination_id = 1051; 返回： 无记录 |
执行更新脚本：
BEGIN -- update rcv_parameters Update po.rcv_parameters p Set p.CLEARING_ACCOUNT_ID = 2316 Where p.organization_id = 126; --update rcv_accounting_events Update po.rcv_accounting_events a Set a.debit_account_id = 2316 Where a.org_id = 127 And a.debit_account_id = 1051; --update rcv_receiving_sub_ledger Update rcv_receiving_sub_ledger a Set a.code_combination_id = 2316 Where a.set_of_books_id = 1002 And a.code_combination_id = 1051; -- Update Inv trnasactions account Update inv.mtl_transaction_accounts mta Set mta.reference_account = 2316 Where mta.organization_id = 126 And mta.reference_account = 1051 And mta.transaction_source_type_id = 1; -- update gl_interface Update gl.gl_interface gi Set gi.code_combination_id = 2316 Where gi.code_combination_id = 1051 And gi.set_of_books_id = 1002; Update gl.gl_interface gi Set gi.code_combination_id = 2316 Where gi.code_combination_id = 1051 And gi.set_of_books_id = 1003; --update gl_je_lines for head 25418 and 25337 Update gl.gl_je_lines a Set a.code_combination_id = 2316 Where a.je_header_id = 25418 And a.code_combination_id = 1051; Update gl.gl_je_lines a Set a.code_combination_id = 2316 Where a.je_header_id = 25337 And a.code_combination_id = 1051; End; |
RAC环境的死锁案例一
环境: linxu 64 ,Oracle 10g ,RAC
现象: 用户报告现象:
费用审批时与通讯服务器出现拥堵的现象描述：
条件：
（1）分公司财务正在进行费用申请单的审核；
（2）通讯服务器正在进行门店费用申请单的导入；
出现的状况：
（1）。分公司费用申请单的审核一直出现漏斗现象；
（2）。通讯服务导入进程出现死循环现象，必须手工删除进程，删除以后，分公司费用审批才能正常；
（3）问题产生时，DBA那里发现有一个SQL语句一直在运转
现象: DBA报告现象:
经查数据库日志发现，由于应用程序问题，使数据库死锁发生,从而导致数据库响应时间很长。数据库做了相关解锁处理后，数据库恢复正常,数据库alert.log报如下信息:
Oracle死锁问题小结
Oracle 有三种常见的死锁:
1)ORA-60, enqueue deadlocks;
2)ORA-4020, library cache deadlocks;
3)Deadlocks in RAC
一、ORA-60, enqueue deadlocks
这种死锁很容易重现，按照如下步骤操作：
In sessionA, update tb set col = ‘x’ where pk = ‘aa’
In sessionB, update tb set col = ‘x’ where pk = ‘bb’
In sessionA, update tb set col = ‘x’ where pk = ‘bb’
In sessionB, update tb set col = ‘x’ where pk = ‘aa’
首先谈一下BPEL和WSDL(Web Service Design Language)的区别，WSDL只是定义接口参数，不会定义如何实现接口，而BPEL不仅有自己的接口定义（也是一个WSDL文件，包括输入参数、方法操作名、返回参数），BPEL会定义如何调用其他服务的接口来实现自己的接口。简单地说，BPEL通过流程编程将各种接口组合在一起，其目的在于提供一个“集成了各种接口”的接口。
BPEL扩展了WSDL以便以抽象方式提供和使用Web服务。这样可以发挥WSDL的重要长处之一，即能够将合成时所需的抽象消息和端口信息与调用时所需的物理绑定和地址详细信息分离。
WSDL中的XML语义：
1. Types指定在后面的Message中需要的类型。
2. Message可以理解为函数中的参数，只不过如果一个函数如果有多个参数的时候应该把这些参数定义到一个Message中而不能定义为多个Message。
3. ProtTypes就是一个服务接口，定制在你的服务中应该包含哪些操作。
4. Operations指的是操作，也就是对应每个接口中的函数名称，每一个Operations都可以有input,output,fault等，这些参数能够来自于Message。
5. Bindings定义通讯方式，每一个PortType对应一个Binding，然后在Binding中进一步细化设置每一个操作，进而每一个input,output,fault的传出方式，编码方式等。
6. Service就是将binding与对应的地址相关联，这样就知道什么地址上的服务能够做哪些事了。
EBS打Patch通用步骤
检查已安装模块版本：
SELECT app.application_short_name, app.application_name, pi.patch_level
FROM fnd_product_installations pi, fnd_application_vl app
WHERE app.application_id = pi.application_id
检查已安装Patch：
SELECT * FROM ad_applied_patches WHERE patch_name = ‘2451368’。
从Metalink找到需要的Patch，然后
0. 阅读Read readme document，看有没有条件，下载，用Unzip解压
1. applmgr用户登录操作系统
2. 设置环境变量（ $APPL_TOP/APPSORA.env）
3. 停应用 adstpall.sh （至少要停并发服务器），数据库和监听保持启动状态
4. 用adadmin Enable Maintenance Mode
5. 之后，运行adpatch命令，从cxxx.drv开始打，然后是dxxx.drv，gxxx.drv
6. 用adadmin Disable Maintenance Mode
7. 启动应用 adstrall.sh