Dataguard log switch question

Wonder if anyone can help me with a question?
I am new to data guard and only recently setup my first implementation of a primary and standby Oracle 11 g database.
It's all setup correctly, i.e no gaps sequences showing, no errors in the alert logs and I have successfully tested a switch over and switch back.
I wanted to re-test the archive logs were going across to the standby database ok, unfortunately I performed an alter system switch logfile on the standby database instead of primary.
No errors are reported anywhere, no archive log sequence gaps or errors in the alert logs, but I am wondering if this will cause a problem the next time I have to failover to the standby database?
Apologies for my lack of my knowledge I am new data guard and only been a DBA for a couple of years, have not had time to read up on the 500 page Data Guard book yet.
Thanks in Advance

First you have to know what happens when log switch occurs either manually or internally.
All data & changes will be in online redo log files, once log switch occurred either automatic or forcefully, these information from online redo log files will be dumped to archives.
Now tell me. Where will be the online redo? There is no concept of online redo data on standby, in case of real time apply you will have only standby redo log files, even you cannot switch standby redo log files.
First this command on standby won't work, it's applicable only for online redo log files. So onions redo exists/active only in primary.
So nothing to worry on it. Make sure environment is sync prior to performing switchover.
Hope this helps.
Your all questions why unanswered? Close them and keep the forum clean.

