Keeping It All In Memory

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQLServerCentral.com » Editorials » Keeping It All In Memory

21 posts, Page 2 of 3

««1 2 3 »»

Keeping It All In Memory

Rate Topic

Display Mode

Topic Options

Author

Message

GSquared

Posted Monday, February 01, 2010 9:18 AM

SSCoach

Group: General Forum Members
Last Login: 2 days ago @ 1:45 PM
Points: 15,442, Visits: 9,572

From what I understand, most tempdb operations already take place purely in RAM, till they get too big to fit there. Temp tables and table variables both work that way. Maybe transaction log actions on temp tables involve disk I/O, I'm not sure. If they do, they could be moved into a RAM version of the tran log just for tempdb and that might improve performance by some tiny amount on really busy systems.

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

Post #857285

Jon Saltzman

Posted Monday, February 01, 2010 10:34 AM

Valued Member

Group: General Forum Members
Last Login: Friday, November 02, 2012 3:20 PM
Points: 51, Visits: 136

Actually, for a little while (in SQL 2000) we used to pin tables in memory using the "dbcc pintable" command. It didn't load the entire table into memory by default, but once pages were read from disk, they would be cached in memory until you "unpinned" the table or restarted the server. This was pretty close to an in-memory database... for those tables which you pinned. However, this feature was deprecated in SQL 2005, mostly because the SQL engine does this kind of in-memory caching of pages automatically, as long as there is enough RAM (or so I have read). I was kind of sad to see it go though, because it did give a little bit of extra control and possibility for using all that RAM that servers have these days.

Jon

Post #857391

Jeff Moden

Posted Monday, February 01, 2010 8:55 PM

SSC-Dedicated

Group: General Forum Members
Last Login: Today @ 7:18 AM
Points: 33,112, Visits: 27,038

It's ironic... as someone once said, "The more things change, the more they stay the same". Holy shades of "RAM DISK", Batman! Tongue

--Jeff Moden

"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/

For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Post #857697

GSquared

Posted Tuesday, February 02, 2010 6:05 AM

SSCoach

Group: General Forum Members
Last Login: 2 days ago @ 1:45 PM
Points: 15,442, Visits: 9,572

Jeff Moden (2/1/2010)

It's ironic... as someone once said, "The more things change, the more they stay the same". Holy shades of "RAM DISK", Batman! Tongue

I thought the same thing.

Sure would add a lot of challenges to DR, but might get a little boost in performance. I think I'd aim more for SSD instead of in-RAM databases, if I really needed just that tiny edge in speed. Less risky, lots faster than HDD.

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

Post #857879

Girish Bhat

Posted Wednesday, February 03, 2010 11:05 PM

SSC Veteran

Group: General Forum Members
Last Login: Friday, February 22, 2013 1:02 AM
Points: 206, Visits: 425

In-memory databases are suitable for a specific set of applications which need extreme performance without worrying too much about recoverability. In such apps recoverability is handled outside the database by the app itself using custom logic. One example would be a stock market order matching engine where tens of thousands of transactions are done per second. Recovering from system failure is handled by the application by rebuilding the IMDB from various sources. Such systems fall under a narrow niche category. A majority of apps need persistence and cannot use IMDBs (at least not till reliable recoverability is built-in).

I would like to see an IMDB version of SQL Server Compact Edition - the zero install embedded database. If that happens, a massive number of desktop applications, Windows service applications and small to medium websites can use it as a local cache in innumerable performance enhancement situations in the form of a multi-key hashtable which can be queried with regular SQL.

Post #859338

Jeff Moden

Posted Thursday, February 04, 2010 5:10 AM

SSC-Dedicated

Group: General Forum Members
Last Login: Today @ 7:18 AM
Points: 33,112, Visits: 27,038

Instrumented data collection apps, especially in the medical and device control fields, would greatly benefit from IMDB instances as well.

--Jeff Moden

Post #859527

David Lean

Posted Thursday, February 04, 2010 4:18 PM

SSC Rookie

Group: General Forum Members
Last Login: Wednesday, June 12, 2013 9:57 AM
Points: 27, Visits: 123

For the niche solutions you mention above check out the StreamInsight component that ships with SQL Server 2008 R2 (currently in beta (as of Feb 2010)).
I think you'll find it meets your needs beautifully. It ships & is licensed as part of SQL Server, but can run as a separate component hence can be configured for way less overhead than running entire SQL stack if you only need the high speed matching bits.

Post #860036

Jon Saltzman

Posted Thursday, February 04, 2010 6:48 PM

Valued Member

Group: General Forum Members
Last Login: Friday, November 02, 2012 3:20 PM
Points: 51, Visits: 136

StreamInsight and SQL 2008 R2 should be RTM in May 2010. See this article for more info about the release.

I'm excited about the great new features! It's a good time to be a SQL Server user!

Jon

Post #860095

Steve Jones - SSC Editor

Posted Friday, February 05, 2010 7:32 AM

SSC-Dedicated

Group: Administrators
Last Login: Today @ 5:09 AM
Points: 31,526, Visits: 13,864

Streaminsight looks good, unfortunately in SS2K8 R2 it's only in data center edition Sad

So most of us won't get to use it. We can play in Developer, but to actually deploy it would take some serious $$$$

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #860455

Jon Saltzman

Posted Friday, February 05, 2010 1:16 PM

Valued Member

Group: General Forum Members
Last Login: Friday, November 02, 2012 3:20 PM
Points: 51, Visits: 136

Steve, isn't that always how it goes? ;)

Post #860803

« Prev Topic | Next Topic »

21 posts, Page 2 of 3

««1 2 3 »»

Permissions