SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


store proc based logical issue


store proc based logical issue

Author
Message
ekant_alone
ekant_alone
Ten Centuries
Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)

Group: General Forum Members
Points: 1097 Visits: 524
I have a job which runs a store procedure. The proc is something like
BEGIN

STEP 1) Archive records into Table A..... (around 15K records)
from TABLE B

STEP 2) Delete some records from the table B

STEP 3) Insert new records into Table B

STEP 4) Update table B

END



This proc takes about 20 mins to run.
Jobs kicks at 7:15 and as soon as job starts i can not access records from TABLE B deleted in STEP 2. I know step 1 takes about 10 mins . My assumption was that SP has sequential processing and not parallel processing. Is it possible that it can run statement 2 along with step 1. I am confused about how it gets executed. I cant see execution plan and getting permission is like 10 day process.
Grant Fritchey
Grant Fritchey
SSC Guru
SSC Guru (186K reputation)SSC Guru (186K reputation)SSC Guru (186K reputation)SSC Guru (186K reputation)SSC Guru (186K reputation)SSC Guru (186K reputation)SSC Guru (186K reputation)SSC Guru (186K reputation)

Group: General Forum Members
Points: 186293 Visits: 33315
Since that's all going to be part of a single transaction, you're very likely going to see all sorts of blocking, not just at the row level, but possibly at the page level, preventing you from accessing data in Table B while the transaction completes. If you need to access data while it's being run, you might want to look at setting up a snapshot isolation level on the server.

----------------------------------------------------
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 Query Performance Tuning and SQL Server Execution Plans
Product Evangelist for Red Gate Software
Sean Lange
Sean Lange
SSC Guru
SSC Guru (126K reputation)SSC Guru (126K reputation)SSC Guru (126K reputation)SSC Guru (126K reputation)SSC Guru (126K reputation)SSC Guru (126K reputation)SSC Guru (126K reputation)SSC Guru (126K reputation)

Group: General Forum Members
Points: 126874 Visits: 18406
In addition to Grant's suggestion maybe you should look at Step1. You say there are only about 15k rows but the archive portion takes 10 minutes. That is awfully slow for not many rows. Are the other 3 steps fast? I would think that archiving 15k rows should take 10-15 seconds tops.

_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Modens splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
TheSQLGuru
TheSQLGuru
SSC Guru
SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)

Group: General Forum Members
Points: 65711 Visits: 8838
ekant_alone (9/13/2013)
I have a job which runs a store procedure. The proc is something like
BEGIN

STEP 1) Archive records into Table A..... (around 15K records)
from TABLE B

STEP 2) Delete some records from the table B

STEP 3) Insert new records into Table B

STEP 4) Update table B

END


This proc takes about 20 mins to run.
Jobs kicks at 7:15 and as soon as job starts i can not access records from TABLE B deleted in STEP 2. I know step 1 takes about 10 mins . My assumption was that SP has sequential processing and not parallel processing. Is it possible that it can run statement 2 along with step 1. I am confused about how it gets executed. I cant see execution plan and getting permission is like 10 day process.


1) Try sp_whoisactive as soon as you kick off the sproc to look for locking blocking. GREAT free resource found on sqlblog.com. You may not have permission to run this either.

2) The statements in a proc do not EVER execute at the same time. They are serial as you expect.

3) Can you see the ESTIMATED execution plan? That could be good enough to identify that you are doing a nasty table scan or something silly to delete just a few rows or for other parts of the sproc.

4) The WITH (ROWLOCK) hint could be helpful. See Books Online for info.

5) I question the order of steps 3 and 4. Assuming your INSERT already has all the correct information for every row, doing the INSERT before the UPDATE simply puts more rows in the table to subsequently be UPDATED. Not efficient coding practices (although rather common at clients I go to!).

Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
GilaMonster
GilaMonster
SSC Guru
SSC Guru (468K reputation)SSC Guru (468K reputation)SSC Guru (468K reputation)SSC Guru (468K reputation)SSC Guru (468K reputation)SSC Guru (468K reputation)SSC Guru (468K reputation)SSC Guru (468K reputation)

Group: General Forum Members
Points: 468354 Visits: 47357
TheSQLGuru (9/13/2013)
4) The WITH (ROWLOCK) hint could be helpful. See Books Online for info.


Or could make it worse. 15000 rows locked at the row level is above the threshold for triggering an escalation to table-level locks.

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

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


GilaMonster
GilaMonster
SSC Guru
SSC Guru (468K reputation)SSC Guru (468K reputation)SSC Guru (468K reputation)SSC Guru (468K reputation)SSC Guru (468K reputation)SSC Guru (468K reputation)SSC Guru (468K reputation)SSC Guru (468K reputation)

Group: General Forum Members
Points: 468354 Visits: 47357
ekant_alone (9/13/2013)
My assumption was that SP has sequential processing and not parallel processing. Is it possible that it can run statement 2 along with step 1.


Your assumption is correct, statements in a stored procedure execute in sequence. Step 2 won't start until step 1 completes. Step 1 will lock rows in TableB though. Should just be shared locks, but they will be locked.

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

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


TheSQLGuru
TheSQLGuru
SSC Guru
SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)SSC Guru (65K reputation)

Group: General Forum Members
Points: 65711 Visits: 8838
GilaMonster (9/13/2013)
TheSQLGuru (9/13/2013)
4) The WITH (ROWLOCK) hint could be helpful. See Books Online for info.


Or could make it worse. 15000 rows locked at the row level is above the threshold for triggering an escalation to table-level locks.


True. But if it is a busy table there will almost certainly be other row/page locks that will prevent the table lock escalation, thus allowing the row locking to continue (up to memory limitations IIRC) in 1250-lock increments, where it will try for the table lock again iteratively. Other than memory concerns this will probably be a better concurrency scenario in many cases than simply attempting to get table lock at the start (and possibly being blocked for long periods) or actually GETTING the table lock at the start and blocking other activity for duration of the transaction.

YMMV, and testing is important as it always is when you use hints!

Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
Ben Teraberry
Ben Teraberry
SSCertifiable
SSCertifiable (5.3K reputation)SSCertifiable (5.3K reputation)SSCertifiable (5.3K reputation)SSCertifiable (5.3K reputation)SSCertifiable (5.3K reputation)SSCertifiable (5.3K reputation)SSCertifiable (5.3K reputation)SSCertifiable (5.3K reputation)

Group: General Forum Members
Points: 5331 Visits: 1199
OP,

I am just curious ... how do you know step 1 takes 10 minutes? Is there some way that you actually know that or is it an assumption based on something else?

If you can read from table B, but just not the records expected to be deleted, that would indicate that your time estimates are off and that the step in question has already been completed. As has been stated, the 2nd statement will not execute until the 1st has completed. If you can't read from table B in general because it is locked that is a separate issue.

Personally I like using SSIS for ETL tasks like you're describing rather than using single procs that perform many separate tasks. For each separate action I use a distinct step and if I have any issues I can easily discover exactly how long each step is taking and where the errors are. Some of this advantage could be had merely by separating the statements into separate procs and then calling the procs in order via the job. Of course, there are times when the code needs to be kept together and your case could very well be one of those times.

└> bt


Forum Etiquette: How to post data/code on a forum to get the best help
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum







































































































































































SQLServerCentral


Search