项目经验-邹建

 
项目一: 数据库自动备份/ 恢复系统
项目简介(功能与用途):
该系统主要实现备份和恢复的自动化处理,尽量减少人在这个处理中需要花费的时间,同时,自动化的工具有利于管理多台服务器,而无需在每台服务器上进行复杂的操作
 
系统工作流程:
1.       备份:
输入指定的服务器列表及数据库信息,系统根据预设的处理规则,自动生成各服务器上的数据库备份处理脚本( JOB+ 备份语句脚本)及备份方案
2. 恢复:
设置好要恢复的数据库及时间点,系统自动列出恢复处理会涉及到的备份文件,生成恢复处理脚本
 
系统架构:
Excel+VBA 实现用户界面(输入与输出)
SQL Server 数据库存储与分析数据
 
项目难点与解决方案:
 
项目成功与失败的经验归纳:
优点:
备份与恢复中,技术含量比较高的处理由系统自动完成,因此,普通人员即可完成备份方案的制定及部署,也可以完成一般的数据恢复任务。
缺点:
1.         缺少好的用户界面(因为人力的问题,没有开发人员参与系统的开发),输入与输出通过 Excel 文档来控制,或者是直接在数据库中做设置
2.         备份考虑了自动覆盖历史数据的问题,所以这套系统现在还是用于磁盘的备份及恢复
3.         恢复比较依赖于 msdb 系统数据库,因此这个库的备份会看得比较重要
 
 
你在项目中岗位与贡献:
独立完成整个项目
 
 
项目二: 数据库运行状态分析系统
项目简介(功能与用途):
定期从指定的所有服务器获取信息,并根据获取的信息进行分析,生成分析报告,目前涉及到的分析信息包括下面几个子系统(每个方面是一套独立的系统,只是通过统一的构架来控制)
1.       SQL Server 日志分析
2.       失败 Job 的分析
3.       发布 / 订阅配置信息报表
4.       服务器磁盘及数据库空间变化状况分析
 
系统工作流程(每个处理部分除了具体的处理细节外,其他都是一样的):
1.    JOB 调度 SSIS 包,定期轮询指定的服务器列表,获取相关的信息放入监控数据库
2.    监控服务器的分析存储过程在用户干预或者是 Job 调度的方式下,根据预定的规则对信息进行初步分析
3.    分析人员获取电脑分析的结果,进行人工确定和再分析,对于故障,给出处理建议
4.    分析的结果放入 Share Point 网站,供处理人员处理
5.    处理人员根据网站上的信息进行再次分析确认,借鉴处理建议形成最终的处理方案
6.    处理人员根据定义好的处理方案,处理问题,并将处理结果反馈到网站
 
系统架构:
SSIS+JOB 实现信息的定期获取
SQL Server 数据库完成数据的存储与自动分析
Excel 完成数据分析方面的人工处理部分
Share point 网站实现分析后信息的共享,记录对分析结果处理后的反馈
 
项目难点与解决方法:
项目的难点主要是在于各种信息的获取脚本的编写上,由于公司的数据库环境有 SQL Server 2000 ,也有 SQL Server 2005 ,所以所有的脚本都要能够在两种版本下通用,或者是有针对各自版本的脚本,而且,很多信息涉及到的系统表,一般资料较难查到,所以更多的时候要靠测试及 SQL Profile 的跟踪
SSIS SQL Server 的一个新子系统,而这个系统中,信息获取处理要全部靠 SSIS 来完成, SSIS 自身的 BUG 加上资源的缺乏,在初期对项目开发的影响比较大( DBA 的程序开发能力有限,所以这套系统没有考虑用程序完成)
 
项目成功与失败的经验归纳:
项目的初期,是针对“服务器磁盘及数据库空间变化状况分析”来写的,后面逐渐增加了其他的任务,所以初期的规划做得不是太好。
后期重新做了规划,在规划后的模式中,信息获取的处理封装成了一个公共的框架,信息获取处理的核心是 T-SQL 脚本,只需要根据不同的处理需要,写出不同的 T-SQL 脚本,并配置到这个框架中,即可完成一个新的系统运行状态获取子系统,这对于后期增加子系统有极大的好处,同时,修改旧的子系统的功能也变得十分容易
缺点:
1.         信息处理的整个流程还不足够流畅,数据处理的结果没有回存到监控服务器,这对信息的进一步分析(比如历史对照)带来了影响
2.         系统运行状态的历史信息没有充分利用,比如,同一个问题,如果某个分析都是某个人一直做的,则他可以凭记忆确定问题出现的频率,但换一个人就无法做到了,因为,还缺少数据的整体分析功能
 
你在项目中岗位与贡献:
独立完成整个项目
 
 
 
