Controversial?

Agile is a way to find out quicker that those cheap resouces who don’t know SQL are killing you.

Joke, sort of…

Prod DBA 2.0 says no**

Dominic Delmolino has made a welcome return to regular blogging and it’s good to see that I’m not the only one forgetting the basics.

In the body and comments of Dominic’s*** first few posts back, the subject of database development is very much in focus.

So, DD got me thinking and here is my stream of random ramblings – they jump about a bit, it must be a Friday.

Production DBAs have no place on most development teams!

When was the last time you saw a production DBA in a scrum standup? (Genuine question – do you do that?).

Today’s production DBA is a busy man whether he’s 0.x (seen a lot of these), 1.0 (met a handful), 2.0 (heard tale of a few) :)

Some might say they’re too busy coming up withinsane “policies” and standards.

At the very least, even if he has automated everything that he can automate(*), with the vast estate of DBs that a small, modern production DBA team *should* be able to support, the ebb and flow of urgent production issues means that he’s unsuited to the predictability of the resource availability that modern agile project development demands.

That vast estate of DBs that a small, modern DBA *should* be able to support also means that the knowledge that the production DBA of any one specific application or schema tends to be very limited.

However, for most enterprise-level data-centric applications (caveats and clarities due to previous sweeping statements), the data model is still so important and it’s just not being done right in so many places.

Here is a link post to a selection of other writings on the subject.

What Dominic D says strikes a chord with me. (But I’ve got a vested interest. The role he describes is essentially what I do or what I try to find.)

Most agile development teams (caveat again – most agile development teams developing enterprise-level data-centric applications) need access to a database development specialist.

Someone who knows SQL, knows PLSQL (in the case of Oracle), knows performance and knows the features and functionality of a database ideally to at least the same level expected of a production DBA (albeit with different peaks and troughs in specific areas) but without the irregular demands on their time from urgent priorities.

Most of them need this to be able to build data models that scale.

And to keep everyone on track with the data model and the big data picture – this can quickly get lost in translation especially with commodity developers (plug and play).

Most of them need this to write or at least QA SQL and PLSQL that will scale.

Most of them need this to strike a balance between new features and stability.

Most of them need this as a regular interface to the production DBAs as a communication conduit and filter, and to uphold the requisite standards and policies for development to move into production.

And absolutely this database specialist should take full responsibility for what goes into production – it’s all about control and responsibility.

Two other thoughts occur (and I’m not sure I’d finished on the previous thought but it’s gone now, flushed).

Firstly, and I commented this on DD’s blog, there is belief that all developers are equal and that you can plug and play any developer into any project without any consequence. I don’t believe at all in this approach. I’ve never seen it work effectively apart from in the presentation layer – i.e. coding input fields and buttons, etc – and even then I’m far from convinced.

What I am definitely convinced about is that this in no way works for any layer that requires significant business knowledge and goddamit does that include the database.

On the subject of the second of the two thoughts mentioned above, the phone rang before I could write it down and so that thought has now disappeared. If I remember, I’ll update this. Until then my mind’s gone blank….

Update:
Oh yes, the second thought. Development DBA is sometimes the starting point for a junior DBA – en route to the production DBA. This is a nonsense given the control, responsibility and knowledge required. As mentioned they need to know at least as much as the typical production DBA.


*I’m not a production DBA. Never have been. And although I’ve thought about it, not sure I want to be. Development’s where it’s at for me. But how DBA teams have much automated? And automated well? Everywhere I’ve been recently, the DBAs are firefighting constantly. Or they’re refreshing environments. Or they’re just completely overloaded with stuff that sounds like it should be automated. I mentioned this to someone else recently and they commented that it was because a large percentage of the production DBA team were contractors and has no vested interest in automating. I don’t know if that’s true. Any thoughts? There should be no greater compliment than going into a company and improving it to such an extent that the manual intervention you were providing was no longer required. But I can see the conflict.

