DBAs are supposed to bring knowledge of the underpinnings of databases to the table. How to lay out tables and indices across disks for linear vs. striped access. How to properly set up partitioning for different types of access. Granting assorted privileges and roles. Managing backup and aging off data in a controlled manner, and so forth.

Some take pride in showing developers the "right" way. Some are maniacal in their tight-fisted my-way-or-the-highway approach. Others seem better suited to a career of asking do you want fries with that?

6sided dice

Bob works at a large, lumbering bureaucracy where there is a procedure for everything, and everything has a procedure. The fundamental premise is that everything should be automated. Requisitioning supplies. Personnel. Software. Deployments. Everything.

To that end, every support team has a plethora of forms where you just click all of the check boxes next to the stuff you want, then click "submit" and a script will automatically do it for you. Sure, it pings a task-owner for approval for certain things, but the managers are so conditioned to just hit approve that you could requisition a GAU-8 as a management training tool, and it would likely get approved. In development. The UAT and production environments were subject to the usual plethora of approvers before anyone could actually do anything.

As such, it should come as no surprise that creating a database, and allocating space, as well as permissions to users is fully automated as well. There is a huge web application that allows you to request that a database be created with a given name for a given system. After you click 'OK', your brand new 10MB database is ready for use and you can begin to administer it.

Bob wasn't a DBA, but had a pretty good idea of what his team needed. Of course, there are things that DBAs do behind the scenes to keep things running (hopefully smoothly), but this was of no consequence at this point.

Bob requested additional space, as 10MB wasn't going to be enough for scratch space, let alone indices, let alone actual data. As the database administrator, he granted himself select, insert, update, delete and execute permissions. He added his co-workers and granted them permissions as well. Then he began to create tables.

After discussions with his team, they decided that partitioning on run-date would be the way to go. He created each table with a bunch of partitions, and local and global indices. He even included a catch-all partition just in case the script to create the daily partition didn't run or failed. Of course, since there was only one table-space in the database, all he could do was assign everything to be thrown together in one big pile.

He made a point of putting a task in the project schedule to have an actual DBA review everything that he was doing so that it would work properly when deployed and had to scale under load.

Fast forward a few months and it was time to have a DBA review the database. The request was made for a DBA to sit down and look at what had been designed. Four days later, the answer came: No!

Bob replied: What do you mean "No"? Everything that's in this database was created by clicking on forms, but was never holistically reviewed for sanity. What table-spaces are needed in a real environment? Do we need to create nicknames, and for what? What about temp space? Did we allocate enough? Are the partitions set up in the best way? What about the local/global indices? Did we set up roles correctly? How will all of this migrate to the UAT environment? What about production? We need an expert who does this for a living to review it with a critical eye and make sure it's the way it needs to be!

The DBA team replied: We only manage the farm of disk space and the physical servers. We don't manage individual databases; that's your responsibility. If something doesn't work, give us the commands to execute to change whatever you need to change and we'll run them for you. Normally, we have a turn-around time of about 3-4 days, but it can be longer if we're busy. This applies across all environments.

Bob was somewhat taken aback by the sheer idiocy of this policy. In an attempt to locate sanity in the midst of this madness, he sought out peers who had used this mechanism to see how they got their stuff into working-form for production. Sadly, he discovered that they did it by trial and error. When something didn't work in production, they made their best guess as to what might fix it and asked the DBAs to make the change. Then they waited for the approvals to be made and the work to be done in order to see if it would make a difference.

Bob reported this as a huge risk to the potential success of the project, but was told that it's just the way things are, and to roll with it...

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!