January 28, 2012 at 4:48 am
Hi,
In my production database have 1:1 data & log file..as per this script no result is dispaly, so no need to add more data file in tempdb database. Is it correct? could suggestion pls.
Select session_id,
wait_type,
wait_duration_ms,
blocking_session_id,
resource_description,
ResourceType = Case
When Cast(Right(resource_description, Len(resource_description)
- Charindex(':', resource_description, 3)) As Int) - 1 % 8088 = 0 Then 'Is PFS Page'
When Cast(Right(resource_description, Len(resource_description)
- Charindex(':', resource_description, 3)) As Int) - 2 % 511232 = 0 Then 'Is GAM Page'
When Cast(Right(resource_description, Len(resource_description)
- Charindex(':', resource_description, 3)) As Int) - 3 % 511232 = 0 Then 'Is SGAM Page'
Else 'Is Not PFS, GAM, or SGAM page'
End
From sys.dm_os_waiting_tasks
Where wait_type Like 'PAGE%LATCH_%'
And resource_description Like '2:%'
Thanks
ananda
January 28, 2012 at 4:58 am
Opinions vary on this, but my own view is that it is only worth creating extra equally-sized tempdb files if you are experiencing allocation contention. Some people prefer to add the extra files to avoid the problem before it materializes, but there can be unwanted side-effects, including slowing down sorts and hashing operations that use tempdb. Overall, my vote would be for you to leave things as they are, but to continue to monitor for allocation contention, just in case.
January 28, 2012 at 5:08 am
Thanks SQL Kiwi for your reply..
SQL Kiwi (1/28/2012)
Overall, my vote would be for you to leave things as they are, but to continue to monitor for allocation contention, just in case.
ok, I should continue to monitor for allocation contention in tempdb.
In cause of if very big sorting operation or sql jobs are running long time for particular time period that time tempdb will be allocate some contention during this activity completion after that what will happend? contention should be their in database or automatically will relase once completed these type of Jobs.
Thanks
ananda
January 28, 2012 at 5:25 am
SQL Kiwi (1/28/2012)
Opinions vary on this, but my own view is that it is only worth creating extra equally-sized tempdb files if you are experiencing allocation contention.
My preference too, although if I have a case where I know that no one will bother to monitor, I may be proactive and create a 2nd file even without seeing contention.
That said, that script is wrong. It's looking at page numbers that are not PFS, GAM, SGAM pages (other than the 1st set in the file).
PFS - first PFS page is page 1, after that where PageNo % 8088 = 0 (no -1 required)
GAM - first GAM is at page 2, after that where PageID % 511232 = 0 (no -2 required)
SGAM - first SGAM is at page 3, after that where (PageID-1)%511232=0 (not -3 )
Easy to prove, by the formula in the script posted, page 511234 (511234 - 2 = 511232. 511232 % 511232 = 0) should be a GAM page, ie page type 8. Go and look at that in a DB big enough, and I get this:
Page @0x0000000080BA0000
m_pageId = (0:0) m_headerVersion = 0 m_type = 0
m_typeFlagBits = 0x0 m_level = 0 m_flagBits = 0x0
m_objId (AllocUnitId.idObj) = 0 m_indexId (AllocUnitId.idInd) = 0 Metadata: AllocUnitId = 0
Metadata: PartitionId = 0 Metadata: IndexId = -1 Metadata: ObjectId = 0
m_prevPage = (0:0) m_nextPage = (0:0) pminlen = 0
m_slotCnt = 0 m_freeCnt = 0 m_freeData = 0
m_reservedCnt = 0 m_lsn = (0:0:0) m_xactReserved = 0
m_xdesId = (0:0) m_ghostRecCnt = 0 m_tornBits = 0
That's just an unallocated page. Check my formula though (PageID % 511232), it says that 511232 is a GAM.
Sure enough...
Page @0x0000000080B9C000
m_pageId = (1:511232) m_headerVersion = 1 m_type = 8
m_typeFlagBits = 0x0 m_level = 0 m_flagBits = 0x200
m_objId (AllocUnitId.idObj) = 99 m_indexId (AllocUnitId.idInd) = 0 Metadata: AllocUnitId = 6488064
Metadata: PartitionId = 0 Metadata: IndexId = 0 Metadata: ObjectId = 99
m_prevPage = (0:0) m_nextPage = (0:0) pminlen = 90
m_slotCnt = 2 m_freeCnt = 6 m_freeData = 8182
m_reservedCnt = 0 m_lsn = (6664:3406110:62) m_xactReserved = 0
m_xdesId = (0:0) m_ghostRecCnt = 0 m_tornBits = 533630942
Trivial to show similarly that 511233 is an SGAM.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 28, 2012 at 5:32 am
ananda.murugesan (1/28/2012)
In cause of if very big sorting operation or sql jobs are running long time for particular time period that time tempdb will be allocate some contention during this activity
Probably not. Growth maybe, but not contention. Contention comes from lots and lots and lots of small operations, not a single large one.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 28, 2012 at 5:36 am
Hi thanks Gail for your clarification, Could you please post the correct script?
thanks
ananda
January 28, 2012 at 5:44 am
I gave you the correct formulas, you should be able to correct the script given those.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply