NC Test 2008 B

一、 简述与分析（本题有5小题，共20分）

1、请简述32位的应用服务器，WAS设置JVM的堆参数最大设置多少？(3分)

答案：推荐小于1.3G 或1284M, 最大不能超过1.5G.

 

2、请简述NC+WAS环境下，如果java产生javacore文件，那么它的位置在哪里？(4分)

 

答案：在%WAS_HOME%/profiles/AppSrv0X/下

         Dmgr的在 %WAS_HOME%/profiles/Dmgr01/目录下

 

3、NC5X，如何设置客户端的日志级别，如果输出到文件，那么文件的位置在哪里？(4分)

答案：登录NC后，点击日志按钮，设置ERROR/DEBUG两种日志级别，如果日志过多可以设置成tofile，日志的位置在%USERPROFILE%/NCCACHE/项目/LOG目录下

 

4. 请写出在linux/aix/hpunix/solaris系统中查看CPU的信息命令？(4分)

答案：

1）linux查看CPU的信息： more /proc/cpuinfo

2）AIX查看CPU的信息： lsdev -Cc processor 

3）hpunix查看CPU的信息：   lscfg |grep proc lsattr -El proc0

3）solaris查看CPU的信息：psrinfo -v | grep "Status of processor"

 

 

5  如何切换noarchivelog到archivelog模式? (5分)

答案:

a.shutdown immediate

b. startup mount

c. alter database archivelog

d. alter database open

e. alter system archive log start;--启用自动归档;

设置log_archive_start=true后如果重现启动了数据库就不需要执行这一步了.

f. alter system set log_archive_start=true scope=spfile;--如果先前没有改变log_archive_start参数时需要运行

 

二、   实务题（本题有4大题，共30分）

 

1 UNIX操作系统作为应用服务器，NC后台日志中报类格式(class format)错误,

如何解决? (6分)

 

原因：

  可能是该类是用ftp的asii方式传到unix下的；

  也可能是因为原来编译该类的jdk版本与运行该类的jdk版本不兼容引起的。

解决办法:

  如果是第一种情况，可以将该代码重新以bin(二进制)方式传上去；

  如果是第二种情况，只有找到该类源代码，在运行该类的jdk环境下重新编译了。"

 

2  如何将NC5X和IUFO分离？ (9分)

答案：1:复制代码形成NCHOME,IUFOHOME

2:NC应用中删除iufo的数据源。

3:将NC代码下，将modules下的iufo目录删除。

4:将NC501,NC5011安装盘下NC_UAP/uap/uapother下的code.jar解压

5:解压完后在code目录下，把modules/iufo拷贝到/nchome/modules/下。

6:重新生成部署ejb

7:如果IUFO下配置了service，

非集群环境下，那么在ncsysconfig/wassysconfig下删除服务。

集群环境下，保留service

8:IUFOHOME下，在ncsysconfig/wassysconfig下有ScheduleEngine，不要启用调度。

9:在NC下修改iufo的超链接

           修改nchome/webapps/nc_web/logo/下的iufo.txt文件。在前面加上地址，如：

           http://192.167.0.88:9086/service/~iufo/nc.ui.iufo.login.Index

10:在IUFO下去掉NC的超链接

           删除nchome/webapps/nc_web/logo/下的nc.txt文件。

11：如果是内外网应用的话，就不要在NC下修改iufo的超链接，这样iufo会访问不了。访问IUFO只能让客户端指定IP＋端口。

如果用了was,建议重新创建一个profile,新建一个节点，把iufo部署在这个节点下的一个server下。然后在防火墙或者路由器上进行端口映射访问。〔或者按照既定的内外网访问方案就行〕

如果没有用was,可以直接在防火墙或者路由器上进行端口映射。〔或者按照既定的内外网访问方案就行〕

3 在数据库中存在如下的大量等待事件：db file sequential read、db file scattered read,、SQL*Net message from client。请分别说明各个等待事件代表的意思是什么？那些是空闲(idle)事件？那些是非空闲事件？我们相应的应该如何处理？ (6分)

 

答案: db file sequential read表示对数据文件的顺序读取，一般对应的是对index的访问。属于非空闲等待事件。

db file scattered read表示对数据文件内容的分散读取，一般对应的是对表的full scan。属于非空闲等待事件。

