Rogerio Antonio

Let's  distillate  a bit the Fast Recovery Area (FRA)   Central location for backup data Logs Archive logs Backups Control file Location (either) ASM filesystem Allow RMAN Retention policies Parameters ( location and size) DB_RECOVERY_FILE_DEST DB_RECOVERY_DEST_SIZE FRA - Maintenance other notes The maintenance is done automatically, and if is properly sized are not expected issues Use the RMAN commands to remove backups and file copies that are not required. If gets full - database stops RMAN> REPORT OBSOLETE  RMAN> DELETE OBSOLETE  Get Info SQL> show parameter DB_RECOVERY_FILE_DEST NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest string /u01/app/oracle/flash_recovery_area db_recovery_file_dest_size big integer 3852M SQL> col name form a30 SQL> col value form a30 SQL> select name, v...

Control file In this post I approach RMAN Configuration, Metadata, Catalogues RMAN always stores its metadata in the target database  control file Whether you use or not the Recovery Catalog Oracle stores metadata into the targer database control file RMAN info on control file is is aged based on CONTROL_FILE_RECORD_KEEP_TIME Single point control ( control file) Does not required another DB Recovery Catalog keep info for long time single point to store many databases RESYNC CATALOG, syncronize the control file metadata with the recover catalog Can store "RMAN backup scripts" in the catalog ... is not possible do it on the control file Recovery Catalog control views RC_* Allow history commands BACKUP .. KEEP UNTIL TIME - keep the backup until point that referrers the configured retention police  BACKUP ... KEEP FOREVER - keep the backup forever, until manually removed REPORT SCHEMA ... AT - show the structure at specific time period Create a RMAN Catalog --1 create tablespace...

English Version Este post saiu da preparacao para o OCP - Oracle Certified Professional . Isto e simples , Oracle trabalha com logs, todos os DMS/DDL vao para a log. chamados redo logs, que sao escritos de forma circular. Para evitar perda de informacao podem ser archivados antes da re-escrita. Entre outras razoes, no caso de necessidade de recuperar a base de dados the forma tradicional sao necessarios 2 passos : 1) Restore - restaurar os data files e control files 2) Recover - Aplicar logs, neste caso convem ter os "archives" De seguida mostro como fazer isso, nota importante, isto deve ser feito com a base de dados em estado consitente. Exemplo, apos um "shutdown immediate". SQL> select startup_time from  v$instance; STARTUP_Time --------- 19-DEC-12 SQL> select dbid,name,log_mode,flashback_on from  v$database;       DBID        NAME       LOG_MODE          FLASHBACK_ON ----------          ---------      ------------               ------------------ 1272...

Versao Portuguesa This post comes out from the practice to learn and preparation the subjects for OCP - Oracle Certified Professional . In simple words, Oracle works with logs, all DMS/DDL are written in log file, know as redo logs, the written happens in circular way. So the files are redo file contents will be replaced, with the transactions. In order to keep that info, Oracle allows to archive the contents. It has a few reasons to archive the redo log, for now let focus on one, teh need of recover the database. I mean some thing happened and is need to put the database back. The traditional method is done in two steps. 1) Restore - restore data files and control files 2) Recover - Apply logs, in this case the archive logs .. and eventually redo log Let's see how to do that, but for now a note, the database should be in mount state and in a consistent manner, eg after a "shutdown immediate". SQL> select startup_time from  v$instance; STARTUP_Time --...