项目三: 数据库运行监控系统
项目简介(功能与用途):
本系统的目的,是要指定的所有服务器的运作情况,自动报告服务器的异常信息,并自动通知相关人员解决。目前在该系统下运行的子系统有:
1.       SQL Down 监控
2.       服务器 BLOCK (堵塞)情况监控
3.       重要 Job 的运行状态监控
4.       发布 / 订阅执行情况监控
 
系统工作流程(每个处理部分除了具体的处理细节外,其他都是一样的):
1.    框架统一调度每个子系统,具体的调度方法由各子系统的配置文件确定(多线程)
2.    每个子系统轮询指定的服务器列表(单线程或者多线程,根据需要配置)
3.    在每个服务器上执行监控处理
4.    监控结果存储到监控服务器
5.    监控服务器根据预设的规则对监控信息进行分析
6.    根据分析的结果,决定信息的发出方式,目前的方式有:发送邮件、发送信息到监控人员操作的监控客户端、只存档,不处理
 
系统架构:
应用程序完成所有的监控处理
SQL Server 数据库完成数据的存储与自动分析
另外有邮件系统和开发的一个监控客户端配合这套系统的工作(不属于这个系统的一部分,只是与这个系统配套)
 
 
项目难点与解决方法:
在这个项目的初期,每个子系统是做为独立的系统开发的。开发的成本和质量都较难掌握,而且开发的时间不好控制
后来经过分析,决定建立统一的框架,完成每个子系统的调度,同时,将监控中会用到的大多数处理方法封装到一个基类中,通过这样的变更,成功解决了重复投资的问题,并实现了良好的扩展性
 
项目成功与失败的经验归纳:
此项目的成功完成,使公司的数据库监控工作部署和添加新的监控处理变得非常简单,只需要 DBA 写好监控信息获取的脚本,设置好监控处理的配置文件,就可以完成一项监控任务的部署(在监控的具体处理方法,有现成的基类,可以继承基类扩充监控处理实现,这个不需要太多的开发技能,一般的 DBA 都有此程序编写能力)
 
 
你在项目中岗位与贡献:
需求分析,框架的规划设计,编写监控处理需要的相关脚本,制订监控信息处理规则,编写监控信息分析处理脚本
 
 
项目四: DB Move (数据库迁移项目)
项目简介(功能与用途):
本系统的目的,是要规范数据库变更的发布流程,使数据库的变更可管和可控,此系统涉及如下几个部分:
1.       数据库发布流程,定义从提出数据变更,到开发环境开发,再到测试环境测试,及最终的项目上线,这整个流程中,数据库相关脚本应发布
2.       数据库脚本规范(包括格式规范和性能规范两部分)
3.       数据库发布处理工具
 
系统工作流程
1.    产生数据变更需求
2.    确定变更的可行性
3.    开发环境中开发
4.    发布到测试环境, DBA 在发布前对要发布的脚本进行规范检查(格式和性能)
5.    完成测试后,发布到线上环境
 
系统架构:
InfoPath 表单 +Share Point 网站,构成数据库变量信息的发布平台
DB Move 工具,完成 DBA 在处理脚本中,除格式和性能处理之外的工作
 
项目难点与解决方法:
项目遇到的第 1 个问题是规范的推动的问题,因为公司的项目大部分是维护旧的项目,而旧的开发是没有遵守任何规范的,这意味着,一个小的改动可能会让开发人员要重写整个存储过程(因为要遵守规范),在这一点的推动上,采用的方法是 DBA 带头调整不规范的代码,逐步带开发人员将代码编写规范融入日常的写作习惯中
项目遇到的第 2 个问题是此项目会牵涉到的人员几乎是所有的开发人员,任何一个人员的不规范行为都可能导致整个规范会被逐渐打破,解决这个问题的方法是 DBA 严格把关,各项目 Leader 协同维持整个流程
3 个问题是 DBA 缺少开发资源,而这个项目牵涉到的技术比较广泛,有的技术比较在公司来说,属于冷门的技术,比如 Share Point 上的开发,数据迁移工具涉及到的 SQLDMO 对象开发, InfoPath 的开发等,解决的方法是先手工处理,通过逐步学习技术,逐步使处理过程自动化
 
项目成功与失败的经验归纳:
项目目前还未完全完成,基本上达到的效果是数据库迁移的过程可控制,资料可查询,脚本的质量有保障,数据库的迁移是自动完成的, DBA 在数据库迁移过程中,重点的精力只会花费在控制脚本方面
技术不完全成熟,加之涉及的人员太广,所以需要时间才能实现数据库迁移的可管理性
 
你在项目中岗位与贡献:
规范和流程的制订,数据库发布平台的搭建, DB Move 工具的编写
 
 
 
