An Oracle DBA at JavaZone – a fish on land?

JavaZone 2016

Why in the world should an Oracle DBA spend two workdays at a Java conference like JavaZone. It doesn’t matter if the JavaZone is the third biggest Java conference in the world, serve great food all day long, have a concert at night with awesome bands, and – of course – you get a couple of free beers. It just doesn’t make sense. Or does it?

According to rationalwiki.org there are fish that survive on land. Sometimes I do feel a little lost in the crowd of developers, but I survive.

I must admit that I’ve attended this conference almost every year since 2010. Why?
Well. This year I’m presenting, and I guess that makes my presence perfectly legitimate. But again – are there other sensible reasons for a DBA to attend a Java conference. I think so.

Learn something new

img_1194Developers are lazy people – like any other smart people. They constantly seek ways to do things smarter and with less effort. Attending developer conferences will probably show you technology and ways of doings things that you never thought off. In my case it was developers that introduced me to tools like Vagrant, FlywayDB, Docker, SALT, Ansible etc. Now I  use both vagrant and docker to run Oracle on my laptop, and can create a new fresh database in a matter of minutes – when Ineed,  and remove it in a matter of seconds – when I don’t need it any more. Using version control systems like subversion and git was also something new that I learned from my developers. 

Many Java developers use object relational mapping tools (ORM APIs) like Hibernate to make their life easier. I have met many developers believing they don’t need to know SQL. Of course this is not true, but as a DBA you really need to have a good explanation for not doing this. In 2013 I went to a presentation by Lukas Eder, the man behind the JooQ framework. JooQ turned out to be a very good alternative to Hibernate. It is SQL-centric and gives the database the attention it needs.

DevOps

One of the buzz words for many years now has been “DevOps”. Yes – this is the old developer versus DBA issue. But think about it. If you put the average DBA together with an average developer, what would they have to talk about. First of all – sorry for doing this generalisation, but it’s done for a reason. I actually think this might be one of the causes behind the developer versus DBA issue.

A DBA could actually cover a lot of different roles, and it would be hard for any DBA to be an expert in every area tied to the use of a database management system (like Oracle). My experience is that very few DBAs would actually contribute in a development project. Back in 2006 I worked as a DBA in one of the biggest IT companies in Norway. In the past I had become the hero in many task forces, finding the cause of different performance issues. Based on this I had a reputation of being an expert regarding Oracle and performance.  So when a customer needed an Oracle DBA for a bigger development project, I was the natural candidate. Today I must admit that I did not contribute with anything in that particular project. Why? I didn’t have the right knowledge and experience.

I used to be a pretty good tennis player, winning the region championship in my area when I was 16 years old. When I was 27 I met Elin (which is my wife today). Elin was the norwegian champion (for 14 years) in squash. Both tennis and squash involves a racket and a ball, the ball can only bounce once, and you hit the ball over a net (or list). I knew tennis, therefore – in my head – squash was my game. After 2 years Elin one day asked me “why do you get mad when loosing against me? Do you actually think you could win?” If i wasn’t mad from before I definitely was now. “I only loose with a few points. I’m so close at winning”. Then my wife said: “Well – don’t you think I maybe is a little bit nice with you. Why don’t I play you once using my left hand?”. As you might understand – I was now cooking – and had no other option than to accept the challenge. I must admit that I was pretty sure that I was going to win the next game. Well – you have probably guessed what happened. I lost! And I think the score was something like 11-0.

So what’s my point? Even if I was a DBA back in 2006, and a knowing performance troubleshooting, this did not make me qualified for doing application design. But as a DBA when somebody tell you “you know Oracle and performance – you are perfect for this project”, it’s very hard to actually say no. Development projects probably don’t need a DBA, but they need an … and this is the problem. There isn’t really a word for it. So maybe we could call it a Oracle Developer … or AppsDBA … or a “Oracle Resource with knowledge and experience from development projects contributing both with application- and database design”. By the way- I have won against my wife. Did she let me win? I don’t know, but we are still married.

Other database systems

Maybe I used to be a little religious. Maybe I used to think Oracle was “the” database. Attending Java conferences I have learned that there is a lot more in this world than Oracle. I still believe Oracle is a great database platform – if not I would be out of a job. This is what I work with! But this does not mean that I would recommend every project to use Oracle – or a relational database. I have to quote Tom Kyte on this: “It depends”. This is also a statement that pays of when you speak with developers. If you are religious they lose faith. I would too, if you came and told me that I should use this one racket for every sport. I could, but it wouldn’t be very smart, and I would potentially lose a lot of matches.

Oracle or related material

Yes. There is actually presentation that I could relate to in my daily work with Oracle. The presentation by Lukas Eder – “10 SQL tricks you didn’t think was possible” was great. Of course I knew some of this before, but features like the model clause, match recognition and pivot clause is not something I have used before. Well – actually I think I once used the model clause. Lukas explains the use of this in a very entertaining way, which really makes you want to dig deeper into these features.

Another presentation which I really enjoyed was “The Silver Bullet Syndrom” by Hadi Hariri. Even though it was about silver bullets in the Java and developer world, this could might as well been in an Oracle or database context. Though I think the developers are more infected with this “virus” than DBAs.

I also liked the presentation from Finn.no on Kafka (“101 ways of configuring Kafka badly“). If you have a lot of clients hammering your database with small inserts, this might reduce the scalability of your solution. Using Kafka as a front layer you might be able to batch up inserts into your Oracle database. I have never tested this, but it’s one of the things that I want to follow up, and have a closer look at.

And the you had my presentation about the Oracle End-to-end Metrics. A requirement to be able to use these features is that your developers actually implement it. To implement it – they have to know about it. So hopefully there is more Java developers out there today, seeing the advantages the end-to-end metrics give.

And most of all …

I think DBAs should strive to understand the developers. When a developer starts to  talk about NoSQL databases, you should know what he or she is talking about. You should know why and when a NoSQL database is a good option, and why it might not be a good options for your project. Developers are champions at following silver bullets. They always chase some new technology to solve their problems.

How can we actually contribute towards our developers and development teams. I don’t think you should sit and wait for the right question or task from the developers. They probably don’t know what to ask for, and they probably don’t know how you – as a DBA – can contribute in their project and in their work. Someone has to start this conversation, and if the developers don’t – the DBAs should!

Post a Comment

Your email is never published nor shared. Required fields are marked *