Does anyone know what will happen if microsoft sql server's power is switched off during a long sql transaction? will the db rollback the unfinished transaction by itself?
Thanks
The actual data-commit will never be excecuted so there is no problem with inconsistent data. There will be a rollback instead of a commit which wil happen as soon as the server restarts.
https://technet.microsoft.com/en-us/library/ms191455%28v=sql.105%29.aspx
After the redo phase has rolled forward all the log transactions, a
database typically contains changes made by transactions that are
uncommitted at the recovery point. This makes the rolled forward data
transactionally inconsistent. The recovery process opens the
transaction log to identify uncommitted transactions. Uncommitted
transactions are undone by being rolled back, unless they hold locks
that prevent other transactions from viewing transactionally
inconsistent data. This step, is called the undo (or roll back) phase.
If the data is already transactionally consistent at the start of the
recovery process, the undo phase is skipped. After the database is
transactionally consistent, recovery brings the database online. After
one or more backups have been restored, recovery typically includes
both the redo and undo phases. Every full and differential backup
contains enough transaction log records to allow for the data in that
backup to be recovered to a self-consistent state.
Related
How is consistency maintained in transactional systems in the event of a power outage?
For example, consider the operation below that are performed within a transaction.
UPDATE table SET someColumn = someColumn + 1 WHERE <whatever>
In the event of a sudden power outage, how can we ensure that the operation is completed or not?
From SQL server docs:
SQL Server uses a write-ahead logging (WAL) algorithm, which guarantees that no data modifications are written to disk before the associated log record is written to disk. This maintains the ACID properties for a transaction. ... The log records must be written to disk before the associated dirty page is removed from the buffer cache and written to disk.
As far as I understand, using the example of the SQL increment operation above, the following operations occur:
Write a record to the transaction log.
Flush changes to disk.
When a sudden shutdown occurs, how does the system know if the incremental operation has completed? How does it understand from when to rollback? (a shutdown can occur after adding a log to transaction log, but before flushing changes to disk, is it?)
And I have another (second) question, it is similar to this one.
How can we guarantee atomicity? For example,
UPDATE table SET someColumn = someColumn + 1 AND otherColumn = otherColumn + 2 WHERE <whatever>
How can we ensure that in the event of a sudden power off, the field otherColumn will also be updated, or no fields will be updated?
Write-Ahead Logging (WAL). See eg Transaction Log Architecture
a shutdown can occur after adding a log to transaction log, but before flushing changes to disk, is it?
Log records are added to the transaction log in memory, but when a transaction is committed SQL Server waits for confirmation that all the log records have been written to durable media. And on restart the transaction will be rolled back if all its log records haven't been flushed to disk.
And SQL Server requires the storage system to flush changes to disk, disabling any non-persistent write caching.
i updated data in my table before commit transaction i shut the database with shutdown abort when again start the database the data gone
how to recover uncommitted transaction in oracle 11g?
There are two possible ways of doing that (besides some workarounds):
Cache Recovery
To solve this dilemma, two separate steps are generally used by Oracle Database for a successful recovery of a system failure: rolling forward with the redo log (cache recovery) and rolling back with the rollback or undo segments (transaction recovery).
The online redo log is a set of operating system files that record all changes made to any database block, including data, index, and rollback segments, whether the changes are committed or uncommitted. All changes to Oracle Database blocks are recorded in the online redo log.
The first step of recovery from an instance or media failure is called cache recovery or rolling forward, and involves reapplying all of the changes recorded in the redo log to the datafiles. Because rollback data is also recorded in the redo log, rolling forward also regenerates the corresponding rollback segments.
Rolling forward proceeds through as many redo log files as necessary to bring the database forward in time. Rolling forward usually includes online redo log files (instance recovery or media recovery) and could include archived redo log files (media recovery only).
After rolling forward, the data blocks contain all committed changes. They could also contain uncommitted changes that were either saved to the datafiles before the failure, or were recorded in the redo log and introduced during cache recovery.
Transaction Recovery
After the roll forward, any changes that were not committed must be undone. Oracle Database applies undo blocks to roll back uncommitted changes in data blocks that were either written before the failure or introduced by redo application during cache recovery. This process is called rolling back or transaction recovery.
Figure 12-2 illustrates rolling forward and rolling back, the two steps necessary to recover from any type of system failure.
Figure 12-2 Basic Recovery Steps: Rolling Forward and Rolling Back
Oracle Database can roll back multiple transactions simultaneously as needed. All transactions that were active at the time of failure are marked as terminated. Instead of waiting for SMON to roll back terminated transactions, new transactions can recover blocking transactions themselves to get the row locks they need.
Source link here.
A small addition, to shed some light on the case:
Oracle performs crash recovery and instance recovery automatically after an instance failure. In the case of media failure, a database administrator (DBA) must initiate a recovery operation. Recovering a backup involves two distinct operations: rolling the backup forward to a more recent time by applying redo data, and rolling back all changes made in uncommitted transactions to their original state.
In general, recovery refers to the various operations involved in restoring, rolling forward, and rolling back a backup. Backup and recovery refers to the various strategies and operations involved in protecting the database against data loss and reconstructing the database should a loss occur.
In brief, you can not recover the updated data, as it should be rolled back, in order to preserve the Database consistency. Have in mind that transactions are atomic, so they should be either COMMITTED or ROLLED BACK. Since the session that initiated it is now killed(stopped), no one can COMMIT it - thus the SMON does a ROLLBACK.
Uncommitted transactions will be rolled-back one the instance starts after the crash.
My DB Admin advised that I should regularly take backup of .ldf files. Fine, this SQL post here explains this beautifully.
Consider that a transaction is being done in SQL Server. And at the same time, a scheduled process tries to access the .ldf file for backing it up.
What happens ? How this works ?
You must read Article Understanding SQL Server backup by Paul Randal. That is the best I can see which is available and can explain you in details various aspects.
Coming to your question a transaction log backup includes all information from previous transaction log back or full backup that started the log chain. Backup simply means reading information froma file(data or log) and writing it to destination disk. The transaction any would work independed of log backup running. A transaction follow a WAL(write ahead logging) protocol, for practical purposes all transaction information is first written in log file and then changes are later made to data file. So when transaction is running it would not be affected by transaction log backup job which is running both are doing different task and are muttually exclusive events. Current backup would try to backup all logs which are marked as committed and would truncate the logs if no transaction requires it. If any portion of log is committed after log backup has read that portion it would not come in current log backup but would come under further log backup.
Transacion log backup has important role in crash recovery it helps in determining what all operations has to be roll forwared and what has to be rolled back. Without transaction log backup or transaction log crash recovery is not possible
You must also read Logging and recovery in SQL Server to know about life cycle of a transaction.
The excat answer as to what acctual steps happens inside is beyond scope of discussion as nobody can exactly tell you what would happen but reading the article would give you a good idea.
Please let me know if you have any further questions.
i am interesting to know know how the isolation level"READ COMMITTED" is provided in Oracle DB implementation. I already know that DB makes records in REDO log, but for now i think that that REDO log is only used to repeat the transaction in case when some unpredictable crash will happen during the transaction. Also i know that DBWR writes the "dirty blocks" every time the REDO log file is filled. But my question is: if DBWR writes "dirty"(changed blocks) to the disk, how isolation level"READ COMMITTED" is provided. I mean during writing DBWR writes data directly to data files or in some special "place" on disk that is visible from current transaction and invisible from other transaction? So after the COMMIT this "place" becomes visible and that's all ? How this works in reality? Sorry for bad English.
In addition to the REDO log, you also have the UNDO tablespace.
When updating data, the old value is stored in the UNDO tablespace. When Oracle sees that you would be reading uncommitted data for a record, it reconstructs the old value from there.
UNDO is also used during database recovery: In addition to re-applying writes that have been committed but not made it to the database files before the crash, the opposite can also take place: rolling back uncommitted changes to database files that happened before the crash.
It's a test environment, I needed some data to test an Update query, but accidentally updated a column in all rows to have wrong data. Must I use a backup to restore the data back to the previous instance, or is there some secret with transaction log that I can take advantage of?
Thanks in advance.
There is a non-secret transaction log called transaction log that you can recover from to a point in time. Here's how... That annoying little file with the ldf extension is the transaction log, as opposed to the .mdf file that is your normal db data.
Unless you have truncated the transaction log (ldf) or otherwise mucked with it, you should be able to do exactly the kind of restore (undo) that you're looking for.
If your database was in full recovery mode then you can try reading transaction log using third party tool such as this one or you can try doing this yourself with DBCC LOG command.
If db is in full recovery then a lot of data is stored in transaction log but it’s not easily readable because MS never polished official documentation for this and because it’s purpose is not recovery but making sure transaction is committed correctly.
However there are workarounds to reading it like using the tool above (paid tool unfortunately but has a trial) or decoding the results of DBCC LOG yourself.
Not unless you wrapped your sql in a transaction block - begin transaction, rollback, commit. That one of the dangerous things about sql server. With Oracle you have to physically commit each transaction which is much safer imho.