Reduce Archive logs

Hi,
I have a database with a schema that gets refreshed nightly (user level export/import). This is generating a lot of redo logs. I have a space crunch for archive log location but cannot turn off archiving.
How could I reduce the redo log generation of the job?
Thanks,
Prachi

if you already have index then yes oracle will mainten it unless it is unusable but if you dont have index then oracle will not create it if you export it with indexes=n
well lets see if thats correct or not...
SQL> create table exp_test(id number,name varchar2(20));
Table created.
SQL> create index exp_test_idx on exp_test(id);
Index created.
SQL> insert into exp_test values(1,'larry');
1 row created.
SQL> insert into exp_test values(2,'bill');
1 row created.
SQL> commit;
Commit complete.
--export table without index
C:\junk>exp scott/tiger file=exp_test_noindex.dmp indexes=n tables=exp_test
. . exporting table EXP_TEST 2 rows exported
Export terminated successfully without warnings.
--export table with index
C:\junk>exp scott/tiger file=exp_test_index.dmp indexes=y tables=exp_test
. . exporting table EXP_TEST 2 rows exported
Export terminated successfully without warnings.
SQL> select index_name from user_indexes where table_name='EXP_TEST';
INDEX_NAME
EXP_TEST_IDX
SQL> DROP TABLE EXP_tEST;
Table dropped.
--import table with indexes
C:\junk>imp scott/tiger file=exp_test_index.dmp tables=exp_test
. . importing table "EXP_TEST" 2 rows imported
Import terminated successfully without warnings.
--index is created
SQL> select index_name from user_indexes where table_name='EXP_TEST';
INDEX_NAME
EXP_TEST_IDX
SQL> drop table exp_test;
Table dropped.
--import table without any indexes
C:\junk>imp scott/tiger file=exp_test_noindex.dmp tables=exp_test
. . importing table "EXP_TEST" 2 rows imported
Import terminated successfully without warnings.
--there is no index
SQL> select index_name from user_indexes where table_name='EXP_TEST';
no rows selected

