年度末NC项目系统优化NC用户年度末时往往是使用NC最频繁的时候,在这个时候效率问题便变得尤为突出,为了防止因为应用服务器配置,数据库配置不当而引起的效率问题,保证客户业务顺利进行,需要前方顾问在这个时间段做以下优化工作:一:应用服务器1:应用服务器中客户日常业务中一定要避免输出所有sql语句:如果输出的话,会极大的加重应用服务器I/O的负载.可以用setting工具中的是否输出sql语句选项,不选,然后点接设置按钮就可以屏蔽掉.2:保证NC应用服务器启动参数设置正常:查看启动文件startup中的-Xms 与-Xmx的值,与发版推荐或技术工作指导手册中推荐的值没有太大出入就行.如果是NC3.0,可以在setting工具的最后一个面板中获取对应端口中间件的内存使用状况,可以跟踪实际使用中内存是否会存在瓶颈.3：对于widows操作系统：操作系统尽量干净。
不要安装DNS系统不要安装盗版防火墙软件在应用服务器上尽量不要安装数据库系统每周重启一次4：应用服务器中NC中间件设置自动重启功能。
通过设置NC应用服务器每天自动重启来提高NC应用服务器响应的效率.如果是NC2.3与NC3.0,可以用NC中commander命令来进行设置.注意：避开NC中自动任务批处理执行时间（1）：用commander.bat(commander.sh)中的clock命令可以设置自动重启定时。
只要中间件监控进程没有断掉，设置的自动重启定时就不会销掉。
（注意，设置后，除非监控进程断掉，否则自动重启定时无法取消）（2）：还可以在./ierp/bin/clock.properts中设置是否默认启动自动重启定时，以及自动重启定时的时间。
### 设置服务器重启闹钟### 闹钟时间clock = 00:00### 是否启动闹钟enable = false如果enable设置位true，则启动中间件时监控进程会默认启动自动重启定时。
时间位clock属性对应的时间。
注意该时间不能为00:00，否则默认为不启动闹钟功能。
5：定时轻理NC中的日志尤其是设置自动重启后，日志出现覆盖重写的几率较小，会出现很多的日志文件在./NCLogs下，需要手动清理掉。
例如：UFNC3000R12_0.log，UFNC3001R12_0.log，UFNC3002R12_0.log,其中R12表示第12次自动重启后的日志。
6：JDK版本的维护在windows下与unix下有些不同，在windows下可以直接用sun提供的jdk。
而在unix 下：如果是solaris，需要用jdk for solaris版本，aix需要用ibm的jdk for aix，hp unix下用hp自己的jdk等等。
在unix下，可以这样启动中间件：./startup.sh /jdk目录7：定时监控系统注意异常的进程对系统的影响：在windows下如异常的防火墙进程，受病毒感染的进程等等有可能会占用大量的资源。
在unix下如异常的对文件操作，访问的进程等等，注意是否存在这样的进程造成大量的cpu资源占用。
8：应用服务器与数据库服务器的通信连接有时候应用服务器与数据库服务器的通信有可能出现问题，尤其是在大并发访问的情况下，应用服务器与数据库间通信非常频繁的时候。
此时要注意：(1)：数据库的listener是否能再监听从应用服务器上发过来的新建连接请求。
二:数据库服务器1:保证统计信息的最新与准确性如果做的统计信息是一个月以前的事情了,或者最近数据量比较大,最好重新做一下统计信息更新:(1)、对Oracle:使用sqlplus以要更新的用户身份登陆到数据库，执行：begindbms_stats.gather_schema_stats(ownname=> '（用户名）' , cascade=> TRUE);end;上述语句会把该用户模式下的所有表、索引的统计信息更新。
如果只想更新其中某个对象的统计信息，可执行analyze table 表名compute statisticsanalyze table 表名compute statistics for all indexes;analyze table 表名compute statistics for all columns;(２)、对SQL Server使用Query Analyzer登陆到SQL Server，执行：use 用户数据库名称sp_updatestats上述语句会把该数据库内的所有表、索引的统计信息更新。
如果只想更新其中某个对象的统计信息，可执行UPDATE STATISTICS 表名(3)、DB2以表的所有者的用户权限登陆数据库,执行：reorgchk update statistics on table all上述语句会更新该数据库内该用户所拥有的所有表、索引的统计信息如果只想更新其中某个对象的统计信息，可执行RUNSTATS ON TABLE（表名） and indexes all2:可以考虑重建索引如果系统已经运行1年以上,并且数据变化很大,可以考虑重建索引.sql server:在用户数据库先执行：select 'dbcc dbreindex('+name+')' from sysobjects where xtype='u'然后把运行结果执行oracle:执行：set pagesize 20000spool c:\index.sql;select 'alter index '||index_name||' rebuild online;' from user_indexes;spool off;编辑c:\index.sql文件，删除除'alter index......'外的其他内容。
运行：@@c:\index.sql;db2:在用户数据库先执行：select 'REORG TABLE '||rtrim(TBCREATOR)||'.'||TBNAME||' INDEX'||rtrim(CREATOR)||'.'||NAME from sysibm.sysindexes然后把运行结果执行3:优化数据库参数:需要根据实际应用情况及数据库性能监控报告,可以考虑调整参数进行优化.详细见附件一:数据库优化说明.附件一:Oracle优化说明ora_perform.sql脚本是用来监测oracle数据库性能的工具。
(该脚本附录在最后面)使用方法：1.将ora_perform.sql文件放入某一磁盘，如c:；启动SQLPLUS，输入用户名/口令及连接名与你将要监测的数据库建立起连接；执行命令：@c:\ora_perform.sql（注意文件所在位置）。
2.需要输入参数：loops,interval的值。
Loops指要做多少次监测操作；interval指定每次监测之间所间隔的时间，单位为秒。
在监测过程中SQLPLUS呈现一种停止状态。
你不用去管它，监测结束后结果后会被输出到SQLPLUS界面及c:\ora_perform_result.txt文件中。
3.建议在业务操作较为频繁的时候来做监测。
loops的值大一些，如10次左右或更大；interval的值建议为900，也就是间隔时间为15分钟。
这样整个监测过程需要花费大约10*900(秒)，即2.5个小时左右。
结果输出后，取结果重覆出现频率较高的几组值进行分析。
结果说明：1.Buffer Cache Hit Ratio说明：数据缓冲区的命中率。
SQL语句执行时，Server进程首先会去数据缓冲区中找返回给用户的数据值，当缓冲区中没有所要的数据时通过DBWR进程将数据从数据文件中读取写入数据冲区再传给用户。
命中率是指未发生物理文件读取的数据请求在所有数据请求中所占比例。
正常值：>=90%优化方法：a.增加初始化参数：db_block_buffers的值。
增加的前提是目前有足够的剩余物理内存。
b.设置多缓冲池。
将缓冲池分为keep区，recycle区,default区，三个区的大小总合为db_block_buffers的值，修改init<sid>.ora文件加入设置，例如下：...DB_BLOCK_BUFFERS = 20000DB_BLOCK_LRU_LATCHES = 6BUFFER_POOL_KEEP=(BUFFERS:14000,LRU_LATCHES:1)BUFFER_POOL_RECYCLE=(BUFFERS:2000,LRU_LATCHES:3)...注：buffer_pool_buffers=2000*3+14000*1=20000keep区用于保留会再一次使用的对象；recycle区用于存放很少被重复使用的对象。
所以我们可以指定经常重复使用的表、索引等对象的缓存区域为keep区，以减少I/O操作。
指定方法如下：alter table bd_accsubj storage(buffer_pool keep);2.Library Cache Hit Ratio；Library Cache Reload Ratio说明：library cache用于存放SQL、PLSQL及其分析树及他们的执行方案。
Library cache hit ratio 指所发送的SQL语句在library cache中能找到它的执行方案的机率；librarycache reload 指所发送的SQL语句在library cache曾经有过同样的语句及它的执行方案，但被移出了library cache，这些语句所占的比率即为library cache reload ratio。
正常值：Library Cache Hit Ratio>=90%Library Cache Reload Ratio<=1%（最好为0）优化方法：增加初始化参数：shared_pool_size 的值。
3.Dictionary Cache Getmisses Ratio说明：dictionary cache用于存放数据库对象如表、视图等的结构定义。
当SQL语句中用到数据库对象时，server进程要去dictionary cache中对比该对象的定义，当找不到时会从数据文件中读取入dictionary cache，dictionary cache getmisses ratio反映的就是找不到的比率。
正常值：<15%优化方法：增加初始化参数：shared_pool_size的值4.Rollback Segment Wait Ratio说明：事务在请求回滚段时发生等待的比率。