The Flash Insider: To POC or Not To POC?

Proof of Concept?

Guest Post




Oh… the Pain







What are you really testing for?


What’s a DBA to do?



Taking Charge


Statistic                                     Total     per Second     per Trans
physical read IO requests                55,301,220        7,682.5       1,180.1
physical read bytes              1.936982535373E+13 2.69087766E+09 4.1334639E+08
physical read partial requests               26,445            3.7           0.6
physical read requests optimized         49,680,085        6,901.6       1,060.2
physical read total IO requests          55,479,809        7,707.3       1,183.9
physical read total multi block          19,552,557        2,716.3         417.3
physical reads cache                     14,137,864        1,964.1         301.7
physical reads cache prefetch            11,716,783        1,627.7         250.0
physical reads direct                 1,168,102,453      162,274.1      24,927.0
physical reads direct (lob)                      22            0.0           0.0
physical reads direct temporary         307,926,728       42,777.5       6,571.1
physical reads prefetch warmup                    0            0.0           0.0
physical write IO requests               37,072,831        5,150.2         791.1
physical write bytes              4,873,114,484,736  676,978,477.6 1.0399083E+08
physical write requests optimize         31,566,182        4,385.2         673.6
physical write total IO requests         37,460,357        5,204.0         799.4
physical write total bytes        4,908,503,636,480  681,894,777.9 1.0474603E+08
physical write total bytes optim  3,540,697,530,368  491,877,634.2  75,557,447.1
physical write total multi block          5,511,767          765.7         117.6
redo writes                                 341,363           47.4           7.3


# single-block, 100% random reads

# multi-block, 100% sequential reads

# single-block, 100% random writes

# multi-block, 100% sequential writes



PoC Avoided?  Maybe.


2 Responses to The Flash Insider: To POC or Not To POC?

  1. Lynn Sattler says:

    I am a USA based Oracle DBA. Very much enjoyed reading all of your blog postings that I came upon in the last couple of days! One question I did not find an answer to was the net effects of this technology wearing out. We have both oltp and a data warehouse. I believe the data warehouse does a lot of writes compared to oltp. How long will the ssd drives last in these arrays?
    Also, I am not sure I have this right, but are you saying that for the vendors to survive, they have to go to ssd drives in their arrays instead of having “ground-up designs”? You were sure high on the “ground-up designs” before Violin got into financial trouble.

    • flashdba says:

      Hi Lynn

      First of all, I wrote an article about flash wear which you can find here:

      But that article is about wear at the cell level. What you are asking about is wear at the array level, which is much more interesting. I should blog about it sometime soon.

      In most cases the answer is that you don’t need to worry, because typically your AFA vendor would replace any worn SSD if your system is under a support contract. I can’t speak for the others but that’s certainly what my employers past and present have done. They are able to do this because the vast majority of customers would never get anywhere near the point where their drives wear out of the lifetime of the arrays (typically 5 to 7 years).

      So why is that? Well, for example, a Samsung PM863 data centre-class SSD has a Drive Writes Per Day (DWPD) rating of around 1.3, which means you can write an average of 1.3x the drive capacity every day for the warranty period. Considering that these drives go up to 3.84TB in size that’s a lot of writes. And of course your storage array will have many drives in it (for example 24 per shelf in a Kaminario K2 array). Of more importance is the fact that what your database writes isn’t what will be written to the flash. Your All Flash Array will likely use a combination of technologies such as thin provisioning, compression, deduplication and zero detection to ensure that what is written down to persistent media is a fraction of the data being sent from the server. So all in all, wear isn’t really an issue unless you have a very unusual requirement. I’ve worked on some of the largest and most write-intensive databases in the world and I can only think of two incidences where this was even a factor.

      Ahh yes, the question of ground up versus commodity component. As you point out, I’ve been on both sides of this equation. I could write at length about Violin’s woes but this isn’t the place. However, I do think history has now shown that hardware-centric designs aren’t agile enough to adapt to market forces (look at Violin, Skyera and DSSD). We got badly burned by that at Violin. I’ve come to the conclusion that software-based approaches are the answer, especially when they are built on the back of commodity components built by companies like Samsung, who has the economies of scale to produce millions of SSD units per year. But hey, I’ve been wrong before so don’t take my word for it. I’m only hoping to share my experiences as one possible set of views.

Leave a Reply


You are commenting using your account. Log Out /  Change )

Google photo


Twitter picture


Facebook photo


Connecting to %s
