<a href="http://g.adspeed.net/ad.php?do=clk&zid=15220&wd=468&ht=60&pair=as" target="_blank"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15220&wd=468&ht=60&pair=as" alt="i" width="468" height="60"/></a>
Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
<a href="http://g.adspeed.net/ad.php?do=clk&zid=15491&wd=120&ht=300&pair=as" target="_top"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15491&wd=120&ht=300&pair=as" alt="i" width="120" height="300"/></a>
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQL Server 2008
»
SQL Server 2008 Administration
»
PAGELATCH_UP suggestions
PAGELATCH_UP suggestions
Rate Topic
Display Mode
Topic Options
Author
Message
Lexa
Lexa
Posted Wednesday, August 15, 2012 5:31 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Today @ 1:36 PM
Points: 152,
Visits: 465
We're experiencing high waits for this type on a user database during high volume inserts on a partitioned table. What are the general recommendations for preventing this type of wait?
Post #1345214
Grant Fritchey
Grant Fritchey
Posted Wednesday, August 15, 2012 7:10 AM
SSChampion
Group: General Forum Members
Last Login: Today @ 3:57 PM
Points: 13,371,
Visits: 25,152
You're experiencing I/O waits during I/O operations... The only way to speed that up is to get faster/more disks.
----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of:
SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans
Product Evangelist for
Red Gate Software
Post #1345253
Lexa
Lexa
Posted Wednesday, August 15, 2012 7:28 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Today @ 1:36 PM
Points: 152,
Visits: 465
Grant Fritchey (8/15/2012)
You're experiencing I/O waits during I/O operations... The only way to speed that up is to get faster/more disks.
That's what I thought. Thanks.
Post #1345264
opc.three
opc.three
Posted Wednesday, August 15, 2012 9:31 AM
SSCertifiable
Group: General Forum Members
Last Login: Today @ 1:28 PM
Points: 6,698,
Visits: 11,726
Grant Fritchey (8/15/2012)
You're experiencing I/O waits during I/O operations... The only way to speed that up is to get faster/more disks.
Are you sure you're not thinking of PAGE
IO
LATCH_UP? I think PAGELATCH_UP is a memory latch (buffer, i.e. not I/O) caused when doing an update. At a guess there is potential for allocation contention issues when you see this wait. Can you provide the DDL for the partitioned table? How many rows are you inserting?
__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
Believe you can and you're halfway there.
--Theodore Roosevelt
Everything Should Be Made as Simple as Possible, But Not Simpler
--Albert Einstein
The significant problems we face cannot be solved at the same level of thinking we were at when we created them.
--Albert Einstein
1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples.
--Giordy
Post #1345350
Lexa
Lexa
Posted Wednesday, August 15, 2012 9:53 AM
SSC-Enthusiastic
Group: General Forum Members
Last Login: Today @ 1:36 PM
Points: 152,
Visits: 465
opc.three (8/15/2012)
Grant Fritchey (8/15/2012)
You're experiencing I/O waits during I/O operations... The only way to speed that up is to get faster/more disks.
Are you sure you're not thinking of PAGE
IO
LATCH_UP? I think PAGELATCH_UP is a memory latch (buffer, i.e. not I/O) caused when doing an update. At a guess there is potential for allocation contention issues when you see this wait. Can you provide the DDL for the partitioned table? How many rows are you inserting?
It wasn't many rows about 40K but I think the main issue was the fact that our dynamic re-indexing process started to rebuild an index in the middle of the insert process. That specific partition itself had only about 30K rows initially + the 40K that got added.
Partition is by store, and a store can have any number of items from 0 to 22 mil. It's not the best partitioning strategy so we're working on a new one to replace the current one.
Wouldn't PAGELATCH_UP be also tied to IO perhaps indirectly? This link gives some good info but we can't implement this type of partitioning. http://sqlcat.com/sqlcat/b/technicalnotes/archive/2009/09/22/resolving-pagelatch-contention-on-highly-concurrent-insert-workloads-part-1.aspx
Post #1345364
GilaMonster
GilaMonster
Posted Wednesday, August 15, 2012 9:59 AM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 5:49 PM
Points: 37,671,
Visits: 29,925
Typically no, Pagelatch is a wait for a latch on a page in memory. Need some idea what pages the latch waits are on to say much more.
Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild
: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter
We stand on the bridge and no one may pass
Post #1345371
opc.three
opc.three
Posted Wednesday, August 15, 2012 10:09 AM
SSCertifiable
Group: General Forum Members
Last Login: Today @ 1:28 PM
Points: 6,698,
Visits: 11,726
Lexa (8/15/2012)
opc.three (8/15/2012)
Grant Fritchey (8/15/2012)
You're experiencing I/O waits during I/O operations... The only way to speed that up is to get faster/more disks.
Are you sure you're not thinking of PAGE
IO
LATCH_UP? I think PAGELATCH_UP is a memory latch (buffer, i.e. not I/O) caused when doing an update. At a guess there is potential for allocation contention issues when you see this wait. Can you provide the DDL for the partitioned table? How many rows are you inserting?
It wasn't many rows about 40K but I think the main issue was the fact that our dynamic re-indexing process started to rebuild an index in the middle of the insert process. That specific partition itself had only about 30K rows initially + the 40K that got added.
If you have multiple processes competing to open latches on the same pages, especially one as intense as an index rebuild/org routine, that could be the problem. When doing a mass insert you'll likely be doing lots of random allocations in your nonclustered indexes, and depending on your DDL lots of sequential or random allocations in your clustered index. Can you please provide the DDL for the table (incl indexes and partition scheme and function)? Does it have an identity or sequential GUID column?
Partition is by store, and a store can have any number of items from 0 to 22 mil. It's not the best partitioning strategy so we're working on a new one to replace the current one.
Wouldn't PAGELATCH_UP be also tied to IO perhaps indirectly?
Not necessarily. The buffer pool does just that, it buffers us from the I/O subsystem so when you're waiting on a buffer latch it has to do with memory, not disk. I think your system would be in a world of hurt if you were seeing buffer latch waits as a result of upstream IO latch waits.
This link gives some good info but we can't implement this type of partitioning. http://sqlcat.com/sqlcat/b/technicalnotes/archive/2009/09/22/resolving-pagelatch-contention-on-highly-concurrent-insert-workloads-part-1.aspx
Use the query in the article to find out what exactly your query is waiting on.
__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
Believe you can and you're halfway there.
--Theodore Roosevelt
Everything Should Be Made as Simple as Possible, But Not Simpler
--Albert Einstein
The significant problems we face cannot be solved at the same level of thinking we were at when we created them.
--Albert Einstein
1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples.
--Giordy
Post #1345372
Grant Fritchey
Grant Fritchey
Posted Wednesday, August 15, 2012 10:42 AM
SSChampion
Group: General Forum Members
Last Login: Today @ 3:57 PM
Points: 13,371,
Visits: 25,152
Oops. Missed the missing 'IO' & responded too quickly.
----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of:
SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans
Product Evangelist for
Red Gate Software
Post #1345393
« Prev Topic
|
Next Topic »
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.
