Against my better judgement, we are using fixed allocations of tempdb on some of our servers. This is to deal with specific limitations of our applicaitons and hardware configuration that I'm not allowed to discuss in much detail.
The problem that I have is that the present plan is to configure the data file at around 18 Gb and the log file at around 2 Gb. This seems just plain wrong to me, but I haven't been able to find a formal recommendation that gives any relative sizing. I would expect to have about twice as much log as data space, especially for tempdb.
Does anyone know of a formal citation (preferably from Microsoft) that discusses this?
We have installed SQL Server 2008 R2 SP1 instance and it's having Share Point 2010 databases.
We have 2 dedicated drives for Tempdb on SAN with 50 GB space. Both tempdb data & log files are created with default size. I would like to presize them.
What are the best values to start with?
U ->Tempdbdata having tempdb.mdf file V->Tempdblog having templog.ldf file
We are planning hardware purchases (more is better). One of our databases is 131 gigs in size and has 45 gigs of 'space available'. I'm not a very experienced SQL Server person, but this seems like quite a bit of 'space available'
1) Is there a way to regulate the amount of 'space available'? 2) are there any rules of thumb for how 'space available' there should be?
I have an SQL server that has probably 20 or so people connected at a time. In addition to these people, there are five people that run Crystal reports with some voluminous data, usually coming from views. About every week and a half, one of the report writers get a message that the master device is full and must be expanded, because tempdb is full. When I expand temdb, it fixes the problem. My question is, the tempdb is now 800 Megs. The sum total of memory allocated to all of the other(besides master)devices is 650. Should this be a flag that something is wrong? It just keeps growing and growing. Tempdb is not on it's own device-it is still on master. Any advice would be greatly appreciated! Jane Davis
I have read that MS suggests you tempdb be atleast 25% of your largest database. Is there any way to monitor your tempdb to determine if it is filling up or being 100% utilized and needs to be expanded?
I have a server with 2.5GB of RAM. I am allocation 1GB to SQL Server and am attempting to put 500MB tempdb in RAM. It would appear as though I am hitting some sort of max threshhold that I am unaware of as I can set tempdb in RAM up to 320MB. Anything beyond that and I get the following errors on start up and SQL Server will not start.
98/12/02 08:25:47.03 spid1 Clearing temp db
98/12/02 08:25:47.03 kernel udactivate(IN_RAM): Operating system error 8(Not enough storage is available to process this command.) encountered
98/12/02 08:25:47.03 spid1 Device activation error. The physical filename 'IN_RAM' may be incorrect
98/12/02 08:25:47.03 spid1 crdb_tempdb: Unable to move tempdb into RAM; RAM device doesn't exist, cannot be created, or doesn't have enough space for tempdb
I am certain that I am not hitting a Physical RAM limit and the memory checks out and is visible to NT. Please Advise. Thanks
Is there any way by which I can determine whether the tempdb size for the SQL Server is enough or not? (I ean are there any symptoms like excessive paging etc. that can identify this bottleneck?).
We had a runaway query which built the size of tempdb to 24000mb. Then someone changed the unrestricted file growth property to restricted growth while the size was 24000mb. Now I can not reduce the initial size. I have set the property back to unrestricted file growth. I have shrunk the tempdb and available space is almost 24000mb. I have stopped sqlserver. I even deleted the existing tempdb.mdf & tempdb.ldf files. But when SQL server is restarted, the initial size is set to 24000mb. It will not let me reduce the size. Is there anything short of manipulating the system tables to reduce the size back to 500mb?
We currently have a hard-drive size of 3.89MB and 3.3MB is being used by tempdb. I have tried shrinking the database truncateonly but this is not working. The problem is that the tempdb file is as large as my C: drive size. In addition can this be moved to another directory. For example can I move the tempdb.mdf and ldf from C: to E:. Any help would be greatly appreciated.
On my server C drive is of 34GB. Right now tempdb size is 22GB which is causing C drive to be full. How I can I reduce it? I dont want to move tempdb to any other drive, and I am only looking a way to reduce its size.
I have the classic "tempdb-out-of-space" problem. Unfortunately, my server fails to reboot properly as tempdb is located on the C: drive which is now completely full. While I understand the changes required to prevent this from happening again, I want to know if it will even reboot if I delete tempdb.mdf and tempdb.ldf. I've read conflicting information on MSDN about default tempdb file size: - files are built to the default size (I will be fine) - files are built to the same size as before (problem) Which is true for SQL 2005?
I have a tempdb that was created at 1Gig. I don't know why but I want to shrink it below the original creation size. Is there a way to shrink this file or create a new file and delete the old?
I have tried shinkfile and shrink database with no luck.
We have a problem with the size of the tempdb.mdf file. The tempdb had grown to 25Gb and consumed all the available disk space. SQL server was restarted and the tempdb was reset back to the default size. The following day the tempdb suddenly increased in size from 200mb to 25GB within a very short space of time. There were a couple of event log entries from sqlservger regarding the lack of disk. Since then the server is running without any problems but the level of free space is virtually zero on the drive with tempdb.mdf file.
What would cause the tempdb to grow suddenly and to this size?
I have got SQLv6.5 SP5a with SMS1.2 SP4 on seperate Alpha boxes. I have automated the backups so they are scheduled for after hours. SMS gets backed up first and TEMPDB shortly afterwards. However, since a back log in SMS MIFS has happened, the TEMPDB backup displays of 100,000pages backed up. When you back it up on its own, it only shows 170+ pages.
The SMS DB is 600MB in size, the Log is 210MB, Open objects is 5000, and TEMPDB is set 210MB on its own device.
I am running a Query in my Production Server. It is hardly taking 15 Mins. The same Query is taking more than 3 Hours in my test server. I can see the only difference between these two servers is Tempdb Size. Will tempdb size matters the performance of a Query. Can anyone reply me?
My prod server (only default instance) is configured TempDB 1024 MB data and Log 200MB. when I run 'sqlperf logspace' it shows most of time around 45% 'log space used'. There nothing going on the instance when I ran 'whoisactive' and select * from sys.sysprocesses where dbid = 2!!!
So my questions are is this normal to see log space around 45%, how to find what what CAUSED the tempdb log space to grow 45%? Is there something to do about it?
I receive Error: 3967, Severity: 17, State: 1. Insufficient space in tempdb to hold row versions. We have 8 data files for temp db of 10210 GB size and given 10240 GB as max size.
As MS suggest to calculate the temp db file size and growth rate we need to monitor the perform counters Free Space in Tempdb (KB) and Version Store Size (KB) in the Transactions object.
basic formula: [Size of Version Store] = 2 * [Version store data generated per minute] * [Longest running time (minutes) of your transaction
My report disk utilizations says tempdb is full ? I thonk I need a shrink for the file .
Still I am confused in calculating the size , My perform counter gives me data as such
Free Space in tempdb (KB)              279938496 Version Generation rate (KB/s)          53681040 Version Cleanup rate (KB/s)      53422320 Version Store Size (KB)     258720 Version Store unit count      22 Version Store unit creation                     774 Version Store unit truncation        752
Hi, I have a problem importing data from SQL Server 2000 'text' columns to SQL Server 2005 nvarchar(max) columns. I get the following error when encountering a transfer of any column that matches the above. The error is copied below,
Any help on this greatly appreciated...
ERROR : errorCode=-1071636471 description=An OLE DB error has occurred. Error code: 0x80004005.An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Unicode data is odd byte size for column 3. Should be even byte size.". helpFile=dtsmsg.rll helpContext=0 idofInterfaceWithError={8BDFE893-E9D8-4D23-9739-DA807BCDC2AC} (Microsoft.SqlServer.DtsTransferProvider)
Just wanted to know what is a general rule of thumb when determining log file space against a database's data file.We allow our data file for our database to grow 10%, unlimited. We do not allow our log file to autogrow due to a specific and poorly written process (which we are in a three month process of remove) that can balloon the log file size.Should it be 10% of the Data file, i.e. if the Date file size is 800MB the log file should be 8MB?I realize there are a myraid of factors that go against file size but a general starting point would be nice.ThanksJeff--Message posted via http://www.sqlmonster.com
I am trying to resize a database initial log file from 500M to 2M. I€™m using€?
ALTER DATABASE <DBNAME> MODIFY FILE ( NAME = <DBLOGFILENAME, SIZE = 2 ) "
And I'm getting "MODIFY FILE failed. Specified size is less than current size." I tried going into the database properties and setting the log file to 2M, but it doesn€™t keep the changes.
Presently, we have allocated 600MB to tempdb and when I run the sp_spaceused command for tempdb I notice that the unallocated space is a negative number. I have not received any errors in the error log with regards to expanding the segment because segment is full. Is this just a bug in SQL 6.5 or something else?
I have tempdb data device size default 2 MB, which has completely filled up. I am trying to expand data device to it. I created new device tempdb_data_ext (250 MB) and tried to expand tempdb data device. But everytime I do it, it ends up adding space to tempdb log device. How can I expand tempdb data device?
tempdb data file has 8Mb and log file has 1Mb - but I´m getting message that log is full.
Once tempdb is shrinked and expanded by the system (we even don´t see it at database folder!!), what can be done, (except reinstall from scrach and restore DBs) to make tempdb not vulnerable to very frequent expanding/shrinking (I guess this can be one of the root of the problem) ?
It is possible that Data Collection can cause massive increasing MB/sec to tempdb ? I cannot find connection with tempdb and I set cash file, but on same disk.
Or it can be something different? Last two weeks what I checked was Read/Write MB/s to tempdb increasing progressively.
One time it was about 20MB/sec
After it was reseting and again 1MB/sec..
What I checked , External company which install SQL Server made one file for tempdb, next week or during breaktime(it will be possible), I would like make 8files next weekend work.
Now I saw that TempDB mdf was still increased, but using was just 8-10%
I'm having an argument with our infrastructure architect who has just gone and bought lots of SSD drives to use for our tempdb data and log files, sounds great doesn't it? There is a catch though, his plan is to add the disks to the two available slots in each blade in a RAID0+1 configuration, effectively giving you one usable drive, and adding both data and log files on to one disk.
I then pointed out that SQL Server best practice is to host tempdb data and log files on two separate drive to reduce contention. The architect then basically said that because this isn't spinning disk the issue of drive, r/w contention isn't an issue I don't agree with this and wanted to get some opinions from the community, I'm still advising that two separate disks should be used but someone just went and spent £80k ($150k) on SSDs and doesn't want to back down...
I have some stored procedures that create table data types for temporary tables. From everything I've read about these, they shouldn't occupy space in tempdb. However we've been having problems with our tempdb log growing quite large, so I've done some profiling on the database and found that the temporary tables are being created in tempdb, and I don't understand why.
The Stored Procedure looks like: -- WORKING TABLES DECLARE @t_InsertParams TABLE (ParamKey1 VARCHAR(50) NOT NULL, ParamValue VARCHAR(1024), ParamOrder INT)
and GetParamsOffload is a user defined function that returns a table: CREATE FUNCTION GetParamsOffload(@p_ParamsList AS VARCHAR(8000), @p_TargetTable AS VARCHAR(50)) RETURNS @t_Params TABLE (ParamKey1 VARCHAR(50) NOT NULL, ParamValue VARCHAR(1024), ParamOrder INT) AS <snip> INSERT @t_Params SELECT @_ParamKey ,@_ParamValue ,ISNULL(@_ParamOrder, 0) <snip> RETURN
During the profiling of the application, I see numerous records of EventType "Object:Created" for the tempdb DatabaseId and the ObjectName is both @t_InsertParams and @t_Params. I am also monitoring the "Objecteleted" EventType, but I never see these objects deleted.
My first question is why this code uses the tempdb in the first place. I've read that you can't use the table data type in a few instances (can't insert the values of a SP execute into the table data type; cannot do SELECT INTO or INSERT INTO statements). Is there an issue with inserting data into the table data type from a function? Is there something that can be changed in the way the table data type is defined/used that will not use tempdb?
If I am stuck with the above using tempdb, is there something that should be explicitly called to Delete the specified objects from tempdb? Do I need to Drop those tables in my SP?
This SP is called via a CSV file parser - gets called A LOT over and over parsing files and I see these objects getting created in tempdb. I need to figure out how this process can manage the space in tempdb better.
