The intern is feeling good about himself. He has worked with the application team on the big new project designing the database structures, protecting the data using constraints and implementing proper security protocols, and assisting the development team on a daily basis. The intern was beginning to think, that perhaps, just maybe, he might be able to handle this job.
His mentor was proud of him, but he knew that the intern had much more to learn. "Keep in mind the word of Lao Tzu, who said "Lay plans for the accomplishment of the difficult before it becomes difficult; make something big by starting with something small"
"And be ready," said the Taoist DBA “for everything, because eventually everything will happen.” The intern wept as his mentor laid out all that was still required to do.
The lesson here is to be sure that you schedule appropriate backups for each and every table space... or a means of backing things up at the system level when that is appropriate. Understand the volatility of the data and the type of recovery that may been needed for each object. Learn about incremental backups and how they differ from full backups. Know how often backups may be needed: more than once-a-day, daily, weekly, monthly, etc. And be sure to test the recoverability of your databases... it is not enough to simply make the image copy backups without ever testing that they can be used for recovery purposes!
The intern learned and worked hard to develop an appropriate backup strategy for the new system. After a few weeks of diligent effort the intern nodded his head and told his mentor "This backup stuff is pretty easy, isn't it?"
"I’m outta here," was the sole reply of his mentor, and all that remained was his spinning chair and a cooling mug of coffee.
The lesson here is that nothing is easy and that there is always more to learn and do. A local recovery plan is vitally important, but you also need to develop a disaster recovery plan, keep it up-to-date and be sure to test it at least annually. Take nothing for granted!
Always remember that contingency planning and recovery from a disaster is a complex and time-consuming endeavor.
As the intern was working on how to integrate the databases for the new system into the disaster recovery plan, a developer he was working with on the project stopped by his cubicle and told him that he couldn't access one of the test tables.
The intern logged onto DB2I and displayed the test databases noticing that one of the table spaces was stopped. "Hmmm, how did that happen," muttered the intern DBA under his breath. "I think I can just restart this," he thought, "now what is that command?" As he rifled through the DB2 Command Guide his mentor stepped back into his cubicle and looked over his shoulder as he typed:
-START DATABASE(DBNAME1) SPACENAM(TSNAME2) ACCESS(FORCE)
Fortunately his mentor had arrived just in time to smack him in the head and stop him executing the command.
The lesson here is that force fitting a resolution to a problem is not a wise approach for the DB2 professional. Why is the object stopped? Uncover the reason behind the symptom and resolve it appropriately. Find out the state of the object and the reason code that caused it to be stopped. Only when you are sure that it can be safely started should you run a START command... better yet, resolve the issue by running a RECOVER or a CHECK on the object based on the situation.
Crisis averted, the intern went back to his recovery planning and his mentor went to get a fresh cup of coffee.