Comments on: Idle Thoughts – SSD, Redo Logs, and Sector Size http://hoopercharles.wordpress.com/2011/12/18/idle-thoughts-ssd-redo-logs-and-sector-size/ Miscellaneous Random Oracle Topics: Stop, Think, ... Understand Thu, 13 Jun 2013 22:46:43 +0000 hourly 1 http://wordpress.com/ By: Charles Hooper http://hoopercharles.wordpress.com/2011/12/18/idle-thoughts-ssd-redo-logs-and-sector-size/#comment-4199 Mon, 19 Dec 2011 12:50:07 +0000 http://hoopercharles.wordpress.com/?p=5751#comment-4199 Nuno,

Thanks for sharing your comment.

You are probably right that someone will take the results out of context and then formulate a general rule. Time to super-size your redo log block size. Let’s see, the table states that I need a 16 KB block size for this Intel SSD… I just type these commands and …

I want to make certain that people understand that I am not recommending to use or not use a 4096 byte block size for redo on SSD. It was but an idle thought while I awaited a LOG FILE SYNC wait to complete. ;-)

]]> By: Charles Hooper http://hoopercharles.wordpress.com/2011/12/18/idle-thoughts-ssd-redo-logs-and-sector-size/#comment-4198 Mon, 19 Dec 2011 12:39:35 +0000 http://hoopercharles.wordpress.com/?p=5751#comment-4198 Guy,

Thanks for sharing your performance results regarding 512 byte and 4096 byte blocksizes for the redo logs – the results are interesting. I wonder if the native sector size of the SSD drives in an Exadata system are 4 KB or if they are actually larger than that size (for example, the apparent 16 KB sector size of some Intel SSD drives).

In your article, you state that, “elapsed time reduced by 70% [when using the 4096 byte redo log blocksize]“. A marketing person could probably spin your results a couple of different ways:

309.68 / 1009.67 = 30.67% of the time required for 512 byte

1009.67 / 309.68 = 326.04% faster for 4096 byte

(1009.67 – 309.68) / 309.68 = 2.2604 = 226.04% time decrease compared to ending point

(1009.67 – 309.68) / 1009.67 = 0.6933 = 69.33% time decrease compared to starting point

Regardless of the above number spinning, based on your test results, SSD in the system is still slower than the spinning rust (serial attached SCSI hard drives). Now if only Oracle Database supported a 16 KB blocksize for the redo logs…

Thanks again for sharing the results.

]]> By: Noons http://hoopercharles.wordpress.com/2011/12/18/idle-thoughts-ssd-redo-logs-and-sector-size/#comment-4196 Mon, 19 Dec 2011 04:17:38 +0000 http://hoopercharles.wordpress.com/?p=5751#comment-4196 Oh boy! I can see the next ROT (rule of thumb) already: “Use 4KB for file system size for redo logs on SSD!”. Regardless of release level, setup, storage architecture, etc.
Agree entirely: I see heaps of reasons to pause. And T-H-I-N-K!
As usual: ECC applies – Experiment! Check! Compare!

Before we’re all saddled with another 10 years of ROT setting in…

I’m curious on how long it’ll be before someone will claim SSD on SAN Fast Provisioning needs a 4K file system block size…
Mark my words: it’ll happen!

]]> By: Guy Harrison http://hoopercharles.wordpress.com/2011/12/18/idle-thoughts-ssd-redo-logs-and-sector-size/#comment-4195 Mon, 19 Dec 2011 02:15:04 +0000 http://hoopercharles.wordpress.com/?p=5751#comment-4195 I tried placing redo logs on SSD in an Exadata system using default (512) and 4K blocksizes. The results are at http://guyharrison.squarespace.com/blog/2011/12/6/using-ssd-for-redo-on-exadata-pt-2.html. It looked to me like setting the redo log block size incorrectly causes definite dramatic degradation, but setting it correctly (or at least in this case to 4K) doesn’t make SSD faster than SAS for sequential writes.

]]>