作者:,,,,,,,,,,,,,,, | 来源:互联网 | 2023-05-18 12:01
正式数据库已经在运营当中因为新需求或者修复BUG等原因,导致表结构或者存储过程等发生变化如何在发布应用新版本的时候,同时对表结构、存储过程做相关的更新如何保证1、不影响正式数据
正式数据库已经在运营当中
因为新需求或者修复BUG等原因,导致表结构或者存储过程等发生变化
如何在发布应用新版本的时候,同时对表结构、存储过程做相关的更新
如何保证
1、不影响正式数据库中的数据
2、保证把新的表结构和存储过程等全部更新到正式数据库,而没有遗漏
3、如何对修复BUG的变动、新需求的变动做好版本控制
不知道有没有好的流程、或者工具
请不吝赐教,越详细越好,定高分相谢
16 个解决方案
1\PD
2\ 在每次做变动时生成SQL更新语句,并保存在一个文件里,写SQL语句考虑数据的搬移.......等等,最重要的一点写明变更原因
我们现在都是在pd里修改然后生成相应的SQL , 需要时当更新包使用
程序和sql 脚本一起更新执行,
文档管理、程序版本可以用vss、suv来控制
数据库应分为 开发库-->测试库-->发布库-->正式库..
开发库与测试库不用解释,
发布库是定期拿正式库备份来还原的,其表结构与正式库一致.
当在开发库完成开发及初步测试后,应编写用于发布的SQL脚本,在测试库执行..
当在测试库完成测试后,用发布的SQL脚本在发布库执行..
当在发布库执行正常后,用发布的SQL脚本在正式库执行..
这个建立在你的数据库都是用脚本归档的前提下,如果是这样,那么你可以针对新增的需求做一些脚本,例如原来的是001版本,然后你可以做个002版本的脚本,这个里面只包含新增脚本,这样的话如果某个地方需要升级,先保证是001版本,再刷002版本的脚本即可,这样也保证了各个地方系统的独立行。
别去找一劳永逸的三方工具,不现实
既然是修改或修正BUG,就得把脚本整理好,以在生产环境部署,偷不了懒
能问出这个问题,说明你们没有较专业的DBA支持。。属于技术资源不足
如何保证
1、不影响正式数据库中的数据
这个要看你的系统运行状况,更准确来说是SLA。如果是24*7的系统,那要做很多额外的东西来确保,但是无论如何,搭建一个尽可能贴近正式环境的测试环境然后在上面先预部署是必须的
2、保证把新的表结构和存储过程等全部更新到正式数据库,而没有遗漏
使用一些第三方工具或者自己开发的工具,保证更新是都在一个事务中完成,要么全部成功要么全部回滚,我以前公司用自己开发的工具来一次性部署。
3、如何对修复BUG的变动、新需求的变动做好版本控制
这些TFS、vss、其他版本管控工具都有。
简单来说,你这些要求其实更多的不是技术上而是管理上的要求
如果想查找旧的对象都在哪里使用,可以试试:
reddate的SQL Search
ApexSQL Refactor和Search
必须事先把要升级的 SQL 语句准备好,等更新的时候,和程序一起发布,最好是把业务停掉。
更新前要反复测试,并且要有回退方案。