Online Redo Log groups

Dear All,
How to check the health of redo log file, we have 200 MB undo tablespace in our production server is it enough for huge transactions. Can I check how much time my redo log file data have been overwritten?
Further in which situation we will add Online Redo Log Groups and which situation we will add Log Members.
My rollback segment is using System tablespace is it recommended?
What is recommendation about 1 redo log group is redo log member or 1 redo log group is multiple redo log members.

Thanks Mr. Nicolas. for your informative guidence.
Can I check how much time my redo log file data have been overwritten?Check v$loghist.
We have 218 records in v$loghist, it means 218 times data have been overwritten, i think its not good. Can you guide me how to rectyify this.
in which situation we will add Online Redo Log GroupsIn case of checkpoint not complete reported into alert.log.
How to findout checkpoint entry in alert.log
which situation we will add Log Members.This is the redolog multiplexing, at least two members for each redolog group.
Ok, Can we do multiplexing for members or just do for groups.
My rollback segment is using System tablespace is it recommended?No.
OK, can we change rollback segments tablespace.
1 redo log group is redo log member or 1 redo log group is multiple redo log membersA minimum of two redolog group with two members for each.
After, it depend of your db activity.
We have just one member for each group and we have three groups, so whats ur recommnedation we will add 1 member in each group.

