软件项目维护方案软件项目维护方案 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、查看是不是所有被请求的SQLServer服务都正常运行。
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 定期扫描线程以查看它们是否已经连续工作了“阻塞线程最长时间“ 字段中指定的时间长度的间隔时间(秒)。