Time for action – enabling the archive log mode

Perform the following steps on the primary database:

  1. Check whether archiving has been enabled or disabled, as follows:
    SQL> archive log list
Database log mode                No Archive Mode
Automatic archival               Disabled
Archive destination              USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence       6
Current log sequence             8
  2. Perform a clean shutdown, as follows:
    SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

    Tip

    Ensure that you have performed a clean shutdown; if not, you may see this error: ORA-00265: instance recovery required, cannot set ARCHIVELOG mode.

  3. Start the database in the mount state.
    SQL>startup mount
ORACLE instance started.
Total System Global Area      818401280 bytes
Fixed Size                    2217792 bytes
Variable Size                 515901632 bytes
Database Buffers              297795584 bytes
Redo Buffers                  2486272 bytes
Database mounted.
  4. Enable the archive log mode.
    SQL> alter database archivelog;
Database altered.
  5. Open the database as follows:
    SQL> alter database open;
Database altered.
  6. Check if archiving has been enabled or not.
    SQL> archive log list
Database log mode                Archive Mode
Automatic archival               Enabled
Archive destination              USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence       6
Next log sequence to archive     8
Current log sequence             8

    Tip

    After enabling the archive log mode, perform a log switch and check whether the archive log is created or not from the v$archived_log view, as follows:

    SQL> select * from v$archived_log;

What just happened?

After mentioning some considerations about Data Guard, we've completed the mandatory task of enabling the archive log mode on the primary database.

Force logging

For a physical standby to be a mirror copy, it must receive redo for the changes made to the primary database. In the primary database, when a segment is defined with the NOLOGGING attribute and if a NOLOGGING operation updates the segment, the online redo logfile will be updated with minimal information. This is preferred to complete operations faster but it's not supported in a primary database with the Data Guard configuration. When the redo/archived logfile containing the NOLOGGING operation is used to recover the datafiles on the standby database, Oracle invalidates such blocks and the error ORA-26040 along with error ORA-1578 are reported by SQL statements in the next block reads. You can see the following errors if operations are performed by NOLOGGING:

ORA-01578: ORACLE data block corrupted (file # 4, block # 84)
ORA-01110: data file 4: ' /u01/app/oracle/oradata/orcl/users01.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.15.221.133