In Oracle, Flashback is used to recover the database to a particular point.
If it is so, what is the need for backup and recovery? Since flashback itself can achieve the
recovery of database what is the need for backup and recovery feature of RMAN in oracle?
First, the retention of the flashback is limited (by the size of the undo tablespace, e.g.). Second, and more importantly - flashback is done against the same database. If you have a hardware failure on your storage device, the flashback will be corrupted just like the rest of the database. Backups, on the other hand, should be made to a different storage device.
Flashback only preserves transaction data, and only - for most people - for a few minutes or hours at most. It cannot be used to restore corrupted data files or to reload entire tables, only to rollback or recover very recent transactions. Running in archivelog mode with proper backups - physical (RMAN) and logical (datapump) - is necessary if you want real protection.
First of all, please keep in mind that Oracle Flashback is a name for Family of techniques (Flashback database, Flashback drop, Flashback query ... ).
You mention that Recovering DB to a paticular point - so I guest that you're mentioning "Flashback Database". There are some limitations with Flashback Database ralating to dropped datafile, NOLOGGING operations, ...
RMAN (with appropriate configuration) doesn't fear dropped datafile, NOLOGGING operations, ... at all! :)
Related
Can I use the "backup" transact sql command (sql-server 2008)
when my database is used (read/write) by other users.
Or I must switch to single_user mode before doing this?
Yes, it will let you do that. There are considerations though, regarding full and precise restoration of the data should a restore operation become necessary.
Best you read up on the whole thing so you can choose the best back-up method for your situation.
Yes, you can use the "backup" T-SQL command even the database is used (read/write) by other users.
For example, you are going to make a full database backup by T-SQL command:
BACKUP DATABASE Test TO DISK ='D:/Test.bak'
Suppose someone is working with the table at this moment. So, the transaction "A" started before the full backup began, made some changes after the checkpoint and committed before the backup completed.
In this case, the full backup includes all transaction log records starting from the latest active transaction. This implies that the full backup includes the whole transaction "A" with all changes that were made after the checkpoint to apply those changes during the database recovery process.
I have to take a Production SQL Database backup (Full Backup ) while the connection is on and transaction is happening. Does it affect any transactions. Do they maintain any transaction isolation levels ??
Not a development question.
Backups are transactional integer and will contain the transactions closed at the time of backup. ALl new / open transaction during the backup will be in the transaction log and not in the backup.
Database servers are not written by mediocre developers and the specialists know that backups are of paramount integrity. And like usual for high level products they write good documentation which - one can acutally read.
Technet magazine had a simple explanation for the different backup strategies; for Full Backup it starts out with:
"A full database backup provides a complete copy of the database and provides a single point-in-time to which the database can be restored. Even though it may take many hours for the backup process to run, you can still only restore the backup to a single point (effectively at the end of the backup, but I'll discuss exactly what that point is later in this article). A full backup does not allow recovery to any point in time while the backup was running. This is also the same for differential backups."
Your users will be able to use the application subject to the server having the disk / memory resources to carry on running whilst the backup is processed.
I wanted to see if you guys are utilizing marked transactions in your TFS backup scenario. Are there any drawbacks or gotchas to consider for this?
If I use the TFS Power Tools to create a backup plan, the following is created for me:
Tables and Stored Procedures needed for marked transactions
Scheduled Jobs
Maintenance Plans for Full, Differential, and Transaction Logs
The Backup/Restore Power Tool relies on SQL marked transactions to
keep consistency across the TFS (and dependency products) databases. Source: http://intovsts.net/tag/tfs-power-tools/
Before inserting named marks into the transaction log, consider the
following: Source: MSDN
Because transaction marks consume log space, use them only for
transactions that play a significant role in the database recovery
strategy.
After a marked transaction commits, a row is inserted in the
logmarkhistory table in msdb.
If a marked transaction spans multiple databases on the same database
server or on different servers, the marks must be recorded in the logs
of all the affected databases.
That kind of settles the matter of marked transactions in my backup plan. Especially since the TFS databases use full recovery mode, and the tool relies on it, there isn't much choice. :)
What's the difference of restore and recovery? What I understand is:
restore: refresh a database using the
backup files of this database
recovery: after the database fail,
such as the reboot the server, the
database reapply the committed
transaction in the transaction log
Does my understanding right?
Thanks,
Restore; bring a file back from backup media, e.g. tape, other disk
Recovery; re-running or unwinding in progress transactions that were partly completed in the DB.
Generally one will recover and then restore. Some RDBMes will hide the 2 different steps to some extent but still undertake the 2 different actions.
They are the same function, bringing back records that were accidentally dropped, repair corrupted database files, restore entire tables as well as queries, forms, macros, and stored procedures.
Oracle has SQL commands that one can issue so that a transaction does not get logged. Is there something similar for SQL Server 2008?
My scenario: We need Tx logs on servers (Dev, QA, Prod), but maybe we can do without them on developer machines.
You can't do without transaction logs in SQL Server, under any circumstances. The engine simply won't function.
You CAN set your recovery model to SIMPLE on your dev machines - that will prevent transaction log bloating when tran log backups aren't done.
ALTER DATABASE MyDB SET RECOVERY SIMPLE;
There is a third recovery mode not mentioned above. The recovery mode ultimately determines how large the LDF files become and how ofter they are written to. In cases where you are going to be doing any type of bulk inserts, you should set the DB to be in "BULK/LOGGED". This makes bulk inserts move speedily along and can be changed on the fly.
To do so,
USE master ;
ALTER DATABASE model SET RECOVERY BULK_LOGGED ;
To change it back:
USE master ;
ALTER DATABASE model SET RECOVERY FULL ;
In the spirit of adding to the conversation about why someone would not want an LDF, I add this: We do multi-dimensional modelling. Essentially we use the DB as a large store of variables that are processed in bulk using external programs. We do not EVER require rollbacks. If we could get a performance boost by turning of ALL logging, we'd take it in a heart beat.
SQL Server requires a transaction log in order to function.
That said there are two modes of operation for the transaction log:
Simple
Full
In Full mode the transaction log keeps growing until you back up the database. In Simple mode: space in the transaction log is 'recycled' every Checkpoint.
Very few people have a need to run their databases in the Full recovery model. The only point in using the Full model is if you want to backup the database multiple times per day, and backing up the whole database takes too long - so you just backup the transaction log.
The transaction log keeps growing all day, and you keep backing just it up. That night you do your full backup, and SQL Server then truncates the transaction log, begins to reuse the space allocated in the transaction log file.
If you only ever do full database backups, you don't want the Full recovery mode.
What's your problem with Tx logs? They grow? Then just set truncate on checkpoint option.
From Microsoft documentation:
In SQL Server 2000 or in SQL Server
2005, the "Simple" recovery model is
equivalent to "truncate log on
checkpoint" in earlier versions of SQL
Server. If the transaction log is
truncated every time a checkpoint is
performed on the server, this prevents
you from using the log for database
recovery. You can only use full
database backups to restore your data.
Backups of the transaction log are
disabled when the "Simple" recovery
model is used.
If this is only for dev machines in order to save space then just go with simple recovery mode and you’ll be doing fine.
On production machines though I’d strongly recommend that you keep the databases in full recovery mode. This will ensure you can do point in time recovery if needed.
Also – having databases in full recovery mode can help you to undo accidental updates and deletes by reading transaction log. See below or more details.
How can I rollback an UPDATE query in SQL server 2005?
Read the log file (*.LDF) in sql server 2008
If space is an issue on production machines then just create frequent transaction log backups.