April 24, 2014 at 10:08 am
I've a transaction table that has seqID column. Every time we process a new transaction through a scheudled job, I take the max(seqID) + 1 and put it in the table.
When a user process transaction manually through the web, it also takes the max(seqid) + 1 and put it in the table.
Often times, when both process runs simultaneously, they read the same seqID and increment that by 1 and ending up duplicates in the table.
Anyway to avoid this concurrency issue? Appreciate your help.
April 24, 2014 at 10:11 am
Make the column an identity? Or use a sequence?
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
April 24, 2014 at 10:14 am
Making column identity is an option that should have thought beforehand. If we go that route now, it can mess up reports and other files that we already sent to the client. Any other options you can think of?
April 24, 2014 at 11:01 am
SQL_Surfer (4/24/2014)
If we go that route now, it can mess up reports and other files that we already sent to the client.
Why?
Any other options you can think of?
...
Or use a sequence?
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
April 24, 2014 at 3:29 pm
How about using the TABLOCK hint?
๐
April 24, 2014 at 3:33 pm
Eirikur Eiriksson (4/24/2014)
How about using the TABLOCK hint?๐
That seems to be dealing with the symptom rather than the cause. ๐
Hints should be used as a last resort. The concurrency issue is caused by poor design, we shouldn't need to resort to query hints to deal with it. Just my 2ยข.
_______________________________________________________________
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 http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 โ Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
April 24, 2014 at 3:43 pm
Sean Lange (4/24/2014)
Eirikur Eiriksson (4/24/2014)
How about using the TABLOCK hint?๐
That seems to be dealing with the symptom rather than the cause. ๐
Hints should be used as a last resort. The concurrency issue is caused by poor design, we shouldn't need to resort to query hints to deal with it. Just my 2ยข.
I agree that one should not try to outsmart the query engine and the optimizer but I believe that not all hints are equal in this sense. If the problem is as described, more than one process reading the value at the same time, then force them to queue. An improved design would probably be a better solution though:cool:
April 24, 2014 at 4:34 pm
SQL_Surfer (4/24/2014)
Making column identity is an option that should have thought beforehand. If we go that route now, it can mess up reports and other files that we already sent to the client. Any other options you can think of?
Adding an identity column need not change existing values, you can create a new table with the column as an identity, then set identity_insert on for the new table, insert the existing rows, then RESEED the identity column, set identity_insert off, rename the old table, rename the new table to the old name.
Once you have done that, you will want to change your code to OUTPUT the identity value whenever you insert a new row, so that you can pass back to the calling code the new value.
MM
select geometry::STGeomFromWKB(0x0106000000020000000103000000010000000B0000001000000000000840000000000000003DD8CCCCCCCCCC0840000000000000003DD8CCCCCCCCCC08408014AE47E17AFC3F040000000000104000CDCCCCCCCCEC3F9C999999999913408014AE47E17AFC3F9C99999999991340000000000000003D0000000000001440000000000000003D000000000000144000000000000000400400000000001040000000000000F03F100000000000084000000000000000401000000000000840000000000000003D0103000000010000000B000000000000000000143D000000000000003D009E99999999B93F000000000000003D009E99999999B93F8014AE47E17AFC3F400000000000F03F00CDCCCCCCCCEC3FA06666666666FE3F8014AE47E17AFC3FA06666666666FE3F000000000000003D1800000000000040000000000000003D18000000000000400000000000000040400000000000F03F000000000000F03F000000000000143D0000000000000040000000000000143D000000000000003D, 0);
April 25, 2014 at 1:32 am
Eirikur Eiriksson (4/24/2014)
How about using the TABLOCK hint?๐
May or may not be sufficient, depending on the code (which we haven't seen), and not necessarily the best option.
There are many ways to do a manual sequence wrong, but preventing any other access to what may be an important table isn't necessarily going to magically fix the problem and it may cause other problems.
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
April 26, 2014 at 3:12 pm
Since you are using sql server 2012 have you considered using the new feature for creating a sequence object? If in addition the application requires knowing whether this is the nth record, this of itself sounds more like something calculated/computed as needed and not something to store.
I am aware that maybe in legacy databases there had been the practice of artificially restricting a sequence by using a varchar, like in our database using suffix fields to arbitrarily limit items to 999 for a given module and type code to represent different entities ...for ex. MasterName( agency, incident_nr, suffix1, suffix2, module, type, <data fields...> ). Then you'd need to use a stored procedure in order to check if the generated sequence value already exists and remains in range and if not to reset the sequence and continue generating until a gap exists. Again, the select would need to compute the seqno to the application having ordered the items by a record's created datetime (in high volume scenarios or when you have bulk insert job, without a surrogate primary key using identity, a datetime may not be sufficient to order deterministically).
Now if your seqid is an int (number) then life's good, use the sequence object and let the application use a select or programing code to compute the item's order. If a varchar and you have no independent surrogate primary key to order by and you do not have an independent field retaining the timestamp for when the record was created, you need to make decisions for whats the best compromise for your situation.
Hope this helps.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply