软件项目维护方案
软件项目维护方案 1. 项目背景及目标 1.1. 项目背景 在国家政策的指导和帮助下，信息化也越来越发挥出十分重要的作用。XXXX不断加大信息化管理工作力度，积极实施“上网工程”，大力推进全市局域网建设，加快办公自动化系统进程，信息技术在改革中发挥了重要的支撑作用，为充分发挥政府公共职能，促进依法理财、科学理财，提供了重要的信息技术保障。近年来建设各系统随着数据量的逐年增加，陆续出现了性能问题，有必要进行数据库系统的升级及性能优化，以确保应用系统的正常运行，为单位员工提供更好的信息服务。
1.2. 项目目标 ● 对各系统数据库进行补丁升级服务，安装补丁前制定详细的升级计划和应急回退计划。
● 完成各系统数据库的性能调优工作。
● 各业务持续性得到有效的保证。
2. 需求分析 XXXXXXX项目，我公司有多年的行业经验。具有对运维服务对象进行适时监测、指标分析、和及时修复的能力。
Oracle 产品日常运行维护项目主要从如下几个方面进行：
(1). 每天对ORACLE数据库的运行状态,日志文件,备份情况,数据库的空间使用情况,系统资源的使用情况进行查看,发现并解决问题。 (2). 每周对数据库对象的空间扩展情况,数据的增长情况进行监控,对数据库做健康查看,对数据库对象的状态做查看。 (3). 查看表空间碎片,提出下一步空间管理计划。对ORACLE数据库状态进行一次全面查看。 （4）由于这些数据库系统承载着XXXX非常重要的业务系统数据，所以在日常 维护中需要非常仔细，每周、每月、每季都需要有相应的巡检记录，需要详细记载以下一些内容：
n 监控数据库对象的空间扩展情况 n 监控数据量的增长情况 n 系统健康查看，查看以下内容: n 数据库对象有效性查看 n 查看是否有危害到安全策略的问题。
n 查看 alert、Sqlnet 等日志并归档报错日志 n 分析表和索引 n 查看对数据库会产生危害的增长速度 n 查看表空间碎片 n 数据库性能调整 n 预测数据库将来的性能 n 调整和维护工作 n 后续空间 3. 整体运行维护服务方案 3.1. Lifekeeper维护 3.1.1. 验证 LifeKeeper 的安装 查看已经安装的LifeKeeper软件包，可以使用命令：
rpm –qa|grep stee 3.1.2. 启动 LifeKeeper a) 启动LifeKeeper 服务器进程 如果当前您的系统没有运行 LifeKeeper 则在所有服务器上以root用户身份输入如下命令 # /opt/LifeKeeper/bin/lkstart b) 启动LifeKeeper GUI服务器进程 同样以root用户运行命令 # /opt/LifeKeeper/bin/lkGUIserver start 注意：以上命令只需运行一次，以后每次系统重新启动时，LifeKeeper会自动运行上述进程 3.1.3. 有关的LifeKeeper软件的其它管理任务 a) 停止 LifeKeeper 服务 如果需要在服务器上永久停止LifeKeeper服务，可以输入下列命令 $LKROOT/bin/lkstop 该命令同时会使所有LifeKeeper保护的资源处于退出服务状态，如果希望在停止LifeKeeper时保持资源/应用的运行，可以使用：
$LKROOT/bin/lkstop -f b) 查看 LifeKeeper 进程 键入下列命令可以查看当前运行的所有 LifeKeeper 进程列表 ps -ef | grep LifeKeeper 3.1.4. 启动LifeKeeperGUI配置工具 进入LifeKeeper GUI管理工具可以通过运行命令：
/opt/LifeKeeper/bin/lkGUIapp 则出现LifeKeeper登录界面：
可以使用root用户登录，也可以使用新建的用户进行登录。
3.1.5. 检测LifeKeeper 集群运行状态 可以使用lcdstatus命令对LifeKeeper 集群的当前运行状态进行查看，命令格式：
lcdstatus [-q] [-d <主机名>] 该程序向 stdout 输出在LifeKeeper 资源层次配置状态和通信路径的状态. 选项 -q 表示输出采用简略的形式（建议使用该选项） 选项–d 表示要查看的主机，缺X查看本机 3.1.6. 管理 LifeKeeper 中的资源 注意：如果能运行LifeKeeper GUI，则使用其提供菜单命令执行相应操作；
在执行命令行启动/停止资源前，一定先使用lcdstatus命令确认资源的实际状态。
a) 启用资源(In-Service) 可以使用命令：
./perform_action -t <资源标记名> -a restore 将资源标记名所对应的资源在本机上投入服务（启动）。如果该资源在命令使用前已经在另一台机器上处于运行状态，则本命令执行的结果相当于执行了一次手工切换 ！！！如果该资源在命令使用前是处于停止状态（即在备机上执行本命令），则本命令执行的结果相当于执行了一次手工切换 b) 停止资源(out-of-service) 可以使用命令：
./perform_action -t <资源标记名> -a remove 将资源标记名所对应的资源在本机上停止服务。如果该资源在命令使用前已经在另一台机器上处于运行状态，则本命令执行不产生任何结果 注意：
n 在执行命令行前后，一定先使用lcdstatus命令确认资源的当前状态。
n 命令停止/启动本地的资源 n 命令中的<资源标记名>是区分大小写的 n 一定要等待命令完成，注意命令的输出。
n 详细用法见在线帮助手册。
3.2. SQL SERVER维护 计算机系统各种软、硬件故障、用户误操作以及恶意破坏是不可避免的,这些影响到数据的正确性甚至造成数据损失、服务器崩溃等致命后果。数据库的备份对保证系统的可靠性具有重要的作用。
下面会根据执行强度对维护任务及其相应的程序进行分类描述，执行强度用不同的时间间隔定义，包括每天、每周、每月和每季度，能够建立起良好的维护实务，确保SQL Server数据库性能和安全。
3.2.1. 每天的例行维护任务 需要数据库管理员密切关注的维护任务，最好每天都查看一下，这样可以确保系统的可靠性、可用性、运行性能和安全。每天的例行维护任务包括：
1、查看是不是所有被请求的SQL Server服务都正常运行。
2、查看日常备份日志中成功、警告或者失败记录。
3、查看Windows事件日志有没有错误记录。
4、查看SQL Server日志有没有安全警告记录，例如非法登录。
5、执行完全备份或差异备份。
6、在设置了完全恢复模型或大容量日恢复模型的数据库上执行事务日志备份任务。
7、核实SQL Server作业没有失败。
8、查看所有的数据库文件和事务日志具有合适的磁盘空间大小。
9、至少要监控处理器、内存或者磁盘计数器没有出现瓶颈。
3.2.2. 每周的例行维护任务 关注程度稍逊于每天的例行维护任务，最好每周进行一次例行查看。每周的例行维护任务包括：
1、执行完全备份或差异备份。
2、查看以前执行的维护计划报告。
3、查看数据库完整性。
4、如果需要，执行收缩数据库任务。
5、通过重新组织索引任务压缩聚集和非聚集表和视图。
6、通过重新生成索引任务在数据页和索引页重新组织数据。
7、更新所有用户表和系统表的统计信息 8、清除备份、还原、SQL Server代理作业和维护计划等操作的历史数据。
9、如果需要，手动增长数据库或事务日志文件 10、清除执行维护计划残留下来的文件。
3.2.3. 每月或每季度的维护任务 有一些维护计划不需要执行得过于频繁，可以每个月或每个季度执行一次。但是请不要以为这些任务不需要天天执行就无足轻重，这些任务可以确保数据库环境的健康，所以不要轻视以下这些维护任务：
1、在测试环境中执行备份还原操作。
2、将历史数据归档。
3、分析收集的性能统计数据，与基准值相比较。
3、查看并更新维护文档。
4、查看并安装最新的SQL Server补丁和补丁包。
5、如果运行簇、数据库镜像或日志传送，则监测故障转移。
6、验证备份和还原进程是否遵循已定义的服务等级协议。
7、更新SQL Server构建指南。
8、更新SQL Server灾难恢复文档。
9、更新维护计划列表 10、修改管理员口令。
11、修改SQL Server服务帐户口令。
3.3. WebLogic维护 3.3.1. 性能调优 3.3.1.1. 设定执行队列的溢出条件 Weblogic Server提供给默认的执行队列或用户自定义的执行队列自定义溢出条件的功能，当满足此溢出条件时，服务器改变其状态为“警告”状态，并且额外的再分配一些线程去处理在队列中的请求，而达到降低队列长度的目的。 通过启动管理控制台，在域（如：mydomain）> 服务器> server实例（如：myserver）> Execute Queue > weblogic.kernel.Defalt > 配置下面几项： 队列长度：此值表示执行队列中可容纳的最大请求数，默认值是65536，最后不要手动改变此值。 队列长度阈值百分比：此值表示溢出条件，在此服务器指出队列溢出之前可以达到的队列长度大小的百分比。 线程数增加：当检测到溢出条件时，将增加到执行队列中的线程数量。如果CPU和内存不是足够的高，尽量不要改变默认值“0”。因为Weblogic一旦增加后不会自动缩减，虽然最终可能确实起到了降低请求的作用，但在将来的运行中将影响程序的性能。 最大线程数：为了防止创建过多的线程数量，可以通过设定最大的线程数进行控制。 在实际的应用场景中，应根据具体情况适当的调整以上参数。 3.3.1.2. 设定队列监测行为 Weblogic Server能够自动监测到当一个执行线程变为“阻塞”。变为“阻塞”状态的执行线程将无法完成当前的工作，也无法再执行新请求。如果执行队列中的所有执行线程都变为“阻塞”状态，Weblogic server可能改变状态为“警告”或“严重”状态。如果Weblogic server变为“严重”状态，可以通过Node Manager来自动关闭此服务器并重新启动它。具体请参考：Node Manager Capabilities文档。 通过启动管理控制台，在域（如：mydomain）> 服务器> server实例（如：myserver）>配置> 调整下可配置下面几项： 阻塞线程最长时间：在此服务器将线程诊断为阻塞线程之前，线程必须连续工作的时间长度(秒)。默认情况下，WebLogic Server 认为线程在连续工作600 秒后成为阻塞线程。 阻塞线程计时器间隔：WebLogic Server 定期扫描线程以查看它们是否已经连续工作了“阻塞线程最长时间“ 字段中指定的时间长度的间隔时间(秒)。默认情况下，WebLogic Server 将此时间间隔设置为600 秒。 3.3.1.2.1. 尽量使用本地IO库 WebLogic Server有两套套接字复用器：Java版和本地库。采用小型本地库更有效,尽量激活Enable Native IO(默认),此时UNIX默认使用CPUs+1个线程,Window下为双倍CPU。如果系统不能加载本地库,将会抛出java.lang.UnsatisfiedLinkException,此时只能使用Java套接字复用器,可以调整socket readers 百分比,默认为33%。该参数可以在Console Server Tuning Configuration配置栏里设置，配置完，重新启动WebLogic Server即可。
3.3.1.2.2. 调整默认执行线程数 名称 开发模式 产品模式 推荐个数 Execute Queues 默认的执行线程为15 默认的执行线程为25 200 在管理控制台修改默认执行队列线程数的步骤如下：
n 如果管理服务器没有运行，先启动。
n 访问管理控制台。
n 展开左边面板的Servers 节点，显示Server列表。
n 右击Server，在弹出菜单中选择View Execute Queues ，就会在右边面板显示有执行队列的表用来修改。
n 注意：你只能修改默认的执行队列或者用户定义的执行队列。
n 在Name列，直接点击默认执行队列名称，显示配置标签用来修改执行队列数。
n 填下适当的线程数。
n 点击Apply，保存刚才的修改。
n 重启Server，使新的执行队列设置生效。
3.3.1.3. JDBC调优 3.3.1.3.1. 驱动程序类型选择 Oracle提供thin驱动和oci驱动,从性能上来讲,oci驱动强于thin驱动,特别是大数据量的操作。但在简单的数据库操作中,性能相差不大,随着thin驱动的不断改进,这一弱势将得到弥补。而thin驱动的移植性明显强于oci驱动。所以在通常情况下建议使用thin驱动 3.3.1.3.2. 调节连接池初始容量和最大容量 JDBC Connection Pool的调优受制于WebLogic Server线程数的设置和数据库进程数,游标的大小。通常我们在一个线程中使用一个连接,所以连接数并不是越多越好,为避免两边的资源消耗，建议设置连接池的最大值等于或者略小于线程数。同时为了减少新建连接的开销,将最小值和最大值设为一致；
值等于WebLogic Server的执行线程数。
3.3.1.3.3. 其他配置 尽管JDBC Connection Pool提供了很多高级参数,在开发模式下比较有用,但大部分在生产环境下不需调整。这里建议最好不要设置测试表, 同时Test Reserved Connections和Test Released Connections也无需勾上。当然如果你的数据库不稳定,时断时续,你就可能需要上述的参数打开 3.3.1.4. WEB调优 3.3.1.4.1. 调整WEB应用描述符 WEB应用除代码之外的调优比较简单,仅仅是对一些WEB应用描述符的调整。首先关闭Session Monitoring Enabled,仅仅在Cluster环境下设置Session复制(优先使用内存复制),在保证应用正常运行的情况下,设置较短的Session超时时间。同时生产环境下无需查看Jsp和servlet：JSPPage Check Secs和Servlet Reload Check Secs均设为-1,关闭JSP Keep Generated 和JSP Verbose对性能也有帮助。此外，还可以对jsp进行预编译,有两种方法：激活precompile选项；
使用weblogic.appc事先编译，建议采用后者。
3.3.1.5. 其他调优设置 3.3.1.5.1. WebLogic文件描述符大小调整 首先设置WEB主机系统的ulimit参数为unlimited ，然后设置WebLogic中文件描述符的大小。
在{WL_HOME}/bea/weblogic/common/bin中打开文件commEnv.sh，修改设置文件描述符大小的指令，将默认的：ulimit –n 1024修改为：ulimit –n 8192 3.3.2. 维护管理 3.3.2.1. 启动weblogic server n 启动管理服务器：执行startAdmserver.sh n 启动被管理服务器：执行startManagedWebLogic.sh servername adminurl 3.3.2.2. 停止weblogic server n 停止被管理服务器：执行stopWebLogic.sh servername n 启动被管理服务器：执行stopWebLogic.sh 3.3.2.3. 登录和退出管理控制台 n 管理服务器启动后可以在浏览器中登录管理控制台 n 输入URL：http://hostname:port/console或https://hostname:port/console l hostname：管理服务器的ip地址或DNS名 l port：管理服务器监听的端口 l 如果管理服务器启动时使用SSL，则使用https访问管理控制台 n 在弹出的窗口“Console Login“中输入用户名和密码登录 3.3.2.4. 性能监控 n 查看性能参数 l 登录控制台后点击Servers-servername-Monitoring-Performance n 参数分析 n 1)Idle Threads && Queue Length && Throughout 正常情况下 idle threads >0 ，queue Length为0，Throughout呈不规则变化曲线，Memory Usage呈适度频度的锯齿变化曲线。
一般来说，对于正常配置的生产环境（线程数50~200），如果idle threads <10，或者呈现不断降低的趋势，就应加以关注；
空闲线程数与队列长度通常有如下关系：
A、如果空闲线程数>0 ，则 queue length =0 ；
B、反之，如果queue length>0 ，则空闲线程数=0 ；
n 2)Memory Usage Memory Usage = totalMemory() – freeMemory() 内存使用曲线反应了JVM Heap内存使用的变化情况，可以结合其他三个值的变化情况来判断server工作情况；
比较理想的状态是适当频度的各种锯齿变化， 由于JVM GC多采用“stop the world”机制，也就是垃圾回收时其他处理将暂停，过度频繁的GC将明显降低server工作效率和性能表现。
3.4. Oracle维护 Oracle Database，又名Oracle RDBMS，或简称Oracle。是甲骨文公司的一款关系数据库管理系统。它是在数据库领域一直处于领先地位的产品。可以说Oracle数据库系统是目前世界上流行的关系数据库管理系统，系统可移植性好、使用方便、功能强，适用于各类大、中、小、微机环境。它是一种高效率、可靠性好的 适应高吞吐量的数据库解决方案。
3.4.1. 数据库性能优化 Oracle 性能管理既是一种艺术，也是一种科学。从实用角度讲，它可以分为两种类型，主动式和被动式性能管理。主动式性能管理涉及到特定系统实施初期的设计和开发，包括硬件选择、性能及容量规划，海量存储系统的选择， I-O子系统配置及优化，以及如何对不同组件进行定制，以满足 Oracle 数据库和应用系统的复杂要求。
被动式性能管理涉及到现有环境中不同组件的性能评估、故障排除和 Oracle环境的优化。本文旨在探讨如何进行被动式性能调优，以便为 Oracle 性能调优提供必要的指导，从而避免仅仅通过反复尝试的方式进行性能调优，提高 Oracle性能管理的效率。
所以 ORACLE 数据库性能恶化表现基本上都是用户响应时间比较长，须要用户长时间的等待。获得满意的用户响应时间有两个途径：
一是减少系统服务时间，即提高数据库的吞吐量；
二是减少用户等待时间，即减少用户访问同一数据库资源的冲突率。
对于以上的两个问题，通常我们采用以下几个方面来进行改善：
n 调整服务器内存分配。例如，可以根据数据库运行状况调整数据库系统全局区（SGA 区）的数据缓冲区、日志缓冲区和共享池的大小；
还可以调整程序全局区（PGA 区）的大小。
n 调整硬盘 I/O 问题，达到 I/O 负载均衡。
n 调整运用程序结构设计。
n 优化调整操作系统参数和使用资源管理器。
n SQL 优化、诊断 latch 竞争、Rollback(undo) Segment 优化、提升 block的效率等等。
3.4.1.1. 查看Oracle数据库性能 查看 Oracle 数据库性能情况，包含：查看数据库的等待事件，查看死锁及处理，查看 cpu、I/O、内存性能，查看是否有僵死进程，查看行链接/迁移，定期做统计分析，查看缓冲区命中率，查看共享池命中率，查看排序区，查看日志ORACLE 产品日常运行维护年度服务项目缓冲区，总共十个部分。
3.4.1.1.1. 查看数据库的等待事件 set pages 80 set lines 120 col event for a40 select sid,event,p1,p2,p3,WAIT_TIME,SECONDS_IN_WAIT from v$session_wait where event notlike ＇SQL%＇ and event not like ＇rdbms%＇; 如果数据库长时间持续出现大量像latch free，enqueue，buffer busy waits，db file sequential read，db file scattered read 等等待事件时，需要对其进行分析，可能存在问题的语句。
3.4.1.1.2. 查看消耗CPU最高的进程 SET LINE 240 SET VERIFY OFF COLUMN SID FORMAT 999 COLUMN PID FORMAT 999 COLUMN S_# FORMAT 999 COLUMN USERNAME FORMAT A9 HEADING “ORA USER“ COLUMN PROGRAM FORMAT A29 COLUMN SQL FORMAT A60 COLUMN OSNAME FORMAT A9 HEADING “OS USER“ SELECT P.PID PID,S.SID SID,P.SPID SPID,S.USERNAME USERNAME,S.OSUSER OSNAME,P.SERIAL# S_#,P.TERMINAL,P.PROGRAM PROGRAM,P.BACKGROUND,S.STATUS,RTRIM(SUBSTR(A.SQL_TEXT, 1, 80)) SQLFROM V$PROCESS P, V$SESSION S,V$SQLAREA A WHERE P.ADDR = S.PADDR AND S.SQL_ADDRESS = A.ADDRESS (+) AND P.SPID LIKE ＇%&1%＇; 3.4.1.1.3. 查看碎片程度高的表 SQL> SELECT segment_name table_name,COUNT(*) extents FROM dba_segments WHERE ownerNOT IN (＇SYS＇, ＇SYSTEM＇) GROUP BY segment_name HAVING COUNT(*)=(SELECT MAX(COUNT(*))FROM dba_segments GROUP BY segment_name); 3.4.1.1.4. 查看表空间的 I/O比例 SQL>SELECT DF.TABLESPACE_NAME NAME,DF.FILE_NAME “FILE“,F.PHYRDS PYR, F.PHYBLKRDPBR,F.PHYWRTS PYW, F.PHYBLKWRT PBW FROM V$FILESTAT F, DBA_DATA_FILES DF WHEREF.FILE# = DF.FILE_ID ORDER BY DF.TABLESPACE_NAME; 3.4.1.1.5. 查看文件系统的 I/O比例 SQL>SELECTSUBSTR(A.FILE#,1,2)“#“,SUBSTR(A.NAME,1,30)“NAME“,A.STATUS,A.BYTES,B.PHYRDS,B.PHYWRTS FROM V$DATAFILE A, V$FILESTAT B WHERE A.FILE# =B.FILE#; 3.4.1.1.6. Disk Read最高的SQL语句的获取 SQL>SELECT SQL_TEXT FROM (SELECT * FROM V$SQLAREA ORDER BY DISK_READS) WHERE ROWNUM<=5 desc; 3.4.1.1.7. 查找前十条性能差的sql SELECT * FROM (SELECT PARSING_USER_ID EXECUTIONS,SORTS,COMMAND_TYPE,DISK_READS, SQL_TEXT FROM V$SQLAREA ORDER BY DISK_READS DESC) WHERE ROWNUM<10 ; 3.4.1.1.8. 等待时间最多的 5 个系统等待事件的获取 SELECT * FROM (SELECT * FROM V$SYSTEM_EVENT WHERE EVENT NOT LIKE ＇SQL%＇ ORDER BYTOTAL_WAITS DESC) WHERE ROWNUM<=5; 3.4.1.1.9. 查看运行很久的SQL COLUMN USERNAME FORMAT A12 COLUMN OPNAME FORMAT A16 COLUMN PROGRESS FORMAT A8 SELECT USERNAME,SID,OPNAME,ROUND(SOFAR*100 / TOTALWORK,0) || ＇%＇ AS PROGRESS,TIME_REMAINING,SQL_TEXT FROM V$SESSION_LONGOPS , V$SQL WHERETIME_REMAINING <> 0 AND SQL_ADDRESS=ADDRESS AND SQL_HASH_VALUE = HASH_VALUE; 3.4.1.1.10. 查看死锁及处理 查询目前锁对象信息：
col sid for 999999 col username for a10 col schemaname for a10 col osuser for a16 col machine for a16 col terminal for a20 col owner for a10 col object_name for a30 col object_type for a10 select sid,serial#,username,SCHEMANAME,osuser,MACHINE, terminal,PROGRAM,owner,object_name,object_type,o.object_id from dba_objects o,v$locked_object l,v$session s where o.object_id=l.object_id and s.sid=l.session_id; oracle 级 kill 掉该 session：
alter system kill session ＇&sid,&serial#＇; 操作系统级 kill 掉 session：
#>kill -9 pid 3.4.1.1.11. 查看数据库cpu、I/O、内存性能 记录数据库的 cpu 使用、IO、内存等使用情况，使用 vmstat,iostat,sar,top等命令进行信息收集并查看这些信息，判断资源使用情况。
n CPU 使用情况：
[root@sale8 ~]# top top - 10:29:35 up 73 days, 19:54, 1 user, load average: 0.37, 0.38, 0.29Tasks: 353 total, 2 running, 351 sleeping, 0 stopped, 0 zombie Cpu(s): 1.2% us, 0.1% sy, 0.0% ni, 98.8% id,0.0% wa, 0.0% hi, 0.0% si Mem: 16404472k total, 12887428k used, 3517044k free, 60796k buffers Swap: 8385920k total, 665576k used, 7720344k free, 10358384k cached PID USER 30495 oracle 32501 oracle 32503 oracle 注意上面的加粗字体部分，此部分内容表示系统剩余的 cpu，当其平均值下降至 10%以下的时视为 CPU 使用率异常，需记录下该数值，并将状态记为异常 n 内存使用情况：
# free -m Totalusedfreesharedbufferscached Mem:20261958670761556 -/+ buffers/cache: 326 1700 Swap: 5992 92 5900 如上所示，total表示系统总内存，used表示系统使用的内存，free表示系统剩余内存，当剩余内存低于总内存的 10%时视为异常。
n 系统负载情况：
#uptime 12:08:37 up 162 days, 23:33, 15 users,load average: 0.01, 0.15, 0.10 如上所示，load average部分表示系统负载，后面的 3 个数值如果有高于 2.5 的时候就表明系统在超负荷运转了，并将此值记录到巡检表，视为异常。
3.4.1.1.12. 查看是否有僵死进程 select spid from v$process where addr not in (select paddr from v$session); 有些僵尸进程有阻塞其他业务的正常运行，定期杀掉僵尸进程。
3.4.1.1.13. 查看行链接/迁移 Sql>select table_name,num_rows,chain_cnt From dba_tables Where owner=＇CTAIS2＇ Andchain_cnt<>0; 注：含有 long raw 列的表有行链接是正常的 ,找到迁移行保存到chained_rows 表中 , 如没有该表执行 ../rdbms/admin/utlchain.sql Sql>analyze table tablename list chained rows; 可通过表 chained_rows 中table_name,head_rowid看出哪些行是迁移行如: Sql>create table aa as selecta.* from sb_zsxx a,chained_rows b where a.rowid=b.head_rowid andb.table_name =＇SB_ZSXX＇; sql>delete from sb_zsxx where rowid in (selecthead_rowid from chained_rows where table_name = ＇SB_ZSXX＇); sql>insertinto sb_zsxx select * from chained_row where table_name = ＇SB_ZSXX＇; 3.4.1.1.14. 定期做统计分析 对于采用 Oracle Cost-Based-Optimizer 的系统，需要定期对数据对象的统计信息进行采集更新，使优化器可以根据准备的信息作出正确的 explain plan。
在以下情况更需要进行统计信息的更新：
应用发生变化；
大规模数据迁移、历史数据迁出、其他数据的导入等；
数据量发生变化。
查看表或索引的统计信息是否需更新，如：
Sql>Select table_name,num_rows,last_analyzed From user_tables wheretable_name =＇DJ_NSRXX＇ sql>select count(*) from DJ_NSRXX 如 num_rows 和 count(*)如果行数相差很多,则该表需要更新统计信息，建议一周做一次统计信息收集，如：
Sql>exec sys.dbms_stats.gather_schema_stats(ownname=>＇CTAIS2＇,cascade=>TRUE,degree => 4); 3.4.1.1.15. 查看日志缓冲区 SQL> select name,value from v$sysstat where name in (＇redo entries＇,＇redo buffer allocationretries＇); 如果 redo buffer allocation retries/redo entries 超过 1% ，则需要增大 log_buffer。
3.4.1.2. 性能调优及方法 性能调优主要有主动调优和被动调优，主动调优在前面我们已经进行了阐述，被动调优主要有以下方法进行。
n 确定合理的性能优化目标 n 测试并记录当前的性能指标 n 确定当前存在的 Oracle 性能瓶颈 (Oracle 中何处存在等待，哪个 SQL语句与此有关) n 确定当前的操作系统瓶颈 n 优化相关的组件 (应用、数据库、I/O、连接 OS 及其它) n 跟踪并实施变化管理制度 n 测试并记录目前的性能指标 n 重复第 3 到第 7 步直至达到既定的优化目标 不要对并非性能瓶颈的部分进行优化，否则可能引起额外的问题。正如任何聪明的人会告诉你的：“如果还未坏，千万不要修”。更重要的是，一旦既定的优化目标已经达到，就务必停止所有的优化。
获取 Oracle 的性能指标 (测试前及测试后)必须在峰值处理时测试并获取系统在优化前和优化后的性能指标。数据采集不应在数据库 instance 刚刚起动后进行。同时，测试数据应在峰值期间每过 15 分钟进行一次。初始化参数TIMED_STATISTICS 应该被设为 TRUE。
通过运行以下脚本开始快照：
$ORACLE_HOME/rdbms/admin/utlbstat.sql. 通过运行以下脚本结束快照：
$ORACLE_HOME/rdbms/admin/utlestat.sql. 完成 utlestat.sql 操作后，会在当前目录中生成名为“report.txt”的文件，包含系统的性能数据。该报告包括每 15 分钟捕获的所有与 Oracle 例程相关的参数。
3.4.1.2.1. 寻找问题根源 如上所述，通过查看 v$system_event 事件开始系统事件的问题诊断。下一步是查看 v$session_event，找出引起或经历等待事件的进程。最后一步是通过v$session_wait 获得事件的细节。同时，应该进一步通过 OS 进行深入分析，了解核心的 CPU、内存和 IO 状态参数。最后，结合两种不同的诊断的结论，找出系统瓶颈所在。
3.4.1.2.2. 应用优化 从统计(和现实) 的角度看，80% 的 Oracle 系统性能问题可以通过 SQL 代码优化来解决。任何应用优化的过程，不外乎是索引优化、全表扫描、并行机制改进和选择正确数据组合方法的过程。这正是要达到最佳应用性能所必须考虑的因素。没有 SQL 的优化，就无法实现高性能的应用。良好的 SQL 语句可以减少 CPU资源的消耗，提高响应速度。同时，优化后的 SQL 语句还可以提高应用的可扩展性，这是除增加大量内存外，任何其它硬件手段也无法实现的。
3.4.1.2.2.1. I-O 优化 I-O 优化是系统优化中的一个关键步骤，还涉及到其它任务，将文件在不同驱动器/卷中进行分布，采用优化分区技术、确定 I-O 子系统瓶颈、确定控制器瓶颈并根据应用的类型选择最佳的 RAID 级。I-O 优化应该在全面了解 Oracle 及Oracle RDBMS 结构之后进行。应该在进行 I-O 优化前后实施 I-O 数据监控，如平均服务时间，IOPS，平均磁盘队列长度等。
3.4.1.2.2.2. O-S监控 数据库忙时，应该对操作系统进行监控，因为操作系统的性能指标会揭示数据库活动的性质及其对系统的影响。例如，为了了解 CPU 的利用率，可以通过system activity reporter (sar – u interval frequency) 、 mpstat (SunSolaris), top (多数 UNIX)、 osview (SGI Irix) 及 vmstat 等命令。Sar 和vmstat 也可被用于确定包括内存使用率、I-O 参数、队列等待、读取/交换区活动等信息。在 Solaris 上，mpstat utility 也可用于获取前面提到的 CPU 利用率数据。Solaris 上的 Adrian 性能管理工具也很有用。可以利用其中的一到多个工具来确定系统的性能状况，找出可能存在的瓶颈。
Oracle 数据库性能的管理需要遵循系统的方法论，以确保所有核心问题得以解决。多数问题可以事先得以管理。了解与 O-S 相关的问题是成功的关键。勿需置疑，系统硬件配置上的良好平衡也是至关重要的。必须承认， 80% 的系统 性能问题可以通过书写更好的 SQL 语句来解决。来文试图探究其余 20%中可能覆盖的内容。同时，必须遵守严格的规定，在调优目标达到后终止所有努力。了解自己想到何处是重要的，更重要的是，要知道自己何时到达了目的地。
3.4.1.2.2.3. 例程调优 n 需要配置的主要初始化参数 以下是一些已知与例程优化关系最密切的一些核心 Oracle 初始化参数。它们都会影响 Oracle 及 SGA 区的活动。任何对这些参数的改动，在实施到生产环境之前，都必须进行测试。一旦改变了生产环境的参数，就必须对相关的 Oracle动态性能指标和操作系统的性能进行监测，寻找可能由此产生的异常现象。
1) DB_BLOCK_SIZE 该参数在数据库建立前设定，决定了数据库中每个数据块的大小。只有重新建立数据库，才有可能改变该参数。db_block_size 的配置应遵循以下公式：DB_BLOCK_SIZE = FILESYSTEM BLOCKSIZE >= O-S PAGESIZE 这可以确保 Oracle获得最佳 I/O 性能，同时不会由于冗余或不必要的 I/O，给 I/O 子系统带来压力。
2) DB_BLOCK_BUFFERS 该参数决定了 SGA 区数据库缓冲区中的块数量。由于这是 Oracle 读取和写入的区域，它的不正确配置会引起严重的 I/O 性能问题。尽管缓冲区的大小与应用性质、数据库大小、同步用户数等无关，它的确是 SGA 区中最大的组件。经常可以看到缓冲区占用 75-80%SGA 区内存的情况。另外，这一参数设置过大，也会引起整个系统的内存不足，引起操作系统过多的读写操作。
该参数及 SHARED_POOL_SIZE 通常是两个最重要的 SGA 优化目标。只有当数据库缓冲率长时间低于 70%时，才需要增加其大小说。即使在这种情况下，也需要进一步审查应用的性能和整个系统的吞吐性。若存在延迟性的应用设计问题，则无论数据库缓冲区的大小如何，缓冲和读写率都不会有太大改变为。在实调优中，也曾发现由于 SQL 语句的问题，出现缓冲率很高，但仍存在全系统性能问题的情况。
3)SHARED_POOL_SIZE 该参数按字节数设定，定义了 SGA 中共享区的大小。该组件的大小严重依赖于应用的类型 (即该应用是重用 SQL，还是生成动态 SQL，等等)。同时它也取决于同步用户的数量，以及实例是否被配置成支持多线程服务器(MTS)。如果该应用采用了 MTS 配置，则共享区应该明显增加，因为光标状态和用户进程数据等程序全局区域(PGA)都被置入了共享区。
有关多数应用的 SHARED_POOL_SIZE 大小设置，可以从每 10 个同步用户 16 MB共享区开始。这不是一成不变的，因为应用的性质最终会决定该组件的大小。只有当库缓冲和字典缓冲使用率一直低于 90%时，才需要关注这一参数。但如果应用并未采用变量合并和/共离图标时，内存的数量并不会使缓冲使用率高于 90%。
共享区过大会导致处理时间增加，甚至 SQL 语句的挂起。如果应用不能有效地重用 SQL，则无论配置多大的库缓冲或字典缓冲都无济于事，不能改善缓冲使用率。
另一个值得考虑的因素是需要随时使用的存储 PL/SQL 代码数量。应用的核心包可以通过查看 DBA_SOURCE、USER_SOURCE 得以确认，其大小通过查询DBA_OBJECT_SIZE 了解。另外，为了确定存储 PL/SQL 是否被置于内存，可以查 询动态性能视图 V$DB_OBJECT_SIZE。内时，包 DBMS_SHARED_POOL 中的程序大小可被用于确定应用中大包的规模。
4) LOG_BUFFER 根据字节设定，该参数定义了 SGA 缓冲区中 redo log 的大小。缺X值通常是数据库块大小的四倍，这对于多数环境并不是最佳的。对于中型的 Oracle 环境，其结构应该为 512 Kb 左右。对该存储结构而言，更大并不意味着更好。超过 1 MB 就可能有问题。需要监控 V$SESSION_WAIT 中 log buffer space 的等待事件，优化该内存结构。需要提醒的是，在线 redo log 文件的大小设置不当，会引起 redo 请求的等待。
5) DB_WRITERS 该参数可以针对所有文件系统支持，且不可使用 Direct I-O 的 Oracle 实施设定。这并不需要与 raw partitions 一起使用，因为异步 I-O 更加。建议将该参数设定为(2 * 独立磁盘驱动器数量/卷)。该参数只有在 report.txt 中的“average write queue length”持续高于 1 时，才需要设定。在 Oracle 8.0 和更高版本中，该参数已不再被支持，而为其它两个名为 DB_WRITER_PROCESSES 和DBWR_IO_SLAVES 的参数取代。若需要设置 DB_WRITER_PROCESSES 值高于 8，则DB_WRITER_PROCESSES 可被设为 1，且 DBWR_IO_SLAVES 可被设为“n”，其中 n的值必须设置为 (2 * 独立磁盘驱动器数量/卷) 3.4.1.2.2.4. 竞争优化 多数与 Oracle 有关的竞争问题可以通过主动配置管理相关的初始化参数进行。不恰当地配置 init.ora 中的锁参数可能引起竞争。为了不打破其中的平衡，所需的参数可进行配置并主动得以处理。
包括表在内的数据库对象可能存在两个竞争点。第一个是所配置的“freelists”的数量 (缺X值为 1)。freelist 结构维护着表中可用于插入的块。对于存在大量同步插入的表，有必要配置该结构。为了以主动方式处理freelist 竞争，必须在建立表时配置 FREELISTS。可考虑的最佳值为 (2 * CPU数量) 。V$WAITSTAT 不可能指示存在 freelist 竞争，除非存在 freelist 组，而这种设置只存在于 Oracle Parallel Server 中。即便如此，也无法了解哪个表存在竞争中。主动式的 freelist 竞争调优可以事先预防问题出现。
资源竞争的第二个来源与索引有关，即对象块头中配置的事务槽数量。事务槽是块头中的区域，是事务处理进程采用自身识别号进行注册，以便任何被修改的更能够通过特定事务槽数量在低层得以识别的地方。如果所有现存的事务槽已经被其它事务占用，服务器器进程会从块的 PCTFREE 中请求 23 个字节，建立一个新的槽。这种情况适用于存在大量同步事务的对象。对于事务槽的竞争，需要设置 INITRANS 参数。对于块大小为 8K 的数据库，多数情况下，4 为最佳设置，占用的空间仅为 92 字节，却可以大大减少运行时故障和性能问题。
3.4.2. 数据库备份恢复 为了保证客户数据库系统的数据安全性，降低各种故障、灾难给客户带来的数据丢失，根据客户系统实际情况，协助客户规划实施符合客户工作要求的完善的备份恢复方案，以确保客户数据库系统的安全可靠运行。数据库的恢复与备份主要有以下几点：
n 恢复管理器(RMAN)，能使备份恢复操作自动化 n Oracle 数据泵，用以数据库的逻辑备份 n 用户管理允许用户通过操作系统命令手动备份数据库。
n 各种各样的其他的数据库备份和恢复软件，增强了 Oracle 的备份实用程序 Oracle 备份时应注意事项：当数据库处于运行状态时的热备份时，不备份活动事务；
使用比如 Oracle 工具（Oracle RAMN）或者其他的第三方软件（IBM/Tivoli的数据存储管理器）压缩 Oracle 备份数据；
如果维持数据存储空间比备份和恢复数据库时间更重要的话，可以考虑使用二进制压缩。
3.4.2.1. 查看Oracle数据库备份结果 查看 Oracle 数据库备份结果，是日常运维中必不可少的一个环节。包含：查看数据库备份日志信息，查看 backup 卷中文件产生的时间，查看 oracle 用户的 email，总共三个部分。
3.4.2.1.1. 查看数据库备份日志信息 假设：备份的临时目录为/backup/hotbakup，我们需要查看 2012 年 7 月 22日的备份结果，则用下面的命令来查看：
#cat /backup/hotbackup/hotbackup-09-7-22.log|grep –i error 备份脚本的日志文件为 hotbackup-月份-日期-年份.log，在备份的临时目录下面。如果文件中存在“ERROR:”，则表明备份没有成功，存在问题需要查看。
3.4.2.1.2. 查看backup卷中文件产生的时间 #ls –lt /backup/hotbackup backup 卷是备份的临时目录，查看输出结果中文件的日期，都应当是在当天凌晨由热备份脚本产生的。如果时间不对则表明热备份脚本没执行成功。
3.4.2.1.3. 查看oracle用户的email #tail –n 300 /var/mail/oracle 热备份脚本是通过 Oracle 用户的 cron 去执行的。cron 执行完后操作系统就会发一条 Email 通知 Oracle 用户任务已经完成。查看 Oracle email 中今天凌晨部分有无 ORA-，Error，Failed 等出错信息，如果有则表明备份不正常。
3.4.3. 数据库迁移 数据迁移是日常运维过程中存在的一个必不可少的应急方案。日常维护过程中，由于硬件的原因或其它一些外在因素需要对数据进行迁移，迁移到更加高级的主机上、迁移到远程的机房上、迁移到不同的平台下等等一些情况。对于数据迁移我公司有非常成熟的方案，从以下几种方式我们可以充分了解其优缺点：
n exp/imp：这也算是最常用最简单的方法了，一般是基于应用的 owner 级做导出导入；
u 优点是可以跨平台使用；
u 缺点是停机时间长，停机时间为从 exp 到网络传输到新库，再加上imp 的时间；
n 存储迁移：这种情况下，数据文件、控制文件、日志文件、spfile 都在存储上（一般情况下是裸设备），我们可以直接把存储挂到新机器上，然后在新机器上启动数据库；
u 优点是该迁移方式非常简单，主要的工作是主机工程师的工作，dba只需配合即可，停机时间为当库、切存储、起库的时间。
u 缺点是要求新老库都是同一平台，是相同的数据库版本。
n 利用 data guard 迁移；
u 优点是停机时间短，停机时间为 switch over 的时间。
u 缺点：主机必须双份、存储必须双份。
n 用 rman 做迁移，这种方式比较适合于跨文件系统的迁移，如同平台下的不同文件系统。
3.4.4. 数据库运维 数据库的运维主要结合各系统的实际情况，提供切实可行的运维建设机制，内容覆盖 ORACLE 数据库的日常维护、紧急故障处理，软件升级等，客户可依据服务内容进行相应的定制。我们将会提供全面的、针对性的服务解决方案，以保证客户系统稳定、高效、可靠的运行，以达到对业务系统的有效支持。
3.4.4.1. 查看数据库基本状况 对数据库的基本状况进行查看，其中包含：查看Oracle实例状态，查看Oracle服务进程，查看 Oracle 监听进程，共三个部分。
3.4.4.1.1. 查看Oracle实例状态 SQL> select instance_name,host_name,startup_time,status,database_status from v$instance; 其中“STATUS”表示 Oracle 当前的实例状态，必须为“OPEN”；
“DATABASE_STATUS”表示 Oracle 当前数据库的状态，必须为“ACTIVE”。
SQL> select name,log_mode,open_mode from v$database; 其中“LOG_MODE”表示 Oracle 当前的归档方式。“ARCHIVELOG”表示数据库运行在归档模式下，“NOARCHIVELOG”表示数据库运行在非归档模式下。在我们的系统中数据库必须运行在归档方式下。
3.4.4.1.2. 查看Oracle服务进程 $ps -ef|grep ora_|grep -v grep&&ps -ef|grep ora_|grep -v grep|wc –l 在查看 Oracle 的进程命令输出后，输出显示至少应包括以下一些进程：
n Oracle 写数据文件的进程，输出显示为：“ora_dbw0_CKDB” n Oracle 写日志文件的进程，输出显示为：“ora_lgwr_ CKDB” n Oracle 监听实例状态的进程，输出显示为：“ora_smon_ CKDB” n Oracle 监听客户端连接进程状态的进程，输出显示为：“ora_pmon_CKDB” n Oracle 进行归档的进程，输出显示为：“ora_arc0_ CKDB” n Oracle 进行查看点的进程，输出显示为：“ora_ckpt_ CKDB” n Oracle 进行恢复的进程，输出显示为：“ora_reco_ CKDB” 3.4.4.1.3. 查看Oracle监听状态 /home/oracle>lsnrctl status “Services Summary”项表示 Oracle 的监听进程正在监听哪些数据库实例，输出显示中至少应该有“CKDB”这一项。
查看监听进程是否存在：
[oracle@AS14 ~]$ ps -ef|grep lsn|grep -v grep 3.4.4.2. 查看系统和oracle日志文件 查看相关的日志文件，包含：查看操作系统的日志文件，查看 Oracle 日志文件，查看 Oracle 核心转储目录，查看 Root 用户和 Oracle 用户的 email，总共四个部分。
3.4.4.2.1. 查看操作系统日志文件 # cat /var/log/messages |grep failed 查看是否有与 Oracle 用户相关的出错信息。
3.4.4.2.2. 查看oracle日志文件 [oracle@AS14 ~]$ cat /data/oracle/admin/CKDB/bdump/alert_CKDB.log |grep ora- [oracle@AS14 ~]$ cat /data/oracle/admin/CKDB/bdump/alert_CKDB.log |grep err [oracle@AS14 ~]$ cat /data/oracle/admin/CKDB/bdump/alert_CKDB.log |grep fail Oracle 在运行过程中，会在警告日志文件(alert_SID.log)中记录数据库的一些运行情况：数据库的启动、关闭，启动时的非缺X参数；
数据库的重做日志切换情况，记录每次切换的时间，及如果因为查看点(checkpoint)操作没有执行完成造成不能切换，会记录不能切换的原因；
对数据库进行的某些操作，如创建或删除表空间、增加数据文件；
数据库发生的错误，如表空间不够、出现坏块、数据库内部错误(ORA－600)等。定期查看日志文件，根据日志中发现的问题及时进行处理：
问题 处理 启动参数不对 查看初始化参数文件 因为查看点操作或归档操作没有完成造 成重做日志不能切换 如果经常发生这样的情况，可以考虑增加重做日 志文件组；
想办法提高查看点或归档操作的效率；
有人未经授权删除了表空间 查看数据库的安全问题，是否密码太简单；
如有 必要，撤消某些用户的系统权限 出现坏块 查看是否是硬件问题(如磁盘本生有坏块)，如果不 是，查看是那个数据库对象出现了坏块，对这个 对象进行重建 表空间不够 增加数据文件到相应的表空间 出现 ORA-600 根据日志文件的内容查看相应的 TRC文件，如果 是 Oracle的 bug，要及时打上相应的补丁 Listener 日志：$ORACLE_HOME/network/log 3.4.4.2.3. 查看Oracle核心转储目录 $ls $ORACLE_BASE/admin/CKDB/cdump/*.trc|wc -l $ls $ORACLE_BASE/admin/CKDB/udump/*.trc|wc –l 如果上面命令的结果每天都在增长，则说明 Oracle 进程经常发生核心转储。这说明某些用户进程或者数据库后台进程由于无法处理的原因而异常退出。频繁的核心转储特别是数据库后台进程的核心转储会导致数据库异常终止。
3.4.4.2.4. 查看Root用户和Oracle用户的email #tail –n 200 /var/mail/root #tail –n 200 /var/mail/oracle 查看有无与 Oracle 用户相关的出错信息。
3.4.4.3. 查看Oracle对象状态 查看相关 Oracle 对象的状态，包含：查看 Oracle 控制文件状态，查看 Oracle在线日志状态，查看 Oracle 表空间的状态，查看 Oracle 所有数据文件状态，查看 Oracle 所有表、索引、存储过程、触发器、包等对象的状态，查看 Oracle 所有回滚段的状态，总共六个部分。
3.4.4.3.1. 查看Oracle控制文件状态 SQL> select status,name from v$controlfile; 输出结果应该有 3 条以上（包含 3 条）的记录，“STATUS”应该为空。状态为空表示控制文件状态正常。
3.4.4.3.2. 查看Oracle在线日志状态 SQL> select group#,status,type,member from v$logfile; 输出结果应该有 3 条以上（包含 3 条）记录，“STATUS”应该为非“INVALID”，非“DELETED”。注：“STATUS”显示为空表示正常。
3.4.4.3.3. 查看Oracle表空间的状态 SQL> select tablespace_name,status from dba_tablespaces; 输出结果中 STATUS 应该都为 ONLINE。
3.4.4.3.4. 查看Oracle所有数据文件状态 SQL> select name,status from v$datafile; 输出结果中“STATUS”应该都为“ONLINE”。或者：
SQL> select file_name,status from dba_data_files; 输出结果中“STATUS”应该都为“AVAILABLE”。
3.4.4.3.5. 查看所有回滚段状态 SQL> select segment_name,status from dba_rollback_segs; 输出结果中所有回滚段的“STATUS”应该为“ONLINE”。
3.4.4.4. 查看Oracle相关资源的使用情况 查看 Oracle 相关资源的使用情况，包含：查看 Oracle 初始化文件中相关的参数值，查看数据库连接情况，查看系统磁盘空间，查看 Oracle 各个表空间使用情况，查看一些扩展异常的对象，查看 system 表空间内的内容，查看对象的下一扩展与表空间的最大扩展值，总共七个部分。
3.4.4.4.1. 查看Oracle初始化文件中相关参数值 SQL> selectresource_name,max_utilization,initial_allocation,limit_value from v$resource_limit; 若 LIMIT_VALU-MAX_UTILIZATION<=5，则表明与 RESOURCE_NAME 相关的Oracle 初始化参数需要调整。可以通过修改 Oracle 初始化参数文件$ORACLE_BASE/admin/CKDB/pfile/initORCL.ora 来修改。
3.4.4.4.2. 查看数据库连接情况 查看当前会话连接数，是否属于正常范围。
select sid,serial#,username,program,machine,status from v$session; n 其中：SID 会话(session)的 ID 号；
n SERIAL#会话的序列号，和 SID 一起用来唯一标识一个会话；
n USERNAME建立该会话的用户名；
n PROGRAM这个会话是用什么工具连接到数据库的；
n STATUS当前这个会话的状态，ACTIVE 表示会话正在执行某些任务，INACTIVE 表示当前会话没有执行任何操作；
如果建立了过多的连接，会消耗数据库的资源，同时，对一些“挂死”的连接可能需要手工进行清理。如果 DBA 要手工断开某个会话，则执行：（一般不建议使用这种方式去杀掉数据库的连接，这样有时候 session 不会断开。容易引起死连接。建议通过 sid 查到操作系统的 spid,使用 ps –ef|grep spidno 的方式确认 spid 不是 ORACLE 的后台进程。使用操作系统的 kill -9 命令杀掉连接） alter system kill session ＇SID,SERIAL#＇; 注意：上例中 SID 为 1 到 10(USERNAME 列为空)的会话，是 Oracle 的后台进程，不要对这些会话进行任何操作。
3.4.4.4.3. 查看系统磁盘空间 如果文件系统的剩余空间过小或增长较快，需对其进行确认并删除不用的文件以释放空间。
[oracle@AS14 ~]$ df –h 3.4.4.4.4. 查看表空间使用情况 SQL> select f.tablespace_name,a.total,f.free,round((f.free/a.total)*100) “% Free“ from (select tablespace_name, sum(bytes/(1024*1024)) total from dba_data_files group by tablespace_name) a, (select tablespace_name, round(sum(bytes/(1024*1024))) free from dba_free_space group by tablespace_name) f WHERE a.tablespace_name = f.tablespace_name(+) order by “% Free“; 如果空闲率%Free 小于 10%以上（包含 10%），则注意要增加数据文件来扩展表空间而不要是用数据文件的自动扩展功能。请不要对表空间增加过多的数据文件，增加数据文件的原则是每个数据文件大小为 2G 或者 4G，自动扩展的最大限制在 8G。
3.4.4.4.5. 查看一些扩展异常的对象 sql>select Segment_Name, Segment_Type, TableSpace_Name, (Extents/Max_extents)*100 Percent From sys.DBA_Segments Where Max_Extents != 0 and (Extents/Max_extents)*100>=95 order By Percent; 如果有记录返回，则这些对象的扩展已经快达到它定义时的最大扩展值。对于这些对象要修改它的存储结构参数。
3.4.4.4.6. 查看对象的下一扩展与表空间的最大扩展值 sql>select a.table_name, a.next_extent, a.tablespace_name from all_tables a, (select tablespace_name, max(bytes) as big_chunk from dba_free_space group by tablespace_name ) f where f.tablespace_name = a.tablespace_name and a.next_extent > f.big_chunk union select a.index_name, a.next_extent, a.tablespace_name from all_indexes a, (select tablespace_name, max(bytes) as big_chunk from dba_free_space group by tablespace_name ) f where f.tablespace_name = a.tablespace_name and a.next_extent > f.big_chunk; 如果有记录返回，则表明这些对象的下一个扩展大于该对象所属表空间的最大扩展值，需调整相应表空间的存储参数。
3.4.4.5. 查看数据库安全性 查看 Oracle 数据库的安全性，包含：查看系统安全信息，定期修改密码，总共两个部分。
3.4.4.5.1. 查看系统安全日志信息 系统安全日志文件的目录在/var/log 下，主要查看登录成功或失败的用户日志信息。
查看登录成功的日志：
[root@rac2 ~]# grep -i accepted /var/log/secure 查看登录失败的日志：
[root@rac2 ~]# grep -i inval /var/log/secure &&grep -i failed /var/log/secure 在出现的日志信息中没有错误(Invalid、refused)提示，如果没有(Invalid、refused)视为系统正常，出现错误提示，应作出系统告警通知。
3.4.4.5.2. 查看用户修改密码 在数据库系统上往往存在很多的用户，如：第三方数据库监控系统，初始安装数据库时的演示用户，管理员用户等等，这些用户的密码往往是写定的，被很多人知道，会被别有用心的人利用来攻击系统甚至进行修改数据。需要修改密码的用户包括：
n 数据库管理员用户 SYS，SYSTEM；
其他用户。
n 登陆系统后，提示符下输入 cat /etc/passwd，在列出来的用户中查看是否存在已经不再使用的或是陌生的帐号。若存在，则记录为异常。
修改密码方法：
Sql>alter user USER_NAME identified by PASSWORD; 3.4.4.6. 其他查看 查看当前 crontab 任务是否正常，查看 Oracle Job 是否有失败等共六个部分。
3.4.4.6.1. Oracle Job是否有失败 Sql>selectjob,what,last_date,next_date,failures,brokenfromdba_jobsWhereschema_user=＇CAIKE＇; 如有问题建议重建 job，如：
exec sys.dbms_job.remove(1); commit; execsys.dbms_job.isubmit(1,＇REFRESH_ALL_SNAPSHOT;＇,SYSDATE+1/1440,＇SYSDATE+4/1440＇); commit; 3.4.4.6.2. 监控数据量的增长情况 SQL> select 2 A.tablespace_name,(1-(A.total)/B.total)*100 used_percent 3 from (select tablespace_name,sum(bytes) total 4 from dba_free_space group by tablespace_name) A, 5 (select tablespace_name,sum(bytes) total 6 from dba_data_files group by tablespace_name) B 7 where A.tablespace_name=B.tablespace_name; 根据本周每天的查看情况找到空间扩展很快的数据库对象,并采取相应的措施：
n 删除历史数据 移动规定数据库中至少保留 6 个月的历史数据，所以以前的历史数据可以考虑备份然后进行清除以便释放其所占的资源空间。
n 扩表空间 alter tablespace <tablespace_name> add datafile ‘<file>’ size <size>autoextend off; 注意：在数据库结构发生变化时，如增加了表空间，增加了数据文件或重做日志文件这些操作，都会造成 Oracle 数据库控制文件的变化，DBA 应及进行控制文件的备份，备份方法是：
执行 SQL 语句：
alter database backup controlfile to ＇/home/backup/control.bak＇; 或：
alter database backup controlfile to trace; 这样，会在 USER_DUMP_DEST(初始化参数文件中指定)目录下生成创建控制文件的 SQL 命令。
3.4.4.6.3. 查看无效的trigger SELECT owner, trigger_name, table_name, status FROM dba_triggers WHERE status = ＇DISABLED＇; 如有失效触发器则启用，如：Sql>alter Trigger TRIGGER_NAME Enable; 4. 系统技术支持及预防性维护方案 一个系统开发与实施的成功与否，很大程度上取决于使用单位对该系统的使用情况，一个再好的系统如果没有人使用，那么也不能说该系统是成功的，只能说它是失败的。所以我公司尤其重视对使用单位的人员针对系统的使用培训，并根据不同的使用权限及功能进行有针对性的培训服务。
4.1. 售后服务 我公司设有专门的技术支持中心,为客户提供快捷周到的服务。技术支持中心有完善的售后服务体系,包括电话支持、电子邮件、远程网络支持、现场响应、紧急恢复等。可快速响应各用户的服务请求，随时为客户提供优质的技术服务。
4.2. 电话支持 当系统发生问题时，用户可以从客服专线得到及时有效的 24 小时电话支持。客户服务人员做好客户服务需求的记录，并向用户明确服务需求的解决方式、进程和最终的解决办法。我公司将提供终身 7×24 小时热线电话支持。提供远程服务器接入、邮件和电话服务支持。
4.3. 现场服务 如果用户的问题不能通过电话解决，客户服务部会立刻派经验丰富的工程师到现场为用户解决问题，客户服务人员对解决的过程进行记录，并向用户提供解决问题的报告．包括问题原因、解决方法、解决问题的方式和进程，以及建议用户对系统进行正常使用的指导和培训．问题解决后需要用户进行确认。
4.4. 定期巡检服务 根据招标文件的技术要求，我公司定期对系统进行运维巡检服务，并出具巡检报告，发现并预防可能产生的问题；
巡检完成后，于次月的 5 日前提交上月度的巡检报告。
巡检内容包括：系统日志、网络状况、系统空间状况、存储设备状态、系统性能、产品参数与配置、数据库各种文件的状态与配置、数据库安全审计、数据对象配置的合理性、实例的运行效率、SQL 代码性能调优等。
5. 项目管理体系 5.1. 概述 项目管理主要包括管理组织、计划管理、质量控制、文档管理、风险管理及范围控制等部分内容。
5.1.1. 管理组织 系统的实施开发涉及大量的业务处理流程与用户核心的管理理念与组织架构,必须得到各部门的通力合作,尤其是业务部门骨干的参与。
因此建议进行二级项目管理。即：
A：项目指导委员会 Ø Ø 负责项目的组织、协调和推广工作。
Ø Ø 将委派相应人员担任方项目总协调人。
Ø Ø 建议客户选派专人担任用户方项目总监，负责整个项目的实施。
B：项目管理小组、项目经理 项目经理全权负责项目管理，负责业务和技术方面的协调。职责如下：
Ø Ø 作出项目实施计划 Ø Ø 安排资源，协调项目组成员的工作 Ø Ø 保证项目按规定的标准和质量进行 Ø Ø 定期提交项目进展情况报告、及时提出需要解决的问题 Ø Ø 管理项目风险 Ø Ø 控制项目预算 Ø Ø 工作进度管理 5.1.2. 计划管理 根据项目进度的要求，制定切实可行的工作计划，规定每个成员的任务，查看任务完成的情况和质量，是保证项目顺利实施的重要保证。工作计划管理应包括以下几点：
Ø Ø 按周做出工作计划，并经双方批准。
Ø Ø 每周进行工作量统计，质量查看，并由客户签字。
Ø Ø 每周做出工作小结，说明未完成原因及改进建议。
Ø Ø 工作分解到人。
Ø Ø 项目经理应随时协调每人的工作，避免重复或脱节。
5.1.3. 质量管理 建议由双方项目经理对项目实施质量进行控制。包括：
Ø Ø 工作质量的审查与评定 Ø Ø 工作质量的测试 Ø Ø 工作过程的控制和资料的完整性 Ø Ø 负责归集客户签署的阶段成果确认书 质量审查 审查是以计划的内容为基础，以目标和方法为依据，对所用的各种技术工作进行描述，同时提交执行文档和软件，所有提交审查的记录将会作为项目审计线索被保存。
测试管理 一般包括以下几部分：
Ø Ø 模块测试：保证/验证一个独立模块的功能。
Ø Ø 系统测试：保证/验证在此项目内功能区之间的功能。
Ø Ø 集成测试：保证/验证在项目整个应用区域内的整体功能。
Ø Ø 测试结果确认。
在进行上述各类测试前，双方项目经理必须先拟定测试计划，确定测试数据和可接受的测试结果。
5.1.4. 文档管理 在项目实施过程中，由于项目实施的复杂性，多方人员参加以及时间跨度长等因素，所以任何需求、建议、解决方案和结论都必须文档化、标准化，以便查阅和引用。实施文档应作为项目成果的一个组成部分。
下列项目资料将在实施期间收集：
1. 各类设计，测试文档。包括：
l l 项目管理文档 l l 客户化文档和模块开发文档 l l 客户提交的需求文档 l l 客户需求改变报告和批准书 l l 测试方案和测试结果报告 l l 客户签署的阶段成果确认书 l l 项目总结报告 2. 建立需求变更表和日志 3. 建立问题与风险报表和日志 4. 建立周阶段工作总结报告 5. 建立会议备忘录和日志 5.1.5. 风险管理 1).用户不能准确表达需求/用户技能的限制 在大型系统实施时，首先要对用户现场的现状及用户需求做详尽的描述。通常由于用户人员对自己的业务理解还在不断的深化，因此往往在实施应用系统时用户对需求的描述会随着实施的不断深入而有所改变，造成系统需求的不稳定。
为避免此风险，可按下列方法实施：
1. 第一阶段：在其它项目上的经验的再利用 2. 所拥有的资深专家在项目实施过程中，将技能传授给项目小组。
3. 客户项目小组的通力合作和大力支持。
2).实施范围的不断扩大及项目延期 通常在实施过程中，用户会对项目开始时所提出的目标和要求有所变化，造成实施范围的不断扩大和项目实施的延期，最终使项目搁浅。
为避免这种情况的发生，我们应该：
1. 建立项目实施管理小组，明确项目的目标和各自的权限；
处理项目实施的成本，明确预算控制。
2. 配备经验丰富的项目经理。
3. 定期向项目的高层管理部门和用户报告项目实施的进展及存在的问题。
4. 控制实施范围的变化──形成书面文档、陈述更改原因，待高层管理部门批准后方可实施更改。
5. 建立当项目实施出现问题时进行汇报和解决的标准工作流程。
3).缺乏多厂商之间的相互协调和各厂商所负的责任不清 1. 项目实施所涉及的厂商很多，包括硬件、数据库、应用软件、第三方软件、网络或集成商等，在项目实施过程中需要多方协调、通力合作，只有这样才能保证项目保质保量、如期完成。
2. 为减少项目实施的协调工作，尽量减少供应商实施方数目。
3. 在项目实施时，要分清实施项目的责任范围。
4).系统技能和技术风险 对项目实施而言，选择一个好的应用系统是十分重要的，一个好的应用系统的标准是：
1. 该产品必须是灵活的。
2. 该产品有很好的系统性能，包括：有一个好的技术结构。
3. 有良好的技术基础，建立在开放系统上，有先进的开发工具。
5).领导层的全力支持 领导层的全力支持是必不可少的。我们必须尽一切可能争取他们的关心和支持，以保障跨部门协作顺畅。
6).避免各类人员业务水平不一对项目实施的影响 在选择项目成员时强调项目成员应有较强的业务背景,业务水平和较强的接受新事物能力。
在业务流程和需求分析时采取启发式询问，多人多岗位调查然后综合以及到业务现场调查等方法。
在实施过程中介绍新系统体现的管理思想。
7).避免实施开发人员变更影响项目进度 我们建议所有实施开发人员所作的工作都应有文档记录，经客户方确认的文档应交由专人保管，包括纸张和电子介质。
所有的需求，承诺和解决方案等均以书面签字为准。不得随便更改其中的内容。除非通过同样的审批程序进行。
这样新的实施人员可以通过阅读上述文档，很快进入工作状态。对前任工作成果的修改控制可避免一些不必要的返工。
5.1.6. 范围控制 保持项目实施范围的前后一贯性是非常重要的。如果出现需要改变原定实施范围的需求，都应以正式文档方式提出，项目小组成员必须谨慎考虑项目范围的改变将对整个项目进程可能产生的影响。必须在批准后才能进行。在实施过程中必须加以跟踪。
范围改变文档内容 l 说明范围改变内容，理由。
l 说明改变部分在项目进程中的状态。
l 评估改变部分对项目进程可能的影响。
l 评估改变部分对项目费用可能的影响。
批准程序 提出实施范围改变请求报告。
凡涉及到整个项目进展，费用成本调整较大的改变，必须交由项目开发实施领导小组批准通过。
跟踪执行 范围改变书签字后，开始正式执行。
调整相应的实施计划。
任务完成进度报告应当定期提交项目双方查看，完成后应当由双方项目经理签字。
5.1.7. 沟通机制 项目例会 在项目实施期间，每周五下午15：00定时召开项目例会，双方项目组负责人及关联成员须按时参加，交流讨论项目工作进度情况，并以会议备忘录形式记录会议内容和决议，同时由双方项目组负责人签字确认存档。
工作周报 在项目实施期间，每周五上午11：00以前项目组负责人向客户项目负责人提交项目实施开发工作周报（包含下周的工作计划及本周工作完成情况），如实反映一周工作的完成情况并报告项目进度情况和实施成果。
问题管理 在项目实施过程中如出现问题时，需在问题管理表详细描述记录问题情况并向双方项目组负责人进行汇报，双方应组织相关人员进行充分沟通、分析问题原因、找出解决方案，并确定问题跟踪的双方责任人 5.2. 项目实施方案 5.2.1. 项目实施策略 项目的实施成功与否主要表现为“两个机制、一个测试”：顺畅沟通机制和 技术转移机制、模拟测试。
n 顺畅沟通机制：建立和用户方的良好顺畅的协调机制；
n 技术转移机制：系统在移交后，日常的管理工作有比较大的专业性，成功的技术转移是以后系统良好运作的前提和保证。建议用户方的技术牵头人和系统管理员对项目的全程深入参与。
n 模拟测试：通过在模拟环境完成系统调试后并在真实环境完成试运行测试。
因而在本次日常运行维护服务的过程中，我公司也将按照软件项目实施的策略来进行管理，从而保证整个项目的维护就如同开发过程一样严格管理。
5.2.2. 项目实施计划 信息系统日常运行维护年度服务项目是一个长期的优化维护项目，本项目我公司根据多年的开发维护经验可分为两个阶段。第一个阶段为优化实施阶段，包括各个应用系统的环境情况调查，应用系统的统计登记、数据库系统的优化等。第二个阶段为运维阶段，主要包括相关应用的培训，数据库管理培训、数据库备份恢复的培训以及后期系统运维、查看等保护措施，定期对全厂数据库及系统进行巡检，巡检内容包括：系统日志、网络状况、系统空间状况、存储设备状态、系统性能、产品参数与配置、数据库各种文件的状态与配置、数据库安全审计、数据对象配置的合理性、实例的运行效率、SQL 代码性能调优等。
5.2.3. 项目交付文档 5.2.3.1. 交付要求 我公司提供的资料将使用国家法定单位制即国际单位制，语言为中文。提供的纸介质文件时需同时提供 Office 电子版文件。
资料的组织结构清晰、逻辑性强。资料内容正确、准确、一致、清晰完整，满足项目要求。
5.2.3.2. 提交文件资料 文档的内容至少包括系统的维护手册、数据库定期巡检记录、数据库日常运维手册、文档介质包括 n 系统信息表 n 数据库日常运维手册 n 数据库定期巡检记录表 n 应用系统巡检记录 n 其他相关的技术资料 5.3. 项目组织 项目小组是实施本项目的直接执行人，负责按照本工作说明书确定的实施范围，组织项目实施工作，保证服务质量，并解决实施过程中遇到的技术方面的问题。项目组包括项目经理、需求分析师、开发工程师、实施工程师，总体职责如下：
1. 保证与项目有关的的问题得到及时解决 2. 提供有关产品的技能和以往经验 3. 计划、协调项目实施过程中各个方面的工作 4. 建立项目环境和项目组结构 5. 依据项目计划充分调动资源，并做好这些资源的后勤保障，并在必要时候，寻求更高层次的支持 6. 针对客户未来的工作流程重组提出建议 7. 从总体上控制项目实施时间进度，保证服务质量 l 客户经理 客户经理配合客户项目经理负责计划、组织、指导和协调项目组的工作，并在适当的时候，负责项目组内部和其他有关方面的相互沟通，项目的关键查看点，对项目各方面进行查看与指导，主要职责如下：
1. 建议项目的阶段审核点 2. 制定项目计划 3. 规定培训内容及过程，制定培训及后勤计划 4. 指导、建议、管理项目日常活动 5. 管理项目初始变更及变更过程 6. 定期向项目领导及项目指导委员会汇报项目的进展状况，并提出问题改进措施 7. 协助客户通报并解决出现的问题 8. 合理分配项目人员 9. 计划、组织系统集成的执行 10. 确认任务的完成，实施质量控制 11. 发现、协调相互沟通/变更控制/组织方面等问题 12. 完成项目状态报告 13. 项目实施程序、原则标准的建立与执行 14. 项目组成员在团队内的有效工作 15. 负责监督项目实施质量 16. 负责完成项目监督报告 l 技术经理 技术经理责如下：
1. 主持需求调研和讨论会 2. 分析现有工作流程 3. 确定用户功能需求并协助制作文档 4. 设计未来工作流程 5. 指导培训计划的制定与培训后勤工作的展开 6. 为关键用户提供标准产品培训 7. 根据功能需求确定产品的功能和流程选择 8. 计划测试，并预估测试所需资源 9. 制定测试方案 10. 协助制定系统测试过程和测试所需的业务案例 11. 协助监控、评估测试的执行 12. 为最终用户培训提供指导和建议 13. 定义基础数据转换步骤和策略 l 技术人员 技术人员的主要职责如下：
1. 提供系统运行环境配置建议和优化措施 2. 产品的安装及系统管理员的培训 3. 负责产品所需基础资料的数据整理及导入系统 4. 负责关键用户的使用培训 5. 负责需求的调研工作 6. 负责培训资料的制作 6. 技术服务流程管理方案 6.1. 制定规章制度 制定规章制度是为了提高技术部服务效率、服务质量及售后响 应时间。技术部一定会精诚团结做到客户零投诉。 6.2. 方案设计 1） 客户故障致电后，需和客户约好维修时间，去现场之前给客户打电话确认客户是否在现场.如确实事情比较多和客户约好的维修时间去不了，需给客户打电话解释，希望客户能谅解，在约维修时间. 2） 在维修的过程中如遇到疑难解决的问题，需及时跟国内市场部联系，不能拖在那不解决.如和国内市场部联系后还不能及时解决，应给客户解释，并承诺解决的时间. 3） 维修结束后一定要让客户签售后维修单. 4） 每天下班后技术部同事需在一起碰头，把当天没解决遗留问题和第二天的工作安排说清楚，这样有利于第二天整个技术部的工作安排。
7. 应急预案 当系统出现紧急情况时，无论是正常工作时间或非工作时间，我公司在确认后立即派工程师进行电话支持和远程支持，同时派工程师赴现场提供紧急技术支持。如 Oracle 系统不能正常工作，发生严重影响正常生产经营管理的紧急故障，要求 10 分钟内通过电话、远程控制工具远程响应，指导客户方工程师操作，在30分钟提交解决方案，1小时内派出技术专家到客户现场，并以最快的速度解决系统故障。
8. 驻场人员管理制度 8.1. 人员管理制度 1）工作时间内不应无故离岗、串岗，不得闲聊、吃零食、大声喧哗，确保办公环境的安静有序。
2）员工在工作时间必须全身心地投入，保持高效率地工作。
3）员工在任何时间均不可利用公司的场所、设备及其他资源从事私人活动。一经发现，给予警告，情节严重者，公司将予以辞退。
8.2. 人员更换方案 1） 变更前所有工作交接 2） 向客户方提交变更说明书 3） 项目经理统一安排人员工作调整 8.3. 后勤保障措施 （1）工作长计划短安排，统筹兼顾，要有轻重缓急，安排工作要密度合理，提前计划和商量，提前安排，不要使后勤人员在某一段时间内无事可做。
（2）严格上下班时间，不定期查岗和考勤。
（3）明确后勤人员各自的工作范围和职责，避免推委扯皮现象。
（4）工作安排后要检查落实，限定完成时间。
9. 培训方案 9.1. 培训方案设计 人员培训作为工程实施的一个重要环节，对整个项目的实施至关重要，通过系统的培训，使得工作人员得到日常工作需要的专业技术知识和经验，从而保障整个系统的顺利运行。 项目建设最终系统将交付用户使用，项目培训是项目实施中的重要环节， 通过项目培训对业主人员进行全面的技术培训，使业主单位人员达到能独立进行管理、故障处理、日常测试维护等工作，以便于我方提供的软、硬件能够正常、安全的运行。
9.2. 培训形式 为了使培训达到最佳效果，使用户获得尽可能多的知识和经验，我们将采用多种途径对用户进行培训：l n 授课：由专业资深的教师，在现场对用户进行培训，培训包括软件的安装，调试，测试，参数配置等。通常由课堂讲授和现场操作讲授组成，通常由用户的使用手册支持，适当的操作为辅助。l n 现场指导：在项目执行过程中，我们的工程时在实际操作中，会详细讲解操作步骤，指导客户操作，并解答客户的问题。l 交流会：在项目执行过程中，我们会经常与客户相互交流工作的经验、存在的问题。
9.3. 培训对象 根据XXXX信息中心的有关意见，用户将凭本次系统建设的机会培训一批自己的管理和维护队伍。
系统维护人员是指对项目中进行管理和维护的人员。这部分人员经过培训，主要能达到以下目标：
n 掌握系统的初始化和主要参数的设定方法；
n 对一般性故障进行诊断、定位和排除；
n 掌握系统故障后的恢复方法；
n 熟练查阅各种系统操作和维护手册；
n 配合我公司进行系统的维护和故障修复；
n 指导一般操作人员的工作。
9.4. 培训需求 本项目中的培训主要包括功能培训和应用系统技术培训两部分。
功能培训，用于对本系统的所有业务功能进行培训，通过培训，使不同岗位、不同角色的用户都可以掌握系统的操作方法。
通过应用系统技术培训，使用户单位系统运行管理人员既具有系统技术原理的理论基础，又具有进行系统维护的实际操作能力。
9.5. 培训目的 通过应用系统技术培训，可以使应用系统技术培训对象是项目单位的技术人员以及各职能部门负责人，主管领导。
培训方案的目的是为了项目单位的技术人员能够有效地管理和维护应用系统，确保系统可靠运行，服务于XXXXXXX信息系统，该信息系统平台不仅需要成熟稳定的产品，更需要技术熟练的运行维护人员，以便能更好地进行科学有效的运行维护工作。而一名合格的运行维护人员，就需要经过严格有效的专业培训，掌握专门的技能才能胜任。我公司将为XXXXX所有负责维护系统的相关系统主管人员、操作人员、系统管理人员等进行系统化、一体化的培训，培训涉及到oracle维护方案、服务器维护与配置、存储维护与配置等知识的综合性培训，以确保相关科技人员能够独立进行管理、运行、故障处理及日常测试维护等工作，使该系统能够得到正确的应用和良好的维护，保证整个信息系统可以健康、稳定的运行。
9.6. 培训目标 为了满足项目单位的培训需求，将安排优秀的讲师，准备教材，精心组织培训。此次培训将达到以下目标：
n 通过对业务人员进行培训，使不同岗位的工作人员都可以熟练掌握系统的业务规则和操作流程，从而提高系统应用水平，充分发挥软件性能。
n 通过对技术人员进行培训，使他们掌握软件的配置与维护方法；
同时公司将为此提供全面开放的实践交流环节，通过多种形式的技术交流与动手实践，学员将更好地掌握系统建设中使用的技术，顺利地承担本系统的维护管理工作。
通过相关培训，使技术人员可以了解、掌握、提高与系统紧密衔接的计算机网络及软件知识；
使业务人员提高计算机应用水平，从而提升应用单位的整体计算机水平，促进单位内部信息化建设。
9.7. 培训方式 应用系统技术培训采用集中培训的组织形式，在用户现场为用户开设培训课程。
n 培训时间和地点 培训时间和地点安排由用户和我公司协商决定。
n 培训费用 由用户和我公司协商决定。
9.8. 培训教材 培训相关手册 我们提供简明易懂的培训资料和讲义，所有资料以中文形式提供。给每个科室发一个针对该科室的系统操作手册，用于日常查看。
9.9. 培训课程 免费提供的技术培训课程主要包括软件的安装，调试，测试，参数配置等。
具体培训课程安排与内容如下：
软硬件平台Oracle 、WebLogic 、sql server2005 、Lifekeeper7 、Vmware 5.0 、Tomcat 、Windows、 Linux 我们的目标就是为您提供综合性的、专门的服务与支持，让您能够利用计算机稳定、可靠、方便地工作。用户的利益即是我们的利益，最终用户在我们公司所享受到的将是全方位的支持。无论是现在还是将来，我们公司都会让您得到最满意的服务。系统维护及售后服务 10. 文档管理方案 ○项目文件集中存放、统一备份、统一访问、统一授权 ○文件可以根据项目进行分类与查看，项目文档可以根据业务需要自定义项目属性，如项目名称、标识、类型、责任人等。
○ 项目文档的产生、批准、更新、归档、查询都可以通过工作流来实现标准化与规范化管理。
○ 项目文档之间可以进行互动关联，如项目章程可以与项目范围说明书关联。
○支持项目文件清单并支持将清单导出 11. 服务质量监督管理办法 11.1. 目的 为了加强服务质量的精确化管理，贯彻“用户至上，用心服务”的服务理念，增强员工服务意识和质量观念，使客户服务质量受控，提高客户的满意度和忠诚度。
11.2. 工作程序 11.2.1. 服务质量监督内容 以客户投诉、客户表扬、客户满意度评价及服务改进措施的执行情况为主要监管内容；
其他相关规范的执行情况作为阶段性监管内容。
11.2.2. 监管环节 服务质量监管主要从业务开展、业务合作和服务跟踪三个阶段对服务质量关键点进行监管。
(一)业务开展：包括对各项目岗位人员服务的及时性、服务态度良好性、服务记录准确性、业务开展合理性等方面进行服务质量监控。
(二)业务合作：主要对业务开展过程中沟通的及时性、合作方案执行规范性和业务合作质量的稳定性进行监管。
(三)服务跟踪：对业务开展后的服务进行监督，通过服务对象满意度测评、专项服务回访等方式，了解服务对象的感知，提升服务质量，确保服务跟踪的及时性和信息反馈的准确性。
11.2.3. 监管客户投诉 ● 监控是否发生有责投诉；
● 投诉处理质量（及时率、合格率、满意率）是否达到公司要求；
Ø ● 每月是否形成了客户部投诉分析报告；
Ø ● 报告中的改进意见是否传递到相关责任部门；
Ø ● 相关责任部门是否按改进意见制订了措施并进行整改；
Ø ● 验证改进措施的完成情况。