项目一: 数据库自动备份/ 恢复系统
项目简介(功能与用途):
该系统主要实现备份和恢复的自动化处理,尽量减少人在这个处理中需要花费的时间,同时,自动化的工具有利于管理多台服务器,而无需在每台服务器上进行复杂的操作
 
系统工作流程:
1.       备份:
输入指定的服务器列表及数据库信息,系统根据预设的处理规则,自动生成各服务器上的数据库备份处理脚本( JOB+ 备份语句脚本)及备份方案
2. 恢复:
设置好要恢复的数据库及时间点,系统自动列出恢复处理会涉及到的备份文件,生成恢复处理脚本
 
系统架构:
Excel+VBA 实现用户界面(输入与输出)
SQL Server 数据库存储与分析数据
 
项目难点与解决方案:
 
项目成功与失败的经验归纳:
优点:
备份与恢复中,技术含量比较高的处理由系统自动完成,因此,普通人员即可完成备份方案的制定及部署,也可以完成一般的数据恢复任务。
缺点:
1.         缺少好的用户界面(因为人力的问题,没有开发人员参与系统的开发),输入与输出通过 Excel 文档来控制,或者是直接在数据库中做设置
2.         备份考虑了自动覆盖历史数据的问题,所以这套系统现在还是用于磁盘的备份及恢复
3.         恢复比较依赖于 msdb 系统数据库,因此这个库的备份会看得比较重要
 
 
你在项目中岗位与贡献:
独立完成整个项目
 
 
项目二: 数据库运行状态分析系统
项目简介(功能与用途):
定期从指定的所有服务器获取信息,并根据获取的信息进行分析,生成分析报告,目前涉及到的分析信息包括下面几个子系统(每个方面是一套独立的系统,只是通过统一的构架来控制)
1.       SQL Server 日志分析
2.       失败 Job 的分析
3.       发布 / 订阅配置信息报表
4.       服务器磁盘及数据库空间变化状况分析
 
系统工作流程(每个处理部分除了具体的处理细节外,其他都是一样的):
1.    JOB 调度 SSIS 包,定期轮询指定的服务器列表,获取相关的信息放入监控数据库
2.    监控服务器的分析存储过程在用户干预或者是 Job 调度的方式下,根据预定的规则对信息进行初步分析
3.    分析人员获取电脑分析的结果,进行人工确定和再分析,对于故障,给出处理建议
4.    分析的结果放入 Share Point 网站,供处理人员处理
5.    处理人员根据网站上的信息进行再次分析确认,借鉴处理建议形成最终的处理方案
6.    处理人员根据定义好的处理方案,处理问题,并将处理结果反馈到网站
 
系统架构:
SSIS+JOB 实现信息的定期获取
SQL Server 数据库完成数据的存储与自动分析
Excel 完成数据分析方面的人工处理部分
Share point 网站实现分析后信息的共享,记录对分析结果处理后的反馈
 
项目难点与解决方法:
项目的难点主要是在于各种信息的获取脚本的编写上,由于公司的数据库环境有 SQL Server 2000 ,也有 SQL Server 2005 ,所以所有的脚本都要能够在两种版本下通用,或者是有针对各自版本的脚本,而且,很多信息涉及到的系统表,一般资料较难查到,所以更多的时候要靠测试及 SQL Profile 的跟踪
SSIS SQL Server 的一个新子系统,而这个系统中,信息获取处理要全部靠 SSIS 来完成, SSIS 自身的 BUG 加上资源的缺乏,在初期对项目开发的影响比较大( DBA 的程序开发能力有限,所以这套系统没有考虑用程序完成)
 
项目成功与失败的经验归纳:
项目的初期,是针对“服务器磁盘及数据库空间变化状况分析”来写的,后面逐渐增加了其他的任务,所以初期的规划做得不是太好。
后期重新做了规划,在规划后的模式中,信息获取的处理封装成了一个公共的框架,信息获取处理的核心是 T-SQL 脚本,只需要根据不同的处理需要,写出不同的 T-SQL 脚本,并配置到这个框架中,即可完成一个新的系统运行状态获取子系统,这对于后期增加子系统有极大的好处,同时,修改旧的子系统的功能也变得十分容易
缺点:
1.         信息处理的整个流程还不足够流畅,数据处理的结果没有回存到监控服务器,这对信息的进一步分析(比如历史对照)带来了影响
2.         系统运行状态的历史信息没有充分利用,比如,同一个问题,如果某个分析都是某个人一直做的,则他可以凭记忆确定问题出现的频率,但换一个人就无法做到了,因为,还缺少数据的整体分析功能
 
你在项目中岗位与贡献:
独立完成整个项目
 
 
 
