LGWR v$archived_logs

Oracle 11.1.0.7 RAC
3 node cluster PRIMARY
2 node cluster STANDBY
After a switchover from PRIMARY to STANDBY v$archived_log is used to verify that logs are applying.
On the standby we periodically run : RMAN delete noprompt archivelog all completed before ‘sysdate’; to reduce the number of rows in v$archived_log.
Now we’ve switched over and made the STANDBY our PRIMARY. The new STANDBY still shows a bunch of metadata exists for the archive logs that don’t exist physically (we use ASM). We are thinking these are leftover from when this was PRIMARY, but we are confused as to why.
Thread Seq# FIRST_TIME NEXT_TIME Creator Regr Arch Applied Del Standby Dest
2 3148 18-MAR-2013 09:24:50 18-MAR-2013 09:39:51 LGWR LGWR YES YES NO YES
1 3167 18-MAR-2013 09:39:01 18-MAR-2013 09:54:01 LGWR LGWR YES YES NO YES
3 3129 18-MAR-2013 09:39:03 18-MAR-2013 09:54:04 LGWR LGWR YES YES NO YES
2 3149 18-MAR-2013 09:39:51 18-MAR-2013 09:54:52 LGWR LGWR YES YES NO YES
1 3168 18-MAR-2013 09:54:01 18-MAR-2013 10:09:02 LGWR LGWR YES YES NO YES
Does anyone have insight into this, and how to get rid of them?

I misspoke.
PRIMARY: Every night we run a backup:
BACKUP INCREMENTAL LEVEL=${lvl} FILESPERSET=1 DATABASE PLUS ARCHIVELOG tag = '${BKPTAG}';
DELETE NOPROMPT ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE';
CROSSCHECK ARCHIVELOG ALL;
However, we don't do a DELETE EXPIRED ARCHIVELOG ALL;
A few times a week a cleanup job does:
delete noprompt obsolete;
delete noprompt expired backup;
crosscheck backup;
resync catalog;
We've added to delete noprompt expired archivelog all; to the cleanup job and will see what happens.
I tried this on a staging instance but it didn't make much difference, a few were deleted.
I notice that the Registrar for everything the old logs are always LGWR. The new stuff is RFS.
The archivelogs don't really exist in ASM, they were deleted a long time ago, but the metadata in v$archived_log hasn't kept up to date.
Sherrie

