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

Similar Messages

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.

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!

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

Continiously log switching, one node unavailable

We run 4-node RAC 9.2.0.4 on Solaris 9. Recently, one of nodes crashed due to hardware failure. After some time since this crash, i executed the command forcing log switching within the cluster: 'Alter system archive log current'. After this command, our redo logs started switching continuously - every 5-6 seconds. Generated archived logs where almost empty - they contained only a few blocks, often only one - header, i suppose. The problem was resolved only after the thread of the died node was disabled with command 'Alter database disable thread 4;'.
I made a few experiments to investigate this problem. It seems that every command forcing redo log switch in a RAC leads to such excessive log switching, when one of nodes in cluster is unavailable. I tested 'Alter system archive log current', ARCHIVE_LAG_TARGET parameter, and the command 'Alter system switch logfile', executing from an Oracle job. In all these cases redo logs began switching continuously when the commands had beed executed or it was time to switch logs by ARCHIVE_LAG_TARGET parameter. Is there any possibility to force redo logs switch in all threads in a cluster without any problems, when one node is unavailable? We would like to switch logs every 10 minutes - to limit the amount of data that can be lost in case of whole cluster failure...
Thanks in advance
Alexey Sergeyev
[email protected]

Joel, thank you for replay. I tested forcing log switch with one node down on different ways - within a job or without one. The command 'Alter system archive log current' was executed without any job from SQL*Plus command line. This triggered continuously log switching on working nodes. The parameter ARCHIVE_LAG_TARGET does'nt produce any job - at least this job is'nt shown in DBA_JOBS. This parameter leads to continuously log switching on survived nodes, when one node goes down.
I tried make a job, one per instance, with 'Execute immediate ''Alter system switch logfile''' command inside. Executing of such a job also triggered continuously log switching on working nodes...
It seems that forcing log switching in a cluster works only when all is fine - all nodes are running. Is it Oracle bug? Or is it expected, but not documented behaviour?
Alexey Sergeyev
[email protected]

Log in problems-please help!

Hi everybody!
I repost my log in problems with some uppdate info, it may help someone to come up with a solution....I am no computer expert, so please excuse my way of describing this problem.
I switched my Mac off manually after having been frozen from the sleep mode.
I have 2 accounts, one admin and one regular. I try to log into my admin, and I get the message "You are unable to log in to the user "my username" at this time".
I restart the computer, same problem again. I can log in to my second account with no problem. I reinstall OS X, same problem again. I ran the disk utility from the installation CD, even changed the passwords and I am still gettig the same message. Neither can I log in when in safe mode.
I would appreciate any suggestion, since my admin account contains valuable data and to reinstal/restore everything will be a pain..and probably impossible. Moreover, the data are encoded in the file vault and I cannot open them from my regular account, or can I? I have tried to open the sparseimage file in the admin user catalog, but I get "no mountable file systems".
Is there any hope? Or should I return my Mac to Apple, in 3 days my one year guarantee expires....
Thanks
Evacha
iMac G5 Mac OS X (10.4.6)

"no mountable file systems"
Sorry to hear of your difficulties, but unfortunately, the above message suggests that your data is likely permanently lost.
When data is stored in a disk image, damage to any portion of that image has the potential to render all of the files on the image inaccessible. Shutting off the power to the computer without "shutting down" normally increases the risk of damage to the directory in general, but if the image was actually mounted at the time, then damage could also occur to the directory in the disk image. Sometimes such errors may be repairable, but with "FileVault", the disk image is encrypted, reducing the chances of a successful recovery. It is unfortunate that nobody told you that maintaining up to date backups is essential when working with "FileVault" protected accounts.
" the data are encoded in the file vault and I cannot open them from my regular account, or can I?"
Normally, only the owner of the ".sparseimage" used in "Filevault" is able to access the image to attempt to open it - this is strictly a permissions issue and has nothing to do with encryption. If someone other than the owner attempts to open the disk image, the message is something like "Filesystem failed to mount... permissions denied". If the permissions are changed such that other users are allowed to use the ".sparseimage", the they would normally be prompted for the password and be allowed to mount the image. However, the "no mountable file systems" error indicates a problem with the image itself.
It is not likely to succeed because I think the filesystem needs to be mounted for this to work, but there is no harm in trying to repair the disk image. Control-click on the "user.sparseimage" file and select "Get Info" from the contextual menu. Under ownership and permissions, change the "Owner" to the second user, or else give "Owner", "Group" and "Other" "Read & Write" access, then follow the instructions in this document:
http://docs.info.apple.com/article.html?artnum=25695
You could also try some of the strategies described in this hint, but again, the probability of success is low:
http://www.macosxhints.com/article.php?story=20050326041757989
I don't think you will be able to return your computer - check the documentation to make sure, but I think the "one year" only covers repairs if there is an actual physical defect - perhaps what is responsible for the original sleep problem. However, if you suspect you may have a lemon, you might want to consider buying two more years of AppleCare coverage as insurance, but I think it has to be activated before the original 1 year is up so you would have to hurry. But so far, I don't see any solid evidence of a defect - loss of the user data can be attributed to cutting the power without shutting down, which you said you have done more than once.

