Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2000 Forums
 SQL Server Development (2000)
 server process won´t die

Author  Topic 

Daniel_Buchholz
Starting Member

28 Posts

Posted - 2002-05-29 : 07:48:31
Hallo all!

We have an import situation here and while the import runs we cannot afford tables to be locked as there are other applications that need to read and write data. All we want is to have rowlocks or pagelocks on tables that get updated. But until now we didn´t succeed with the rowlock oder paglock hints. At some stage of the import the server always escalates to table locking.

So right now the workaround is to hold rowlocks in a separate server process on single rows of some tables. We know that these locked rows will never be touched by the normal import process, in fact they are just there for the purpose of being locked. After that SQL server cannot escalate to table locks in our main process because we set up those row locks before (and they are only cleared after the main process finishes it´s tasks).

We have one master import procedure that controls the whole import process. What we do is:

- Create a separate connection via SQL-DMO. There we open up a transaction and obtain some rowlocks by doing dummy updates on single rows.

- In the main process we do our import in it´s own transaction

- After that we release the locks in the DMO connection by doing a rollback or commit (don´t know which one at the moment) and bring down the connection.

This works excellent so far. The problem is: If the main import process fails the DMO connection never releases the locks and the spid still is there. Even if the session that built up the DMO conn exits the other connection survives and I have to kill it.

Is there any way to ensure that the locks are released and the process gets terminated even if the main process fails and cannot do the cleanup?

Or if there is another approach to prevent escalation to table locks... PAGLOCK or ROWLOCK hints don´t seem to do.

Daniel

setbasedisthetruepath
Used SQL Salesman

992 Posts

Posted - 2002-05-29 : 09:29:48
Questions:
1) What version of SQL Server?
2) What isolation level are your transactions running in?
3) What have you done to verify the lock escalation?
4) Is there a specific DML statement that causes the escalation?

Also, posting the relevant snippets of the import procedure along w/ any relevant DDL would give us a better picture of what you're doing.

setBasedIsTheTruepath
<O>
Go to Top of Page

Daniel_Buchholz
Starting Member

28 Posts

Posted - 2002-06-03 : 04:08:41
Unfortunately I have no idea where the lock escalation happens. It happens somewhere in a set of about 30 to 40 stored procedures that do the import. They were coded by some of my colleagues.

My task is to provide a workaround. Server version ist SQL Server 2000. I still do not understand why those locks are not cleared. Here´s what I do:



DECLARE @Error INT
DECLARE @ErrorMsg VARCHAR(255)
DECLARE @oSQLServer INTEGER
DECLARE @Source VARCHAR(255)
DECLARE @Return INTEGER
declare @dynsql nvarchar(3000)
declare @oDatabase int
declare @oQueryResults int
declare @Length int
declare @CurrentDB varchar(255)
declare @SQL varchar(8000)

-- Create the SQLServer object
EXEC @Error = sp_OACreate 'SQLDMO.SQLServer', @oSQLServer OUT

-- Set the login process to use NT Authentication
EXEC @Error = sp_OASetProperty @oSQLServer, 'LoginSecure', -1

-- Connect to server using NT Authentication
EXEC @Error = sp_OAMethod @oSQLServer, 'Connect', NULL, @@SERVERNAME

-- Verify the connection
EXEC @Error = sp_OAMethod @oSQLServer, 'VerifyConnection', @Return OUTPUT

-- Create Function with server object
select @dynsql = N'CREATE Function MFF_Imp_DummyLockConnectionTest () RETURNS INT AS BEGIN RETURN ' + cast(@oSQLServer as varchar) + N' END'
EXEC sp_executesql @dynsql

-- Set the database object to be the current database
SELECT @CurrentDB = DB_NAME()
SELECT @CurrentDB = 'Databases("' + RTRIM(@CurrentDB) + '")'
EXEC @Error = sp_OAGetProperty @oSQLServer, @CurrentDB, @oDatabase OUT

--+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-- Build the SQL string
SET @SQL = (Some statements that will result in some rowlocks after opening a transaction)'
--+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

-- Execute the SQL
SET @Length = LEN(@SQL)
SET @ErrorMsg = '' -- Must initialize the @ErrorMsg string
EXEC @Error = sp_OAMethod @oDatabase, 'ExecuteWithResultsAndMessages', @oQueryResults OUTPUT, @Length = @Length, @Command = @SQL , @Messages = @ErrorMsg OUTPUT

EXEC @Error = sp_OADestroy @oDatabase
EXEC @Error = sp_OADestroy @oQueryResults

begin tran

Some real work here. If this code works the locks are cleared
afterwards as the cleanup part executes. If the procedure crashes
here the locks still are there...


commit tran

-- Get the connection object
Select @oSQLServer = dbo.MFF_Imp_DummyLockConnectionTest()

-- Set the database object to be the current database
SELECT @CurrentDB = DB_NAME()
SELECT @CurrentDB = 'Databases("' + RTRIM(@CurrentDB) + '")'
EXEC @Error = sp_OAGetProperty @oSQLServer, @CurrentDB, @oDatabase OUT

--+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-- Build the SQL string
SET @SQL = 'Commit Transaction '
--+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

-- Execute the SQL (this will NOT be rolled back)
-- We could use ExecuteImmediate here, but it doesn't return a result
-- and we found while debugging that you really NEED that
SET @Length = LEN(@SQL)
SET @ErrorMsg = '' -- Must initialize the @ErrorMsg string
EXEC @Error = sp_OAMethod @oDatabase, 'ExecuteWithResultsAndMessages', @oQueryResults OUTPUT, @Length = @Length, @Command = @SQL , @Messages = @ErrorMsg OUTPUT

EXEC @Error = sp_OADestroy @oDatabase
EXEC @Error = sp_OADestroy @oQueryResults

if exists (select * from sysobjects where id = object_id(N'dbo.MFF_Imp_DummyLockConnectionTest') and OBJECTPROPERTY(id, N'IsScalarFunction') = 1)
drop function dbo.MFF_Imp_DummyLockConnectionTest



Any ideas?

Daniel

Go to Top of Page
   

- Advertisement -