The first start-up stage I’ve worked within is the prototype phase. Within this phase traffic is not an issue for performance or scale, it’s about functionality. Low traffic and small datasets can hide atrocious code quite easily. The nice thing about this stage is that you should not have to invest a lot of time or money into your database and instead can focus on functionality and business development. Over-engineering at this point can be a devastating waste of very precious resources.
Here are the three criteria I would recommend focusing on:
1. Standards – I’m not talking about long lists of rules or apocryphal abbreviations here; rather focus on simplicity, consistency and usability. Don’t make decisions without asking yourself if the choice you’ve made is simple to practice, can be done so consistently, and would be easy for a new employee to use. Without standards, you will find that your database quickly becomes difficult to navigate and utilize – and a headache to maintain. Important standards include database object names, file system layouts, documentation design and locations.
2. Backups – There is nothing more frustrating than losing days or weeks of work. One of the key jobs of a DBA is making sure that your data can be recovered in case of a crisis. From the beginning, you need a solid backup and recovery process. Again, at this stage, nothing elaborate is required. It may be as simple as a nightly dump, or you may need more frequent dumps and perhaps even point in time recovery depending on the amount of change and number of people making the changes. Another key factor here is actually documenting how to perform the restores and practicing them regularly. Backups do fail and sometimes that failure is subtle. Regular practice will help to insure a successful recovery.
3. Documentation – As you make decisions about standards, set up processes, start building scripts, and implement tools and management utilities you need to document them for repeatability. Wikis are great for this, but again you must maintain a culture of discipline in regards to documentation. Tasks should not be completed without documentation and those responsible for doing so must be held accountable for it. This is an excellent way to start building discipline into the culture. As the prototype becomes operational more rigorous processes can build on this, such as change and problem management.
Interested in working with Administrator? Schedule a tech call.