**Prod DBA 2.0 says no -> Not sure how many, people outside the UK are familiar with Little Britain. Think it was way overhyped myself, followed by way overplayed. Personally (as comedy appeal always is), although there have been exceptions like the Armstrong and Miller fighter pilot sketch, there’s not much sketch comedy that has regularly and consitently tickled my fancy in the last decade since the Fast Show.

*** Confusing – am I referring to Dominic Delmolino or have I taken to the convention of referring to myself in the third person.Did you know that the latter is known as Illeism? I didn’t.
Stylistic device or a form of narcissism?
My CV is in the third person and I’ve never been even 83.2% happy with that approach.
But I’ve never liked it when I’ve rewritten it with a personal pronoun – “I” – neither with the modern trend of no pronoun whatsoever, e.g. “Worked on an oil rig. Implemented XYZ. Put out lots of fires.”
It stems from my time at a consultancy – that was their style.
Then again, I don’t agree with the narcissism interpretation (e.g. a bit like celebrities and some sports persons).
If anything, for me at least, it’s completely opposite – a form of anti-narcissism, a self-demotion which I think of as being particularly British.
It can be easier to say “X achieved this” than “I achieved this” and maybe there’s a comforting distance between this CV character “Dominic Brooks” and myself?
Don’t know if there’s an established phrase of “take the blame but share the glory” but maybe it’s something like that …

Did I know that?

On an internal chat channel a while back, someone wondered if, as part of a process, they could lock a table, do some stuff and truncate the table as part of the same transaction, with the idea that with two concurrent sessions, the second session would wait at the lock table stage before progressing.

At the end of the day, it doesn’t really matter why they wanted to do this, whether their thinking was flawed or whether there were better approaches, because the reason why this particular approach can’t work is a simple illustration of a very basic Oracle concept.

Session A

SQL>
SQL> create table truncate_me
  2  (col1 number);

Table created.

SQL> lock table truncate_me in exclusive mode;

Table(s) Locked.

Session B


SQL>
SQL>
SQL>
SQL> lock table truncate_me in exclusive mode;

... waiting ...

Session B waits, naturally.

Back to Session A:

SQL> truncate table truncate_me;
truncate table truncate_me
               *
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified

SQL>

Eh? What was that?

Back to Session B – which is no longer waiting:

SQL> lock table truncate_me in exclusive mode;     <-- Still previous statement

Table(s) Locked.

SQL>

Maybe when you see this, you’re like me and there’s a brief pause while you look up and to the side (in what hopefully looks meaningful though) before you “remember” that Oracle issues a COMMIT both BEFORE and AFTER a DDL statement.

Then, maybe like me, you start questioning whether you really knew that? You used to know that, right? Maybe you had forgotten? Maybe you can’t tell if you had known and had forgotten, you still knew but you’re just a bit slow (and getting slower all the time) or you had never known…

Tom Kyte always says that he learns something new every day.

I wish I did.

Yesterday I learned lots of stuff while looking at 10104 trace file information – I enjoyed it. But how much of it will stick?. And for how long?

I often relearn something every day.

But that’s just a positive spin isn’t it?

A positive spin on finding out I’m forgetting stuff all the time.

And probably, most of the time, I’m forgetting stuff and not finding out.

Which is doubly bad.

Doing more for less…

… seems to mean doing less.

Over recent years, economic troubles, and focus on the bottom line, I’ve heard wide mention of the phrase “Doing More for Less.”

Everywhere I look where people claim to be “doing more for less”, all I see is doing less.

(Although making sure you look busy while doing less seems to be the most important “quality”).

Has there ever been a time where so many people have been so focused on the short term, today’s budget, what just needs to be done “for this requirement only”?

Or so little care about whether it will be still standing tomorrow, whether it’s good value, or the right way to do something?

It’s a checkbox world.

Box ticked? Check! Move on to the next one!

In my day-to-day IT role, I seem to have regressed recently to only having one line changes to make.

One line changes which take ages to test.

Is it the cheapest change to make for the requirement?

Check!

Are we slowly making so many cheap, tactical one line changes such that system just becomes too convoluted, the cost of testing changes vastly outweighs the cost of making the code change and it starts to look cheaper to start again than to make any more changes?

