ZT:深度分析数据库的热点块问题

热点块的定义

数据库的热点块,从简单了讲,就是极短的时间内对少量数据块进行了过于频繁的访问。定义看起来总是很简单的,但实际在数据库中,我们要去观察或者确定热点 块的问题,却不是那么简单了。要深刻地理解数据库是怎么通过一些数据特征来表示热点块的,我们需要了解一些数据库在这方面处理机制的特性。

数据缓冲区的结构

我们都知道,当查询开始的时候,进程首先去数据缓冲区中查找是否存在查询所需要的数据块,如果没有,就去磁盘上把数据块读到内存中来。在这个过程中,涉及 到数据缓冲区中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

EBS R12 Demo 虚拟机 使用Readme

/*
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))

win7 使用EBS R12的虚拟机时依赖主机的网卡状态的问题

现象:主机不连网的情况下,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方式的网络在主机网卡断开的情况下使用正常)

EBS R12 Demo 瘦身

Creation Time: 2011-03-05

LastUpdate Date: 2011-03-05

Author: 商云方

—————————————————————————————-

EBS R12 Demo版安装后有236G(linux显示这么大,那么在windows下需要创建约260G 左右的虚拟硬盘),尝试进行瘦身操作,稍微压缩掉一些空间占用。

image

一 、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

image

image

这个并发程序实际就是删除 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) 总帐模块的数据清理

Consolidation Audit Data:当您在审核模式运行巩固Consolidation,总帐模块将维护一个总帐的综合审计报告,未映射的子账户报告,以及失效的父帐户报告的审计线索。在运行这些报告后,您可以清除GL_CONSOLIDATION_AUDIT表中的支持源数据

image

select count(*) from GL_CONSOLIDATION_AUDIT  , 0 条记录

–GL_CONSOLIDATION_AUDIT 表碎片整理

image

由于该表空间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

image

 

image

image

点【Submit Purge】提交请求,进行删除:

image

–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:

image

–进行Order表碎片整理

alter table ONT.OE_ORDER_LINES_ALL shrink space;
alter table ONT.OE_ORDER_HEADERS_ALL shrink space;

–整理后:FreeMB=1879;  释放了11M空间;

image

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 表的碎片整理

整理前:

image

image

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;

整理后:没啥变化,看来原来就没啥碎片;

image

在订单清除程序中,还有一些跟订单相关的表中数据也会被清除,但估计数据量较小,也没啥碎片。此处略,想了解还有哪些表中的数据被清除可查看OEXPURGE这个package;

 

总结:本次销售订单清除了2500多条已经Closed的记录,碎片整理后节省11M空间;

如果想进一步清除,就要把系统中现有的可以关闭的销售订单都关闭掉,然后才能进一步清除。

 

=============

报价单清除:

生成puge set:

image

只有一条可清除:

image

submit purge , 成功puge了一条记录:

image

 

 

 

 

2.2.n) OM模块清除导入的信贷风险记录

image

此程序实际是删除  OE_CREDIT_SUMMARIES  表中balance_type =18的记录,目前不存在这样的记录。

 

2.2.n) OM模块清除订单处理过程中的历史消息

image

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;

整理前:

image

整理后:

image

释放了3M空间;

 

 

2.2.n) Shipping模块清除例外日志信息

image

先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;

image

整理后 FreeMB 从1881变成1882,节省了1M空间;

 

 

2.2.n) INV模块清除 Transaction(逐个切换一次库存组织运行一次)

image

此程序删除已经关闭的库存会计期的如下表中的记录:

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;

image

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空间;

image

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

image

MTL_TRANSACTION_ACCOUNTS  整理后节省了2496-2184=312M空间;

 

2.2.n) INV模块清除标准成本历史记录

image

 

此程序需要逐个组织运行,比较麻烦;可考虑直接参考清除程序,以脚本清除:

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;

clip_image001

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;

clip_image002

节省 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模块清除成本信息

image

比较麻烦,几十个库存组织,每个组织都有几十种成本类型,全部清除得提交几百次请求,太麻烦了,搞了一个库存组织后就买有再继续搞。

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) 系统管理员:删除工作流运行时历史记录:

image

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)系统管理员:清除并发程序和并发管理器的日志

image

二、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下重新调整分区大小。

image

[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数据库侦听性能问题

最近发现一件怪事情: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.2 使用问题汇集

 

本文的上一篇文章是:从 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了。