高分请教：如何对正式运营的数据库做表结构和存储过程等的更新，详见帖子

scsnsjsl_cs_dn 2014-09-04 05:30:16

正式数据库已经在运营当中

因为新需求或者修复BUG等原因，导致表结构或者存储过程等发生变化
如何在发布应用新版本的时候，同时对表结构、存储过程做相关的更新

如何保证
1、不影响正式数据库中的数据
2、保证把新的表结构和存储过程等全部更新到正式数据库，而没有遗漏
3、如何对修复BUG的变动、新需求的变动做好版本控制

不知道有没有好的流程、或者工具

请不吝赐教，越详细越好，定高分相谢

...全文

545 16 打赏收藏转发到动态举报

写回复

用AI写文章

16 条回复

切换为时间正序

请发表友善的回复…

发表回复

scsnsjsl_cs_dn 2014-09-10

打赏
举报

多谢

發糞塗牆 2014-09-09

打赏
举报

如何保证 1、不影响正式数据库中的数据这个要看你的系统运行状况，更准确来说是SLA。如果是24*7的系统，那要做很多额外的东西来确保，但是无论如何，搭建一个尽可能贴近正式环境的测试环境然后在上面先预部署是必须的 2、保证把新的表结构和存储过程等全部更新到正式数据库，而没有遗漏使用一些第三方工具或者自己开发的工具，保证更新是都在一个事务中完成，要么全部成功要么全部回滚，我以前公司用自己开发的工具来一次性部署。 3、如何对修复BUG的变动、新需求的变动做好版本控制这些TFS、vss、其他版本管控工具都有。简单来说，你这些要求其实更多的不是技术上而是管理上的要求

scsnsjsl_cs_dn 2014-09-09

打赏
举报

引用 6 楼 luckyrandom 的回复:

别去找一劳永逸的三方工具，不现实既然是修改或修正BUG，就得把脚本整理好，以在生产环境部署，偷不了懒能问出这个问题，说明你们没有较专业的DBA支持。。属于技术资源不足

确实是没有专业的DBA，能详细说下你的方案么，多谢

Q315054403 2014-09-09

打赏
举报

引用 7 楼 scsnsjsl_cs_dn 的回复:

[quote=引用 6 楼 luckyrandom 的回复:] 别去找一劳永逸的三方工具，不现实既然是修改或修正BUG，就得把脚本整理好，以在生产环境部署，偷不了懒能问出这个问题，说明你们没有较专业的DBA支持。。属于技术资源不足

确实是没有专业的DBA，能详细说下你的方案么，多谢[/quote] 没有神奇的魔术方案，缺啥补啥。。缺专业的DBA，就应该补缺DBA（当然涉及成本及合适的人选等综合问题）如果真有魔术方案，大把DBA也该退出江湖了

卖水果的net 版主 2014-09-09

打赏
举报

必须事先把要升级的 SQL 语句准备好，等更新的时候，和程序一起发布，最好是把业务停掉。更新前要反复测试，并且要有回退方案。

發糞塗牆 2014-09-09

打赏
举报

引用 10 楼 scsnsjsl_cs_dn 的回复:

[quote=引用 8 楼 DBA_Huangzj 的回复:] 如何保证 1、不影响正式数据库中的数据这个要看你的系统运行状况，更准确来说是SLA。如果是24*7的系统，那要做很多额外的东西来确保，但是无论如何，搭建一个尽可能贴近正式环境的测试环境然后在上面先预部署是必须的 2、保证把新的表结构和存储过程等全部更新到正式数据库，而没有遗漏使用一些第三方工具或者自己开发的工具，保证更新是都在一个事务中完成，要么全部成功要么全部回滚，我以前公司用自己开发的工具来一次性部署。 3、如何对修复BUG的变动、新需求的变动做好版本控制这些TFS、vss、其他版本管控工具都有。简单来说，你这些要求其实更多的不是技术上而是管理上的要求

针对第二点： 1、不管是第三方还是自己开发的工具都是通过SQL脚本对正式库做更新吧/ 2、常用的第三方工具有哪些呢[/quote] 通常对SQL Server的更新都是SQL脚本操作，除非一些外部引用。第三方软件，我以前用公司内部开发的，不是外部用的，所以不清楚，现在离开了也没拿到收

道素 2014-09-09

打赏
举报

如果想查找旧的对象都在哪里使用，可以试试： reddate的SQL Search ApexSQL Refactor和Search

scsnsjsl_cs_dn 2014-09-09

打赏
举报

引用 8 楼 DBA_Huangzj 的回复:

如何保证 1、不影响正式数据库中的数据这个要看你的系统运行状况，更准确来说是SLA。如果是24*7的系统，那要做很多额外的东西来确保，但是无论如何，搭建一个尽可能贴近正式环境的测试环境然后在上面先预部署是必须的 2、保证把新的表结构和存储过程等全部更新到正式数据库，而没有遗漏使用一些第三方工具或者自己开发的工具，保证更新是都在一个事务中完成，要么全部成功要么全部回滚，我以前公司用自己开发的工具来一次性部署。 3、如何对修复BUG的变动、新需求的变动做好版本控制这些TFS、vss、其他版本管控工具都有。简单来说，你这些要求其实更多的不是技术上而是管理上的要求

针对第二点： 1、不管是第三方还是自己开发的工具都是通过SQL脚本对正式库做更新吧/ 2、常用的第三方工具有哪些呢

scsnsjsl_cs_dn 2014-09-09

打赏
举报

引用 8 楼 DBA_Huangzj 的回复:

如何保证 1、不影响正式数据库中的数据这个要看你的系统运行状况，更准确来说是SLA。如果是24*7的系统，那要做很多额外的东西来确保，但是无论如何，搭建一个尽可能贴近正式环境的测试环境然后在上面先预部署是必须的 2、保证把新的表结构和存储过程等全部更新到正式数据库，而没有遗漏使用一些第三方工具或者自己开发的工具，保证更新是都在一个事务中完成，要么全部成功要么全部回滚，我以前公司用自己开发的工具来一次性部署。 3、如何对修复BUG的变动、新需求的变动做好版本控制这些TFS、vss、其他版本管控工具都有。简单来说，你这些要求其实更多的不是技术上而是管理上的要求

第二点都是通过执行更新脚本吧？第三方工具一般有哪些呢?

Q315054403 2014-09-06

打赏
举报

别去找一劳永逸的三方工具，不现实既然是修改或修正BUG，就得把脚本整理好，以在生产环境部署，偷不了懒能问出这个问题，说明你们没有较专业的DBA支持。。属于技术资源不足

KeepSayingNo 2014-09-05

打赏
举报

这个建立在你的数据库都是用脚本归档的前提下，如果是这样，那么你可以针对新增的需求做一些脚本，例如原来的是001版本，然后你可以做个002版本的脚本，这个里面只包含新增脚本，这样的话如果某个地方需要升级，先保证是001版本，再刷002版本的脚本即可，这样也保证了各个地方系统的独立行。

唐诗三百首 2014-09-05

打赏
举报

数据库应分为开发库-->测试库-->发布库-->正式库.. 开发库与测试库不用解释, 发布库是定期拿正式库备份来还原的,其表结构与正式库一致. 当在开发库完成开发及初步测试后,应编写用于发布的SQL脚本,在测试库执行.. 当在测试库完成测试后,用发布的SQL脚本在发布库执行.. 当在发布库执行正常后,用发布的SQL脚本在正式库执行..