Similar Messages

  • Reduce amount of archived log generated.

    RDBMS version : 9.2.0.8
    SQL> SELECT tablespace_name, force_logging FROM dba_tablespaces;
    TABLESPACE_NAME FORCE_LOGGING
    SYSTEM NO
    Above is what status of database, but when I do maintenance work of rebuilding index tablespace I get day or two worth of archived log files.
    and I dont' think ALTER DATABASE no force logging will reduce the amount of log generated.
    Is there any other method available?
    thanks

    Hi,
    if you force logging for a tablespace or for the database, then this means only that any nologging clause that comes with statements related to segments in that tablespace/database is ignored. No force logging is the default.
    In order to reduce the amount of redo protocol, you may consider to use NOLOGGING for the rebuild of your indexes:
    create index <indexname> on <table(column)> nologging;Or you put the tablespace in NOLOGGING in which the indexes are created in:
    alter tablespace <indextablespace> nologging;Or (perhaps even better) simply leave the indexes as they are. Most indexes do not need a rebuild anyway.
    Kind regards
    Uwe
    http://uhesse.wordpress.com

  • Error while taking archive log backup

    Dear all,
    We are getting the below mentioned error while taking the archive log backup
    ============================================================================
    BR0208I Volume with name RRPA02 required in device /dev/rmt0.1
    BR0210I Please mount BRARCHIVE volume, if you have not already done so
    BR0280I BRARCHIVE time stamp: 2010-05-27 16.43.41
    BR0256I Enter 'c[ont]' to continue, 's[top]' to cancel BRARCHIVE:
    c
    BR0280I BRARCHIVE time stamp: 2010-05-27 16.43.46
    BR0257I Your reply: 'c'
    BR0259I Program execution will be continued...
    BR0280I BRARCHIVE time stamp: 2010-05-27 16.43.46
    BR0226I Rewinding tape volume in device /dev/rmt0 ...
    BR0351I Restoring /oracle/RRP/sapreorg/.tape.hdr0
    BR0355I from /dev/rmt0.1 ...
    BR0278W Command output of 'LANG=C cd /oracle/RRP/sapreorg && LANG=C cpio -iuvB .tape.hdr0 < /dev/rmt0.1':
    Can't read input
    ===========================================================================
    We are able to take offline, online backups but we are facing the above mentioned problem while taking archive log backup
    We are on ECC 6 / Oracle / AIX
    The kernel is latest
    The drive is working fine and there is no problem with the tapes as we have tried using diffrent tapes
    can this be a permissions issue?
    I ran saproot.sh but somehow it is setting owner as sidadm and group as sapsys to some of the br* files
    I tried by changing the permissions to oraSID : dba but still the error is the same
    Any suggestions?

    Means you have not initialized the medias but trying to take backups.
    First check how many medias you have entered in your tape count parameter for archive log backups (just go to initSID.sap and check)
    Then increase/reduce them to according to your archive backup plan >> Initialize all the tapes according to their name (same as you have initialized in initSID.sap) >> stick physical label to all the medias according to name >> Schedule archive backups
    It will not ask you for initialization as already you have initialized in second step.
    Suggestion: Use 7 medias per week (one tape per day)
    Regards,
    Nick Loy

  • Managing ARCHIVE Logs in Oracle 10.2.0.3

    I am working with a customer who seems to think there is a way of controling the database other than a custom JOB, script or RMAN in how it creates, manages and deletes its archive logs while running in archivelog mode. He wants the database to automatically delete obsolete archive logs. He also wants to control the duration in time between each time an archive log is written in order to stop the growth of archive logs and filling up disk space.
    I am saying this is not possible. You either configure RMAN to delete the obsolete or expired archive logs based on your retention policy or do it manually in the Enterprise Manager or Grid Control Console by deletenig obsolete or expired logs.
    Am I correct or am I off base here?

    4.1.3 Sizing Redo Log Files
    The size of the redo log files can influence performance, because the behavior of the database writer and archiver processes depend on the redo log sizes. Generally, larger redo log files provide better performance. Undersized log files increase checkpoint activity and reduce performance.
    Although the size of the redo log files does not affect LGWR performance, it can affect DBWR and checkpoint behavior. Checkpoint frequency is affected by several factors, including log file size and the setting of the FAST_START_MTTR_TARGET initialization parameter. If the FAST_START_MTTR_TARGET parameter is set to limit the instance recovery time, Oracle automatically tries to checkpoint as frequently as necessary. Under this condition, the size of the log files should be large enough to avoid additional checkpointing due to under sized log files. The optimal size can be obtained by querying the OPTIMAL_LOGFILE_SIZE column from the V$INSTANCE_RECOVERY view. You can also obtain sizing advice on the Redo Log Groups page of Oracle Enterprise Manager Database Control.
    It may not always be possible to provide a specific size recommendation for redo log files, but redo log files in the range of a hundred megabytes to a few gigabytes are considered reasonable. Size your online redo log files according to the amount of redo your system generates. A rough guide is to switch logs at most once every twenty minutes.
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/build_db.htm#sthref237
    If you are talking about data guard then:
    4.1.3 Sizing Redo Log Files
    The size of the redo log files can influence performance, because the behavior of the database writer and archiver processes depend on the redo log sizes. Generally, larger redo log files provide better performance. Undersized log files increase checkpoint activity and reduce performance.
    Although the size of the redo log files does not affect LGWR performance, it can affect DBWR and checkpoint behavior. Checkpoint frequency is affected by several factors, including log file size and the setting of the FAST_START_MTTR_TARGET initialization parameter. If the FAST_START_MTTR_TARGET parameter is set to limit the instance recovery time, Oracle automatically tries to checkpoint as frequently as necessary. Under this condition, the size of the log files should be large enough to avoid additional checkpointing due to under sized log files. The optimal size can be obtained by querying the OPTIMAL_LOGFILE_SIZE column from the V$INSTANCE_RECOVERY view. You can also obtain sizing advice on the Redo Log Groups page of Oracle Enterprise Manager Database Control.
    It may not always be possible to provide a specific size recommendation for redo log files, but redo log files in the range of a hundred megabytes to a few gigabytes are considered reasonable. Size your online redo log files according to the amount of redo your system generates. A rough guide is to switch logs at most once every twenty minutes.
    Automatic Deletion of Applied Archive Logs
    Archived logs, once they are applied on the logical standby database, will be automatically deleted by SQL Apply.
    This feature reduces storage consumption on the logical standby database and improves Data Guard manageability.
    See also:
    Oracle Data Guard Concepts and Administration for details
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14214/chapter1.htm#sthref269

  • Data guard real time apply vs archived log apply on physical standby

    Dear DBA's,
    last week i configuared DR , now the phyiscal stanby database is archive apply mode,
    i want to confirm is it better to apply the archived log or should i cahnge it to real time apply .
    give me sugesstions.
    Thanks and Regards
    Raja...

    One question are you using ARCH transport to move the redo? or have you configured standby redo logs and logwr transport (either async or syncronous), if you are using the archiver to transport the logs then you can not use real time apply.
    If you are using log writer to transpor the redo the realtime apply reduces the recovery time required if you need to failover as trher should be less redo to apply to bring the standby up to date, which mode you use to transport redo will depend on what is acceptable in terms of data loss and the impact on performance.

  • OVM 3.0 Database Creating Lots of Archive Logs

    Greetings - ever since we initially installed OVM 3.0 earlier this fall (~October), the OVM database has generated archive logs at a very rapid rate. It continually threatens to fill up our 16 GB filesystem dedicated to archive logs, even after daily backup and purging.
    Our OVM database itself is about 4-6 GB large, and we would need to increase the archive log filesystem to about 20-25 GB in size, which we see as unreasonable for such a small database.
    What is causing OVM to generate so many redo logs? Our best guess is that OVM is continuously gathering guest VM CPU usage on each physical server.
    Is there a way to configure the OVM application in order to reduce the amount of redo/archive logs being created?
    We are currently running 3.0.3, having upgraded each time a 3.0.* patch was released. OVMM running on OEL 6.1, database running on latest HP-UX.

    majedian21 wrote:
    Greetings - ever since we initially installed OVM 3.0 earlier this fall (~October), the OVM database has generated archive logs at a very rapid rate. It continually threatens to fill up our 16 GB filesystem dedicated to archive logs, even after daily backup and purging.I would log an SR with Oracle Support for this, so that Development can look at it. Sounds like your environment has lots of VMs running and yes, collecting usage stats for all of those environments. However, there may be some old data from the previous versions that's causing more stats to be collected than necessary.

  • Why size of archive log file increasing in merge clause

    my database is running in archive log mode.
    someone is running oracle merge statement. still it is running.
    He will issue commit after the operation.
    in that period redolog file increasing now.
    my question is why size of archive log file increasing with redolog file.
    i know that after commit archive log file should generate.(may be it is wrong).
    please suggest........
    Edited by: 855516 on Mar 13, 2012 11:18 AM

    855516 wrote:
    my database is running in archive log mode.
    someone is running oracle merge statement. still it is running.
    He will issue commit after the operation.
    in that period redolog file increasing now.
    my question is why size of archive log file increasing with redolog file.
    i know that after commit archive log file should generate.(may be it is wrong). No this is not correct that after commit archive log will generate....You know merge statement causes the insert (if data not present already) or update if database is present.. Obviously these operation will generate lots of redo if the amount of data been processed is high.
    If you feel that this operation is causing excessive of redo then root cause analysis should be done...
    For that use Logminer (excellent tool to provide segment level breakdown of redo size). V$logmnr_contens has columns redo block and redo byte address associated with the current redo
    change
    There are some gudlines in order to reduce redos( which may vary in any environment)
    1) check if there are unwanted indexes being used in tables which are refereed in merge. If yes then remove those could bring down the redo
    2) Use global temporary tables to reduce redo (if there is a need to keep data only temporarily in a session)
    3) Use nologging if possible (but see its implications)
    Hope this helps

  • Archive Logs in every 15 minutes(Oracle 11g 64 bit  EE on Linux RHEL 4

    In our production database we have very few transactions may be of few MB's in whole day but it is generating archive logs constantly in every 15 minutes(may be sometime in 14 minutes also) of file size 50 MB each and this way consume 4 GB of space in a day for archive log which is way above than expected.
    I have checked archive_lag_target and value of this is 0.
    Any clue why it is creating 50 MB archive log file after every 14-15 minutes?

    It's easy enough to reduce redo log file size without downtime; just add new smaller redo log files, switch logfile a couple of times and drop the old redo log files.
    However, if the redo logs are filling up before they switch, then this will probably only make matters worse.
    If the redo logs are switching before they are full then maybe you also need to consider log_checkpoint_interval and log_checkpoint_timeout settings.
    If the redo logs are filling up before they switch then use the techniques suggested by a couple of the other posters to track down the guilty SQL.

  • Archive Log Generation in EBusiness Suite

    Hi,
    I am responsible for EBusiness suite 11.5.10.2 AIX Production server. Until last week (for the past 1.5 years), there were excessive archive log generation (200 MB for every 10 mins) which has been reduced to (200 MB for every 4.5 hours).
    I am unable to understand this behavior. The number of users still remain the same and the usage is as usual.
    Is there a way I can check what has gone wrong? I could not see any errors also in the alert.log
    Please suggest what can be done.
    (I have raised this issue in Metalink Forum also and awaiting a response)
    Thanks
    qA

    Log/archive logs generation is directly related to the level of activities on the database, so it is almost certain that the level of activities have dropped significantly.
    If possible, can you run this query and post the result:
    select trunc(FIRST_TIME), count(SEQUENCE#) from v$archived_log
    where to_char(trunc(FIRST_TIME),'MONYYYY') = 'SEP2007'
    group by trunc(first_time)
    order by 1
    --Adams                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • Archive logs and recovering database with no RMAN

    Hello,
    I inherited a database with no RMAN backup activated but archive redo logs are activated and generating at every moment.
    As there is no rman backup I always thought that those archive redo logs were useless and because of reduced disk space, regularly I delete all of them.
    Then I read that archive redo logs can be usefull even if there is no RMAN. Archive redo logs can be used in a recovery situation like this:
    set all tablespaces in backup mode
    alter tablespace tsp1..tsp100 begin backup;
    copy all datafiles
    alter tablespace tsp1..tsp100 end backup;
    alter database create standby controlfile as 'c:\temp\sbytemp.ctl';
    copy of archivelogs from start begin backup time till nowAs I delete my archive logs, I don't have all ones from the first time. My question is:
    How many archive redo log files would I need to have? Would I need to have all archive logs that were generated from the first time? Or would be enough to have the last three or four ones?
    Thanks
    Edited by: user521219 on 21-may-2012 7:50

    How many archive redo log files would I need to have?
    Would I need to have all archive logs that were generated from the first time?
    would be enough to have the last three or four ones?You need all archive redo log from the moment you have started taking full backup.
    If you take full backup every night at 1:00 AM, you will need all archive redo logs that have transactions finished at and after 1:00 AM.

  • How to find out who deleted the archive logs

    Hi All,
    Recently some archive logs were deleted from one of our servers. Is there any way to find out which user has deleted the archive logs through OS or through database ?
    OS Version :-
    SunOS Generic_Virtual sun4u sparc SUNW,SPARC-Enterprise
    Database Version:-
    SQL*Plus: Release 9.2.0.8.0 - Production on Mon Apr 9 01:12:15 2012

    888132 wrote:
    Hi All,
    Recently some archive logs were deleted from one of our servers. Is there any way to find out which user has deleted the archive logs through OS or through database ?
    OS Version :-
    SunOS Generic_Virtual sun4u sparc SUNW,SPARC-Enterprise
    Database Version:-
    SQL*Plus: Release 9.2.0.8.0 - Production on Mon Apr 9 01:12:15 2012As explained by others, from oracle database there is no record if they are deleted from OS.
    But you can probably find the history of OS command been run with history command :). You can get the date and time.
    Following link can help
    http://stackoverflow.com/questions/99755/how-do-i-get-the-command-buffer-in-solaris-10
    http://www.cyberciti.biz/faq/unix-linux-bash-history-display-date-time/
    http://www.linuxquestions.org/questions/solaris-opensolaris-20/in-solaris-command-line-how-to-get-the-previous-commands-573814/
    But i suggest you to post in Sun OS forum to get more details as its nothing to do with Database(in this scenario)

  • ARCHIVE LOGS CREATED in WRONG FOLDER

    Hello,
    I'm facing an issue with the Archive logs.
    In my Db the parameters for Archive logs are
    log_archive_dest_1 string LOCATION=/u03/archive/SIEB MANDATORY REOPEN=30
    db_create_file_dest string /u01/oradata/SIEB/dbf
    db_create_online_log_dest_1 string /u01/oradata/SIEB/rdo
    But the archive logs are created in
    /u01/app/oracle/product/9.2.0.6/dbs
    Listed Below :
    bash-2.05$ ls -lrt *.arc
    -rw-r----- 1 oracle dba 9424384 Jan 9 09:30 SIEB_302843.arc
    -rw-r----- 1 oracle dba 7678464 Jan 9 10:00 SIEB_302844.arc
    -rw-r----- 1 oracle dba 1536 Jan 9 10:00 SIEB_302845.arc
    -rw-r----- 1 oracle dba 20480 Jan 9 10:00 SIEB_302846.arc
    -rw-r----- 1 oracle dba 10010624 Jan 9 10:30 SIEB_302847.arc
    -rw-r----- 1 oracle dba 104858112 Jan 9 10:58 SIEB_302848.arc
    bash-2.05$
    Does anyone have an Idea why this happens?
    Is this a Bug!!!
    Thxs

    But in another Db I've
    log_archive_dest string
    log_archive_dest_1 string LOCATION=/u03/archive/SIEB MANDATORY REOPEN=30
    and my archivelogs are in
    oracle@srvsdbs7p01:/u03/archive/SIEB/ [SIEB] ls -lrt /u03/archive/SIEB
    total 297696
    -rw-r----- 1 oracle dba 10010624 Jan 9 10:30 SIEB_302847.arc
    -rw-r----- 1 oracle dba 21573632 Jan 9 11:00 SIEB_302848.arc
    -rw-r----- 1 oracle dba 101450240 Jan 9 11:30 SIEB_302849.arc
    -rw-r----- 1 oracle dba 6308864 Jan 9 12:00 SIEB_302850.arc
    -rw-r----- 1 oracle dba 12936704 Jan 9 12:30 SIEB_302851.arc
    oracle@srvsdbs7p01:/u03/archive/SIEB/ [SIEB]

  • 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;

  • Archive Logs NOT APPLIED but transferred

    Hi Gurus,
    I have configured Primary & Standby databases in same Oracle Home. OS version is OEL 5. Database version is 10.2.0.1. I could get the archive logs in the standby site but they are not getting applied in the standby database. I don't have OLAP installed in my database version. Would this create this issue? However I attached my primary alert log details below for your reference:
    Thu Aug 30 23:55:37 2012
    Starting ORACLE instance (normal)
    Cannot determine all dependent dynamic libraries for /proc/self/exe
    Unable to find dynamic library libocr10.so in search paths
    RPATH = /ade/aime1_build2101/oracle/has/lib/:/ade/aime1_build2101/oracle/lib/:/ade/aime1_build2101/oracle/has/lib/:
    LD_LIBRARY_PATH is not set!
    The default library directories are /lib and /usr/lib
    Unable to find dynamic library libocrb10.so in search paths
    Unable to find dynamic library libocrutl10.so in search paths
    Unable to find dynamic library libocrutl10.so in search paths
    LICENSE_MAX_SESSION = 0
    LICENSE_SESSIONS_WARNING = 0
    Picked latch-free SCN scheme 2
    Autotune of undo retention is turned on.
    IMODE=BR
    ILAT =18
    LICENSE_MAX_USERS = 0
    SYS auditing is disabled
    ksdpec: called for event 13740 prior to event group initialization
    Starting up ORACLE RDBMS Version: 10.2.0.1.0.
    System parameters with non-default values:
    processes = 150
    sga_target = 289406976
    control_files = /home/oracle/oracle/product/10.2.0/db_1/oradata/newprim/control01.ctl, /home/oracle/oracle/product/10.2.0/db_1/oradata/newprim/control02.ctl, /home/oracle/oracle/product/10.2.0/db_1/oradata/newprim/control03.ctl
    db_file_name_convert = /home/oracle/oracle/product/10.2.0/db_1/oradata/newstand, /home/oracle/oracle/product/10.2.0/db_1/oradata/newprim
    log_file_name_convert = /home/oracle/oracle/product/10.2.0/db_1/oradata/newstand, /home/oracle/oracle/product/10.2.0/db_1/oradata/newprim, /home/oracle/oracle/product/10.2.0/db_1/flash_recovery_area/NEWSTAND/onlinelog, /home/oracle/oracle/product/10.2.0/db_1/flash_recovery_area/NEWPRIM/onlinelog
    db_block_size = 8192
    compatible = 10.2.0.1.0
    log_archive_config = DG_CONFIG=(newprim,newstand)
    log_archive_dest_1 = LOCATION=/home/oracle/oracle/product/10.2.0/db_1/oradata/newprim/arch/
    VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
    DB_UNIQUE_NAME=newprim
    log_archive_dest_2 = SERVICE=newstand LGWR ASYNC VALID_FOR=(online_logfiles,primary_role) DB_UNIQUE_NAME=newstand
    log_archive_dest_state_1 = enable
    log_archive_dest_state_2 = enable
    log_archive_max_processes= 30
    log_archive_format = %t_%s_%r.dbf
    fal_client = newprim
    fal_server = newstand
    db_file_multiblock_read_count= 16
    db_recovery_file_dest = /home/oracle/oracle/product/10.2.0/db_1/flash_recovery_area
    db_recovery_file_dest_size= 2147483648
    standby_file_management = AUTO
    undo_management = AUTO
    undo_tablespace = UNDOTBS1
    remote_login_passwordfile= EXCLUSIVE
    db_domain =
    dispatchers = (PROTOCOL=TCP) (SERVICE=newprimXDB)
    job_queue_processes = 10
    background_dump_dest = /home/oracle/oracle/product/10.2.0/db_1/admin/newprim/bdump
    user_dump_dest = /home/oracle/oracle/product/10.2.0/db_1/admin/newprim/udump
    core_dump_dest = /home/oracle/oracle/product/10.2.0/db_1/admin/newprim/cdump
    audit_file_dest = /home/oracle/oracle/product/10.2.0/db_1/admin/newprim/adump
    db_name = newprim
    db_unique_name = newprim
    open_cursors = 300
    pga_aggregate_target = 95420416
    PMON started with pid=2, OS id=28091
    PSP0 started with pid=3, OS id=28093
    MMAN started with pid=4, OS id=28095
    DBW0 started with pid=5, OS id=28097
    LGWR started with pid=6, OS id=28100
    CKPT started with pid=7, OS id=28102
    SMON started with pid=8, OS id=28104
    RECO started with pid=9, OS id=28106
    CJQ0 started with pid=10, OS id=28108
    MMON started with pid=11, OS id=28110
    MMNL started with pid=12, OS id=28112
    Thu Aug 30 23:55:38 2012
    starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
    starting up 1 shared server(s) ...
    Thu Aug 30 23:55:38 2012
    ALTER DATABASE MOUNT
    Thu Aug 30 23:55:42 2012
    Setting recovery target incarnation to 2
    Thu Aug 30 23:55:43 2012
    Successful mount of redo thread 1, with mount id 1090395834
    Thu Aug 30 23:55:43 2012
    Database mounted in Exclusive Mode
    Completed: ALTER DATABASE MOUNT
    Thu Aug 30 23:55:43 2012
    ALTER DATABASE OPEN
    Thu Aug 30 23:55:43 2012
    LGWR: STARTING ARCH PROCESSES
    ARC0 started with pid=16, OS id=28122
    ARC1 started with pid=17, OS id=28124
    ARC2 started with pid=18, OS id=28126
    ARC3 started with pid=19, OS id=28128
    ARC4 started with pid=20, OS id=28133
    ARC5 started with pid=21, OS id=28135
    ARC6 started with pid=22, OS id=28137
    ARC7 started with pid=23, OS id=28139
    ARC8 started with pid=24, OS id=28141
    ARC9 started with pid=25, OS id=28143
    ARCa started with pid=26, OS id=28145
    ARCb started with pid=27, OS id=28147
    ARCc started with pid=28, OS id=28149
    ARCd started with pid=29, OS id=28151
    ARCe started with pid=30, OS id=28153
    ARCf started with pid=31, OS id=28155
    ARCg started with pid=32, OS id=28157
    ARCh started with pid=33, OS id=28159
    ARCi started with pid=34, OS id=28161
    ARCj started with pid=35, OS id=28163
    ARCk started with pid=36, OS id=28165
    ARCl started with pid=37, OS id=28167
    ARCm started with pid=38, OS id=28169
    ARCn started with pid=39, OS id=28171
    ARCo started with pid=40, OS id=28173
    ARCp started with pid=41, OS id=28175
    ARCq started with pid=42, OS id=28177
    ARCr started with pid=43, OS id=28179
    ARCs started with pid=44, OS id=28181
    Thu Aug 30 23:55:44 2012
    ARC0: Archival started
    ARC1: Archival started
    ARC2: Archival started
    ARC3: Archival started
    ARC4: Archival started
    ARC5: Archival started
    ARC6: Archival started
    ARC7: Archival started
    ARC8: Archival started
    ARC9: Archival started
    ARCa: Archival started
    ARCb: Archival started
    ARCc: Archival started
    ARCd: Archival started
    ARCe: Archival started
    ARCf: Archival started
    ARCg: Archival started
    ARCh: Archival started
    ARCi: Archival started
    ARCj: Archival started
    ARCk: Archival started
    ARCl: Archival started
    ARCm: Archival started
    ARCn: Archival started
    ARCo: Archival started
    ARCp: Archival started
    ARCq: Archival started
    ARCr: Archival started
    ARCs: Archival started
    ARCt: Archival started
    LGWR: STARTING ARCH PROCESSES COMPLETE
    ARCt started with pid=45, OS id=28183
    LNS1 started with pid=46, OS id=28185
    Thu Aug 30 23:55:48 2012
    Thread 1 advanced to log sequence 68
    Thu Aug 30 23:55:48 2012
    ARCo: Becoming the 'no FAL' ARCH
    ARCo: Becoming the 'no SRL' ARCH
    Thu Aug 30 23:55:48 2012
    ARCp: Becoming the heartbeat ARCH
    Thu Aug 30 23:55:48 2012
    Thread 1 opened at log sequence 68
    Current log# 1 seq# 68 mem# 0: /home/oracle/oracle/product/10.2.0/db_1/oradata/newprim/redo01.log
    Successful open of redo thread 1
    Thu Aug 30 23:55:48 2012
    MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
    Thu Aug 30 23:55:48 2012
    SMON: enabling cache recovery
    Thu Aug 30 23:55:48 2012
    Successfully onlined Undo Tablespace 1.
    Thu Aug 30 23:55:48 2012
    SMON: enabling tx recovery
    Thu Aug 30 23:55:49 2012
    Database Characterset is WE8ISO8859P1
    replication_dependency_tracking turned off (no async multimaster replication found)
    Starting background process QMNC
    QMNC started with pid=47, OS id=28205
    Thu Aug 30 23:55:49 2012
    Error 1034 received logging on to the standby
    Thu Aug 30 23:55:49 2012
    Errors in file /home/oracle/oracle/product/10.2.0/db_1/admin/newprim/bdump/newprim_arc1_28124.trc:
    ORA-01034: ORACLE not available
    FAL[server, ARC1]: Error 1034 creating remote archivelog file 'newstand'
    FAL[server, ARC1]: FAL archive failed, see trace file.
    Thu Aug 30 23:55:49 2012
    Errors in file /home/oracle/oracle/product/10.2.0/db_1/admin/newprim/bdump/newprim_arc1_28124.trc:
    ORA-16055: FAL request rejected
    ARCH: FAL archive failed. Archiver continuing
    Thu Aug 30 23:55:49 2012
    ORACLE Instance newprim - Archival Error. Archiver continuing.
    Thu Aug 30 23:55:49 2012
    db_recovery_file_dest_size of 2048 MB is 9.77% used. This is a
    user-specified limit on the amount of space that will be used by this
    database for recovery-related files, and does not reflect the amount of
    space available in the underlying filesystem or ASM diskgroup.
    Thu Aug 30 23:55:50 2012
    Errors in file /home/oracle/oracle/product/10.2.0/db_1/admin/newprim/udump/newprim_ora_28120.trc:
    ORA-00604: error occurred at recursive SQL level 1
    ORA-12663: Services required by client not available on the server
    ORA-36961: Oracle OLAP is not available.
    ORA-06512: at "SYS.OLAPIHISTORYRETENTION", line 1
    ORA-06512: at line 15
    Thu Aug 30 23:55:50 2012
    Completed: ALTER DATABASE OPEN
    Thu Aug 30 23:56:33 2012
    FAL[server]: Fail to queue the whole FAL gap
    GAP - thread 1 sequence 1-33
    DBID 1090398314 branch 792689455
    Kindly, guide me please..
    -Vimal.

    CKPT: The trace file details are added below for your reference;
    /home/oracle/oracle/product/10.2.0/db_1/admin/newprim/bdump/newprim_arc1_28124.trc
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
    With the Partitioning and Data Mining options
    ORACLE_HOME = /home/oracle/oracle/product/10.2.0/db_1
    System name:     Linux
    Node name:     localhost.localdomain
    Release:     2.6.18-8.el5PAE
    Version:     #1 SMP Tue Jun 5 23:39:57 EDT 2007
    Machine:     i686
    Instance name: newprim
    Redo thread mounted by this instance: 1
    Oracle process number: 17
    Unix process pid: 28124, image: [email protected] (ARC1)
    *** SERVICE NAME:() 2012-08-30 23:55:48.314
    *** SESSION ID:(155.1) 2012-08-30 23:55:48.314
    kcrrwkx: nothing to do (start)
    Redo shipping client performing standby login
    OCISessionBegin failed -1
    .. Detailed OCI error val is 1034 and errmsg is 'ORA-01034: ORACLE not available
    *** 2012-08-30 23:55:49.723 60679 kcrr.c
    Error 1034 received logging on to the standby
    Error 1034 connecting to destination LOG_ARCHIVE_DEST_2 standby host 'newstand'
    Error 1034 attaching to destination LOG_ARCHIVE_DEST_2 standby host 'newstand'
    ORA-01034: ORACLE not available
    *** 2012-08-30 23:55:49.723 58941 kcrr.c
    kcrrfail: dest:2 err:1034 force:0 blast:1
    kcrrwkx: unknown error:1034
    ORA-16055: FAL request rejected
    ARCH: Connecting to console port...
    ARCH: Connecting to console port...
    kcrrwkx: nothing to do (end)
    *** 2012-08-31 00:00:43.417
    kcrrwkx: nothing to do (start)
    *** 2012-08-31 00:05:43.348
    kcrrwkx: nothing to do (start)
    *** 2012-08-31 00:10:43.280
    kcrrwkx: nothing to do (start)
    *** 2012-08-31 00:15:43.217
    kcrrwkx: nothing to do (start)
    *** 2012-08-31 00:20:43.160
    kcrrwkx: nothing to do (start)
    *** 2012-08-31 00:25:43.092
    kcrrwkx: nothing to do (start)
    *** 2012-08-31 00:30:43.031
    kcrrwkx: nothing to do (start)
    *** 2012-08-31 00:35:42.961
    kcrrwkx: nothing to do (start)
    *** 2012-08-31 00:40:42.890
    kcrrwkx: nothing to do (start)
    *** 2012-08-31 00:45:42.820
    kcrrwkx: nothing to do (start)
    *** 2012-08-31 00:50:42.755
    kcrrwkx: nothing to do (start)
    *** 2012-08-31 00:55:42.686
    kcrrwkx: nothing to do (start)
    *** 2012-08-31 01:00:42.631
    kcrrwkx: nothing to do (start)
    *** 2012-08-31 01:05:42.565
    kcrrwkx: nothing to do (start)
    *** 2012-08-31 01:10:42.496
    kcrrwkx: nothing to do (start)
    Mahir: Yes I have my 4 standby redo logs!
    I created the standby manually without using RMAN.
    Hemant: if it asks for even first thread, then obviously it shows nothing is applied on Standby. By the way so it is not called a 'GAP', I think..!
    Thanks.

  • How to delete the data in archived log files

    hi
    how can i delete the enteries in archived log files. and what is the disadvantage of deleting archived log enteries.

    There is no documented way to delete data stored in archived log files: you can only remove the archived log files if needed.

Maybe you are looking for