Voice of the DBA

Author: way0utwest

The Master of the Schema

“The database … should be the master of the schema”.

It’s not often I see an application developer talk about the importance of the database, or at least that the database (and data) are very important to the success of the application, but in this case, that’s what I saw. The quote is from this blog, which talks about the problems of the code first approach to building an application. It’s from a Java development company, though it’s their jooQ product blog that actually generates Java code from the database, so they get the need to pay some attention to the database.

The thrust of the article is that using an ORM is fine, but this isn’t necessarily the best way to design your datastore if you need a relational system. There will be mistakes made in naming objects, in structuring them and ensuring indexes exist and more. The longer you go with generated database code from some code-first type system, the more issues you might have later as you try to modify both the application and database, especially the database, since you can’t drop it and recreate it.

If we could drop the tables and rebuild them, life would be great. Maybe we should keep copies of data on the clients, and just reload the necessary data after a deployment… It would make my life easier as a database professional, but I suspect this isn’t the best way to ensure data quality and consistency (not to mention completeness).

I agree that if you’re building an application, you should go database first. At least start with some basic structures and learn to modify them. The practice you get modifying code, with scripts not GUIs, will be invaluable later to both developers and DBAs/admins. You’ll start getting practice and understand what it means to deploy scripts to your database. After all, making schema changes with scripts in your development database is the first “practice” you get for deployment. If you can’t get the scripts to work here, how would you have any confidence they’ll work in production?

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 3.1MB) podcast or subscribe to the feed at iTunes and Libsyn.

August 14, 2018
Another Brick in the Wall–T-SQL Tuesday #105

It’s that time again, and this month we have a good topic from Wayne Sheffield. We’re asked about getting stuck, about being blocked, about encountering a brick wall.

I have to say that I don’t think I encounter these very often, usually because I try to be effective, even if things get ugly in code. The important thing for me is to deliver value. That doesn’t mean I build slapdash applications and leave them. I do my best, and try to continue to learn to build things better. However, in the heat of the moment, I might need to do something silly that I end up either rewriting later or having someone else rebuild the solution.

With that…

The Large Aggregate

I once worked for a financial services company. This was decades ago, back in the age of spinning disks, SQL Server 6.5, and flip phones. We had a number of clients on our main application, but one large client that dominated our business.

We needed to provide quarterly summaries of activity and portfolio performance for all clients, but for this main customer, they also wanted us to add monthly reports. They were actually their own management firm, but we provided them with back end services. Within a month, they would have millions of transactions that we had to group by some organization and then calculate performance.

This wasn’t a big deal with other clients, though most of them had relatively simple calculations. For this client, however, they had separate rules for certain types of activity and the result was a calculation that we couldn’t easily get into CASE statements or other types of query workflows.

In trying to handle all their requirements, I (and my junior team), got stuck. We couldn’t come up with a set of queries that would work. We didn’t want to go down the road of writing custom queries for each organization as this would be an ongoing nightmare as new requirements were introduced.

We had delay after delay in trying to implement their monthly reporting and pressure kept mounting. Eventually we turned to using temp tables and making different passes through them to handle specific requirements. We had ugly flags in our temp tables to let us know which set of rules we’d applied and which we hadn’t.

The code worked, but it was slow. Too slow, in fact, and my boss wasn’t pleased. After a particular unpleasant dressing down, I was wondering if this was the career for me. I’d talked with friends, posted questions, but in this pre-SQLServerCentral era, there were limited places to get assistance. I had hit brick wall.

I never got to find a solution to the problems. My boss at the time was one of my worst, and he became petty. I started to get assigned various inane tasks, which were slightly annoying. However, on a night off, while on a date with my wife at a concert, he paged me with an emergency. I had to leave the show to answer and call in. When I did, he told me this was just a test to see if I would respond, then berated me for taking more than 5 minutes to do so.

I quit the next day.

Perhaps not the best reaction, but between the brick wall and poor treatment, I decided to move on. Hopefully someone else managed to solve the the performance issues and help the client.

August 13, 2018
The New SQL Provision Dashboard

