Redo log wait event
Hi,
in my top evens i've:
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
CPU time 1,894 36.1
log file sync 36,862 1,008 27 19.2 Commit
db file scattered read 165,508 970 6 18.5 User I/O
db file sequential read 196,596 857 4 16.3 User I/O
log file parallel write 35,847 565 16 10.8 System I/O
Log file are on a separate disks, with no activity, only 1 redo per group, and 4 groups.
I think that 27ms for log file synch is high.
I raised commits in sqlloader putting rows=100000 instead 30000 but it's always high.
Which check i can perform?
I'm on AIX 5.3 and database in 10.2.0.4.4
Log File Sync
The “log file sync” wait event is triggered when a user session issues a commit (or a rollback). The user session will signal or post the LGWR to write the log buffer to the redo log file. When the LGWR has finished writing, it will post the user session. The wait is entirely dependent on LGWR to write out the necessary redo blocks and send confirmation of its completion back to the user session. The wait time includes the writing of the log buffer and the post, and is sometimes called “commit latency”.
The P1 parameter in <View:V$SESSION_WAIT> is defined as follows for this wait event:
P1 = buffer#
All changes up to this buffer number (in the log buffer) must be flushed to disk and the writes confirmed to ensure that the transaction is committed and will be kept on an instance crash. The wait is for LGWR to flush up to this buffer#.
Reducing Waits / Wait times:
If a SQL statement is encountering a significant amount of total time for this event, the average wait time should be examined. If the average wait time is low, but the number of waits is high, then the application might be committing after every row, rather than batching COMMITs. Applications can reduce this wait by committing after “n” rows so there are fewer distinct COMMIT operations. Each commit has to be confirmed to make sure the relevant REDO is on disk. Although commits can be "piggybacked" by Oracle, reducing the overall number of commits by batching transactions can be very beneficial.
If the SQL statement is a SELECT statement, review the Oracle Auditing settings. If Auditing is enabled for SELECT statements, Oracle could be spending time writing and commit data to the AUDIT$ table.
If the average time waited is high, then examine the other log related waits for the session, to see where the session is spending most of its time. If a session continues to wait on the same
If the average time waited is high, then examine the other log related waits for the session, to see where the session is spending most of its time. If a session continues to wait on the same buffer# then the SEQ# column of V$SESSION_WAIT should increment every second. If not then the local session has a problem with wait event timeouts. If the SEQ# column is incrementing then the blocking process is the LGWR process. Check to see what LGWR is waiting on as it may be stuck. If the waits are because of slow I/O, then try the following:
Reduce other I/O activity on the disks containing the redo logs, or use dedicated disks.
Try to reduce resource contention. Check the number of transactions (commits + rollbacks) each second, from V$SYSSTAT.
Alternate redo logs on different disks to minimize the effect of the archiver on the log writer.
Move the redo logs to faster disks or a faster I/O subsystem (for example, switch from RAID 5 to RAID 1).
Consider using raw devices (or simulated raw devices provided by disk vendors) to speed up the writes.
See if any activity can safely be done with NOLOGGING / UNRECOVERABLE options in order to reduce the amount of redo being written.
See if any of the processing can use the COMMIT NOWAIT option (be sure to understand the semantics of this before using it).
Check the size of the log buffer as it may be so large that LGWR is writing too many blocks at one time.
Similar Messages
-
Dear All,
We are usinf ecc5 ans the databse oacle 9i on wondows 2003I have notice that the
Redo log wait S has been suddenly increase in number 690
Please suggest what si the problem and to solve it.
Data buffer
Size kb 1,261,568
Quality % 96.2
Reads 4,234,462,711
Physical reads 160,350,516
writes 3,160,751
Buffer busy waits 1,117,697
Buffer wait time s 3,507
Shared Pool
Size kb 507,904
DD-Cache quality % 84.3
SQL Area getratio % 95.6
pinratio % 98.8
reloads/pins % 0.0297
Log buffer
Size kb 1,176
Entries 11,757,027
Allocation retries 722
Alloc fault rate % 0.0
*Redo log wait s 690*
Log files (in use) 8( 8)
Calls
User calls 41,615,763
commits 367,243
rollbacks 7,890
Recursive calls 100,067,593
Parses 7,822,590
User/Recursive calls 0.4
Reads / User calls 101.8
Time statistics
Busy wait time s 697,392
CPU time s 42,505
Time/User call ms 18
Sessions busy % 9.26
CPU usage % 4.51
CPU count 2
Redo logging
Writes 1,035,582
OS-Blocks written 14,276,056
Latching time s 1
Sessions busy % 9.26
CPU usage % 4.51
CPU count 2
Redo logging
Writes 1,035,582
OS-Blocks written 14,276,056
Latching time s 1
Write time s 806
Mb written 6,574
Table scans & fetches
Short table scans 607,891
Long table scans 32,468
Fetch by rowid 1,620,054,083
by continued row 761,131
Sorts
Memory 3,046,669
Disk 32
Rows sorted 446,593,854
Regards,
ShivaHi Stefan,
As per the doc you have suggest. The details are as following.
In the day there is only 24 log switch , but in hour there is no more than 10 to 15 as per doc ,so ti is very less.
The DD-Cache quality % 84.1 is less
The elapsed time since start
Elapsed since start (s) 540,731
Log buffer
Size kb 1,176
Entries 13,449,901
Allocation retries 767
Alloc fault rate % 0.0
*Redo log wait s 696*
Log files (in use) 8( 8)
Check DB Wait times
TCode ST04->Detail Analysis Menu->Wait Events
Statistics on total waits for an event
Elapsed time: 985 s
since reset at 09:34:06
Type Client Sessions Busy wait Total wait Busy wait
time (ms) time (ms) time (%)
USER User 40 1,028,710 17,594,230 5.85
BACK ARC0 1 2,640 1,264,410 0.21
BACK ARC1 1 540 1,020,400 0.05
BACK CKPT 1 950 987,490 0.10
BACK DBW0 1 130 983,920 0.01
BACK LGWR 1 160 986,430 0.02
BACK PMON 1 0 987,000 0.00
BACK RECO 1 10 1,800,010 0.00
BACK SMON 1 3,820 1,179,410 0.32
Disk based sorts
Sorts
Memory 3,443,693
Disk 41
Rows sorted 921,591,847
Check DB Shared Pool Quality
Shared Pool
Size kb 507,904
DD-Cache quality % 84.1
SQL Area getratio % 95.6
pinratio % 98.8
reloads/pins % 0.0278
V$LOGHIST
THREAD# SEQUENCE# FIRST_CHANGE# FIRST_TIME SWITCH_CHANGE#
1 31612 381284375 2008/11/13 00:01:29 381293843
1 31613 381293843 2008/11/13 00:12:12 381305142
1 31614 381305142 2008/11/13 03:32:39 381338724
1 31615 381338724 2008/11/13 06:29:21 381362057
1 31616 381362057 2008/11/13 07:00:39 381371178
1 31617 381371178 2008/11/13 07:13:01 381457916
1 31618 381457916 2008/11/13 09:26:17 381469012
1 31619 381469012 2008/11/13 10:27:19 381478636
1 31620 381478636 2008/11/13 10:59:54 381488508
1 31621 381488508 2008/11/13 11:38:33 381498759
1 31622 381498759 2008/11/13 12:05:14 381506545
1 31623 381506545 2008/11/13 12:33:48 381513732
1 31624 381513732 2008/11/13 13:08:10 381521338
1 31625 381521338 2008/11/13 13:50:15 381531371
1 31626 381531371 2008/11/13 14:38:36 381540689
1 31627 381540689 2008/11/13 15:02:19 381549493
1 31628 381549493 2008/11/13 15:43:39 381556307
1 31629 381556307 2008/11/13 16:07:47 381564737
1 31630 381564737 2008/11/13 16:39:45 381571786
1 31631 381571786 2008/11/13 17:07:07 381579026
1 31632 381579026 2008/11/13 17:37:26 381588121
1 31633 381588121 2008/11/13 18:28:58 381595963
1 31634 381595963 2008/11/13 20:00:41 381602469
1 31635 381602469 2008/11/13 22:23:20 381612866
1 31636 381612866 2008/11/14 00:01:28 381622652
1 31637 381622652 2008/11/14 00:09:52 381634720
1 31638 381634720 2008/11/14 03:32:00 381688156
1 31639 381688156 2008/11/14 07:00:30 381703441
14.11.2008 Log File information from control file 10:01:32
Group Thread Sequence Size Nr of Archive First Time 1st SCN
Nr Nr Nr (bytes) Members Status Change Nr in log
1 1 31638 52428800 2 YES INACTIVE 381634720 2008/11/14 03:32:00
2 1 31639 52428800 2 YES INACTIVE 381688156 2008/11/14 07:00:30
3 1 31641 52428800 2 NO CURRENT 381783353 2008/11/14 09:50:09
4 1 31640 52428800 2 YES ACTIVE 381703441 2008/11/14 07:15:07
Regards, -
Dear all,
In st04 I see Redo log wait is this a problem. Please suggest how to solve it
Please find the details.
Size (kB) 14,352
Entries 42,123,046
Allocation retries 9,103
Alloc fault rate(%) 0.0
Redo log wait (s) 486
Log files (in use) 8 ( 8 )
DB_INST_ID Instance ID 1
DB_INSTANCE DB instance name prd
DB_NODE Database node A
DB_RELEASE Database release 10.2.0.4.0
DB_SYS_TIMESTAMP Day, Time 06.04.2010 13:07:10
DB_SYSDATE DB System date 20100406
DB_SYSTIME DB System time 130710
DB_STARTUP_TIMESTAMP Start up at 22.03.2010 03:51:02
DB_STARTDATE DB Startup date 20100322
DB_STARTTIME DB Startup time 35102
DB_ELAPSED Seconds since start 1329368
DB_SNAPDIFF Sec. btw. snapshots 1329368
DATABUFFERSIZE Size (kB) 3784704
DBUFF_QUALITY Quality (%) 96.3
DBUFF_LOGREADS Logical reads 5615573538
DBUFF_PHYSREADS Physical reads 207302988
DBUFF_PHYSWRITES Physical writes 7613263
DBUFF_BUSYWAITS Buffer busy waits 878188
DBUFF_WAITTIME Buffer wait time (s) 3583
SHPL_SIZE Size (kB) 1261568
SHPL_CAQUAL DD-cache Quality (%) 95.1
SHPL_GETRATIO SQL area getratio(%) 98.4
SHPL_PINRATIO SQL area pinratio(%) 99.9
SHPL_RELOADSPINS SQLA.Reloads/pins(%) 0.0042
LGBF_SIZE Size (kB) 14352
LGBF_ENTRIES Entries 42123046
LGBF_ALLORETR Allocation retries 9103
LGBF_ALLOFRAT Alloc fault rate(%) 0
LGBF_REDLGWT Redo log wait (s) 486
LGBF_LOGFILES Log files 8
LGBF_LOGFUSE Log files (in use) 8
CLL_USERCALLS User calls 171977181
CLL_USERCOMM User commits 1113161
CLL_USERROLLB User rollbacks 34886
CLL_RECURSIVE Recursive calls 36654755
CLL_PARSECNT Parse count 10131732
CLL_USR_PER_RCCLL User/recursive calls 4.7
CLL_RDS_PER_UCLL Log.Reads/User Calls 32.7
TIMS_BUSYWT Busy wait time (s) 389991
TIMS_CPUTIME CPU time session (s) 134540
TIMS_TIM_PER_UCLL Time/User call (ms) 3
TIMS_SESS_BUSY Sessions busy (%) 0.94
TIMS_CPUUSAGE CPU usage (%) 2.53
TIMS_CPUCOUNT Number of CPUs 4
RDLG_WRITES Redo writes 1472363
RDLG_OSBLCKWRT OS blocks written 54971892
RDLG_LTCHTIM Latching time (s) 19
RDLG_WRTTIM Redo write time (s) 2376
RDLG_MBWRITTEN MB written 25627
TABSF_SHTABSCAN Short table scans 12046230
TABSF_LGTABSCAN Long table scans 6059
TABSF_FBYROWID Table fetch by rowid 1479714431
TABSF_FBYCONTROW Fetch by contin. row 2266031
SORT_MEMORY Sorts (memory) 3236898
SORT_DISK Sorts (disk) 89
SORT_ROWS Sorts (rows) 5772889843
SORT_WAEXOPT WA exec. optim. mode 1791746
SORT_WAEXONEP WA exec. one pass m. 93
SORT_WAEXMULTP WA exec. multipass m 0
IEFF_SOFTPARSE Soft parse ratio 0.9921
IEFF_INMEM_SORT In-memory sort ratio 1
IEFF_PARSTOEXEC Parse to exec. ratio 0.9385
IEFF_PARSCPUTOTOT Parse CPU to Total 0.9948
IEFF_PTCPU_PTELPS PTime CPU / PT elps. 0.1175
Regards,
KumarHi,
If the redo buffers are not large enough, the Oracle log-writer process waits for space to become available. This wait time becomes wait time for the end user. Hence this may cause perfromance problem at database end and hence need to be tuned.
The size of the redo log buffer is defined in the init.ora file using the 'LOG_BUFFER' parameter. The statistic 'redo log space requests' reflects the number of times a user process waits for space in the redo log buffer.
If the size of redo log buffer is not big enough causing this wait, recommendation is to increase the size of redo log buffer in such a way that the value of "redo log space requests" should be near to zero.
regards,
rakesh -
Hi,
one of my friends get this question in DBA interviews many times , the interviwers want to list some of unusual wait events
any thoughts
ThanksThat question has no context.
It is like asking what is an unusual thing to eat for dinner. Food that may be normal to one person, may be foreign and strange to another. Just like a database with a high amount of time allocated against a specific wait event, may be very different to another because their workload is different. Which one is then unusual? Well, neither.
Take for instance. If a Database was used solely for OLTP with highly selective queries, then you could possibly generalize that a high number of scattered reads would be unusual, and higher sequential reads normal. On the flip side, for a data warehouse that ran large reports with non-selective queries ,then high scattered reads would be normal, and high sequential reads would not be expected as much.
A question more along the lines of "A database is using solid state disks for online redo, what wait event or events do you think would be unusual if there was large amounts of wait time against them and why?" would be a better way of doing it. -
Performance Issue: Wait event "log file sync" and "Execute to Parse %"
In one of our test environments users are complaining about slow response.
In statspack report folowing are the top-5 wait events
Event Waits Time (cs) Wt Time
log file parallel write 1,046 988 37.71
log file sync 775 774 29.54
db file scattered read 4,946 248 9.47
db file parallel write 66 248 9.47
control file parallel write 188 152 5.80
And after runing the same application 4 times, we are geting Execute to Parse % = 0.10. Cursor sharing is forced and query rewrite is enabled
When I view v$sql, following command is parsed frequently
EXECUTIONS PARSE_CALLS
SQL_TEXT
93380 93380
select SEQ_ORDO_PRC.nextval from DUAL
Please suggest what should be the method to troubleshoot this and if I need to check some more information
Regards,
Sudhanshu BhandariWell, of course, you probably can't eliminate this sort of thing entirely: a setup such as yours is inevitably a compromise. What you can do is make sure your log buffer is a good size (say 10MB or so); that your redo logs are large (at least 100MB each, and preferably large enough to hold one hour or so of redo produced at the busiest time for your database without filling up); and finally set ARCHIVE_LAG_TARGET to something like 1800 seconds or more to ensure a regular, routine, predictable log switch.
It won't cure every ill, but that sort of setup often means the redo subsystem ceases to be a regular driver of foreground waits. -
Wait Events "log file parallel write" / "log file sync" during CREATE INDEX
Hello guys,
at my current project i am performing some performance tests for oracle data guard. The question is "How does a LGWR SYNC transfer influences the system performance?"
To get some performance values, that i can compare i just built up a normal oracle database in the first step.
Now i am performing different tests like creating "large" indexes, massive parallel inserts/commits, etc. to get the bench mark.
My database is an oracle 10.2.0.4 with multiplexed redo log files on AIX.
I am creating an index on a "normal" table .. i execute "dbms_workload_repository.create_snapshot()" before and after the CREATE INDEX to get an equivalent timeframe for the AWR report.
After the index is built up (round about 9 GB) i perform an awrrpt.sql to get the AWR report.
And now take a look at these values from the AWR
Avg
%Time Total Wait wait Waits
Event Waits -outs Time (s) (ms) /txn
log file parallel write 10,019 .0 132 13 33.5
log file sync 293 .7 4 15 1.0
......How can this be possible?
Regarding to the documentation
-> log file sync: http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref3120
Wait Time: The wait time includes the writing of the log buffer and the post.-> log file parallel write: http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref3104
Wait Time: Time it takes for the I/Os to complete. Even though redo records are written in parallel, the parallel write is not complete until the last I/O is on disk.This was also my understanding .. the "log file sync" wait time should be higher than the "log file parallel write" wait time, because of it includes the I/O and the response time to the user session.
I could accept it, if the values are close to each other (maybe round about 1 second in total) .. but the different between 132 seconds and 4 seconds is too noticeable.
Is the behavior of the log file sync/write different when performing a DDL like CREATE INDEX (maybe async .. like you can influence it with the initialization parameter COMMIT_WRITE??)?
Do you have any idea how these values come about?
Any thoughts/ideas are welcome.
Thanks and RegardsSurachart Opun (HunterX) wrote:
Thank you for Nice Idea.
In this case, How can we reduce "log file parallel write" and "log file sync" waited time?
CREATE INDEX with NOLOGGINGA NOLOGGING can help, can't it?Yes - if you create index nologging then you wouldn't be generating that 10GB of redo log, so the waits would disappear.
Two points on nologging, though:
<ul>
it's "only" an index, so you could always rebuild it in the event of media corruption, but if you had lots of indexes created nologging this might cause an unreasonable delay before the system was usable again - so you should decide on a fallback option, such as taking a new backup of the tablespace as soon as all the nologging operatons had completed.
If the database, or that tablespace, is in +"force logging"+ mode, the nologging will not work.
</ul>
Don't get too alarmed by the waits, though. My guess is that the +"log file sync"+ waits are mostly from other sessions, and since there aren't many of them the other sessions are probably not seeing a performance issue. The +"log file parallel write"+ waits are caused by your create index, but they are happeninng to lgwr in the background which is running concurrently with your session - so your session is not (directly) affected by them, so may not be seeing a performance issue.
The other sessions are seeing relatively high sync times because their log file syncs have to wait for one of the large writes that you have triggered to complete, and then the logwriter includes their (little) writes with your next (large) write.
There may be a performance impact, though, from the pure volume of I/O. Apart from the I/O to write the index you have LGWR writting (N copies) of the redo for the index and ARCH is reading and writing the completed log files caused by the index build. So the 9GB of index could easily be responsible for vastly more I/O than the initial 9GB.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan -
Log file sync wait event advise?
Due to business needs, Apps has been designed to do every single transaction commit and coming to infrastructure, db Datafiles and redo logs are in faster disk (FC) and archive logs are placed in slower speed disk(SATA). We are seeing the log file sync wait event in the top events and symptoms for this waitevent is either disk speed is slow or doing frequent commit. In my scenario i guess 99% this wait event happening due to frequent commits. Can i assume archive log slower disk will not be root cause for this (my understanding this waitevent occurs on redo log writing area and not in archive log writing area) ? Please confirm.
user530956 wrote:
We are seeing the log file sync wait event in the top events and symptoms for this waitevent is either disk speed is slow or doing frequent commit.As Hemant has pointed out, this could also be due to CPU overload.
I note you say the event is IN the top events - this tells us virtually nothing; an event might be IN the top 5 while being responsible for less than 1% of the total recorded wait time; it could be IN the top 5 but explained as a side effect of something that appeared above it in the Top 5. Why not just show us a typical Top 5 (along with a typical Load Profile it you want to be really helpful).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files from text files, START and END the text with the tag {noformat}{noformat} (the word "code" in lowercase, curly brackets, no spaces) so that the text appears in fixed format. This won't be sufficient if you try to cut and paste from an HTML report, which will need further editing. -
Redo log space requests and Enqueue Waits
Hi all,
I am seeing an increase on the Enqueue Waits and Redo Log Space Request from 58, 274 to 192, 1245 in two weeks time respectively.
The DB is a production database and runs on an HP cluster with 4X1G ram and 550mghz cpu.
There are four Redo Log files with 200M (2 members each)which I have increased to 400M over this past weekend.
I have included below the memory structure details:
Redo Log Summary
Total System Global Area 1646094824 bytes
Fixed Size 104936 bytes
Variable Size 408989696 bytes
Database Buffers 1228800000 bytes
Redo Buffers 8200192 bytes
My question is that, who do I stop it from growing further and passing the 1:5000 ratio ?
At the moment the ratio is in the range of 1:186194.
Your input is much appreciated.
Cheers,
Seyoum.Here is some information from Oracle's Peformance Tuning Guide.
The V$SYSSTAT statistic redo log space requests indicates how many times a server process had to wait for space in the online redo log, not for space in the redo log buffer. A significant value for this statistic and the wait events should be used as an indication that checkpoints, DBWR, or archiver activity should be tuned, not LGWR. Increasing the size of log buffer does not help. -
Hello,
Our DB is having very high redo log space wait time :
redo log space requests 867527
redo log space wait time 67752674
LOG_BUFFER is 14 MB and having 6 redo logs groups and the size of redo log file is 500MB for each log file.
Also, the amount of redo generated per hour :
START_DATE START NUM_LOGS MBYTES DBNAME
2008-07-03 10:00 2 1000 TKL
2008-07-03 11:00 4 2000 TKL
2008-07-03 12:00 3 1500 TKL
Does increasing the size of LOG_BUFFER will help to reduce the redo log space wait ?
Thanks in advance ,
Regards,
AmanLooking quickly over the AWR report provided the following information could be helpful:
1. You are currently targeting approx. 6GB of memory with this single instance and the report tells that physical memory is 8GB. According to the advisories it looks like you could decrease your memory allocation without tampering your performance.
In particular the large_pool_size setting seems to be quite high although you're using shared servers.
Since you're using 10.2.0.4 it might be worth to think about using the single SGA_TARGET parameter instead of the specifying all the single parameters. This allows Oracle to size the shared pool components within the given target dynamically.
2. You are currently using a couple of underscore parameters. In particular the "_optimizer_max_permutations" parameter is set to 200 which might reduce significantly the number of execution plans permutations Oracle is investigating while optimizing the statement and could lead to suboptimal plans. It could be worth to check why this has been set.
In addition you are using a non-default setting of "_shared_pool_reserved_pct" which might no longer be necessary if you are using the SGA_TARGET parameter as mentioned above.
3. You are using non-default settings for the "optimizer_index_caching" and "optimizer_index_cost_adj" parameters which favor index-access paths / nested loops. Since the "db file sequntial read" is the top wait event it might be worth to check if the database is doing too excessive index access. Also most of the rows have been fetched by rowid (table fetch by rowid) which could also be an indicator for excessive index access/nested loop usage.
4. You database has been working quite a lot during the 30min. snapshot interval: It processed 123.000.000 logical blocks, which means almost 0.5GB per second. Check the top SQLs, there are a few that are responsible for most of the blocks processed. E.g. there is a anonymous PL/SQL block that has been executed almost 17.000 times during the interval representing 75% of the blocks processed. The statements executed as part of these procedures might be worth to check if they could be tuned to require less logical I/Os. This could be related to the non-default optimizer parameters mentioned above.
5. You are still using the compatible = 9.2.0 setting which means this database could still be opened by a 9i instance. If this is no longer required, you might lift this to the default value of 10g. This will also convert the REDO format to 10g I think which could lead to less amount of redo generated. But be aware of the fact that this is a one-way operation, you can only go back to 9i then via a restore once the compatible has been set to 10.x.
6. Your undo retention is set quite high (> 6000 secs), although your longest query in the AWR period was 151 seconds. It might be worth to check if this setting is reasonable, as you might have quite a large undo tablespace at present. Oracle 10g ignores the setting if it isn't able to honor the setting given the current Undo tablespace size.
7. "parallel_max_servers" has been set to 0, so no parallel operations can take place. This might be intentional but it's something to keep in mind.
Regards,
Randolf
Oracle related stuff:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle:
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/ -
Hi,
I can see "high redo log buffer wait" event. The instance spent 23% of its resources waiting for this event. Any suggestion to tune redo log buffer?
DB version : 10.2.0.4.0
Os : AIX
SQL> SELECT name, value FROM v$sysstat WHERE name = 'redo log space requests';
NAME VALUE
redo log space requests 3542
SQL> sho parameter buffer
NAME TYPE VALUE
buffer_pool_keep string
buffer_pool_recycle string
db_block_buffers integer 0
log_buffer integer 14238720
use_indirect_data_buffers boolean FALSE
SQL> select GROUP#,BYTES from v$log;
GROUP# BYTES
1 1073741824
4 1073741824
3 1073741824
2 1073741824
SQL> show parameter sga
NAME TYPE VALUE
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 5G
sga_target big integer 5G
ThanksGowin_dba wrote:
I can see "high redo log buffer wait" event. The instance spent 23% of its resources waiting for this event. Any suggestion to tune redo log buffer?
SQL> SELECT name, value FROM v$sysstat WHERE name = 'redo log space requests';
NAME VALUE
redo log space requests 3542 How are you getting from 3,542 "redo log space requests" to 23% of the instance resources waiting for "high redo log buffer wait" (which is not a wait event that can be found in v$event_name in any version of Oracle) ?
"redo log space requests" is about log FILE space, by the way, not about log BUFFER space.
Regards
Jonathan Lewis -
Streams capture waiting for dictionary redo log
Hi ,
The stream capture is waiting for the dictionary redo log
as per the alert logs ,the logminer is able to register the logfile
RFS LogMiner: Registered logfile [TEMP_114383_1_628824420.arc] to LogMiner session id [142]
Fri Feb 13 00:00:39 2009
Capture Session Redo Total
Capture Process Session Serial Entries LCRs
Name Number ID Number State Scanned Enqueued
C_REF C001 675 2707 WAITING FOR DICTIONARY REDO 0 0
Capture Capture Capture
Process Process Positive Negative Process
Name Queue Rule Set Rule Set Status
C_REF CA_REF RULESET$_80 ENABLED
Capture Capture
Capture Process Process
Name Queue START_SCN Status STATUS_CHAN CAPTURED_SCN APPLIED_SCN USE FIRST_SCN
C_REF CA_REF 8586133398117 ENABLED 12-Feb-2009 8586133398117 8586133398117 YES 8586133398117
CONSUMER_NAM SEQUENCE# FIRST_SCN NEXT_SCN TO_DATE(FIR TO_DATE(NEX NAME
C_REF 114378 8586133399062 8586162685837 12-Feb-2009 12-Feb-2009 /TEMP_114378_1_628824420.arc
C_REF 114379 8586162685837 8586163112496 12-Feb-2009 12-Feb-2009 /TEMP_114379_1_628824420.arc
C_REF 114380 8586163112496 8586163984886 12-Feb-2009 12-Feb-2009 /TEMP_114380_1_628824420.arc
C_REF 114381 8586163984886 8586163986301 12-Feb-2009 12-Feb-2009 /TEMP_114381_1_628824420.arc
C_REF 114382 8586163986301 8586163987651 12-Feb-2009 12-Feb-2009 /TEMP_114382_1_628824420.arc
C_REF 114383 8586163987651 8586163989497 12-Feb-2009 13-Feb-2009 /TEMP_114383_1_628824420.arc
C_REF 114384 8586163989497 8586163989674 13-Feb-2009 13-Feb-2009 /TEMP_114384_1_628824420.arc
Capture Time of
Name LogMiner ID Last Redo SCN Last Redo SCN
C_REF 142 8586166339742 00:10:13 02/13/09
i am not still able to make out even after the archivelogs are registered they are not done logmining by logminer.
Can you please help ,i am stuck up this situation.i have rebuild streams by completely removing the stream configuration and also dropped and recreated the strmadmin.Perhaps I missed it in your post but I didn't see a version number or any information as to what form of Streams was implemented or how.
There are step-by-step instructions for debugging Streams applications at metalink. I would suggest you find the directions for your version and follow them. -
Hi: I'm analyzing this STATSPACK report: it is "volume test" on our UAT server, so most input is from 'bind variables'. Our shared pool is well utilized in oracle. Oracle redo logs is not appropriately configured on this server, as in 'Top 5 wait events' there are 2 for redos.
I need to know what else information can be dig-out from 'foreground wait events' & 'background wait events', and what can assist us to better understanding, in combination of 'Top 5 wait event's, that how the server/test went? it could be overwelming No. of wait events, so appreciate any helpful diagnostic or analysis. Database is oracle 11.2.0.4 upgraded from 11.2.0.3, on IBM AIX power system 64bit, level 6.x
STATSPACK report for
Database DB Id Instance Inst Num Startup Time Release RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
700000XXX XXX 1 22-Apr-15 12:12 11.2.0.4.0 NO
Host Name Platform CPUs Cores Sockets Memory (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
dXXXX_XXX AIX-Based Systems (64- 2 1 0 16.0
Snapshot Snap Id Snap Time Sessions Curs/Sess Comment
~~~~~~~~ ---------- ------------------ -------- --------- ------------------
Begin Snap: 5635 22-Apr-15 13:00:02 114 4.6
End Snap: 5636 22-Apr-15 14:00:01 128 8.8
Elapsed: 59.98 (mins) Av Act Sess: 0.6
DB time: 35.98 (mins) DB CPU: 19.43 (mins)
Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 2,064M Std Block Size: 8K
Shared Pool: 3,072M Log Buffer: 13,632K
Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~ ------------------ ----------------- ----------- -----------
DB time(s): 0.6 0.0 0.00 0.00
DB CPU(s): 0.3 0.0 0.00 0.00
Redo size: 458,720.6 8,755.7
Logical reads: 12,874.2 245.7
Block changes: 1,356.4 25.9
Physical reads: 6.6 0.1
Physical writes: 61.8 1.2
User calls: 2,033.7 38.8
Parses: 286.5 5.5
Hard parses: 0.5 0.0
W/A MB processed: 1.7 0.0
Logons: 1.2 0.0
Executes: 801.1 15.3
Rollbacks: 6.1 0.1
Transactions: 52.4
Instance Efficiency Indicators
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 99.98 Optimal W/A Exec %: 100.00
Library Hit %: 99.77 Soft Parse %: 99.82
Execute to Parse %: 64.24 Latch Hit %: 99.98
Parse CPU to Parse Elapsd %: 53.15 % Non-Parse CPU: 98.03
Shared Pool Statistics Begin End
Memory Usage %: 10.50 12.79
% SQL with executions>1: 69.98 78.37
% Memory for SQL w/exec>1: 70.22 81.96
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time
CPU time 847 50.2
enq: TX - row lock contention 4,480 434 97 25.8
log file sync 284,169 185 1 11.0
log file parallel write 299,537 164 1 9.7
log file sequential read 698 16 24 1.0
Host CPU (CPUs: 2 Cores: 1 Sockets: 0)
~~~~~~~~ Load Average
Begin End User System Idle WIO WCPU
1.16 1.84 19.28 14.51 66.21 1.20 82.01
Instance CPU
~~~~~~~~~~~~ % Time (seconds)
Host: Total time (s): 7,193.8
Host: Busy CPU time (s): 2,430.7
% of time Host is Busy: 33.8
Instance: Total CPU time (s): 1,203.1
% of Busy CPU used for Instance: 49.5
Instance: Total Database time (s): 2,426.4
%DB time waiting for CPU (Resource Mgr): 0.0
Memory Statistics Begin End
~~~~~~~~~~~~~~~~~ ------------ ------------
Host Mem (MB): 16,384.0 16,384.0
SGA use (MB): 7,136.0 7,136.0
PGA use (MB): 282.5 361.4
% Host Mem used for SGA+PGA: 45.3 45.8
Foreground Wait Events DB/Inst: XXXXXs Snaps: 5635-5636
-> Only events with Total Wait Time (s) >= .001 are shown
-> ordered by Total Wait Time desc, Waits desc (idle events last)
Avg %Total
%Tim Total Wait wait Waits Call
Event Waits out Time (s) (ms) /txn Time
enq: TX - row lock contentio 4,480 0 434 97 0.0 25.8
log file sync 284,167 0 185 1 1.5 11.0
Disk file operations I/O 8,741 0 4 0 0.0 .2
direct path write 13,247 0 3 0 0.1 .2
db file sequential read 6,058 0 1 0 0.0 .1
buffer busy waits 1,800 0 1 1 0.0 .1
SQL*Net more data to client 29,161 0 1 0 0.2 .1
direct path read 7,696 0 1 0 0.0 .0
db file scattered read 316 0 1 2 0.0 .0
latch: shared pool 144 0 0 2 0.0 .0
CSS initialization 30 0 0 3 0.0 .0
cursor: pin S 10 0 0 9 0.0 .0
row cache lock 41 0 0 2 0.0 .0
latch: row cache objects 19 0 0 3 0.0 .0
log file switch (private str 8 0 0 7 0.0 .0
library cache: mutex X 28 0 0 2 0.0 .0
latch: cache buffers chains 54 0 0 1 0.0 .0
latch free 290 0 0 0 0.0 .0
control file sequential read 1,568 0 0 0 0.0 .0
log file switch (checkpoint 4 0 0 6 0.0 .0
direct path sync 8 0 0 3 0.0 .0
latch: redo allocation 60 0 0 0 0.0 .0
SQL*Net break/reset to clien 34 0 0 1 0.0 .0
latch: enqueue hash chains 45 0 0 0 0.0 .0
latch: cache buffers lru cha 7 0 0 2 0.0 .0
latch: session allocation 5 0 0 1 0.0 .0
latch: object queue header o 6 0 0 1 0.0 .0
ASM file metadata operation 30 0 0 0 0.0 .0
latch: In memory undo latch 15 0 0 0 0.0 .0
latch: undo global data 8 0 0 0 0.0 .0
SQL*Net message from client 6,362,536 0 278,225 44 33.7
jobq slave wait 7,270 100 3,635 500 0.0
SQL*Net more data from clien 7,976 0 15 2 0.0
SQL*Net message to client 6,362,544 0 8 0 33.7
Background Wait Events DB/Inst: XXXXXs Snaps: 5635-5636
-> Only events with Total Wait Time (s) >= .001 are shown
-> ordered by Total Wait Time desc, Waits desc (idle events last)
Avg %Total
%Tim Total Wait wait Waits Call
Event Waits out Time (s) (ms) /txn Time
log file parallel write 299,537 0 164 1 1.6 9.7
log file sequential read 698 0 16 24 0.0 1.0
db file parallel write 9,556 0 13 1 0.1 .8
os thread startup 146 0 10 70 0.0 .6
control file parallel write 2,037 0 2 1 0.0 .1
Log archive I/O 35 0 1 30 0.0 .1
LGWR wait for redo copy 2,447 0 0 0 0.0 .0
db file async I/O submit 9,556 0 0 0 0.1 .0
db file sequential read 145 0 0 2 0.0 .0
Disk file operations I/O 349 0 0 0 0.0 .0
db file scattered read 30 0 0 4 0.0 .0
control file sequential read 5,837 0 0 0 0.0 .0
ADR block file read 19 0 0 4 0.0 .0
ADR block file write 5 0 0 15 0.0 .0
direct path write 14 0 0 2 0.0 .0
direct path read 3 0 0 7 0.0 .0
latch: shared pool 3 0 0 6 0.0 .0
log file single write 56 0 0 0 0.0 .0
latch: redo allocation 53 0 0 0 0.0 .0
latch: active service list 1 0 0 3 0.0 .0
latch free 11 0 0 0 0.0 .0
rdbms ipc message 314,523 5 57,189 182 1.7
Space Manager: slave idle wa 4,086 88 18,996 4649 0.0
DIAG idle wait 7,185 100 7,186 1000 0.0
Streams AQ: waiting for time 2 50 4,909 ###### 0.0
Streams AQ: qmn slave idle w 129 0 3,612 28002 0.0
Streams AQ: qmn coordinator 258 50 3,612 14001 0.0
smon timer 43 2 3,605 83839 0.0
pmon timer 1,199 99 3,596 2999 0.0
SQL*Net message from client 17,019 0 31 2 0.1
SQL*Net message to client 12,762 0 0 0 0.1
class slave wait 28 0 0 0 0.0
thank you very much!Hi: just know it now: it is a large amount of 'concurrent transaction' designed in this "Volume Test" - to simulate large incoming transaction volme, so I guess wait in eq:TX - row is expected.
The fact: (1) redo logs at uat server is known to not well-tune for configurations (2) volume test slow 5%, however data amount in its test is kept the same by each time import production data, by the team. So why it slowed 5% this year?
The wait histogram is pasted below, any one interest to take a look? any ideas?
Wait Event Histogram DB/Inst: XXXX/XXXX Snaps: 5635-5636
-> Total Waits - units: K is 1000, M is 1000000, G is 1000000000
-> % of Waits - column heading: <=1s is truly <1024ms, >1s is truly >=1024ms
-> % of Waits - value: .0 indicates value was <.05%, null is truly 0
-> Ordered by Event (idle events last)
Total ----------------- % of Waits ------------------
Event Waits <1ms <2ms <4ms <8ms <16ms <32ms <=1s >1s
ADR block file read 19 26.3 5.3 10.5 57.9
ADR block file write 5 40.0 60.0
ADR file lock 6 100.0
ARCH wait for archivelog l 14 100.0
ASM file metadata operatio 30 100.0
CSS initialization 30 100.0
Disk file operations I/O 9090 97.2 1.4 .6 .4 .2 .1 .1
LGWR wait for redo copy 2447 98.5 .5 .4 .2 .2 .2 .1
Log archive I/O 35 40.0 8.6 25.7 2.9 22.9
SQL*Net break/reset to cli 34 85.3 8.8 5.9
SQL*Net more data to clien 29K 99.9 .0 .0 .0 .0 .0
buffer busy waits 1800 96.8 .7 .7 .6 .3 .4 .5
control file parallel writ 2037 90.7 5.0 2.1 .8 1.0 .3 .1
control file sequential re 7405 100.0 .0
cursor: pin S 10 10.0 90.0
db file async I/O submit 9556 99.9 .0 .0 .0
db file parallel read 1 100.0
db file parallel write 9556 62.0 32.4 1.7 .8 1.5 1.3 .1
db file scattered read 345 72.8 3.8 2.3 11.6 9.0 .6
db file sequential read 6199 97.2 .2 .3 1.6 .7 .0 .0
direct path read 7699 99.1 .4 .2 .1 .1 .0
direct path sync 8 25.0 37.5 12.5 25.0
direct path write 13K 97.8 .9 .5 .4 .3 .1 .0
enq: TX - row lock content 4480 .4 .7 1.3 3.0 6.8 12.3 75.4 .1
latch free 301 98.3 .3 .7 .7
latch: In memory undo latc 15 93.3 6.7
latch: active service list 1 100.0
latch: cache buffers chain 55 94.5 3.6 1.8
latch: cache buffers lru c 9 88.9 11.1
latch: call allocation 6 100.0
latch: checkpoint queue la 3 100.0
latch: enqueue hash chains 45 97.8 2.2
latch: messages 4 100.0
latch: object queue header 7 85.7 14.3
latch: redo allocation 113 97.3 1.8 .9
latch: row cache objects 19 89.5 5.3 5.3
latch: session allocation 5 80.0 20.0
latch: shared pool 147 90.5 1.4 2.7 1.4 .7 1.4 2.0
latch: undo global data 8 100.0
library cache: mutex X 28 89.3 3.6 3.6 3.6
log file parallel write 299K 95.6 2.6 1.0 .4 .3 .2 .0
log file sequential read 698 29.5 .1 4.6 46.8 18.9
log file single write 56 100.0
log file switch (checkpoin 4 25.0 50.0 25.0
log file switch (private s 8 12.5 37.5 50.0
log file sync 284K 93.3 3.7 1.4 .7 .5 .3 .1
os thread startup 146 100.0
row cache lock 41 85.4 9.8 2.4 2.4
DIAG idle wait 7184 100.0
SQL*Net message from clien 6379K 86.6 5.1 2.9 1.3 .7 .3 2.8 .3
SQL*Net message to client 6375K 100.0 .0 .0 .0 .0 .0 .0
Wait Event Histogram DB/Inst: XXXX/xxxx Snaps: 5635-5636
-> Total Waits - units: K is 1000, M is 1000000, G is 1000000000
-> % of Waits - column heading: <=1s is truly <1024ms, >1s is truly >=1024ms
-> % of Waits - value: .0 indicates value was <.05%, null is truly 0
-> Ordered by Event (idle events last)
Total ----------------- % of Waits ------------------
Event Waits <1ms <2ms <4ms <8ms <16ms <32ms <=1s >1s
SQL*Net more data from cli 7976 99.7 .1 .1 .0 .1
Space Manager: slave idle 4086 .1 .2 .0 .0 .3 3.2 96.1
Streams AQ: qmn coordinato 258 49.2 .8 50.0
Streams AQ: qmn slave idle 129 100.0
Streams AQ: waiting for ti 2 50.0 50.0
class slave wait 28 92.9 3.6 3.6
jobq slave wait 7270 .0 100.0
pmon timer 1199 100.0
rdbms ipc message 314K 10.3 7.3 39.7 15.4 10.6 5.3 8.2 3.3
smon timer 43 100.0 -
ORA-00333: redo log read error block
ORA-01033: ORACLE initialization or shutdown in progress ...
/ as sysdba
SQL> shutdown immediate;
SQL> startup nomount;
SQL> alter database mount;
SQL> alter database open;
ORA-00333: redo log read error block 8299 count 8192
SQL> SELECT * FROM V$VERSION;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Product
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
SQL> select group#,members,THREAD, STATUS,ARCHIVED,BYTES,FIRST_TIME,FIRST_CHAGE#,SEQUENCE# from v$log;
GROUP# MEMBERS,THREAD,STATUS,ARCHIVED,BYTES,FIRST_TIME,FIRST_CHAGE#,SEQUENCE#
1 1 1 CURRENT NO 52428800 29-FEB-12 1597643 57
2 1 1 INACTIVE NO 52428800 29-FEB-12 1573462 56
Dump file c:\oraclexe\app\oracle\admin\xe\bdump\alert_xe.log
Wed Feb 29 19:46:38 2012
Recovery of Online Redo Log: Thread 1 Group 1 Seq 56 Reading mem 0
Mem# 0 errs 0: C:\ORACLEXE\APP\ORACLE\FLASH_RECOVERY_AREA\XE\ONLINELOG\O1_MF_1_7LZYZK8S_.LOG
Wed Feb 29 19:46:40 2012
Completed redo application
Wed Feb 29 19:46:40 2012
Completed crash recovery at
Thread 1: logseq 56, block 6568, scn 1597642
270 data blocks read, 270 data blocks written, 1460 redo blocks read
Wed Feb 29 19:46:43 2012
Thread 1 advanced to log sequence 57
Thread 1 opened at log sequence 57
Current log# 2 seq# 57 mem# 0: C:\ORACLEXE\APP\ORACLE\FLASH_RECOVERY_AREA\XE\ONLINELOG\O1_MF_2_7LZYZL5V_.LOG
Successful open of redo thread 1
Wed Feb 29 19:46:43 2012
SMON: enabling cache recovery
Wed Feb 29 19:46:55 2012
Successfully onlined Undo Tablespace 1.
Wed Feb 29 19:46:55 2012
SMON: enabling tx recovery
Wed Feb 29 19:46:56 2012
Database Characterset is AL32UTF8
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=19, OS id=3024
Wed Feb 29 19:47:09 2012
Completed: alter database open
Wed Feb 29 19:47:14 2012
db_recovery_file_dest_size of 10240 MB is 0.98% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Wed Feb 29 20:33:30 2012
MMNL absent for 1537 secs; Foregrounds taking over
Wed Feb 29 20:33:31 2012
MMNL absent for 1540 secs; Foregrounds taking over
Wed Feb 29 20:33:31 2012
MMNL absent for 1540 secs; Foregrounds taking over
MMNL absent for 1540 secs; Foregrounds taking over
Wed Feb 29 20:33:32 2012
MMNL absent for 1540 secs; Foregrounds taking over
Wed Feb 29 20:33:33 2012
MMNL absent for 1540 secs; Foregrounds taking over
Wed Feb 29 21:45:24 2012
MMNL absent for 4318 secs; Foregrounds taking over
MMNL absent for 4318 secs; Foregrounds taking over
MMNL absent for 4322 secs; Foregrounds taking over
Dump file c:\oraclexe\app\oracle\admin\xe\bdump\alert_xe.log
Wed Feb 29 22:30:01 2012
ORACLE V10.2.0.1.0 - Production vsnsta=0
vsnsql=14 vsnxtr=3
Windows XP Version V5.1 Service Pack 3, v.3244
CPU : 2 - type 586, 2 Physical Cores
Process Affinity : 0x00000000
Memory (Avail/Total): Ph:3097M/3546M, Ph+PgF:5143M/5429M, VA:1943M/2047M
Wed Feb 29 22:30:01 2012
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
IMODE=BR
ILAT =10
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.1.0.
System parameters with non-default values:
sessions = 49
__shared_pool_size = 201326592
__large_pool_size = 8388608
__java_pool_size = 4194304
__streams_pool_size = 0
spfile = C:\ORACLEXE\APP\ORACLE\PRODUCT\10.2.0\SERVER\DBS\SPFILEXE.ORA
sga_target = 805306368
control_files = C:\ORACLEXE\ORADATA\XE\CONTROL.DBF
__db_cache_size = 587202560
compatible = 10.2.0.1.0
db_recovery_file_dest = C:\oraclexe\app\oracle\flash_recovery_area
db_recovery_file_dest_size= 10737418240
undo_management = AUTO
undo_tablespace = UNDO
remote_login_passwordfile= EXCLUSIVE
dispatchers = (PROTOCOL=TCP) (SERVICE=XEXDB)
shared_servers = 4
local_listener = (ADDRESS=(PROTOCOL=TCP)(HOST=winsp3ue)(PORT=1522))
job_queue_processes = 4
audit_file_dest = C:\ORACLEXE\APP\ORACLE\ADMIN\XE\ADUMP
background_dump_dest = C:\ORACLEXE\APP\ORACLE\ADMIN\XE\BDUMP
user_dump_dest = C:\ORACLEXE\APP\ORACLE\ADMIN\XE\UDUMP
core_dump_dest = C:\ORACLEXE\APP\ORACLE\ADMIN\XE\CDUMP
db_name = XE
open_cursors = 300
os_authent_prefix =
pga_aggregate_target = 268435456
PMON started with pid=2, OS id=2176
PSP0 started with pid=3, OS id=2204
MMAN started with pid=4, OS id=2208
DBW0 started with pid=5, OS id=2212
LGWR started with pid=6, OS id=2220
CKPT started with pid=7, OS id=2240
SMON started with pid=8, OS id=2460
RECO started with pid=9, OS id=2464
CJQ0 started with pid=10, OS id=2480
MMON started with pid=11, OS id=2484
Wed Feb 29 22:30:02 2012
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started with pid=12, OS id=2492
Wed Feb 29 22:30:02 2012
starting up 4 shared server(s) ...
Oracle Data Guard is not available in this edition of Oracle.
Wed Feb 29 22:30:02 2012
alter database mount exclusive
Wed Feb 29 22:30:06 2012
Setting recovery target incarnation to 2
Wed Feb 29 22:30:06 2012
Successful mount of redo thread 1, with mount id 2657657770
Wed Feb 29 22:30:06 2012
Database mounted in Exclusive Mode
Completed: alter database mount exclusive
Wed Feb 29 22:30:07 2012
alter database open
Wed Feb 29 22:30:07 2012
Beginning crash recovery of 1 threads
Wed Feb 29 22:30:07 2012
Started redo scan
Wed Feb 29 22:30:15 2012
Errors in file c:\oraclexe\app\oracle\admin\xe\udump\xe_ora_2544.trc:
ORA-00333: redo log read error block 10347 count 6144
ORA-00312: online log 2 thread 1: 'C:\ORACLEXE\APP\ORACLE\FLASH_RECOVERY_AREA\XE\ONLINELOG\O1_MF_2_7LZYZL5V_.LOG'
ORA-27070: async read/write failed
OSD-04016: Error queuing an asynchronous I/O request.
O/S-Error: (OS 23) Data error (cyclic redundancy check).
Waiting for Help
RegardsErrors in file c:\oraclexe\app\oracle\admin\xe\udump\xe_ora_2544.trc:
ORA-00333: redo log read error block 10347 count 6144
ORA-00312: online log 2 thread 1: 'C:\ORACLEXE\APP\ORACLE\FLASH_RECOVERY_AREA\XE\ONLINELOG\O1_MF_2_7LZYZL5V_.LOG'
ORA-27070: async read/write failed
OSD-04016: Error queuing an asynchronous I/O request.
O/S-Error: (OS 23) Data error (cyclic redundancy check).Might your redo log file is corrupted or not exist, check physically. -> C:\ORACLEXE\APP\ORACLE\FLASH_RECOVERY_AREA\XE\ONLINELOG\O1_MF_2_7LZYZL5V_.LOG
is it archivelog mode?
perform fake recovery and open resetlogs. -
Bottleneck when switching the redo log files.
Hello All,
I am using Oracle 11.2.0.3.
The application team reported that they are facing slowness at certain time.
I monitored the database and I found that at some switching of the redo log files (not always) I am facing a slowness at the application level.
I have 2 threads since my database is RAC, each thread have 3 redo log groups multiplexed to the FRA, with size 300 MB each.
Is there any way to optimize the switch of redo log files? knowing that my database is running in ARCHIVELOG mode.
Regards,Hello Nikolay,
Thanks for your input I am sharing with you the below information. I have 2 instances so I will provide the info from each instance
Instance 1:
Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~ --------------- --------------- ---------- ----------
DB Time(s): 4.9 0.0 0.00 0.00
DB CPU(s): 1.1 0.0 0.00 0.00
Redo size: 3,014,876.2 3,660.4
Logical reads: 32,619.3 39.6
Block changes: 7,969.0 9.7
Physical reads: 0.2 0.0
Physical writes: 164.0 0.2
User calls: 7,955.4 9.7
Parses: 288.9 0.4
Hard parses: 96.0 0.1
W/A MB processed: 0.2 0.0
Logons: 0.9 0.0
Executes: 2,909.4 3.5
Rollbacks: 0.0 0.0
Instance 2:
Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~ --------------- --------------- ---------- ----------
DB Time(s): 5.5 0.0 0.00 0.00
DB CPU(s): 1.4 0.0 0.00 0.00
Redo size: 3,527,737.9 3,705.7
Logical reads: 29,916.5 31.4
Block changes: 8,893.7 9.3
Physical reads: 0.2 0.0
Physical writes: 194.0 0.2
User calls: 7,742.8 8.1
Parses: 262.7 0.3
Hard parses: 99.5 0.1
W/A MB processed: 0.4 0.0
Logons: 1.0 0.0
Executes: 2,822.5 3.0
Rollbacks: 0.0 0.0
Transactions: 952.0
Instance 1:
Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avg
wait % DB
Event Waits Time(s) (ms) time Wait Class
DB CPU 1,043 21.5
log file sync 815,334 915 1 18.9 Commit
gc buffer busy acquire 323,759 600 2 12.4 Cluster
gc current block busy 215,132 585 3 12.1 Cluster
enq: TX - row lock contention 23,284 264 11 5.5 Applicatio
Instance 2:
Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Avg
wait % DB
Event Waits Time(s) (ms) time Wait Class
DB CPU 1,340 24.9
log file sync 942,962 1,125 1 20.9 Commit
gc buffer busy acquire 377,812 594 2 11.0 Cluster
gc current block busy 211,270 488 2 9.1 Cluster
enq: TX - row lock contention 30,094 299 10 5.5 Applicatio
Instance 1:
Operating System Statistics Snaps: 1016-1017
-> *TIME statistic values are diffed.
All others display actual values. End Value is displayed if different
-> ordered by statistic type (CPU Use, Virtual Memory, Hardware Config), Name
Statistic Value End Value
AVG_BUSY_TIME 17,451
AVG_IDLE_TIME 81,268
AVG_IOWAIT_TIME 1
AVG_SYS_TIME 6,854
AVG_USER_TIME 10,548
BUSY_TIME 420,031
IDLE_TIME 1,951,741
IOWAIT_TIME 288
SYS_TIME 165,709
USER_TIME 254,322
LOAD 3 6
OS_CPU_WAIT_TIME 523,000
RSRC_MGR_CPU_WAIT_TIME 0
VM_IN_BYTES 311,280
VM_OUT_BYTES 75,862,008
PHYSICAL_MEMORY_BYTES 62,813,896,704
NUM_CPUS 24
NUM_CPU_CORES 6
NUM_LCPUS 24
NUM_VCPUS 6
GLOBAL_RECEIVE_SIZE_MAX 4,194,304
GLOBAL_SEND_SIZE_MAX 4,194,304
TCP_RECEIVE_SIZE_DEFAULT 16,384
TCP_RECEIVE_SIZE_MAX 9.2233720368547758E+18
TCP_RECEIVE_SIZE_MIN 4,096
TCP_SEND_SIZE_DEFAULT 16,384
TCP_SEND_SIZE_MAX 9.2233720368547758E+18
TCP_SEND_SIZE_MIN 4,096
Operating System Statistics - Detail Snaps: 1016-101
Snap Time Load %busy %user %sys %idle %iowait
22-Aug 11:33:55 2.7 N/A N/A N/A N/A N/A
22-Aug 11:50:23 6.2 17.7 10.7 7.0 82.3 0.0
Instance 2:
Operating System Statistics Snaps: 1016-1017
-> *TIME statistic values are diffed.
All others display actual values. End Value is displayed if different
-> ordered by statistic type (CPU Use, Virtual Memory, Hardware Config), Name
Statistic Value End Value
AVG_BUSY_TIME 11,823
AVG_IDLE_TIME 86,923
AVG_IOWAIT_TIME 0
AVG_SYS_TIME 4,791
AVG_USER_TIME 6,991
BUSY_TIME 475,210
IDLE_TIME 3,479,382
IOWAIT_TIME 410
SYS_TIME 193,602
USER_TIME 281,608
LOAD 3 6
OS_CPU_WAIT_TIME 615,400
RSRC_MGR_CPU_WAIT_TIME 0
VM_IN_BYTES 16,360
VM_OUT_BYTES 72,699,920
PHYSICAL_MEMORY_BYTES 62,813,896,704
NUM_CPUS 40
NUM_CPU_CORES 10
NUM_LCPUS 40
NUM_VCPUS 10
GLOBAL_RECEIVE_SIZE_MAX 4,194,304
GLOBAL_SEND_SIZE_MAX 4,194,304
TCP_RECEIVE_SIZE_DEFAULT 16,384
TCP_RECEIVE_SIZE_MAX 9.2233720368547758E+18
TCP_RECEIVE_SIZE_MIN 4,096
TCP_SEND_SIZE_DEFAULT 16,384
TCP_SEND_SIZE_MAX 9.2233720368547758E+18
TCP_SEND_SIZE_MIN 4,096
Operating System Statistics - Detail Snaps: 1016-101
Snap Time Load %busy %user %sys %idle %iowait
22-Aug 11:33:55 2.6 N/A N/A N/A N/A N/A
22-Aug 11:50:23 5.6 12.0 7.1 4.9 88.0 0.0
------------------------------------------------------------- -
Multiplexing redo logs and control files to a separate diskgroup
General question this one...
I've been using ASM for a few years now and have always installed a new system with 3 diskgroups
+DATA - for datafiles, control files, redo logs
+FRA - for achive logs, flash recovery. RMAN backup
Those I guess are the standards, but I've always created an extra (very small) diskgroup, called +ONLINE where I keep multiplexed copies of the redo logs and control files.
My reasoning behind this is that if there are any issues with the +DATA diskgroup, the redo logs and control files can still be accessed.
In the olden days (all those 5 years ago!), on local storage, this was important, but is it still important now? With all the striping and mirroring going on (both at ASM and RAID level), am I just being overtly paranoid? Does this additional +ONLINE diskgroup actually hamper performance? (with dual write overheads that are not necessary)
Thoughts?Some of the decision will probably depend on your specific environment's data activity, volume, and throughput.
Something to remember is that redo logs are sequential write, which benefit from a lower RAID overhead (RAID-10, 2 writes per IOP vs RAID-5, 4 writes per IOP). RAID-10 is often not cost-effective for the data portion of a database. If your database is OLTP with a high volume of random reads/writes, you're potentially hurting redo throughput by creating contention on the disks sharing data and redo. Again, that depends entirely on what you're seeing in terms of wait events. A low volume database would probably not experience any noticeable degraded performance.
In my environment, I have RAID-5 and RAID-10 available, and since the RAID-10 requirement from a capacity perspective for redo is very low, it makes sense to create 2 diskgroups for online redo, separate from DATA, and separate from each other. This way, we don't need to be concerned with DATA transactions impacting REDO performance, and vice versa, and we still maintain redo redundancy.
In my opinion, you can't be too paranoid. :)
Good luck!
K
Maybe you are looking for
-
RDDEXCEL job is getting cancelled
Dear All, While transporting the request, the request ending with error code -12 , when i checked the log its showing RDDEXCEL JOB is cancelled , This is happening for every request . Thanks in advance . Thanks S SURESH <subject_modified> Do NOT use
-
I can't print only selected text since upgrading to Firefox 8.0. Using Mac OS Lion
Until Firefox 8.0, I could select text on any webpage and print only that text. Now, I can't even get a print dialog box with an option to "Print Selection" only. I also recently upgraded to OS Lion (from OS Leopard) on Mac. Any chance that that is t
-
[solved] Conky docking problem.
Sorry for my poor English. I hope you can understand what I say. I want to make my conky stay at bottom like a panel. So I try this in my .conkyrc: own_window yes own_window_transparent no own_window_type dock alignment bottom_middle But the problem
-
Component to component communication
Hi i have aDC with two components comp1 and comp2 i want to call amethod present in comp1 from comp2,can you please tell me how to do it. thanks rahul
-
Hi all, I've deployed a content delivery network with a CE565 as a CDM, a CE7205 as the main root content engine and some 10 content engines at remote locations on the end of various speed links. I have some video content on a web server. I've create