I realize this is backseat driving and I don't know anything specific to your environment but I see the above often and it drives me crazy because if done right the DBA's life can be pretty cushy and make everyone's job a lot easier.
First, fully script all restores/backups of all databases. Then cron that poo poo overnight. Yesterday's production data should always be immediately available to test against without anyone lifting a finger. If you are lucky enough to have fancy SANs create scripts to spin up copy on write DB clones from automatically restored databases which let you create a fresh testing environment near instantly (bonus points if this can be done through a web interface by QA or automatically with application deployment scripts, sparing you the trouble).
Then when your PM comes and say, "We need new production data on the testing environments ASAP for this new project" you can be like, "Sure, yesterday's production data was automatically restored at 2am today, QA need only press this here button to get an application with fresh data to test against". Then you walk off to lunch in slow motion with classic rock playing in the background.
Or when you get a worried manager, "Do you check the backups??!" "Yep at 3am today yesterday's backups were restored and checked automatically and our testers now hammering the restore as we speak working on that new project" And then you walk off to get coffee in slow motion with classic rock playing in the background.
This also lets you easily give people a fresh playground of production data to test/report/truncate tables against instead of giving them actual access to production which should rarely be interacted with directly.
If you or any human is manually interacting with a database for non-experimental regular administration tasks like configuration, backup, restores, and schema changes there will be slow downs and gently caress ups and life will be more difficult than it needs to be.
|# ¿ Nov 20, 2011 01:08|
|# ¿ May 25, 2013 23:17|