An archive failure can affect both recovery and availability. This lesson connects the files needed for recovery to the evidence you collect when a required archive copy cannot finish.
Oracle DBA Lesson 13 Part 2 — Find an Archive Destination Problem
How archived redo extends recovery
A usable data-file backup provides starting data. Redo contains subsequent changes. After restoring a file, media recovery applies the required redo to reconstruct changes toward the selected recovery point. Retain the complete required chain and usable recovery metadata. The latest changes may also require online redo.
See recovery concepts.
An archiver process, shown as ARCn, copies a completed online redo sequence into a separate archived file on disk. The original online group stays in the rotation. Archived copies preserve sequences after their online groups are reused.
Automatic instance recovery uses online redo after an instance failure with the required files available. NOARCHIVELOG still supports this recovery. After file loss, its normal recovery choice is restoring a consistent whole-database backup, losing changes made afterward.
See recovery modes.
Enabling ARCHIVELOG is one part of a recovery strategy. Keep usable backups, required redo, recovery metadata, and tested recovery procedures.
Why an archive problem can hold up writes
Consider group 1, sequence 101, with its instance-recovery requirement already resolved. Its required archive copy remains pending. The destination cannot accept the file. Writing can continue in other available groups. When rotation needs group 1 again, its outstanding archive requirement can prevent reuse and eventually stall new writes.
Determine required copies from the configured mandatory destinations and the minimum-success setting. All enabled mandatory requirements apply. The minimum can also require eligible optional local copies. Assess the failed destination against that configuration.
Collect evidence
SELECT log_mode FROM v$database;LOG_MODE reports ARCHIVELOG, NOARCHIVELOG, or MANUAL. This lesson uses ARCHIVELOG with automatic archiving.
See V$DATABASE.
SELECT dest_id, status, destination, error
FROM v$archive_dest_status
WHERE status <> 'INACTIVE'
ORDER BY dest_id;DEST_ID identifies the destination. DESTINATION gives its configured target. Preserve ERROR exactly, with the observation time. The filter removes entries with no destination information. Failed and deferred entries remain. VALID means initialized and available. ERROR indicates an open/copy error. DEFERRED is manually disabled. FULL means the destination quota is exceeded.
Destination 1 targets USE_DB_RECOVERY_FILE_DEST and reports ORA-19809, "limit exceeded for recovery files." Investigate the recovery-area quota and the underlying storage. Correlate the exact error with the alert log. Other errors can direct investigation to storage access, connectivity, or configuration.
See recovery-area maintenance.
SELECT name, space_limit, space_used, space_reclaimable
FROM v$recovery_file_dest;NAME identifies the recovery location. The space fields are bytes. SPACE_LIMIT is the configured quota. SPACE_USED reports recovery-file usage. SPACE_RECLAIMABLE is potentially recoverable space from eligible files. If NAME is unset, or no applicable configured area is reported, follow the actual archive destination to its storage.
See V$RECOVERY_FILE_DEST.
The capacity example is a 20 GB limit, 19.8 GB used, and 0.1 GB reclaimable. GB here means 1,000,000,000 bytes. Immediate quota headroom is 0.2 GB. Eligible reclaimable space is assessed separately. Reclaimable files still occupy space until reclaimed.
Choose the next action while preserving recovery
The fast recovery area is Oracle-managed physical storage for recovery files, which can include archived redo and backups. Its quota and actual storage capacity both matter. Increasing a quota requires sufficient real capacity.
See recovery-area configuration.
Reclaimability depends on recovery, retention, and remaining log-consumer requirements. Diagnose access or capacity problems. Arrange any backup or offload and policy-aware RMAN cleanup with the responsible administrator. Do not remove archived logs through operating-system commands as a space shortcut. After a correction, confirm that destination errors clear as appropriate, that archiving advances, and that reuse resumes.
See recovery-area maintenance.
Recap
A usable backup supplies starting data, and redo carries later changes toward the selected recovery point. The latest changes may also require online redo. Enabling ARCHIVELOG does not replace usable backups, required redo, recovery metadata, or tested recovery procedures. NOARCHIVELOG still supports instance recovery when the required files are available. After file loss, its normal choice is a consistent whole-database restore, which loses later changes. ARCn copies a completed online sequence into a separate file and leaves the online group in the rotation. If a required archive copy stays pending, reuse of that group can wait and eventually stall new writes. Required copies come from the enabled mandatory destinations and the minimum-success setting, which can also include eligible optional local copies. Collect log mode, destination identity, status, and the exact error, then recovery-area quota, usage, and reclaimable space. Quota headroom and underlying storage are separate limits. Do not remove archived logs with operating-system commands. After a correction, confirm that destination errors clear, archiving advances, and reuse resumes.
No comments:
Post a Comment