As much as I liked the ability to quickly and easily build development and test databases with SQL Provision, I thought the dashboard of cloned databases was hideous. It left a lot to be desired, and frankly, the dark theme is annoying to me. Here’s my old dashboard.

I wasn’t alone, as various customers were asking about enhancements and additions. The team has been listening and I talked with them a few months ago during a meeting about possible ideas and designs. I saw an early mock up, and was hoping it would be released soon.

After coming back from vacation, I saw an update was available, so I applied it. After a few minutes, I saw this:

Once this was done, the page refreshed, and I saw the dashboard. I know, not much has changed, but look at the upper right part of the screen. There’s a blue box that says “Preview new dashboard”.

Once you click this, you get a new dashboard, which thankfully doesn’t use the dark theme. What’s nice is that I also get some information at the top of what my activity is. I can see the total clones and images, and the machines that are working or having issues.

I also have options for resorting the clones and images. I can change the sorting, which is set by the client, not the server. This means one person can see clones by instance, while another can see clones by image.

If I change this, you can see that I get a new view at the bottom.

There are more changes needed, and some coming. There is a feedback item when you switch to give feedback to the team, and I’d encourage you to do so. Certainly I think sizes or some calculation of total sizes for images and clones is needed. It would be nice to get filters for sizing, so I can also tell if someone is using a clone to do a lot of work and growing it’s size. One of the important things here is that you ought to not get to wedded to a particular clone. We want to rebuild these as needed.

I’d also like to see some way to link images to a source and perhaps group them so that I know how many copies I have of some database, like production. While I think we definitely need a couple of images at any time for rotation, we want to get control of our systems and limit the number.

If you have other feedback, let us know, and we’ll build a better dashboard together.

August 13, 2018
The Worst Day

I challenged people to write about their daily work a few weeks ago. I haven’t see a lot of posts, but I am still hopeful some of you will document your day, as Iris Classon has done a few times. It’s not that I expect a lot of the same posts, but rather, I’d like you to talk about the way a specific day has flowed for you. Did you work on a problem? Just pick up tickets and perform routine scripting? Learn a specific thing? Give us some details. I expect everyone’s day to be different.

Jon Shaulis broke his series in a few parts, one of which was his worst days as a DBA. I thought that was interesting and it brought back from memories for me. Overall, I’ve had mostly good days, and even the crisis situations weren’t that bad. That being said, there are some tough days, both physically and mentally, and worse, tough for my family.

This week, I wanted to ask you what was the worst day in your career? Or maybe the worst event, since some of the tough times I’ve had actually spanned multiple days. Let us know what happened, but also, what the challenge was for you?

I’ve got a couple items. My first exposure to SQL Server was as a network admin. I helped a group of 4 other FTEs run a large Novell Netware environment of over 1000 nodes. We handled the servers (6 or 7), email, and more for hundreds of employees. We managed Netware servers, Windows (and DOS) desktops, and way too many printers. As a part of a government mandated change, we rolled out a new system at midnight on Jan 1, backed by this new database, SQL Server. We installed an OS/2 server at the end of December and prepared for the cutover from the old system. Since this was a mandated change, we weren’t going to roll back. Ever.

I arrived at work on Dec 31, around 6pm. I planned on getting setup, checking with developers, and being ready. We cut over at midnight and people began using the system. Within 30 minutes, we had problems, including an overloaded SQL Server that would freeze up. We ended up babysitting the server to reboot it regularly, as well as trying to determine the problems. I left work on Jan 2, around noon. That was a bad day.

Another bad way was with a SQL Server 6.5 instance that ran financial services. We detected corruption in a table and got on the phone with Microsoft one afternoon. I worked with support, being handed off from the west coast to Asia to North Carolina throughout the night, trying to debug the problems and extract data. A nice 30+ hour, high stress day for me. After that I kept a pillow and blanket in my desk, which I used a few more times that year.

Those were tough times, but most of my days are great. Some are long, some stressful, but overall, I’ve enjoyed my time doing database work. Can you say the same thing?

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 5.3MB) podcast or subscribe to the feed at iTunes and Libsyn.

August 10, 2018