It happened to me before.
I was running a stored procedure and it stopped after about 11 minutes of running, without completion.
The problem is because it uses too much memory (private memory set).
It stopped when there is no more memory able to allocate for the process.
You can see that for my case, the private working started from 148 MB to 984 MB (and the physical memory reached 93%) and then it stopped.
So, the reason is not that physical memory has reached 100%, even though this is inevitable. The real reason is that it wasn't able to get memory to do processing.
That is the reason why it stopped.
Now, let's investigate the reason why it happened.
It is because of the stored procedure which keeps updating the screen due to SELECT query.
The stored procedure's function is to copy data from one table and try to sync it to another table if it is not exist, otherwise, existing record will be updated accordingly.
Thus, the solution that I have derived is to not perform SELECT query to check if a record is in existence or not.
Instead of performing SELECT query, for each record from the source table, the revised script will perform UPDATE directly, and if @@rowcount is equal to 1, then it means similar record exist and update is successful, otherwise, similar record is not in existence and INSERT query will then be performed.
This actually solved the whole thing and the stored procedure was able to execute to completion.
Besides that, using the revised script, the CPU utilization is virtually zero and private memory set is low.
1.) The snippet SQL script with SELECT query to match existing record. (Not recommended, fail to complete)
2.) The SQL script using UPDATE query to match existing record. (Recommended)
Can we assume that this is an issue for SQL Server Management studio (SSMS) ?
I was running a stored procedure and it stopped after about 11 minutes of running, without completion.
The problem is because it uses too much memory (private memory set).
It stopped when there is no more memory able to allocate for the process.
You can see that for my case, the private working started from 148 MB to 984 MB (and the physical memory reached 93%) and then it stopped.
So, the reason is not that physical memory has reached 100%, even though this is inevitable. The real reason is that it wasn't able to get memory to do processing.
That is the reason why it stopped.
Now, let's investigate the reason why it happened.
It is because of the stored procedure which keeps updating the screen due to SELECT query.
The stored procedure's function is to copy data from one table and try to sync it to another table if it is not exist, otherwise, existing record will be updated accordingly.
Thus, the solution that I have derived is to not perform SELECT query to check if a record is in existence or not.
Instead of performing SELECT query, for each record from the source table, the revised script will perform UPDATE directly, and if @@rowcount is equal to 1, then it means similar record exist and update is successful, otherwise, similar record is not in existence and INSERT query will then be performed.
This actually solved the whole thing and the stored procedure was able to execute to completion.
Besides that, using the revised script, the CPU utilization is virtually zero and private memory set is low.
1.) The snippet SQL script with SELECT query to match existing record. (Not recommended, fail to complete)
fetch next from @maincursor into @cMyID,@cName while (@@fetch_status <> -1)
BEGIN
-- If not found, insert, else update -------------
SELECT recID FROM [TBL_1] where cMyID=@cMyID
if @@ROWCOUNT >=1
BEGIN
--- UPDATE -----
BEGIN TRY
UPDATE [TBL_1] SET cName=@cName WHERE cMyID=@cMyID
END TRY
BEGIN CATCH
--- Update Exception ----
END CATCH
END
else
BEGIN
-- INSERT -----
BEGIN TRY
INSERT INTO [TBL_1] (cMyID,cName) VALUES (@cMyID,@cName)
END TRY
BEGIN CATCH
--- Insert Exception ----
END CATCH
END
fetch next from @maincursor into @cMyID,@cName
END
2.) The SQL script using UPDATE query to match existing record. (Recommended)
fetch next from @maincursor into @cMyID,@cName while (@@fetch_status <> -1)
BEGIN
-- If not found, insert, else update -------------
--- UPDATE -----
BEGIN TRY
UPDATE [TBL_1] SET cName=@cName WHERE cMyID=@cMyID
if @@ROWCOUNT >=1
BEGIN
--- Success ----
END
ELSE
BEGIN
-- INSERT -----
BEGIN TRY
INSERT INTO [TBL_1] (cMyID,cName) VALUES (@cMyID,@cName)
END TRY
BEGIN CATCH
--Insert exception---
END CATCH
END
END TRY
BEGIN CATCH
-- Update exception ---
END CATCH
fetch next from @maincursor into @cMyID,@cName
END
Can we assume that this is an issue for SQL Server Management studio (SSMS) ?





Comments