It’s not too hard to see that the alliteration was on my mind when I came up with the title for this entry. And I could have added one more “D” to the title with “Discussion” or “Definition”. I view this as a discussion since the exact duties of a DBE (Database Engineer) can vary depending on how responsibilities are divided up within your IT organization. Even if there are other teams that own functions like security, a DBE should function as an extended member of those other teams focusing on the database-specific requirements.
On
client engagements, our Lab Services Db2 team is often asked “What should be
the duties of a Db2 for i DBE?”. The short answer is that a DBE performs the
same role as a Database Administrator (DBA) on other platforms minus the
low-level administrative tasks. And that’s why our team uses DBE instead of DBA
to highlight that difference.
Recently another blogger wrote about the responsibilities of a traditional DBA, so I thought it would be useful to compare that list with the to-do list of a Db2 for i DBE. You can find the complete DBA writeup here. I’ve summarized that article by copying some of the key high-level topics here and adding my Db2 for i commentary. I have used green to highlights those responsibilities that are exact matches for a DBE and the red for those tasks that are not as applicable to Db2 for i.
·
Data modeling and database design – Going back to
the AS/400 days, this design work often was done by the application development
team. Unfortunately, this also explains some of the subpar data models that our
team encounters. Now that Db2 for i has much a wider set of technology that can
be applied to the design, a DBE should be leading these efforts.
·
Database schema creation and management – Allowing
others to create and change Db2 objects is a mistake because it increases the
risks that those without deep Db2 knowledge will perform the actions
incorrectly resulting in database performance and security issues.
·
Metadata management and repository usage – “Data
about the data” is important. Probably a small part of a DBE’s job, but they
must support the company’s efforts to document the business data.
·
SQL code reviews and walk-throughs – Another
intersection point between a DBE and the developers. These reviews are a great
way to prevent query performance problems. In the process, developers learn
more about SQL programming performance best practices.
·
Programming and
development – A DBE doesn’t need to worry about the state of an SQL
program object causing performance problems. Traditional DBAs often have to
BIND/REBIND SQL programs when the database or server has changed to notify the
optimizer about the change. The Db2 for i engine automatically recognizes changes
that have been made to the database or server changes that may impact
performance.
·
Procedural coding and debugging – With proliferation
of procedural SQL, a DBE needs a good understanding of these SQL objects. In
addition, procedural SQL makes it easy for a DBE to programmatically use Db2
for i utilities and services for database maintenance.
·
Performance management and tuning – This role is a
no-brainer. On a system with SQL usage, a DBE should be continually focused on
proactive and reactive performance tuning. A solid indexing strategy is a critical success factor in this area.
·
Ensuring availability, Backup and recovery – Both of
these tasks are usually handled at the system-level in IBM i shops, but a DBE
needs to be aware of the database impacts for the different types of system
approaches to keep database availability high and providing input to the system
strategy.
·
Data security – A DBE is going to be working hand in
hand with the security administrator to ensure the best database controls are
used to meet and enforce the company’s security policy.
·
Data movement, Data archiving – DBE should
be leading these efforts to ensure that data is moved/archived safely and
efficiently to minimize impacts on system performance.
·
Ensuring data integrity
– The other article highlights the use of database constraints and triggers to
ensure data integrity. However, I would argue those are options a DBE would
consider in the database design. The reason this topic is highlighted as not
applicable for Db2 for i databases is because it talks about a DBA ensuring the
structural integrity of database – looking for corruption in the disk page and
structures associated with table and index objects.
·
Storage management
techniques – Thanks to IBM i single-level storage, a DBE doesn’t have to
spend time allocating disk storage for Db2 for i objects and trying to evenly
spread the Db2 object data across disk devices to minimize hot spots. As Db2
for i objects grow or shrink in size, IBM i automatically handles the
requirement for more or less disk space.
· Capacity planning – Yes, a DBE needs to understand future data growth requirements for their databases, but this work is done at a much higher level. This is due to the fact that IBM i single-level storage simplifies the storage allocation and management for Db2 for i objects.
Hopefully,
you can see how this list from the other article easily reinforces the
proposition that a Db2 for i DBE should be focused on the same work as
traditional DBAs minus a lot of the low-level administrative tasks. Thanks
largely to Db2 for i and IBM i operating system automating many of those low-level
tasks.
As I
wrap up this discussion, I wanted to share a discovery that I made while
putting this entry together. I learned that the DBA acronym is also used for
the phrase “Don’t Be Afraid”. One could
make a compelling argument that IT organizations with a DBA don’t have to be
afraid because the DBA role has their business data covered. These orgs have less risk because they’ve
dedicated resources to making sure that their databases are secure, available,
extensible, and scalable. And that’s why our Lab Services team continues to
remind IBM i clients about the importance of staffing the DBE role… it
minimizes the risks associated with your companies most valuable asset – the
business data stored in Db2 for i.
NOTE: After this entry was originally published, a follow-on entry highlighted Tools for the Db2 for i DBE
