Do you suffer from Storage Stockholm Syndrome?


The last year at DSSD (now a part of Dell EMC) has been an extremely interesting one for me, and I’ve learned a great deal, which is always good. Some of the lessons have been surprising, though…

One of them is what I will rather dramatically refer to as Storage Stockholm Syndrome. Stockholm Syndrome is a psychological concept which defines a traumatic bonding, or “strong emotional ties that develop between two persons where one person intermittently harasses, beats, threatens, abuses, or intimidates the other” and seems an appropriate analogy for the relationship that DBAs have historically courted with their storage tier.

I spend quite a bit of time talking to Oracle DBAs about the DSSD D5 storage platform, and what that means from not only a storage performance standpoint but also from an agility perspective and an architectural consequence perspective. We often get stuck at the first point: This is a really, really fast box 1. My blog isn’t a sales platform, so I won’t go into the details on how fast here. The real problem is this: Many of the DBAs react to the performance in a very strange way…mostly along the lines of:

“We don’t need that level of performance.”

I know where this is coming from: It’s from 50+ years of systematically poor performance from the storage tier. I’m not referring to any particular vendor or product here, I’m referring to the fact that there has always been several orders of magnitude difference in storage performance compared to DRAM performance. Always, always, always – right back to the genesis of computer science.

This difference in performance has led to an abusive relationship between the DBA and the storage platform and (this is where the Stockholm Syndrome comes in) the DBA doesn’t want to change it. They feel some kind of bond to their old abuser, or feel that they don’t deserve great performance from their storage. They feel like it would be an imposition to request what the believe to be obscenely expensive storage (it’s not – it’s comparable to any enterprise storage) from the budget holder.

Stockholm Syndrome.

Let’s break free from our captors! Let me help: All storage is going to be fast, not just the DSSD D5. You will not be able to buy lousy storage at all in the very near future because the D5 has broken the impasse with the access time gap. It is the first to do so, but most certainly not the last – everything will be this quick soon.

I do believe that: <marketing hat on> Dell EMC has a major headstart in this </marketing hat off> but the competitors are coming, believe me.

Let me help more: When storage performance stops being the main bottleneck (it’s now CPU and IPC), you can spend less time avoiding I/O and more time delivering business value through a more agile physical schema. But that’s a topic for another day…

1: Fast: High bandwidth and low latency

7 thoughts on “Do you suffer from Storage Stockholm Syndrome?”

  1. What everyone seems to be forgetting is that nowadays DAs
    (when was the last time anyone separated “database” into two words? Never? Then why use “db” in the acronym for database administration? About time it changed! But, I digress…)
    do not have any involvement with the schema and design of applications.
    Apps are mostly bought from 3rd parties, complete turn-key and with a water-tight contract that precludes and stops any DA from being able to make any change other than partition a table or add/drop indexes. In many cases even tablespace distribution cannot be manipulated!
    As such once the disk is fast enough, there is very little that a DA can do to further improve things…

    1. But are those physical schema attributes, such as partitioning schemes, secondary indexes, materialized views, etc. not an a classic dba function? They all serve to minimize I/O…

      1. Sure. But when the contract says “thou shalt not change anything”, what can indeed be done?
        Take Hyperion, JDEdwards and Peoplesoft HCM/EPM, for example: move a table or index to a different tablespace and you broke the contract because you will break its internal (unneeded!) app meta-data! Same for partitioning! Regardless of potential I/O reductions.

  2. James, you could credit DBAs with a bit more nowse thank that. The cost of your very fast storage was reported to be one or two orders of magnitude higher than our already very fast SSD storage platform. In some shops you will find the blocker is getting the storage guys to recommend your very expensive device – on which we can prove no significant benefit in the time available -to the management controlling the purse.

    On top of that, you must know developers are easily able to create code soaking up your faster performance and make it look “slow” again.

    It is easier for you to slam DBAs than look at price/performance. If money were not a factor, I would probably agree with you completely.

    1. JT – my intention here is not to slam DBAs, neither is it to make out that they are stupid. I have worked with DBAs for 25 years and feel that I have a very good grasp on the challenges. I have felt all this pain personally for those years. It is a genuine observation of reactions, that’s all.
      Regarding your price/performance comment – two orders of magnitude is completely wrong. Flash storage costs are all about capacity – so if you only need 1TB and compare that to a 100TB unit, then two orders of magnitude would make sense. But compare 25TB of SSDs with a 25TB DSSD box and you will find things to be much closer to parity. And rest assured, TCO is a primary consideration across the entire company – nobody is trying to rip anyone off here.

  3. Pingback: more info

Leave a Reply