Retention for redo logs

Hi ,
Is it possible to set retention for redo logs in 11g R2 and the OS Version will be AIX 6.1?

936639 wrote:
Hi ,
Is it possible to set retention for redo logs in 11g R2 and the OS Version will be AIX 6.1?Redo logs are written to in a cyclical manner; you do not configure retention for them. If you're speaking of archive logs (archived redo logs), then yes, retention policies can be configured for them.
http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmconfb.htm#i1019318
-Justin

Similar Messages

  • Polling on a practice for REDO logs

    I would like to do a poll on the below security practice because it seemed not commonly deployed. If this practice is done in your company for the core databases, could you please reply to my posting and state your industry, DBA strength and total number of employees? Will collate the results later.
    Previous posting 14/4/04:
    Can the archive and redo logs be maintained in a way such that no one administrator (sys ad or DBA) will have access to all copies of logs? This is to prevent any disgrunted party to delete the logs and render the point-in-time data recovery impossible. What is the most common way used to achieve this? Thanks for reply:-)
    (I am thinking of writing the logs to 2 servers, inwhich one server is fully owned and not accessible to the SysAd)

    Are you trying to simultaneously use the Data Guard Broker and issue commands in SQL*Plus?
    If so this does not work: Choose one tool and stick with it.

  • Third party tools for redo log

    Dear,
    Any third party tools can read redo log for oracle9i?
    ManyThanks

    Most 3rd parties gave up when they realized that
    a) Oracle now owns, and includes for free, the logminer, and
    b) Oracle is free - and willing to - change the contents of the log files at any time, including patch releases.

  • Following omf for redo log files

    Hi,
    when DB_CREATE_ONLINE_LOG_DEST_1 IS set then I would like to
    know whether 2 log groups would be created at the location specified if yes then in archive log mode whether this would create any problems .

    Before DBWn can write a modified buffer, all redo records associated with the changes to the buffer must be written to disk (the write-ahead protocol). If DBWn finds that some redo records have not been written, it signals LGWR to write the redo records to disk and waits for LGWR to complete writing the redo log buffer before it can write out the data buffers.
    http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14220/process.htm#i21918

  • Recommended os block size for redo log

    Hi
    Platform AIX
    Oracle 10.2.0.4
    Is there any recommended filesystem blocksize where redo log should be placed?
    We have tested with 512 bytes and 4096 bytes. We got better performance on 512 bytes in terms of avg wait on log file sync.
    Is there oracle/Aix recommendation on the same?

    978881 wrote:
    Hi
    Platform AIX
    Oracle 10.2.0.4
    Is there any recommended filesystem blocksize where redo log should be placed?
    We have tested with 512 bytes and 4096 bytes. We got better performance on 512 bytes in terms of avg wait on log file sync.
    Is there oracle/Aix recommendation on the same?The recommendation is to create redo logs on a mount with agblk=512bytes. Please refer following link(page 60) which is a oracle+IBM technical brief:
    http://www-03.ibm.com/support/techdocs/atsmastr.nsf/5cb5ed706d254a8186256c71006d2e0a/bae31a51a00fa0018625721f00268dc4/$FILE/Oracle%20Architecture%20and%20Tuning%20on%20AIX%20(v%202.30).pdf
    Regards,
    S.K.

  • Redo log best practice for performace - ASM 11g

    Hi All,
    I am new to ASM world....can you please give your valuable suggestion on below topic.
    What is the best practice for online redo log files ? I read it somewhere that oracle recommand to have only two disk group one for the all DB fils, control files online redo log files and other disk group for recovery files, like mulitplex redo file, archive log files etc.
    Will there be any performance improvment to make different diskgroup for online redo log (separate from datafiles, contorl files etc) ?
    I am looking for oracle document to find the best practise for redo log (peformance) on ASM.
    Please share your valuable views on this.
    Regards.

    ASM is only a filesystem.
    What really count on performance about I/O is the Storage Design i.e (RAID used, Array Sharing, Hard Disk RPM value, and so on).
    ASM itself is only a layer to read and write on ASM DISK. What mean if you storage design is ok ... ASM will be ok. (of course there is best pratices on ASM but Storage must be in first place)
    e.g There is any performance improvement make different Diskgroup?
    Depend...and this will lead to another question.
    Is the Luns on same array?
    If yes the performance will end up on same point. No matter if you have one or many diskgroup.
    Coment added:
    Comparing ASM to Filesystem in benchmarks (Doc ID 1153664.1)
    Your main concern should be how many IOPs,latency and throughput the storage can give you. Based on these values you will know if your redologs will be fine.

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

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

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

  • Private strand flush not complete how to find optimal size of redo log file

    hi,
    i am using oracle 10.2.0 on unix system and getting Private strand flush not complete in the alert log file. i know this is due to check point is not completed.
    I need to increase the size of redo log files or add new group to the database. i have log file switch (checkpoint incomplete) in the top 5 wait event.
    i can't change any parameter of database. i have three redo log group and log files are of 250MB size. i want to know the suitable size to avoid problem.
    select * from v$instance_recovery;
    RECOVERY_ESTIMATED_IOS     ACTUAL_REDO_BLKS     TARGET_REDO_BLKS     LOG_FILE_SIZE_REDO_BLKS     LOG_CHKPT_TIMEOUT_REDO_BLKS     LOG_CHKPT_INTERVAL_REDO_BLKS     FAST_START_IO_TARGET_REDO_BLKS     TARGET_MTTR     ESTIMATED_MTTR     CKPT_BLOCK_WRITES     OPTIMAL_LOGFILE_SIZE     ESTD_CLUSTER_AVAILABLE_TIME     WRITES_MTTR     WRITES_LOGFILE_SIZE     WRITES_LOG_CHECKPOINT_SETTINGS     WRITES_OTHER_SETTINGS     WRITES_AUTOTUNE     WRITES_FULL_THREAD_CKPT
    625     9286     9999     921600          9999          0     9     112166207               0     0     219270206     0     3331591     5707793please suggest me or tell me the way how to find out suitable size to avoid problem.
    thanks
    umesh

    How often should a database archive its logs
    Re: Redo log size increase and performance
    Please read the above thread and great replies by HJR sir. I think if you wish to get concept knowledge, you should add in your notes.
    "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."
    Source:http://download-west.oracle.com/docs/cd/B13789_01/server.101/b10752/build_db.htm#19559
    Pl also see ML Doc 274264.1 (REDO LOGS SIZING ADVISORY) on tips to calculate the optimal size for redo logs in 10g databases
    Source:Re: Redo Log Size in R12
    HTH
    Girish Sharma

  • Redo log space requests VALUE high

    SELECT name||' = '||value
    FROM v$sysstat
    WHERE name = 'redo log space requests';
    I am noticing 40+ space requests for some of my Oracle 9.2.0.5 databases.
    On another 7.3.4 DB I see this over 140 but this DB shutdown only on weekends so this cumulative value increases I presume.
    I have 20MB of 5 groups already. Do I still add another 2 more groups or increase their sizes ?
    I did read somewhere that I'd have to increase the log_buffer parameter. So how do we deal with this issue ? Any repercussions if I let this as it is for now ?
    The cause of this would be redo logs are not big enough or otherwise ?
    Thanks.

    user4874781 wrote:
    Thanks for your response Charles.
    So if I understand this correctly ... Redolog Space requests corresponds to a either an incorrectly sized redo log file / DBWR / CKPT needs to be tuned.
    Maybe I was interpreting this the wrong way. (Possibly)
    " The statistic 'redo log space requests' reflects the number of times a user process waits for space in the redo log buffer. " If that is the case, if there was longer waits for this event, I was under the assumption that log_buffer needs to be increased.
    http://www.idevelopment.info/data/Oracle/DBA_tips/Tuning/TUNING_6.shtml
    * Yes, the waits have increased to 70 as of now (since 40 yesterday .. DB was started Saturday night and will run till weekend) Less activity as of now, since the day has just started ; so it would definitely rise by end of the day. I took a look at the above article, and I think I understand why the article is slightly confusing. With due respect to the author, the article was last modified 16-Apr-2001, which I believe is before the Oracle documentation was better clarified regarding these statistics. From:
    http://download.oracle.com/docs/cd/B14117_01/server.101/b10755/stats002.htm
    "redo log space requests: Number of times the active log file is full and Oracle must wait for disk space to be allocated for the redo log entries. Such space is created by performing a log switch. Log files that are small in relation to the size of the SGA or the commit rate of the work load can cause problems. When the log switch occurs, Oracle must ensure that all committed dirty buffers are written to disk before switching to a new log file. If you have a large SGA full of dirty buffers and small redo log files, a log switch must wait for DBWR to write dirty buffers to disk before continuing."
    "redo log space wait time: Total elapsed waiting time for "redo log space requests" in 10s of milliseconds"
    It is quite possible that the "redo log space requests" will increase with every redo log file switch, which should not be too much of a concern. You may want to focus a little more on the "redo log space wait time" statistic, which indicates how much wait time was involved waiting. You might also want to focus on the system-wide wait event interface, examining how the accumulated wait time increases from one sampling of each of the statistics to the next.
    * I have 1 log switch every 11 minutes ; BTW ; I have 5 log groups of 20 MB each as of now. So I am assuming 40 MB of 4 or 5 log groups should be fine as per your suggestion ?If you have the disk space, considering that it is an ancient AIX box, you may want to set the redo log files to an even larger size, possibly 100MB (or larger). You may then want to force periodic switches of the redo log, for instance once an hour, or once every 30 minutes.
    * This is an ancient AIX box with 512 MB Ram. Is the redo log located on a fast device ? I'd have to find that out ( any hints on that ? )
    * Decreasing the log_buffer is possible on weekends since I'd have to bounce it for it to take effect.
    I will increase the log files accordingly and hopefully the space waits will reduce. Thanks again.Someone else, possibly Sybrand, on the forums might be familiar with AIX and be able to provide you with an answer. If you are seeing system-wide increasing wait time for redo related waits, then that might be an indication that the redo logs are not located on a fast device.
    Charles Hooper
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

  • Redo Log times ?

    During peak times my redo log times go sky high.. like 104.65ms .. How can I tune this to be lower ?

    The "sync" is the time it takes for a process to send a message to the log writer, the log writer to notice the message and write any pending log buffer to disc, and then send a message back to the initiating process.
    When the return message is sent, the process may be at the bottom of a long run queue, and take some time to get to the top of the queue and notice the message. This is most likely to happen when your system gets busy - especially with a large number of concurrent processes that are enthusiastically consuming the CPU.
    An increase in the "sync" time may be about CPU and process counts and have nothing to do with the ability of the log writer to do its job.
    Unfortunately, the log writer write times aren't captured properly in 9i, so it's hard to tell if the log writer really is starting to collapse under pressure; but if you've got sync times of 1/10 second a typical job isn't going to see it as much of a threat unless it's a pseudo-batch job that is inserting and committing 1,000,000 rows one at a time. So you have to ask if there are any jobs which are visibly much slower under load, rather than depending on the totalled log file sync time as an indicator - a check of v$session_event may give you a view on whether any session is suffering particularly badly.
    You might want to read this from Kevin Closson:
    http://kevinclosson.wordpress.com/2007/07/21/manly-men-only-use-solid-state-disk-for-redo-logging-lgwr-io-is-simple-but-not-lgwr-processing/
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk

  • Improving redo log writer performance

    I have a database on RAC (2 nodes)
    Oracle 10g
    Linux 3
    2 servers PowerEdge 2850
    I'm tuning my database with "spotilght". I have alredy this alert
    "The Average Redo Write Time alarm is activated when the time taken to write redo log entries exceeds a threshold. "
    The serveres are not in RAID5.
    How can I improve redo log writer performance?
    Unlike most other Oracle write I/Os, Oracle sessions must wait for redo log writes to complete before they can continue processing.
    Therefore, redo log devices should be placed on fast devices.
    Most modern disks should be able to process a redo log write in less than 20 milliseconds, and often much lower.
    To reduce redo write time see Improving redo log writer performance.
    See Also:
    Tuning Contention - Redo Log Files
    Tuning Disk I/O - Archive Writer

    Some comments on the section that was pulled from Wikipedia. There is some confusion in the market as their are different types of solid state disks with different pros and cons. The first major point is that the quote pulled from Wikipedia addresses issues with Flash hard disk drives. Flash disks are one type of solid state disk that would be a bad solution for redo acceleration (as I will attempt to describe below) they could be useful for accelerating read intensive applications. The type of solid state disk used for redo logs use DDR RAM as the storage media. You may decide to discount my advice because I work with one of these SSD manufacturers but I think if you do enough research you will see the point. There are many articles and many more customers who have used SSD to accelerate Oracle.
    > Assuming that you are not CPU constrained,
    moving the online redo to
    high-speed solid-state disk can make a hugedifference.
    Do you honestly think this is practical and usable
    advice Don? There is HUGE price difference between
    SSD and and normal hard disks. Never mind the
    following disadvantages. Quoting
    (http://en.wikipedia.org/wiki/Solid_state_disk):[
    i]
    # Price - As of early 2007, flash memory prices are
    still considerably higher  
    per gigabyte than those of comparable conventional
    hard drives - around $10
    per GB compared to about $0.25 for mechanical
    drives.Comment: Prices for DDR RAM base systems are actually higher than this with a typical list price around $1000 per GB. Your concern, however, is not price per capacity but price for performance. How many spindles will you have to spread your redo log across to get the performance that you need? How much impact are the redo logs having on your RAID cache effectiveness? Our system is obviously geared to the enterprise where Oracle is supporting mission critical databases where a hugh return can be made on accelerating Oracle.
    Capacity - The capacity of SSDs tends to be
    significantly smaller than the
    capacity of HDDs.Comment: This statement is true. Per hard disk drive versus per individual solid state disk system you can typically get higher density of storage with a hard disk drive. However, if your goal is redo log acceleration, storage capacity is not your bottleneck. Write performance, however, can be. Keep in mind, just as with any storage media you can deploy an array of solid state disks that provide terabytes of capacity (with either DDR or flash).
    Lower recoverability - After mechanical failure the
    data is completely lost as
    the cell is destroyed, while if normal HDD suffers
    mechanical failure the data
    is often recoverable using expert help.Comment: If you lose a hard drive for your redo log, the last thing you are likely to do is to have a disk restoration company partially restore your data. You ought to be getting data from your mirror or RAID to rebuild the failed disk. Similarly, with solid state disks (flash or DDR) we recommend host based mirroring to provide enterprise levels of reliability. In our experience, a DDR based solid state disk has a failure rate equal to the odds of losing two hard disk drives in a RAID set.
    Vulnerability against certain types of effects,
    including abrupt power loss
    (especially DRAM based SSDs), magnetic fields and
    electric/static charges
    compared to normal HDDs (which store the data inside
    a Faraday cage).Comment: This statement is all FUD. For example, our DDR RAM based systems have redundant power supplies, N+1 redundant batteries, four RAID protected "hard disk drives" for data backup. The memory is ECC protected and Chipkill protected.
    Slower than conventional disks on sequential I/OComment: Most Flash drives, will be slower on sequential I/O than a hard disk drive (to really understand this you should know there are different kinds of flash memory that also impact flash performance.) DDR RAM based systems, however, offer enormous performance benefits versus hard disk or flash based systems for sequential or random writes. DDR RAM systems can handle over 400,000 random write I/O's per second (the number is slightly higher for sequential access). We would be happy to share with you some Oracle ORION benchmark data to make the point. For redo logs on a heavily transactional system, the latency of the redo log storage can be the ultimate limit on the database.
    Limited write cycles. Typical Flash storage will
    typically wear out after
    100,000-300,000 write cycles, while high endurance
    Flash storage is often
    marketed with endurance of 1-5 million write cycles
    (many log files, file
    allocation tables, and other commonly used parts of
    the file system exceed
    this over the lifetime of a computer). Special file
    systems or firmware
    designs can mitigate this problem by spreading
    writes over the entire device,
    rather than rewriting files in place.
    Comment: This statement is mostly accurate but refers only to flash drives. DDR RAM based systems, such as those Don's books refer to, do not have this limitation.
    >
    Looking at many of your postings to Oracle Forums
    thus far Don, it seems to me that you are less
    interested in providing actual practical help, and
    more interested in self-promotion - of your company
    and the Oracle books produced by it.
    .. and that is not a very nice approach when people
    post real problems wanting real world practical
    advice and suggestions.Comment: Contact us and we will see if we can prove to you that Don, and any number of other reputable Oracle consultants, recommend using DDR based solid state disk to solve redo log performance issues. In fact, if it looks like your system can see a serious performance increase, we would be happy to put you on our evaluation program to try it out so that you can do it at no cost from us.

  • Why multiplex redo log group ?

    Hello,
    Why should we multiplex redo log groups if we have only file system which is already mirrored. Is there any one who had an incident when he has only one redo log member per group placed on a mirrored file system but still got corrupted and he felt better to have multiple members even if they reside on the same file system (which is mirrored)
    Thanks
    Salman

    Ansiktet wrote:
    EdStevens wrote:
    Salman Qureshi wrote:
    Hello,
    Why should we multiplex redo log groups if we have only file system which is already mirrored. Is there any one who had an incident when he has only one redo log member per group placed on a mirrored file system but still got corrupted and he felt better to have multiple members even if they reside on the same file system (which is mirrored)
    Thanks
    SalmanThe mirror won't protect you from an SA who deletes '/u01/oradata/redo01.log' because he is running out of space on /u01 and figures its safe to delete a log file.
    Or similar types of errors.
    The redo and control files are simply too critical to put all your eggs in one basket when planning their protection.:) Thats why you should not use Oracle default .log on redo, instead .dbf or .dbl can be used. THat's why I use the older (pre-10g) default of .rdo for redo logs
    However, has this happend anyone for real, that a SA delete Oracle files? Where do you think I came up with the example?
    HOw about an SA (or maybe the kind of "fresher" we often see here, Taking a look at a "log" file with notepad?
    If he is isnt stupid he should know that Oracle resides on /u01 partion (for example), and should not delete files there without consulting the DBA."should" is the operative word there. There is no accounting for corporate cultures and attitudes.
    But end the end, my example was to illustrate that not all problems with redo and control files are mitigated with disk mirroring.

  • Error verifing REDO LOG COLLECTOR

    Dear all,
    I get this error when i try to verify REDO collector:
    $avorcldb verify -src 10.52.128.176:3000:TEST -colltype REDO
    Introducir Nombre de Usuario de Origen: srcuser
    Introducir Contraseña de Origen:
    ERROR: el nombre de base de datos global para la base de datos origen debe incluir el dominio para utilizar el recopilador REDO LOG
    ERROR: defina los parámetros init.ora anteriores para los valores recomendados/necesarios
    The message languaje is spanish.... sorry.... the translation is:
    ERROR: Database global name for the source database must include the domain to use te REDO LOG COLLECTOR.
    ERROR: Define the before parameters on init.ora with the necesary values.
    I think that the error is because of the DB_DOMAIN parameter of the source database. I've incluide it and it doesn´t work.
    Thank you!!

    Of course, the problem looks easy but I can´t still solve it...
    I created the source user on the source database, following the instructions of the Administrator guide.
    After create this user and grant him the privileges of the script zarsspriv.sql and so on. Then I had to add a database and to do it, i have to enter the username and password of the user that i created and I have no problems...
    Then I need to add the collectors of the source database. When I add theses collector I dont have to enter the usernae/password, becasuse I entered it when I register the source database. Well... I add the DBAUD and OSAUD fine but when I try to add the REDO COLLECTOR i recive the error...
    The more strange is that I can verify the collectors fine:
    avorcldb verify -src neptuno:3000:testl -colltype REDO
    Enter Source user name: srcuser
    Enter Source password: ******
    source neptuno verified for REDO Log Audit Collector collector
    ...but when I launch the add_collector comand for REDO collector i have the problem..
    I´m using Oracle 10G, not 11G.
    Thanks

  • Redo log resizing

    Hi all,
    I wanted to know what are the situations in which one has to go for redo log resizing.....
    Regards,
    Nick.

    You could have searched here.
    Redo log Resizing

  • Why not use Redo log for consistent read

    Oracle 11.1.0.7:
    This might be a stupid question.
    As I understand if a select was issued at 7:00 AM and the data that select is going to read has changed at 7:10 AM even then Oracle will return the data that existed at 7:00 AM. And for this Oracle needs the data in Undo segments.
    My question is since redo also has past and current information why can't redo logs be used to retreive that information? Why is undo required when redo already has all that information.

    user628400 wrote:
    Thanks. I get that piece but isn't it the same problem with UNDO? It's written as it expires and there is no guranteee until we specifically ask oracle to gurantee the UNDO retention? I guess I am trying to understand that UNDO was created for effeciency purposes so that there is less performance overhead as compared to reading and writing from redo.And this also you said,
    >
    If data was changed to 100 to 200 wouldn't both the values be there in redo logs. As I understand:
    1. Insert row with value 100 at 7:00 AM and commit. 100 will be writen to redo log
    2. update row to 200 at 8:00 AM and commit. 200 will be written to redo log
    So in essence 100 and 200 both are there in the redo logs and if select was issued at 7:00 data can be read from redo log too. Please correct me if I am understanding it incorrectly.I guess you didnt understand the explaination that I did. Its not the old data that is kept. Its the changed vector of Undo that is kept which is useful to "recover" it when its gone but not useful as such for a select statement. Whereas in an Undo block, the actual value is kept. You must remember that its still a block only which can contain data just like your normal block which may contain a table like EMP. So its not 100,200 but the change vectors of these things which is useful to recover the transaction based on their SCN numbers and would be read in that order as well. And to read the data from Undo, its quite simple for oracle to do so using an Undo block as the transaction table which holds the entry for the transaction, knows where the old data is kept in the Undo Segment. You may have seen XIDSEQ, XIDUSN, XIDSLOT in the tranaction id which are nothing but the information that where the undo data is kept. And to read it, unlke redo, undo plays a good role.
    About the expiry of Undo, you must know that only INACTIVE Undo extents are marked for expiry. The Active Extents which are having an ongoing tranaction records, are never marked for it. You can come back after a lifetime and if undo is there, your old data would be kept safe by oracle since its useful for the multiversioning. Undo Retention is to keep the old data after commit, something which you need not to do if you are on 11g and using Total Recall feature!
    HTH
    Aman....

Maybe you are looking for