Check!

But I’m not just talking about IT.

After the recent cold snap in the UK, there have been potholes in the roads everywhere.

Last week a couple of the biggest, most alloy-threatening down my lane had suddenly been filled in.

Had they been filled in properly?

Of course not.

Was it a proper repair, properly sealed that stood a chance of lasting another bout of the cold stuff?

Of course not.

Had it just been filled and compacted in the cheapest way to meet the immediate requirement? Hole filled?

Check!

But I can push the edges of the repair with my finger and it starts to crumble!

At the gym this week, I was chatting to one of the instructors.

The local place had a reputation of having one of the best line-ups of instructors in Europe requiring several years of experience, sports science degrees, etc.

She was bemoaning the cost-cutting which had resulted in several very experience and motivating instructors leaving and the general trend of moving away from instructors with significant years of experience and sports science education towards using far less experienced instructors working to prescripted classes detailing the precise times to shout specific motivating phrases.

You could go to any of these guys and their wealth of broad knowledge would be evident when telling you what was probably causing a specific problem or suggesting a change to a specific routine, etc.

Same number of classes?

Check! (but shorter)

Short-termist?

Of course.

This years budget reduced?

Check.

Are punters leaving because of the poorer service?

Check!

Politics has always been notoriously short-termist. But in the UK so many of the actions are targeted towards just winning the next, imminent election, not doing what’s best for the deficit, the long-term future of the country, etc.

And just look at the state of people’s pensions with the actions on dividend tax relief when Labour first came to power, etc.

Tax raised?

Check!

Long-term financial security and state independence undermined?

Who cares.

I don’t like talking about politics. But what about the deployments of underequipped armed forces? Defence budgets cut? Check! Armies deployed? Check!

Look at the big banks. Saved by taxpayers billions? Check! Now inappropriately making billions of short-term profits based on QE and paying huge bonuses? Check! Move along! This isn’t the contrition and long term thinking that you were looking for.

I used to think that so many of the things which annoyed me were IT specific and the result of, for example, poor interpretations/implementations of “Agile.” (Mind you before that I was incredibly frustrated by the blind adherence to Waterfall – Analysis done? Check!)

But I see so many tangents in so many unrelated areas.

And everywhere I look (not just IT) there seems to be an abundance of managers (Managing? Check!) and a void of leaders.

It’s a funny old world.

Where are the last bastions of doing things properly?

The dea(r)th of Oracle RDBMS and contracting?

I’m feeling flat today and apologise for the sensationalist headline.

I also apologise for another one of this useless opinion-based posts. There are far too many opinions in this site, not to mention far too many posts on things requiring further investigation which never gets done, and not nearly enough concise, factual posts which give anyone any genuine interest. One day this will change… but not today - it’s cathartic to let it out.

So, I tend to contract these days, specialising in pretty much anything Oracle RDBMS-wise coming primarily from a development/application angle – i.e. development, design, performance tuning, architecture, development DBA.

Two observations I have about the current market for Oracle contracts in the UK.

Firstly, an increasing number of clients have HR-imposed limits where they will engage a contractor for a maximum of one year. For a database specialist, this presents a bit of a problem. So much of what we do is about the data. I find it takes at least six months to get a really good handle on just a fraction of the business and its data. So, after one year you’ve not long started ramping up the value that you can deliver. Maybe this behaviour is more common in banks and other such finance companies but, apart from my current client, I’ve talked to two prospective future clients who have the same such policy. This sort of policy only make sense if you think you can swap in/out any development resource and put no value on them having knowledge specific to your business.

And now to Oracle. I feel like the war has been lost and there are only a few pockets of resistance left now, resistance that will sooner or later be squashed. The religious war regarding sensible, about pragmatic use of databases and database code, about doing work related to data in the database, about data quality being enforced in the database, etc versus the database should be a bit bucket camp. 

Over the last few years I’ve worked on some pretty decent databases, some of which I created. They all took a pragmatic approach to the database. Even in n-tier Java environments, if it made sense we put the logic where it made sense, where there was a strategic or performance advantage whichever tier that was.

