I executed a simple SQL performance query to retrieve the sessions running currently in the database in Oracle sql developer.
But accidentally my cursor clicked on the roll back icon and it got rolled back.
Could you please tell me What happens to the entire database after this?
Rolling back a select does nothing as long as you didn't make changes to the database without committing the transaction.
In oracle clients when you run a query that modifies the database, the query is first run. Another step is then needed to commit the transaction.
MS SQL Server has a similar concept where you can do safe transactions like
begin tran
delete from table where val > 5
rollback{commit}
This allows you to look at the number of records your SQL statement have done prior to committing the transaction. If you want you can choose to rollback or commit your transaction.
What exactly did you roll back? That "simple SQL performance query", or "sessions running currently in the database in Oracle SQL Developer"?
If former, nothing happened, SELECT didn't do any changes anyway. If it were SELECT ... FOR UPDATE, lock would have been released.
If latter, then any changes you did in the database since previous COMMIT were rolled back (as you didn't roll back to a savepoint), so - nothing happened either.
What happens to the entire database after this?
It returned to state it was in earlier, as if you didn't touch anything at all.
Related
In haste, I stupidly ran a statement to update a table without qualifying it with a where statement. So it started to update all records in the table.
I immediately noticed the error and hit the 'Cancel Execution" button in SQL Server Management Studio, but it took a minute to stop running.
So my question is, did it roll back the changes or were they made until it was told to stop?
I can't tell which records were updated just by looking at them. I'd have to restore the table if it did make any changes.
Thanks.
I wanted to run:
Update tableA
set newdate = '2019-01-01'
where account = 'abc'
but instead I ran:
Update tableA
set newdate = '2019-01-01'
The database is a transactional type database.
SQL Server has the default transaction behaviour by default. That means that each sentence you run in the query editor is like:
BEGIN TRANSACTION
<YOUR COMMAND>
COMMIT TRANSACTION
So, if you have cancelled before finished, the transaction should be rolled back.
If the query hasn't finished before being cancelled then yes, it was rolled back. Either whole update was executed or nothing was changed.
I'm using MS SQL Server 2005 enterprise edition. I executed an update query to get affect a record in a row and a column.
update HS_SM_USERACCOUNT
set ACCOUNTPOLICYTYPE=1
where EMP_NUMBER='000540' and USERID='03510410#'
Earlier the column called ACCOUNTPOLICYTYPE is holding value 1 for that particular condition in WHERE clause. Now I want to get the previous state without executing Update Query again.
Will ROLLBACK help me? Please help me on this.
No. It's changed. If you want to know what it was, restore from backup
Unless you executed the above query within the scope of a TRANSACTION - i.e. within BEGIN TRAN / COMMIT / ROLLBACK TRAN block, the ROLLBACK command is going to be of no use.
There is nothing you can do to get back the state that you updated with the above statement in such a situation except RESTORE an OLD backup of that table data
I have a SQL Server 2008 database and I have a problem with this database that I don't understand.
The steps that caused the problems are:
I ran a SQL query to update a table called authors from another table called authorAff
The authors table is 123,385,300 records and the authorsAff table is 139,036,077
The query took about 7 days executing but it didn't finish
I decided to cancel the query to do it another way.
The connection on which I was running the query disconnected suddenly so the database became in recovery until the query cancels
The server was shut down many times afterwards because of some electricity problems
The database took about two days and then recovered.
Now when I run this query
SELECT TOP 1000 *
FROM AUTHORS WITH(READUNCOMMITTED)
It executes and returns the results but when I remove WITH(READUNCOMMITTED) hint it gets locked by a process running on the master database that appears only on the Activity Monitor with Command [DB STARTUP] and no results show up.
so what is the DB STARTUP command and if it's a problem, how can I solve it?
Thank you in advance.
I suspect that your user database is still trying to rollback the transaction that you canceled. A general rule of thumb indicates that it will take about the same amount of time, or more, for an aborted transaction to rollback as it has taken to run.
The rollback can't be avoided even with the SQL Server stops and starts you had.
The reason you can run a query WITH(READUNCOMMITTED) is because it's ignoring the locks associated with transaction that is rolling back. Your query results are considered unreliable, but ironically, the results are probably what you want to see since the blocking process is a rollback.
The best solution is to wait it out, if you can afford to do so. You may be able to find ways to kill the blocking process, but then you should be concerned with database integrity.
A few minutes ago, while working out a new sproc, I executed the wrong delete statement. Something like this:
Delete From SomeTable Where SomeStatusID=1
10 seconds into it, I realized that I typed in the wrong status and hit cancel. It said that the statement was canceled.
I did a restore to a separate database to get back the table that I just presumably nuked, thinking that since this was not in a transaction some records were probably deleted.
Oddly, the records were all intact. Just curious as to why this was -- did it treat the individual delete statement as a transaction in this case, even though there was not an explicit transaction defined?
By default, a single DML statement is executed as a transaction. If the statement succeeds, the transaction is committed. If the statement is cancelled or otherwise fails, the transaction is rolled back.
This behavior is built in to the engine, and is not related to management studio. See Autocommit Transactions in the docs.
There are always transactions. The only thing that changes is how those transactions are isolated from each other and that in management studio the transaction might not be defined explicitly and is auto-committed when the query finishes.
When running a stored procedure (from a .NET application) that does an INSERT and an UPDATE, I sometimes (but not that often, really) and randomly get this error:
ERROR [40001] [DataDirect][ODBC Sybase Wire Protocol driver][SQL Server]Your server command (family id #0, process id #46) encountered a deadlock situation. Please re-run your command.
How can I fix this?
Thanks.
Your best bet for solving you deadlocking issue is to set "print deadlock information" to on using
sp_configure "print deadlock information", 1
Everytime there is a deadlock this will print information about what processes were involved and what sql they were running at the time of the dead lock.
If your tables are using allpages locking. It can reduce deadlocks to switch to datarows or datapages locking. If you do this make sure to gather new stats on the tables and recreate indexes, views, stored procedures and triggers that access the tables that are changed. If you don't you will either get errors or not see the full benefits of the change depending on which ones are not recreated.
I have a set of long term apps which occasionally over lap table access and sybase will throw this error. If you check the sybase server log it will give you the complete info on why it happened. Like: The sql that was involved the two processes trying to get a lock. Usually one trying to read and the other doing something like a delete. In my case the apps are running in separate JVMs, so can't sychronize just have to clean up periodically.
Assuming that your tables are properly indexed (and that you are actually using those indexes - always worth checking via the query plan) you could try breaking the component parts of the SP down and wrapping them in separate transactions so that each unit of work is completed before the next one starts.
begin transaction
update mytable1
set mycolumn = "test"
where ID=1
commit transaction
go
begin transaction
insert into mytable2 (mycolumn) select mycolumn from mytable1 where ID = 1
commit transaction
go