Redo logs and Flash recovery area

Hi,
Is it a good practice to place a copy of the (multiplexed) online redo at the flash recovery area? Wouldn't it be better to place a copy of the archived log at the flash recovery area?

user492400 wrote:
Hi,
Is it a good practice to place a copy of the (multiplexed) online redo at the flash recovery area? Wouldn't it be better to place a copy of the archived log at the flash recovery area?Its not only the archvielogs that should be placed in the FRA. FRA is supposed to contain one copy of the archive logs and the rest 9 destinations are given to you for the multiplexing of it. The idea of multiplexing the redo logs and placing them anywhere( not just on the FRA itself) is simply required so that you won't get to a situation where you would lose all the redo log files and thus have to recreate them, losing the data inside them. So aleast one copy of the log files should be there and where you want to put it, that would depend on you.
HTH
Aman....

Similar Messages

  • Disk array configurations with oracle redo logs and flash recovery area.

    Dear Oracle users,
    We are planning to buy the new server for oracle database 10g standard edition. We put oracle database file, redo logs, and flash recovery area on each of disk array. My question is what is the best disk array configuration for redo logs and flash recovery area? RAID 10 or RAID 1? Is that possible we can duplicate Flash recovery area to the other location (such as net work drive) at the same time? Since we only have single disk array controller to connect to the disk arrays, I am try to avoid the single failure that will lose archive logs and daily backup.
    thanks,
    Belinda

    Thank you so much for the suggestion. Could you please let me know the answer for my question of FRA redundancy?
    “Is that possible we can duplicate Flash recovery area to the other location (such as net work drive) at the same time? Since we only have single disk array controller to connect to the disk arrays, I am try to avoid the single failure that will lose archive logs and daily backup.”

  • Online redo logs in Flash Recovery Area

    Hi,
    Currently I have redo logs multiplexed on two separate disks. I want to add a new member to each log file group that goes in flash recovery area. What is the easiest way to accomplish this?
    It seems to me that I can only do this by dropping the existing groups and recreating them. If I decide to go this route, what parameters do I need to set so that 3 members are created for each group?
    Thanks

    Simply issue 'alter database add logfile group <n>;', don't specify a location. Assuming 'db_recovery_file_dest' is correctly set this will create an Oracle managed file under <FRA>/onlinelog/<OMF-filename>, something like
    4 ONLINE
    C:\ORACLE\FLASH_RECOVERY_AREA\ORACLE\ONLINELOG\O1_MF_4_5WRBM1C4_.LOG
    GROUP# STATUS TYPE
    MEMBER
    IS_
    YES
    Werner

  • Changing the location of archive log from flash recovery area PLZ HELP!!!

    Hi All,
    My archive log is being stored in flash memory area which got full and the production server went down.
    alert log file details.....
    ORA-19809: limit exceeded for recovery files
    ORA-19804: cannot reclaim 43432960 bytes disk space from 2147483648 limit
    *** 2010-04-25 14:22:49.777 62692 kcrr.c
    ARCH: Error 19809 Creating archive log file to
    '/oracle/product/10.2.0/flash_rec
    overy_area/EDWREP/archivelog/2010_04_25/o1_mf_1_232_%u_.arc'
    *** 2010-04-25 14:22:49.777 60970 kcrr.c
    kcrrfail: dest:10 err:19809 force:0 blast:1I removed the files and started the database,
    Can someone kindly tell me as to how to avoid this problem in future by keeping archive log destination in flash recovery area.
    I want to change the location of archive log files, can someone please guide me as to hiow to do that
    I changed the size of flash recovery area for the time being, but i am afraid it will be full again!!
    SQL> select * from v$flash_recovery_area_usage;
    FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
    CONTROLFILE                   0                         0               0
    ONLINELOG                     0                         0               0
    ARCHIVELOG                99.44                         0              57
    BACKUPPIECE                   0                         0               0
    IMAGECOPY                     0                         0               0
    FLASHBACKLOG                  0                         0               0
    6 rows selected.
    SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE = 4G ;
    System altered.
    SQL> select * from v$flash_recovery_area_usage;
    FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
    CONTROLFILE                   0                         0               0
    ONLINELOG                     0                         0               0
    ARCHIVELOG                49.72                         0              57
    BACKUPPIECE                   0                         0               0
    IMAGECOPY                     0                         0               0
    FLASHBACKLOG                  0                         0               0
    6 rows selected.regards,
    Edited by: user10243788 on Apr 25, 2010 6:12 AM

    user10243788 wrote:
    Hi All,
    My archive log is being stored in flash memory area which got full and the production server went down.
    alert log file details.....
    ORA-19809: limit exceeded for recovery files
    ORA-19804: cannot reclaim 43432960 bytes disk space from 2147483648 limit
    *** 2010-04-25 14:22:49.777 62692 kcrr.c
    ARCH: Error 19809 Creating archive log file to
    '/oracle/product/10.2.0/flash_rec
    overy_area/EDWREP/archivelog/2010_04_25/o1_mf_1_232_%u_.arc'
    *** 2010-04-25 14:22:49.777 60970 kcrr.c
    kcrrfail: dest:10 err:19809 force:0 blast:1I removed the files and started the database,
    Can someone kindly tell me as to how to avoid this problem in future by keeping archive log destination in flash recovery area.
    I want to change the location of archive log files, can someone please guide me as to hiow to do that
    I changed the size of flash recovery area for the time being, but i am afraid it will be full again!!
    SQL> select * from v$flash_recovery_area_usage;
    FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
    CONTROLFILE                   0                         0               0
    ONLINELOG                     0                         0               0
    ARCHIVELOG                99.44                         0              57
    BACKUPPIECE                   0                         0               0
    IMAGECOPY                     0                         0               0
    FLASHBACKLOG                  0                         0               0
    6 rows selected.
    SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE = 4G ;
    System altered.
    SQL> select * from v$flash_recovery_area_usage;
    FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
    CONTROLFILE                   0                         0               0
    ONLINELOG                     0                         0               0
    ARCHIVELOG                49.72                         0              57
    BACKUPPIECE                   0                         0               0
    IMAGECOPY                     0                         0               0
    FLASHBACKLOG                  0                         0               0
    6 rows selected.regards,
    Edited by: user10243788 on Apr 25, 2010 6:12 AMPointing the archive log dest (and/or the FRA) to a new location, or enlarging them, will do no good if you are not performing regular housekeeping on the archivelogs. You will just keep knocking down the same problem over and over.
    If you simply delete the archivelogs at the OS level, the database will never know about it and it will continue to think the destination is full, based on records kept in the control file.
    For regular housekeeping, you need to be doing something similar to this in rman:
    run {
      backup archivelog all not backed up 1 times tag='bkup_vlnxora1_arch';
      delete noprompt archivelog all backed up 1 times to device type disk;
    run {
    delete noprompt obsolete;
    crosscheck archivelog all;
    delete noprompt expired archivelog all;

  • RMAN backups and Flash Recovery Area

    I have Oracle database 10.2.0.4 running on red hat 4.5 box. We are using a recovery catalog.A backup script runs everyday with option keep forever logs and retention policy is set to redendency 2.
    We have Flash recovery area.
    What will be criteria for Flash recovery area files to become obsolete?
    Thanks

    Is that mean that files in FRA are not effected by keep clause?
    To be more specific Files which status is unavailable with RMAN are they eligible for automatic deletion policy in FRA?
    Edited by: user11985663 on Dec 2, 2009 7:28 AM

  • Flash recovery area issue. I can not open the database??

    Hi all
    I am using oracle 11.2.0 .1.0 on windows
    when i tried to start the database I got the following error.
    ORA-03113: end-of-file on communication channel
    I clear out all information in Trace file. I cleared out all operating system level audit trails. then i deleted archivelog files using operating system level delete. still my database is not opening???
    I tried to start this using RMAN but got the same error. now i have deleted the files from flash recovery area how can i let oracle system to know that those are deleted and there is enough space. Rman does not execute crosschek commands at mount state of the database?
    Need solution.
    Regards
    MAlik

    malikdba wrote:
    the last option which ask to delete the files. i already have deleted the files at operating system level. now the issue is how to let the system that the space is free in flash recovery area? rman is not running crosscheck command at mount stage of the target database. What steps should i follow now?
    Thanks
    malik
    Are you saying you are getting an error while trying to crosscheck at mount?  Or you simply don't believe it will work?
    oracle:orcl$ rman target /
    Recovery Manager: Release 11.2.0.2.0 - Production on Thu Jul 11 10:52:48 2013
    Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
    connected to target database (not started)
    RMAN> startup mount;
    Oracle instance started
    database mounted
    Total System Global Area     839282688 bytes
    Fixed Size                     2231128 bytes
    Variable Size                503317672 bytes
    Database Buffers             331350016 bytes
    Redo Buffers                   2383872 bytes
    RMAN> crosscheck archivelog all;
    using target database control file instead of recovery catalog
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: SID=18 device type=DISK
    specification does not match any archived log in the repository
    RMAN>
    A perfectly normal crosscheck at the mount stage

  • Multiplex Redo Logs and Control File

    I am wanting to setup an existing Oracle Express 10g instance to multiplex the redo log files and the control file.
    Instance is using Oracle-Managed Files and the Flash Recovery Area.
    With these options being used what are the steps required to setup multiplexing?
    I tried setting the DB_CREATE_ONLINE_LOG_DEST_1 and DB_CREATE_ONLINE_LOG_DEST_2 parameters but this doesn't appear to have worked (I even bounced the db instance).
    BTW, the DB_CREATE_FILE_DEST is set to null and the DB_RECOVERY_FILE_DEST is set to the flash recovery area.
    Any help is much appreciated.
    Regards, Sheila

    Thanks for this. My instance originally had two log groups so I've added a new member to each group into the same flash recovery area directory, but have assigned a name. Is this why when I query v$logfile the is_recovery_dest_file is set to NO? Is it ok to assign a name & directory and if not, how do you add a new memeber and allow Oracle-Managed files to name them?
    Also, how can I check that the multiplexing is working (ie the database is writing to both sets of files)?
    Thanks again.

  • Multiplexing redo logs and control files to a separate diskgroup

    General question this one...
    I've been using ASM for a few years now and have always installed a new system with 3 diskgroups
    +DATA - for datafiles, control files, redo logs
    +FRA - for achive logs, flash recovery. RMAN backup
    Those I guess are the standards, but I've always created an extra (very small) diskgroup, called +ONLINE where I keep multiplexed copies of the redo logs and control files.
    My reasoning behind this is that if there are any issues with the +DATA diskgroup, the redo logs and control files can still be accessed.
    In the olden days (all those 5 years ago!), on local storage, this was important, but is it still important now? With all the striping and mirroring going on (both at ASM and RAID level), am I just being overtly paranoid? Does this additional +ONLINE diskgroup actually hamper performance? (with dual write overheads that are not necessary)
    Thoughts?

    Some of the decision will probably depend on your specific environment's data activity, volume, and throughput.
    Something to remember is that redo logs are sequential write, which benefit from a lower RAID overhead (RAID-10, 2 writes per IOP vs RAID-5, 4 writes per IOP). RAID-10 is often not cost-effective for the data portion of a database. If your database is OLTP with a high volume of random reads/writes, you're potentially hurting redo throughput by creating contention on the disks sharing data and redo. Again, that depends entirely on what you're seeing in terms of wait events. A low volume database would probably not experience any noticeable degraded performance.
    In my environment, I have RAID-5 and RAID-10 available, and since the RAID-10 requirement from a capacity perspective for redo is very low, it makes sense to create 2 diskgroups for online redo, separate from DATA, and separate from each other. This way, we don't need to be concerned with DATA transactions impacting REDO performance, and vice versa, and we still maintain redo redundancy.
    In my opinion, you can't be too paranoid. :)
    Good luck!
    K

  • How to use Flash recovery area only for flashback database feature

    I would like to use flash recovery area only for flashback database feature, which means, flash recovery area will store only flashback logs.
    I dont want to use that file system for any other files, like archive log files, database backups, control file copies, multiplex redo log, etc
    is it possible? I want to use this feature only for flashback database option and hence i dont want to disturb any existing configuration in my database
    including backup jobs. Is it required to store archive redo log files also in flash recovery area to use the flashback database feature?
    I certainly can't afford to have a copy of entire database in this file system as size of my DB is more than the flash recovery area file system I have.
    Thanks
    Sarayu

    user13312943 wrote:
    Aman,
    I think i was not clear in my question. Let me try again
    My only requirement is to use flashback database feature (or be prepared to use if required). I dont want to create a large file system to use this FRA to store all these files. Out of all the files being stored here copy of data files seems to be consuming more space. I see these files are classified as transient and permanent files. I am okay with permanent files. I fear that this file system may consume more space if i store backup files on disk. I want database backups to go to tapes, not to the FRA disk. Is it possible?
    Thanks for your reply
    Okay, well in that case you can use RMAN and push the backups to the tape drives. FLB logs would be stored on the FRA.
    Aman....

  • Retention policy for archivelogs in the flash recovery area

    I am using the flash recovery area for all my backup files (archive logs, data and control files). I want to use the redundancy retention policy because it is easy to calculate the space requirement. However, I am not clear how the retention policy applies to archive logs.
    Say I set the retention policy to be "keeping 3 backups". How does it affect the archive logs? Will archive logs in the flash recovery area be deleted automatically or I need to do it manually. If they are deleted automatically just like dataset files, what is the "retention policy" for them? I do not have a tape device so all archive logs are going to be stay in disk.
    Thanks.

    I am using the flash recovery area for all my backup
    files (archive logs, data and control files). I want
    to use the redundancy retention policy because it is
    easy to calculate the space requirement. However, I
    am not clear how the retention policy applies to
    archive logs.
    RMAN> show retention policy
    2> ;
    RMAN configuration parameters are:
    CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
    RMAN> report obsolete
    2> ;
    RMAN retention policy will be applied to the command
    RMAN retention policy is set to redundancy 2
    no obsolete backups found
    RMAN> list backup
    2> ;
    RMAN>AS documentation says
    "Besides affecting datafile and control file backups, the retention policy affects archived logs and archived log backups.
    First, RMAN decides which datafile and control file backups are obsolete. Then, RMAN considers as obsolete all archived
    log backups that are older than the oldest datafile or control file backup that must be retained."
    Now i connect to SQL and create two big table for filling the redo log file and then get it archived.Please
    consider it here that i am getting archived before any taking backup i.e backup database in order to make
    archive older then the oldest datafile.
    SQL> show parameter control_file_record_keep_time
    NAME                                 TYPE        VALUE
    control_file_record_keep_time        integer     7
    SQL> create table a1 as select * from all_objects
      2  /
    Table created.
    SQL> create table a2 as select * from all_objects
      2  /
    Table created.
    C:\>dir C:\oracle\product\10.1.0\flash_recovery_area\ORCL\ARCHIVELOG\2008_03_17
    Volume in drive C is khurram
    Volume Serial Number is F49D-FF2B
    Directory of C:\oracle\product\10.1.0\flash_recovery_area\ORCL\ARCHIVELOG\2008_03_17
    03/17/2008  03:44 PM    <DIR>          .
    03/17/2008  03:44 PM    <DIR>          ..
    03/17/2008  03:44 PM         9,750,528 O1_MF_1_15_3XWLVK6T_.ARC
                   1 File(s)      9,750,528 bytes
                   2 Dir(s)  62,714,875,904 bytes free
    Now i take backup
    RMAN> backup database
    2> ;
    Starting backup at 17-MAR-08
    using channel ORA_DISK_1
    RMAN> report obsolete
    2> ;
    RMAN retention policy will be applied to the command
    RMAN retention policy is set to redundancy 2
    no obsolete backups found
    RMAN> backup database
    2> ;
    Starting backup at 17-MAR-08
    using channel ORA_DISK_1
    RMAN> report obsolete
    2> ;
    RMAN retention policy will be applied to the command
    RMAN retention policy is set to redundancy 2
    Report of obsolete backups and copies
    Type                 Key    Completion Time    Filename/Handle
    Archive Log          402    17-MAR-08          C:\ORACLE\PRODUCT\10.1.0\FLASH_RE
    COVERY_AREA\ORCL\ARCHIVELOG\2008_03_17\O1_MF_1_15_3XWLVK6T_.ARCYou can see the obsolete archived files which is the older then the oldest file which has been obsolete.It also
    does'nt make sense to keep the archived log files which is older then the oldest file cause it will no longer
    be useful for recovery process.
    now back to pavillion
    RMAN> delete obsolete
    2> ;
    RMAN retention policy will be applied to the command
    RMAN retention policy is set to redundancy 2
    using channel ORA_DISK_1
    Deleting the following obsolete backups and copies:
    Type                 Key    Completion Time    Filename/Handle
    Archive Log          402    17-MAR-08          C:\ORACLE\PRODUCT\10.1.0\FLASH_RE
    COVERY_AREA\ORCL\ARCHIVELOG\2008_03_17\O1_MF_1_15_3XWLVK6T_.ARC
    Do you really want to delete the above objects (enter YES or NO)? yes
    deleted archive log
    archive log filename=C:\ORACLE\PRODUCT\10.1.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELO
    G\2008_03_17\O1_MF_1_15_3XWLVK6T_.ARC recid=402 stamp=649611842
    Deleted 1 objects
    RMAN> delete backup
    2> ;
    using channel ORA_DISK_1
    RMAN> list backup
    2> ;
    C:\>dir C:\oracle\product\10.1.0\flash_recovery_area\ORCL\ARCHIVELOG\2008_03_17
    Volume in drive C is khurram
    Volume Serial Number is F49D-FF2B
    Directory of C:\oracle\product\10.1.0\flash_recovery_area\ORCL\ARCHIVELOG\2008_
    03_17
    03/17/2008  03:59 PM    <DIR>          .
    03/17/2008  03:59 PM    <DIR>          ..
                   0 File(s)              0 bytes
                   2 Dir(s)  62,724,440,064 bytes freenow this time what i did i created the archived log files after first backup in order to not to make it older
    then the oldest datafile backup.
    RMAN> backup database
    2> ;
    Starting backup at 17-MAR-08
    using channel ORA_DISK_1
    RMAN> report obsolete
    2> ;
    RMAN retention policy will be applied to the command
    RMAN retention policy is set to redundancy 2
    no obsolete backups foundnow i come to at SQL and make redo log file filled by creating 2 big tables in order to get it archived
    SQL> create table a3 as select * from all_objects
      2  /
    Table created.
    SQL> create table a4 as select * from all_objects
      2  /
    Table created.
    C:\>dir C:\oracle\product\10.1.0\flash_recovery_area\ORCL\ARCHIVELOG\2008_03_17
    Volume in drive C is khurram
    Volume Serial Number is F49D-FF2B
    Directory of C:\oracle\product\10.1.0\flash_recovery_area\ORCL\ARCHIVELOG\2008_
    03_17
    03/17/2008  04:09 PM    <DIR>          .
    03/17/2008  04:09 PM    <DIR>          ..
    03/17/2008  04:09 PM         9,751,552 O1_MF_1_16_3XWNCGRS_.ARC
                   1 File(s)      9,751,552 bytes
                   2 Dir(s)  62,563,205,120 bytes free
    RMAN> backup database
    2> ;
    Starting backup at 17-MAR-08
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting compressed full datafile backupset
    channel ORA_DISK_1: specifying datafile(s) in backupset
    RMAN> report obsolete
    2> ;
    RMAN retention policy will be applied to the command
    RMAN retention policy is set to redundancy 2
    no obsolete backups foundYou can see no archived logs get obsolete yet cause the archivelog O1_MF_1_16_3XWNCGRS_.ARC
    is not older then oldest datafile backup.
    But this archivelog file will get obsolete if its beyond the retention policy,lest see how ,just take one more
    backup ,as i have already taken two time backup and the moment i go to take third backup it will cross ours
    retetnion policy from the period of 2.
    RMAN> backup database
    2> ;
    RMAN> report obsolete
    2> ;
    RMAN retention policy will be applied to the command
    RMAN retention policy is set to redundancy 2
    Report of obsolete backups and copies
    Type                 Key    Completion Time    Filename/Handle
    Backup Set           240    17-MAR-08
      Backup Piece       231    17-MAR-08          C:\ORACLE\PRODUCT\10.1.0\FLASH_RE
    COVERY_AREA\ORCL\BACKUPSET\2008_03_17\O1_MF_NNNDF_TAG20080317T160604_3XWN4WTB_.B
    KP
    Backup Set           241    17-MAR-08
      Backup Piece       232    17-MAR-08          C:\ORACLE\PRODUCT\10.1.0\FLASH_RE
    COVERY_AREA\ORCL\BACKUPSET\2008_03_17\O1_MF_NCSNF_TAG20080317T160604_3XWN6Z95_.B
    KP
    Archive Log          403    17-MAR-08          C:\ORACLE\PRODUCT\10.1.0\FLASH_RE
    COVERY_AREA\ORCL\ARCHIVELOG\2008_03_17\O1_MF_1_16_3XWNCGRS_.ARCKhurram

  • Proper layout of datafiles, archivelogs, flash recovery area

    Hi all,
    Sorry a bit of a newb,
    Have a question about how to layout my db files.
    My understanding is that control and archivelog files should be multiplexed to a separate disk than the datafiles.
    Is this also true for the flash_recovery_area?
    Thanks for any help.

    geeter wrote:
    Hi all,
    Sorry a bit of a newb,
    Have a question about how to layout my db files.
    My understanding is that control and archivelog files should be multiplexed to a separate disk than the datafiles.
    Is this also true for the flash_recovery_area?
    Thanks for any help.Lose your control file or your redo file, and you have a problem. Therefore, in a professional environment, the control file and redo logs need to be protected by multiplexing to different physical drives (not different partitions on same disk). One of those locations can be the same DASD as the database files.
    Archivelogs should be bounced from online to nearline to offline storage. These days 'online' is inside flash recovery area. If you are paranoid, you can send archivelogs to multiple destinations (multiplex), although some form of disk protection (RAID 1 ... or 5 - ugh!) should be sufficient.
    Flash Recovery Area can be inside ASM or on regular file system. If in ASM, consider using either RAID 1 under ASM and external failgroups, or normal failgroup mode to allow the system to do it's own RAID 1 equivalent. If on regular file system, use standard disk protection (RAID 1 or 5) to do the protection.
    Oracle uses the SAME (Stripe and Mirror Everything) philosophy, so separating Fast Recovery Area (new name - used to be Flash Recovery Area in the ancient days of Oracle 10g) from database files is not needed.
    Highly recommend you read the first chapter of the Database Concepts Manual and the first chapter of the Database Administrator Guide to get used to the docs, adn then use that as a pringboard (via table of contents) to the sections that answer your question. Start at http://tahiti.oracle.com to get to those docs - they are on the front page of the doc set for your favorite version.

  • Multiplexing Redo Log and maximum protection mode.

    Assume that during writing into redo logs the instance crashes. As a result, members of active redo group are not synchronized, some of them had more data. How Oracle will handle this when instance starts? And there can be case when at startup time some members that had more redo before crash, are lost.
    Now assume that we have standby database with maximum protection mode. After LGWR has written to local redo logs and before writing to standby redo logs, primary instance crashes. In this case standby site lost last transaction.
    Is it correct? Thanks.

    Assume that during writing into redo logs the instance crashes. As a result, members of active redo group are not synchronized, some of them had more data. How Oracle will handle this when instance starts? And there can be case when at startup time some members that had more redo before crash, are lost.
    Members of a particular group are written concurrently by LGWR, all members of a log group will have same data.  If any member of a particular group is lost or not reachable, oracle will read from the available log member during instance recovery.
    Multiplexing Redo Log Files
    http://docs.oracle.com/cd/B19306_01/server.102/b14231/onlineredo.htm#i1006249
    To answer your second question,In this mode no transaction commits on primary unless the redo is also written on atleast one standby database, otherwise primary will go down.
    Check below
    Maximum Protection
    http://docs.oracle.com/cd/B28359_01/server.111/b28294/protection.htm#CHDHFHJI

  • Redo Log and Supplemental Logging related doubts

    Hi Friends,
    I am studying Supplemental logging in detail. Have read lots of articles and oracle documentation about it and redo logs. But couldnot found answers of some doubts..
    Please help me clear it.
    Scenario: we have one table with primary key. And we execute an update query on that table which is not using the primary key column in any clause..
    Question: In this case, does the redo log entry generated for the changes done by update query contain the primary columns values..?
    Question: If we have any table with primary key, do we need to enable the supplemental logging on primary columns of that table? If yes, in which circumstances, do we need to enable it?
    Question: If we have to configure stream replication on that table(having primary key), why do we actually need to enable its supplemental logging ( I have read the documentation saying that stream requires some more information so.., but actually what information does it need. Again this question is highly related to the first question.)
    Also please suggest any good article/site which provide inside details of redo log and supplemental logging, if you know.
    Regards,
    Dipali..

    1) Assuming you are not updating the primary key column and supplemental logging is not enabled, Oracle doesn't need to log the primary key column to the redo log, just the ROWID.
    2) Is rather hard to answer without being tautological. You need to enable supplemental logging if and only if you have some downstream use for additional columns in the redo logs. Streams, and those technologies built on top of Streams, are the most common reason for enabling supplemental logging.
    3) If you execute an update statement like
    UPDATE some_table
      SET some_column = new_value
    WHERE primary_key = some_key_value
       AND <<other conditions as well>>and look at an update statement that LogMiner builds from the redo logs in the absence of supplemental logging, it would basically be something like
    UPDATE some_table
      SET some_column = new_value
    WHERE rowid = rowid_of_the_row_you_updatedOracle doesn't need to replay the exact SQL statement you issued, (and thus it doesn't have to write the SQL statement to the redo log, it doesn't have to worry if the UPDATE takes a long time to run (otherwise, it would take as long to apply an archived log as it did to generate the log, which would be disasterous in a recovery situation), etc). It just needs to reconstruct the SQL statement from the information in redo, which is just the ROWID and the column(s) that changed.
    If you try to run this statement on a different database (via Streams, for example) the ROWIDs on the destination database are likely totally different (since a ROWID is just a physical address of a row on disk). So adding supplemental logging tells Oracle to log the primary key column to redo and allows LogMiner/ Streams/ etc. to reconstruct the statement using the primary key values for the changed rows, which would be the same on both the source and destination databases.
    Justin

  • Flash Recovery Area On 11.5.10.2

    Hello,
    We are running 11.5.10.2 on window 2003 server 32-bit,we save backup on flash_recovery area which size is 91 GB,total file system size on window of flash recovery area is 190GB.When i check the space on file system it show me 84 GB free space,I want to ask then where is 27 GB space,because backupset size is 2.70GB autobackup size is 128 MB and datafile size is 79 GB.
    Please help me out.
    List of Backups
    ===============
    Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
    2745    B  F  A DISK        23-SEP-13       1       1       NO         TAG20130923T233305
    2747    B  F  A DISK        24-SEP-13       1       1       NO         TAG20130924T203609
    2749    B  F  A DISK        26-SEP-13       1       1       NO         TAG20130926T194832
    2751    B  F  A DISK        27-SEP-13       1       1       NO         TAG20130927T214235
    2753    B  F  A DISK        08-OCT-13       1       1       NO         TAG20131008T184055
    2754    B  1  A DISK        09-OCT-13       1       1       NO         ORA\$OEM_LEVEL_0
    2755    B  F  A DISK        09-OCT-13       1       1       NO         TAG20131009T225822
    Regards,
    Merri

    Hello,
    report obsolete show's
    RMAN> report obsolete;
    RMAN retention policy will be applied to the command
    RMAN retention policy is set to redundancy 1
    Report of obsolete backups and copies
    Type                 Key    Completion Time    Filename/Handle
    Backup Set           2745   23-SEP-13
      Backup Piece       2745   23-SEP-13          I:\FLASH_RECOVERY\APPPROD\AUTOBACKUP\C-1628308050-20130923-00
    Backup Set           2747   24-SEP-13
      Backup Piece       2747   24-SEP-13          I:\FLASH_RECOVERY\APPPROD\AUTOBACKUP\C-1628308050-20130924-00
    Backup Set           2749   26-SEP-13
      Backup Piece       2749   26-SEP-13          I:\FLASH_RECOVERY\APPPROD\AUTOBACKUP\C-1628308050-20130926-00
    Archive Log          135874 03-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98760_578172119.DBF
    Backup Set           2751   27-SEP-13
      Backup Piece       2751   27-SEP-13          I:\FLASH_RECOVERY\APPPROD\AUTOBACKUP\C-1628308050-20130927-00
    Archive Log          135876 03-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98761_578172119.DBF
    Archive Log          135878 03-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98762_578172119.DBF
    Archive Log          135880 03-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98763_578172119.DBF
    Archive Log          135882 03-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98764_578172119.DBF
    Archive Log          135884 03-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98765_578172119.DBF
    Archive Log          135886 03-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98766_578172119.DBF
    Archive Log          135888 03-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98767_578172119.DBF
    Archive Log          135890 03-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98768_578172119.DBF
    Archive Log          135892 03-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98769_578172119.DBF
    Archive Log          135894 03-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98770_578172119.DBF
    Archive Log          135896 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98771_578172119.DBF
    Archive Log          135898 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98772_578172119.DBF
    Archive Log          135900 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98773_578172119.DBF
    Archive Log          135902 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98774_578172119.DBF
    Archive Log          135904 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98775_578172119.DBF
    Archive Log          135906 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98776_578172119.DBF
    Archive Log          135908 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98777_578172119.DBF
    Archive Log          135910 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98778_578172119.DBF
    Archive Log          135912 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98779_578172119.DBF
    Archive Log          135914 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98780_578172119.DBF
    Archive Log          135916 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98781_578172119.DBF
    Archive Log          135918 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98782_578172119.DBF
    Archive Log          135920 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98783_578172119.DBF
    Archive Log          135922 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98784_578172119.DBF
    Archive Log          135924 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98785_578172119.DBF
    Archive Log          135926 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98786_578172119.DBF
    Archive Log          135928 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98787_578172119.DBF
    Archive Log          135930 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98788_578172119.DBF
    Archive Log          135932 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98789_578172119.DBF
    Archive Log          135934 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98790_578172119.DBF
    Archive Log          135936 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98791_578172119.DBF
    Archive Log          135938 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98792_578172119.DBF
    Archive Log          135940 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98793_578172119.DBF
    Archive Log          135942 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98794_578172119.DBF
    Archive Log          135944 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98795_578172119.DBF
    Archive Log          135946 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98796_578172119.DBF
    Archive Log          135948 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98797_578172119.DBF
    Archive Log          135950 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98798_578172119.DBF
    Archive Log          135952 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98799_578172119.DBF
    Archive Log          135954 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98800_578172119.DBF
    Archive Log          135956 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98801_578172119.DBF
    Archive Log          135958 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98802_578172119.DBF
    Archive Log          135960 04-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98803_578172119.DBF
    Archive Log          135962 05-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98804_578172119.DBF
    Archive Log          135964 05-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98805_578172119.DBF
    Archive Log          135966 05-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98806_578172119.DBF
    Archive Log          135968 05-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98807_578172119.DBF
    Archive Log          135970 05-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98808_578172119.DBF
    Archive Log          135972 05-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98809_578172119.DBF
    Archive Log          135974 06-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98810_578172119.DBF
    Archive Log          135976 06-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98811_578172119.DBF
    Archive Log          135978 06-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98812_578172119.DBF
    Archive Log          135980 06-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98813_578172119.DBF
    Archive Log          135982 06-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98814_578172119.DBF
    Archive Log          135984 07-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98815_578172119.DBF
    Archive Log          135986 07-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98816_578172119.DBF
    Archive Log          135988 07-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98817_578172119.DBF
    Archive Log          135990 07-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98818_578172119.DBF
    Archive Log          135992 07-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98819_578172119.DBF
    Archive Log          135994 07-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98820_578172119.DBF
    Archive Log          135996 07-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98821_578172119.DBF
    Archive Log          135997 07-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98822_578172119.DBF
    Archive Log          136000 07-OCT-13          F:\******\1_98823_578172119.DBF
    Archive Log          136002 08-OCT-13          F:\\1_98824_578172119.DBF
    Archive Log          136004 08-OCT-13          F:\********\1_98825_578172119.DBF
    Archive Log          136006 08-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98826_578172119.DBF
    Archive Log          136008 08-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98827_578172119.DBF
    Archive Log          136010 08-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98828_578172119.DBF
    Archive Log          136012 08-OCT-13          F:\ARCHIVELOGS\APPPROD\1_98829_578172119.DBF
    Backup Set           2753   08-OCT-13
      Backup Piece       2753   08-OCT-13          I:\FLASH_RECOVERY\APPPROD\AUTOBACKUP\C-1628308050-20131008-00
    NAME
    SPACE_LIMIT
    SPACE_USED
    SPACE_RECLAIMABLE
    NUMBER_OF_FILES
    I:\flash_recovery\
    97710505984
    83336011776
    0
    47
    Regards,
    Merri

  • Changing the location of the Flash Recovery Area

    My flash recovery area is currently on the same disk as the database. The recovery area also has all out backups for the past month. What's steps should I take to change location of the flash recovery area? Do I have to do anything besides changing db_recovery_file_dest? Would I have to update the control files, spfile and so on?
    Thanks in advance,

    you can make the change at pfile or spfile level and stop and restart the database. this should work.

Maybe you are looking for