归档日志满处理过程(国外英文资料).docVIP

归档日志满处理过程(国外英文资料) Execute the following two commands: RMAN crosscheck archivelog all; RMAN delete nopromptexpired archivelog all; With the processing above, you can get the system running back to normal. But its not a big deal to clean up the space after this. In general if using RMAN backup plan, is proposed to perform the following a few lines of RMAN command, this might clean up because the backup plan execution causes such as some outdated or repetitive backup file; RMAN crosscheck backup; RMAN delete noprompt expired backup; RMAN delete noprompt obsolete; RMAN resync catalog; In the end, there are two other scenarios: Delete all archived logs a few days ago When an emergency situation occurs, if you are familiar with the database backup scheme, you can also delete all archive logs from a few days prior to the following Rman command. Delete all archive logs 7 days ago: RMAN run { DELETE ARCHIVELOG UNTIL TIME SYSDATE - 7; } RMAN crosscheck archivelog all; RMAN delete noprompt expired archivelog all; UNIX/LINUX also can FIND archived data from 7 days before FIND, using EXEC suboperations Find/archivelog - xdev-mtime + 7-name *.dbf - This still leaves unmanaged archive files in RMAN You still need to execute the following two commands in RMAN RMAN crosscheck archivelog all; RMAN delete expired archivelog all; Db_recovery_file_dest_size parameter Since Oracle10g db_recovery_file_dest_size parameters are commonly used to store the archive log (archivelog) and rman backup set (backupset), the default value is 2 g commonly, when the backup and archive logs over this parameter is also can appear ORA - 19815 error. The solution is to increase the parameter values of db_recovery_file_dest_size: SQL show parameter db_recovery_file_dest_size NAMETYPEVALUE -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --