|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 12:30 PM
Points: 32,893,
Visits: 26,770
|
|
peter-970097 (2/6/2010) Thanks Jeff for the informative reply. Independently of this blog, we very quickly canned any further thought on ISOLATION LEVEL et aliter All the tests we did with this were catastrophic!
We will work on your suggestion and blog the outcome. Rgds Peter
Thanks for the feedback, Peter. I look forward to your follow up especially since I went through it once myself. Let us know if we can be of any further assistance.
--Jeff Moden "RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
|
|
|
|
|
SSChampion
        
Group: General Forum Members
Last Login: Wednesday, May 08, 2013 10:33 AM
Points: 10,989,
Visits: 10,529
|
|
|
|
|
|
SSCrazy Eights
        
Group: General Forum Members
Last Login: Saturday, May 04, 2013 11:13 AM
Points: 9,855,
Visits: 9,374
|
|
Paul: So on RollBacks, will it leave permanent gaps, try to recycle the gaps, or does it guarantee no gaps, ever? (I am pretty sure that this last choice cannot be done, by anything, without some kind of frequent deadlocking or severe blocking).
-- RBarryYoung, (302)375-0451 blog: MovingSQL.com, Twitter: @RBarryYoung Proactive Performance Solutions, Inc. "Performance is our middle name."
|
|
|
|
|
SSChampion
        
Group: General Forum Members
Last Login: Wednesday, May 08, 2013 10:33 AM
Points: 10,989,
Visits: 10,529
|
|
RBarryYoung (2/28/2010)
Paul: So on RollBacks, will it leave permanent gaps, try to recycle the gaps, or does it guarantee no gaps, ever? (I am pretty sure that this last choice cannot be done, by anything, without some kind of frequent deadlocking or severe blocking).  Like IDENTITY, it leaves gaps on ROLLBACK - as you say, all non-blocking methods do. It is, however, possible to avoid gaps if a 'pool' of pre-allocated keys is cached and managed by a separate component. That is an implementation detail to be handled by the application.
Paul
Paul White SQL Server MVP SQLblog.com @SQL_Kiwi
|
|
|
|
|
SSCrazy Eights
        
Group: General Forum Members
Last Login: Saturday, May 04, 2013 11:13 AM
Points: 9,855,
Visits: 9,374
|
|
|
|
|
|
SSChampion
        
Group: General Forum Members
Last Login: Wednesday, May 08, 2013 10:33 AM
Points: 10,989,
Visits: 10,529
|
|
RBarryYoung (2/28/2010) Cool. That would be my choice, simpler. Quite. The pooled keys would be allocated from a Sequence Table, naturally
Paul White SQL Server MVP SQLblog.com @SQL_Kiwi
|
|
|
|
|
SSC-Addicted
      
Group: General Forum Members
Last Login: Thursday, May 16, 2013 1:15 PM
Points: 423,
Visits: 1,948
|
|
If I am not misreading the original request, I think you are trying to get multiple pseudo-identity columns in a single table.
This is a somewhat squirrely approach but it'd probably work for you as long as possible holes in your sequences are not a problem. This code is based on a discussion some time back (it may have been here at SSC; does anyone still have the link?) about doing pretty much what you wanted-- except for the "multiple columns" requirement. Each column that needs its own pseudo identity value needs its own SneakyIdentity table... Ideally you'd lock it down and document the bejeebers out of it so nobody stumbles in and tries to figure out what an empty table is doing in the system. (and potentially mungs the identity value) Add appropriate error trapping. You may want to put the code shown in a USP.
-- create the table to start -- create table SneakyIdentity(rowid bigint identity PRIMARY KEY) -- drop table SneakyIdentity
-- insert bumps "next identity row" but the rollback prevents the row from getting saved begin transaction insert into SneakyIdentity DEFAULT VALUES rollback transaction
-- IN USP, this would actually be an OUTPUT parm so wouldn't need to declare here... declare @uid bigint select @uid = Scope_Identity() select @uid Retval
-- the table stays empty select * from SneakyIdentity
Cursors are useful if you don't know SQL
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Tuesday, January 08, 2013 4:57 PM
Points: 9,
Visits: 64
|
|
| That is sneaky! How would you manage the locking and multi-user aspects of this, ie to prevent thousands of calls per second retrieving the same ID?
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 12:30 PM
Points: 32,893,
Visits: 26,770
|
|
peter-970097 (3/1/2010) That is sneaky! How would you manage the locking and multi-user aspects of this, ie to prevent thousands of calls per second retrieving the same ID?
The value of the identity property doesn't rollback with the transaction and the insert can happen many times within the same table. It's no where's near as contentious as an UPDATE. It would be interesting to see if deadlocks occur or not on this.
It would be diffcult to reserve a range of ID's with because IDENTITIES are not guaranteed to be sequential if other people are also inserting into the table.
--Jeff Moden "RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
|
|
|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: Yesterday @ 5:42 PM
Points: 15,
Visits: 78
|
|
From NOT a DBA ...
sounds like what you really need is an Oracle "sequence". I have implemented similar as follows: CREATE PROCEDURE dbo.nextval @sequence varchar(28) AS SET NOCOUNT ON DECLARE @sql nvarchar(100), @scope_identity int SET @sql = 'INSERT ' + @sequence + ' default values SELECT @scope_identity=SCOPE_IDENTITY()' BEGIN TRANSACTION NEXTVAL SAVE TRANSACTION SEQUENCER EXEC sp_executesql @sql, N'@scope_identity INTEGER OUT', @scope_identity OUT ROLLBACK TRANSACTION SEQUENCER COMMIT TRANSACTION NEXTVAL SET NOCOUNT OFF SELECT @scope_identity; GO with a created table (@sequence) that contains only an identity column, this concept allows any number of "sequences".
The upside: locking is minimized or eliminated, the table size never changes (more or less) The downside: there maybe gaps in the sequence
SQL Server has this "useful" feature, it never rolls back an identity value assigned, so even though the transaction is rolled back the identity value is not :)
Phil
|
|
|
|