Enabling Archivelog Mode- Managing Control Files, Online Redo Logs,and Archivelogs

After you have set the location for your archive redo log files, you can enable it as SYS with the following:

You can confirm archivelog mode with this query:

You can also confirm it as follows:
 

Disabling Archivelog Mode

Usually, you don’t disable archivelog mode for a production database. However, there might be a reason for disabling it, and if you can afford the downtime, you should at least know how to turn off archivelog mode. If you do this, be sure you make a backup as soon as possible after re-enabling archiving.

To disable archiving, do the following as SYS:

You can confirm archivelog mode with either one of these queries:

Reacting to Lack of Disk Space for Archive Logs

The archiver background process writes archive redo logs to a location that you specify. If, for any reason, the archiver process cannot write to the archive location, your database hangs. Any users attempting to connect receive this error:

As a production-support DBA, you never want to let your database get into that state. Sometimes, unpredictable events happen and you have to deal with unforeseen issues, quickly.

Note: DBAs who support production databases have a mindset completely different from that of architect DBAs. Getting new ideas or learning about new technologies is a perfect time to work together and communicate what might work or not work in your environment. Set up time outside of troubleshooting with production DBAs and architects to plan and set strategies for the environment.

In this situation with the archiver error, your database is as good as down and completely unavailable. To fix the issue, you have to act quickly:

•     If using the FRA, increase the space allocation for DB_RECOVERY_ FILE_DEST_SIZE.

•     If using the FRA, change the destination to a different location in the parameter DB_RECOVERY_FILE_DEST.

•     Use RMAN to back up and delete the archive log files.

•     Remove expired files from the directory using RMAN.

•     Move files to a different location as a temporary solution, which will require cleanup afterward.

•     Compress old files in the archive redo log location.

The quickest and safest way to resolve the archiver error is to increase the allocation or change the directory with the DB_RECOVERY_FILE_DEST parameters. Moving files is another quick way to resolve the archiver error with an OS utility such as mv; however, for restore and recovery processes, you will have to let the recovery process know about the new locations of these files. You also have to be careful not to move an archive redo log that is currently being written to. You can use the V$ARCHIVED_LOG view to verify if the file appears there; this means it has been completely archived.

Using the FRA with ASM will also allow you to either move the location or quickly add an additional disk to the FRA disk group.

When the archive redo log files destination is full, you have to scramble to resolve it. This is why a good deal of thought should be done about the architecture of the system for 24/7 production database. This includes monitoring the workload and properly sizing the disks and redo logs.

For most databases, writing the archive redo logs to one location is sufficient. However, if you have any type of disaster recovery or high availability requirements, then you should write to multiple locations. Sometimes, DBAs set up a job to back up the archive redo logs every hour and copy them to an alternate location or even to an alternate server.