Delete archive log files on physical standby

I want to delete the archive log files on the phsical standby database when they were applied. The archive log files are in the flash recovery area. So i used
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
in rman.
My question:
Does rman delete the archive log files immediately when they are applied or when the disk space becomes scarce?

Hi,
They're marked as reclaimable when applied, so they're still on the disk but when the flah recovery area will become full they'll be deleted to give space to the new one, and so...
Loïc

Similar Messages

  • Will RMAN delete archive log files on a Standby server?

    Environment:
    Oracle 11.2.0.3 EE on Solaris 10.5
    I am currently NOT using an RMAN repository (coming soon).
    I have a Primary database sending log files to a Standby.
    My Retention Policy is set to 'RECOVERY WINDOW OF 8 DAYS'.
    Question: Will RMAN delete the archive log files on the Standby server after they become obsolete based on the Retention Policy or do I need to remove them manually via O/S command?
    Does the fact that I'm NOT using an RMAN Repository at the moment make a difference?
    Couldn't find the answer in the docs.
    Thanks very much!!
    -gary

    Hello again Gary;
    Sorry for the delay.
    Why is what you suggested better?
    No, its not better, but I prefer to manage the archive. This method works, period.
    Does that fact (running a backup every 4 hours) make my archivelog deletion policy irrelevant?
    No. The policy is important.
    Having the Primary set to :
    CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBYBut set to "NONE" on the Standby.
    Means the worst thing that can happen is RMAN will bark when you try to delete something. ( this is a good thing )
    How do I prevent the archive backup process from backing up an archive log file before it gets shipped to the standby?
    Should be a non-issue, the archive does not move, the REDO is transported and applied. There's SQL to monitor both ( Transport and Apply )
    For Data Guard I would consider getting a copy of
    "Oracle Data Guard 11g Handbook" - Larry Carpenter (AKA Dr. Paranoid ) ISBN 978-0-07-162111-2
    Best Oracle book I've read in 10 years. Covers a ton of ground clearly.
    Also Data Guard forum here :
    Data Guard
    Best Regards
    mseberg
    Edited by: mseberg on Apr 10, 2012 4:39 PM

  • How to delete archive log files from ASM through Grid Control

    Hi
    Anybody suggest me how to delete archive log files from ASM through Grid Control.
    Thanks

    It is important to specify both, the oracle version and os version when posting, so confusions can be avoided.
    In this particular case, since you are referring to asm and grid control you could be talking about either 10gR1, 10gR2 or 11gR1; but I strongly suggest you to avoid us to be guessing. In either case, you sould go to the maintenance tab of the target database and program a scheduled 'delete noprompt obsolete;' procedure. This will purge the information stored at the Flash recovery area, which I assume you have declared inside the ASM.
    ~ Madrid
    http://hrivera99.blogspot.com/

  • Manual delete archived log files

    Because we don't have RMAN in our development server, I need to use manual operation to delete all archived logs. Is my procedure correct and safe?
    SHUTDOWN IMMEDIATE
    STARTUP MOUNT
    ALTER DATABASE NOARCHIVELOG;
    EXITRun OS command to manually delete archived log files:
    rm /oradata/arch/*
    Login to sqlplus
    SHUTDOWN IMMEDIATE
    STARTUP MOUNT
    ALTER DATABASE ARCHIVELOG;
    STARTUP OPENThanks!

    linuxos wrote:
    Oh I suppose RMAN need to be configured somthing before use. I tried it, and find no pre-requisite is required. Thanks!
    If the archives are deleted manually in open mode, how can Oracle match the archived logs' retention policy? Does Oracle store the archived logs in data dictionary?While you can delete archivelogs manually any time you want, you should let rman manage them with appropriate rman commands, preferably in a script that you schedule for regular execution.
    Some of your questions lead me to question if you understand that archivelogs are not actively open by the database, and they technically are not part of the database. They are simply a series of "offline" copies of the online redo logs. They are written to once, when an online redo is being archived, then they just sit there until needed for a recovery.

  • How can we delete archive log files from OEM

    Hi,
    I took backup of the archive log file and deleted it at OS level but in it is not reflecting in the EM can any one tell me how to delete archive log files from OEM.
    any help will be appreciated.
    Regards,
    Ashraf

    This link?
    http://download-west.oracle.com/docs/cd/B10501_01/em.920/a96670/ch_backp.htm#26936

  • When to delete Archive Log files ? and is safe to delete ?

    Hi all,
    I have a question, my DB is running in Archive Log mode and is growing day by day, so should I delete archive log files and where i find that my which files are old and how to delete theses files, for info I also take full RMAN and export backup regularly .
    abbas

    Well, if you're not comfortable with Backup and Recovery principles, i'd advise you to first read TFM: Backup and Recovery Concept(click) for you data safety's sake.
    Anyway, just to give you a glance at what could happen, immagine suche a situation where your database is made of 5 different datafiles (whatever they are - SYSTEM, SYSAUX, UNDO, ...), controlfiles and online redo logs. If, for example your backup is done in a timeline such as:T0 : Backup datafile F1 and F2
    T1 : Backup datafile F2 and controlfile
    T2 : Backup datafile F3, F4
    T3 : Backup datafile F5
    T0' : Backup datafile F1 and F2
    T1' : Backup datafile F2 and controlfile
    T2' : Backup datafile F3, F4
    T3' : Backup datafile F5
    ...If your server crashes (for example is thrown though the 5th floor window..) in order to make a full recovery, you could proceed multiple ways.
    . Restore files from Tx' backups. Then you'd need every archived redo logs created from T0' to now in order to be able to do a full recovery.
    . Restore files from backups; T3, T0', T2' and rectreate controlfile. Then you'd need every archived redo log created from T3 (inclusive).
    . Restore Tx backup, ...
    . Restore ...
    and so on.
    What's important is that you're at least able to resynch a full-set backup. What I mean is: if you restored "T3, T0', T2' and rectreate controlfile", in order to open the database you'll absolutely need every archived redo log created between T3 and T2' inclusive. If one is missions, you won't be able to open it.
    That is the principle. Read the concept book I linked to get more infos.
    Regards,
    Yoann.

  • Delete archive log file

    hello,
    I am using oracle 10g on linux i want to delete archive log file automaticaly there is any way to do this.or anyone can tell me scripts for do this.ur help regarding this is highly appreciated
    Regard,s
    Umair Iqbal

    Hi,
    Can you please let us know why you want to delete the archive log file?
    BTW, you can use RMAN to achieve this by taking the backup of archive log and delete the original file using the following command:
    Backup archivelog all delete input;Regards

  • How to delete archive log file

    hii,
    presently i am working on oracle 10gR2 on windows server 2003.
    hard disk drive is almost full.
    when i execute this command
    "DELETE EXPIRED ARCHIVE LOG ALL";
    it give message
    "specifies does not match any archive log in the recovery catalog"
    how can i delete archive log files ??
    Regards
    Vaibhav Dixit

    these are the list
    RMAN> list archivelog all;
    List of Archived Log Copies
    Key Thrd Seq S Low Time Name
    696 1 341 A 25-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_341_758982530.ARC
    698 1 342 A 26-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_342_758982530.ARC
    700 1 343 A 26-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_343_758982530.ARC
    702 1 344 A 26-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_344_758982530.ARC
    704 1 345 A 26-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_345_758982530.ARC
    705 1 346 A 26-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_346_758982530.ARC
    708 1 347 A 26-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_347_758982530.ARC
    710 1 348 A 27-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_348_758982530.ARC
    712 1 349 A 27-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_349_758982530.ARC
    714 1 350 A 27-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_350_758982530.ARC
    716 1 351 A 28-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_351_758982530.ARC
    719 1 352 A 28-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_352_758982530.ARC
    720 1 353 A 28-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_353_758982530.ARC
    721 1 354 A 28-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_354_758982530.ARC
    722 1 355 A 28-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_355_758982530.ARC
    727 1 356 A 29-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_356_758982530.ARC
    728 1 357 A 29-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_357_758982530.ARC
    730 1 358 A 29-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_358_758982530.ARC
    732 1 359 A 29-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_359_758982530.ARC
    734 1 360 A 29-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_360_758982530.ARC
    736 1 361 A 30-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_361_758982530.ARC
    738 1 362 A 30-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_362_758982530.ARC
    740 1 363 A 30-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_363_758982530.ARC
    741 1 364 A 30-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_364_758982530.ARC
    742 1 365 A 30-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_365_758982530.ARC
    743 1 366 A 30-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_366_758982530.ARC
    744 1 367 A 30-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_367_758982530.ARC
    745 1 368 A 30-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_368_758982530.ARC
    746 1 369 A 30-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_369_758982530.ARC
    753 1 370 A 30-NOV-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_370_758982530.ARC
    756 1 371 A 01-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_371_758982530.ARC
    758 1 372 A 01-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_372_758982530.ARC
    759 1 373 A 01-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_373_758982530.ARC
    763 1 374 A 01-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_374_758982530.ARC
    764 1 375 A 02-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_375_758982530.ARC
    767 1 376 A 02-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_376_758982530.ARC
    768 1 377 A 02-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_377_758982530.ARC
    770 1 378 A 02-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_378_758982530.ARC
    772 1 379 A 02-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_379_758982530.ARC
    774 1 380 A 02-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_380_758982530.ARC
    776 1 381 A 03-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_381_758982530.ARC
    778 1 382 A 03-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_382_758982530.ARC
    780 1 383 A 03-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_383_758982530.ARC
    782 1 384 A 03-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_384_758982530.ARC
    784 1 385 A 04-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_385_758982530.ARC
    785 1 386 A 04-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_386_758982530.ARC
    788 1 387 A 05-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_387_758982530.ARC
    790 1 388 A 05-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_388_758982530.ARC
    791 1 389 A 05-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_389_758982530.ARC
    792 1 390 A 05-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_390_758982530.ARC
    793 1 391 A 06-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_391_758982530.ARC
    794 1 392 A 06-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_392_758982530.ARC
    795 1 393 A 06-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_393_758982530.ARC
    796 1 394 A 06-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_394_758982530.ARC
    797 1 395 A 06-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_395_758982530.ARC
    798 1 396 A 06-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_396_758982530.ARC
    799 1 397 A 06-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_397_758982530.ARC
    800 1 398 A 06-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_398_758982530.ARC
    801 1 399 A 07-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_399_758982530.ARC
    802 1 400 A 07-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_400_758982530.ARC
    803 1 401 A 07-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_401_758982530.ARC
    804 1 402 A 07-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_402_758982530.ARC
    805 1 403 A 07-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_403_758982530.ARC
    806 1 404 A 07-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_404_758982530.ARC
    808 1 405 A 07-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_405_758982530.ARC
    814 1 406 A 07-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_406_758982530.ARC
    816 1 407 A 07-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_407_758982530.ARC
    817 1 408 A 07-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_408_758982530.ARC
    822 1 409 A 07-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_409_758982530.ARC
    823 1 410 A 07-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_410_758982530.ARC
    824 1 411 A 07-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_411_758982530.ARC
    826 1 412 A 07-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_412_758982530.ARC
    829 1 413 A 07-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_413_758982530.ARC
    831 1 414 A 07-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_414_758982530.ARC
    839 1 415 A 08-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_415_758982530.ARC
    841 1 416 A 08-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_416_758982530.ARC
    843 1 417 A 08-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_417_758982530.ARC
    844 1 418 A 08-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_418_758982530.ARC
    848 1 419 A 08-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_419_758982530.ARC
    849 1 420 A 08-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_420_758982530.ARC
    850 1 421 A 08-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_421_758982530.ARC
    851 1 422 A 08-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_422_758982530.ARC
    852 1 423 A 08-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_423_758982530.ARC
    853 1 424 A 08-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_424_758982530.ARC
    854 1 425 A 08-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_425_758982530.ARC
    856 1 426 A 08-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_426_758982530.ARC
    862 1 427 A 08-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_427_758982530.ARC
    870 1 428 A 09-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_428_758982530.ARC
    872 1 429 A 09-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_429_758982530.ARC
    874 1 430 A 09-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_430_758982530.ARC
    875 1 431 A 09-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_431_758982530.ARC
    878 1 432 A 09-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_432_758982530.ARC
    880 1 433 A 09-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_433_758982530.ARC
    882 1 434 A 10-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_434_758982530.ARC
    884 1 435 A 10-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_435_758982530.ARC
    886 1 436 A 10-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_436_758982530.ARC
    888 1 437 A 10-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_437_758982530.ARC
    890 1 438 A 11-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_438_758982530.ARC
    891 1 439 A 11-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_439_758982530.ARC
    893 1 440 A 12-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_440_758982530.ARC
    896 1 441 A 12-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_441_758982530.ARC
    898 1 442 A 12-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_442_758982530.ARC
    900 1 443 A 12-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_443_758982530.ARC
    901 1 444 A 12-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_444_758982530.ARC
    902 1 445 A 13-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_445_758982530.ARC
    903 1 446 A 13-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_446_758982530.ARC
    904 1 447 A 13-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_447_758982530.ARC
    910 1 448 A 13-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_448_758982530.ARC
    912 1 449 A 13-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_449_758982530.ARC
    914 1 450 A 13-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_450_758982530.ARC
    916 1 451 A 13-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_451_758982530.ARC
    918 1 452 A 13-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_452_758982530.ARC
    920 1 453 A 13-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_453_758982530.ARC
    922 1 454 A 13-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_454_758982530.ARC
    924 1 455 A 14-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_455_758982530.ARC
    926 1 456 A 14-DEC-11 E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ES
    PL\1_456_758982530.ARC
    RMAN> delete noprompt expired archivelog all;
    released channel: ORA_DISK_1
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: sid=77 devtype=DISK
    specification does not match any archive log in the recovery catalog

  • How do I setup RMAN not to delete archive log files on the source database so GoldenGate can process DDL/DML changes?

    I want to setup RMAN not to delete any archive log files that will be used by GoldenGate.   Once GoldenGate is completed with the archive log file, the archive log file can be backup and deleted by RMAN.   It's my understanding that I can issue the following command "REGISTER EXTRACT <ext_name>, LOGRETENTION" to enable to functionally.   Is this the only thing I need to do to execute to enable this functionally?

    Hello,
    Yes this is the rigth way  using clasic capture.
    Using the command : REGISTER EXTRACT Extract_name LOGRETENTION.
    Create a Oracle Streams Group Capture (Artificial)  that prevent RMAN archive deletion if these are pending to process for Golden Gate capture process.
    You can see this integration doing a SELECT * FROM DBA_CAPTURE; after execute the register command.
    Then, when RMAN try to delete a archive file pending to process for GG this warning appear AT RMAN logs:
    Error:     RMAN 8317 (RMAN-08317 RMAN-8317)
    Text:     WARNING: archived log not deleted, needed for standby or upstream capture process.
    Then , this is a good manageability feature. I think is a 11.1 GG new feature.
    Tip. To avoid RMAN backup multiples times a archive pending to process, there is a option called BACKUP archivelog not backed 1 times.
    If you remove a Capture process that is registered with the database you need to use this comand to remove the streams capture group:
    unREGISTER EXTRACT extract_name LOGRETENTION;
    Then if you query dba_capture, the artificial Streams group is deleted.
    I hope help.
    Regards
    Arturo

  • How do i delete archive log files manually?

    My db is running in oracle 10.2.0.4. somehow, the RMAN command is not deleting archived backup files. I need to delete those files manually at os level. how do i find till which archivelog files are backed up through RMAN?

    RMAN> connect target
    connected to target database: INVENT (DBID=1001824944)
    using target database control file instead of recovery catalog
    RMAN> show all;
    RMAN configuration parameters are:
    CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
    CONFIGURE BACKUP OPTIMIZATION OFF; # default
    CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
    CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
    CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
    CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
    CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
    CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
    CONFIGURE MAXSETSIZE TO UNLIMITED; # default
    CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
    CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
    CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
    CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/ora/app/oracle/product/10.2.0/db_1/dbs/snapcf_INVENT.f'; # default
    RMAN>
    Here is the commands....
    connect target;
    run
    allocate channel t1 device type disk format /target/ret/%U';
    set command id to 'L0 Backup';
    delete noprompt obsolete;
    backup incremental level 0 as compressed backupset database;
    release channel t1;
    connect target;
    run
    allocate channel t1 device type disk format /target/ret/%U';
    set command id to 'L1 Backup';
    delete noprompt obsolete;
    backup incremental level 1 as compressed backupset database;
    release channel t1;
    }

  • How to delete archived log file in rman

    Hi friends,
    I got a series list of archived log validation failed by crosscheck.
    How can I delete these files to release space?
    Thanks for help!
    Jimmy

    user589812 wrote:
    Thanks for your help!
    RMAN> report obsolete;
    RMAN> DELETE OBSOLETE;
    these twon way does not work. the fail backup is still in backup report by EM
    How do I get a backup set number?
    JIm
    Edited by: user589812 on Nov 17, 2008 2:52 PMDELETE OBSOLETE deletes the backups that are no longer needed to meet the recovery policy.
    DELETE EXPIRED deletes backups that are found (through a CROSSCHECK) to no longer exist - usually because the files were deleted outside of rman.
    Documentation is at tahiti.oracle.com

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

  • How to delete Archive log files in ASM?

    Hi,
    Env: Sun Solaris
    10.2.0.2.0 RAC with 2 node cluster
    using ASM
    I noticed that there are directories for ARCHIVELOG for every day.
    for example:
    2007_01_13/
    2007_01_29/
    ASMCMD> pwd
    +DG01/<<INSTANCENAME>>/ARCHIVELOG
    a) How to purge these files/directories automatically?
    b) We use RMAN for backup. Not sure if these directories are created by RMAN
    Thanks

    Natrajan,
    Since I don't remember what exactly I did which caused stopping those folder from being created, this is what I would try.
    You have mentioned that these folder are being created at
    "+DG01/<<INSTANCENAME>>/ARCHIVELOG" in your first post. Is this the same location what you set at init/spfile.ora ?
    "*.log_archive_dest_1='LOCATION=+<<DISKNAME?>/<<DBNAEM>>/'"
    If yes please change one of the nodes
    node1.log_arch_dest_1 to some where else which is not the current location. Then watch whether these directories being created at this location. If they are not created we have an answer what causing this folder creation.
    This is just a suggestion.
    Do you see the filename inside these foloder somewhat in this pattern
    "o1_mf_1_9403_2pxpr9dw_.arc"
    Let me know what you think? Again it is just a suggestion I really don't know the answer.
    Thanks
    Leo

  • I have one problem with Data Guard. My archive log files are not applied.

    I have one problem with Data Guard. My archive log files are not applied. However I have received all archive log files to my physical Standby db
    I have created a Physical Standby database on Oracle 10gR2 (Windows XP professional). Primary database is on another computer.
    In Enterprise Manager on Primary database it looks ok. I get the following message “Data Guard status Normal”
    But as I wrote above ”the archive log files are not applied”
    After I created the Physical Standby database, I have also done:
    1. I connected to the Physical Standby database instance.
    CONNECT SYS/SYS@luda AS SYSDBA
    2. I started the Oracle instance at the Physical Standby database without mounting the database.
    STARTUP NOMOUNT PFILE=C:\oracle\product\10.2.0\db_1\database\initluda.ora
    3. I mounted the Physical Standby database:
    ALTER DATABASE MOUNT STANDBY DATABASE
    4. I started redo apply on Physical Standby database
    alter database recover managed standby database disconnect from session
    5. I switched the log files on Physical Standby database
    alter system switch logfile
    6. I verified the redo data was received and archived on Physical Standby database
    select sequence#, first_time, next_time from v$archived_log order by sequence#
    SEQUENCE# FIRST_TIME NEXT_TIME
    3 2006-06-27 2006-06-27
    4 2006-06-27 2006-06-27
    5 2006-06-27 2006-06-27
    6 2006-06-27 2006-06-27
    7 2006-06-27 2006-06-27
    8 2006-06-27 2006-06-27
    7. I verified the archived redo log files were applied on Physical Standby database
    select sequence#,applied from v$archived_log;
    SEQUENCE# APP
    4 NO
    3 NO
    5 NO
    6 NO
    7 NO
    8 NO
    8. on Physical Standby database
    select * from v$archive_gap;
    No rows
    9. on Physical Standby database
    SELECT MESSAGE FROM V$DATAGUARD_STATUS;
    MESSAGE
    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
    ARC0: Becoming the 'no FAL' ARCH
    ARC0: Becoming the 'no SRL' ARCH
    ARC1: Becoming the heartbeat ARCH
    Attempt to start background Managed Standby Recovery process
    MRP0: Background Managed Standby Recovery process started
    Managed Standby Recovery not using Real Time Apply
    MRP0: Background Media Recovery terminated with error 1110
    MRP0: Background Media Recovery process shutdown
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[1]: Assigned to RFS process 2148
    RFS[1]: Identified database type as 'physical standby'
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[2]: Assigned to RFS process 2384
    RFS[2]: Identified database type as 'physical standby'
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[3]: Assigned to RFS process 3188
    RFS[3]: Identified database type as 'physical standby'
    Primary database is in MAXIMUM PERFORMANCE mode
    Primary database is in MAXIMUM PERFORMANCE mode
    RFS[3]: No standby redo logfiles created
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[4]: Assigned to RFS process 3168
    RFS[4]: Identified database type as 'physical standby'
    RFS[4]: No standby redo logfiles created
    Primary database is in MAXIMUM PERFORMANCE mode
    RFS[3]: No standby redo logfiles created
    10. on Physical Standby database
    SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;
    PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    RFS IDLE 0 0 0 0
    RFS IDLE 0 0 0 0
    RFS IDLE 1 9 13664 2
    RFS IDLE 0 0 0 0
    10) on Primary database:
    select message from v$dataguard_status;
    MESSAGE
    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
    ARCm: Becoming the 'no FAL' ARCH
    ARCm: Becoming the 'no SRL' ARCH
    ARCd: Becoming the heartbeat ARCH
    Error 1034 received logging on to the standby
    Error 1034 received logging on to the standby
    LGWR: Error 1034 creating archivelog file 'luda'
    LNS: Failed to archive log 3 thread 1 sequence 7 (1034)
    FAL[server, ARCh]: Error 1034 creating remote archivelog file 'luda'
    11)on primary db
    select name,sequence#,applied from v$archived_log;
    NAME SEQUENCE# APP
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00003_0594204176.001 3 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00004_0594204176.001 4 NO
    Luda 4 NO
    Luda 3 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00005_0594204176.001 5 NO
    Luda 5 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00006_0594204176.001 6 NO
    Luda 6 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00007_0594204176.001 7 NO
    Luda 7 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00008_0594204176.001 8 NO
    Luda 8 NO
    12) on standby db
    select name,sequence#,applied from v$archived_log;
    NAME SEQUENCE# APP
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00004_0594204176.001 4 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00003_0594204176.001 3 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00005_0594204176.001 5 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00006_0594204176.001 6 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00007_0594204176.001 7 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00008_0594204176.001 8 NO
    13) my init.ora files
    On standby db
    irina.__db_cache_size=79691776
    irina.__java_pool_size=4194304
    irina.__large_pool_size=4194304
    irina.__shared_pool_size=75497472
    irina.__streams_pool_size=0
    *.audit_file_dest='C:\oracle\product\10.2.0\admin\luda\adump'
    *.background_dump_dest='C:\oracle\product\10.2.0\admin\luda\bdump'
    *.compatible='10.2.0.1.0'
    *.control_files='C:\oracle\product\10.2.0\oradata\luda\luda.ctl'
    *.core_dump_dest='C:\oracle\product\10.2.0\admin\luda\cdump'
    *.db_block_size=8192
    *.db_domain=''
    *.db_file_multiblock_read_count=16
    *.db_file_name_convert='luda','irina'
    *.db_name='irina'
    *.db_unique_name='luda'
    *.db_recovery_file_dest='C:\oracle\product\10.2.0\flash_recovery_area'
    *.db_recovery_file_dest_size=2147483648
    *.dispatchers='(PROTOCOL=TCP) (SERVICE=irinaXDB)'
    *.fal_client='luda'
    *.fal_server='irina'
    *.job_queue_processes=10
    *.log_archive_config='DG_CONFIG=(irina,luda)'
    *.log_archive_dest_1='LOCATION=C:/oracle/product/10.2.0/oradata/luda/ VALID_FOR=(ALL_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=luda'
    *.log_archive_dest_2='SERVICE=irina LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=irina'
    *.log_archive_dest_state_1='ENABLE'
    *.log_archive_dest_state_2='ENABLE'
    *.log_archive_max_processes=30
    *.log_file_name_convert='C:/oracle/product/10.2.0/oradata/irina/','C:/oracle/product/10.2.0/oradata/luda/'
    *.open_cursors=300
    *.pga_aggregate_target=16777216
    *.processes=150
    *.remote_login_passwordfile='EXCLUSIVE'
    *.sga_target=167772160
    *.standby_file_management='AUTO'
    *.undo_management='AUTO'
    *.undo_tablespace='UNDOTBS1'
    *.user_dump_dest='C:\oracle\product\10.2.0\admin\luda\udump'
    On primary db
    irina.__db_cache_size=79691776
    irina.__java_pool_size=4194304
    irina.__large_pool_size=4194304
    irina.__shared_pool_size=75497472
    irina.__streams_pool_size=0
    *.audit_file_dest='C:\oracle\product\10.2.0/admin/irina/adump'
    *.background_dump_dest='C:\oracle\product\10.2.0/admin/irina/bdump'
    *.compatible='10.2.0.1.0'
    *.control_files='C:\oracle\product\10.2.0\oradata\irina\control01.ctl','C:\oracle\product\10.2.0\oradata\irina\control02.ctl','C:\oracle\product\10.2.0\oradata\irina\control03.ctl'
    *.core_dump_dest='C:\oracle\product\10.2.0/admin/irina/cdump'
    *.db_block_size=8192
    *.db_domain=''
    *.db_file_multiblock_read_count=16
    *.db_file_name_convert='luda','irina'
    *.db_name='irina'
    *.db_recovery_file_dest='C:\oracle\product\10.2.0/flash_recovery_area'
    *.db_recovery_file_dest_size=2147483648
    *.dispatchers='(PROTOCOL=TCP) (SERVICE=irinaXDB)'
    *.fal_client='irina'
    *.fal_server='luda'
    *.job_queue_processes=10
    *.log_archive_config='DG_CONFIG=(irina,luda)'
    *.log_archive_dest_1='LOCATION=C:/oracle/product/10.2.0/oradata/irina/ VALID_FOR=(ALL_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=irina'
    *.log_archive_dest_2='SERVICE=luda LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=luda'
    *.log_archive_dest_state_1='ENABLE'
    *.log_archive_dest_state_2='ENABLE'
    *.log_archive_max_processes=30
    *.log_file_name_convert='C:/oracle/product/10.2.0/oradata/luda/','C:/oracle/product/10.2.0/oradata/irina/'
    *.open_cursors=300
    *.pga_aggregate_target=16777216
    *.processes=150
    *.remote_login_passwordfile='EXCLUSIVE'
    *.sga_target=167772160
    *.standby_file_management='AUTO'
    *.undo_management='AUTO'
    *.undo_tablespace='UNDOTBS1'
    *.user_dump_dest='C:\oracle\product\10.2.0/admin/irina/udump'
    Please help me!!!!

    Hi,
    After several tries my redo logs are applied now. I think in my case it had to do with the tnsnames.ora. At this moment I have both database in both tnsnames.ora files using the SID and not the SERVICE_NAME.
    Now I want to use DGMGRL. Adding a configuration and a stand-by database is working fine, but when I try to enable the configuration DGMGRL gives no feedback and it looks like it is hanging. The log, although says that it succeeded.
    In another session 'show configuration' results in the following, confirming that the enable succeeded.
    DGMGRL> show configuration
    Configuration
    Name: avhtest
    Enabled: YES
    Protection Mode: MaxPerformance
    Fast-Start Failover: DISABLED
    Databases:
    avhtest - Primary database
    avhtestls53 - Physical standby database
    Current status for "avhtest":
    Warning: ORA-16610: command 'ENABLE CONFIGURATION' in progress
    It there anybody that experienced the same problem and/or knows the solution to this?
    With kind regards,
    Martin Schaap

  • Data Guard. My archive log files are not applied.

    I have one problem with Data Guard. My archive log files are not applied. However I have received all archive log files to my physical Standby db
    I have created a Physical Standby database on Oracle 10gR2 (Windows XP professional). Primary database is on another computer.
    In Enterprise Manager on Primary database it looks ok. I get the following message “Data Guard status Normal”
    But as I wrote above ”the archive log files are not applied”
    After I created the Physical Standby database, I have also done:
    1. I connected to the Physical Standby database instance.
    CONNECT SYS/SYS@luda AS SYSDBA
    2. I started the Oracle instance at the Physical Standby database without mounting the database.
    STARTUP NOMOUNT PFILE=C:\oracle\product\10.2.0\db_1\database\initluda.ora
    3. I mounted the Physical Standby database:
    ALTER DATABASE MOUNT STANDBY DATABASE
    4. I started redo apply on Physical Standby database
    alter database recover managed standby database disconnect from session
    5. I switched the log files on Physical Standby database
    alter system switch logfile
    6. I verified the redo data was received and archived on Physical Standby database
    select sequence#, first_time, next_time from v$archived_log order by sequence#
    SEQUENCE# FIRST_TIME NEXT_TIME
    3 2006-06-27 2006-06-27
    4 2006-06-27 2006-06-27
    5 2006-06-27 2006-06-27
    6 2006-06-27 2006-06-27
    7 2006-06-27 2006-06-27
    8 2006-06-27 2006-06-27
    7. I verified the archived redo log files were applied on Physical Standby database
    select sequence#,applied from v$archived_log;
    SEQUENCE# APP
    4 NO
    3 NO
    5 NO
    6 NO
    7 NO
    8 NO
    8. on Physical Standby database
    select * from v$archive_gap;
    No rows
    9. on Physical Standby database
    SELECT MESSAGE FROM V$DATAGUARD_STATUS;
    MESSAGE
    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
    ARC0: Becoming the 'no FAL' ARCH
    ARC0: Becoming the 'no SRL' ARCH
    ARC1: Becoming the heartbeat ARCH
    Attempt to start background Managed Standby Recovery process
    MRP0: Background Managed Standby Recovery process started
    Managed Standby Recovery not using Real Time Apply
    MRP0: Background Media Recovery terminated with error 1110
    MRP0: Background Media Recovery process shutdown
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[1]: Assigned to RFS process 2148
    RFS[1]: Identified database type as 'physical standby'
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[2]: Assigned to RFS process 2384
    RFS[2]: Identified database type as 'physical standby'
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[3]: Assigned to RFS process 3188
    RFS[3]: Identified database type as 'physical standby'
    Primary database is in MAXIMUM PERFORMANCE mode
    Primary database is in MAXIMUM PERFORMANCE mode
    RFS[3]: No standby redo logfiles created
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[4]: Assigned to RFS process 3168
    RFS[4]: Identified database type as 'physical standby'
    RFS[4]: No standby redo logfiles created
    Primary database is in MAXIMUM PERFORMANCE mode
    RFS[3]: No standby redo logfiles created
    10. on Physical Standby database
    SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;
    PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    ARCH CONNECTED 0 0 0 0
    RFS IDLE 0 0 0 0
    RFS IDLE 0 0 0 0
    RFS IDLE 1 9 13664 2
    RFS IDLE 0 0 0 0
    10) on Primary database:
    select message from v$dataguard_status;
    MESSAGE
    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
    ARCm: Becoming the 'no FAL' ARCH
    ARCm: Becoming the 'no SRL' ARCH
    ARCd: Becoming the heartbeat ARCH
    Error 1034 received logging on to the standby
    Error 1034 received logging on to the standby
    LGWR: Error 1034 creating archivelog file 'luda'
    LNS: Failed to archive log 3 thread 1 sequence 7 (1034)
    FAL[server, ARCh]: Error 1034 creating remote archivelog file 'luda'
    11)on primary db
    select name,sequence#,applied from v$archived_log;
    NAME SEQUENCE# APP
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00003_0594204176.001 3 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00004_0594204176.001 4 NO
    Luda 4 NO
    Luda 3 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00005_0594204176.001 5 NO
    Luda 5 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00006_0594204176.001 6 NO
    Luda 6 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00007_0594204176.001 7 NO
    Luda 7 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\IRINA\ARC00008_0594204176.001 8 NO
    Luda 8 NO
    12) on standby db
    select name,sequence#,applied from v$archived_log;
    NAME SEQUENCE# APP
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00004_0594204176.001 4 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00003_0594204176.001 3 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00005_0594204176.001 5 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00006_0594204176.001 6 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00007_0594204176.001 7 NO
    C:\ORACLE\PRODUCT\10.2.0\ORADATA\LUDA\ARC00008_0594204176.001 8 NO
    13) my init.ora files
    On standby db
    irina.__db_cache_size=79691776
    irina.__java_pool_size=4194304
    irina.__large_pool_size=4194304
    irina.__shared_pool_size=75497472
    irina.__streams_pool_size=0
    *.audit_file_dest='C:\oracle\product\10.2.0\admin\luda\adump'
    *.background_dump_dest='C:\oracle\product\10.2.0\admin\luda\bdump'
    *.compatible='10.2.0.1.0'
    *.control_files='C:\oracle\product\10.2.0\oradata\luda\luda.ctl'
    *.core_dump_dest='C:\oracle\product\10.2.0\admin\luda\cdump'
    *.db_block_size=8192
    *.db_domain=''
    *.db_file_multiblock_read_count=16
    *.db_file_name_convert='luda','irina'
    *.db_name='irina'
    *.db_unique_name='luda'
    *.db_recovery_file_dest='C:\oracle\product\10.2.0\flash_recovery_area'
    *.db_recovery_file_dest_size=2147483648
    *.dispatchers='(PROTOCOL=TCP) (SERVICE=irinaXDB)'
    *.fal_client='luda'
    *.fal_server='irina'
    *.job_queue_processes=10
    *.log_archive_config='DG_CONFIG=(irina,luda)'
    *.log_archive_dest_1='LOCATION=C:/oracle/product/10.2.0/oradata/luda/ VALID_FOR=(ALL_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=luda'
    *.log_archive_dest_2='SERVICE=irina LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=irina'
    *.log_archive_dest_state_1='ENABLE'
    *.log_archive_dest_state_2='ENABLE'
    *.log_archive_max_processes=30
    *.log_file_name_convert='C:/oracle/product/10.2.0/oradata/irina/','C:/oracle/product/10.2.0/oradata/luda/'
    *.open_cursors=300
    *.pga_aggregate_target=16777216
    *.processes=150
    *.remote_login_passwordfile='EXCLUSIVE'
    *.sga_target=167772160
    *.standby_file_management='AUTO'
    *.undo_management='AUTO'
    *.undo_tablespace='UNDOTBS1'
    *.user_dump_dest='C:\oracle\product\10.2.0\admin\luda\udump'
    On primary db
    irina.__db_cache_size=79691776
    irina.__java_pool_size=4194304
    irina.__large_pool_size=4194304
    irina.__shared_pool_size=75497472
    irina.__streams_pool_size=0
    *.audit_file_dest='C:\oracle\product\10.2.0/admin/irina/adump'
    *.background_dump_dest='C:\oracle\product\10.2.0/admin/irina/bdump'
    *.compatible='10.2.0.1.0'
    *.control_files='C:\oracle\product\10.2.0\oradata\irina\control01.ctl','C:\oracle\product\10.2.0\oradata\irina\control02.ctl','C:\oracle\product\10.2.0\oradata\irina\control03.ctl'
    *.core_dump_dest='C:\oracle\product\10.2.0/admin/irina/cdump'
    *.db_block_size=8192
    *.db_domain=''
    *.db_file_multiblock_read_count=16
    *.db_file_name_convert='luda','irina'
    *.db_name='irina'
    *.db_recovery_file_dest='C:\oracle\product\10.2.0/flash_recovery_area'
    *.db_recovery_file_dest_size=2147483648
    *.dispatchers='(PROTOCOL=TCP) (SERVICE=irinaXDB)'
    *.fal_client='irina'
    *.fal_server='luda'
    *.job_queue_processes=10
    *.log_archive_config='DG_CONFIG=(irina,luda)'
    *.log_archive_dest_1='LOCATION=C:/oracle/product/10.2.0/oradata/irina/ VALID_FOR=(ALL_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=irina'
    *.log_archive_dest_2='SERVICE=luda LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=luda'
    *.log_archive_dest_state_1='ENABLE'
    *.log_archive_dest_state_2='ENABLE'
    *.log_archive_max_processes=30
    *.log_file_name_convert='C:/oracle/product/10.2.0/oradata/luda/','C:/oracle/product/10.2.0/oradata/irina/'
    *.open_cursors=300
    *.pga_aggregate_target=16777216
    *.processes=150
    *.remote_login_passwordfile='EXCLUSIVE'
    *.sga_target=167772160
    *.standby_file_management='AUTO'
    *.undo_management='AUTO'
    *.undo_tablespace='UNDOTBS1'
    *.user_dump_dest='C:\oracle\product\10.2.0/admin/irina/udump'
    Please help me!!!!

    Hi,
    After several tries my redo logs are applied now. I think in my case it had to do with the tnsnames.ora. At this moment I have both database in both tnsnames.ora files using the SID and not the SERVICE_NAME.
    Now I want to use DGMGRL. Adding a configuration and a stand-by database is working fine, but when I try to enable the configuration DGMGRL gives no feedback and it looks like it is hanging. The log, although says that it succeeded.
    In another session 'show configuration' results in the following, confirming that the enable succeeded.
    DGMGRL> show configuration
    Configuration
    Name: avhtest
    Enabled: YES
    Protection Mode: MaxPerformance
    Fast-Start Failover: DISABLED
    Databases:
    avhtest - Primary database
    avhtestls53 - Physical standby database
    Current status for "avhtest":
    Warning: ORA-16610: command 'ENABLE CONFIGURATION' in progress
    It there anybody that experienced the same problem and/or knows the solution to this?
    With kind regards,
    Martin Schaap

Maybe you are looking for