I have a stored procedure and it has several insert/update statements. Then it has at last a huge select statement and after the selection of more than 1000 records ASE isql stops working, it just shows "Executing", but nothing else is working, I cannot connect or reconnect again. The same happens when I have a small select query.
Can somebody explain me, why?
I am working on SYBASE 15
Related
I have a Snowflake stored procedure which is running for 8 hrs. Upon checking the query profiler to see which query is running long I just see a single entry for the call stored procedure statement.
However, Through the logs I know that an insert statement is running which is like:
insert into Snowflake_table
select *
from External_table(over S3 bucket)
I want to check and find out why reading from external table is taking lot of time but the insert query is not showing up in the Query profiler. I have tried querying the information_schema.Query_history but its not showing another query running apart from the call stored procedure statement
SELECT *
FROM Table(information_schema.Query_history_by_warehouse('ANALYTICS_WH_PROD'))
WHERE execution_status = 'RUNNING'
ORDER BY start_time desc;
Please suggest how to find the bottleneck here
Docs is stating that Queries on INFORMATION_SCHEMA views do not guarantee consistency with respect to concurrent DDL: https://docs.snowflake.com/en/sql-reference/info-schema.html
This means that it is possible that your insert-statement is running but is not shown as a result of your query. It could be included but it's not a must.
You could now change the filter to execution_status IN 'success', 'failed' and check again after the procedure finished.
I am using the mssql-jdbc JDBC driver to do the following in a single transaction.
Executed the following statement:
delete from table1
There were around 10 records in the table which were deleted (execute update returned 10). Then, immediately following the delete, executed the following select statement:
select count(*) from table1
Resultset said that there are still 10 records.
In other DBs like Oracle and Postgres, we get 0, which is what I am expecting.
I do not want autocommit=true behaviour. Also, the two statements need to execute in the same transaction.
Is there anything I can do to get the behaviour I want?
Answering for my question.
There was a bug in the on-delete cascade trigger we had added for the table.
As a result, a commit was not happening when records in that table were deleted. Since no JDBC exceptions were being thrown for failures in the trigger, the problem was not apparent from Java end.
There was no other issue.
SP is RecordSource of the form.
When form is opened SP executed and after a time-out of query, connection is closing with nothing.
If SP executed from SSMS it performed for about 2 seconds and returns a set of records.
As I watched through the SSMS Profiler calls are identical, but count of Reads value (an execute from Access) > 28 million, and about 70 thousand from the SSMS.
Help me, I'm confused.
Screen with profiler
http://take.ms/u7tTy
#tobypls,
thank you very much - your link was helpful.
Simple solution is rewrite (for example)
from
ALTER PROCEDURE [dbo].[sproc]
#param1 int,
AS
SELECT * FROM Table WHERE ID = #param1
to
ALTER PROCEDURE [dbo].[sproc]
#param1 int,
AS
DECLARE #param1a int
SET #param1a = #param1
SELECT * FROM Table WHERE ID = #param1a
I get it from this post.
But if you need full understanding of trouble then you must read really great article
Slow in the Application, Fast in SSMS?
Understanding Performance Mysteries
I have trouble to update some rows in SQL Server (2005 and 2008).
Often, when I try to update one row while having a running query (select * from thistable),
I start the update command and it will fail due to a timeout/lock issue.
It only appears on tables with nvarchar(max)/text columns!
Even if I try to SELECT * FROM thistable WITH(ROWLOCK), I do encounter the same problem.
So my basic question here is:
Can I motivate SQL Server NOT to lock more than the actual row ?
Edit: I first run the SELECT afterwards I try to UPDATE...
There is a great explanation on Locking in SQL-Server on simple talk
Try using:
SELECT * FROM thistable (NOLOCK)
for your select statement.
Then run your update as normal.
I am migrating several hundred stored procedures from one server to another, so I wanted to write a stored procedure to execute an SP on each server and compare the output for differences.
In order to do this, I would normally use this syntax to get the results into tables:
select * into #tmp1 from OpenQuery(LocalServer,'exec usp_MyStoredProcedure')
select * into #tmp2 from OpenQuery(RemoteServer,'exec usp_MyStoredProcedure')
I then would union them and do a count, to get how many rows differ in the results:
select * into #tmp3
from ((select * from #tmp1) union (select * from #tmp2))
select count(*) from #tmp1
select count(*) from #tmp3
However, in this case, my stored procedure contains an OpenQuery, so when I try to put the exec into an OpenQuery, the query fails with the error:
The operation could not be performed because OLE DB provider "SQLNCLI"
for linked server "RemoteServer" was unable to begin a distributed transaction.
Are there any good workarounds to this? Or does anybody have any clever ideas for things I could do to make this process go more quickly? Because right now, it seems that I would have to run the SP on each server, script the results into tmp tables, then do the compare. That seems like a poor solution!
Thank you for taking the time to read this, and any help would be appreciated greatly!
I think your method would work - you just need to start the MSDTC. This behavior occurs if the Distributed Transaction Coordinator (DTS) service is disabled or if network DTC access is disabled. By default, network DTC access is disabled in Windows. When running and configured properly, the OLE DB provider would be able start the distributed transaction.
Check out this for instructions- it applies to any Windows Server 2003 or 2008.
Similar to your question.
Insert results of a stored procedure into a temporary table