项目经验-邹建
|
项目一：
数据库自动备份/
恢复系统
|
|
项目简介（功能与用途）：
该系统主要实现备份和恢复的自动化处理，尽量减少人在这个处理中需要花费的时间，同时，自动化的工具有利于管理多台服务器，而无需在每台服务器上进行复杂的操作
系统工作流程：
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
工具的编写
|