Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
ferrethouse
Constraint Violating Yak Guru
352 Posts |
 Posted - 2011-10-21 : 00:26:39
|
| Anyone tried this? I have 64 gigs of RAM and am thinking of creating a 4 gig RAM disk and having the first of 10 tempdb files pointing to it. The vast majority of tempdb IO will be less than 4 gigs so most of the time it will use memory instead of disk...Trick 1. For files that use page allocation techniques to fill, such as tempDB, you can trick the page fills to both favor SSD and expand onto slower/cheaper disk in cases where locking/blocking would cause the files to become large very fast. This is usually due to temporary conditions, but we still need a ‘fuse’ so that our server won’t crash before we can address the issue.Example:SSD in RAID / tempdb file #1 = 20GB with auto-growth OFFRAID 10 disks / tempdb file #2 = 2GB with auto-growth ONResult> greater than 80% of activity, including the pointers/maps will be maintained on the solid state disk. During an emergency, the file is allowed to grow very large on the slower disk. The fact that we have one of the files on slower disk doesn’t affect total available performance because the I/O is asynchronous.http://infrastructureesoterica.wordpress.com/2011/07/17/cost-effective-ssd-tuning-on-a-shoestring/edit: fixed formatting |
|
|
Lumbago
Norsk Yak Master
3271 Posts |
Posted - 2011-10-21 : 04:40:53
|
| Even though the idea is very intriguing I'm not sure it will be possible. SQL Server need this ram disk and the tempdb-files to be available when the service is starting...is ramdisk capable of this? I googled a bit and found this similar forum post on the subject -> http://social.msdn.microsoft.com/Forums/en-US/sqldatabaseengine/thread/dc46796c-fcd5-430e-951b-e706e0885c70/Has something happened in the past year that changes this conclusion?- LumbagoMy blog-> http://thefirstsql.com/2011/07/08/how-to-find-gaps-in-identity-columns-at-the-speed-of-light/ |
 |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2011-10-21 : 07:35:21
