项目经验-邹建

 

项目一：数据库自动备份/恢复系统

项目简介（功能与用途）：

该系统主要实现备份和恢复的自动化处理，尽量减少人在这个处理中需要花费的时间，同时，自动化的工具有利于管理多台服务器，而无需在每台服务器上进行复杂的操作

 

系统工作流程：

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工具的编写