Roger25 wrote:The backup files can be understood as like the xerox copy of a file. So if you want to save a duplicate of an original document, how would you do that, you would make a xerox of it right? Backup of a file is just that, a duplicate copy of the original source file. But assume that the source file is getting updated too. So how would you ensure that the duplicate copy of the source file, which you made a month ago is going to match exactly with the new and updated source file? Well, simply by fitting in those missing new entries right? Those new entries are updated in the redo log/ archive log. If you understand this (sort of) analogy , it's good else it would be tricky to make you get the concept.
Can anyone tell me what's the real difference between a backup file and a redo log file/archived redo log file and the scenarios (examples) when each of them can be used (for example, "......") ?
Both are used for database/instance recovery. I have read the concepts of there 2 terms, but I need some additional information about the difference.No, you are wrong in the concept. The backup files are not used in the case of the instance recovery and so are the archive logs . In the instance recovery, only the online log files are going to be used. The backup files and the archive logs are going to be asked only in the case of the media recovery.
Roger25 wrote:Database changes are written to the online redo logs, which are of a fixed number and fixed size. Since they are fixed in size and number, they can only hold a fixed number of changes. When one online redolog group is full, the changes begin to be written to the next online redo log group. While that group is being used, the previous log is being copied to an archivelog file. Once the copy to the archivelog file is complete, that online redo log is available to be used again when the others get full.
Ok, thanks for reply.
Like your example with the xerox file give me please an example/scenario with online redo log / archive redo log, to better understant the concept with an example.
Roger25 wrote:No, with the system's crash, the transaction never gets a chance to get committed (and even rolled back) because a commit is only supposed to happen if there is an explicit or implicit commit statement is issued. Now, for the redo , with the statement, a commit marker is entered at the end of the redo stream of that transaction denoting that it's finally over now and for the corresponding transaction, the status is cleared from the transaction table that's stored in the Undo segment in which the Undo information of that transaction is stored. If you have given a huge update, the redo would be very highly required as you should be knowing that it's not all the time that the dirty buffers that are written to the data files unlikely the redo log files which are written every 3 econds. This means, there is a very fair chance that many changes have yet not even propagated to the data files for which the change vectors are now already there in the redo log files. Now, for the sake of clarity, assume that this transaction was actually committed! So now, without those changes be applied to the data files how Oracle can actually show the committed reults when the database next time would be opened? For this purpose, the redo change vectors are required. And for the uncommitted transactions , the applcation of the redo change vectors would keep on updating the Checkpoint numbers of the data files and would eventually get them synched with the control file and redo log files, without which the database would never be opened.
What i still don't understand is how redo mechanism works; I know, redo logs records changes made to the database and it's used to re-do informations in case of a system failure/crash, for example. Ok, let's say I have a huge update, but when the system crash has occured, the transaction is neither comitted, nor rolled back. Then, how this redo is useful? If a system crash occur, all those updates aren't rolled back automatically? So the database state is as before executing that huge update? So in this case, 'what to redo'?
Roger25 wrote:too bad for us that you never read or understood details available from Reading The Fine Manual below
Yes, it's accurate.. that update "crashed" the instance (that table is very often used and no one can do nothing on the instance in that moment), but why "on restart the uncommitted transaction would roll forward then roll back" ? In this case (instance recovery) only the online redo log file was used and not the backup?