-1

Why is solid state devices not a good option to store data for a very dynamic (frequent updates) oracle database?
Although for read intensive databases ssd does give a huge performance improvement.

Jack
  • 7
  • 3

2 Answers2

6

SSD drives have memory cells with finite lifespans; the more you write/erase/write to the cells the sooner they go "bad" so frequently accessed drives with something like a heavily used database will drive down the life of the drive. I don't know if there are any "enterprise ready" SSD drives on the market that offer high reliability either. That would lead me to believe that the advice you've heard is because SSD drives may be more prone to failure in a relatively short time compared to fast (and field-tested) hardware solutions out there already, given the high price point of SSD drives per gigabyte.

If you're going to use that kind of solution you should be ready to deal with having it well-RAIDed with spares ready and a well tested backup and restore procedure.

Bart Silverstrim
  • 31,172
  • 9
  • 67
  • 87
  • SSDs do not operate well in RAID spans, due to lack of support by RAID controllers for SSDs and all that comes along with that. – brandeded Aug 24 '11 at 14:37
  • "Enterprise" flash tends to have some very good lifetime estimates these days (and, of course, price points to go along with that). – Shane Madden Aug 24 '11 at 15:29
  • @shaneMadden It's been awhile since I checked on SSD's that were for the enterprise, so I'm not surprised if they started coming out. Still don't know if I'd recommend them for most setups, though. – Bart Silverstrim Aug 24 '11 at 17:25
1

When it comes to database read operations it's best they won't require any (disk) storage access at all. If read query speed is your concern make sure all data is held in-memory.

update

My advice just throwing as much memory as possible at your database addresses only the simple assumption that using SSD will give you better read operation performance.

Filburt
  • 149
  • 1
  • 11
  • With frequent updates, as he specified, memory won't help because updates need to be committed to disk. It is also a difficult strategy for anyone that doesn't have small datasets. You need memory for the Indexs, joins operations etc in addition to just the size of the DB. Also, because of NuMA, I believe memory gets duplicated in banks per processor to avoid always having to shove data over the interconnect. – Kyle Brandt Aug 24 '11 at 13:23
  • I admit my answer simply deals with the OP part "Fast SSD will result in fast read operations". The whole question is not up to the complexity of the matter and I didn't expect much praise (=upvote) on such simplistic advice. @Chopper has a point. – Filburt Aug 24 '11 at 13:59
  • My point is pretty simple. SSD do give a really fast Random Read Performance over conventional Hard Disks. Although the Sequential Reads performance is not that huge. But when it comes to writing to disks, enterprise storage arrays (EMC DMX4, HDS USPv etc) writes all data to cache and the write is acknowledged to the host. Destaging takes place later. In such a scenario, how is SSD going to perform? Moreover, for updates in oracle the ssd have to go through the erase-write cycle, conventional hdd dont. How does this impact performance? – Jack Aug 25 '11 at 05:34
  • @jack Now we're talking. Move/copy your comment to your post and you're likely to receive better answers than "Don't bother spending your money on SSD; rather buy RAM.". Also add some info on your database-to-be: Approx. size, is failover clustering req'd. In general I'd still stay with my opinion that you tweak a lot before worrying about disk IO - it's a performance bottleneck that SSD won't eliminate (just reduce at present state of technology). Other comments point out that you may have to deal with limitations like RAID capability which could be essential for your scenario. – Filburt Aug 25 '11 at 07:27