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
Similar Messages
-
Will Analyze create too many redo logs ??
DB : 10gR2
Hello Folks,
Is analyze process creates too many redo log files ?? Is their any other valid option other than no log ?I guess that's also going to create too many log switches as it's part of DDLHUH?
REDO log switches result from DML.
If you are obsessed with LOG switches, then you need to use LOGMINER to observe the the relative per centage of changed data is from DBMS_STATS
when compared to normal DML activity.
I seriously doubt that DBMS_STATS has any significant impact to redo log switches. -
REDO scanning goes in infinite loop and Too much ARCHIVE LOG
After we restart DATABASE, capture process REDO scanning goes in infinite loop and Too much ARCHIVE LOG being generated.
No idea whats going on.... otherwise basic streams functionality working fine.What's your DB version
-
What is the difference between undo tablespace and online redo log files.
what is the difference between undo tablespace and online redo log files. I am confused
as per my knowledge undo tablespace is used to store the undo information when a table is being updated so that, just incase we need to rollback a transaction we know what was present in the table earlier.
when a transaction fails the SMON performs the rollback of the data.
This undo data is stored in the undo tablespace and read consistency if any is enforced.
is my understanding till here correct?
Now, can this undo data/before image not be stored in the redo log buffer and online redolog files?
can redo-log files not store this information?
in fact, is it that when undo tablespaces exist in a database, the undo data/before image is stored in both the undo tablespace and also the redo log files?
kindly clarify my doubt.
thank you.This question has been asked many times before. The answer is always the same.
Yes, redo contains the before image of data (and the after-image). Therefore, it **COULD** be used to roll back a transaction.
BUT... Redo is written sequentially. Using it to rollback your transaction would involve reading through all the redo written by maybe thousands of other people. It would be painfully slow.
Your transaction is, however, directly linked to just the UNDO that it generates (which is JUST the before image of the data). So, your undo is your undo and doesn't share space with anyone else's undo. Therefore, using it to roll back YOUR transaction is fast.
The fact that undo is only the before image of the data also makes it faster than wading through a sea of before and AFTER images as you'd find in redo. About twice as fast, in fact, since there's half the data. Roughly.
Redo also gets written and flushed to disk whenever there's a commit, 3 seconds are up or too much (1MB, actually) redo gets generated between flushes caused by other factors. Your redo gets flushed when those things happen, even if you haven't actually committed your transaction. And redo logs recycle themselves, meaning that your redo -even if your transaction hasn't been committed yet- can be over-written by later transactions. Try rolling back when that's happened, if redo was the source of your rollback data!
Undo, however, cannot be over-written if the transaction has not been committed. Ever. If you don't commit for three years, there will be three years' undo stored in your database (assuming you had the space, of course!).
I could go on, but that will do. Redo is there fore RECOVERY, after catastrophe. Undo is there for read-consistency (and the occasional change of mind). Two different functions. Two different mechanisms. Each one highly tuned to doing what it does, why it does it, most efficiently and effectively. -
How to disable write to redo log file in oracle7.3.4
in oracle 8, alter table no logged in redo log file like: alter table tablename nologging;
how to do this in oracle 7.3.4?
thanks.user652965 wrote:
Thanks very much for your help guys. I appreciate it. unfortunately none of these commands worked for me. I kept getting error on clearing logs that redo log is needed to perform recovery so it can't be cleared. So I ended up restoring from earlier snapshot of my db volume. Database is now open.
Thanks again for your input.And now, as a follow-up, at a minimum you should make sure that all redo log groups have at least 3 members. Then, if you lose a single redo log file, all you have to do is shutdown the db and copy one of the good members (of the same group as the lost member) over the lost member.
And as an additional follow-up, if you value your data you will run in archivelog mode and take regular backups of the database and archivelogs. If you fail to do this you are saying that your data is not worth saving. -
How to recover from one corrupted redo log file in NOARCHIVE mode?
Oracle 10.2.1.
The redo log file was corrupted and Oracle can't work.
When I use STARTUP mount, I got no error msg.
SQL> startup mount
ORACLE instance started.
Total System Global Area 1652555776 bytes
Fixed Size 1251680 bytes
Variable Size 301991584 bytes
Database Buffers 1342177280 bytes
Redo Buffers 7135232 bytes
Database mounted.
But I have some applications which are depended on Oracle can't be started.
So, I tried STARTUP open. But I got error msg.
SQL> startup open
ORACLE instance started.
Total System Global Area 1652555776 bytes
Fixed Size 1251680 bytes
Variable Size 301991584 bytes
Database Buffers 1342177280 bytes
Redo Buffers 7135232 bytes
Database mounted.
ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 497019 change 42069302 time 11/07/2007
23:43:09
ORA-00312: online log 4 thread 1:
'G:\ORACLE\PRODUCT\10.2.0\ORADATA\NMDATA\REDO04.LOG'
So, how can I restore and recover my database?
If use RMAN, how to do that?
Any help will be appreciated.
Thanks.Hi, Yingkuan,
Thanks for the helps.
Actually, I have 10 redo log files exists. All of them are here.
I tried your suggestion:
alter database clear unarchived logfile group 4;
The error msg I got is the same as before:
SQL> alter database clear unarchived logfile group 4;
alter database clear unarchived logfile group 4
ERROR at line 1:
ORA-01624: log 4 needed for crash recovery of instance nmdata (thread 1)
ORA-00312: online log 4 thread 1:
'G:\ORACLE\PRODUCT\10.2.0\ORADATA\NMDATA\REDO04.LOG'
Compared to losing all the data, it is OK for me lose some of them.
I have more than 1 TB data stored and 99.9% of them are raster images.
The loading of these data were the headache. If I can save them, I can bear the lost.
I want to grasp the last straw.
But I don't know how set the parameter: allowresetlogs_corruption
I got the error msg:
SQL> set allowresetlogs_corruption=true;
SP2-0735: unknown SET option beginning "_allow_res..."
I have run the command:
Recover database until cancel
Alter database open resetlogs
The error msg I got is the following:
SQL> recover database until cancel
ORA-00279: change 41902930 generated at 11/05/2007 22:01:48 needed for thread 1
ORA-00289: suggestion :
D:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\NMDATA\ARCHIVELOG\2007_11_09\O1_MF_
1_1274_%U_.ARC
ORA-00280: change 41902930 for thread 1 is in sequence #1274
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\NMDATA\SYSTEM01.DBF'
ORA-01112: media recovery not started
SQL>
From the log file, I got the following:
ALTER DATABASE RECOVER database until cancel
Fri Nov 09 00:12:48 2007
Media Recovery Start
parallel recovery started with 2 processes
ORA-279 signalled during: ALTER DATABASE RECOVER database until cancel ...
Fri Nov 09 00:13:20 2007
ALTER DATABASE RECOVER CANCEL
Fri Nov 09 00:13:21 2007
ORA-1547 signalled during: ALTER DATABASE RECOVER CANCEL ...
Fri Nov 09 00:13:21 2007
ALTER DATABASE RECOVER CANCEL
ORA-1112 signalled during: ALTER DATABASE RECOVER CANCEL ...
Thank you very much. and I am looking forward to your followup input. -
Dear All,
In am using oracle 10.2.0.4.0 in RHEL 4.
In my current set we had two node RAC (tims1,tims2) db_name (tims).
One of the node has failed(hard disk),Failed node information has been remove from OCR(all the cluster component like...ons,vip,listener,instance).
My Question IS:After Removing All the Cluster Component does it remove redo log files associate with the failed instance.
Redo logfile Before Node Delete:
SQL> select member from v$logfile;
MEMBER
/database/tims/redo02.log
/database/tims/redo01.log
/database/tims/redo03.log
/database/tims/redo04.log
Redo Logfile After Node Delete
SQL> select member from v$logfile;
MEMBER
/database/tims/redo02.log
/database/tims/redo01.log
/database/tims/redo03.log
/database/tims/redo04.log
It means redo logfile has not been removed.
Please help me what are the redo thread i will have to remove.
SQL> select group#,sequence#,thread# from v$log;
GROUP# SEQUENCE# THREAD#
1 28868 1
2 28867 1
3 29327 2
4 29328 2
Thanks &Regards
Monoj Dasmonoj wrote:
Dear All
SQL> select group#,sequence#,thread# from v$log;
GROUP# SEQUENCE# THREAD#
1 28868 1
2 28867 1
3 29327 2
4 29328 2
According to my above query, thread# for group 1,2 is showing as 1 but the thread has been remove from cluster is there any use of those redo log.
Thanks and Regards
Monoj Das
Please leave your theories aside and read the replies given in the thread. The logs are going to stay as they are (should be) on the shared storage. Why you are hard-bent to remove these log files anyways? Are you not willing to add the other instance? RAC db with just one instance is really not of much use.
Aman.... -
Need to understand when redo log files content is wrote to datafiles
Hi all
I have a question about the time when redo log files are wrote to the datafiles
supposing that the database is in NOARCHIVELOG mode, and all redo log files are filled, the official oracle database documentation says that: *a filled redo log file is available
after the changes recorded in it have been written to the datafiles* witch mean that we just need to have all the redo log files filled to "*commit*" changes to the database
Thanks for help
Edited by: rachid on Sep 26, 2012 5:05 PMrachid wrote:
the official oracle database documentation says that: a filled redo log file is available after the changes recorded in it have been written to the datafiles It helps if you include a URL to the page where you found this quote (if you were using the online html manuals).
The wording is poor and should be modified to something like:
<blockquote>
+"a filled online redo log file is available for re-use after all the data blocks that have been changed by change vectors recorded in the log file have been written to the data files"+
</blockquote>
Remember if a data block that is NOT an undo block has been changed by a transaction, then an UNDO block has been changed at the same time, and both change vectors will be in the redo log file. The redo log file cannot, therefore, be re-used until the data block and the associated UNDO block have been written to disc. The change to the data block can thus be rolled back (uncommitted changes can be written to data files) because the UNDO is also available on disc if needed.
If you find the manuals too fragmented to follow you may find that my book, Oracle Core, offers a narrative description that is easier to comprehend.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: <b><em>Oracle Core</em></b> -
Sizing the redo log files using optimal_logfile_size view.
Regards
I have a specific question regarding logfile size. I have deployed a test database and i was exploring certain aspects with regards to selecting optimal size of redo logs for performance tuning using optimal_logfile_size view from v$instance_recovery. My main goal is to reduce the redo bytes required for instance recovery. Currently i have not been able to optimize the redo log file size. Here are the steps i followed:-
In order to use the advisory from v$instance_recovery i had to set fast_start_mttr_target parameter which is by default not set so i did these steps:-
1)SQL> sho parameter fast_start_mttr_target;
NAME TYPE VALUE
fast_start_mttr_target integer 0
2) Setting the fast_start_mttr_target requires nullifying following deferred parameters :-
SQL> show parameter log_checkpoint;
NAME TYPE VALUE
log_checkpoint_interval integer 0
log_checkpoint_timeout integer 1800
log_checkpoints_to_alert boolean FALSE
SQL> select ISSES_MODIFIABLE,ISSYS_MODIFIABLE,ISINSTANCE_MODIFIABLE,ISMODIFIED from v$parameter where name like'log_checkpoint_timeout';
ISSES_MODIFIABL ISSYS_MODIFIABLE ISINSTANCE_MODI ISMODIFIED
FALSE IMMEDIATE TRUE FALSE
SQL> alter system set log_checkpoint_timeout=0 scope=both;
System altered.
SQL> show parameter log_checkpoint_timeout;
NAME TYPE VALUE
log_checkpoint_timeout integer 0
3) Now setting fast_start_mttr_target
SQL> select ISSES_MODIFIABLE,ISSYS_MODIFIABLE,ISINSTANCE_MODIFIABLE,ISMODIFIED from v$parameter where name like'fast_start_mttr_target';
ISSES_MODIFIABL ISSYS_MODIFIABLE ISINSTANCE_MODI ISMODIFIED
FALSE IMMEDIATE TRUE FALSE
Setting the fast_mttr_target to 1200 = 20 minutes of checkpoint switching according to Oracle recommendation
Querying the v$instance_recovery view
4) SQL> select ACTUAL_REDO_BLKS,TARGET_REDO_BLKS,TARGET_MTTR,ESTIMATED_MTTR, OPTIMAL_LOGFILE_SIZE,CKPT_BLOCK_WRITES from v$instance_recovery;
ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE CKPT_BLOCK_WRITES
276 165888 *93* 59 361 16040
Here Target Mttr was 93 so i set the fast_mttr_target to 120
SQL> alter system set fast_start_mttr_target=120 scope=both;
System altered.
Now the logfile size suggested by v$instance_recovery is 290 Mb
SQL> select ACTUAL_REDO_BLKS,TARGET_REDO_BLKS,TARGET_MTTR,ESTIMATED_MTTR, OPTIMAL_LOGFILE_SIZE,CKPT_BLOCK_WRITES from v$instance_recovery;
ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE CKPT_BLOCK_WRITES
59 165888 93 59 290 16080
After altering the logfile size to 290 as show below by v$log view :-
SQL> select GROUP#,THREAD#,SEQUENCE#,BYTES from v$log;
GROUP# THREAD# SEQUENCE# BYTES
1 1 24 304087040
2 1 0 304087040
3 1 0 304087040
4 1 0 304087040
5 ) After altering the size i have observed the anomaly as redo log blocks to be applied for recovery has increased from *59 to 696* also now v$instance_recovery view is now suggesting the logfile size of *276 mb*. Have i misunderstood something
SQL> select ACTUAL_REDO_BLKS,TARGET_REDO_BLKS,TARGET_MTTR,ESTIMATED_MTTR, OPTIMAL_LOGFILE_SIZE,CKPT_BLOCK_WRITES from v$instance_recovery;
ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE CKPT_BLOCK_WRITES
*696* 646947 120 59 *276* 18474
Please clarify the above output i am unable to optimize the logfile size and have not been able to achieve the goal of reducing the redo log blocks to be applied for recovery, any help is appreciated in this regard.sunny_123 wrote:
Sir oracle says that fast_start_mttr target can be set to 3600 = 1hour. As suggested by following oracle document
http://docs.oracle.com/cd/B10500_01/server.920/a96533/instreco.htm
I set mine value to 1200 = 20 minutes. Later i adjusted it to 120=2 minutes as Target_mttr suggested it to be around 100 (if fast_mttr_target value is too high or too low effective value is contained in target_mttr of v$instance_recovery)Just to add, you are reading the documentation of 9.2 and a lot has changed since then. For example, in 9.2 the parameter FSMTTR was introduced and explicitly required to be set and monitored by the DBA for teh additional checkpoint writes which might get caused by it. Since 10g onwards this parameter has been made automatically maintained by Oracle. Also it's been long that 9i has been desupported followed by 10g so it's better that you start reading the latest documentation of 11g and if not that, at least of 10.2.
Aman.... -
How to recover from corrupt redo log file in non-archived 10g db
Hello Friends,
I don't know much about recovering databases. I have a 10.2.0.2 database with corrupt redo file and I am getting following error on startup. (db is non archived and no backup) Thanks very much for any help.
Database mounted.
ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 6464 change 9979452011066 time 06/27/2009
15:46:47
ORA-00312: online log 1 thread 1: '/dbfiles/data_files/log3.dbf'
====
SQL> select Group#,members,status from v$log;
GROUP# MEMBERS STATUS
1 1 CURRENT
3 1 UNUSED
2 1 INACTIVE
==
I have tried this so far but no luck
I have tried following commands but no help.
SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 3;
Database altered.
SQL> alter database open resetlogs;
alter database open resetlogs
ERROR at line 1:
ORA-01139: RESETLOGS option only valid after an incomplete database recovery
SQL> alter database open;
alter database open
ERROR at line 1:
ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 6464 change 9979452011066 time 06/27/2009
15:46:47
ORA-00312: online log 1 thread 1: '/dbfiles/data_files/log3.dbf'user652965 wrote:
Thanks very much for your help guys. I appreciate it. unfortunately none of these commands worked for me. I kept getting error on clearing logs that redo log is needed to perform recovery so it can't be cleared. So I ended up restoring from earlier snapshot of my db volume. Database is now open.
Thanks again for your input.And now, as a follow-up, at a minimum you should make sure that all redo log groups have at least 3 members. Then, if you lose a single redo log file, all you have to do is shutdown the db and copy one of the good members (of the same group as the lost member) over the lost member.
And as an additional follow-up, if you value your data you will run in archivelog mode and take regular backups of the database and archivelogs. If you fail to do this you are saying that your data is not worth saving. -
How do i find the location of the redo log files in the database.
you can do it too if you use Oracle Enterprise Maneger.
Joel P�rez -
Redo Log Files - more than 12 per hour
Hello @all,
I have a problem with my redo log files. I get more than 12 switches per Hour. I have 3 Files with 5oM size. I increased the sitz to 15o M, but
I still have 12 switches per hour.
Do anyone know, what I did wrong?
Database:
Oracle 9i
Thanks
Martinuser9528362 wrote:
Hello @all,
yes I know, that 3 switches per hour are perfekt, but I had increased the Size from 5o M to 15oM already and the amount from switches, are not reduced.
So there must be something else, that causes the log switches.Martin,
As I said somewhere above too, 150meg is a tiny size if you are managing a production db. I have already mentioned that make your log file size to at least 500meg and than check. As for the high redo activity, only you can confirm that whether this has been started from now only or was happening before too? In anycase, for an active oltp, 500 to 1gb of redo log file size should be okay.
For the extra redo generation, you have been given link for mining log files using logminer. Try using it to see what is causing extra redo.
HTH
Aman.... -
Multiplexing Redo Log Files question
If you are running RAC on ASM on a RAID system, is this required? We are using an HP autoraid which mirrors at the block level and in the documentation about Multiplexing Redo Log Files it says that you do it to protect against media failure. The autoraid that we are using gives us multiple levels of redundancy against media failure so I was wondering if Multiplexing would be adding more overhead than is needed. Thanks for your input.
ASM is quite compex and I'm not going to outline all the advantages or reasons for ASM, but under ASM you can drop and add devices to maintain your capacity needs online without loosing data, which you cannot do using RAID, which requires a re-initialize, for example, regardless of redundancy. Please see the documentation. ASM, like pretty much everything Oracle will add complexity and you will have to check your requirements. ASM is however pretty much the standard. If you use external RAID, make sure your storage is not using RAID 5 or 0. Regarding logical errors, you could for example overwrite or delete a file by mistake, in which case file redundancy does not protect you. If you are looking for reasons or ways not to use ASM, I'm sure you will find them, but what's the point?
-
T is frequently switching the redo log files within 5min approx..
i am facing frequent switching of redo logs within 5minutes
can you please tell how to resolve
thanks for helpHi,
I found this:
More frequent log switches may result in decreased performance. If your redo logs switches so faster Oracle will stop processing until the checkpoint completes successfully. Generally it is recommended to size your redo log file in a way that Oracle performs a log switch every 15 to 30 minutes.
A recommended approach is to
Query V$LOG view to determine the current size of the redo log members.
Record the number of log switches per hour.
Increase the log file size so that Oracle switches at the recommended rate of one switch per 15 to 30 minutes.
You can also check messages in the alert log in order to determine how fast Oracle is filling and switching logs. Suppose if your database redo log file size is set to 1MB. It means that Oracle switches the logs every 1 minute. So you will need to increase the size of redo log file to 30MB so that Oracle switches per 30 minutes.
It is also recommended to ensure that your online redo log files do not switch too often during high activity time. Instead in the period of high activity it should switch less while it should switch enough times during the time of low processing workloads. Many database administrators create PL/SQL programs to ensure that the logs switch every 15 to 30 minutes during times when activity is low.
Oracle ARCHIVE_LAG_TARGET can also be used to force a log switch after the specified amount of time elapses. The basic purpose of ARCHIVE_LAG_TARGET parameter is to control the amount of data that is lost and effectively increasing the availability of the standby database but many database administrators set ARCHIVE_LAG_TARGET parameter to make sure that the logs switch at regular intervals during lower activity time periods.
You should also keep in mind that how the size of the online redo log files will affect the instance recovery. Remember the lesser the checkpoints are taken; the longer will be the instance recovery duration. You can decrease the instance recovery time by appropriately setting the LOG_CHECKPOINT_TIMEOUT, LOG_CHECKPOINT_INTERVAL and FAST_START_MTTR_TARGET parameters. -
WARNING - Last redo log file switch interval was 6 minutes. Next interval p
Hello!
I just started monitoring my Oracle via ConSol Nagios script.
Now it show`s a Warning because:
WARNING - Last redo log file switch interval was 6 minutes. Next interval presumably >2 minutes. Second incident in a row.
As I do not know much about Oracle I do not understand that message.
a) What does it mean ?
b) Is it really critical ?
Thanks!>
I just started monitoring my Oracle via ConSol Nagios script.
Now it show`s a Warning because:
WARNING - Last redo log file switch interval was 6 minutes. Next interval presumably >2 minutes. Second incident in a row.
As I do not know much about Oracle I do not understand that message.
a) What does it mean ?
b) Is it really critical ?
>
First of all: This is not an Oracle Error message. Instead, you have a somewhat arbitrarily threshold set in your non-Oracle monitoring tool. If this happens only once in a while - ignore it or modify the threshold.
Generally, frequent fast logswitches can be the cause of performance problems.
If you have Oracle Enterprise Manager in place and Diagnostic Pack licensed, it would give you a much more qualified statement about your Database performance. Also a recommendation to increase the Logfile size in case.
If you look for a procedure to increase the size of your logfiles:
http://uhesse.wordpress.com/2010/01/20/how-to-change-the-size-of-online-redologs/
Kind regards
Uwe Hesse
http://uhesse.wordpress.com
Maybe you are looking for
-
Derivation of fund center based on purchasing group
Hi, It is required to determine the fund center based on purchasing group (during PR creation). I have gone through one thread which suggests inclusion of the field EKGRP into FMDERIVE, then to COBL. However I was trying to check whether it can b
-
Define Flat Rate for Travel Cost based on location (Maximum points awarded)
Hello, SPRO>Financial Accounting>Travel Management>Travel Expenses>Trip Reimbursement Amount>Reimbursement Amount Travel Costs>Define Flat rates for Travel Costs, in this path we can enter the reimbursement amount for trip country/ trip region. I cre
-
My iphone does not show up as a device on itunes
-
Pages re-numbers paragraphs in a document!
Hi all -- thanks in advance for any insight you may have. I received an email on my iPad with a Word attachment. I opened the attached in Mail, and when going through the document with someone on the phone, we realized that the paragraphs were not nu
-
Is it possible to create new material type on my own?
hi gurus, Is it possible to create material type on my own?. i want to create with out referring existing one.... regards Dinesh.a