SQL*Net message from client表示服务器进程在等待客户端给出的操作需求。属于空闲等待事件。

对于SQL*Net message from client事件我们不予关注，而对于另外的两个等待事件，我们需要进一步查看具体的sid对应的具体操作，一般来说如果是db file sequential read事件，且对应sid相关的操作是对大表的full scan，则需要考虑在大表上创建合适的index来避免full scan，而如果是大量对小表的full scan可以考虑把小表cache到ram中。

对于db file sequential read的等待事件，我们需要进一步查看具体的sid对应的具体操作，如果具体的sql的执行计划中使用了合适的index，我们可以不予处理；如果对应的sql的执行计划中使用了不合适的index，我们需要通过hint或者数据库参数的调整，让sql使用合适的index。

 

4    目前数据库服务器系统topas表现出如下情况:

Topas Monitor for host:    p561a_svc            EVENTS/QUEUES    FILE/TTY

Wed Jan 23 11:32:03 2008   Interval:  2         Cswitch    1231  Readch    96877

                                                Syscall    7276  Writech   55493

Kernel    0.5   |#                           |  Reads       444  Rawin         0

User     84.6   |########################    |  Writes      444  Ttyout      279

Wait      0.0   |                            |  Forks         0  Igets         0

Idle     14.9   |#####                       |  Execs         0  Namei         0

                                                Runqueue    9.5  Dirblk        0

Network  KBPS   I-Pack  O-Pack   KB-In  KB-Out  Waitqueue   0.0

en0     193.1    446.7   494.6   112.5    80.6

en2       0.0      0.0     0.0     0.0     0.0  PAGING           MEMORY

en3       0.0      0.0     0.0     0.0     0.0  Faults       42  Real,MB   15808

lo0       0.0      0.0     0.0     0.0     0.0  Steals        0  % Comp     44.5

                                                PgspIn        0  % Noncomp  32.1

Disk    Busy%     KBPS     TPS KB-Read KB-Writ  PgspOut       0  % Client   32.1

hdisk13   0.4    205.4     2.0     0.0   205.4  PageIn        0

hdisk1    0.0      0.0     0.0     0.0     0.0  PageOut       0  PAGING SPACE

hdisk3    0.0      0.0     0.0     0.0     0.0  Sios          0  Size,MB    8192

dac1      0.0      0.0     0.0     0.0     0.0                   % Used      0.8

dac0      0.0    277.2     3.0     0.0   277.2  NFS (calls/sec)  % Free     99.1

hdisk4    0.0     71.9     1.0     0.0    71.9  ServerV2       0

oracle       151940  12.0  10.2 oracle

oracle       266712  11.9   9.8 oracle

oracle       212998  11.9   9.7 oracle

oracle       291246   9.1   9.3 oracle

oracle       282988   9.0   9.3 oracle

oracle       368944   6.3   9.8 oracle

oracle       188800   6.2   9.8 oracle

oracle       352636   6.2   9.7 oracle

oracle       287042   6.1   9.3 oracle

oracle       512020   6.1  10.7 oracle

syncd         94370   0.0   0.5 root 

topas        110852   0.0   1.8 ncuser

dtgreet      389308   0.0   1.3 root 

oracle       233490   0.0  12.6 oracle

请分析系统目前的主要问题是什么？如果来定位问题的根源？如何查询oracle的那些操作在占用大量的系统资源？ (9分)

答案:目前系统的主要问题是cpu资源短缺，造成这个问题的原因是oracle的多个用户进程占用了太多的cpu资源。

可以通过如下步骤来定位问题：

首先根据操作系统的pid来查询对应的oracle的对应SID和SQL_HASH_VALUE（不写出具体sql，讲明具体方法，给出具体视图也行，比如说：通过v$session/v$process/v$sql/v$session_wait的相互关联关系查找具体的sql和等待事件等）:

SELECT SID,b.SQL_HASH_VALUE

  FROM V$PROCESS A, V$SESSION B

 WHERE A.ADDR = B.PADDR

   AND A.SPID = 151940;

根据得到的sid和SQL_HASH_VALUE可以进一步查看具体的session_event和sql_txt:

SELECT event

  FROM V$session_Wait

 WHERE sid=上面得到的sid;

SELECT sql_text

  FROM v$sql

 WHERE hash_value='上面得到的sql_hash_value ';