| If you want to change the data stored in production database tables, following the below rules will be helpful. 1. Please don’t issue I/U/D SQL statements directly. You’d better write up some programs acting as the “revert transactions” to do the data modification. In this way, you don’t need to grant the I/U/D privileges of the production tables to any user IDs. Instead, you give access to those programs. It will help you to remove the human error as much as possible. And the behavior of the programs is more predictable and consistent. 2. You should have a fixed change window for these kinds of data changes. You should not execute those “revert transactions” whenever you want. 3. Then you give the execution access of those programs to the people who need to do the work only during the change window. That is you grant the execute access to the user ID beforehand and revoke the access afterward. Since this is grant/revoke between user ID and programs, it’s much safer. If you have to grant/revoke between user ID and tables, there might be cascade effects. 4. Before the change, capture the “before” data and get ready the fallback script. 5. Don’t forget to turn on the audio options/tools during the change window. 6. If you guys work in a physical office, you can think about binding those revert transactions to a dedicated desktop. I know these rules are complicated and tedious, but they could protect the team and the data as well :) |