软件项目维护方案参考示例.docx
《软件项目维护方案参考示例.docx》由会员分享，可在线阅读，更多相关《软件项目维护方案参考示例.docx（51页珍藏版）》请在冰豆网上搜索。
软件项目维护方案参考示例
软件项目维护方案
1.项目背景及目标
1.1.项目背景
在国家政策的指导和帮助下，信息化也越来越发挥出十分重要的作用。
不断加大信息化管理工作力度，积极实施“上网工程”，大力推进全市局域网建设，加快办公自动化系统进程，信息技术在改革中发挥了重要的支撑作用，为充分发挥政府公共职能，促进依法理财、科学理财，提供了重要的信息技术保障。
近年来建设各系统随着数据量的逐年增加，陆续出现了性能问题，有必要进行数据库系统的升级及性能优化，以确保应用系统的正常运行，为单位员工提供更好的信息服务。
1.2.项目目标
●对各系统数据库进行补丁升级服务，安装补丁前制定详细的升级计划和应急回退计划。
●完成各系统数据库的性能调优工作。
●各业务持续性得到有效的保证。
2.需求分析
项目，我公司有多年的行业经验。
具有对运维服务对象进行适时监测、指标分析、和及时修复的能力。
产品日常运行维护项目主要从如下几个方面进行：
（1）.每天对数据库的运行状态,日志文件,备份情况,数据库的空间使用情况,系统资源的使用情况进行查看,发现并解决问题。
（2）.每周对数据库对象的空间扩展情况,数据的增长情况进行监控,对数据库做健康查看,对数据库对象的状态做查看。
（3）.查看表空间碎片,提出下一步空间管理计划。
对数据库状态进行一次全面查看。
（4）由于这些数据库系统承载着非常重要的业务系统数据，所以在日常
维护中需要非常仔细，每周、每月、每季都需要有相应的巡检记录，需要详细记载以下一些内容：
⏹监控数据库对象的空间扩展情况
⏹监控数据量的增长情况
⏹系统健康查看，查看以下内容:
⏹数据库对象有效性查看
⏹查看是否有危害到安全策略的问题。
⏹查看、等日志并归档报错日志
⏹分析表和索引
⏹查看对数据库会产生危害的增长速度
⏹查看表空间碎片
⏹数据库性能调整
⏹预测数据库将来的性能
⏹调整和维护工作
⏹后续空间
3.整体运行维护服务方案
3.1.维护
3.1.1.验证的安装
查看已经安装的软件包，可以使用命令：
–
3.1.2.启动
a）启动服务器进程
如果当前您的系统没有运行则在所有服务器上以用户身份输入如下命令
#
b）启动服务器进程
同样以用户运行命令
#
注意：
以上命令只需运行一次，以后每次系统重新启动时，会自动运行上述进程
3.1.3.有关的软件的其它管理任务
a）停止服务
如果需要在服务器上永久停止服务，可以输入下列命令
$
该命令同时会使所有保护的资源处于退出服务状态，如果希望在停止时保持资源/应用的运行，可以使用：
$
b）查看进程
键入下列命令可以查看当前运行的所有进程列表
|
3.1.4.启动配置工具
进入管理工具可以通过运行命令：
则出现登录界面：
可以使用用户登录，也可以使用新建的用户进行登录。
3.1.5.检测集群运行状态
可以使用命令对集群的当前运行状态进行查看，命令格式：
[][<主机名>]
该程序向输出在资源层次配置状态和通信路径的状态.
选项表示输出采用简略的形式（建议使用该选项）
选项–d表示要查看的主机，缺X查看本机
3.1.6.管理中的资源
注意：
如果能运行，则使用其提供菜单命令执行相应操作；在执行命令行启动/停止资源前，一定先使用命令确认资源的实际状态。
a）启用资源（）
可以使用命令：
<资源标记名>
将资源标记名所对应的资源在本机上投入服务（启动）。
如果该资源在命令使用前已经在另一台机器上处于运行状态，则本命令执行的结果相当于执行了一次手工切换
！
！
！
如果该资源在命令使用前是处于停止状态（即在备机上执行本命令），则本命令执行的结果相当于执行了一次手工切换
b）停止资源（）
可以使用命令：
<资源标记名>
将资源标记名所对应的资源在本机上停止服务。
如果该资源在命令使用前已经在另一台机器上处于运行状态，则本命令执行不产生任何结果
注意：
⏹在执行命令行前后，一定先使用命令确认资源的当前状态。
⏹命令停止/启动本地的资源
⏹命令中的<资源标记名>是区分大小写的
⏹一定要等待命令完成，注意命令的输出。
⏹详细用法见在线帮助手册。
3.2.维护
计算机系统各种软、硬件故障、用户误操作以及恶意破坏是不可避免的,这些影响到数据的正确性甚至造成数据损失、服务器崩溃等致命后果。
数据库的备份对保证系统的可靠性具有重要的作用。
下面会根据执行强度对维护任务及其相应的程序进行分类描述，执行强度用不同的时间间隔定义，包括每天、每周、每月和每季度，能够建立起良好的维护实务，确保数据库性能和安全。
3.2.1.每天的例行维护任务
需要数据库管理员密切关注的维护任务，最好每天都查看一下，这样可以确保系统的可靠性、可用性、运行性能和安全。
每天的例行维护任务包括：
1、查看是不是所有被请求的服务都正常运行。
2、查看日常备份日志中成功、警告或者失败记录。
3、查看事件日志有没有错误记录。
4、查看日志有没有安全警告记录，例如非法登录。
5、执行完全备份或差异备份。
6、在设置了完全恢复模型或大容量日恢复模型的数据库上执行事务日志备份任务。
7、核实作业没有失败。
8、查看所有的数据库文件和事务日志具有合适的磁盘空间大小。
9、至少要监控处理器、内存或者磁盘计数器没有出现瓶颈。
3.2.2.每周的例行维护任务
关注程度稍逊于每天的例行维护任务，最好每周进行一次例行查看。
每周的例行维护任务包括：
1、执行完全备份或差异备份。
2、查看以前执行的维护计划报告。
3、查看数据库完整性。
4、如果需要，执行收缩数据库任务。
5、通过重新组织索引任务压缩聚集和非聚集表和视图。
6、通过重新生成索引任务在数据页和索引页重新组织数据。
7、更新所有用户表和系统表的统计信息
8、清除备份、还原、代理作业和维护计划等操作的历史数据。
9、如果需要，手动增长数据库或事务日志文件
10、清除执行维护计划残留下来的文件。
3.2.3.每月或每季度的维护任务
有一些维护计划不需要执行得过于频繁，可以每个月或每个季度执行一次。
但是请不要以为这些任务不需要天天执行就无足轻重，这些任务可以确保数据库环境的健康，所以不要轻视以下这些维护任务：
1、在测试环境中执行备份还原操作。
2、将历史数据归档。
3、分析收集的性能统计数据，与基准值相比较。
3、查看并更新维护文档。
4、查看并安装最新的补丁和补丁包。
5、如果运行簇、数据库镜像或日志传送，则监测故障转移。
6、验证备份和还原进程是否遵循已定义的服务等级协议。
7、更新构建指南。
8、更新灾难恢复文档。
9、更新维护计划列表
10、修改管理员口令。
11、修改服务帐户口令。
3.3.维护
3.3.1.性能调优
3.3.1.1.设定执行队列的溢出条件
提供给默认的执行队列或用户自定义的执行队列自定义溢出条件的功能，当满足此溢出条件时，服务器改变其状态为“警告”状态，并且额外的再分配一些线程去处理在队列中的请求，而达到降低队列长度的目的。
通过启动管理控制台，在域（如：
）>服务器>实例（如：
）>>>配置下面几项：
队列长度：
此值表示执行队列中可容纳的最大请求数，默认值是65536，最后不要手动改变此值。
队列长度阈值百分比：
此值表示溢出条件，在此服务器指出队列溢出之前可以达到的队列长度大小的百分比。
线程数增加：
当检测到溢出条件时，将增加到执行队列中的线程数量。
如果和内存不是足够的高，尽量不要改变默认值“0”。
因为一旦增加后不会自动缩减，虽然最终可能确实起到了降低请求的作用，但在将来的运行中将影响程序的性能。
最大线程数：
为了防止创建过多的线程数量，可以通过设定最大的线程数进行控制。
在实际的应用场景中，应根据具体情况适当的调整以上参数。
3.3.1.2.设定队列监测行为
能够自动监测到当一个执行线程变为“阻塞”。
变为“阻塞”状态的执行线程将无法完成当前的工作，也无法再执行新请求。
如果执行队列中的所有执行线程都变为“阻塞”状态，可能改变状态为“警告”或“严重”状态。
如果变为“严重”状态，可以通过来自动关闭此服务器并重新启动它。
具体请参考：
文档。
通过启动管理控制台，在域（如：
）>服务器>实例（如：
）>配置>调整下可配置下面几项：
阻塞线程最长时间：
在此服务器将线程诊断为阻塞线程之前，线程必须连续工作的时间长度（秒）。
默认情况下，认为线程在连续工作600秒后成为阻塞线程。
阻塞线程计时器间隔：
定期扫描线程以查看它们是否已经连续工作了"阻塞线程最长时间"字段中指定的时间长度的间隔时间（秒）。
默认情况下，将此时间间隔设置为600秒。
3.3.1.2.1.尽量使用本地库
有两套套接字复用器：
版和本地库。
采用小型本地库更有效,尽量激活（默认）,此时默认使用1个线程下为双倍。
如果系统不能加载本地库,将会抛出,此时只能使用套接字复用器,可以调整百分比,默认为33%。
该参数可以在配置栏里设置，配置完，重新启动即可。
3.3.1.2.2.调整默认执行线程数
名称
开发模式
产品模式
推荐个数
默认的执行线程为15
默认的执行线程为25
200
在管理控制台修改默认执行队列线程数的步骤如下：
⏹如果管理服务器没有运行，先启动。
⏹访问管理控制台。
⏹展开左边面板的节点，显示列表。
⏹右击，在弹出菜单中选择，就会在右边面板显示有执行队列的表用来修改。
⏹注意：
你只能修改默认的执行队列或者用户定义的执行队列。
⏹在列，直接点击默认执行队列名称，显示配置标签用来修改执行队列数。
⏹填下适当的线程数。
⏹点击，保存刚才的修改。
⏹重启，使新的执行队列设置生效。
3.3.1.3.调优
3.3.1.3.1.驱动程序类型选择
提供驱动和驱动,从性能上来讲驱动强于驱动,特别是大数据量的操作。
但在简单的数据库操作中,性能相差不大,随着驱动的不断改进,这一弱势将得到弥补。
而驱动的移植性明显强于驱动。
所以在通常情况下建议使用驱动
3.3.1.3.2.调节连接池初始容量和最大容量
的调优受制于线程数的设置和数据库进程数,游标的大小。
通常我们在一个线程中使用一个连接,所以连接数并不是越多越好,为避免两边的资源消耗，建议设置连接池的最大值等于或者略小于线程数。
同时为了减少新建连接的开销,将最小值和最大值设为一致；值等于的执行线程数。
3.3.1.3.3.其他配置
尽管提供了很多高级参数,在开发模式下比较有用,但大部分在生产环境下不需调整。
这里建议最好不要设置测试表,同时和也无需勾上。
当然如果你的数据库不稳定,时断时续,你就可能需要上述的参数打开
3.3.1.4.调优
3.3.1.4.1.调整应用描述符
应用除代码之外的调优比较简单,仅仅是对一些应用描述符的调整。
首先关闭,仅仅在环境下设置复制（优先使用内存复制）,在保证应用正常运行的情况下,设置较短的超时时间。
同时生产环境下无需查看和：
和均设为-1,关闭和对性能也有帮助。
此外，还可以对进行预编译,有两种方法：
激活选项；使用事先编译，建议采用后者。
3.3.1.5.其他调优设置
3.3.1.5.1.文件描述符大小调整
首先设置主机系统的参数为，然后设置中文件描述符的大小。
在{}中打开文件，修改设置文件描述符大小的指令，将默认的：
–n1024修改为：
–n8192
3.3.2.维护管理
3.3.2.1.启动
⏹启动管理服务器：
执行
⏹启动被管理服务器：
执行
3.3.2.2.停止
⏹停止被管理服务器：
执行
⏹启动被管理服务器：
执行
3.3.2.3.登录和退出管理控制台
⏹管理服务器启动后可以在浏览器中登录管理控制台
⏹输入：
或
●：
管理服务器的地址或名
●：
管理服务器监听的端口
●如果管理服务器启动时使用，则使用访问管理控制台
⏹在弹出的窗口““中输入用户名和密码登录
3.3.2.4.性能监控
⏹查看性能参数
●登录控制台后点击
⏹参数分析
1）
正常情况下>0，为0，呈不规则变化曲线，呈适度频度的锯齿变化曲线。
一般来说，对于正常配置的生产环境（线程数50~200），如果<10，或者呈现不断降低的趋势，就应加以关注；
空闲线程数与队列长度通常有如下关系：
A、如果空闲线程数>0，则=0；
B、反之，如果>0，则空闲线程数=0；
2）
=（）–（）
内存使用曲线反应了内存使用的变化情况，可以结合其他三个值的变化情况来判断工作情况；比较理想的状态是适当频度的各种锯齿变化，
由于多采用“”机制，也就是垃圾回收时其他处理将暂停，过度频繁的将明显降低工作效率和性能表现。
3.4.维护
，又名，或简称。
是甲骨文公司的一款关系数据库管理系统。
它是在数据库领域一直处于领先地位的产品。
可以说数据库系统是目前世界上流行的关系数据库管理系统，系统可移植性好、使用方便、功能强，适用于各类大、中、小、微机环境。
它是一种高效率、可靠性好的适应高吞吐量的数据库解决方案。
3.4.1.数据库性能优化
性能管理既是一种艺术，也是一种科学。
从实用角度讲，它可以分为两种类型，主动式和被动式性能管理。
主动式性能管理涉及到特定系统实施初期的设计和开发，包括硬件选择、性能及容量规划，海量存储系统的选择，子系统配置及优化，以及如何对不同组件进行定制，以满足数据库和应用系统的复杂要求。
被动式性能管理涉及到现有环境中不同组件的性能评估、故障排除和环境的优化。
本文旨在探讨如何进行被动式性能调优，以便为性能调优提供必要的指导，从而避免仅仅通过反复尝试的方式进行性能调优，提高性能管理的效率。
所以数据库性能恶化表现基本上都是用户响应时间比较长，须要用户长时间的等待。
获得满意的用户响应时间有两个途径：
一是减少系统服务时间，即提高数据库的吞吐量；
二是减少用户等待时间，即减少用户访问同一数据库资源的冲突率。
对于以上的两个问题，通常我们采用以下几个方面来进行改善：
⏹调整服务器内存分配。
例如，可以根据数据库运行状况调整数据库系统全局区（区）的数据缓冲区、日志缓冲区和共享池的大小；还可以调整程序全局区（区）的大小。
⏹调整硬盘问题，达到负载均衡。
⏹调整运用程序结构设计。
⏹优化调整操作系统参数和使用资源管理器。
⏹优化、诊断竞争、（）优化、提升的效率等等。
3.4.1.1.查看数据库性能
查看数据库性能情况，包含：
查看数据库的等待事件，查看死锁及处理，查看、、内存性能，查看是否有僵死进程，查看行链接/迁移，定期做统计分析，查看缓冲区命中率，查看共享池命中率，查看排序区，查看日志产品日常运行维护年度服务项目缓冲区，总共十个部分。
3.4.1.1.1.查看数据库的等待事件
80
120
a40
123v$'''';
如果数据库长时间持续出现大量像，，，，等等待事件时，需要对其进行分析，可能存在问题的语句。
3.4.1.1.2.查看消耗最高的进程
240
999
999
999
A9""
A29
A60
A9""
（（,1,
80））V$P,V$$A=
=（+）'1%';
3.4.1.1.3.查看碎片程度高的表
>（*）（'',''）（*）=（（（*）））;
3.4.1.1.4.查看表空间的比例
>"",,V$F,=;
3.4.1.1.5.查看文件系统的比例
>（,1,2）"#"（,1,30）""V$A,V$B;
3.4.1.1.6.最高的语句的获取
>（*V$）
<=5;
3.4.1.1.7.查找前十条性能差的
*（
V$）
<10;
3.4.1.1.8.等待时间最多的5个系统等待事件的获取
*（*V$''）<=5;
3.4.1.1.9.查看运行很久的
A12
A16
A8
（*100/,0）'%'
V$,V$<>0=;
3.4.1.1.10.查看死锁及处理
查询目前锁对象信息：
999999
a10
a10
a16
a16
a20
a10
a30
a10
$$s
;
级掉该：
'';
操作系统级掉：
#>-9
3.4.1.1.11.查看数据库、、内存性能
记录数据库的使用、、内存等使用情况，使用等命令进行信息收集并查看这些信息，判断资源使用情况。
⏹使用情况：
[8~]#
-10:
29:
3573,19:
54,1,:
0.37,0.38,0.29:
353,2,351,0,0
（s）:
1.2%,0.1%,0.0%,98.8%,0.0%,0.0%,0.0%
:
16404472k,12887428k,3517044k,60796k
:
8385920k,665576k,7720344k,10358384k
30495
32501
32503
注意上面的加粗字体部分，此部分内容表示系统剩余的，当其平均值下降至10%以下的时视为使用率异常，需记录下该数值，并将状态记为异常
⏹内存使用情况：
#
:
261556
:
3261700
:
5992925900
如上所示，表示系统总内存，表示系统使用的内存，表示系统剩余内存，当剩余内存低于总内存的10%时视为异常。
⏹系统负载情况：
12:
08:
37162,23:
33,15:
0.01,0.15,0.10
如上所示，部分表示系统负载，后面的3个数值如果有高于2.5的时候就表明系统在超负荷运转了，并将此值记录到巡检表，视为异常。
3.4.1.1.12.查看是否有僵死进程
v$（v$）;
有些僵尸进程有阻塞其他业务的正常运行，定期杀掉僵尸进程。
3.4.1.1.13.查看行链接/迁移
>'2'<>0;
注：
含有列的表有行链接是正常的,找到迁移行保存到表中,如没有该表执行
>;
可通过表中看出哪些行是迁移行如:
>.*b='';
>（=''）;
>*='';
3.4.1.1.14.定期做统计分析
对于采用的系统，需要定期对数据对象的统计信息进行采集更新，使优化器可以根据准备的信息作出正确的。
在以下情况更需要进行统计信息的更新：
应用发生变化；
大规模数据迁移、历史数据迁出、其他数据的导入等；
数据量发生变化。
查看表或索引的统计信息是否需更新，如：
>=''
>（*）如和（*）如果行数相差很多,则该表需要更新统计信息，建议一周做一次统计信息收集，如：
>（>'2'>=>4）;
3.4.1.1.15.查看日志缓冲区
>v$（'',''）;
如果超过1%，则需要增大。
3.4.1.2.性能调优及方法
性能调优主要有主动调优和被动调优，主动调优在前面我们已经进行了阐述，被动调优主要有以下方法进行。
⏹确定合理的性能优化目标
⏹测试并记录当前的性能指标
⏹确定当前存在的性能瓶颈（中何处存在等待，哪个语句与此有关）
⏹确定当前的操作系统瓶颈
⏹优化相关的组件（应用、数据库、、连接及其它）
⏹跟踪并实施变化管理制度
⏹测试并记录目前的性能指标
⏹重复第3到第7步直至达到既定的优化目标
不要对并非性能瓶颈的部分进行优化，否则可能引起额外的问题。
正如任何聪明的人会告诉你的：
“如果还未坏，千万不要修”。
更重要的是，一旦既定的优化目标已经达到，就务必停止所有的优化。
获取的性能指标（测试前及测试后）必须在峰值处理时测试并获取系统在优化前和优化后的性能指标。
数据采集不应在数据库刚刚起动后进行。
同时，测试数据应在峰值期间每过15分钟进行一次。
初始化参数应该被设为。
通过运行以下脚本开始快照：
$.
通过运行以下脚本结束快照：
$.
完成操作后，会在当前目录中生成名为“”的文件，包含系统的性能数据。
该报告包括每15分钟捕获的所有与例程相关的参数。
3.4.1.2.1.寻找问题根源
如上所述，通过查看v$事件开始系统事件的问题诊断。
下一步是查看v$，找出引起或经历等待事件的进程。
最后一步是通过v$获得事件的细节。
同时，应该进一步通过进行深入分析，了解核心的、内存和状态参数。
最后，结合两种不同的诊断的结论，找出系统瓶颈所在。
3.4.1.2.2.应用优化
从统计（和现实）的角度看，80%的系统性能问题可以通过代码优化来解决。
任何应用优化的过程，不外乎是索引优化、全表扫描、并行机制改进和选择正确数据组合方法的过程。
这正是要达到最佳应用性能所必须考虑的因素。
没有的优化，就无法实现高性能的应用。
良好的语句可以减少资源的消耗，提高响应速度。
同时，优化后的语句还可以提高应用的可扩展性，这是除增加大量内存外，任何其它硬件手段也无法实现的。
3.4.1.2.2.1.优化
优化是系统优化中的一个关键步骤，还涉及到其它任务，将文件在不同驱动器/卷中进行分布，采用优化分区技术、确定子系统瓶颈、确定控制器瓶颈并根据应用的类型选择最佳的级。
优化应该在全面了解及结构之后进行。
应该在进行优化前后实施数据监控，如平均服务时间，，平均磁盘队列长度等。
3.4.1.2.2.2.监控
数据库忙时，应该对操作系统进行监控，因为操作系统的性能指标会揭示数据库活动的性质及其对系统的影响。
例如，为了了解的利用率，可以通过（–u）、（）,（多数）、（）及等命令。
和也可被用于确定包括内存使用率、参数、队列等待、读取/交换区活动等信息。
在上，也可用于获取前面提到的利用率数据。
上的性能管理工具也很有用。
可以利用其中的一到多个工具来确定系统的性能状况，找出可能存在的瓶颈。
数据库性能的管理需要遵循系统的方法论，以确保所有核心问题得以解决。
多数问题可以事先得以管理。
了解与相关的问题是成功的关键。
勿需置疑，系统硬件配置上的良好平衡也是至关重要的。
必须承认，80%的系统
性能问题可以通过书写更好的语句来解决。
来文试图探究其余20%中可能覆盖的内容。
同时，必须遵守严格的规定，在调优目标达到后终止所有努力。
了解自己想到何处是重要的，更重要的是，要知道自己何时到达了目的地。
3.4.1.2.2.3.例程调优
⏹需要配置的主要初始化参数
以下是一些已知与例程优化关系最密切的一些核心初始化参数。
它们都会影响及区的活动。
任何对这些参数的改动，在实施到生产环境之前，都必须进行测试。
一旦改变了生产环境的参数，就必须对相关的动态性能指标和操作系统的性能进行监测，寻找可能由此产生的异常现象。
1）
该参数在数据库建立前设定，决定了数据库
升级会员 