项目三: 数据库运行监控系统
项目简介(功能与用途):
本系统的目的,是要指定的所有服务器的运作情况,自动报告服务器的异常信息,并自动通知相关人员解决。目前在该系统下运行的子系统有:
1.       SQL Down 监控
2.       服务器 BLOCK (堵塞)情况监控
3.       重要 Job 的运行状态监控
4.       发布 / 订阅执行情况监控
 
系统工作流程(每个处理部分除了具体的处理细节外,其他都是一样的):
1.    框架统一调度每个子系统,具体的调度方法由各子系统的配置文件确定(多线程)
2.    每个子系统轮询指定的服务器列表(单线程或者多线程,根据需要配置)
3.    在每个服务器上执行监控处理
4.    监控结果存储到监控服务器
5.    监控服务器根据预设的规则对监控信息进行分析
6.    根据分析的结果,决定信息的发出方式,目前的方式有:发送邮件、发送信息到监控人员操作的监控客户端、只存档,不处理
 
系统架构:
应用程序完成所有的监控处理
SQL Server 数据库完成数据的存储与自动分析
另外有邮件系统和开发的一个监控客户端配合这套系统的工作(不属于这个系统的一部分,只是与这个系统配套)
 
 
项目难点与解决方法:
在这个项目的初期,每个子系统是做为独立的系统开发的。开发的成本和质量都较难掌握,而且开发的时间不好控制
后来经过分析,决定建立统一的框架,完成每个子系统的调度,同时,将监控中会用到的大多数处理方法封装到一个基类中,通过这样的变更,成功解决了重复投资的问题,并实现了良好的扩展性
 
项目成功与失败的经验归纳:
此项目的成功完成,使公司的数据库监控工作部署和添加新的监控处理变得非常简单,只需要 DBA 写好监控信息获取的脚本,设置好监控处理的配置文件,就可以完成一项监控任务的部署(在监控的具体处理方法,有现成的基类,可以继承基类扩充监控处理实现,这个不需要太多的开发技能,一般的 DBA 都有此程序编写能力)
 
 
你在项目中岗位与贡献:
需求分析,框架的规划设计,编写监控处理需要的相关脚本,制订监控信息处理规则,编写监控信息分析处理脚本
 
 
项目四: DB Move (数据库迁移项目)
项目简介(功能与用途):
本系统的目的,是要规范数据库变更的发布流程,使数据库的变更可管和可控,此系统涉及如下几个部分:
1.       数据库发布流程,定义从提出数据变更,到开发环境开发,再到测试环境测试,及最终的项目上线,这整个流程中,数据库相关脚本应发布
2.       数据库脚本规范(包括格式规范和性能规范两部分)
3.       数据库发布处理工具
 
系统工作流程
1.    产生数据变更需求
2.    确定变更的可行性
3.    开发环境中开发
4.    发布到测试环境, DBA 在发布前对要发布的脚本进行规范检查(格式和性能)
5.    完成测试后,发布到线上环境
 
系统架构:
InfoPath 表单 +Share Point 网站,构成数据库变量信息的发布平台
DB Move 工具,完成 DBA 在处理脚本中,除格式和性能处理之外的工作
 
项目难点与解决方法:
项目遇到的第 1 个问题是规范的推动的问题,因为公司的项目大部分是维护旧的项目,而旧的开发是没有遵守任何规范的,这意味着,一个小的改动可能会让开发人员要重写整个存储过程(因为要遵守规范),在这一点的推动上,采用的方法是 DBA 带头调整不规范的代码,逐步带开发人员将代码编写规范融入日常的写作习惯中
项目遇到的第 2 个问题是此项目会牵涉到的人员几乎是所有的开发人员,任何一个人员的不规范行为都可能导致整个规范会被逐渐打破,解决这个问题的方法是 DBA 严格把关,各项目 Leader 协同维持整个流程
3 个问题是 DBA 缺少开发资源,而这个项目牵涉到的技术比较广泛,有的技术比较在公司来说,属于冷门的技术,比如 Share Point 上的开发,数据迁移工具涉及到的 SQLDMO 对象开发, InfoPath 的开发等,解决的方法是先手工处理,通过逐步学习技术,逐步使处理过程自动化
 
项目成功与失败的经验归纳:
项目目前还未完全完成,基本上达到的效果是数据库迁移的过程可控制,资料可查询,脚本的质量有保障,数据库的迁移是自动完成的, DBA 在数据库迁移过程中,重点的精力只会花费在控制脚本方面
技术不完全成熟,加之涉及的人员太广,所以需要时间才能实现数据库迁移的可管理性
 
你在项目中岗位与贡献:
规范和流程的制订,数据库发布平台的搭建, DB Move 工具的编写
 
 
 

你可能感兴趣的:(项目经验-邹建)