10G redo log switchs with no activity

We have been testing 8i to 10G migrations and two things I have noticed that are different bwteeen the 2 databases are:
1) redo log switching occurring even though the database has no users and just sitting there. This is not happeniong in our 8i databases.
2) trace files of format instance_m001_ and instance_m000_ in ../bdump. Our 8i bdump's normally do not have trc files unless a problem occurs.
Is it normal for 10G to automatically switch redo logs with no activity and are these .trc files also normal? In general I get nervous with trc files. -quinn

Still haven't figured out the redo log switches, they seem to be slowing down, but the excess trace files are apparently cuased by a bug and can be fixed with Patch 3432729.

Force log switch using dbmcli

Hello!
How do I force a log switch using dbmcli?
For data protection purpose I would like to do this on daily basis.
The system has autolog=on, and I run the backups using dbmcli via crontab on a linux box. MaxDB version is 7.6.01.12
Regards,
Fredrik
Message was edited by:
Fredrik Rosengren
Message was edited by:
Fredrik Rosengren

Hi Fredrik,
with Oracle Databases you use logswitches to get online redo logs copied to archive logs even when these online redo logs are not yet completely filled.
Basically you just want to make sure to have the latest changes in your backup too.
Well in MaxDB there is no "switch logfile" because there is no such thing as the logfiles. And there is also no limitation like the one of Oracle when backing up log data.
If you want to backup each and all not yet backed up log entries: no problem!
Deactivate the automatic log backup, perform a manual log backup and restart the automatic logbackup.
The log segments in MaxDB are not like the online redo logfiles of oracle. They are just markers in the logarea that are used by the autolog features to know "oh, there had been some changes again - let's do a backup of that now".
You may also want to have a look into this note:
<a href="https://websmp206.sap-ag.de/~form/handler?_APP=01100107900000000342&_EVENT=REDIR&_NNUM=869267&_NLANG=E">#869267 - FAQ: MaxDB LOG area</a>
KR Lars

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.

Log switch frecuency so fast

In have a RAC compose by 2 instances. Two weeks ago I had problems with my redologs because the group number was not enough. That is why I increased from 3 group of online redolog to 10 each one of 50MB. From yesterday on I noticed that the log switch occur every 20 seconds and its provoque that the disk group where I'm archiving them gets full faster than ever. When I say faster I mean really really fast.
Could someone, please help me out.
Thanks in advance.

user13007224 wrote:
In have a RAC compose by 2 instances. Two weeks ago I had problems with my redologs because the group number was not enough. That is why I increased from 3 group of online redolog to 10 each one of 50MB. From yesterday on I noticed that the log switch occur every 20 seconds and its provoque that the disk group where I'm archiving them gets full faster than ever. When I say faster I mean really really fast.
Could someone, please help me out.
Thanks in advance.In addition to Cocksan's comments, if you are filling up your archivelog destination, increasing the SIZE of your redologs won't really help. Doing that will cause you to SWITCH less frequently but the resulting archivelogs will be bigger. If you a generateing redo at the rate of 100mb/sec (just to pull a number out of the air) your archivelog destination will be consumed at the rate of 100mb/sec, regardless of the number or size of your online redo logs. You need to find out what is causing so much redo in the first place.

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.

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

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

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.

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

Log Switch Problem

Similar Messages

Maybe you are looking for