1 2 Previous Next 17 Replies Latest reply on May 14, 2013 1:40 AM by Hemant K Chitale Go to original post
      • 15. Re: why does backing up archivelogs take so long....
        Thanks Hemant, and all others who have offered their insights.

        Since migrating the database to our SAN, the backups are completing in nearly half the time, including backing up archive logs.

        But what is more important is that I'm now seeing the archivelogs to get backed up in proportional times with respect to the database.

        For the past 5 days at least, the archivelogs are only taking a few minutes to backup, as opposed to a couple hours previously.
        The only thing I can attribute it to is the I/O contention of DBWriter after the database backup completed with the backups of the archivelogs.
        Now that the database is separated from the archivelogs, there is no contention any more.
        I'm assuming this is why the performance is now much better (and as it should be).

        Notice the difference now of the completion time as compared to before:
        --------------- ------------- --------- -------------- -------------- -------
                   5588 DB INCR       COMPLETED 05/13/13 01:00 05/13/13 02:40    1.67
                   5579 DB INCR       COMPLETED 05/12/13 01:00 05/12/13 02:57    1.95
                   5570 DB INCR       COMPLETED 05/11/13 01:00 05/11/13 02:42    1.71
                   5561 DB INCR       COMPLETED 05/10/13 01:00 05/10/13 02:59    1.99
                   5552 DB INCR       COMPLETED 05/09/13 01:00 05/09/13 02:50    1.85
                   5543 DB INCR       COMPLETED 05/08/13 01:00 05/08/13 06:23    5.39
                   5540 DB INCR       RUNNING   05/06/13 01:26 05/06/13 03:10    1.74
                   5526 DB INCR       COMPLETED 05/05/13 05:41 05/05/13 08:31    2.83
                   5507 DB INCR       COMPLETED 05/04/13 02:28 05/04/13 04:57    2.48
                   5490 DB INCR       COMPLETED 05/03/13 01:00 05/03/13 05:30    4.50
                   5481 DB INCR       COMPLETED 05/02/13 01:00 05/02/13 05:43    4.72
                   5472 DB INCR       COMPLETED 05/01/13 01:00 05/01/13 05:46    4.77
                   5463 DB INCR       COMPLETED 04/30/13 01:00 04/30/13 04:57    3.96
                   5454 ARCHIVELOG    COMPLETED 04/29/13 03:07 04/29/13 04:56    1.82
        • 16. Re: why does backing up archivelogs take so long....

          Just for my own clarity, can you help me to understand this better.

          So, during the time of the backups, the tablespaces affected by backing up of datafiles are put in "backup" mode (if I remember correctly).
          Then, while in backup mode, the changes to those tablespaces are stored in UNDO tablespace.
          Then, once those tablespaces are put back online, then the changes are applied to the actual datafiles (by DBWriter) by reading the saved changes from the UNDO tablespace.
          So, does DBWriter also read the changes, or is that done by another background process?

          Is this correct?
          • 17. Re: why does backing up archivelogs take so long....
            Hemant K Chitale
            When you use RMAN, the tablespaces are NOT put in BEGIN BACKUP mode.

            BEGIN BACKUP and END BACKUP are for non-RMAN methods (e.g. "cp", "cpio", "tar", storage based snapshots etc) that are called User Managed Backups.

            In User Managed (BEGIN BACKUP mode) backups, _all changes do continue to be written to the datafiles_. It is wrong to assume that they are "stored" (or "held in reserve") in either the Undo or Redo files. Changes continue to be applied to datafiles. The datafile header is frozen to the checkpoint issued at the BEGIN BACKUP so the header is not updated with any subsequent checkpoints but blocks continue to be updated. When you issue an END BACKUP, the header is also updated.
            So, there is no additional I/O when you issue an END BACKUP.

            (During the BEGIN BACKUP mode, when a block is modified for the first time it is written in it's entirety to the redo stream, not just changes. That is why redo-archivelog generation is higher in User Managed backups).

            Hemant K Chitale

            Edited by: Hemant K Chitale on May 14, 2013 9:40 AM
            1 2 Previous Next