Q
Problem solve Get help with specific problems with your technologies, process and projects.

Questions about backup and recovery

I have several questions about backup and recovery. How is consistency maintained in RMAN and hot backups?

I have several questions about backup and recovery:

  1. You are storing 10 million records and after storing 3 million records, you get an error, "cannot extend rollback segment." What is this error and what do you do?
  2. How does hot backup maintain consistency during the backup?
  3. How does RMAN backup maintain consistency during the backup?
  4. During hot backup, what will happen to ongoing transactions?
  5. During hot backup, if a user performs a commit, then how will the data be stored in the data files?
  6. In RMAN backup, if, during the backup, you get a message about two archive log files missing so the backup cannot be completed, what would you do?

There are lots of questions here, so I'll take them one at a time.

  1. In order to make any changes to the database, you need the ability to be able to undo those changes, or roll the changes back. That is the purpose of your rollback segments. The rollback segment needs to have enough space to hold all the changes for your transaction. Inserting 10 million rows will take a lot of space in the rollback segments. You have two choices here. You can commit more often (like every 1 million rows), and you shouldn't have a problem, or you can increase the MAXEXTENTS of your rollback segments with a command similar to the following:
    ALTER ROLLBACK SEGMENT r01 STORAGE (MAXEXTENTS 500);
    

    You'll need to ensure that your rollback segment tablespace is sufficiently large to handle this.

  2. The hot backup maintains consistency by the ALTER TABLESPACE [BEGIN|END] BACKUP commands. When you place a tablespace in backup mode, the database freezes the System Change Number (SCN) in the data file's header. The SCN is like an incremental transaction number. The lower the SCN value, the older the transaction that caused the data to be changed. You then copy the data files with operating system commands. While this is going on, the database can be making changes to the data files, thus making the backup inconsistent. When you restore, the database uses information logged in the redo logs to build a consistent image of the data. This is why you must be in Archive Log mode before you can put a tablespace in backup mode. It is the combination of freezing the data file header's SCN and the redo logs that create a consistent data file from the inconsistent backup image. The database starts at the SCN in the frozen header and applies any changes to that data file since that SCN was frozen.
  3. RMAN uses a slightly different technique. You still need the archived redo logs to resolve the inconsistency. But you do not have to freeze the datafile's header SCN. Instead, RMAN looks at the block level for the SCN of the last change of that block. Otherwise, the process is the same.
  4. During a backup, transactions are allowed to proceed and modify the data files. All transaction information is written to the online redo logs, which eventually become archived. So even though your data files are inconsistent when backed up, the transactions are recorded and played back on recovery.
  5. When a user performs a COMMIT, then the changed data does not immediately get written to the datafiles. However, the changed data must be written to the online redo log files. A COMMIT is not complete until the online redo log files are updated. That's the only rule at play. Changed data will be flushed from the database buffer cache to the data files when room is needed in the cache and that changed block needs to be cleared out. Notice that the last sentence says nothing about a COMMIT. It is possible for uncommitted data to be written to data files. It is the job of the undo segments to revert the change in case of a ROLLBACK or a system failure.
  6. RMAN should be giving you that message during backup when an archived redo log is missing. What I would do is to perform a full backup of the database immediately. That way, you won't miss any transactions that were in the missing archived redo logs.

Dig Deeper on Oracle database backup and recovery

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchDataManagement

SearchBusinessAnalytics

SearchSAP

SearchSQLServer

TheServerSide.com

SearchDataCenter

SearchContentManagement

SearchHRSoftware

Close