U9日常维护手册(共29页).doc

精选优质文档-倾情为你奉上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是否开启网络自动优化功能（命令：netsh interface tcp show global），如下图：“normal”说明已经开启网络自动优化功能。关闭win2008网络自动优化功能（命令：netsh interface tcp set global autotuninglevel=disabled），如下图：“disabled”说明已经关闭网络自动优化功能。3.4. 事件查看器服务器管理员应该每天检查事件查看器，通过事件查看器可以了解服务器运转状况，例如，是否发生了软硬件错误、应用程序是否出错、操作系统是否被入侵等。管理员应该重点检查系统日志、应用程序日志和安全日志。3.4.1. 系统日志事件查看器-系统日志包含 Windows 的系统组件记录的事件。例如，下图的系统日志中提示了群集磁盘无法找到的错误。3.4.2. 应用程序日志事件查看器-应用程序日志包含由应用程序或系统程序记录的事件。例如，下图的应用程序日志提示报表服务无法连接报表数据库。3.4.3. 安全日志事件查看器-安全性日志记录诸如有效和无效的登录尝试等事件，以及记录与资源使用相关的事件，如创建、打开或删除文件或其他对象。管理器可以指定在安全性日志中记录什么事件。例如，如果您已启用登录审核，登录系统的尝试将记录在安全性日志里。3.5. 性能监视器如果发现服务器响应缓慢，可以通过性能监视器来检查哪些系统资源出现了瓶颈。开启性能监视器，见下图。可以通过资源概述直观的观察系统资源占用情况，见下图。也可以添加具体性能计数器，细粒度的了解具体情况。例如查看当前磁盘队列长度，以确认是否出现I/O瓶颈，见下图：更详细的用法，请参考windows帮助文档。3.6. 网络工具3.6.1. PingPing是一个简单而有效的工具，可以帮助维护人员快速检查网络传输是否存在问题。例如，指定一个较大的包（30K），连续ping的时候time应该小于等于10ms，丢包率小于0.5%：更详细的用法，请参考windows帮助文档。3.6.2. PathpingPathping命令可以帮助服务器管理员检查网络传输路径。当发现部分客户机访问服务器较慢时，可以通过该工具检查路由情况是否正常，哪些网段响应时间较慢。例如，如果发现某一网段较慢，可考虑检查是否网线离路由器距离太长、网线质量或接头是否存在问题等。例如，使用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. NetstatNetstat命令可以帮助服务器管理员了解TCP和UDP等协议端口被哪些进程占用，见下图。说明：PID是进程ID，可以通过PID在windows任务管理器中定位到底是哪个进程。更详细的用法，请参考windows帮助文档。3.8. 操作系统补丁更新设置服务器管理员应该有选择的进行操作系统补丁更新。强烈建议禁用自动补丁更新。手工进行补丁安装筛选。安全漏洞补丁可以安装，.netframework升级补丁不要安装。如果安装.netframework升级补丁有可能造成和目前程序不兼容的问题。4. 数据库服务器4.1. 必须开启的服务请务必保证以下SQL Server服务保持启动状态。l SQL Server (MSSQLSERVER)：SQL Server引擎服务。l SQL Server Reporting Services (MSSQLSERVER)：SQL Server报表服务。l SQL Server 代理 (MSSQLSERVER)：SQL Server用于调度定时执行作业的服务。（数据库备份和碎片整理都需要用到此服务）4.2. U9数据库服务器管理员应该定期（推荐一天一次）检查U9数据库所在磁盘是否有足够的空间。最好每周都记录数据库的数据和日志文件大小M:DB。定期汇总统计数据增长的趋势。4.3. 报表数据库服务器管理员应该定期（推荐一天一次）检查U9报表数据库所在磁盘是否有足够的空间。最好每周都记录数据库的数据和日志文件大小M:MSSQL10_50.MSSQLSERVERMSSQLDATA。定期汇总统计数据增长的趋势。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文件）。可以在SQL Server Management Studio中执行系统存储过程sp_readerrorlog读取Errorlog内容，见下图。如果发现有异常提示信息，请第一时间联系数据库维护人员分析原因。4.8. 作业Log巡检作业Log记录了作业执行情况。服务器管理员应该每天检查作业Log，以确保已调度的作业每天都执行成功，见下图。在SQL Server Management Studio中按上图方式查看作业的历史记录。如果发现有异常提示信息，请第一时间联系数据库维护人员分析原因。4.9. 群集环境维护4.9.1. 检查节点是否发生切换如果数据库服务器是基于windows故障转移群集模式，服务器管理员应该每天检查群集节点是否因为故障发生了节点切换。判断节点是否发生切换最简单的办法是在操作系统群集管理器中查看资源是否在主节点上。见下图。曾经遇到过这种情况，客户反映系统性能下降。检查发现群集因为曾经发生故障，已经切到从服务器上了。由于从服务器的配置比主服务器要差不少，所以系统性能出现下降。4.9.2. 补丁如何安装安装群集环境操作系统补丁时，可以先安装附属节点服务器。当附属节点安装完毕后，手工切换群集节点（资源）到附属节点，然后安装主节点服务器。全部安装完毕后，最后将资源切换到主节点服务器。注意：节点切换时会中断当前的正在使用的数据库连接，应该在U9系统不使用时进行。5. 应用服务器应用服务器的维护工作相对比较简单，主要是检查各种日志文件的增长，以预防磁盘可用空间不足导致服务器不能正常工作。5.1. U9日志清理U9日志记录了访问U9系统的历史信息，日志文件包括两部分：Portal Log和ApplicationServer Log。随着U9系统的长时间运行，日志文件的大小也将不断增长，为了保证可用的磁盘空间，历史日志的清理是十分必要的：从上图看，如果长期不清理，最后空间增长可能是非常大的。遇到的一个例子：由于长期不做清理，客户U9日志和IIS日志的总和达到了接近40个G！建议定期清理日志，例如两周或每月为周期，删除掉之前的历史日志。5.2. IIS日志清理IIS日志中记录了访问U9系统在内的所有ASP或ASP.NET Web站点的历史信息。建议每两周或每月清理IIS日志，删除历史记录，以保证可用的磁盘空间。IIS 7.0中，查看IIS日志物理路径：选择默认站点->日志：IIS日志路径：IIS 6.0中，查看IIS日志物理路径：选择默认站点->属性->网站->活动日志属性5.3. NLB检查如果应用服务器使用NLB群集的配置方式，应每天检查NLB群集中的各节点是否可用。方法是通过NLB管理器查看各节点状态。在NLB群集任一节点中，命令行中输入nlbmgr，打开NLB管理器，选中网络负载平衡群集根->连接到现有群集->输入群集节点IP或机器名->连接->完成，如下图：查看节点状态：NLB正常时，各节点的前面图标如上图所示。如果有异常，会用红色背景的图标来提升。当发现NLB有异常时，请参考<<U9产品配置指南>>检查NLB的配置。专心-专注-专业