By Uri Margalit
I recently had a discussion with a DBA, who reminded me of days long ago when I was a DBA for almost 15 happy years. I worked with IMS, DB2, Oracle, MS-SQL, Sybase, and MySQL. I usually started as the only DBA in the organization, then hired people and established a DBA team. After my DBA days, I switched to the world of R&D where I managed the development of tools for DBAs. Today, I'm the Director of Products Management at DBmaestro, where I am still immersed in the database world. However, this time my products are not just for DBAs, but also for developers (in order to make a DBA's life easier).
Looking back, I remember that my role as a DBA did not really fit into the scope of R&D, as I was also in charge of production and everything that had the word "database" in it. For example, I was responsible for keeping track of the developers' changes, creating their initial environments, and merging their environments with changes from other teams. On top of all of that, I was expected to be involved in design, making sure the database and applications were well-tuned.
As you could expect, I found myself burdened by the tedious tasks of merging, creating environments so that the developers can work and was less involved in the designs. I didn't even have time to run performance tests or keep track of the changes being made as I would have liked to.
Being lazy, I always tried to automate my work so I could be more efficient, but it took me several months to reach an acceptable level of automation. It usually involved taking up the developers' time to create the tools I needed (in order to support them).
So, what was missing for me during those happy days? I definitely needed something that would have allowed me to be more in control of the changes developers made in the database. Better control over schema changes would have allowed me to be more involved in design, while more control over changes to database code (procedure, function, package, etc…) would have enabled me to fix performance issues before they occurred in production.
Of course, I could have solved those issues if I didn't allow the developers to make changes directly in the database (only I could make database updates), and forced them to work with scripts. However this approach would not have lasted even a week.
Merging and synching also consumed a tremendous amount of my time. I found myself spending about 5 to 7 days a month merging environments for development. The reason that this task was done by me and not the developers was because: a) it involved a database; b) not every developer was up to this task as it required a deep level of database syntax and understanding of the dependencies between database objects.
Looking now at the tools that exist today, I can only regret that I didn't have them then.
For example, a Database Enforced Change Management (DECM) solution will allow developers to work directly on/make changes to database objects. I can then look at the reports and see who made what change, when, where and why. The fundamental requirement for this solution is that the work on the database object must be synchronized between all team members. Otherwise I would be interrupted by a developer complaining that his/her code disappeared (as someone else compiled the same package, procedure, etc.).
[Database Enforced Change Management Policy]
But DECM wasn't around in my DBA days, so I had to use what I could. I used file-based version control, which was used by the developers for their development, and tried to make it work on the database. This posed a great challenge because sometimes the developers forgot to sync between the database and the file-based version control processes and I paid the price (no hard feelings).
[Two Isolated Processes]
What I needed was some way to turn the development process into a single enforced process, as they had in their native application code (Java, .NET, C#, C++, Cobol, etc.).
[A Single Enforced Process]
I also wanted a reliable way to easily merge environments (preferably with a click of a button). Being confident in the automation is important; otherwise I would not use it. Compare and Sync tools (cutting edge technology at that time) didn't help me much. One example of why was when the database object in my target environment was not the same as in my repository. Because developers sometimes forgot to update the file-based version control repository, I couldn't be sure where the correct definition of the object was, so I had to ask my colleagues questions.
[More than Simple Compare & Sync]
Another example was when I had to merge (not just override) the development database with what existed in the file-based version control repository. The challenge here was to catch the work-in-progress objects and avoid overriding them with the code in the file-based version control.
If I had a DECM solution back then, I would have been happier and more productive as a DBA and would have been able to use my knowledge and experience more effectively. If you are a developer, team leader, or R&D manager, I recommend that you find ways for you and your team to help the DBA be more productive, so you can gain from their experiences.
Now that I've told my story, I'm very interested in your comments.
About the Author:
Uri is a product executive, who possesses over 22 years of experience and has a proven track record for taking new ideas to the market. With a passion for understanding and translating market requirements into working products and solutions, Uri effectively leads product teams in the enterprise software and systems management categories. Prior to joining DBmaestro, Uri held senior Product Management and R&D Management positions at SafePeak (a leader in performance and scalability of enterprise application systems), Symantec (a provider of information storage and security services), VERITAS Software (which merged with Symantec in 2005), and Precise Software (which was acquired by VERITAS in 2002).
Uri earned a BA in Sciences from Open University.