Please anyone guide me samples for oracle for update attributes for row level locking purpose. please give me sample sql. thanks in advance
Guys thanx for your support, i had done a mistake, i will run the for update in same session that is the problem it wont affect the row level becoz of same thread process, using two different thread i mean sessions it will work fine.
Related
My understanding is 2 select statements will not cause deadlock to each other.
Recently, I got an error in my code. It happened maybe once or twice a week. I got a deadlock error when my code tries to query a view. The table is maintained by a third party application. We are not allowed to modify it. We just query the data via a view created from that table.
My understanding is even I have multiple threads querying this view. It won't cause the deadlock. I am sure that the rows I am querying will never be updated. So the deadlocks here can only be caused by multiple select statements?
If so, is there a way to overcome this issue?
I have read the post Transaction deadlock for select query.
I am using sql server 2008. There is no extended events in 2008. There is no solutions for this issue in that post? Does anyone know how to solve this issue?
Thank you.
Two processes are running simultaneously on a table. One is updating the records. The other is reading the data. While updating it is locking the table.so I am unable to read the data. Help to to handle the same.
Thanks,
Bibhu
I am assuming you are using SQL Server. You can use the WITH NOLOCK hint in your select statement, so the read goes through. However, you should be aware that it is a dirty read. Since the update statement is changing the data and the changes may or may not have been committed, the result of the read (select) statement can be problematic.
Here is a link to a page with more details and simple examples
https://www.mssqltips.com/sqlservertip/2470/understanding-the-sql-server-nolock-hint/
Someone deleted few rows off a very important table in SQL Server 2008 few weeks back, I wonder if I can check log or something, or if I can recover the rows.
Cheers
You can recover the records if you have backups of some kind. If you where logging every action then you should be able to check it out.
And finally, this link is questioning exactly about same issue. On comments to that questions you can find this other link on how to read transaction logs
Complementing the previous answer, an easiest way for "next time" that this happens would be to enable CDC to track changes on your tables.
Here is a very good article
While running the SQL Profiler on a client site I noticed getmyrunningjobs running over and over bogging down their system in the morning from about 5:30 am to 6:30am. I know it runs all the time but for some reason it appears to run 4 times in a row every couple of seconds in the morning. I'm not really sure what it is used for, though I've read a lot on SQL Profiler, I can't find much on SQL Report Server.
Can I stop or change the frequency or is there something else going on that I can check? Also, what is Tablockx, and is this related?
Thanks. Any help appreciated!
To answer your secondary question, TABLOCKX is a SQL Server table hint that applies an exclusive table lock. I'd think this would be related to your problem only if something is holding the lock for an unusually long time during the timeframe you indicated.
We have been having problems with ghost updates in our DB (SQL Server 2005). Fields are changing, and we cannot find the routine that is performing the update.
Is there any way, (perhaps using an update trigger ?) to determine what caused the update? The SQL statement, process, username/login,etc?
Use SQL Server Profiler
You'll probably want to filter away the things you don't need so it might take a while to get it setup.
At least it'll get you to the procedure / query that is responsible as well as user / computer for the alterations, which leaves finding that in your code.
I found and article that might help you out over here:
http://aspadvice.com/blogs/andrewmooney/archive/2007/08/20/SQL-Server-2005-Audit-Log-Using-Triggers.aspx
All the information that you are asking for is available at the time the update is performed. The SQL Profiler will certainly work, but it is a bit of work to craft a filter that does not overwhelm you with data, particularly if you need to run it for days or weeks at a time. An update trigger is easy enough the create, and you can log the information that you need in a new table.
I would probably use AutoAudit to generate triggers on the table first.
It's somewhat limited in terms of knowing exactly what is changing your data, but it's a start.
You could always look at the triggers and modify them to only log certain columns you are interested in and perhaps get more information which it doesn't currently log.