Similar Messages

  • Entries in gv$archived_log

    Hello,
    I am using Oracle 11.2.0.3.0
    My primary database is a RAC 2 nodes database with ASM. The Name of the DB is PREPROD
    I have created a single instance physical standby database with normal file system. The Name of the DB is PRESTDBY
    below are some queries on my primary and standby database:
    Primary Database:
    SQL> select * from gv$log;
       INST_ID     GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
             1          1          1      37303  943718400        512          2 YES INACTIVE             903149994 12-MAR-15    903166262 12-MAR-15
             1          2          1      37304  943718400        512          2 NO  CURRENT              903166262 12-MAR-15   2.8147E+14
             1          3          2      37520  943718400        512          2 NO  CURRENT              903166253 12-MAR-15   2.8147E+14
             1          4          2      37519  943718400        512          2 YES INACTIVE             903149990 12-MAR-15    903166253 12-MAR-15
             1          5          1      37302  943718400        512          2 YES INACTIVE             903139521 12-MAR-15    903149994 12-MAR-15
             1          6          2      37518  943718400        512          2 YES INACTIVE             903139509 12-MAR-15    903149990 12-MAR-15
             2          1          1      37303  943718400        512          2 YES INACTIVE             903149994 12-MAR-15    903166262 12-MAR-15
             2          2          1      37304  943718400        512          2 NO  CURRENT              903166262 12-MAR-15   2.8147E+14
             2          3          2      37520  943718400        512          2 NO  CURRENT              903166253 12-MAR-15   2.8147E+14
             2          4          2      37519  943718400        512          2 YES INACTIVE             903149990 12-MAR-15    903166253 12-MAR-15
             2          5          1      37302  943718400        512          2 YES INACTIVE             903139521 12-MAR-15    903149994 12-MAR-15
             2          6          2      37518  943718400        512          2 YES INACTIVE             903139509 12-MAR-15    903149990 12-MAR-15
    12 rows selected.
    SQL> select * from gv$standby_log;
       INST_ID     GROUP# DBID                                        THREAD#  SEQUENCE#      BYTES  BLOCKSIZE       USED ARC STATUS     FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME LAST_CHANGE# LAST_TIME
             1          7 UNASSIGNED                                        1          0  943718400        512          0 YES UNASSIGNED
             1          8 UNASSIGNED                                        1          0  943718400        512          0 YES UNASSIGNED
             1          9 UNASSIGNED                                        1          0  943718400        512          0 YES UNASSIGNED
             1         10 UNASSIGNED                                        1          0  943718400        512          0 YES UNASSIGNED
             1         11 UNASSIGNED                                        2          0  943718400        512          0 YES UNASSIGNED
             1         12 UNASSIGNED                                        2          0  943718400        512          0 YES UNASSIGNED
             1         13 UNASSIGNED                                        2          0  943718400        512          0 YES UNASSIGNED
             1         14 UNASSIGNED                                        2          0  943718400        512          0 YES UNASSIGNED
             2          7 UNASSIGNED                                        1          0  943718400        512          0 YES UNASSIGNED
             2          8 UNASSIGNED                                        1          0  943718400        512          0 YES UNASSIGNED
             2          9 UNASSIGNED                                        1          0  943718400        512          0 YES UNASSIGNED
             2         10 UNASSIGNED                                        1          0  943718400        512          0 YES UNASSIGNED
             2         11 UNASSIGNED                                        2          0  943718400        512          0 YES UNASSIGNED
             2         12 UNASSIGNED                                        2          0  943718400        512          0 YES UNASSIGNED
             2         13 UNASSIGNED                                        2          0  943718400        512          0 YES UNASSIGNED
             2         14 UNASSIGNED                                        2          0  943718400        512          0 YES UNASSIGNED
    16 rows selected.
    SQL> select g.INST_ID, g.DEST_ID, g.status, g.TYPE, g.PROTECTION_MODE, g.gap_status from gV$archive_Dest_Status g where dest_id in (1,2);
       INST_ID    DEST_ID STATUS    TYPE           PROTECTION_MODE      GAP_STATUS
             2          1 VALID     LOCAL          MAXIMUM PERFORMANCE
             2          2 VALID     PHYSICAL       MAXIMUM PERFORMANCE  NO GAP
             1          1 VALID     LOCAL          MAXIMUM PERFORMANCE
             1          2 VALID     PHYSICAL       MAXIMUM PERFORMANCE  NO GAP
    SQL> select inst_id, name, value from gv$parameter where name in ( 'log_archive_dest_1', 'log_archive_dest_2');
       INST_ID NAME
    VALUE
             2 log_archive_dest_1
    LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PREPROD
             2 log_archive_dest_2
    SERVICE=PRESTDBY LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PRESTDBY
             1 log_archive_dest_1
    LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PREPROD
             1 log_archive_dest_2
    SERVICE=PRESTDBY LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PRESTDBY
    Standby Database:
    SQL> select * from gv$log;
       INST_ID     GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
             1          1          1      37303  943718400        512          3 YES CLEARING             903149994 12-MAR-15    903166262 12-MAR-15
             1          2          1      37304  943718400        512          3 YES CURRENT              903166262 12-MAR-15    903139521 12-MAR-15
             1          3          2      37520  943718400        512          3 YES CURRENT              903166253 12-MAR-15    903139509 12-MAR-15
             1          4          2      37519  943718400        512          3 YES CLEARING             903149990 12-MAR-15    903166253 12-MAR-15
             1          5          1      37302  943718400        512          3 YES CLEARING             903139521 12-MAR-15    903149994 12-MAR-15
             1          6          2      37518  943718400        512          3 YES CLEARING             903139509 12-MAR-15    903149990 12-MAR-15
    6 rows selected.
    SQL> select * from gv$standby_log;
       INST_ID     GROUP# DBID                                        THREAD#  SEQUENCE#      BYTES  BLOCKSIZE       USED ARC STATUS     FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME LAST_CHANGE# LAST_TIME
             1          7 UNASSIGNED                                        1          0  943718400        512          0 NO  UNASSIGNED
             1          8 591853822                                         1      37304  943718400        512    5067776 YES ACTIVE         903166262 12-MAR-15    903174339 12-MAR-15    903174339 12-MAR-15
             1          9 UNASSIGNED                                        1          0  943718400        512          0 YES UNASSIGNED
             1         10 UNASSIGNED                                        1          0  943718400        512          0 YES UNASSIGNED
             1         11 UNASSIGNED                                        2          0  943718400        512          0 NO  UNASSIGNED
             1         12 591853822                                         2      37520  943718400        512    1138688 YES ACTIVE         903166253 12-MAR-15    903174341 12-MAR-15    903174341 12-MAR-15
             1         13 UNASSIGNED                                        2          0  943718400        512          0 YES UNASSIGNED
             1         14 UNASSIGNED                                        2          0  943718400        512          0 YES UNASSIGNED
    8 rows selected.
    SQL> select g.INST_ID, g.DEST_ID, g.status, g.TYPE, g.PROTECTION_MODE, g.gap_status from gV$archive_Dest_Status g where dest_id in (1,2);
       INST_ID    DEST_ID STATUS    TYPE           PROTECTION_MODE      GAP_STATUS
             1          1 VALID     LOCAL          MAXIMUM PERFORMANCE
             1          2 VALID     UNKNOWN        MAXIMUM PERFORMANCE  NO GAP
    SQL> select inst_id, name, value from gv$parameter where name in ( 'log_archive_dest_1', 'log_archive_dest_2');
       INST_ID NAME
    VALUE
             1 log_archive_dest_1
    LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PRESTDBY
             1 log_archive_dest_2
    SERVICE=PREPROD LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PREPROD
    gv$archived_log on primary RAC Database:
    SQL> select g.SEQUENCE#, g.INST_ID,g.thread#, to_char(g.COMPLETION_TIME, 'DD MON YYYY hh:mi:ss AM'), g.recid, g.name, g.DEST_ID, g.CREATOR, g.STANDBY_DEST,g.ARCHIVED, g.applied, g.deleted, g.status  from gv$archived_log g where  g.SEQUENCE#  in (37248, 37249, 37313) order by  sequence#,inst_id, thread#, g.COMPLETION_TIME;
    SEQUENCE#    INST_ID    THREAD# TO_CHAR(G.COMPLETION_TI      RECID NAME        DEST_ID CREATOR STANDBY_DEST ARCHIVED APPLIED   DELETED STATUS
         37248          1          1 11 MAR 2015 11:03:50 AM      86791 PRESTDBY          2      LGWR         YES      YES      YES       NO      A
         37248          1          1 11 MAR 2015 11:03:50 AM      86792                             1      ARCH         NO      YES      NO        YES      D
         37248          1          2 07 MAR 2015 01:00:07 AM      85921 PRESTDBY          2      LGWR         YES      YES      YES       NO      A
         37248          1          2 07 MAR 2015 01:00:07 AM      85922                             1      ARCH         NO      YES      NO        YES      D
         37248          2          1 11 MAR 2015 11:03:50 AM      86792                             1      ARCH         NO      YES      NO        YES      D
         37248          2          1 11 MAR 2015 11:03:50 AM      86791 PRESTDBY          2      LGWR         YES      YES      YES       NO      A
         37248          2          2 07 MAR 2015 01:00:07 AM      85922                             1      ARCH         NO      YES      NO        YES      D
         37248          2          2 07 MAR 2015 01:00:07 AM      85921 PRESTDBY          2      LGWR         YES      YES      YES       NO      A
         37249          1          1 11 MAR 2015 11:33:48 AM      86795 PRESTDBY          2      LGWR         YES      YES      YES       NO      A
         37249          1          1 11 MAR 2015 11:33:48 AM      86796                             1      ARCH         NO      YES      NO        YES      D
         37249          1          2 07 MAR 2015 01:03:47 AM      85926                             1      ARCH         NO      YES      NO        YES      D
         37249          1          2 07 MAR 2015 01:03:47 AM      85925 PRESTDBY          2      LGWR         YES      YES      YES       NO      A
         37249          2          1 11 MAR 2015 11:33:48 AM      86795 PRESTDBY          2      LGWR         YES      YES      YES       NO      A
         37249          2          1 11 MAR 2015 11:33:48 AM      86796                             1      ARCH         NO      YES      NO        YES      D
         37249          2          2 07 MAR 2015 01:03:47 AM      85925 PRESTDBY          2      LGWR         YES      YES      YES       NO      A
         37249          2          2 07 MAR 2015 01:03:47 AM      85926                             1      ARCH         NO      YES      NO        YES      D
         37313          1          2 08 MAR 2015 08:41:17 AM      86181 PRESTDBY          2      LGWR         YES      YES      YES       NO      A
         37313          1          2 08 MAR 2015 08:41:17 AM      86182                             1      ARCH         NO      YES      NO        YES      D
         37313          2          2 08 MAR 2015 08:41:17 AM      86182                             1      ARCH         NO      YES      NO        YES      D
         37313          2          2 08 MAR 2015 08:41:17 AM      86181 PRESTDBY          2      LGWR         YES      YES      YES       NO      A
    20 rows selected.
    SQL>
    My question:
         1.     My v$log and v$log_standby looks ok?
         2.     As shown above in gv$archived_log there are 8 entries for sequences 37248 and 37249, however for sequence 37313 i have only 4 entries:    
                   Why I have this difference in the number of entries?
         3.     Why for 37248 and 37249 I have 2 completion_date Mar 07 and Mar 11  ?
         4.      Is the output correct or do I have an issue in applying the redo logs ? I am expecting it is correct as all the entries of the stanby destination were applied.
         5.      Why the entries of the standby destination were not deleted ? and when it will be deleted ?
         6.     What process deletes the Archive logs on the standby ? I am still having archive logs since March 3rd, how should I automate the deletion of these archive logs?
    Regards,

    Hi,
    I checked some sequence have 4 entries in V$archive_log and some have only 2 entries.
    Below is an example:
    select g.RECID, stamp, name, dest_id, thread#, sequence#, first_time, next_time, creator, standby_dest, archived, applied, deleted, status, completion_time  from v$archived_log g where g.SEQUENCE# in(37716, 37507);
    RECID
    stamp
    name
    dest_id
    thread#
    sequence#
    first_time
    next_time
    creator
    standby_dest
    archived
    applied
    deleted
    status
    completion_time
    87812
    874501675
    +FRA/preprod/archivelog/2015_03_16/thread_1_seq_37507.12440.874501675
    1
    1
    37507
    3/16/2015 12:37
    3/16/2015 13:07
    ARCH
    NO
    YES
    NO
    NO
    A
    3/16/2015 13:07
    87811
    874501674
    PRESTDBY
    2
    1
    37507
    3/16/2015 12:37
    3/16/2015 13:07
    LGWR
    YES
    YES
    YES
    NO
    A
    3/16/2015 13:07
    86961
    874134695
    PRESTDBY
    2
    2
    37507
    3/12/2015 6:41
    3/12/2015 7:11
    LGWR
    YES
    YES
    YES
    NO
    A
    3/12/2015 7:11
    86962
    874134695
    1
    2
    37507
    3/12/2015 6:41
    3/12/2015 7:11
    ARCH
    NO
    YES
    NO
    YES
    D
    3/12/2015 7:11
    87809
    874501674
    PRESTDBY
    2
    2
    37716
    3/16/2015 12:37
    3/16/2015 13:07
    LGWR
    YES
    YES
    YES
    NO
    A
    3/16/2015 13:07
    87810
    874501675
    +FRA/preprod/archivelog/2015_03_16/thread_2_seq_37716.12712.874501675
    1
    2
    37716
    3/16/2015 12:37
    3/16/2015 13:07
    ARCH
    NO
    YES
    NO
    NO
    A
    3/16/2015 13:07

  • Same Sequence# with different applied value in v$archived_log

    Hi everyone,
    I have an issue with one of the dataguard servers here.
    Basically, looking at the v$managed_standby, it is still applying the latest archived log sequence.
    However when I checked for unapplied archived log from v$archived_log, I found at least 1 sequence# which was quite old (around a few days old) not applied.
    my query to check this is:
    SELECT sequence# from v$archived_log where applied = 'NO';result:
    SEQUENCE#
        40154
        40546with a different query I found an interesting result
    select sequence#, recid, stamp, status, applied from v$archived_log where sequence# in (40154, 40546);result:
    SEQUENCE#      RECID      STAMP S APP
        40154       8093  777156019 D NO
        40154       8095  777156053 D YES
        40546       8486  777673729 D NO
        40546       8487  777673734 D YESAt the time I ran this query, the v$managed_standby are as follow:
    select process, status, sequence# from v$managed_standby;result:
    PROCESS   STATUS        SEQUENCE#
    ARCH      CLOSING           40562
    ARCH      CLOSING           40557
    MRP0      APPLYING_LOG      40563
    RFS       IDLE                  0
    RFS       IDLE              40563A simple solution to get those un-applied archived log to be applied is to restart the standby database instance.
    Another finding from the production database:
    select recid, stamp, sequence#, creator, registrar, standby_dest from v$archived_log where sequence# in (40154, 40546);result:
    RECID      STAMP  SEQUENCE# CREATOR REGISTR STA
    45446  777156011      40154 ARCH    ARCH    NO
    45447  777156017      40154 LGWR    LGWR    YES
    45450  777156051      40154 ARCH    ARCH    YES
    46231  777673709      40546 ARCH    ARCH    NO
    46232  777673728      40546 LGWR    LGWR    YES
    46233  777673733      40546 ARCH    ARCH    YESThe question is of course, why is this happening?
    Can this be prevented?
    Thank you,
    Adhika

    CKPT wrote:
    I have an issue with one of the dataguard servers here.
    Basically, looking at the v$managed_standby, it is still applying the latest archived log sequence.
    However when I checked for unapplied archived log from v$archived_log, I found at least 1 sequence# which was quite old (around a few days old) not applied.
    my query to check this is:
    SELECT sequence# from v$archived_log where applied = 'NO';result:
    SEQUENCE#
    40154
    40546
    Even if old archives applied or not, it will keep transfer the archivelogs from primary. Please confirm that you been executed above query in standby.. is it?Yes I ran it from the standby database
    CKPT wrote:
    with a different query I found an interesting result
    select sequence#, recid, stamp, status, applied from v$archived_log where sequence# in (40154, 40546);result:
    SEQUENCE#      RECID      STAMP S APP
    40154       8093  777156019 D NO
    40154       8095  777156053 D YES
    40546       8486  777673729 D NO
    40546       8487  777673734 D YES
    How many remote/standby destinations you have in your DR setup?
    Might this query you have executed in primary, You should always use DEST_ID when executing from primary (or) do check in standby database, Because the applied column you have to check in standby , If you see above the same sequence showing applied in one destination & not applied on other instance, so please do select for dest_2 or in standby.I have only 1 standby destination.
    The query above was executed in the standby database server as well as to show that the same sequence# has different result in the applied column.
    CKPT wrote:
    The question is of course, why is this happening?
    Can this be prevented?What is your Online redo log file size (or) how much average archive log file size?
    This issue happens when Network glitch while transferring archives from primary to standby RFS , So when is big enough in such conditions it will be in status can be WAIT_FOR_LOG.
    BTW, which redo transport you are using? -- recommended to use LGWR
    Is there any network problem?
    check for exact problem either from primary alert log file or from below query,
    SQL> select severity,error_code,message,to_char(timestamp,'DD-MON-YYYY HH24:MI:SS') from v$dataguard_status;
    SQL> select sequence#, to_char(completion_time,'DD-MON-YYYY HH24:MI:SS') from v$archived_log where sequence# in (40154, 40546);
    HTH.The redolog file size is 100MB and so does the archive log file size.
    I'm using LGWR ASYNC
    these are the result of the query which I modified slightly:
    query:
    select severity,error_code,message,to_char(timestamp,'DD-MON-YYYY HH24:MI:SS') from v$dataguard_status where message like '%40154%' or message like '%40546%';result:
    SEVERITY ERROR_CODE MESSAGE                                                                                              TIMESTAMP
    Warning           0 LNS: Standby redo logfile selected for thread 1 sequence 40546 for destination LOG_ARCHIVE_DEST_2    11-MAR-2012 20:28:44
    Warning           0 ARC1: Standby redo logfile selected for thread 1 sequence 40546 for destination LOG_ARCHIVE_DEST_2   11-MAR-2012 20:28:49The message for the 40154 must have been purged.
    It appeared to me that sequence 40546 has been sent twice, by LNS and ARC1.
    query:
    select sequence#, registrar, creator, standby_dest, dest_id, to_char(completion_time,'DD-MON-YYYY HH24:MI:SS') completion_time from v$archived_log where sequence# in (40154, 40546);result:
    SEQUENCE# REGISTR CREATOR STA    DEST_ID COMPLETION_TIME
        40154 ARCH    ARCH    NO           1 05-MAR-2012 20:40:11
        40154 LGWR    LGWR    YES          2 05-MAR-2012 20:40:17
        40154 ARCH    ARCH    YES          2 05-MAR-2012 20:40:51
        40546 ARCH    ARCH    NO           1 11-MAR-2012 20:28:29
        40546 LGWR    LGWR    YES          2 11-MAR-2012 20:28:48
        40546 ARCH    ARCH    YES          2 11-MAR-2012 20:28:53This query proved that the primary database is actually trying to send twice with a different completion time.
    Why does the primary database has to send twice?
    Thanks for replying,
    Adhika

  • Detect archivelog gap through gv$archived_log or GV$ARCHIVE_DEST_STATUS

    I am trying to set up a physical standby.
    Version 11.2.0.1,Single instance.
    Platform - Linux     X86-64
    After setting up, when i execute the following queries, there is a difference in the output with reference to archivelog gap. Any inputs why these 2 views report different numbers.
    SQL> SELECT   a.thread#,  b. last_seq, a.applied_seq, a. last_app_timestamp, b.last_seq-a.applied_seq   ARC_DIFF FROM (SELECT  thread#, MAX(sequence#) applied_seq, MAX(next_time) last_app_timestamp FROM gv$archived_log WHERE applied = 'YES' GROUP BY thread#) a,      
    (SELECT  thread#, MAX (sequence#) last_seq FROM gv$archived_log GROUP BY thread#) b WHERE a.thread# = b.thread#;
       THREAD#   LAST_SEQ APPLIED_SEQ LAST_APP_TIMESTAMP
    ARC_DIFF
    1    
    59     
    59 21-JUL-2013 09:09:05     
    0
    SQL> select INST_ID,DEST_NAME,STATUS,RECOVERY_MODE,ARCHIVED_THREAD#,ARCHIVED_SEQ#,APPLIED_THREAD#,APPLIED_SEQ#,DB_UNIQUE_NAME
       from GV$ARCHIVE_DEST_STATUS
    where DEST_NAME in ('LOG_ARCHIVE_DEST_3');
      2
    3
       INST_ID DEST_NAME            
    STATUS
    RECOVERY_MODE      
    ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# DB_UNIQUE_NAME
    1 LOG_ARCHIVE_DEST_3   
    VALID
    MANAGED                           
    1       
    59          
    1      
    57 db101pln

    Hi,
    I checked some sequence have 4 entries in V$archive_log and some have only 2 entries.
    Below is an example:
    select g.RECID, stamp, name, dest_id, thread#, sequence#, first_time, next_time, creator, standby_dest, archived, applied, deleted, status, completion_time  from v$archived_log g where g.SEQUENCE# in(37716, 37507);
    RECID
    stamp
    name
    dest_id
    thread#
    sequence#
    first_time
    next_time
    creator
    standby_dest
    archived
    applied
    deleted
    status
    completion_time
    87812
    874501675
    +FRA/preprod/archivelog/2015_03_16/thread_1_seq_37507.12440.874501675
    1
    1
    37507
    3/16/2015 12:37
    3/16/2015 13:07
    ARCH
    NO
    YES
    NO
    NO
    A
    3/16/2015 13:07
    87811
    874501674
    PRESTDBY
    2
    1
    37507
    3/16/2015 12:37
    3/16/2015 13:07
    LGWR
    YES
    YES
    YES
    NO
    A
    3/16/2015 13:07
    86961
    874134695
    PRESTDBY
    2
    2
    37507
    3/12/2015 6:41
    3/12/2015 7:11
    LGWR
    YES
    YES
    YES
    NO
    A
    3/12/2015 7:11
    86962
    874134695
    1
    2
    37507
    3/12/2015 6:41
    3/12/2015 7:11
    ARCH
    NO
    YES
    NO
    YES
    D
    3/12/2015 7:11
    87809
    874501674
    PRESTDBY
    2
    2
    37716
    3/16/2015 12:37
    3/16/2015 13:07
    LGWR
    YES
    YES
    YES
    NO
    A
    3/16/2015 13:07
    87810
    874501675
    +FRA/preprod/archivelog/2015_03_16/thread_2_seq_37716.12712.874501675
    1
    2
    37716
    3/16/2015 12:37
    3/16/2015 13:07
    ARCH
    NO
    YES
    NO
    NO
    A
    3/16/2015 13:07

  • What are CREATOR and REGISTRAR in the V$ARCHIVED_LOG view?

    Environment: Oracle 11.2.0.3 EE on Solaris 10.5
    I'm not sure exactly where this question belongs since it deals with database processes, RMAN and Data Guard all in one so I'll start here and see where it takes me.
    I have a Data Guard environment set up with 1 primary and 1 standby. I am running some queries against the V$ARCHIVED_LOG view to understand the view so I can better monitor the archive log activity between the databases.
    I have read the documentation but am still confused over a couple of things:
    1- What is the FGRD process and how can it write archive logs as seen in the CREATOR column of the view looking from the primary side? I thought only the ARCn process could do that.
    2- On the standby side all the logs have LGWR as the CREATOR which makes sense since, as I understand it, the LGWR process on the primary is sending the log files to the standby via SQL*Net. I realize this is not a question. :-)
    3- The documentation for the view shows RMAN as a possible value for the CREATOR column. How and where does RMAN create an archive log file?
    4- Finally, for now, what is the meaning of the REGISTRAR column? What exactly is it registering since we already know the source (CREATOR), status and whether the log has been archived, applied and deleted.
    Thanks very much for any light you can shed in my darkness.
    -gary

    garywicke wrote:
    Environment: Oracle 11.2.0.3 EE on Solaris 10.5
    I'm not sure exactly where this question belongs since it deals with database processes, RMAN and Data Guard all in one so I'll start here and see where it takes me.
    I have a Data Guard environment set up with 1 primary and 1 standby. I am running some queries against the V$ARCHIVED_LOG view to understand the view so I can better monitor the archive log activity between the databases.
    I have read the documentation but am still confused over a couple of things:
    1- What is the FGRD process and how can it write archive logs as seen in the CREATOR column of the view looking from the primary side? I thought only the ARCn process could do that.I thinks its the RFS process, when its writes directly to archivelog files when standby redolog are not available and LGWR on standby wait for its confirmation. Thats why acting as forground process.
    >
    2- On the standby side all the logs have LGWR as the CREATOR which makes sense since, as I understand it, the LGWR process on the primary is sending the log files to the standby via SQL*Net. I realize this is not a question. :-)
    3- The documentation for the view shows RMAN as a possible value for the CREATOR column. How and where does RMAN create an archive log file?It might be when you explicitly register archivelog with "REGISTER" command.
    >
    4- Finally, for now, what is the meaning of the REGISTRAR column? What exactly is it registering since we already know the source (CREATOR), status and whether the log has been archived, applied and deleted.
    This might be because archivelog file can be generated from other resource i.e either from RFS or by registering with RMAN command REGISTER.
    >
    Thanks very much for any light you can shed in my darkness.
    -gary

  • Database Crash - LGWR: terminating instance due to error 227

    Hi,
    We´re having a problem with our database. The server reboots abnormally and the database shutdown abort, when we bring online the machine the database didn´t open.
    Analyzing the logs, we found a corrupt problem. see the alert file:
    Corrupt block relative dba: 0x00000003 (file 0, block 3)
    Completely zero block found during controlfile block read
    LGWR: terminating instance due to error 227
    Instance terminated by LGWR, pid = 2080
    Dump file E:\ORACLE\PDS\bdump\pdsALRT.LOG
    So ... we try to starts the database and he didn´t mount, we only startup nomount. see the log above:
    Oracle Server Manager Release 3.1.7.0.0 - Production
    Copyright (c) 1997, 1999, Oracle Corporation. All Rights Reserved.
    Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
    JServer Release 8.1.7.0.0 - Production
    SVRMGR> connect internal
    Password:
    Connected.
    SVRMGR> startup nomount
    ORACLE instance started.
    Total System Global Area 633632796 bytes
    Fixed Size 75804 bytes
    Variable Size 167411712 bytes
    Database Buffers 466067456 bytes
    Redo Buffers 77824 bytes
    SVRMGR> alter database mount;
    alter database mount
    ORA-03113: end-of-file on communication channel
    SVRMGR>
    We doesn´t mount the database, so we can´t do a recovery.
    Anybody knows the resolution of this problem ??
    Regards,
    Eduardo

    We can´t do a recover because database is not mounted.
    We don´t have a backup of the controlfile and didn´t make the "alter database backup controlfile to trace"
    Thanks,
    Eduardo

  • Logical Standby - LGWR or ARCH mode

    After reading the [Setting the Data Protection Mode of a Data Guard Configuration|http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/log_transport.htm#i1183694] , I'm still confusing about it!
    What is the main difference between LGWR or ARCH when implementing a logical standby database, if I want "Maximum Performance" mode?
    What the advantages and disadvantages of them? In real situation, which are used mostly by business?
    Thanks!

    Using the LGWR process differs from ARCn processing because instead of waiting for the online redo log to switch at the primary database and then writing the entire archived redo log at the remote destination all at once, the LGWR process selects a standby redo log file at the standby site that reflects the log sequence number (and size) of the current online redo log file of the primary database. Then, as redo is generated at the primary database, it is also transmitted to the remote destination. The transmission to the remote destination will either be synchronous or asynchronous, based on whether the SYNC or the ASYNC attribute is set on the LOG_ARCHIVE_DEST_n parameter. Synchronous LGWR processing is required for the maximum protection and maximum availability modes of data protection in Data Guard configurations.
    Regards,
    Muzafar

  • LGWR ASYNC doest not working for redolog files, while archiving is working

    Hi All,
    I am using Oracle Database 10g Enterprise Edition Release 10.2.0.4.0.
    I have created a database named black. I then creaetd a standby database. now I want to syncronize the redo logs file as well.
    SO I added log_archive_dest_2='SERVICE=standby LGWR ASYNC',
    I have also added following standby log files on standby database.
    ALTER DATABASE ADD STANDBY LOGFILE '/oracle/oradata/black/srl1.f' SIZE 52428800;
    ALTER DATABASE ADD STANDBY LOGFILE '/oracle/oradata/black/srl2.f' SIZE 52428800;
    ALTER DATABASE ADD STANDBY LOGFILE '/oracle/oradata/black/srl3.f' SIZE 52428800;
    ALTER DATABASE ADD STANDBY LOGFILE '/oracle/oradata/black/srl4.f' SIZE 52428800;
    Now I want to confirm that the redo log files are syncronizing same time on both Primary and Standby. I have checked thru alter system switch logfile; when i executed the redo log sync at both sides.
    Archive logs are also applying successfully.
    The Primary database is in MAXIMUM PERFORMANCE Mode;
    Regards,
    Hassan

    Hi Khurram,
    I have successfully executed the commands on Primary Database as below: (Standby database was in mount state at that time)
    SQL> startup mount;
    ORACLE instance started.
    Total System Global Area 1258291200 bytes
    Fixed Size 2083728 bytes
    Variable Size 318768240 bytes
    Database Buffers 922746880 bytes
    Redo Buffers 14692352 bytes
    Database mounted.
    SQL> alter system set log_archive_dest_2='SERVICE=standby LGWR SYNC AFFIRM' scope=both;
    System altered.
    SQL> alter database set standby database to MAXIMIZE AVAILABILITY;
    Database altered.
    SQL> alter database open;
    Database altered.
    SQL> shutdown immediate;
    Database closed.
    Database dismounted.
    ORACLE instance shut down.
    SQL> startup
    ORACLE instance started.
    After that I activated managed recovery process on standby database and all archive files were applied successfully;
    Then I executed a script to insert 2000 records in Primary Database Scott Schema, and during the execution of this script I executed shutdown abort from anothe session on primary database.
    at that time no new archive file generated only redo files was there.
    I then executed below commands on standby database to apply current redo log file but that IS WAHT I WANT TO ACHIEVE IS UN-SUCCESSFULL.
    SQL> alter database recover managed standby database cancel;
    Database altered.
    SQL> recover standby database;
    ORA-00279: change 1065936 generated at 10/22/2009 17:02:43 needed for thread 1
    ORA-00289: suggestion : /oradata/black/arch/1700844250_0000000043.arc
    ORA-00280: change 1065936 for thread 1 is in sequence #43
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    /oracle/oradata/black/stdb_redo01.log
    ORA-00310: archived log contains sequence 42; sequence 43 required
    ORA-00334: archived log: '/oracle/oradata/black/stdb_redo01.log'
    SQL> recover standby database;
    ORA-00279: change 1065936 generated at 10/22/2009 17:02:43 needed for thread 1
    ORA-00289: suggestion : /oradata/black/arch/1700844250_0000000043.arc
    ORA-00280: change 1065936 for thread 1 is in sequence #43
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    /oracle/oradata/black/stdb_redo02.log
    ORA-00283: recovery session canceled due to errors
    ORA-00354: corrupt redo log block header
    ORA-00353: log corruption near block 49141 change 1095254 time 10/22/2009
    17:03:55
    ORA-00334: archived log: '/oracle/oradata/black/stdb_redo02.log'
    ORA-01112: media recovery not started
    The standby redo log files are already generated on standby database. The database is in MAXIMUM AVAILABILITY MODE.
    I have also go through your blog but did not find solution for my issue.
    My scenario is that: SHUTDOWN ABORT (Primary Database) means that server goes down and we have to make our Standby Database as Primary Database, so we need to apply redo log file that niether switched nor applied yet.
    Kindly advice.
    Regards,
    Hassan
    Edited by: Hassan Raza Khan Lodhi on Oct 22, 2009 4:33 PM

  • Unable to understand meaning of next_time in v$archived_log

    hi all,
    i am working with 10g standby databases. There are column names FIRST_CHANGE#, FIRST_TIME, NEXT_CHANGE#, NEXT_TIME in v$archived_log. I am unable to understand the exact meaning of these columns by reading the oracle document.
    Can somebody explain me the meaning of these columns in v$archived_log.
    Same columns are there in v$log_history also but i think there meanings are different as from columns in v$archived_log.
    thanks in advance.

    Hi,
    See, when you referred to "v$archived_log", by the name it depends on the Online Redo Log. See, the columns
    FIRST_CHANGE#, FIRST_TIME, NEXT_CHANGE#, NEXT_TIME reflects the changes happened with respect to online redolog, Suppose if the online redo log for first time archived then the respect to record will be appeared, in the "v$archived_log" with respect to details like which is first changed started or done in this particular log and time of it, Next change comes to like a link of next log which happened and respective time. By tracking this details itwill help ful for process to apply the necessary logs on data files at the time of recovery.
    Coming to " v$log_history " -> its maintains the history of logs, with respect to SCN numbers, by this we can information which SCN will fall under which log files or existing in which logs. it will have lowest SCN and Highest SCN Numbers with respect to Sequnence number of Log
    - Pavan Kumar N

  • FIRST_TIME and NEXT_TIME columns in v$archived_log view

    Oracle Version      : 11.2
    OS Platform      : Solaris 10
    Could anyone please explain what FIRST_TIME and NEXT_TIME columns in v$archived_log are?
    Oracle Documentation (below) and googling didn't help.
    http://docs.oracle.com/cd/E18283_01/server.112/e17110/dynviews_1016.htm
    Did quite understand what
    FIRST_TIME      DATE      Timestamp of the first change
    NEXT_TIME      DATE      Timestamp of the next changeis.
    Did a search on OTN as well. A similair OTN post unfortunately ended up in Abuse and Insults !
    description of NEXT_TIME colume in V$ARCHIVED_LOG View

    For each archive log file, there would be First_time & Next_time.
    first_time refers to the timestamp when when first SCN is recorded, Also next_time refers to the timestamp of the next archivelog change.
    Here next_change/next_time of archive value is equal to the next logs first_change/first_time.
    SEQUENCE#         FIRST_CHANGE# TO_CHAR(FIRST_TIME,'DD-MON-YYYYHH24:MI:SS')                                          NEXT_CHANGE# TO_CHAR(NEXT_TIME,'DD-MON-YYYYHH24:MI:SS')
        116329            1042518947 16-DEC-2011 04:05:16                                                                   1042534917 16-DEC-2011 04:07:04
        116330            1042534917 16-DEC-2011 04:07:04                                                                   1042550495 16-DEC-2011 04:08:24

  • Confusion in the APP column in V$ARCHIVED_LOG

    Hi All,
    I have some confusion regarding APP column of v$ARCHIVED_LOG
    On my Primary machine when i execute :-
    SQL> SELECT THREAD#,SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE#,APPLIED FROM V$ARCHIVED_LOG;
       THREAD#  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# APP
             1          2        527611       545327 NO
             1          3        545327       549119 NO
             1          4        549119       557792 NO
             1          5        557792       559897 NO
             1          6        559897       560068 NO
             1          7        560068       560072 NO
             1          6        559897       560068 YES
             1          7        560068       560072 YES
             1          5        557792       559897 YES
             1          8        560072       560335 NO
             1          9        560335       560338 NO
       THREAD#  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# APP
             1         10        560338       560340 NO
             1         10        560338       560340 YES
             1          8        560072       560335 YES
             1          9        560335       560338 YES
             1         11        560340       560819 NO
             1         11        560340       560819 YES
             1         12        560819       560840 NO
             1         12        560819       560840 YES
             1         13        560840       561853 YES
             1         13        560840       561853 NO
             1         14        561853       590041 YES
       THREAD#  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# APP
             1         14        561853       590041 NO
             1         15        590041       590061 NO
             1         15        590041       590061 YES
             1         16        590061       594075 YES
             1         16        590061       594075 NO
             1         17        594075       594119 NO
             1         17        594075       594119 YES
             1         18        594119       604547 YES
             1         18        594119       604547 NO
             1         19        604547       605449 YES
             1         19        604547       605449 NO
       THREAD#  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# APP
             1         20        605449       605682 NO
             1         20        605449       605682 YES
             1         21        605682       605722 NO
             1         21        605682       605722 YES
             1         22        605722       605726 NO
             1         22        605722       605726 YES
             1         23        605726       605728 NO
             1         23        605726       605728 YES
             1         23        605726       605728 NO
             1         22        605722       605726 NO
             1         21        605682       605722 NO
       THREAD#  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# APP
             1         19        604547       605449 NO
             1         20        605449       605682 NO
             1         18        594119       604547 NO
    On my standby Machine when i execute :-
    SQL>  SELECT THREAD#,SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE#,APPLIED FROM V$ARCHIVED_LOG;
       THREAD#  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# APP
             1          7        560068       560072 YES
             1          6        559897       560068 YES
             1          5        557792       559897 YES
             1         10        560338       560340 YES
             1          8        560072       560335 YES
             1          9        560335       560338 YES
             1         11        560340       560819 YES
             1         12        560819       560840 YES
             1         13        560840       561853 YES
             1         14        561853       590041 YES
             1         15        590041       590061 YES
       THREAD#  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# APP
             1         16        590061       594075 YES
             1         17        594075       594119 YES
             1         18        594119       604547 YES
             1         19        604547       605449 YES
             1         20        605449       605682 YES
             1         21        605682       605722 YES
             1         22        605722       605726 YES
             1         23        605726       605728 YES
             1         24        605728       605818 YES
             1         25        605818       606571 YES
             1         26        606571       606586 NO
    So here we find that in primary machine in the APP column NO is mentioned but as i can check in the standby machine the log is present. So what do we understand by NO in primary machine.

    Hi,
    Yes It is not APP columns, Its APPLIED.
    Applied column says, The particular sequence of archive log is applied on stand by database or not
    If YES - Applied, NO - Not Applied, IN-MEMORY - In Process of applied
    On Primary database every sequence has entry with respected DEST_ID
    DEST_ID = 1 = Primary database
    DEST_ID = 2 = Standby database
    On Primary database O/P looks like
    SEQUENCE# APPLIED   ARC
    DEST_ID
    90763 YES  
    YES     
    2
    90763 NO   
    YES     
    1
    90764 YES  
    YES     
    2
    90764 NO   
    YES     
    1
    90765 YES  
    YES     
    2
    90765 NO   
    YES     
    1
    90766 YES  
    YES     
    2
    No Need to apply archive logs on primary that's why it says NO under Applied columns on Primary database
    Thanks
    Viren

  • Description of NEXT_TIME colume in V$ARCHIVED_LOG View

    i m new in oracle .. i juut want to know the exact meannig in simple word and uasag of next_time col of V$ARCHIVED_LOG View

    user627401 wrote:
    i m new in oracle .. But your profile says you've been a member of the forum for over 2 years ....
    i juut want to know the exact meannig in simple word and uasag of next_time col of V$ARCHIVED_LOG ViewI don't want to be flippant or rude, but if people want to be professionals in ANY field, the first knowledge they need to acquire is how to locate AND USE+ the fundamental reference materials for that profession. And the most important trait, the one for which they are really hired, is the ability to do independent research. We don't mind helping newbies, and even the most experienced person on this board will run into something they are not familiar with, or occasionally just require a second set of eyes to look at something. But a professional+ needs, above all, a willingness and capability to check the docs. A professional isn't necessarily someone who has all the answers at their fingertips or has a full understanding about every arcane subject in their field. It certainly isn't someone who has an encyclopedia full of memorized answers but little understanding of how it all fits together. It's someone who knows where to find the answers when needed, how to recognize them when he sees them. It's less about knowing than it is about attitude. Everything you've been asking the last couple of days can be answered in the Oracle docs at tahiti.oracle.com. You should bookmark that site.
    =================================================
    Learning how to look things up in the documentation is time well spent investing in your career. To that end, you should drop everything else you are doing and do the following:
    Go to tahiti.oracle.com.
    Drill down to your product and version.
    <b><i><u>BOOKMARK THIS LOCATION</u></i></b>
    Spend a few minutes just getting familiar with what is available here. Take special note of the "books" and "search" tabs. Under the "books" tab you will find the complete documentation library.
    Spend a few minutes just getting familiar with what <b><i><u>kind</u></i></b> of documentation is available there by simply browsing the titles under the "Books" tab.
    Open the Reference Manual and spend a few minutes looking through the table of contents to get familiar with what <b><i><u>kind</u></i></b> of information is available there.
    Do the same with the SQL Reference Manual.
    Do the same with the Utilities manual.
    You don't have to read the above in depth. They are <b><i><u>reference</b></i></u> manuals. Just get familiar with <b><i><u>what</b></i></u> is there to <b><i><u>be</b></i></u> referenced. Ninety percent of the questions asked on this forum can be answered in less than 5 minutes by simply searching one of the above manuals.
    Then set yourself a plan to dig deeper.
    - Read a chapter a day from the Concepts Manual.
    - Take a look in your alert log. One of the first things listed at startup is the initialization parms with non-default values. Read up on each one of them in the Reference Manual.
    - Take a look at your listener.ora, tnsnames.ora, and sqlnet.ora files. Go to the Network Administrators manual and read up on everything you see in those files.
    - When you have finished reading the Concepts Manual, do it again.
    Give a man a fish and he eats for a day. Teach a man to fish and he eats for a lifetime.

  • Missing archived logs in v$archived_log

    I want to monitor if system accounts such as system, sys or other DBA accounts
    did any DML in my application schema. What are the minimal audit statements?
    needed to accomplish this. I know using Oracle Database Vault one can set realm to restrict this but I do
    not have Data Vault, just looking to audit this using Oracle’s database auditing.
    My organization also has Oracle Audi Vault, but Database Auditing Events have to be set in database
    first for collection agent to pass this information to Oracle Audit Vault server.
    Thanks a lot.

    Duplicate post
    Please ignore
    Missing archived logs in v$archived_log
    Handle:      user632098
    Status Level:      Newbie
    Registered:      Apr 20, 2008
    Total Posts:      115
    Total Questions:      29 (28 unresolved)
    Edited by: sb92075 on Dec 19, 2009 4:49 PM

  • Reg Records Missing in v$archived_log view

    Hi,
    Physically archives are available from sequence 79 to 620
    But in v$archived_log only from sequence 526 and completion date 24 Apr 2010 is available.
    I have not taken any backup of archive log thro rman or i have not set any retention policy.
    Can some explain the reason for this.
    Thanks
    Krishna

    Krishna VV wrote:
    Hi,
    Physically archives are available from sequence 79 to 620
    But in v$archived_log only from sequence 526 and completion date 24 Apr 2010 is available.
    I have not taken any backup of archive log thro rman or i have not set any retention policy.
    Can some explain the reason for this.
    Thanks
    KrishnaDear Krishna
    Are you sure that you're checking the correct database (and archived redo log files)?
    What's the first and last archived redo log sequence number and timestamp?
    Could you check whether you're looking to the correct directory by getting LOG_ARCHIVE_DEST_n parameter?
    You can register missed archived redo log files using the following command:
    alter database register logfile 'log_file_name';

  • Unwanted record in v$archived_log

    Hello All,
    v$archived_log view shows archive log record for previous incarnation also.
    Is there any way we can exclude these record from this view i mean it should show record for current incarnation only not for the previous one
    Database version Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
    Regards
    Vinay

    Hi,
    First thing i will tell u why u remove this. U know this is needed for Database recovery.
    If u really remove this one plse recreate controlfile.

Maybe you are looking for

  • I want to pick the Exp.GL A/c of GRN with the help of IR Doc.(INv.Verifica)

    Dear All,         CAn i know how can i pick the GL Account of GRN Doc.No.with the help of Invoice Doc.No.(Inv.Verification).From which table i can take these information. Please answer me immediately so that i can also reward point & the requirement

  • During costing batch price is not picking

    Hi, Thanks  in advance, We activated  batch valuation type with FIFO activation for materials procured externally , while running costing system  not picking batch price, it is picking moving  average price , Thanks and Regards, prema.d

  • Swfs not displaying in IE, using SWFObject2

    Hi, I have a site I did a couple years ago, and have had to open it up, and now none of the SWFs display in IE. In my template I deleted my old Flash nav and reinserted it (insert/media/swf) and then I got a white box where the navigation should be.

  • Finding a common Time Dimension in DSO and InfoCube

    Hi, I am working on creating a MultiProvider which is a combination of 2 COPA InfoCubes, Open Orders DSO and a Shipment Data DSO. I want to use the 'Requested Delivery Period' from Open Orders DSO and a custom field ZSHIPMONTH from the Shipments Data

  • SALESPERSONS COMMISSIONS PROCESS

    Hai Friends I would request to provide information on  SALESPERSONS COMMISSIONS PROCESS  in SAP SD . 1. What are the IMG Settings needed. 2. What are the master data , I have to create . 3. Without implementing HR module , Can I configure  SALESPERSO