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.
Similar Messages
-
Redo log space requests VALUE high
SELECT name||' = '||value
FROM v$sysstat
WHERE name = 'redo log space requests';
I am noticing 40+ space requests for some of my Oracle 9.2.0.5 databases.
On another 7.3.4 DB I see this over 140 but this DB shutdown only on weekends so this cumulative value increases I presume.
I have 20MB of 5 groups already. Do I still add another 2 more groups or increase their sizes ?
I did read somewhere that I'd have to increase the log_buffer parameter. So how do we deal with this issue ? Any repercussions if I let this as it is for now ?
The cause of this would be redo logs are not big enough or otherwise ?
Thanks.user4874781 wrote:
Thanks for your response Charles.
So if I understand this correctly ... Redolog Space requests corresponds to a either an incorrectly sized redo log file / DBWR / CKPT needs to be tuned.
Maybe I was interpreting this the wrong way. (Possibly)
" The statistic 'redo log space requests' reflects the number of times a user process waits for space in the redo log buffer. " If that is the case, if there was longer waits for this event, I was under the assumption that log_buffer needs to be increased.
http://www.idevelopment.info/data/Oracle/DBA_tips/Tuning/TUNING_6.shtml
* Yes, the waits have increased to 70 as of now (since 40 yesterday .. DB was started Saturday night and will run till weekend) Less activity as of now, since the day has just started ; so it would definitely rise by end of the day. I took a look at the above article, and I think I understand why the article is slightly confusing. With due respect to the author, the article was last modified 16-Apr-2001, which I believe is before the Oracle documentation was better clarified regarding these statistics. From:
http://download.oracle.com/docs/cd/B14117_01/server.101/b10755/stats002.htm
"redo log space requests: Number of times the active log file is full and Oracle must wait for disk space to be allocated for the redo log entries. Such space is created by performing a log switch. Log files that are small in relation to the size of the SGA or the commit rate of the work load can cause problems. When the log switch occurs, Oracle must ensure that all committed dirty buffers are written to disk before switching to a new log file. If you have a large SGA full of dirty buffers and small redo log files, a log switch must wait for DBWR to write dirty buffers to disk before continuing."
"redo log space wait time: Total elapsed waiting time for "redo log space requests" in 10s of milliseconds"
It is quite possible that the "redo log space requests" will increase with every redo log file switch, which should not be too much of a concern. You may want to focus a little more on the "redo log space wait time" statistic, which indicates how much wait time was involved waiting. You might also want to focus on the system-wide wait event interface, examining how the accumulated wait time increases from one sampling of each of the statistics to the next.
* I have 1 log switch every 11 minutes ; BTW ; I have 5 log groups of 20 MB each as of now. So I am assuming 40 MB of 4 or 5 log groups should be fine as per your suggestion ?If you have the disk space, considering that it is an ancient AIX box, you may want to set the redo log files to an even larger size, possibly 100MB (or larger). You may then want to force periodic switches of the redo log, for instance once an hour, or once every 30 minutes.
* This is an ancient AIX box with 512 MB Ram. Is the redo log located on a fast device ? I'd have to find that out ( any hints on that ? )
* Decreasing the log_buffer is possible on weekends since I'd have to bounce it for it to take effect.
I will increase the log files accordingly and hopefully the space waits will reduce. Thanks again.Someone else, possibly Sybrand, on the forums might be familiar with AIX and be able to provide you with an answer. If you are seeing system-wide increasing wait time for redo related waits, then that might be an indication that the redo logs are not located on a fast device.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
Redo log space requests should be zero?
do logbuffer should be request s should be zero
as my environment showing below as output
let me know do i need to log switch manually
SQL> select name,value
2 from v$sysstat
3 where name='redo log space requests';
NAME VALUE
redo log space requests 14130Hi Can you please post the output of this as well
=====================
SET PAGESIZE 90
SET LINESIZE 150
set heading on
column "00:00" format 9999
column "01:00" format 9999
column "02:00" format 9999
column "03:00" format 9999
column "04:00" format 9999
column "05:00" format 9999
column "06:00" format 9999
column "07:00" format 9999
column "08:00" format 9999
column "09:00" format 9999
column "10:00" format 9999
column "11:00" format 9999
column "12:00" format 9999
column "13:00" format 9999
column "14:00" format 9999
column "15:00" format 9999
column "16:00" format 9999
column "17:00" format 9999
column "18:00" format 9999
column "19:00" format 9999
column "20:00" format 9999
column "21:00" format 9999
column "22:00" format 9999
column "23:00" format 9999
SELECT * FROM (
SELECT * FROM (
SELECT TO_CHAR(FIRST_TIME, 'DD/MM') AS "DAY"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '00', 1, 0), '99')) "00:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '01', 1, 0), '99')) "01:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '02', 1, 0), '99')) "02:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '03', 1, 0), '99')) "03:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '04', 1, 0), '99')) "04:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '05', 1, 0), '99')) "05:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '06', 1, 0), '99')) "06:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '07', 1, 0), '99')) "07:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '08', 1, 0), '99')) "08:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '09', 1, 0), '99')) "09:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '10', 1, 0), '99')) "10:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '11', 1, 0), '99')) "11:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '12', 1, 0), '99')) "12:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '13', 1, 0), '99')) "13:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '14', 1, 0), '99')) "14:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '15', 1, 0), '99')) "15:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '16', 1, 0), '99')) "16:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '17', 1, 0), '99')) "17:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '18', 1, 0), '99')) "18:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '19', 1, 0), '99')) "19:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '20', 1, 0), '99')) "20:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '21', 1, 0), '99')) "21:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '22', 1, 0), '99')) "22:00"
, SUM(TO_NUMBER(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '23', 1, 0), '99')) "23:00"
FROM V$LOG_HISTORY
WHERE extract(year FROM FIRST_TIME) = extract(year FROM sysdate)
GROUP BY TO_CHAR(FIRST_TIME, 'DD/MM')
) ORDER BY TO_DATE(extract(year FROM sysdate) || DAY, 'YYYY DD/MM') DESC
) WHERE ROWNUM <8;
==========================
select GROUP#,members,bytes/1024/1024 from v$log;
Cheers..
Sameer Ameen -
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/ -
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,
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 -
Recursive call with commit not written to redo log
In my DBA training I was led to the belief that a commit caused the log writer to write the redo log buffer to the redo log file, but I find this is not true if the commit is inside recursive code.
I believe this is intentional as a way off reducing i/o but it does raise data integrity problems.
Apparently if you have some PL/SQL (can be sql*plus code or procedure) with a loop containing a commit,
the commit does not actually ensure that the transaction is written to the Redo log.
Instead Oracle only ensures all is written to the redo log when control is returned to the application/sqlplus.
You can see this by checking the redo writes in v$sysstat.
It will be less than the number of expected commits.
Thus the old rule of expecting all committed transation to be there after a database recovery is not necessarily true.
Does anyone know how to force the commit to ensure redo is written
-inside pl/sql or perhaps a setting in the the calling environment ?
ThanksThanks for your input
The trouble is that I believe if you stopped in a debugger the log writer would catch up -
Or if you killed your instance in the middle of this test you wouldn't be sure how many commits the db thought it did
ie. the db would recover to the last known commit in the redo logs
- maybe I should turn on tracing ?
Since my question I have a found a site that seems to back up the results I am getting
http://www.ixora.com.au/notes/redo_write_triggers.htm
see the note under point 3
Have a look at the stats below and you will see
redo writes 19026
user commits 100057
How I actually tested was to run
the utlbstat scipt
then run some pl/sql that
- mimiced a business transactions (4 select lookup validations, 2 inserts and 1 insert or update and a commit)
- loop * 100000
then ran utlestat.sql
i.e. test script
@C:\oracle\ora92\rdbms\admin\utlbstat.sql
connect test/test
@c:\mig\Load_test.sql
@C:\oracle\ora92\rdbms\admin\utlestat.sql
Statistic Total Per Transact Per Logon Per Second
CPU used by this session 37433 .37 935.83 79.31
CPU used when call started 37434 .37 935.85 79.31
CR blocks created 62 0 1.55 .13
DBWR checkpoint buffers wri 37992 .38 949.8 80.49
DBWR checkpoints 6 0 .15 .01
DBWR transaction table writ 470 0 11.75 1
DBWR undo block writes 22627 .23 565.68 47.94
SQL*Net roundtrips to/from 4875 .05 121.88 10.33
background checkpoints comp 5 0 .13 .01
background checkpoints star 6 0 .15 .01
background timeouts 547 .01 13.68 1.16
branch node splits 4 0 .1 .01
buffer is not pinned count 4217 .04 105.43 8.93
buffer is pinned count 649 .01 16.23 1.38
bytes received via SQL*Net 1027466 10.27 25686.65 2176.83
bytes sent via SQL*Net to c 5237709 52.35 130942.73 11096.84
calls to get snapshot scn: 1514482 15.14 37862.05 3208.65
calls to kcmgas 303700 3.04 7592.5 643.43
calls to kcmgcs 215 0 5.38 .46
change write time 4419 .04 110.48 9.36
cleanout - number of ktugct 1875 .02 46.88 3.97
cluster key scan block gets 101 0 2.53 .21
cluster key scans 49 0 1.23 .1
commit cleanout failures: b 27 0 .68 .06
commit cleanouts 1305175 13.04 32629.38 2765.2
commit cleanouts successful 1305148 13.04 32628.7 2765.14
commit txn count during cle 3718 .04 92.95 7.88
consistent changes 752 .01 18.8 1.59
consistent gets 1514852 15.14 37871.3 3209.43
consistent gets - examinati 1005941 10.05 25148.53 2131.23
data blocks consistent read 752 .01 18.8 1.59
db block changes 3465329 34.63 86633.23 7341.8
db block gets 3589136 35.87 89728.4 7604.1
deferred (CURRENT) block cl 1068723 10.68 26718.08 2264.24
enqueue releases 805858 8.05 20146.45 1707.33
enqueue requests 805852 8.05 20146.3 1707.31
execute count 1004701 10.04 25117.53 2128.6
free buffer requested 36371 .36 909.28 77.06
hot buffers moved to head o 3801 .04 95.03 8.05
immediate (CURRENT) block c 3894 .04 97.35 8.25
index fast full scans (full 448 0 11.2 .95
index fetch by key 201128 2.01 5028.2 426.12
index scans kdiixs1 501268 5.01 12531.7 1062.01
leaf node splits 1750 .02 43.75 3.71
logons cumulative 2 0 .05 0
messages received 19465 .19 486.63 41.24
messages sent 19465 .19 486.63 41.24
no work - consistent read g 3420 .03 85.5 7.25
opened cursors cumulative 201103 2.01 5027.58 426.07
opened cursors current -3 0 -.08 -.01
parse count (hard) 4 0 .1 .01
parse count (total) 201103 2.01 5027.58 426.07
parse time cpu 2069 .02 51.73 4.38
parse time elapsed 2260 .02 56.5 4.79
physical reads 6600 .07 165 13.98
physical reads direct 75 0 1.88 .16
physical writes 38067 .38 951.68 80.65
physical writes direct 75 0 1.88 .16
physical writes non checkpo 34966 .35 874.15 74.08
prefetched blocks 2 0 .05 0
process last non-idle time 1029203858 10286.18 25730096.45 2180516.65
recursive calls 3703781 37.02 92594.53 7846.99
recursive cpu usage 35210 .35 880.25 74.6
redo blocks written 1112273 11.12 27806.83 2356.51
redo buffer allocation retr 21 0 .53 .04
redo entries 1843462 18.42 46086.55 3905.64
redo log space requests 17 0 .43 .04
redo log space wait time 313 0 7.83 .66
redo size 546896692 5465.85 13672417.3 1158679.43
redo synch time 677 .01 16.93 1.43
redo synch writes 63 0 1.58 .13
redo wastage 4630680 46.28 115767 9810.76
redo write time 64354 .64 1608.85 136.34
redo writer latching time 42 0 1.05 .09
redo writes 19026 .19 475.65 40.31
rollback changes - undo rec 10 0 .25 .02
rollbacks only - consistent 122 0 3.05 .26
rows fetched via callback 1040 .01 26 2.2
session connect time 1029203858 10286.18 25730096.45 2180516.65
session logical reads 5103988 51.01 127599.7 10813.53
session pga memory -263960 -2.64 -6599 -559.24
session pga memory max -788248 -7.88 -19706.2 -1670.02
session uga memory -107904 -1.08 -2697.6 -228.61
session uga memory max 153920 1.54 3848 326.1
shared hash latch upgrades 501328 5.01 12533.2 1062.14
sorts (memory) 1467 .01 36.68 3.11
sorts (rows) 38796 .39 969.9 82.19
switch current to new buffe 347 0 8.68 .74
table fetch by rowid 1738 .02 43.45 3.68
table scan blocks gotten 424 0 10.6 .9
table scan rows gotten 4164 .04 104.1 8.82
table scans (short tables) 451 0 11.28 .96
transaction rollbacks 5 0 .13 .01
user calls 5912 .06 147.8 12.53
user commits 100057 1 2501.43 211.99
user rollbacks 56 0 1.4 .12
workarea executions - optim 1676 .02 41.9 3.55
write clones created in bac 5 0 .13 .01
write clones created in for 745 .01 18.63 1.58
99 rows selected. -
Too much redo log files...
Hi,
I have a very light application in Oracle 9.2.0.7 in Linux-32bits that is generating 400 logfiles a day. I can´t find why those logs are being generated!
The only thing relevant in that application is a big table that serves only for insert command (1000 per hour) for audit reasons. But this table was created with NOLOGGING option.
Redo Size: 4 groups of 40 Mb each.
The insert statement uses a sequence to generate a unique key. Is this sequence causing my big logfile generation?
Thanks,
Paulo.Here is the statspack:
STATSPACK report for
DB Name DB Id Instance Inst Num Release Cluster Host
DB 378381468 DB 1 9.2.0.7.0 NO host
Snap Id Snap Time Sessions Curs/Sess Comment
Begin Snap: 12 28-Jun-07 11:05:11 26 1,198.7
End Snap: 13 28-Jun-07 12:05:24 29 1,077.2
Elapsed: 60.22 (mins)
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 512M Std Block Size: 8K
Shared Pool Size: 512M Log Buffer: 5,120K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
Redo size: 281,252.38 2,073.48
Logical reads: 73,113.76 539.02
Block changes: 3,133.29 23.10
Physical reads: 3.24 0.02
Physical writes: 21.39 0.16
User calls: 26.12 0.19
Parses: 145.64 1.07
Hard parses: 0.81 0.01
Sorts: 138.33 1.02
Logons: 0.69 0.01
Executes: 443.27 3.27
Transactions: 135.64
% Blocks changed per Read: 4.29 Recursive Call %: 98.97
Rollback per transaction %: 0.13 Rows per Sort: 17.26
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.99 Redo NoWait %: 100.00
Buffer Hit %: 100.00 In-memory Sort %: 99.99
Library Hit %: 99.66 Soft Parse %: 99.44
Execute to Parse %: 67.14 Latch Hit %: 99.93
Parse CPU to Parse Elapsd %: 55.03 % Non-Parse CPU: 99.22
Shared Pool Statistics Begin End
Memory Usage %: 91.06 91.23
% SQL with executions>1: 44.54 39.78
% Memory for SQL w/exec>1: 43.09 33.89
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
CPU time 3,577 84.73
log file parallel write 854,726 359 8.51
row cache lock 56,780 104 2.47
process startup 172 91 2.16
SQL*Net message from dblink 5,001 22 .53
Wait Events for DB: DB Instance: DB Snaps: 12 -13
-> s - second
-> cs - centisecond - 100th of a second
-> ms - millisecond - 1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
log file parallel write 854,726 0 359 0 1.7
row cache lock 56,780 0 104 2 0.1
process startup 172 4 91 530 0.0
SQL*Net message from dblink 5,001 0 22 4 0.0
log file sync 3,015 3 19 6 0.0
enqueue 471 1 9 20 0.0
buffer busy waits 20,290 0 8 0 0.0
db file sequential read 3,853 0 6 2 0.0
SQL*Net more data from dblin 88,584 0 5 0 0.2
control file parallel write 1,704 0 5 3 0.0
latch free 1,404 748 4 3 0.0
single-task message 134 0 4 27 0.0
LGWR wait for redo copy 8,230 1 2 0 0.0
log file switch completion 60 0 2 32 0.0
log file sequential read 1,333 0 2 1 0.0
control file sequential read 4,530 0 1 0 0.0
db file scattered read 246 0 0 1 0.0
SQL*Net more data to client 7,292 0 0 0 0.0
SQL*Net break/reset to clien 72 0 0 1 0.0
db file parallel write 4,568 0 0 0 0.0
log file single write 62 0 0 0 0.0
async disk IO 3,410 0 0 0 0.0
SQL*Net message to dblink 5,001 0 0 0 0.0
direct path read (lob) 84 0 0 0 0.0
direct path read 318 0 0 0 0.0
direct path write 312 0 0 0 0.0
buffer deadlock 115 115 0 0 0.0
SQL*Net message from client 86,475 0 27,758 321 0.2
jobq slave wait 4,594 4,532 13,455 2929 0.0
SQL*Net more data from clien 602 0 1 2 0.0
SQL*Net message to client 86,481 0 0 0 0.2
Background Wait Events for DB: DB Instance: DB Snaps: 12 -13
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
log file parallel write 854,744 0 359 0 1.7
control file parallel write 1,704 0 5 3 0.0
LGWR wait for redo copy 8,230 1 2 0 0.0
log file sequential read 1,333 0 2 1 0.0
control file sequential read 1,849 0 1 1 0.0
db file parallel write 4,567 0 0 0 0.0
latch free 74 0 0 0 0.0
rdbms ipc reply 65 0 0 0 0.0
log file single write 62 0 0 0 0.0
async disk IO 3,410 0 0 0 0.0
db file sequential read 1 0 0 8 0.0
buffer busy waits 5 0 0 0 0.0
direct path read 248 0 0 0 0.0
direct path write 248 0 0 0 0.0
rdbms ipc message 868,357 6,776 30,095 35 1.8
pmon timer 1,204 1,204 3,529 2931 0.0
smon timer 154 0 3,514 22816 0.0
Instance Activity Stats for DB: DB Instance: DB Snaps: 12 -13
Statistic Total per Second per Trans
active txn count during cleanout 2,844 0.8 0.0
background checkpoints completed 31 0.0 0.0
background checkpoints started 31 0.0 0.0
background timeouts 7,956 2.2 0.0
branch node splits 15 0.0 0.0
buffer is not pinned count 324,721,116 89,875.8 662.6
buffer is pinned count 308,901,876 85,497.3 630.3
bytes received via SQL*Net from c 8,048,130 2,227.6 16.4
bytes received via SQL*Net from d 181,575,342 50,256.1 370.5
bytes sent via SQL*Net to client 33,964,494 9,400.6 69.3
bytes sent via SQL*Net to dblink 933,170 258.3 1.9
calls to get snapshot scn: kcmgss 9,900,434 2,740.2 20.2
calls to kcmgas 985,222 272.7 2.0
calls to kcmgcs 11,669 3.2 0.0
change write time 9,910 2.7 0.0
cleanout - number of ktugct calls 18,903 5.2 0.0
cleanouts and rollbacks - consist 33 0.0 0.0
cleanouts only - consistent read 932 0.3 0.0
cluster key scan block gets 289,955 80.3 0.6
cluster key scans 101,840 28.2 0.2
commit cleanout failures: block l 0 0.0 0.0
commit cleanout failures: buffer 113 0.0 0.0
commit cleanout failures: callbac 96 0.0 0.0
commit cleanout failures: cannot 3,095 0.9 0.0
commit cleanouts 1,966,376 544.3 4.0
commit cleanouts successfully com 1,963,072 543.3 4.0
commit txn count during cleanout 309,283 85.6 0.6
consistent changes 5,245,452 1,451.8 10.7
consistent gets 242,967,989 67,248.3 495.8
consistent gets - examination 135,768,580 37,577.8 277.0
CPU used by this session 357,659 99.0 0.7
CPU used when call started 344,951 95.5 0.7
CR blocks created 768 0.2 0.0
current blocks converted for CR 0 0.0 0.0
cursor authentications 886 0.3 0.0
data blocks consistent reads - un 1,760 0.5 0.0
db block changes 11,320,580 3,133.3 23.1
db block gets 21,192,200 5,865.5 43.2
DBWR buffers scanned 0 0.0 0.0
DBWR checkpoint buffers written 69,649 19.3 0.1
DBWR checkpoints 31 0.0 0.0
DBWR free buffers found 0 0.0 0.0
DBWR lru scans 0 0.0 0.0
DBWR make free requests 0 0.0 0.0
DBWR revisited being-written buff 0 0.0 0.0
DBWR summed scan depth 0 0.0 0.0
DBWR transaction table writes 2,070 0.6 0.0
DBWR undo block writes 44,323 12.3 0.1
deferred (CURRENT) block cleanout 745,333 206.3 1.5
dirty buffers inspected 1 0.0 0.0
enqueue conversions 8,193 2.3 0.0
enqueue deadlocks 1 0.0 0.0
enqueue releases 2,002,960 554.4 4.1
enqueue requests 2,002,963 554.4 4.1
enqueue timeouts 3 0.0 0.0
enqueue waits 451 0.1 0.0
Instance Activity Stats for DB: DB Instance: DB Snaps: 12 -13
Statistic Total per Second per Trans
exchange deadlocks 115 0.0 0.0
execute count 1,601,528 443.3 3.3
free buffer inspected 30 0.0 0.0
free buffer requested 1,196,628 331.2 2.4
hot buffers moved to head of LRU 26,707 7.4 0.1
immediate (CR) block cleanout app 965 0.3 0.0
immediate (CURRENT) block cleanou 10,817 3.0 0.0
index fast full scans (full) 0 0.0 0.0
index fetch by key 131,028,270 36,265.8 267.4
index scans kdiixs1 17,868,907 4,945.7 36.5
leaf node splits 4,528 1.3 0.0
leaf node 90-10 splits 3,017 0.8 0.0
logons cumulative 2,499 0.7 0.0
messages received 859,631 237.9 1.8
messages sent 859,631 237.9 1.8
no buffer to keep pinned count 21,253 5.9 0.0
no work - consistent read gets 87,667,752 24,264.5 178.9
opened cursors cumulative 528,984 146.4 1.1
OS Involuntary context switches 0 0.0 0.0
OS Page faults 0 0.0 0.0
OS Page reclaims 0 0.0 0.0
OS System time used 0 0.0 0.0
OS User time used 0 0.0 0.0
OS Voluntary context switches 0 0.0 0.0
parse count (failures) 7 0.0 0.0
parse count (hard) 2,928 0.8 0.0
parse count (total) 526,209 145.6 1.1
parse time cpu 2,778 0.8 0.0
parse time elapsed 5,048 1.4 0.0
physical reads 11,690 3.2 0.0
physical reads direct 6,698 1.9 0.0
physical reads direct (lob) 102 0.0 0.0
physical writes 77,270 21.4 0.2
physical writes direct 7,620 2.1 0.0
physical writes direct (lob) 0 0.0 0.0
physical writes non checkpoint 33,360 9.2 0.1
pinned buffers inspected 0 0.0 0.0
prefetched blocks 799 0.2 0.0
prefetched blocks aged out before 0 0.0 0.0
process last non-idle time 3,630 1.0 0.0
recursive calls 9,053,277 2,505.8 18.5
recursive cpu usage 255,973 70.9 0.5
redo blocks written 2,572,625 712.1 5.3
redo buffer allocation retries 50 0.0 0.0
redo entries 3,074,994 851.1 6.3
redo log space requests 60 0.0 0.0
redo log space wait time 193 0.1 0.0
redo ordering marks 0 0.0 0.0
redo size 1,016,164,852 281,252.4 2,073.5
redo synch time 1,956 0.5 0.0
redo synch writes 5,317 1.5 0.0
redo wastage 259,689,040 71,876.3 529.9
redo write time 37,488 10.4 0.1
redo writer latching time 242 0.1 0.0
redo writes 854,744 236.6 1.7
rollback changes - undo records a 1,098 0.3 0.0
Instance Activity Stats for DB: DB Instance: DB Snaps: 12 -13
Statistic Total per Second per Trans
rollbacks only - consistent read 747 0.2 0.0
rows fetched via callback 117,908,375 32,634.5 240.6
session connect time 0 0.0 0.0
session cursor cache count 16 0.0 0.0
session cursor cache hits 484,372 134.1 1.0
session logical reads 264,160,020 73,113.8 539.0
session pga memory 16,473,320 4,559.5 33.6
session pga memory max 16,914,080 4,681.5 34.5
session uga memory 17,216,514,728 4,765,157.7 35,130.3
session uga memory max 1,865,036,296 516,201.6 3,805.6
shared hash latch upgrades - no w 17,251,803 4,774.9 35.2
shared hash latch upgrades - wait 24,671 6.8 0.1
sorts (disk) 32 0.0 0.0
sorts (memory) 499,747 138.3 1.0
sorts (rows) 8,626,333 2,387.6 17.6
SQL*Net roundtrips to/from client 80,069 22.2 0.2
SQL*Net roundtrips to/from dblink 5,001 1.4 0.0
summed dirty queue length 0 0.0 0.0
switch current to new buffer 1 0.0 0.0
table fetch by rowid 238,882,317 66,117.4 487.4
table fetch continued row 4,436,670 1,228.0 9.1
table scan blocks gotten 5,066,302 1,402.2 10.3
table scan rows gotten 134,679,712 37,276.4 274.8
table scans (direct read) 0 0.0 0.0
table scans (long tables) 447 0.1 0.0
table scans (short tables) 152,382 42.2 0.3
transaction rollbacks 530 0.2 0.0
transaction tables consistent rea 0 0.0 0.0
transaction tables consistent rea 0 0.0 0.0
user calls 94,382 26.1 0.2
user commits 489,423 135.5 1.0
user rollbacks 653 0.2 0.0
write clones created in backgroun 11 0.0 0.0
write clones created in foregroun 878 0.2 0.0
Tablespace IO Stats for DB: DB Instance: DB Snaps: 12 -13
->ordered by IOs (Reads + Writes) desc
Tablespace
Av Av Av Av Buffer Av Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
T1_UNDO
31 0 0.0 1.0 46,535 13 344 0.4
T1
31 0 0.0 1.0 13,754 4 3,657 0.4
T2
3,308 1 0.8 1.1 2,973 1 0 0.0
T3
31 0 0.0 1.0 5,710 2 16,240 0.4
T4
555 0 4.0 1.0 600 0 0 0.0
SYSTEM
429 0 3.9 2.5 280 0 49 0.2
TEMP
134 0 0.4 48.1 238 0 0 0.0
T1_16K
31 0 0.0 1.0 31 0 0 0.0
T2_16K
31 0 0.0 1.0 31 0 0 0.0
Buffer Pool Statistics for DB: DB Instance: DB Snaps: 12 -13
-> Standard block size Pools D: default, K: keep, R: recycle
-> Default Pools for other block sizes: 2k, 4k, 8k, 16k, 32k
Free Write Buffer
Number of Cache Buffer Physical Physical Buffer Complete Busy
P Buffers Hit % Gets Reads Writes Waits Waits Waits
D 49,625 100.0 263,975,320 4,909 69,666 0 0 20,290
16k 7,056 100.0 30 0 0 0 0 0
Instance Recovery Stats for DB: DB Instance: DB Snaps: 12 -13
-> B: Begin snapshot, E: End snapshot
Targt Estd Log File Log Ckpt Log Ckpt
MTTR MTTR Recovery Actual Target Size Timeout Interval
(s) (s) Estd IOs Redo Blks Redo Blks Redo Blks Redo Blks Redo Blks
B 0 0 10518 10000 73728 186265 10000
E 0 0 13189 10000 73728 219498 10000
Buffer Pool Advisory for DB: DB Instance: DB End Snap: 13
-> Only rows with estimated physical reads >0 are displayed
-> ordered by Block Size, Buffers For Estimate
Size for Size Buffers for Est Physical Estimated
P Estimate (M) Factr Estimate Read Factor Physical Reads
D 32 .1 3,970 205.60 4,726,309,734
D 64 .2 7,940 111.86 2,571,419,284
D 96 .2 11,910 59.99 1,379,092,849
D 128 .3 15,880 32.24 741,224,090
D 160 .4 19,850 16.05 369,050,333
D 192 .5 23,820 1.28 29,352,221
D 224 .6 27,790 1.05 24,077,507
D 256 .6 31,760 1.03 23,723,389
D 288 .7 35,730 1.02 23,518,434
D 320 .8 39,700 1.01 23,328,106
D 352 .9 43,670 1.01 23,193,257
D 384 1.0 47,640 1.00 23,064,957
D 400 1.0 49,625 1.00 22,987,576
D 416 1.0 51,610 1.00 22,927,325
D 448 1.1 55,580 0.99 22,824,032
D 480 1.2 59,550 0.99 22,713,509
D 512 1.3 63,520 0.99 22,649,147
D 544 1.4 67,490 0.98 22,605,489
D 576 1.4 71,460 0.98 22,525,897
D 608 1.5 75,430 0.97 22,407,418
D 640 1.6 79,400 0.96 22,022,381
16k 16 .1 1,008 1.00 139,218,299
16k 32 .3 2,016 1.00 139,211,699
16k 48 .4 3,024 1.00 139,207,678
16k 64 .6 4,032 1.00 139,202,581
16k 80 .7 5,040 1.00 139,198,339
16k 96 .9 6,048 1.00 139,193,448
16k 112 1.0 7,056 1.00 139,188,446
16k 128 1.1 8,064 1.00 139,183,808
16k 144 1.3 9,072 1.00 139,179,598
16k 160 1.4 10,080 1.00 139,175,656
16k 176 1.6 11,088 1.00 139,170,607
16k 192 1.7 12,096 1.00 139,166,491
16k 208 1.9 13,104 1.00 139,162,487
16k 224 2.0 14,112 1.00 139,158,197
16k 240 2.1 15,120 1.00 139,153,797
16k 256 2.3 16,128 1.00 139,149,365
16k 272 2.4 17,136 1.00 139,144,252
16k 288 2.6 18,144 1.00 139,140,121
16k 304 2.7 19,152 1.00 139,135,435
16k 320 2.9 20,160 1.00 139,130,845
Buffer wait Statistics for DB: DB Instance: DB Snaps: 12 -13
-> ordered by wait time desc, waits desc
Tot Wait Avg
Class Waits Time (s) Time (ms)
data block 19,912 8 0
undo header 343 0 0
segment header 34 0 0
undo block 1 0 0
Enqueue activity for DB: DB Instance: DB Snaps: 12 -13
-> Enqueue stats gathered prior to 9i should not be compared with 9i data
-> ordered by Wait Time desc, Waits desc
Avg Wt Wait
Eq Requests Succ Gets Failed Gets Waits Time (ms) Time (s)
TM 981,781 981,773 0 7 1,365.43 10
TX 983,944 983,906 0 412 .59 0
HW 4,645 4,645 0 32 .09 0
Rollback Segment Stats for DB: DB Instance: DB Snaps: 12 -13
->A high value for "Pct Waits" suggests more rollback segments may be required
->RBS stats may not be accurate between begin and end snaps when using Auto Undo
managment, as RBS may be dynamically created and dropped as needed
Trans Table Pct Undo Bytes
RBS No Gets Waits Written Wraps Shrinks Extends
0 155.0 0.00 0 0 0 0
1 202,561.0 0.00 31,178,710 40 2 3
2 191,044.0 0.00 30,067,156 23 2 6
3 195,891.0 0.00 30,470,548 39 1 3
4 203,928.0 0.00 31,822,638 38 2 5
5 196,386.0 0.00 -4,264,350,168 38 1 3
6 204,125.0 0.00 32,081,200 24 1 7
7 192,169.0 0.00 33,732,012 45 3 6
8 195,819.0 0.00 30,503,550 40 2 2
9 202,905.0 0.00 31,595,438 40 2 4
10 195,796.0 0.00 30,566,652 29 4 9
Rollback Segment Storage for DB: DB Instance: DB Snaps: 12 -13
->Optimal Size should be larger than Avg Active
RBS No Segment Size Avg Active Optimal Size Maximum Size
0 385,024 0 385,024
1 12,705,792 944,176 2,213,732,352
2 11,657,216 1,548,937 2,214,715,392
3 13,754,368 832,465 243,392,512
4 13,754,368 946,902 235,069,440
5 12,705,792 964,352 2,195,374,080
6 20,045,824 1,232,438 2,416,041,984
7 12,705,792 977,490 3,822,182,400
8 10,608,640 875,068 243,392,512
9 11,657,216 878,119 243,392,512
10 18,997,248 1,034,104 2,281,889,792
Undo Segment Summary for DB: DB Instance: DB Snaps: 12 -13
-> Undo segment block stats:
-> uS - unexpired Stolen, uR - unexpired Released, uU - unexpired reUsed
-> eS - expired Stolen, eR - expired Released, eU - expired reUsed
Undo Undo Num Max Qry Max Tx Snapshot Out of uS/uR/uU/
TS# Blocks Trans Len (s) Concurcy Too Old Space eS/eR/eU
1 44,441 ########## 47 2 0 0 0/0/0/0/0/0
Undo Segment Stats for DB: DB Instance: DB Snaps: 12 -13
-> ordered by Time desc
Undo Num Max Qry Max Tx Snap Out of uS/uR/uU/
End Time Blocks Trans Len (s) Concy Too Old Space eS/eR/eU
28-Jun 11:56 7,111 ######## 47 1 0 0 0/0/0/0/0/0
28-Jun 11:46 10,782 ######## 18 2 0 0 0/0/0/0/0/0
28-Jun 11:36 6,170 ######## 42 1 0 0 0/0/0/0/0/0
28-Jun 11:26 4,966 ######## 13 1 0 0 0/0/0/0/0/0
28-Jun 11:16 6,602 ######## 40 1 0 0 0/0/0/0/0/0
28-Jun 11:06 8,810 ######## 10 1 0 0 0/0/0/0/0/0
Latch Activity for DB: DB Instance: DB Snaps: 12 -13
->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for
willing-to-wait latch get requests
->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests
->"Pct Misses" for both should be very close to 0.0
Pct Avg Wait Pct
Get Get Slps Time NoWait NoWait
Latch Requests Miss /Miss (s) Requests Miss
active checkpoint queue 9,585 0.0 0.0 0 0
alert log latch 158 0.0 0 0
archive control 220 0.0 0 0
archive process latch 220 0.5 1.0 0 0
cache buffer handles 264,718 0.0 0.0 0 0
cache buffers chains 416,051,175 0.0 0.0 4 401,018 0.0
cache buffers lru chain 1,285,963 0.0 0.0 0 1,206,550 0.0
channel handle pool latc 4,927 0.0 0 0
channel operations paren 10,788 0.0 0 0
checkpoint queue latch 528,319 0.0 0.0 0 69,506 0.0
child cursor hash table 35,371 0.0 0 0
Consistent RBA 854,833 0.0 0.0 0 0
dml lock allocation 1,963,007 0.9 0.0 0 0
dummy allocation 4,995 0.0 0 0
enqueue hash chains 4,014,593 0.5 0.0 0 0
enqueues 94,666 0.0 0.0 0 0
event group latch 2,340 0.0 0 0
FAL request queue 72 0.0 0 0
FIB s.o chain latch 310 0.0 0 0
FOB s.o list latch 6,769 0.0 0 0
global tx hash mapping 10,388 0.0 0 0
hash table column usage 16 0.0 0 479 0.0
job workq parent latch 0 0 316 0.0
job_queue_processes para 116 0.0 0 0
ktm global data 200 0.0 0 0
lgwr LWN SCN 855,008 0.0 0.0 0 0
library cache 5,836,900 0.4 0.0 0 8,926 0.6
library cache load lock 468 0.0 0 0
library cache pin 3,510,695 0.0 0.0 0 0
library cache pin alloca 1,402,523 0.0 0.0 0 0
list of block allocation 6,115 0.0 0 0
loader state object free 620 0.0 0 0
message pool operations 262 0.0 0 0
messages 2,664,950 0.4 0.0 0 0
mostly latch-free SCN 856,000 0.1 0.0 0 0
multiblock read objects 3,184 0.0 0 0
ncodef allocation latch 57 0.0 0 0
object stats modificatio 8 0.0 0 0
post/wait queue 6,183 0.0 0 3,082 0.0
process allocation 4,677 0.0 0 2,340 0.0
process group creation 4,677 0.0 0 0
redo allocation 4,784,936 0.5 0.0 0 0
redo copy 0 0 3,081,261 0.3
redo writing 2,576,299 0.0 0.2 0 0
row cache enqueue latch 3,017,144 0.0 0.0 0 0
row cache objects 5,049,552 0.8 0.0 0 92 0.0
sequence cache 984,824 0.0 0.1 0 0
session allocation 110,417 0.0 0.0 0 0
session idle bit 205,319 0.0 0 0
session switching 57 0.0 0 0
Latch Activity for DB: DB Instance: DB Snaps: 12 -13
->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for
willing-to-wait latch get requests
->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests
->"Pct Misses" for both should be very close to 0.0
Pct Avg Wait Pct
Get Get Slps Time NoWait NoWait
Latch Requests Miss /Miss (s) Requests Miss
session timer 1,204 0.0 0 0
shared pool 2,409,725 0.1 0.1 0 0
simulator hash latch 7,439,429 0.0 0.0 0 0
simulator lru latch 202 0.0 0 128,961 0.2
sort extent pool 1,053 0.0 0 0
SQL memory manager worka 67 0.0 0 0
temp lob duration state 187 0.0 0 0
transaction allocation 7,290 0.0 0 0
transaction branch alloc 5,668 0.0 0 0
undo global data 3,002,808 0.4 0.0 0 0
user lock 8,642 0.0 0 0
Latch Sleep breakdown for DB: DB Instance: DB Snaps: 12 -13
-> ordered by misses desc
Get Spin &
Latch Name Requests Misses Sleeps Sleeps 1->4
cache buffers chains 416,051,175 197,296 750 196776/298/2
15/7/0
row cache objects 5,049,552 42,368 38 42330/38/0/0
/0
redo allocation 4,784,936 24,766 77 24697/61/8/0
/0
library cache 5,836,900 23,477 276 23207/264/6/
0/0
enqueue hash chains 4,014,593 21,061 26 21035/26/0/0
/0
dml lock allocation 1,963,007 17,887 16 17872/14/1/0
/0
undo global data 3,002,808 12,350 8 12342/8/0/0/
0
messages 2,664,950 10,131 5 10126/5/0/0/
0
shared pool 2,409,725 1,362 189 1175/185/2/0
/0
row cache enqueue latch 3,017,144 470 7 463/7/0/0/0
mostly latch-free SCN 856,000 434 1 433/1/0/0/0
library cache pin 3,510,695 345 4 341/4/0/0/0
sequence cache 984,824 53 4 49/4/0/0/0
library cache pin allocati 1,402,523 35 1 34/1/0/0/0
redo writing 2,576,299 5 1 4/1/0/0/0
archive process latch 220 1 1 0/1/0/0/0
Latch Miss Sources for DB: DB Instance: DB Snaps: 12 -13
-> only latches with sleeps are shown
-> ordered by name, sleeps desc
NoWait Waiter
Latch Name Where Misses Sleeps Sleeps
archive process latch kcrrpa 0 1 0
cache buffers chains kcbgtcr: fast path 0 346 188
cache buffers chains kcbgtcr: kslbegin excl 0 163 239
cache buffers chains kcbrls: kslbegin 0 86 170
cache buffers chains kcbget: pin buffer 0 53 49
cache buffers chains kcbgcur: kslbegin 0 44 20
cache buffers chains kcbnlc 0 38 22
cache buffers chains kcbget: exchange 0 8 16
cache buffers chains kcbchg: kslbegin: call CR 0 3 21
cache buffers chains kcbget: exchange rls 0 3 2
cache buffers chains kcbnew 0 3 0
cache buffers chains kcbbxsv 0 2 0
cache buffers chains kcbchg: kslbegin: bufs not 0 1 23
dml lock allocation ktaiam 0 13 1
dml lock allocation ktaidm 0 3 15
enqueue hash chains ksqgtl3 0 22 2
enqueue hash chains ksqrcl 0 4 24
library cache kglic 0 55 4
library cache kglhdgn: child: 0 42 86
library cache kglobpn: child: 0 26 32
library cache kglpndl: child: after proc 0 14 0
library cache kglpndl: child: before pro 0 13 73
library cache kglpin: child: heap proces 0 12 29
library cache kgllkdl: child: cleanup 0 11 4
library cache kglupc: child 0 4 7
library cache kgldti: 2child 0 2 4
library cache kglpnp: child 0 1 4
library cache pin kglpnal: child: alloc spac 0 3 3
library cache pin kglpndl 0 1 1
library cache pin alloca kglpnal 0 1 0
messages ksaamb: after wakeup 0 3 2
messages ksarcv 0 2 2
mostly latch-free SCN kcslcu3 0 1 1
redo allocation kcrfwr 0 74 8
redo allocation kcrfwi: more space 0 -
Tuning of Redo logs in data warehouses (dwh)
Hi everybody,
I'm looking for some guidance to configure redo logs in data warehouse environments.
Of course we are running in noarchive log mode and use direct path inserts (nologging) whereever possible.
Nevertheless every etl process (one process per day) produces 150 GB of redo logs. That seems quite a lot compared to the overall data volume (1 TB tables + indexes).
Actually im not sure if there is a tuning problem, but because of the large amount of redo I'm interested in examining it.
Here are the facts:
- Oracle 10g, 32 GB RAM
- 6 GB SGA, 20 GB PGA
- 5 log groups each with 1 Gb log file
- 4 MB Log buffer
- every day ca 150 logswitches (with peaks: some logswitches after 10 seconds)
- some sysstat metrics after one etl load:
Select name, to_char(value, '9G999G999G999G999G999G999') from v$sysstat Where name like 'redo %';
"NAME" "TO_CHAR(VALUE,'9G999G999G999G999G999G999')"
"redo synch writes" " 300.636"
"redo synch time" " 61.421"
"redo blocks read for recovery"" 0"
"redo entries" " 327.090.445"
"redo size" " 159.588.263.420"
"redo buffer allocation retries"" 95.901"
"redo wastage" " 212.996.316"
"redo writer latching time" " 1.101"
"redo writes" " 807.594"
"redo blocks written" " 321.102.116"
"redo write time" " 183.010"
"redo log space requests" " 10.903"
"redo log space wait time" " 28.501"
"redo log switch interrupts" " 0"
"redo ordering marks" " 2.253.328"
"redo subscn max counts" " 4.685.754"
So the questions:
Does anybody can see tuning needs? Should the Redo logs be increased or incremented? What about placing redo logs on Solid state disks?
kind regards,
Mirkouser5341252 wrote:
I'm looking for some guidance to configure redo logs in data warehouse environments.
Of course we are running in noarchive log mode and use direct path inserts (nologging) whereever possible.Why "of course" ? What's your recovery strategy if you wreck the database ?
Nevertheless every etl process (one process per day) produces 150 GB of redo logs. That seems quite a lot compared to the overall data volume (1 TB tables + indexes).This may be an indication that you need to do something to reduce index maintenance during data loading
>
Actually im not sure if there is a tuning problem, but because of the large amount of redo I'm interested in examining it.
For a quick check you might be better off running statspack (or AWR) snapshots across the start and end of batch to get an idea of what work goes on and where the most time goes. A better strategy would be to examine specific jobs in detail, though).
"redo synch time" " 61.421"
"redo log space wait time" " 28.501" Rough guideline - if the redo is slowing you down, then you've lost less than 15 minutes across the board to the log writer. Given the number of processes loading and the elapsed time to load, is this significant ?
"redo buffer allocation retries"" 95.901" This figure tells us how OFTEN we couldn't get space in the log buffer - but not how much time we lost as a result. We also need to see your 'log buffer space' wait time.
Does anybody can see tuning needs? Should the Redo logs be increased or incremented? What about placing redo logs on Solid state disks?Based on the information you've given so far, I don't think anyone should be giving you concrete recommendations on what to do; only suggestions on where to look or what to tell us.
Regards
Jonathan Lewis -
Redo log buffer is in cretical position
hi Experts,
please try to solve my query, here in my system redo log buffer shows(alert monitoring) 99<4000 and message is '4000 redo entries per redo log space requests'
so i think i need to increase log_buffer parameter value upto required level ,then i entered in database
splplus / as sysdba
and i try to check my file is in which type (spfile or in pfile) by executing command
" SHOW PARAMETER pfile"
it shows
name--- spfile
type---string
value---/oracle/qty/102_64/dbs/spfileqty.ora
when i Excute 'SHOW PARAMETER spfile' also the same result
now in here i have doubt please clarify me
1) my file is spfile or pfile ?
2) how can i increase my parameter value (alter system set log_buffer = xxx scope=pfile (or) spfile )
3) is that my process correct for that error
please clarify me
thanks & regardsHi,
As per my knowledge, Oracle 10g by default starts with SPFILE and if you are setting the parameter with alter command then yes the scope should be SPFILE. After that when you schedule any DB related activity(backup, update statistics etc.,) it will create pfile from spfile.
Before doing any changes take the backup of the existing files both (pfile and spfile) at os level.
Regards,
Sharath -
Redo Log and Supplemental Logging related doubts
Hi Friends,
I am studying Supplemental logging in detail. Have read lots of articles and oracle documentation about it and redo logs. But couldnot found answers of some doubts..
Please help me clear it.
Scenario: we have one table with primary key. And we execute an update query on that table which is not using the primary key column in any clause..
Question: In this case, does the redo log entry generated for the changes done by update query contain the primary columns values..?
Question: If we have any table with primary key, do we need to enable the supplemental logging on primary columns of that table? If yes, in which circumstances, do we need to enable it?
Question: If we have to configure stream replication on that table(having primary key), why do we actually need to enable its supplemental logging ( I have read the documentation saying that stream requires some more information so.., but actually what information does it need. Again this question is highly related to the first question.)
Also please suggest any good article/site which provide inside details of redo log and supplemental logging, if you know.
Regards,
Dipali..1) Assuming you are not updating the primary key column and supplemental logging is not enabled, Oracle doesn't need to log the primary key column to the redo log, just the ROWID.
2) Is rather hard to answer without being tautological. You need to enable supplemental logging if and only if you have some downstream use for additional columns in the redo logs. Streams, and those technologies built on top of Streams, are the most common reason for enabling supplemental logging.
3) If you execute an update statement like
UPDATE some_table
SET some_column = new_value
WHERE primary_key = some_key_value
AND <<other conditions as well>>and look at an update statement that LogMiner builds from the redo logs in the absence of supplemental logging, it would basically be something like
UPDATE some_table
SET some_column = new_value
WHERE rowid = rowid_of_the_row_you_updatedOracle doesn't need to replay the exact SQL statement you issued, (and thus it doesn't have to write the SQL statement to the redo log, it doesn't have to worry if the UPDATE takes a long time to run (otherwise, it would take as long to apply an archived log as it did to generate the log, which would be disasterous in a recovery situation), etc). It just needs to reconstruct the SQL statement from the information in redo, which is just the ROWID and the column(s) that changed.
If you try to run this statement on a different database (via Streams, for example) the ROWIDs on the destination database are likely totally different (since a ROWID is just a physical address of a row on disk). So adding supplemental logging tells Oracle to log the primary key column to redo and allows LogMiner/ Streams/ etc. to reconstruct the statement using the primary key values for the changed rows, which would be the same on both the source and destination databases.
Justin -
Redo Log Buffer 32.8M, Seems to Big?
I just took over a database (Mainly used for OLTP on 11gR1) and I am looking at the log_buffer parameter it is set to 34412032 (32.8M). Not sure why it is so high.
select
NAME,
VALUE
from
SYS.V_$SYSSTAT
where
NAME in ('redo buffer allocation retries', 'redo log space wait time');
redo buffer allocation retries 185
redo log space wait time 5180(database has been up for 7.5 days)
Any opinions on this? I Normally keep try to stay below 3M and have not really seen it above 10M.Sky13 wrote:
I just took over a database (Mainly used for OLTP on 11gR1) and I am looking at the log_buffer parameter it is set to 34412032 (32.8M). Not sure why it is so high.
In 11g you shouldn't set the log_buffer parameter - let Oracle set the default.
The value is derived from the setting for the CPU count and the transactions parameter, which may be derived from sessions, which may be derived from processes. Moreover, Oracle is going to allocate at least a granule (which may be 4MB, 8MB, 16MB, 64MB or 256MB depending on the size of the SGA, so you are unlikely to save memory by reducing the log buffer size.
Here's a link to a discussion which shows you how to find out what's really behind that figure.
Re: Archived redo log size more less than online redo logs
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: <b><em>Oracle Core</em></b> -
All Redo Log groups are active.
Hi All,
In one of our production database now a days we are seeing that all redo logs become active and then everything just get hang. It happens for 15-20 minutes and after that they come normal. Database size is over 4.5 TB and it's OLTP cum MIS database. As per Unix Team at server and storage level everything is fine so what could be other reason for this?
Database version is 9.2.0.5 and O/S is AIX 5.3 Power System.
select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME
1 1 435847 1,342,177,280 2 YES ACTIVE 1.1782E+13 13-MAR-10
2 1 435848 1,342,177,280 2 YES ACTIVE 1.1782E+13 13-MAR-10
3 1 435850 1,342,177,280 2 NO CURRENT 1.1782E+13 13-MAR-10
4 1 435844 1,342,177,280 2 YES ACTIVE 1.1782E+13 13-MAR-10
5 1 435845 1,342,177,280 2 YES ACTIVE 1.1782E+13 13-MAR-10
6 1 435846 1,342,177,280 2 YES ACTIVE 1.1782E+13 13-MAR-10
7 1 435843 1,342,177,280 2 YES ACTIVE 1.1782E+13 13-MAR-10
8 1 435849 1,342,177,280 2 YES ACTIVE 1.1782E+13 13-MAR-10
9 1 435842 1,342,177,280 2 YES INACTIVE 1.1782E+13 13-MAR-10
9 rows selected.
VMSTAT output:
vmstat 2 10
kthr memory page faults cpu
r b avm fre re pi po fr sr cy in sy cs us sy id wa
35 13 23262385 48530 0 0 0 0 0 0 27910 531516 111964 54 7 12 26
30 12 23270696 26769 0 0 0 4277 19644 0 28759 604423 106619 53 7 14 25
26 12 23269357 25691 0 0 0 8899 38750 0 28620 552550 103736 55 7 15 23
32 14 23263410 31111 0 0 0 10778 47248 0 29722 690889 112674 53 7 16 24
27 17 23268835 25011 0 0 0 10267 51727 0 30321 779933 116936 58 8 13 21
30 20 23274592 25181 0 0 0 13569 59742 0 28290 731707 109167 59 7 13 22
33 10 23280476 30823 0 0 0 15259 66334 0 28942 774600 107692 65 7 8 20
36 13 23280770 26040 0 0 0 7199 33048 0 29351 687375 98487 63 7 10 20
35 16 23277780 27758 0 0 0 7250 33003 0 30699 622788 97172 65 6 10 19
31 13 23277431 25107 0 0 0 8521 37996 0 29746 596172 89831 63 6 11 20
select event, count(*) from v$session_wait group by event order by 2;
EVENT COUNT(*)
PL/SQL lock timer 2
SQL*Net more data from client 2
jobq slave wait 3
direct path read 5
rdbms ipc message 8
enqueue 11
log file sync 11
db file parallel write 12
latch free 12
pipe get 22
PX Deq: Execution Msg 27
buffer busy waits 33
db file scattered read 39
db file sequential read 169
SQL*Net message from client 2120Hi,
Complete output would be so long so just putting tail of that.
RECID STAMP
NAME
DEST_ID THREAD# SEQUENCE# RESETLOGS_CHANGE# RESETLOGS_TIME FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME BLOCKS BLOCK_SIZE CREATOR REGISTR STA ARC APP DEL S COMPLETION_TIME
DIC DIC END BACKUP_COUNT ARCHIVAL_THREAD# ACTIVATION#
711558 713531894
(DESCRIPTION=(ADDRESS_LIST = (ADDRESS=(PROTOCOL=tcp)(HOST=ilerpstdby)(PORT=1540)))(CONNECT_DATA=(SID=ILPROD)(SERVER=DEDICATED)))
2 1 435868 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH YES YES YES NO A 13-MAR-10
NO NO NO 0 1 2142322718
711559 713531942
/arch/ora/prod/PRODDB_1_00135869.arc
1 1 435869 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH NO YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718
711560 713531994
(DESCRIPTION=(ADDRESS_LIST = (ADDRESS=(PROTOCOL=tcp)(HOST=ilerpstdby)(PORT=1540)))(CONNECT_DATA=(SID=ILPROD)(SERVER=DEDICATED)))
2 1 435869 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH YES YES YES NO A 13-MAR-10
NO NO NO 0 1 2142322718
711561 713532090
/arch/ora/prod/PRODDB_1_00135870.arc
1 1 435870 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH NO YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718
711562 713532149
(DESCRIPTION=(ADDRESS_LIST = (ADDRESS=(PROTOCOL=tcp)(HOST=ilerpstdby)(PORT=1540)))(CONNECT_DATA=(SID=ILPROD)(SERVER=DEDICATED)))
2 1 435870 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH YES YES YES NO A 13-MAR-10
NO NO NO 0 1 2142322718
711563 713532276
/arch/ora/prod/PRODDB_1_00135871.arc
1 1 435871 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH NO YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718
711564 713532322
(DESCRIPTION=(ADDRESS_LIST = (ADDRESS=(PROTOCOL=tcp)(HOST=ilerpstdby)(PORT=1540)))(CONNECT_DATA=(SID=ILPROD)(SERVER=DEDICATED)))
2 1 435871 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH YES YES YES NO A 13-MAR-10
NO NO NO 0 1 2142322718
711565 713532449
/arch/ora/prod/PRODDB_1_00135872.arc
1 1 435872 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH NO YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718
711566 713532506
(DESCRIPTION=(ADDRESS_LIST = (ADDRESS=(PROTOCOL=tcp)(HOST=ilerpstdby)(PORT=1540)))(CONNECT_DATA=(SID=ILPROD)(SERVER=DEDICATED)))
2 1 435872 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH YES YES YES NO A 13-MAR-10
NO NO NO 0 1 2142322718
711567 713532607
/arch/ora/prod/PRODDB_1_00135873.arc
1 1 435873 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH NO YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718
711568 713532662
(DESCRIPTION=(ADDRESS_LIST = (ADDRESS=(PROTOCOL=tcp)(HOST=ilerpstdby)(PORT=1540)))(CONNECT_DATA=(SID=ILPROD)(SERVER=DEDICATED)))
2 1 435873 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH YES YES YES NO A 13-MAR-10
NO NO NO 0 1 2142322718
711569 713532773
/arch/ora/prod/PRODDB_1_00135874.arc
1 1 435874 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH NO YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718
711570 713532832
(DESCRIPTION=(ADDRESS_LIST = (ADDRESS=(PROTOCOL=tcp)(HOST=ilerpstdby)(PORT=1540)))(CONNECT_DATA=(SID=ILPROD)(SERVER=DEDICATED)))
2 1 435874 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH YES YES YES NO A 13-MAR-10
NO NO NO 0 1 2142322718
711571 713532933
/arch/ora/prod/PRODDB_1_00135875.arc
1 1 435875 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH NO YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718
711572 713532980
(DESCRIPTION=(ADDRESS_LIST = (ADDRESS=(PROTOCOL=tcp)(HOST=ilerpstdby)(PORT=1540)))(CONNECT_DATA=(SID=ILPROD)(SERVER=DEDICATED)))
2 1 435875 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH YES YES YES NO A 13-MAR-10
NO NO NO 0 1 2142322718
711573 713533101
/arch/ora/prod/PRODDB_1_00135876.arc
1 1 435876 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH NO YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718
711574 713533178
(DESCRIPTION=(ADDRESS_LIST = (ADDRESS=(PROTOCOL=tcp)(HOST=ilerpstdby)(PORT=1540)))(CONNECT_DATA=(SID=ILPROD)(SERVER=DEDICATED)))
2 1 435876 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH YES YES YES NO A 13-MAR-10
NO NO NO 0 1 2142322718
711575 713533258
/arch/ora/prod/PRODDB_1_00135877.arc
1 1 435877 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH NO YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718
711576 713533323
(DESCRIPTION=(ADDRESS_LIST = (ADDRESS=(PROTOCOL=tcp)(HOST=ilerpstdby)(PORT=1540)))(CONNECT_DATA=(SID=ILPROD)(SERVER=DEDICATED)))
2 1 435877 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH YES YES YES NO A 13-MAR-10
NO NO NO 0 1 2142322718
711577 713533366
/arch/ora/prod/PRODDB_1_00135878.arc
1 1 435878 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH NO YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718
711578 713533419
(DESCRIPTION=(ADDRESS_LIST = (ADDRESS=(PROTOCOL=tcp)(HOST=ilerpstdby)(PORT=1540)))(CONNECT_DATA=(SID=ILPROD)(SERVER=DEDICATED)))
2 1 435878 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH YES YES YES NO A 13-MAR-10
NO NO NO 0 1 2142322718
711579 713533497
/arch/ora/prod/PRODDB_1_00135879.arc
1 1 435879 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH NO YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718
711580 713533537
(DESCRIPTION=(ADDRESS_LIST = (ADDRESS=(PROTOCOL=tcp)(HOST=ilerpstdby)(PORT=1540)))(CONNECT_DATA=(SID=ILPROD)(SERVER=DEDICATED)))
2 1 435879 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH YES YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718
711581 713533678
/arch/ora/prod/PRODDB_1_00135880.arc
1 1 435880 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH NO YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718
711582 713533737
(DESCRIPTION=(ADDRESS_LIST = (ADDRESS=(PROTOCOL=tcp)(HOST=ilerpstdby)(PORT=1540)))(CONNECT_DATA=(SID=ILPROD)(SERVER=DEDICATED)))
2 1 435880 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH YES YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718
711583 713533841
/arch/ora/prod/PRODDB_1_00135881.arc
1 1 435881 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH NO YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718
711584 713533919
(DESCRIPTION=(ADDRESS_LIST = (ADDRESS=(PROTOCOL=tcp)(HOST=ilerpstdby)(PORT=1540)))(CONNECT_DATA=(SID=ILPROD)(SERVER=DEDICATED)))
2 1 435881 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH YES YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718
711585 713533983
/arch/ora/prod/PRODDB_1_00135882.arc
1 1 435882 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH NO YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718
711586 713534050
(DESCRIPTION=(ADDRESS_LIST = (ADDRESS=(PROTOCOL=tcp)(HOST=ilerpstdby)(PORT=1540)))(CONNECT_DATA=(SID=ILPROD)(SERVER=DEDICATED)))
2 1 435882 8.6960E+12 24-SEP-03 1.1782E+13 13-MAR-10 1.1782E+13 13-MAR-10 2621438 512 ARCH ARCH YES YES NO NO A 13-MAR-10
NO NO NO 0 1 2142322718 -
Hi,
DB: 10.2.0.4
OS: UNIX/Windows
I have some doubts in archive log generation.
*1)* Once current redo log is filed , LGWR will move to next redo log which is available with status INACTIVE , and current one will become ACTIVE.If more archive logs are generating , based on business , ACTIVE will become INACTIVE after sometime and can use for CURRENT redo log.
If no archive logs are generated , my redo log is not coming out from status ACTIVE to INACTIVE .Even i waited for 5 minutes , but i had the same status.
What will be the time to make ACTIVE to INACTIVE?. What causing to make this happen ?.
Normally , when checkpoint is happened DBWR will write the CURRENT log data to data files , right?.In ACTIVE state , has archive log generated?. Many times i seen archive log is generated even it is in ACTIVE state.
*2)* My Archive logs size (25MB) is not equal to the redo log size. Normally , when we switch the logs or any rman backup , logs will be switched automatically and how much redo is filled , same will be generated with size.
But, in my case , more archive logs are generating and many have the different size out of generated and no manual switching or rman script are running during this period.
Any idea on this?.
Thanks,
Sunandsunand wrote:
Hi,
DB: 10.2.0.4
OS: UNIX/Windows
I have some doubts in archive log generation.
*1)* Once current redo log is filed , LGWR will move to next redo log which is available with status INACTIVE , and current one will become ACTIVE.If more archive logs are generating , based on business , ACTIVE will become INACTIVE after sometime and can use for CURRENT redo log.
If no archive logs are generated , my redo log is not coming out from status ACTIVE to INACTIVE .Even i waited for 5 minutes , but i had the same status.
What will be the time to make ACTIVE to INACTIVE?. What causing to make this happen ?.
Normally , when checkpoint is happened DBWR will write the CURRENT log data to data files , right?.In ACTIVE state , has archive log generated?. Many times i seen archive log is generated even it is in ACTIVE state.
That is wrong.DBWR process write dirty blocks from database buffer cache to datafiles but not "CURRENT log data to data files".So if your current online log group is full then ARCH process will try archiving this group to available destination and without archiving there will not happen LOG SWITCH.After archiving log switch will happen and LOG SEQUENCE NUMBER will increase then you will get new current log group.IF old group status is ACTIVE it means this group still need instance recovery.SO when you execute ALTER SYSTEM CHECKPOINT in this case status of this group will INACTIVE.
*2)* My Archive logs size (25MB) is not equal to the redo log size. Normally , when we switch the logs or any rman backup , logs will be switched automatically and how much redo is filled , same will be generated with size.
But, in my case , more archive logs are generating and many have the different size out of generated and no manual switching or rman script are running during this period.
Any idea on this?.
As you know archivelogs is a copy of online redologs,but there can be several reasons and result these size can be different.For example manual log switch or if you set ARCHIVE_LAG_TARGET != 0.Finally archive logs contains information for media recover,but online redo logs contain instance and media recovery it means these size can be different. -
Private strand flush not complete how to find optimal size of redo log file
hi,
i am using oracle 10.2.0 on unix system and getting Private strand flush not complete in the alert log file. i know this is due to check point is not completed.
I need to increase the size of redo log files or add new group to the database. i have log file switch (checkpoint incomplete) in the top 5 wait event.
i can't change any parameter of database. i have three redo log group and log files are of 250MB size. i want to know the suitable size to avoid problem.
select * from v$instance_recovery;
RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS TARGET_REDO_BLKS LOG_FILE_SIZE_REDO_BLKS LOG_CHKPT_TIMEOUT_REDO_BLKS LOG_CHKPT_INTERVAL_REDO_BLKS FAST_START_IO_TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR CKPT_BLOCK_WRITES OPTIMAL_LOGFILE_SIZE ESTD_CLUSTER_AVAILABLE_TIME WRITES_MTTR WRITES_LOGFILE_SIZE WRITES_LOG_CHECKPOINT_SETTINGS WRITES_OTHER_SETTINGS WRITES_AUTOTUNE WRITES_FULL_THREAD_CKPT
625 9286 9999 921600 9999 0 9 112166207 0 0 219270206 0 3331591 5707793please suggest me or tell me the way how to find out suitable size to avoid problem.
thanks
umeshHow often should a database archive its logs
Re: Redo log size increase and performance
Please read the above thread and great replies by HJR sir. I think if you wish to get concept knowledge, you should add in your notes.
"If the FAST_START_MTTR_TARGET parameter is set to limit the instance recovery time, Oracle automatically tries to checkpoint as frequently as necessary. Under this condition, the size of the log files should be large enough to avoid additional checkpointing due to under sized log files. The optimal size can be obtained by querying the OPTIMAL_LOGFILE_SIZE column from the V$INSTANCE_RECOVERY view. You can also obtain sizing advice on the Redo Log Groups page of Oracle Enterprise Manager Database Control."
Source:http://download-west.oracle.com/docs/cd/B13789_01/server.101/b10752/build_db.htm#19559
Pl also see ML Doc 274264.1 (REDO LOGS SIZING ADVISORY) on tips to calculate the optimal size for redo logs in 10g databases
Source:Re: Redo Log Size in R12
HTH
Girish Sharma
Maybe you are looking for
-
I recently bought Photoshop Elements 12 and the system is telling me that the Redemption Code is no longer active. How do I get a new Code number that will allow met to access the software?
-
After doing a simple purchase and sale transaction, it seems that my REVENUE GL account remains unreconciled. Can someone help me figure out how to get it reconciled without doing an Adjustment? i am now playing around with the SAP business one 2007A
-
How to register a stolen computer mac book pro
how to register a stolen computer mac book pro
-
Moving Mail Message Preview Pane to Right of Screen Like in Entourage
Hello, Would anyone be able to tell me if I can move my Mail Message Preview Pane to the right side of the screen like I can do in Entourage? I prefer the message preview screen on the right side instead of at the bottom as is the default in mail. Th
-
Hello I have dropped user ANONYMOUS long before. Now trying to setup Apex 4.2. I don't have backup. Could any one tell me how to restore ANONYMOUS? My database version is 11g . Thanks