Even at my current client, I was pleasantly surprised to find a database-centric application – you might even say excessively so. But not for much longer. The database is under attack. A newly created hierarchy have decreed that databases are indeed bad.

And I was speaking to a friend today at a previous employer, a major media / entertainment company. They are planning to abandon their pragmatic approach to Oracle and switch wholely to open source databases, ORM tools, and the like.

I just don’t understand why. Actually I do understand some of the why. 

  • Databases don’t perform well when SQL is written by people who neither like nor understand SQL, people who don’t appreciate that they need to abandon their iterative approaches and need to think in sets, people who struggle to string together a couple of tables.
  • SQL doesn’t always perform well when written by people who neither like nor understand access paths and indexes.
  • It’s difficult to write good SQL against poor table design.
  • When databases don’t perform well, people don’t want to wait for people to tune or redesign, they want to buy some more memory or CPU and have it installed later that day. 
  • People of Influence with a decent database background are becoming few and far between.
  • People are reluctant to use built-in features like RLS, Oracle Audit Vault / FGA, etc, etc and prefer to write their own framework from scratch.
  • And not insignificantly, database testing tools are way behind the curve. Managers are getting used to full-featured testing reports, code coverage and code metrics and rightfully see the database as backward in this area.

And if you’re going to have a bit bucket, well, you might as well have a free bit bucket. And then you might as well stick ORM on top of it.

New Year’s Resolutions

Happy New Year.

My main personal technical resolution is to find more time to get a grip on more of the topics that Jonathan Lewis writes about. His level of knowledge and insight continues to astound. His book Cost-Based Oracle Fundamentals is excellent. I’d love to get to a position where I don’t have to read, re-read and then re-read again his articles and chapters and then re-read and refer to other reference points to get a handle on his excellent works.

It’s all bloody good stuff for getting one thinking … thinking about how little one understands about one’s own so-called specialist subject.

I’m sure I’m not alone in feeling humbled, to the point of embarassment even, by my lack of knowledge in comparison to the real experts out there like himself, Tom Kyte, et al.

The depth and breadth of their knowledge is phenomenal.

The long and winding road III

Of course, what you could do in this situation is write a set of encapsulating functions that return the conditions of the WHERE clause. But then you’re probably sacrificing some degree of maintainability and visibility/simplicity of code.

I was reminded of the quote from Pulp Fiction, well really from the Bible of course (Ezekial 25:17), which one could try to adapt in a pathetic attempt at geeky humour:

“Blessed is he, who in the name of relational databases and set operations, shepherds the weak through the valley of ORM mapping tools for he is truly his brother’s keeper, and the finder of lost database developers.

And I will strike down upon thee with great wait events and furious hit ratios, those who poison and destory my database efficiency.

And you will know my name is Oracle, when I lay my buffer cache upon thee.”

… oh dear….

Other people’s problems are great

Tom Kyte and others talk excellently as usual about participation in the Oracle commuity.

About 8 years ago, I used to use the various community channels quite heavily – both seeking advice and offering. For whatever reason, this used to be the less open ones such as Experts Exchange.

Anyway, without realising it, I must have become a lot more introspective. I only tended to visit the community when I myself was stuck. I know I must have been really busy at times, but no excuse, who isn’t. And after a while, I just forgot.

Where I currently work, they have a private chat system with all sorts of channels of interest, including a Oracle channel. Huzzah. I had forgotten how cool it is to try to answer other people’s questions.

The great thing about other people’s problems is that they are often so much more interesting than your own work and what you are meant to be working on. And sometimes it’s an opportunity to have a bit of focus on that feature you’ve been meaning to look at, or a refresher on something you’d unwittingly forgotten, or just helping a fellow teammate out of a fix.

And you can always laugh at some people’s problems / attitude. Wowzers Penny! That’s an extreme. Sometimes you can lead a horse to water but you can’t make it drink, but that is just another level.

Follow

Get every new post delivered to your Inbox.

Join 68 other followers