Similar Messages

  • Online redo log group needed??

    hey guys!
         Am about to recreate the clone file of the clone db, open it using recover it until cancel using backup controlfile and apply all necessary archive logs!
    My question is, does ai need to have online redo log group of the production db? since ai have all the archive log, so ai think while recraeting the control file, online redo log group will be created too?
    Thanks!

    while recraeting the control file, online redo log group will be created tooWhile creating control file, online redo log group doesn't get created. After applying all the archivel logs you have to open the database with RESET LOG option and then oracle will create redo logs for you.
    Best of Luck !!
    Daljit Singh

  • Abot loss online Redo log group

    Hi,
    Is there different from recovering between loss CURRENT online redo log group and ACTIVE online redo log group?
    Both of them are needed to incomplete recovery, right?

    For CURRENT redolog recovery:
    startup mount
    recover database until cancel;
    alter database open resetlogs;
    For ACTIVE redolog recovery:
    If the database is still running, force a checkpoint by issuing the following command:
    alter system checkpoint;
    If above was successful and if the lost group has been archived then issue:
    alter database clear logfile group <number of the online redo log group>;
    And if the lost group has NOT been archived then issue:
    alter database clear logfile unarchived group <number of the online redo log group>;
    alter database open;
    If the database is not running (crashed) then
    startup mount
    recover database until cancel;
    alter database open resetlogs;
    Daljit Singh

  • The file structure online redo log, archived redo log and standby redo log

    I have read some Oracle documentation for file structure and settings in Data Guard environment. But I still have some doubts. What is the best file structure or settings in Oracle 10.2.0.4 on UNIX for a data guard environment with 4 primary databases and 4 physical standby databases. Based on Oracle documents, there are 3 redo logs. They are: online redo logs, archived redo logs and standby redo logs. The basic settings are:
    1. Online redo logs --- This redo log must be on Primary database and logical standby database. But it is not necessary to be on physical standby database because physical standby is not open. It doesn't generate redo log. However, if don't set up online redo log on physical standby, when primary failover and switch standby as primary. How can standby perform without online redo logs? In my standby databases, online redo logs have been set up.
    2. Archived redo logs --- It is obviously that primary database, logical and physical standby database all need to have this log file being set up. Primary use it to archive log files and ship to standby. Standby use it to receive data from archived log and apply to database.
    3. Standby redo logs --- In the document, it says A standby redo log is similar to an online redo log, except that a standby redo log is used to store redo data received from another database. A standby redo log is required if you want to implement: The maximum protection and maximum availability levels of data protection and Real-time apply as well as Cascaded destinations. So it seems that this standby redo log only should be set up on standby database, not on primary database. Am my understanding correct? Because I review current redo log settings on my environment, I have found that Standby redo log directory and files have been set up on both primary and standby databases. I would like to get more information and education from experts. What is the best setting or structure on primary and standby database?

    FZheng:
    Thanks for your input. It is clear that we need 3 type of redo logs on both databases. You answer my question.
    But I have another one. In oracle ducument, it says If you have configured a standby redo log on one or more standby databases in the configuration, ensure the size of the current standby redo log file on each standby database exactly matches the size of the current online redo log file on the primary database. It says: At log switch time, if there are no available standby redo log files that match the size of the new current online redo log file on the primary database. The primary database will shut down
    My current one data gurard envirnment setting is: On primary DB, online redo log group size is 512M and standby redo log group size is 500M. On the standby DB, online redo log group size is 500M and standby redo log group size is 750M.
    This was setup by someone I don't know. Is this setting OK? or I should change Standby Redo Log on standby DB to 512M to exactly meatch with redo log size on primary?
    Edited by: 853153 on Jun 22, 2011 9:42 AM

  • Redo Log Groups

    Call me stupid, but for some reason I've decided to get certified as a DBA even though I have always been a developer. Honestly, its not my fault. The choices in the development track are pretty boring...
    Anyway, while pouring through the Backup/Recovery documentation, I run across this:
    Every database must have at least two online redo log groups.
    Each redo log group contains at least one online redo log member,
    which is a physical file containing the redo records.I decided to check and see if I have "at least two online redo log groups" for my play database. Now, I am very very confused.
    I think this query shows my 3 log members, but for some reason the 1st column makes me think I have 3 log groups:
    select group#, member from v$logfile
        GROUP# MEMBER
             3 /var/opt/oracle/oradata/db92/redo03.log
             2 /var/opt/oracle/oradata/db92/redo02.log
             1 /var/opt/oracle/oradata/db92/redo01.logI only know of one place where my online redo is located:
    ls $ORACLE_BASE/oradata/db92
    redo01.log  redo02.log  redo03.logCan someone help me figure out if I have one-group and three-members??
    Any comments are welcome,
    Stan

    This information can help you:
    Adding Redo Log File Groups: Examples
    The following statement adds a redo log file group with two members and identifies it with a GROUP parameter value of 3:
    ALTER DATABASE
    ADD LOGFILE GROUP 3
    ('diska:log3.log' ,
    'diskb:log3.log') SIZE 50K;
    The following statement adds a redo log file group containing two members to thread 5 (in a Real Application Clusters environment) and assigns it a GROUP parameter value of 4:
    ALTER DATABASE
    ADD LOGFILE THREAD 5 GROUP 4
    ('diska:log4.log',
    'diskb:log4:log');
    Dropping Log File Members: Example
    The following statement drops one redo log file member added in the previous example:
    ALTER DATABASE
    DROP LOGFILE MEMBER 'diskb:log3.log';
    The following statement drops all members of the redo log file group 3:
    ALTER DATABASE DROP LOGFILE GROUP 3;
    Adding Redo Log File Group Members: Example
    The following statement adds a member to the redo log file group added in the previous example:
    ALTER DATABASE
    ADD LOGFILE MEMBER 'diskc:log3.log'
    TO GROUP 3;
    Renaming a Log File Member: Example
    The following statement renames a redo log file member:
    ALTER DATABASE
    RENAME FILE 'diskc:log3.log' TO 'diskb:log3.log';
    The preceding statement only changes the member of the redo log group from one file to another. The statement does not actually change the name of the file 'diskc:log3.log' to 'diskb:log3.log'. You must perform this operation through your operating system.
    Joel P�rez

  • Unable to drop a Redo Log Group

    Hi,
    My database is running on version 11.1.0.7 on OEL platform.
    I am trying to delete one of the Active Redo Log Group, it fails with the below error. Could someone please help me fix this issue?
    SQL >  select * from v$log;
        GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARCHIVED  STATUS                                           FIRST_CHANGE# FIRST_TIME
            10          1       8017  524288000          2 YES       INACTIVE                                            1.2120E+13 17-JUN-2012 19:43:49
            11          1       8018  524288000          2 YES       INACTIVE                                            1.2120E+13 18-JUN-2012 06:49:45
            12          1       8019  524288000          2 YES       INACTIVE                                            1.2120E+13 18-JUN-2012 16:56:43
            13          1       8021  524288000          2 YES       INACTIVE                                            1.2120E+13 18-JUN-2012 23:18:07
            14          1       8020  524288000          2 YES       INACTIVE                                            1.2120E+13 18-JUN-2012 23:14:27
            15          1       8022  524288000          2 NO        CURRENT                                             1.2120E+13 19-JUN-2012 01:07:27
            16          2       6835  524288000          2 YES       INACTIVE                                            1.2120E+13 18-JUN-2012 23:15:46
            17          2       6836  524288000          2 YES       INACTIVE                                            1.2120E+13 18-JUN-2012 23:18:04
            18          2       6837  524288000          2 YES       INACTIVE                                            1.2120E+13 18-JUN-2012 23:20:22
            19          2       6838  524288000          2 YES       INACTIVE                                            1.2120E+13 18-JUN-2012 23:22:38
            20          2       6839  524288000          2 NO        CURRENT                                             1.2120E+13 19-JUN-2012 01:07:24
            21          2       6832  524288000          2 YES       INACTIVE                                            1.2120E+13 18-JUN-2012 23:11:45
            22          3       3771  524288000          2 YES       INACTIVE                                            1.2103E+13 09-SEP-2011 22:04:11
            23          3       3772  524288000          2 YES       INACTIVE                                            1.2103E+13 09-SEP-2011 23:55:55
            24          3       3773  524288000          2 YES       ACTIVE                                              1.2103E+13 09-SEP-2011 23:55:59
            25          3       3766  524288000          2 YES       INACTIVE                                            1.2103E+13 08-SEP-2011 22:05:29
            26          3       3767  524288000          2 YES       INACTIVE                                            1.2103E+13 08-SEP-2011 22:05:50
            27          3       3768  524288000          2 YES       INACTIVE                                            1.2103E+13 09-SEP-2011 14:02:05
    SQL > archive log list;
    Database log mode              Archive Mode
    Automatic archival             Enabled
    Archive destination            /archive/MYCSMA/MYCSMA2
    Oldest online log sequence     6832
    Next log sequence to archive   6839
    Current log sequence           6839
    SQL > archive log all;
    ORA-00271: there are no logs that need archiving
    SQL > ALTER SYSTEM ARCHIVE LOG GROUP 24;
    ALTER SYSTEM ARCHIVE LOG GROUP 24
    ERROR at line 1:
    ORA-16013: log 24 sequence# 3773 does not need archiving
    SQL > alter database drop LOGFILE  group 24;
    alter database drop LOGFILE  group 24
    ERROR at line 1:
    ORA-01623: log 24 is current log for instance MYCSMA3 (thread 3) - cannot drop
    ORA-00312: online log 24 thread 3: '/u247/oradata/MYCSMA/redo24_1.log'
    ORA-00312: online log 24 thread 3: '/u247/oradata/MYCSMA/redo24_2.log'This was previously a 3 node RAC and when it was moved to a different machine, it got build with a 2-node RAC.
    Hence thread 3 is no more required. Thats why I am planning to drop these Redo Log Groups.
    Thanks!

    Hi;
    All information cover at:
    NOTE:102995.1 - Maintenance of Online Redo Log Groups and Members
    Regard
    Helios

  • Can we use online redo log to recover lost datafile in NOARCHIVE mode?

    I am working on OCA exam and confued about these 2 sample questions. (similar questions with totally different answer)
    Please give me hint about the different between these 2 questions.
    ** If the database is in NOARCHIVELOG mode, and one of the datafile for tablespace USERS is lost, what kind of recovery is possible? (answer: B)
    A. All transactions except those in the USERS tablespace are recoverable up to the loss of the datafile.
    B. Recovery is possible only up to the point in time of the last full database backup.
    C. The USERS tablespace is recoverable from the online redo log file as long as none of the redo log files have been reused since the last backup.
    D. Tablespace point in time recovery is available as long as a full backup of the USERS tablespace exists.
    ** The database of your company is running in the NOARCHIVELOG mode. You perform a complete backup of the database every night. On Monday morning, you lose the USER1.dbf file belonging to the USERS tablespace. Your database has four redo log groups, and there have been two log switches since Sunday night's backup.
    Which is true (answer: B)
    A. The database cannot be recovered.
    B. The database can be recovered up to the last commit.
    C. The database can be recovered only up to the last completed backup.
    D. The database can be recovered by performing an incomplete recovery.
    E. The database can be recovered by restoring only the USER!.dbf datafile from the most recent backup.

    I think Gaurav is correct, you can recover to the last commit even in NOARCHIVELOG, as long as all the changes in the redo logs have not been overwritten. So answer should be B for question 2.
    Here is my test:
    SQL> select log_mode from v$database;
    LOG_MODE
    NOARCHIVELOG
    SQL> select tablespace_name, file_name from dba_data_files;
    TABLESPACE_NAME
    FILE_NAME
    USERS
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA101RC\USERS01.DBF
    SYSAUX
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA101RC\SYSAUX01.DBF
    UNDOTBS1
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA101RC\UNDOTBS01.DBF
    SYSTEM
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA101RC\SYSTEM01.DBF
    DATA
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA101RC\DATA01.DBF
    SQL> create table names
    2 ( name varchar(16))
    3 tablespace users;
    Table created.
    so this segment 'names' is created in the datafile users01.
    At this point I shut down and mount the DB, then:
    RMAN> backup database;
    channel ORA_DISK_1: backup set complete, elapsed time: 00:00:29
    Finished backup at 06-OCT-07
    SQL>alter database open
    SQL> insert into names values ('pippo');
    1 row created.
    SQL> commit;
    Commit complete.
    SQL>shutdown immediate;
    Database closed.
    Database dismounted.
    ORACLE instance shut down.
    At this point I delete datafile users01 and restart:
    SQL> startup
    ORACLE instance started.
    Total System Global Area 167772160 bytes
    Fixed Size 1247900 bytes
    Variable Size 67110244 bytes
    Database Buffers 96468992 bytes
    Redo Buffers 2945024 bytes
    Database mounted.
    ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
    ORA-01110: data file 4: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA101RC\USERS01.DBF'
    restoring the backup taken before inserting the value 'pippo' in table names:
    RMAN> restore database;
    Starting restore at 06-OCT-07
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting datafile backupset restore
    channel ORA_DISK_1: specifying datafile(s) to restore from backup set
    restoring datafile 00001 to C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA101RC\SYSTEM01.D
    BF
    restoring datafile 00002 to C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA101RC\UNDOTBS01.
    DBF
    restoring datafile 00003 to C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA101RC\SYSAUX01.D
    BF
    restoring datafile 00004 to C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA101RC\USERS01.DB
    F
    restoring datafile 00005 to C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA101RC\DATA01.DBF
    channel ORA_DISK_1: reading from backup piece C:\ORACLE\PRODUCT\10.2.0\DB_1\DATA
    BASE\0AITR52K_1_1
    channel ORA_DISK_1: restored backup piece 1
    piece handle=C:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\0AITR52K_1_1 tag=TAG20071006
    T181337
    channel ORA_DISK_1: restore complete, elapsed time: 00:02:07
    Finished restore at 06-OCT-07
    RMAN> recover database;
    Starting recover at 06-OCT-07
    using channel ORA_DISK_1
    starting media recovery
    media recovery complete, elapsed time: 00:00:05
    Finished recover at 06-OCT-07
    SQL> alter database open;
    Database altered.
    SQL> select * from names;
    NAME
    pippo
    SQL>
    enrico

  • Online redo log files being removed physically

    Grid Infra version: 11.2.0.4
    RDBMS Version: 11.2.0.4
    Although this is a RAC DB, this is not a RAC-specific question. Hence posting it here.
    Few months back, I remember issuing a command similair to below (DROP LOGFILE GROUP ...) and the redo log files were still physically present in the diskgroup.
    If I remember correctly, the file is not deleted physical so that we can use the REUSE functionality (ALTER DATABASE ADD LOGFILE MEMBER '+REDO/orcl/onlinelog/redo1b.log' reuse to group 11; ) ie. you can use the REUSE command to add the logfile of the same name which is physically present in OS Filesystem/Diksgroup to redo log group.
    But today, after I issued the below command, I checked the diskgroup location from ASMCMD
    SQL> alter database drop logfile group 31;
    Database altered.
    From ASMCMD, I can that the file has disappeared physically. Is this a new feature with 11.2.0.4 or am I missing something here ?
    ASMCMD> ls +DATA/msblprd/onlinelog/group_31.548.833154995
    ASMCMD-8002: entry 'group_31.548.833154995' does not exist in directory '+DATA/msblprd/onlinelog/'

    Just to add to what Aman has said.
    It is a bad practice not to let OMF decide the placement of Online redo logs because of this issue especially when you use ASM.
    Executing rm command in Linux/Unix is easy but Dropping ASM aliases in the disk group can be a hassle.
    This is documented.
    "When a redo log member is dropped from the database, the operating system file is not deleted from disk. Rather, the control files of the associated database are updated to drop the member from the database structure. After dropping a redo log file, ensure that the drop completed successfully, and then use the appropriate operating system command to delete the dropped redo log file."
    http://docs.oracle.com/cd/E11882_01/server.112/e25494/onlineredo.htm#ADMIN11324
    BTW . You don't even need to set  db_create_online_log_dest_n to enable OMF for ORLs.
    SQL> show parameter log_dest
    NAME                                 TYPE        VALUE
    db_create_online_log_dest_1          string
    db_create_online_log_dest_2          string
    db_create_online_log_dest_3          string
    db_create_online_log_dest_4          string
    db_create_online_log_dest_5          string
    SQL> show parameter db_create_file_dest
    NAME                                 TYPE        VALUE
    db_create_file_dest                  string      +MBL_DATA
    alter database add logfile thread 4
    group 31 ('+MBL_DATA','+MBL_FRA') size 4096M,
    group 32 ('+MBL_DATA','+MBL_FRA') size 4096M,
    group 33 ('+MBL_DATA','+MBL_FRA') size 4096M,
    group 34 ('+MBL_DATA','+MBL_FRA') size 4096M ;
    Database altered.
    And redo logs will be neatly placed as shown below
       INST     GROUP# MEMBER                                             STATUS           ARC
             4         31 +MBL_DATA/bsblprd/onlinelog/group_31.276.832605441 UNUSED           YES
                          +MBL_FRA/bsblprd/onlinelog/group_31.297.832605445  UNUSED           YES
                       32 +MBL_DATA/bsblprd/onlinelog/group_32.547.832605451 UNUSED           YES
                          +MBL_FRA/bsblprd/onlinelog/group_32.372.832605457  UNUSED           YES
                       33 +MBL_DATA/bsblprd/onlinelog/group_33.548.832605463 UNUSED           YES
                          +MBL_FRA/bsblprd/onlinelog/group_33.284.832605469  UNUSED           YES
                       34 +MBL_DATA/bsblprd/onlinelog/group_34.549.832605475 UNUSED           YES
                          +MBL_FRA/bsblprd/onlinelog/group_34.359.832605481  UNUSED           YES

  • Physical Standby Online Redo log  files,

    Hi,
    I'm trying to create a physical standby database (10.2.0.3). I'm a little confused about the requirement for online redo logs on the standby.
    in my standby alert log I get the following when I issue:
    SQL> alter database recover managed standby database disconnect from session
    "ORA-00313: open failed for members of log group 1 of thread 1
    ORA-00312: online log 1 thread 1: '/appl/oradata/prod/prod_1_redo_01_02.log'
    ORA-27037: unable to obtain file status
    SVR4 Error: 2: No such file or directory
    Additional information: 3"
    /appl/oradata/prod/prod_1_redo_01_02.log is the path to the location of the online redo logs on the production system. This file does not exist on the standby filesystem so the error is correct.
    I assume that it gets this information from the standby control file I created on the production system and copied over to the standby.
    Do I need to copy the online redo logs from the primary over to the standby site or do I need to create online redo logs on the standby?
    Does the standby need to have redo log files?
    I'm not talking about 'standby log files' of the type created using 'alter database add standby log file'. I've not got that far yet.
    I just need to establish if a physical standby requires online redo log files?
    Thanks in advance,
    user234564

    I wanted to update this thread since I've been dealing with the exact same errors. The basic question is: "does a physical standby need the online redo logs?"
    Answer: Not really, until one wants to switchover or failover (and become a primary database). Furthermore, whenever the MRP process is started, Oracle prepares for a possible switchover/failover by "clearing" the online redo logs (MetaLink note# 352879.1). It is not a big deal, since Oracle will build the actual redo files when the "alter database open resetlogs" is accomplished during a "role transition."
    In our situation, we have decided to use our standby for nightly exports. We stop MRP, open the database read-only, then restart MRP. We built these standby DBs with RMAN. The RMAN duplicate process will not build the online redo log files until the database is opened for read/write (with resetlogs). However, we haven't had a need for read/write (i.e. a switchover).
    Thus, every morning we have been getting the same errors that "user234564" posted above. At first the errors seemed scary, then we realized they were just a nusiance. In order to clean things up, all I did was just "cp" our stanby redo logs (SRL) into our online redo directories ensuring the names matched what was in v$logfile. When I restarted MRP, the alert log clearly showed Oracle clearing these "newly found" online redo logs.

  • Online redo logs on a physical standby?

    A question on REDO logs on physical standby databases. (10.2.0.4 db on Windows 32bit)
    My PRIMARY has 3 ONLINE REDO groups, 2 members each, in ..ORADATA\LOCP10G
    My PHYSICAL STANDBY has 4 STANDBY REDO groups, 2 members each, in ..ORADATA\SBY10G
    I have shipping occurring from the primary in LGWR, ASYNC mode - max availablility
    However I notice the STANDBY also has ONLINE REDO logs, same as the PRIMARY, in the ..ORADATA\SBY10G folder
    According to the 10g Dataguard docs, section 2.5.1:
    "Physical standby databases do not use an online redo log, because physical standby databases are not opened for read/write I/O."
    I have tried to drop these on the STANDBY when not in apply mode, but I get the following:
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
    Database altered.
    SQL> ALTER DATABASE DROP LOGFILE GROUP 3;
    ALTER DATABASE DROP LOGFILE GROUP 3
    ERROR at line 1:
    ORA-01275: Operation DROP LOGFILE is not allowed if standby file management is
    automatic.
    I also deleted them while the STANDBY instance was idle, but it recreated them when moved to MOUNT mode.
    So my question is why is my PHYSICAL recreating and using these, if the docs say the shouldn't?
    I saw the same error mentioned here: prob. with DataGuard
    Is this a case of the STANDBY needing at least a notion of where the REDO logs will need to be should a failover occur, and if the files are already there, the standby database CONTROLFILE will hold onto them, as they are not doing any harm anyway?
    Or, is this a prooduct of having management=AUTOMATIC - i.e. the database will create these 'automatically'
    Ta
    bt

    According to the 10g Dataguard docs, section 2.5.1:
    "Physical standby databases do not use an online redo log, because physical standby databases are not opened for read/write I/O."yes, those are used when database is open.
    You should not perform any changes in Standby. Even if those exist online redo log files, whats the difficulty you have seen?
    These will be used whenever you performed switchover/failover. So nothing to worry on this.
    Is this a case of the STANDBY needing at least a notion of where the REDO logs will need to be should a failover occur, and if the files are already there, the standby database CONTROLFILE will hold onto them, as they are not doing any harm anyway?Then oracle functionality itself harm if you think in that way. When they not used in open then what the harm with that?
    Standby_File_management --> for example if you add any datafile, those information will be in archives/redos once they applied on standby those will be added automatically when it is set to AUTO if its manual, then it creates a unnamed file in $ORACLE_HOME/dbs location later you have to rename that file and recovery need to perform .
    check this http://docs.oracle.com/cd/B14117_01/server.101/b10755/initparams206.htm
    HTH.

  • Commit Completes although current online redo log file have been removed.

    Although i have removed current online redo log file in linux os (Oracle Linux),when i type "commit" it says that "commit complete".
    Is this fair for this princip?*:" if Only when all redo records associated with a given transaction are safely on disk in the online logs is the user process notified that the transaction has been committed."*
    I think that it can lead to loss of data in some cases..I'm using Oracle 11g R2 on OEL (x64)..
    Can anyone explain me ? I'm getting stuck in this situation..
    P.S : I haven't multiplexed current ORL group files...

    Javid wrote:
    Although i have removed current online redo log file in linux os (Oracle Linux),when i type "commit" it says that "commit complete".
    Is this fair for this princip?*:" if Only when all redo records associated with a given transaction are safely on disk in the online logs is the user process notified that the transaction has been committed."*
    I think that it can lead to loss of data in some cases..I'm using Oracle 11g R2 on OEL (x64)..
    Can anyone explain me ? I'm getting stuck in this situation..
    In *nix, a file that is open by a process isn't really deleted until the process that has it completes.  So even though you 'deleted' a redo log, oracle is still holding it.  As soon as you stop your database (maybe even as soon as the db does a log switch) the redo will really be gone and no longer available.  consider the implications for archive logging.
    P.S : I haven't multiplexed current ORL group files...You need to fix that. the online logs are the achilles heel of the database. That's why it is standard practice to multiplex them.

  • Adding online redo logs with standby database in place

    Hi group,
    I have decided to add one new member to my existing redo log groups and an additional redo log group to my primary database.
    That change went ok without problems. I assumed that with standby_file_management=auto the equivalent online redo logs are created on the standby database. But this is not the case.
    The documentation is unclear about this point and I did not find anything suitable on metalink. The docs suggest to cancel managed recovery on the standy, setting standby_file_management to MANUAL and then adding online logs, quote:
    "To add an online redo log, use a SQL statement such as this:
    SQL> ALTER DATABASE ADD STANDBY LOGFILE 'prmy3.log' SIZE 100K;"
    This however - IMO - adds a new STANDBY redo log to the standby database, what I need is an ONLINE redo log.
    Does anybody have some experience to share here?
    Facts:
    Solaris 8
    Oracle 9.2.0.6
    Thanks!
    Martin

    OK, for those who come across the same problem.
    You need to create a new standby controlfile, copy it as well as any new online redo log from production to the standby environment.
    Once the files are in place, start the standby as normal and open it read only to see if everything is ok:
    startup nomount
    alter database mount standby database;
    alter database open read only
    Only when there are no errors in your alert.log you are safe.
    Martin

  • Multiplexing Online redo logs, archive logs, and control files.

    Currently I am only multiplexing my control files and online redo logs, My archive logs are only going to the FRA and then being backed up to tape.
    We have to replace disks that hold the FRA data. HP says there is a chance we will have to rebuild the FRA.
    As my archive logs are going to the FRA now, can I multiplex them to another disk group? And if all of the control files, online redo logs and archive logs are multiplexed to another disk group, when ASM dismounts the FRA disk group due to insufficient number of disks, will the database remain open and on line.
    If so then I will just need to rebuild the ASM volumes, and the FRA disk group and bring it to the mount state, correct?
    Thanks!

    You can save your online redo logs and archive logs anywhere you want by making use of of init params create_online_log_dest and log_archive_dest_n. You will have to create new redo log groups in the new location and drop the ones in the FRA. The archive logs will simply land wherever you designate with log_archive_dest_n parameters. Moving the control files off FRA is a little trickier because you will need to restore your controlfile to a non-FRA destination and then shutdown your instance, edit the control file param to reflect changes and restart.
    I think you will be happier if you move everything off the FRA diskgroup before dismounting it, and not expecting the db to automagically recover from the loss of files on the FRA.

  • Online redo logs vs backup

    Below quoted sentence is from Oracle documentation
    "Online redo logs, unlike archived logs, should never be backed up. The chief danger
    associated by having backups of online redo logs is that you may accidentally restore
    those backups without meaning to, and corrupt your database"
    Can any one explain , how the database will be corrupted if we backup online redo logs. I am having a hard time to understand this quote
    thanks for your help
    shajan

    Redo log file contents is very dynamic. It changes minute after minute, so a backup is useless if you try to do it online. (In fact there is no command to perform such backup).
    Let's suppose you shutdown (normal, immediate or transactional) The contents of the redo log files become useless as the checkpoint process has already taken place, so it is enough to have a copy of all of the consistent datafiles to have the last applied transaccion.
    In a recovery scenario with archivelog it is important to keep all of the requiered archivelog files plus all of the online redo log files.
    In case of a missing logfile it is useless to have a backup of it. If you ever had one, and you tried to restore it, an error would arise, warning you that the contents of the logfile is inconsistent with the expected scn. The only way you can succeed is to have them multiplexed and have them on different paths, just to reduce to probability of loosing all of the members of a group.
    rman does not perform backup of redo log files. Classical theory of backup/recovery states that during a hot backup it must be backed up the archive log files, not the redo log files.

  • Online redo logs vs standby redo logs

    Hi All,
    Oracle version : 10.2.0.4
    OS : SunOS 5.10 Generic_118855-36 i86pc i386 i86pc
    This might be a silly question for the experts :(
    We are having 2 standby databases and 1 logical database. Everything is running fine , I have one confusion : My primary server having 3 online redo log files and 3 standby redo log files (on primary local), but as per the architecture standby redo logs should be on standby server.My question is whether standby redo logs on standby are online redo logs of standby server or standby redo logs of primary server. e.g If i perform a log switch on primary then what is the role of sync and affirm, will lgwr write parallel on online redo logs ,standby redo logs (of primary) or online redo logs (of primary) and online redo logs (which is known as standby redo logs on standby ). Please help me to understand the scenerio.
    Thanks in advance!

    RFS receives redo information from the primary database.
    RFS can write the redo into standby redo logs or directly to archived redo logs. Each LNSn and ARCn process from the primary database has its own RFS process.
    A standby redo log is used only when the database is in the standby role to store redo data received from the primary database. Standby redo logs form a separate pool of log file groups.
    Configuring standby redo log files is highly recommended on all standby databases in a Data Guard configuration, including the primary database to aid in role reversal.
    A standby redo log is required to implement:
    • The maximum protection and maximum availability levels of data protection
    • Real-time apply
    • Cascaded redo log destinations
    Standby redo logs are recommended for maximum performance data protection mode. Unless you are using the real-time apply feature, standby redo logs must be archived before the data can be applied to the standby database. The standby archival operation occurs automatically.

Maybe you are looking for