|
| There was a session at last week's PASS Summit about tempdb and the subject of tempdb in RAM was covered briefly. Basically it's not worth it as SQL Server always works on data buffers from RAM, so in effect you would be using twice as much RAM to store the same data. If you attended the PASS Summit you can download Bob Ward's slides and demos, and if not you can probably contact him at Microsoft and he'll email them.I don't think "files on slower disk doesn’t affect total available performance because the I/O is asynchronous" is valid however, since tempdb is logged and checkpointed, the slower disk will impact those operations vs. SSD-only. I'm skeptical of that article since it provides no measurements of performance or case studies of the described scenario. It also doesn't mention the proportional-fill algorithm used by SQL Server and how the different file sizes would impact it. There's also no mention of the log file, which will also grow, and not in a proportional manner.I think the best route would be to size tempdb appropriately on the SSD, and leave some free space for auto-growth. Whatever "fuse" he's talking about would probably be an alert on tempdb file growth, and if disk space really becomes critical you could have the alert fire a job that adds a new tempdb file on another disk. |
|
|
|
Nurgle
Starting Member
2 Posts |
Posted - 2011-12-13 : 19:43:52
|
| I have a failover system I am building for a remote location, I am using this opportunity to test some other possible improvements. I have a box filled with 2 Xeon e5620's, 144gb of ram 2 600gb SSDs and 4 2tb 7200rpm SATA in RAID 10. Originally I had intended to have the tempdb on SSD but later I noticed that our instance of SQL Server 2008 r2 is having an inordinate amount of writes to disk, in the order of 2-3TB per day. The problem I am faced with is write endurance for MLC SSDs. So I have set up a 20gb ramdisk to put tempdb on. RAM doesn't have the write endurance problems that an SSD has so one problem solved. The remaining problem is the capacity. Best practice says 1 tempdb per processor. Since I have 8 real cores plus 8 hyperthreaded ones I have 16 logical procs, I would like to have enough room to grow but I don't want to use too much ram either.I would possibly use autoshrink. Unfortunately everyone says don't use autoshrink. Furthermore nobody substantiates any reason for not using it. Sometimes I read some cursory statement about fragmentation, but that certainly is not an issue for a ramdisk since I benched 4k random reads and writes at 1000MB/sec.So my question is what would be an acceptable use of the ramdisk for tempdb. How many files are actually necessary, should I really have 16 files? or would I be ok with 4? Is autoshrink ok for ramdisks? Is staggered/tiered sizing for tempdb acceptable/useful (8gb, 4gb, 2gb, 2gb for 4 files rather than 4, 4, 4, 4). What about autogrowth, what would be good growth settings? If I was to put some tempdb files on the raid10 set what preference would that have compared to the ramdisk files?Thanks |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2011-12-14 : 08:04:20
|
quote:
Originally posted by Nurgle
I have a failover system I am building for a remote location, I am using this opportunity to test some other possible improvements. I have a box filled with 2 Xeon e5620's, 144gb of ram 2 600gb SSDs and 4 2tb 7200rpm SATA in RAID 10. Originally I had intended to have the tempdb on SSD but later I noticed that our instance of SQL Server 2008 r2 is having an inordinate amount of writes to disk, in the order of 2-3TB per day. The problem I am faced with is write endurance for MLC SSDs.
If you're using FusionIO devices, they have published guidance on their wear-leveling techniques that mitigate this concern. I can't find it but you can contact your FusionIO rep and they can provide it for you. If you're using another product, you can probably get similar information from them. With a good wear-leveling algorithm, most SSDs will exceed 5 years of use before reaching the write limit of the cells, and a high-end product will also provide excess capacity to compensate. This timeframe is comparable to hard disk lifetime, or scheduled replacement due to cost, capacity, or other improvements.quote:
So I have set up a 20gb ramdisk to put tempdb on. RAM doesn't have the write endurance problems that an SSD has so one problem solved. The remaining problem is the capacity. Best practice says 1 tempdb per processor.
I believe you mean 1 tempdb data file per processor. Technically it should be 1 data file per core, and again, Bob Ward's PASS presentation has guidance on that. If you have more than 8 cores you'll want to read.quote:
Since I have 8 real cores plus 8 hyperthreaded ones I have 16 logical procs, I would like to have enough room to grow but I don't want to use too much ram either.
You may want to do some research on hyperthreading as it does not always help SQL Server performance. Several people support it (Glenn Berry, Joe Chang) but many still experience performance hits.quote:
I would possibly use autoshrink.
Never use autoshrink. Google Paul Randal and autoshrink. Don't use it.quote:
Unfortunately everyone says don't use autoshrink.
Because they've read Paul Randal's advice on it, and/or experienced the problems firsthand.quote:
Furthermore nobody substantiates any reason for not using it.
Again, Google Paul Randal on this. I'll keep repeating this until you read it. Consider this: the guy who WROTE the code for it says you SHOULDN'T use it.quote:
Sometimes I read some cursory statement about fragmentation, but that certainly is not an issue for a ramdisk since I benched 4k random reads and writes at 1000MB/sec.
It DOES cause fragmentation, and it's still an issue. Your scenario is incomplete, because it assumes you'll always have tempdb in RAM, and you'll always have enough RAM to hold tempdb. What if you run out, or tempdb needs to grow beyond available RAM? If tempdb cannot grow when it needs to, SQL Server tends to shut down, or throw other errors that can impact your server.quote:
So my question is what would be an acceptable use of the ramdisk for tempdb. How many files are actually necessary, should I really have 16 files? or would I be ok with 4? Is autoshrink ok for ramdisks? Is staggered/tiered sizing for tempdb acceptable/useful (8gb, 4gb, 2gb, 2gb for 4 files rather than 4, 4, 4, 4). What about autogrowth, what would be good growth settings? If I was to put some tempdb files on the raid10 set what preference would that have compared to the ramdisk files?
I don't recommend it, for the reasons I listed in my earlier reply (duplicated data in particular). You also don't want to have different file sizes, because of the way SQL Server allocates file space. Again, please read Bob Ward's and Paul Randal's advice on these topics, Paul also has advice on file sizes. Some links you can check:http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-%281230%29-tempdb-should-always-have-one-data-file-per-processor-core.aspxhttp://www.sqlpass.org/summit/2011/Speakers/CallForSpeakers/SessionDetail.aspx?sid=1869 |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2011-12-14 : 09:19:40
|
| "Furthermore nobody substantiates any reason for not using it [Autoshrink on TEMPDB)"Starting point is that SHRINK should not be necessary on TEMPDB because next time SQL Service restarts then TEMPDB will be recreated at the configured startup-size.Sometimes this doesn't happen, no idea why, but I do see related quesitons on the forum from time-to-time so it does seem to be an issue.So that riases the issue of "how do you shrink TEMPDB if you need to". Everything I have ever seen on the subject says that the Service must be in single user / emergency mode to do this (which involves a Stop/Start, so this is not a work around for wanting to avoid that!). The reason given is that concurrent processes using TEMPDB will cause data corruption in their underlying databases if SHRINK occurs on TEMPDB at an inopportune time.Hence the advice not to do itI have no current knowledge of TEMPDB in RAMDISK. It use to be popular back in the old days (was that SQL 7, or 6.5 ... or even 6.0 maybe?). Since then I have been lead to believe that giving all the RAM to SQL for its caches and buffers gives a better overall benefit. But I certainly don't have the experience of the sort of systems you are contemplating to offer any learned input, but my immediate thought on an "inordinate amount of writes to disk" would be to try to tune the system to avoid that; no idea how feasible that is in your case though."How many files are actually necessary"We have created the requisite number of TEMPDB files related to CPU cores on our systems ... but I've read very mixed information about whether this is actually beneficial.But if you are not familiar with it I recommend you have a look at reducing / managing VLFs (and avoiding exact 4GB boundaries)See: http://www.sqlskills.com/BLOGS/KIMBERLY/post/Transaction-Log-VLFs-too-many-or-too-few.aspx |
|
|
|
Nurgle
Starting Member
2 Posts |
Posted - 2011-12-14 : 14:07:02
|
| Thanks for all the great responses and links. I am not using FusionIO devices so that solution is inapplicable to my scenario. I did stumble across this MS article http://support.microsoft.com/kb/917047 it referenced ram disk use on SQL 2000 and 2005. Pointing out the drawbacks, but did confirm it's merits. I really appreciated the links about the number of tempdb files and it does seem like many people use the multiple tempdb files across different media to assist with iocontention, so a ram disk seems like it is a good choice for possible iocontention bottlenecks.Luckily I am in a nice position to to some testing. I am going to be doing some performance testing with this system using some different ram disk configurations as well as conventional disk configurations. I will post the results of my tests here. |
|
|
|
glixyl
Starting Member
2 Posts |
Posted - 2012-04-16 : 18:58:12
|
| I own the blog infrastructureesoterica.wordpress.com and posted the blog reference responsible for this topic> http://infrastructureesoterica.wordpress.com/2011/07/17/cost-effective-ssd-tuning-on-a-shoestring/. Don't use RAMDISK for tempDB because it is more volatile and SQL server can't handle tempDB being offline. Use high-quality SSD for tempDB (low latency writes are very important). It is OK to spread tempDB over more than 1 disk or disk group as the I/O is asynchronous.If you are looking for my original data, I am looking for it- but here is the jist of the problem and solution. A few years ago, clustered SSD was very expensive. I could only afford 8 x 72GB SSD disks for our HP EVA 6400, but the high water mark for SSD was very large. I had a lot of big customers with heavy concurrent usage patterns and I needed to come up with an optimal way to use that disk. What we did was make a 40GB LUN for each database server and put the large tempDB segments on it with auto-grow to off. We then created little files on a large VRAID 1 disk group that were set to auto-growth = on to allow for the server to hit is previous high-water mark. To my suprise (sort of) the high-water mark for SSD went from 150GB to 50GB and the little files only grew when there was a problem. Now.. before all the haters out there say 'what about fragmentation?' What fragmentation? The files sat at using 2-4GB of their allocated 50GB. SSD made all the difference for tempDB and the trick worked.. since then we are on more SSD as it is cheaper. |
|
|
|
glixyl
Starting Member
2 Posts |
Posted - 2012-04-20 : 09:46:57
|
| The data related to the topic. sorry for formatting>-- dbcc showfilestats-- Tier0: tempdev_t0_f1, tempdev_t0_f2, 30MB each no autogrowth-- Tier1: tempdev_t1_f1, tempdev_t1_f2, 10MB each autogrowth 10%-- 3rd column: Total extend-- 4th column: Used extend-- Initial tempdb file statsID Group Total Used Name FileName--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------1 1 480 19 tempdev_t0_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdb.mdf3 1 480 2 tempdev_t0_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t0_f2.ndf4 1 160 1 tempdev_t1_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f1.ndf5 1 160 1 tempdev_t1_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f2.ndf-- select * into #tempdb_test from ****-- (2530 row(s) affected) ID Group Total Used Name FileName--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------1 1 480 43 tempdev_t0_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdb.mdf3 1 480 25 tempdev_t0_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t0_f2.ndf4 1 160 9 tempdev_t1_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f1.ndf5 1 160 9 tempdev_t1_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f2.ndf-- insert rows to #tempdb_test-- insert into #tempdb_test select top 2000 * from #tempdb_test-- 2000 rows each time-- Tempdb file usage is proportional filled based on size of the data files. In our case, 75% of tempdb usage on tier0, 25% of tempdb usage on tier1 (For detail see table below ID Group Total Used Name FileName--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------1 1 480 62 tempdev_t0_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdb.mdf3 1 480 44 tempdev_t0_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t0_f2.ndf4 1 160 15 tempdev_t1_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f1.ndf5 1 160 16 tempdev_t1_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f2.ndfID Group Total Used Name FileName--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------1 1 480 81 tempdev_t0_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdb.mdf3 1 480 62 tempdev_t0_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t0_f2.ndf4 1 160 21 tempdev_t1_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f1.ndf5 1 160 22 tempdev_t1_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f2.ndfID Group Total Used Name FileName--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------1 1 480 100 tempdev_t0_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdb.mdf3 1 480 80 tempdev_t0_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t0_f2.ndf4 1 160 27 tempdev_t1_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f1.ndf5 1 160 28 tempdev_t1_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f2.ndf-- insert rows to #tempdb_test-- insert into #tempdb_test select top 2000 * from #tempdb_test-- 6000 rows each timeID Group Total Used Name FileName--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------1 1 480 155 tempdev_t0_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdb.mdf3 1 480 137 tempdev_t0_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t0_f2.ndf4 1 160 45 tempdev_t1_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f1.ndf5 1 160 47 tempdev_t1_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f2.ndfID Group Total Used Name FileName--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------1 1 480 212 tempdev_t0_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdb.mdf3 1 480 191 tempdev_t0_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t0_f2.ndf4 1 160 63 tempdev_t1_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f1.ndf5 1 160 65 tempdev_t1_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f2.ndfID Group Total Used Name FileName--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------1 1 480 266 tempdev_t0_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdb.mdf3 1 480 248 tempdev_t0_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t0_f2.ndf4 1 160 81 tempdev_t1_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f1.ndf5 1 160 83 tempdev_t1_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f2.ndfID Group Total Used Name FileName--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------1 1 480 322 tempdev_t0_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdb.mdf3 1 480 302 tempdev_t0_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t0_f2.ndf4 1 160 100 tempdev_t1_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f1.ndf5 1 160 101 tempdev_t1_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f2.ndfID Group Total Used Name FileName--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------1 1 480 377 tempdev_t0_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdb.mdf3 1 480 358 tempdev_t0_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t0_f2.ndf4 1 160 117 tempdev_t1_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f1.ndf5 1 160 120 tempdev_t1_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f2.ndfID Group Total Used Name FileName--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------1 1 480 425 tempdev_t0_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdb.mdf3 1 480 413 tempdev_t0_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t0_f2.ndf4 1 160 141 tempdev_t1_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f1.ndf5 1 160 140 tempdev_t1_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f2.ndf-- Tier0 doesn’t have enough space for transaction, most of the tempdb usage shift to tier1ID Group Total Used Name FileName--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------1 1 480 424 tempdev_t0_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdb.mdf3 1 480 425 tempdev_t0_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t0_f2.ndf4 1 236 200 tempdev_t1_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f1.ndf5 1 236 217 tempdev_t1_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f2.ndf-- insert rows to #tempdb_test-- insert into #tempdb_test select top 2000 * from #tempdb_test-- back to 2000 rows each time-- Trancation is using tier0 data files again when transaction is small enough to fit into tier0’s free spaceID Group Total Used Name FileName--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------1 1 480 443 tempdev_t0_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdb.mdf3 1 480 444 tempdev_t0_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t0_f2.ndf4 1 236 206 tempdev_t1_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f1.ndf5 1 236 223 tempdev_t1_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f2.ndfID Group Total Used Name FileName--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------1 1 480 462 tempdev_t0_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdb.mdf3 1 480 461 tempdev_t0_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t0_f2.ndf4 1 236 212 tempdev_t1_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f1.ndf5 1 236 230 tempdev_t1_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f2.ndf-- Tier0 is not enough for transaction even for smaller transaction, all tempdb usage goes to tier1ID Group Total Used Name FileName--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------1 1 480 462 tempdev_t0_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdb.mdf3 1 480 462 tempdev_t0_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t0_f2.ndf4 1 260 236 tempdev_t1_f1 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f1.ndf5 1 260 254 tempdev_t1_f2 C:\Program Files\Microsoft SQL Server\MSSQL.3\MSSQL\DATA\tempdev_t1_f2.ndfData file block used for each transaction/filesTransaction/Row Inserted2530200020002000600060006000600060006000200020002000Block used for each tempdb data files Tier0 File1241919195557545548019190Tier0 File22319181857545756551319171Tier1 File186661818181724596624Tier1 File287661918181920776724 |
|
|
|
|
|
|
|
|
tempdb on RAMdisk?