Viewing 15 posts - 1 through 15 (of 18 total)
So is it common practice to have a handful of traces running all the time to track performance/maint issues? It seems like a growth trace would be something you would...
August 29, 2007 at 12:10 pm
0 for both.
The coworker contacted me, and has shut down his app. Hopefully that's the problem.
August 28, 2007 at 2:41 pm
Tempdb is already set to simple recovery, so everything in the templog is just waiting to commit...from what I've read. I'm no expert.
August 28, 2007 at 2:14 pm
Ok I found some log growth already. I also picked up on the user, and it's a coworker in Texas who is pushing data into my DB. I killed his...
August 28, 2007 at 2:04 pm
Good advice. I'm going to set up a trace on file growth, and see what's going on. I stopped and started the service yesterday at approximately 4pm, so that would...
August 28, 2007 at 12:49 pm
Ok I just stopped and started the service again. Templog is now 2g. Still seems pretty large.
August 28, 2007 at 12:43 pm
I tried running a DBCC SHRINKFILE (templog, TRUNCATEONLY) and got these results:
DBID FILEID CURRENTSIZE MINSIZE USEDPAGES MINPAGES
2 2 546152 64 546152 64
So then I ran DBCC SHRINKFILE (templog, 2000) to try and...
August 28, 2007 at 12:34 pm
More information: I just read that truncating the log file won't actually free up physical size only logical size. So I need to go in and run a shrinkfile on...
August 28, 2007 at 12:16 pm
Yeah I often use temp tables when gathering data to update into a very large data table. The database I'm updating is only about 1g (but it's log file is...
August 28, 2007 at 11:56 am
Ok I've got a trace running for starttime greater than 2007-08-28 00:00:00 less than 2007-08-28 09:00:00. That should show me what's going on with tembdb, correct?
August 28, 2007 at 11:29 am
In regards to shrinking the db, I did restart the service by stop then start. The growth happend after this point. What I've read is even if you do this...
August 28, 2007 at 11:07 am
Ok I'm not out of the woods yet. My templog is 40 gigs...
I did verify the lock problem I was having is indeed not a problem by running sp_who, which...
August 28, 2007 at 10:55 am
I found additional info regarding locks on spt_values and a lockinfo[spid] for this while searching the web (Go Google!):
The person's question was what are these two locks:
------------
Object:master.dbo.spt_values
Lock Type:TAB
Mode:Sch-S
Status:GRANT
Owner:Xact
Index:
Object:tempdb.dbo.##lockinfo51
Lock Type:TAB
Mode:X
Status:GRANT
Owner:Xact
Index:##lockinfo51
------------
(Ah doesn't...
August 28, 2007 at 9:57 am
Ok the problem is it is holding a lock on part of the master db. I queried the tembdb lock info (select * from ##lockinfo53), and here are the results:
August 28, 2007 at 9:04 am
Yes the client connection is myself, but usually the status is 'awaiting command' not 'select into'.
August 28, 2007 at 8:23 am
Viewing 15 posts - 1 through 15 (of 18 total)