Post reply

Solid State Replacements - Database Weekly (August, 18, 2008)

  • August 16, 2008 at 2:55 am

    #195913

    Comments posted to this topic are about the item Solid State Replacements - Database Weekly (August, 18, 2008)

  • August 17, 2008 at 12:36 am

    #859150

    Have you tested the RamSan 500 with SQL Server 2005?

    Anyone?

    Looks promising but I wonder what the next bottleneck would be.

  • August 17, 2008 at 8:20 pm

    #859242

    Is that the Texas Memory Systems SSD? I've heard mixed things from it.

    If it works, I'm sure the bottleneck will move around and our tuning advice would change quite a bit.

  • August 18, 2008 at 3:18 am

    #859325

    Good!

    I'm looking forward to a different tuning paradigm that does not have to take Disk IO into account (as much).

    http://www.superssd.com/products/ramsan-500/

    I'm fairly convinced on these right now before actually using one.

    They have addressed all of my concerns thus far.

    But, I would like to know more about what the next bottleneck would be so I can design servers around that too.

    Will it be machine related or software? Can SQL Server even handle the parrallel processing required to get the most out of IO this fast?

    My intent is to put the entire data warehouse database on one of these.

    What would happen then?

    I know 64bit would really help.

    I know faster and more processors is always great.

    But what about getting that data into memory.

    How fast would that be?

    How many processors could it use on a single column update on 300,000,000 rows?

    These are just some of my thoughts and questions.

    I do not expect complete answers to these question until I actually get one and do it.

    But any direction is very much appreciated.

  • August 19, 2008 at 12:58 pm

    #860223

    I don't know much about SSD comparisons to HDs, but i would guess the SEEK times would be 1 of their strong suits. Even so, a smaller look up table may well be faster than a larger 1 even on an SSD.

    I mention this because one ot the main storage sizing recommendations that I make for clients is NOT to go over board on size mainly because of the hit that usually causes for SEEK times. We don't have many clients that are going to have database files larger than 20 GB. I recommend they opt for 36 GB each for data and logs, and even smaller for the tempDB. I always recommend they add budget for 15k RPM too, and that doesn't usually add much.

    Tom Garth
    Vertical Solutions[/url]

    "There are three kinds of men. The one that learns by reading. The few who learn by observation. The rest of them have to pee on the electric fence for themselves." -- Will Rogers

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply