Can i recover transaction after instance crash in oracle 11g - sql

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.

Related

How is consistency maintained in transactional systems in the event of a power outage?

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.

when exactly does writing in data files occur in sql?

i am currently studying transaction management in dbms .... from database systems elmasri and navathe 6th edition link: http://mathcomp.uokufa.edu.iq/staff/kbs/file/2/Fundamentals%20of%20Database%20Systems%20-%20Ramez%20Elmasri%20&%20Navathe.pdf
can someone please tell (in short) the transaction commit process i.e. without going into too much detail .... i also read some portion from oracle forum link :
https://docs.oracle.com/cd/B19306_01/server.102/b14220/transact.htm
what i could understand is that actual writing can take place before or after committing ... but if changes made have to be visible to all users then it must take before commit not after commit , right ?
can someone please help me clear the confusion ??
As the forum post indicates, writes to the data files are completely independent of transaction control. Changes might be written before a transaction commits, they might be written after the transaction commits.
When changes are made, those changes are made to a version of the data in memory. In order for a transaction to commit successfully (assuming default commit settings), the change must be written to the redo logs. That allows the database to re-create the change if it has not been written to data files and the database crashes. Conversely, if a change is written to a data file before the transaction is committed, information on how to reverse the change will be in the undo logs so that if the transaction will be able to be rolled back if the database fails before the transaction commits (or if the application issues a rollback).

power off during long sql transaction

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.

What happens when a transaction is being carried out during backing up of LDF files?

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.

What impact does SQL transactional Replication have on the transaction log file

Im setting up SQL Server Transactional replication that will be continuously running. The distributor for this setup at the server receiving the data
Should i have any concerns with transaction log file sizes if this is running continuously?
Considerations for Transactional Replication: Transaction Log Space
For each database that will be
published using transactional
replication, ensure that the
transaction log has enough space
allocated. The transaction log of a
published database might require more
space than the log of an identical
unpublished database, because the log
records are not truncated until they
have been moved to the distribution
database.
If the distribution database is
unavailable, or if the Log Reader
Agent is not running, the transaction
log of a publication database
continues to grow. The log cannot be
truncated past the oldest published
transaction that has not been
delivered to the distribution
database. We recommend that you set
the transaction log file to auto grow
so that the log can accommodate these
circumstances. For more information,
see CREATE DATABASE (Transact-SQL) and
ALTER DATABASE (Transact-SQL).
Disk Space for the Distribution Database
Ensure that you have enough disk space
to store replicated transactions in
the distribution database:
If you do not make snapshot files
available to Subscribers immediately
(which is the default): transactions
are stored until they have been
replicated to all Subscribers or until
the retention period has been reached,
whichever is shorter.
If you create a transactional
publication and make the snapshot
files available to Subscribers
immediately: transactions are stored
until they have been replicated to all
Subscribers or until the Snapshot
Agent runs and creates a new snapshot,
whichever is longer. If the elapsed
time between Snapshot Agent runs is
greater than the maximum distribution
retention period for the publication,
which has a default of 72 hours,
transactions older than the retention
period are removed from the
distribution database. For more
information, see Subscription
Expiration and Deactivation.