tag:blogger.com,1999:blog-10846234.post112326697399893148..comments2023-06-22T09:51:55.639+01:00Comments on BOBABLOG: Agile software development and Salesforce: The Database Patch Runner - RollbacksRob Bailliehttp://www.blogger.com/profile/06513796097645814224noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-10846234.post-86817974630140172332008-01-05T04:14:00.000+00:002008-01-05T04:14:00.000+00:00Yep Shannon, you're on the money.It can get cumber...Yep Shannon, you're on the money.<BR/><BR/>It can get cumbersome whichever way round you do it. At the moment we're still keeping our patches small and haven't added another layer of recording into the patch runner, though we're now at the point where we have more than a couple of hundred patch files sitting in our release. It's no big deal really I suppose, but we are considering producing a new greenfield build at a version before which we would not move. It's going to be a bit of a task, but it will speed our development builds up a little.<BR/><BR/>Whatever you do, whichever option you take, there are pros and cons. You've just got to make sure you understand what they are first, and then react to them when they change.Rob Bailliehttps://www.blogger.com/profile/06513796097645814224noreply@blogger.comtag:blogger.com,1999:blog-10846234.post-27780118515521782532008-01-04T17:41:00.000+00:002008-01-04T17:41:00.000+00:00What if you record each step within your PL/SQL pr...What if you record each step within your PL/SQL program and condition each step (Each step being a DDL activity)?<BR/><BR/>Your patch runner then not only examines for the version, but the last successfully implemented step within the versioned patch. Another possibility is to break out each DDL statement as a patch...this could get cumbersome as well!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10846234.post-1123362516025194342005-08-06T22:08:00.000+01:002005-08-06T22:08:00.000+01:00I'm not really sure what our DBA's would think if ...I'm not really sure what our DBA's would think if we no longer need them during upgrades. I'm already taking (automating) so much work away from them ;-)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10846234.post-1123330897955727542005-08-06T13:21:00.000+01:002005-08-06T13:21:00.000+01:00Looks very interesting, cheers for the tip off!As ...Looks very interesting, cheers for the tip off!<BR/><BR/>As people who read this blog might have guessed, I'm much more of a developer than a DBA, so I tend to lean towards development solutions rather than DBA ones.<BR/><BR/>Once of the situations I like at our place is that the database upgrades are now so solid that the DBA team very very rarely gets involved. We normally have a member of the support team performing the upgrade with a DBA and developer on standby on the off chance that something goes wrong. It very rarely does.<BR/><BR/>Our DBAs like it!Rob Bailliehttps://www.blogger.com/profile/06513796097645814224noreply@blogger.comtag:blogger.com,1999:blog-10846234.post-1123273372763893462005-08-05T21:22:00.000+01:002005-08-05T21:22:00.000+01:00If you're database is running in ARCHIVELOG mode a...If you're database is running in ARCHIVELOG mode and you have exclusive access to the database during a patch run (which is good advice) perhaps you can use FLASHBACK DATABASE to rollback the entire database to a previous point in time.<BR/><BR/>This is 10g feature which I haen't used myself yet but it should be possible. See http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10734/rcmflash.htm#1020720 for more info.Anonymousnoreply@blogger.com