Similar Messages

  • Question about frequent log switches

    I support an Oracle 10g database (10.2.0.4) and database activity has increase to the point that, during the heaviest parts of the day, log switches are occurring too frequently (15 - 20 times per hour!). We also utilize Data Guard to replicate the database to our DR site. We currently have 2 log groups with 2 membes in each group.
    I understand that I can tackle this issue 2 ways: either to increase the size of my redo log files (they are currently at 50 Meg each), or I can add additional redo log groups to the database.
    I would like to get some opinions on whether on solution is better than the other, or the pros and cons of each course of action.
    Thank you in advance for your advice with my question!

    CowTown_dba wrote:
    Thanks for helping me to understand my true problem. The issue is that because of the frequent log switches, database performance is degrading.Maybe that's the cause, maybe it isn't.
    Users are complaining about slow response. So if I add more groups it will buy the archiver extra time but it will not help with the slow response issue.Depends on the root cause of the slow response issue. That has yet to be determined. While it may be true that your car has a short in the electrical system and your car doesn't start, it doesn't necessarily follow that the car doesn't start because of the short in the electrical system.
    >
    I really appreciate everyone contributing to my understanding of the issue, and helping clarify the root problem so that I can fix it the first time around.
    You guys rock!

  • Dataguard- scheduling manual log switch to have minimal lag

    Hi,
    I need some suggestion..
    Recentry I had configured a physical standby for my 10g production database in maximum performance mode.
    Now , to reduce the lag between the primary and standby , I put one cron job which will do a manual log switch(alter system switch logfile) in every 30 minutes.
    and it is doing the job..!
    Does this have any impact on my databases...?
    Looking forward for your invaluable responce...
    Regards
    Noushad
    DBA

    Maybe you should let Oracle do it's job, configure this parameter which signifies that no buffer will remain dirty (in the cache) for more than 1800 (or whatever you want) seconds:
    LOG_CHECKPOINT_TIMEOUT = 1800:p

  • Is there a way to identify manual log switches?

    Hi!
    A while ago I upgraded a 10g database to 11.2.0.2 64 Bit Windows.
    During the Upgrade we realized that redo logs were configured really small (~10MB) what resulted in a lot of log switches (a few hundred per day). So we adjusted redo log size to 100MB and set archive_lag_target to 1800.
    The amount of log switches went down a little but less far than we expected it. After further analysing the situation we recognized that Oracle is switching logs far before reaching the 100MB log size (and also far before reaching 1800s). All the archived logs have a size of about 15MB. I know that 11g invented something like "preemptive log switching" that switches logs round about 20% before reaching the maximum value (if I remember it correctly..). But switching already at 15% of the maximum size seems strange to me...
    I couldn't find any helpful stuff on Google or Metalink about that topic but today I had a different idea: what if it's the application software that's doing manual log switches?
    (I have no idea why it should do that but I can remember that the application user does require the sysdba privilege - don't ask me why, I didn't write it, I won't defend it...)
    So I checked the alert log but unfortunately I had to realize that there is no difference between an automatic switch and a manual one (only alter system archive log... does get an extra line).
    So my questions are:
    1) Does anybody know a way of distinguishing between an automatic log switch and a manual one? Is there a table or another logfile where this information is recorded?
    2) Has anybody experienced a similar situation where Oracle is switching the logs way before reaching the maximum size?
    Best regards,
    Marcus

    lebigmac wrote:
    1) Does anybody know a way of distinguishing between an automatic log switch and a manual one? Is there a table or another logfile where this information is recorded?
    Off the top of my head - I think the only way to do a manual log switch is to issue "alter system switch log file", and I think that any "alter system" command is written to the alter log in you version of Oracle. (I really ought to check both statements before posting this, but I've been up since 2:30 am).
    2) Has anybody experienced a similar situation where Oracle is switching the logs way before reaching the maximum size?
    It's very common with recent versions of Oracle when private redo threads come into play; but your example seems a little exaggerated. The log file switch has to start when there is enough space left in the log file for all the public and all (or maybe it's the previously used - i'll have to check my book) private redo threads. You could check x$kcrfstrand to see what this sizes look like: http://jonathanlewis.wordpress.com/?s=private+thread
    Regards
    Jonathan Lewis

  • Redo logs switches too frequent after migrating the db to different server

    Dear Experts,
    A couple of days back, we migrated our database (belonging to EBusiness Suite) to a different server, to get good performance benefit. The database is 10.2.0.4 and it was migrated from AIX 5.3 to Linux x86 64.
    Users are happy with the performance, but I am getting below errors in the alert logs
    a) Thread 1 cannot allocate new log, sequence 498
    b) Private strand flush not complete
    c) ORACLE Instance PROD - Can not allocate log, archival requiredOracle support is saying the issue is coming because of too frequent log switches. I am wondering how the log switches has become frequent in the new server. In the old server it was about 10 mins for every switch, now it is as frequent as 1 minute?
    Any idea, what could be the reason behind this? Do you agree this issue is coming because frequent log switches?
    Thanks
    ARS

    Kanchana Devasurendra wrote:
    Hi ARS,
    Please check the following item in your new database.
    1. log_archive_max_processes Most properbly value set for this parameter is low ( may be it's set to 1.) Please increase up ( 4)I am curious to know what makes you think 4 is the right magic number for log_archive_max_processes - after all, he's only got one archive destination.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    A general reminder about "Forum Etiquette / Reward Points": http://forums.oracle.com/forums/ann.jspa?annID=718
    If you never mark your questions as answered people will eventually decide that it's not worth trying to answer you because they will never know whether or not their answer has been of any use, or whether you even bothered to read it.
    It is also important to mark answers that you thought helpful - again it lets other people know that you appreciate their help, but it also acts as a pointer for other people when they are researching the same question, moreover it means that when you mark a bad or wrong answer as helpful someone may be prompted to tell you (and the rest of the forum) what's so bad or wrong about the answer you found helpful.

  • Redo log switching

    11gR2
    Found out log switched every a few mins (2, 3 mins) at peak periods. I will make the recommendation for larger redo logs such that switches will be every 20 to 30 mins .
    Wanted to know what would be negative side of large redo logs?

    >
    11gR2
    Found out log switched every a few mins (2, 3 mins) at peak periods. I will make the recommendation for larger redo logs such that switches will be every 20 to 30 mins .
    Wanted to know what would be negative side of large redo logs?
    >
    Patience, grasshopper!
    If it ain't broke, don't fix it. So first make sure it is broken, or about to break.
    Unless you have an emergency on your hands you don't want to implement a change like that without careful examination of your current log file usage and history.
    You need to provide more information such as typical size of your log files, number of log groups, number of members in each group, log archive policy, etc.
    1. How often do these 'peak periods' occur? Do they occur fewer than 5 or 6 times a day? Or dozens of times?
    2. How long do they last? A few minutes? Or a few hours?
    3. What is the typical, non-peak rate of switches? This is really your base-line that you need to compare things to.
    4. What has the switch pattern been over the last few weeks or months?
    5. What has the growth in DB activity benn over the last few weeks or months? What do expect over the next few months?
    6. What is your goal in reducing the frequency of log switches?
    Basic negative sides include longer time to archive each log file (the fewer logs in each group the more impact here) and the length of time to recover in the event you need to. With large log files there is more for Oracle to wade through to find the relevant data for restoring the DB to a given point in time.
    Your suggestion of every 20 - 30 minutes means 2 to 3 times per hour. If you currently switch 10 or 12 times per hour you are making a very big change.
    Although you don't want to 'tweak' the logs unnecessarily you also don't want to make such large changes.
    Everything in moderation. If your current switch rate is 10 or 12 times per hour you may want to first cut this to maybe 1/2 to 1/3: that is, to 4 or 5 time per hour. It all depends on the answers to questions like I ask above. If you post the answers to know if will be helpful to anyone trying to advise you.

  • Want to reduce Log switch time interval !!!

    Friends ,
    I know that the standard LOG SWITCH TIme interval is 20/30 minutes , i.e., every time it is better switch redolog 1 to redolog 2 (or redolog2 to redolog3) within 20/30 minutes.
    But in my production server , Logfile switches within every 60 minutes every time in the peak hour . Now my question , How I can make a situation where my logfile should switch to another logfile between 20/30 minutes .
    Here my database configuration is :
    Oracle database 10g (10.2.0.1.0 version) in AIX 5.3 server
    AND
    SQL> show parameter fast_start_mttr_target
    NAME TYPE VALUE
    fast_start_mttr_target integer 600
    My every redolog file size is = 50 MB
    In this situation , give me advice plz how I can reduce my logswitch time interval ?

    You could either
    a. Recreate your RedoLog files with a smaller size --- which action I would not recommend
    OR
    b. Set the instance parameter ARCHIVE_LAG_TARGET to 1800
    ARCHIVE_LAG_TARGET specifies (in seconds) the duration at which a log switch would be forced, if it hasn't been done so by the online redo log file being full.
    You should be able to use ALTER SYSTEM to change this value.
    Hemant K Chitale
    http://hemantoracledba.blogspot.com

  • Checkpoint and log switch

    I would like to know if when a redo log is filled, the new redo log can be written in parallel with the chekpoint.
    Or simply, what's the sequence for log switching:
    1 - redo log is filled -> checkpoint -> new log writes. or
    2 - redo log is filled -> checkpoint/new log writes (in parallel)
    Best Regards,
    Rogerio C. Schreiner
    null

    I'm tempted to say 'don't worry about it', because L_C_T has been deprecated since 9i: instead use FAST_START_MTTR_TARGET to control the rate of checkpointing.
    But that aside, L_C_T essentially says: "if a block was dirtied (changed) by a transaction whose redo was generated more that X seconds ago -where X is the number of seconds LCT is set to- then that block will be flushed to disk the next time DBWR wakes up on the '3 second rule'"
    L_C_INTERVAL means something similar: "If a block was dirtied by a transaction whose redo can be found in the redo log more than Y redo blocks away from the current checkpoint marker, where Y is the setting for LCI, flush it next time DBWR wakes up"
    A checkpoint does not always result in a log switch, but a log switch always results in a checkpoint.
    You can't really answer your third question, because the LCT parameter doesn't mean "Every 1800 seconds, flush everything to disk" (as it used to in version 8.0). But if a block was dirtied more than 1800 seconds ago, it will be a candidate for flushing to disk next time DBWR wakes up. But that doesn't tell us when a log switch will occur: that will only happen when the redo log fills up and we have to switch to the next log to keep going. I can't tell anything about the size of your logs or the rate at which they will fill up from the parameters you list.
    A parameter does exist which will force a log switch every so often. It's called ARCHIVE_LAG_TARGET, and it's set to a number of seconds. If that was set to 1800, I could say with confidence that you'd log switch every half hour. But that's not what you had in your question, of course!
    You might care to read this slightly more technical description of the parameters:
    http://www.jlcomp.demon.co.uk/faq/log_checkpoint.html
    (though I think Jonathan's timelines are wrong, because the change to the effect of the parameters came in with 8i).
    Message was edited by:
    howardjr

  • High Commit @ Log switch

    Dear Oracle Experts,
    From Oracle EM, high commit is observed in one of our database (10g with dataguard) when it is performing a archive log switch. Currently archivelog size is 50MB and in average one log switch per hour.
    According to Oracle EM, the following SQL seems to cause the problem.
    SELECT IDX_ID FROM DR$INDEX WHERE IDX_OWNER# = :B2 AND IDX_NAME = :B1
    What could be the problem? How can I fix this?
    Thanks in advance.

    I don't know how EM generates that information.
    However, what would be happening is this :
    1. Some sessions do some significant DML (this could be the CTX_DDL.SYNC_INDEX OR could be other INSERT/UPDATE/DELETE etc operations)
    2. Many other sessions do very small but very many transactions
    3. Both types of sesssions issue COMMITs
    4. When they issue COMMITs , they wait on the 'log file sync' event (This is in the COMMIT class of events). Essentially, they are waiting for LGWR to write redo to disk (from the redo log buffer in the SGA to the redo log files on disk).
    4a. The LGWR, if it cannot write fast enough to disk, may, itself, wait on the 'log file parallel write' wait
    5. On completion of the redo writes, LGWR posts back to the sessions
    6. The sessions then proceed with the next set of operations. Now, these could be Queries.
    7. EM attempts to identify the SQLs that were waiting on 'log file sync' a short while ago. It had tracked the SIDs , now it joins to V$SQL based on HASH_VALUE+ADDRESS or based on SQL_ID.
    8. By now, the SQL_ID for the current operation of those sessions is pointing to the Queries they are running.
    9. EM now reports the SELECT as the operation that the session was doing.
    Since step 4 and step 6 are at different points in time and EM is possibly running seperate queries, it is likely to be running getting two different "images" of the operations those sessions are doing -- from two different points in time.

  • Database log switch and WLS connection pool relation

    Hi,
    We have been facing WLS JDBC connection pool disable and suspension issue very frequently in our environment and as a work around have implemented multi-datasource configuration (fail over method).
    But we need to know the root cause for the same and want to fix the issue too.
    We have tried many options like increasing no. of processes and transaction on Database, fine tune the weblogic datasource but still we could not isolate the issue.
    Recently we have been advised to minimize the log switch on database front and increase the redo log size. Not sure if this will help in isolating the issue or not.
    So we are Looking forward for the comments and suggestions on what would be the relationship b/w datasource and log switch be and if someone have faced this issue and resolved the same by fine tuning the database and minimizing the log switch.
    We are using WLS 10.3.3.0
    -Rohit

    turn on jdbc logging. The server log should be showing the troubles WLS is having
    while testing connections and trying/failing to make replacement connections.

  • Log Switch during RMAN backup

    I have seen in many RMAN backup scripts that a manual log switching is performed in first line of the script? What is it purpose, just to write changes needed to reconstruct the DML/DDL statements to online redo logfiles and start the archiving process if db is running in archive log mode?

    918868 wrote:
    I have seen in many RMAN backup scripts that a manual log switching is performed in first line of the script? What is it purpose, just to write changes needed to reconstruct the DML/DDL statements to online redo logfiles and start the archiving process if db is running in archive log mode?That could be the only reason but even that is not needed as RMAN would do a log switch automatically to push the current redo log file to make it's archive log and include it in the backup.
    Aman....

  • REDO LOG GROUP QUESTION

    I was reading an article and it said
    the distance(in bytes) between the checkpoint position in a redolog group and the end of the current redolog group can never be more then 90 % of the size of the smallest redo log group
    Can someone elaborate this

    I'm not sure what you want to elaborate on, but yes, it's true. If your redo logs are 100MB in size, and nothing else causes a checkpoint to take place, you'll have a checkpoint issued when you hit the 90MB mark. The idea is simply that you don't want to sit there doing nothing at all and then bang! the logs switch and you have to go hell-for-leather performing a massive checkpoint, all the while praying more log switches don't mean that you're threatening to catch up with yourself (at which point you'd have the 'thread unable to advance to log...' problem). By implementing the 90% rule, the idea is that your log switch, at worst, will cause a "10%-sized" checkpoint, which should be bearable.
    Of course, the situation is made more complex by the fact that other things DO kick in and cause their own checkpoints, so the interaction between -for example, FAST_START_MTTR_TARGET and the 90% rule can get, er, 'interesting'.

  • Standby Log switch

    Hello all,
    From Oracle Docs:
    "A log switch on the primary database triggers a log switch on the standby database, causing ARCn processes on the standby database to archive the standby redo log files to archived redo log files on the standby database."
    Does the ARCH process on the primary send a message to the RFS process on the standby server, and then the RFS process sends a message to the ARCH process on the standby server telling the standby server ARCH to archive the current standby redo log?
    With regards

    992801 wrote:
    Hello all,
    From Oracle Docs:
    "A log switch on the primary database triggers a log switch on the standby database, causing ARCn processes on the standby database to archive the standby redo log files to archived redo log files on the standby database."
    Does the ARCH process on the primary send a message to the RFS process on the standby server, and then the RFS process sends a message to the ARCH process on the standby server telling the standby server ARCH to archive the current standby redo log?
    With regardsWhat is the version you are using?
    As simple, Redo data transmitted from the primary database will be received by RFS on the standby, From here RFS process writes the redo data to either standby redo logs or to archived redo logs.

  • Log Switch Problem

    Hello Everybody,
    Solaris ver : 10
    Oracle ver : 10.2.0.1.0
    I am gettin gthe following Messages in my Alert Log..
    Sun Oct 25 02:38:46 2009
    Thread 1 cannot allocate new log, sequence 1709
    Private strand flush not complete
      Current log# 4 seq# 1708 mem# 0: /u04/oradata/inora/redo/redo04.log
      Current log# 4 seq# 1708 mem# 1: /u03/oradata/inora/ctrl/redo04.log
    Thread 1 advanced to log sequence 1709
      Current log# 1 seq# 1709 mem# 0: /u04/oradata/inora/redo/redo01.log
      Current log# 1 seq# 1709 mem# 1: /u03/oradata/inora/ctrl/redo01.log
    Sun Oct 25 02:39:06 2009
    Thread 1 cannot allocate new log, sequence 1710
    Private strand flush not complete
      Current log# 1 seq# 1709 mem# 0: /u04/oradata/inora/redo/redo01.log
      Current log# 1 seq# 1709 mem# 1: /u03/oradata/inora/ctrl/redo01.log
    Thread 1 advanced to log sequence 1710
      Current log# 2 seq# 1710 mem# 0: /u04/oradata/inora/redo/redo02.log
      Current log# 2 seq# 1710 mem# 1: /u03/oradata/inora/ctrl/redo02.log
    Sun Oct 25 02:39:53 2009
    Thread 1 cannot allocate new log, sequence 1711
    Private strand flush not complete
      Current log# 2 seq# 1710 mem# 0: /u04/oradata/inora/redo/redo02.log
      Current log# 2 seq# 1710 mem# 1: /u03/oradata/inora/ctrl/redo02.log
    Thread 1 advanced to log sequence 1711
      Current log# 3 seq# 1711 mem# 0: /u04/oradata/inora/redo/redo03.log
      Current log# 3 seq# 1711 mem# 1: /u03/oradata/inora/ctrl/redo03.logCan this be resolved by Increasing the Sizes of Online Redo Logs..
    Any Help Appreciated..
    Thanks & Regards,
    Prosenjit Mukherjee.

    Dear
    If you see such messages then better to go for either of the 2 things.
    1- increase the size of the redo log files,
    2- increase the groups of the redo logs.
    Also ideally there should be around max. 4 log switches per hour, so you can calculate that and act accordingly.
    cheers
    Mehmood
    url: http://mehmoodm.blogspot.com

  • Abnormally Log switches

    Dear all,
    In my oltp system,the redo size for per member is 20m,and the average log switch is in 10-15 mints.But today i saw a disturbing information in my alert_log......
    Thread 1 advanced to log sequence 221335
    Current log# 1 seq# 221335 mem# 0: O:\ORACLE\ORADATA\TEST\REDO_A\REDO01_A.LOG
    Current log# 1 seq# 221335 mem# 1: O:\ORACLE\ORADATA\TEST\REDO_B\REDO01_B.LOG
    Thread 1 advanced to log sequence 221336
    Current log# 3 seq# 221336 mem# 0: O:\ORACLE\ORADATA\TEST\REDO_A\REDO03_A.LOG
    Current log# 3 seq# 221336 mem# 1: O:\ORACLE\ORADATA\TEST\REDO_B\REDO03_B.LOG
    Thread 1 advanced to log sequence 221337
    Current log# 4 seq# 221337 mem# 0: O:\ORACLE\ORADATA\TEST\REDO_A\REDO04_A.LOG
    Current log# 4 seq# 221337 mem# 1: O:\ORACLE\ORADATA\TEST\REDO_B\REDO04_B.LOG
    Thread 1 advanced to log sequence 221338
    Current log# 5 seq# 221338 mem# 0: O:\ORACLE\ORADATA\TEST\REDO_A\REDO05_A.LOG
    Current log# 5 seq# 221338 mem# 1: O:\ORACLE\ORADATA\TEST\REDO_B\REDO05_B.LOG
    Thread 1 cannot allocate new log, sequence 221339
    All online logs needed archiving
    Current log# 5 seq# 221338 mem# 0: O:\ORACLE\ORADATA\TEST\REDO_A\REDO05_A.LOG
    Current log# 5 seq# 221338 mem# 1: O:\ORACLE\ORADATA\TEST\REDO_B\REDO05_B.LOG
    What is the reason behind these 5 log switches at a time?I'm very much worried with this matter....
    Any suggestion......................?????
    Warm Regards,

    Hi.
    I guess you have a very high load values on your system... inserts / updates... Your database is running in archivlog mode. The archiver process could not backup the redo log files in that time period that the database take to round robin the log switches.
    Its not a big deal you will gain a wait enqueue for database changes. You can increase the logfile size to avoid this problem. but keep in mind that in recovery case the recovery take more time.
    *T                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

Maybe you are looking for