U9日常维护手册.doc
《U9日常维护手册.doc》由会员分享,可在线阅读,更多相关《U9日常维护手册.doc(29页珍藏版)》请在冰豆网上搜索。
U9-IT维护手册
1.文档目的
本文档将介绍U9上线后,建议服务器维护人员进行的一些日常维护工作,目的是保证U9的稳定健康地运行。
由于各个企业的实际情况有所不同,本文档只作为参考和建议用。
2.硬件巡检
数据库和应用服务器的日常硬件检查非常必要。
通过服务器各类硬件指示灯,我们可以知道CPU风扇是否需要更换、硬盘是否损坏、电源是否正常工作等。
一旦发现硬件故障应该及时通知硬件维护商,在系统宕机前解决问题。
各企业可以根据自己实际情况创建自己的巡检机制和巡检报告,但是巡检频率最好不要少于一周一次。
下表是某公司服务器硬件巡检报告(一天一次),供参考:
3.操作系统
3.1.防火墙
U9上线后,如果新增防火墙(软、硬件),应注意尽量将U9数据库服务器和应用服务器放在防火墙同一侧,避免防火墙阻隔数据库服务器和应用服务器的正常通讯。
3.2.杀毒软件
杀毒软件种类繁多,企业引入杀毒软件应注意是否对性能造成影响。
总体原则是建议对外网访问的安全控制统一在代理服务器上进行,内部网络的访问不要设置对TCP/IP和HTTP协议的包过滤检查,因为这会严重影响网络传输性能。
当然,文件杀毒则是每台机器都应该配置启用的。
3.3.win2008(vista)和win2003混合使用
目前微软已经不再出售win2003操作系统,但是企业中仍然有很多安装了win2008和win2003操作系统的计算机在混合使用。
当win2003和win2008混合使用时,如果发现通过网络互相访问较慢时,应该检查win2008的网络自动优化功能是否开启。
该项功能可能由于部分路由器无法正确支持RFC1323协议,反而在某些情况下导致网络性能大幅下降。
如果发现网络访问存在性能问题,请关闭掉Win2008接收窗口自动调谐功能。
检查win2008是否开启网络自动优化功能(命令:
netshinterfacetcpshowglobal),如下图:
“normal”说明已经开启网络自动优化功能。
关闭win2008网络自动优化功能(命令:
netshinterfacetcpsetglobalautotuninglevel=disabled),如下图:
“disabled”说明已经关闭网络自动优化功能。
3.4.事件查看器
服务器管理员应该每天检查事件查看器,通过事件查看器可以了解服务器运转状况,例如,是否发生了软硬件错误、应用程序是否出错、操作系统是否被入侵等。
管理员应该重点检查系统日志、应用程序日志和安全日志。
3.4.1.系统日志
事件查看器-系统日志包含Windows的系统组件记录的事件。
例如,下图的系统日志中提示了群集磁盘无法找到的错误。
3.4.2.应用程序日志
事件查看器-应用程序日志包含由应用程序或系统程序记录的事件。
例如,下图的应用程序日志提示报表服务无法连接报表数据库。
3.4.3.安全日志
事件查看器-安全性日志记录诸如有效和无效的登录尝试等事件,以及记录与资源使用相关的事件,如创建、打开或删除文件或其他对象。
管理器可以指定在安全性日志中记录什么事件。
例如,如果您已启用登录审核,登录系统的尝试将记录在安全性日志里。
3.5.性能监视器
如果发现服务器响应缓慢,可以通过性能监视器来检查哪些系统资源出现了瓶颈。
开启性能监视器,见下图。
可以通过资源概述直观的观察系统资源占用情况,见下图。
也可以添加具体性能计数器,细粒度的了解具体情况。
例如查看当前磁盘队列长度,以确认是否出现I/O瓶颈,见下图:
更详细的用法,请参考windows帮助文档。
3.6.网络工具
3.6.1.Ping
Ping是一个简单而有效的工具,可以帮助维护人员快速检查网络传输是否存在问题。
例如,指定一个较大的包(30K),连续ping的时候time应该小于等于10ms,丢包率小于0.5%:
更详细的用法,请参考windows帮助文档。
3.6.2.Pathping
Pathping命令可以帮助服务器管理员检查网络传输路径。
当发现部分客户机访问服务器较慢时,可以通过该工具检查路由情况是否正常,哪些网段响应时间较慢。
例如,如果发现某一网段较慢,可考虑检查是否网线离路由器距离太长、网线质量或接头是否存在问题等。
例如,使用pathping命令检查通过哪些网络路径到达IP为192.168.8.105的服务器,见下图。
说明:
本机IP是10.1.73.57。
到达192.168.8.105需要先后经过10.1.73.1和10.254.254.9。
更详细的用法,请参考windows帮助文档。
3.7.Netstat
Netstat命令可以帮助服务器管理员了解TCP和UDP等协议端口被哪些进程占用,见下图。
说明:
PID是进程ID,可以通过PID在windows任务管理器中定位到底是哪个进程。
更详细的用法,请参考windows帮助文档。
3.8.操作系统补丁更新设置
服务器管理员应该有选择的进行操作系统补丁更新。
强烈建议禁用自动补丁更新。
手工进行补丁安装筛选。
安全漏洞补丁可以安装,.netframework升级补丁不要安装。
如果安装.netframework升级补丁有可能造成和目前程序不兼容的问题。
4.数据库服务器
4.1.必须开启的服务
请务必保证以下SQLServer服务保持启动状态。
lSQLServer(MSSQLSERVER):
SQLServer引擎服务。
lSQLServerReportingServices(MSSQLSERVER):
SQLServer报表服务。
lSQLServer代理(MSSQLSERVER):
SQLServer用于调度定时执行作业的服务。
(数据库备份和碎片整理都需要用到此服务)
4.2.U9数据库
服务器管理员应该定期(推荐一天一次)检查U9数据库所在磁盘是否有足够的空间。
最好每周都记录数据库的数据和日志文件大小M:
\DB。
定期汇总统计数据增长的趋势。
4.3.报表数据库
服务器管理员应该定期(推荐一天一次)检查U9报表数据库所在磁盘是否有足够的空间。
最好每周都记录数据库的数据和日志文件大小M:
\MSSQL10_50.MSSQLSERVER\MSSQL\DATA。
定期汇总统计数据增长的趋势。
4.4.数据库定期备份
4.4.1.恢复模式
恢复模式旨在控制事务日志维护。
有三种恢复模式:
简单恢复模式、完整恢复模式和大容量日志恢复模式。
通常,数据库使用完整恢复模式或简单恢复模式。
恢复模式
说明
工作丢失的风险
能否恢复到时点?
简单
无日志备份。
自动回收日志空间以减少空间需求,实际上不再需要管理事务日志空间。
最新备份之后的更改不受保护。
在发生灾难时,这些更改必须重做。
只能恢复到备份的结尾。
不能恢复到时点。
完整
需要日志备份。
数据文件丢失或损坏不会导致丢失工作。
可以恢复到任意时点(例如应用程序或用户错误之前)。
正常情况下没有。
如果日志尾部损坏,则必须重做自最新日志备份之后所做的更改。
有关详细信息,请参阅结尾日志备份。
如果备份在接近特定的时点完成,则可以恢复到该时点。
有关详细信息,请参阅将数据库还原到备份中的某个时间点。
4.4.1.1.简单恢复模式
简单恢复模式因为不需要完整记录Redo信息,因此性能较好。
即使日常不备份日志文件,日志文件也不会无限制增长。
日志文件的大小一般由最大的Undo操作决定。
但是因为没有记录完整的Redo信息,发生故障时,仅能将数据库恢复到最后一次全备份时。
如果符合下列所有要求,则使用简单恢复模式:
l不需要故障点恢复。
如果数据库丢失或损坏,则会丢失自上一次备份到故障发生之间的所有更新,但您愿意接受这个损失。
l您愿意承担丢失日志中某些数据的风险。
l您不希望备份和还原事务日志,希望只依靠完整备份和差异备份。
下图显示了简单恢复模式下最简单的备份与还原策略。
此策略仅使用包含数据库中所有数据的完整数据库备份。
存在五个完整数据库备份,但只需要还原最近的备份(在t5时点执行的备份)。
还原此备份会将数据库恢复到t5时点。
由t6框表示的所有后续更新都将丢失。
4.4.1.2.完整恢复模式
完整恢复模式会记录完整的Redo信息,性能不如简单恢复模式。
需要日常备份日志文件,如果不做日志备份,日志文件会无限制的增长下去。
如果发生故障时未备份日志没有损坏,几乎没有数据丢失(未提交事务将被回退)。
如果符合下列任一要求,则使用完整恢复模式:
l您必须能够恢复所有数据。
l数据库包含多个文件组,并且您希望逐段还原读/写辅助文件组(以及可选地还原只读文件组)。
l您必须能够恢复到故障点。
l您希望可以还原单个页。
l您愿意承担事务日志备份的管理开销。
下图显示了在完整恢复模式下的最简单的备份策略。
在此图中,已完成了完整数据库备份Db_1以及两个例行日志备份Log_1和Log_2。
在Log_2日志备份后的某个时间,数据库出现数据丢失。
在还原这三个备份前,数据库管理员必须备份活动日志(日志尾部)。
然后还原Db_1、Log_1和Log_2,而不恢复数据库。
接着数据库管理员还原并恢复结尾日志备份(Tail)。
这将把数据库恢复到故障点,从而恢复所有数据。
4.4.2.备份日常管理
我们的实施顾问会按照您的需求(数据库恢复模式)为您设定好相应的备份的作业。
服务器管理员需要定期检查备份作业是否执行成功。
如果发生作业失败情况,应该及时联系我公司支持人员查找原因。
服务器管理员需要管理数据库的备份文件。
每周清理过期的备份文件,以避免磁盘空间被耗尽。
备份文件的保留周期可以根据客户具体情况决定。
特别提醒:
如果事务恢复模型为完整恢复模式,一定要做日志文件备份。
如果不做日志备份,日志文件会无限制的增长下去。
4.5.碎片整理
我们的实施顾问会设定每天进行碎片整理的作业。
服务器管理员需要每天检查碎片整理作业是否执行成功。
如果发生作业失败情况,应该及时联系我公司支持人员查找原因。
4.6.日志收缩方法
在数据库维护期间,服务器管理员可能需要手工执行收缩日志,我们在这里给出收缩日志的方法,以供参考。
第一步,首先将数据库设置为简单恢复模式,见下图。
点击“属性”
“选项”à“恢复模式”à选择“简单”。
确定完成。
第二步,收缩日志文件,见下图。
点击“文件”
“文件类型”à选择“日志”;
“收缩操作”选择“在释放未使用的空间前重新组织页”;
确定,完成收缩。
4.7.ErrorLog巡检
Errorlog记录了数据库中是否发生了系统级错误、登陆失败等错误。
服务器管理员每天都应该检查数据库的错误日志(Errorlog文件)。
可以在SQLServerManagementStudio中执行系统存储过程sp_readerrorlog读取Errorlog内容,见下图。
如果发现有异常提示信息,请第一时间联系数据库维护人员分析原因。
4.8.作业Log巡检
作业Log记录了作业执行情况。
服务器管理员应该每天检查作业Log,以确保已调度的作业每天都执行成功,见下图。
在SQLServerManagementStudio中按上图方式查看作业的历史记录。
如果发现有异常提示信息,请第一时间联系数据库维护人员分析原因。
4.9.群集环境维护
4.9.1.检查节点是否发生切换
如果数据库服务器是基于windows故障转移群集模式,服务器管理员应该每天检查群集节点是否因为故障发生了节点切换。
判断节点是否发生切换最简单的办法是在操作系统群集管理器中查看资源是否在主节点上。
见下图。