Redo log generation
Hi,
I have oracle 9i on HP-UX, I want to know how many redo getting generated every hour for the past one month or so, is there any script that I can use to find this?
Thanks
Hi,
You can use this script which gives hour by hour log generation and its total for a month
SQL> L
1 select
2 to_char(first_time,'DD-MM-YY') day,
3 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'00',1,0)),'999') "00",
4 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'01',1,0)),'999') "01",
5 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'02',1,0)),'999') "02",
6 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'03',1,0)),'999') "03",
7 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'04',1,0)),'999') "04",
8 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'05',1,0)),'999') "05",
9 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'06',1,0)),'999') "06",
10 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'07',1,0)),'999') "07",
11 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'08',1,0)),'999') "08",
12 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'09',1,0)),'999') "09",
13 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'10',1,0)),'999') "10",
14 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'11',1,0)),'999') "11",
15 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'12',1,0)),'999') "12",
16 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'13',1,0)),'999') "13",
17 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'14',1,0)),'999') "14",
18 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'15',1,0)),'999') "15",
19 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'16',1,0)),'999') "16",
20 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'17',1,0)),'999') "17",
21 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'18',1,0)),'999') "18",
22 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'19',1,0)),'999') "19",
23 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'20',1,0)),'999') "20",
24 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'21',1,0)),'999') "21",
25 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'22',1,0)),'999') "22",
26 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'23',1,0)),'999') "23",
27 COUNT(*) TOT
28 from v$log_history
29 group by to_char(first_time,'DD-MM-YY')
30 order by day
31*
SQL> @log_hour
DAY 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 TOT
01-07-10 29 19 10 8 8 13 12 19 24 20 10 16 10 10 33 24 23 26 27 32 25 13 8 11 430
02-07-10 9 8 8 8 8 8 10 8 15 8 10 8 8 9 44 30 14 8 25 11 8 12 9 11 297
03-07-10 10 9 8 8 8 8 9 13 14 18 14 22 16 14 10 8 9 10 9 12 10 11 9 11 270
04-07-10 10 8 8 9 8 8 8 9 13 9 8 17 10 8 10 13 14 8 9 11 9 10 8 11 236
05-07-10 10 8 9 8 8 8 9 8 16 14 11 9 10 8 9 10 8 19 13 16 8 10 9 11 249
06-07-10 10 8 9 8 8 8 9 12 13 15 9 8 10 12 13 11 10 9 10 11 13 9 8 11 244
07-07-10 10 11 8 8 8 8 9 8 15 8 19 10 19 14 12 10 21 9 8 12 9 9 14 17 276
08-07-10 13 9 8 8 8 8 9 14 13 11 8 8 13 9 8 21 8 8 13 9 8 9 8 8 239
09-07-10 10 8 8 8 9 8 10 12 15 9 8 14 8 9 19 9 8 8 16 8 9 8 8 9 238
10-07-10 9 9 8 8 8 8 9 14 14 10 8 8 9 9 13 8 8 8 8 9 8 9 8 8 218
11-07-10 10 8 9 8 8 8 9 11 14 8 8 8 8 9 8 8 9 8 10 8 8 8 8 8 209
12-07-10 10 9 8 8 8 8 9 12 14 11 14 13 8 13 13 9 8 13 10 8 10 8 8 8 240
13-07-10 9 12 8 8 8 8 8 14 16 17 11 9 12 17 12 11 9 9 8 15 9 12 11 8 261
14-07-10 10 12 8 8 8 8 9 12 14 10 8 8 8 8 9 9 8 8 9 9 9 31 52 40 315
15-07-10 16 8 9 8 8 8 12 10 17 9 13 16 9 11 8 15 8 10 15 12 8 12 8 8 258
16-07-10 10 9 8 8 8 8 9 11 15 11 14 12 20 8 9 9 9 8 8 12 10 8 8 8 240
17-07-10 10 8 8 8 8 8 8 12 16 10 15 8 9 8 9 8 8 8 9 8 8 9 8 8 219
18-07-10 11 10 8 8 8 8 8 8 10 9 10 8 9 12 16 10 9 8 8 8 8 8 10 8 220
19-07-10 10 9 8 8 8 8 9 4 15 9 8 9 8 8 9 11 9 8 17 8 21 8 8 8 228
20-07-10 9 9 8 8 8 8 12 9 15 16 11 8 9 8 10 12 8 8 9 11 8 9 8 9 230
21-07-10 19 9 8 8 9 8 8 8 9 9 13 8 8 8 9 11 8 14 24 12 37 40 35 8 330
22-07-10 10 8 12 10 8 8 8 11 17 9 8 9 8 9 9 8 14 16 31 11 39 53 40 9 365
23-07-10 10 15 18 8 9 8 9 8 13 9 8 16 9 10 8 14 11 10 9 8 9 9 8 14 250
24-07-10 10 9 8 8 8 8 8 12 14 9 8 8 10 9 9 9 8 11 12 8 8 8 8 8 218
25-07-10 10 8 9 8 8 8 9 8 14 9 8 8 8 9 8 9 8 10 8 9 9 8 8 8 209
26-07-10 10 9 8 8 8 8 9 9 13 10 8 14 8 8 10 19 24 10 27 37 36 23 8 9 333
27-07-10 9 9 8 8 8 8 8 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 64
30-06-10 0 1 49 11 9 8 15 8 8 15 17 25 16 27 28 9 13 9 12 14 12 28 40 43 417
28 rows selected.thanks,
baskar.l
Similar Messages
-
How to reduce excessive redo log generation in Oracle 10G
Hi All,
Please let me know is there any way to reduce excessive redo log generation in Oracle DB 10.2.0.3
previously per day there is only 15 Archive log files are generating but now a days it is increased to 40 to 45
below is the size of redo log file members:
L.BYTES/1024/1024 MEMBER
200 /u05/applprod/prdnlog/redolog1a.dbf
200 /u06/applprod/prdnlog/redolog1b.dbf
200 /u05/applprod/prdnlog/redolog2a.dbf
200 /u06/applprod/prdnlog/redolog2b.dbf
200 /u05/applprod/prdnlog/redolog3a.dbf
200 /u06/applprod/prdnlog/redolog3b.dbf
here is the some content of alert message for your reference how frequent log switch is occuring:
Beginning log switch checkpoint up to RBA [0x441f.2.10], SCN: 4871839752
Thread 1 advanced to log sequence 17439
Current log# 3 seq# 17439 mem# 0: /u05/applprod/prdnlog/redolog3a.dbf
Current log# 3 seq# 17439 mem# 1: /u06/applprod/prdnlog/redolog3b.dbf
Tue Jul 13 14:46:17 2010
Completed checkpoint up to RBA [0x441f.2.10], SCN: 4871839752
Tue Jul 13 14:46:38 2010
Beginning log switch checkpoint up to RBA [0x4420.2.10], SCN: 4871846489
Thread 1 advanced to log sequence 17440
Current log# 1 seq# 17440 mem# 0: /u05/applprod/prdnlog/redolog1a.dbf
Current log# 1 seq# 17440 mem# 1: /u06/applprod/prdnlog/redolog1b.dbf
Tue Jul 13 14:46:52 2010
Completed checkpoint up to RBA [0x4420.2.10], SCN: 4871846489
Tue Jul 13 14:53:33 2010
Beginning log switch checkpoint up to RBA [0x4421.2.10], SCN: 4871897354
Thread 1 advanced to log sequence 17441
Current log# 2 seq# 17441 mem# 0: /u05/applprod/prdnlog/redolog2a.dbf
Current log# 2 seq# 17441 mem# 1: /u06/applprod/prdnlog/redolog2b.dbf
Tue Jul 13 14:53:37 2010
Completed checkpoint up to RBA [0x4421.2.10], SCN: 4871897354
Tue Jul 13 14:55:37 2010
Incremental checkpoint up to RBA [0x4421.4b45c.0], current log tail at RBA [0x4421.4b5c5.0]
Tue Jul 13 15:15:37 2010
Incremental checkpoint up to RBA [0x4421.4d0c1.0], current log tail at RBA [0x4421.4d377.0]
Tue Jul 13 15:35:38 2010
Incremental checkpoint up to RBA [0x4421.545e2.0], current log tail at RBA [0x4421.54ad9.0]
Tue Jul 13 15:55:39 2010
Incremental checkpoint up to RBA [0x4421.55eda.0], current log tail at RBA [0x4421.56aa5.0]
Tue Jul 13 16:15:41 2010
Incremental checkpoint up to RBA [0x4421.58bc6.0], current log tail at RBA [0x4421.596de.0]
Tue Jul 13 16:35:41 2010
Incremental checkpoint up to RBA [0x4421.5a7ae.0], current log tail at RBA [0x4421.5aae2.0]
Tue Jul 13 16:42:28 2010
Beginning log switch checkpoint up to RBA [0x4422.2.10], SCN: 4872672366
Thread 1 advanced to log sequence 17442
Current log# 3 seq# 17442 mem# 0: /u05/applprod/prdnlog/redolog3a.dbf
Current log# 3 seq# 17442 mem# 1: /u06/applprod/prdnlog/redolog3b.dbf
Thanks in advancehi,
Use the below script to find out at what hour the generation of archives are more and in the hour check for eg. if MV's are running...or any programs where delete * from table is going on..
L
1 select
2 to_char(first_time,'DD-MM-YY') day,
3 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'00',1,0)),'999') "00",
4 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'01',1,0)),'999') "01",
5 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'02',1,0)),'999') "02",
6 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'03',1,0)),'999') "03",
7 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'04',1,0)),'999') "04",
8 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'05',1,0)),'999') "05",
9 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'06',1,0)),'999') "06",
10 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'07',1,0)),'999') "07",
11 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'08',1,0)),'999') "08",
12 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'09',1,0)),'999') "09",
13 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'10',1,0)),'999') "10",
14 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'11',1,0)),'999') "11",
15 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'12',1,0)),'999') "12",
16 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'13',1,0)),'999') "13",
17 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'14',1,0)),'999') "14",
18 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'15',1,0)),'999') "15",
19 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'16',1,0)),'999') "16",
20 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'17',1,0)),'999') "17",
21 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'18',1,0)),'999') "18",
22 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'19',1,0)),'999') "19",
23 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'20',1,0)),'999') "20",
24 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'21',1,0)),'999') "21",
25 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'22',1,0)),'999') "22",
26 to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'23',1,0)),'999') "23",
27 COUNT(*) TOT
28 from v$log_history
29 group by to_char(first_time,'DD-MM-YY')
30 order by daythanks,
baskar.l -
Supressing Redo Log Generation
Hi,
I have a PL/SQL script that uses FORALL function with SAVE EXCEPTIONS clause to bulk insert/update a table.
How can I supress redo log generation in my script?
I have placed the database in NOARCHIVELOG mode, does this supress redo log generation?Read these chapters:
[url http://download.oracle.com/docs/cd/E11882_01/server.112/e16508/startup.htm#g12154]Oracle Database Instance
[url http://download.oracle.com/docs/cd/E11882_01/server.112/e16508/physical.htm#CNCPT11302]Overview of the Online Redo Log
Redo is needed to redo transactions. Archiving of the redo is needed to redo transactions that go beyond the online redo. Archivelog mode means to keep the redo beyond the time it is immediately used. If your instance or disk crashes, you need to recover the transactions that were in process. There are reasons to use noarchivelog mode, but if you do, you have to be able to recreate what gets lost in a crash. That's why most normal production OLTP is done in archivelog mode, the data is important enough to need to come back if the instance or computer goes away. Other types of production may not need it, but it needs to be explicitly justified why running in noarchivelog mode is done, as well as how to recover if things go south.
Since archiving redo requires reading the redo and writing it elsewhere, heavy batch loads may benefit from noarchivelog mode. So it might be ok to suppress archiving, but you must have redo. Sometimes it can be justified to do large loads in noarchivelog mode, then switch to archivelog mode, but you must take backups before and after. Since the backups will use the same order of magnitude I/O and cpu as archivelog mode, only a time-window limitation can make it make sense, and you can't have production access either. So it usually makes more sense just to have the hardware to stay archivelog.
Demo, test, archive and development databases are usually somebodies production, too. They all have their own restoration and recovery requirements. -
Redo Log Generation Rate is more as compaired to Single Instacne
Hi Experts,
i need views regarding the experience that i m facing in rac environment. actually we have two node rac 10gr2 running on AIX 6.1
on application side we have a process of 4 hrs and during this process we observed average 110 Gb of logs. but if we run same process on application and single instance DB is being used at back end, then it generates only 40Gb of log. now my question is why same process have different redo log generation values against rac db and single instacne.Amiabu,
Your question calls for crystal balls, as you have provided way too few details.
Also you didn't use Logminer to find out what is going on. This would have been a sensible approach, even before posting a question which can be paraphrased as 'It doesn't work as expected, why?'.
Two general observations:
if your code doesn't scale, using RAC will make things worse.
Oracle 10g is a heavily instrumented product, assuming you use AWR or ADDM or statspack.
The Cache Fusion feature of RAC can easily result in extra wait events, which in turn are being tracked (INSERTed that is) in the AWR or statspack repository.
Only you can answer the question what was going on by using Logminer.
Sybrand Bakker
Senior Oracle DBA
Edited by: sybrand_b on 16-jun-2011 14:33 -
Hi all
I want ask some questions about redo log generation in RAC.
1. Does Oracle confirms that each committed transaction, from begin_transaction to commit, redo and undo information resides in redo log of one node? Which means, would it possible that Oracle put begin transaction in redo log of node A, and put commit in redo log of another node B?Reup this thread :)
Another questions:
What about RAC broadcast performs? I mean is it true that when node A commits a transaction T, then it broadcast this information to all other nodes, would Oracle write this information about T to node B's online redo log? for example, in redo log of Node B contains a redo record including opcode=5.4 and T's transaction id and Node A's thread number.
But during my analyze, Oracle 10.2.0.1.0 RAC, (NFS share), both dump file of redo log and binary redo log don't contains that redo record.
So I wonder what Oracle does?
Black Thought -
Hi,
I am running Oracle 11g on Red Hat with a data block size of 8K
I have question on the efficiency of redo logs
I have an application that is extracting data from one DB and updating a second DB based on this data (not a copy). I have the option of doing it as a single mass up date inserts such as the one below. My question is whether this is more efficient (purely in terms of redo log generation) then having discrete single row inserts. The reason for my question is that the current ETL process design is to drop the table and do a mass re-insert and there have been some concerns raised about the impact on redo log generation. I am of the belief that it will be efficient as there will only be one set of logs per block impacted.
Picking your brains and gaining from our knowledge is much appreciated.
Cheers,
Daryl
INSERT INTO TMP_DIM_EXCH_RT
(EXCH_WH_KEY,
EXCH_NAT_KEY,
EXCH_DATE, EXCH_RATE,
FROM_CURCY_CD,
TO_CURCY_CD,
EXCH_EFF_DATE,
EXCH_EFF_END_DATE,
EXCH_LAST_UPDATED_DATE)
VALUES
(1, 1, '28-AUG-2008', 109.49, 'USD', 'JPY', '28-AUG-2008', '28-AUG-2008', '28-AUG-2008'),
(2, 1, '28-AUG-2008', .54, 'USD', 'GBP', '28-AUG-2008', '28-AUG-2008', '28-AUG-2008'),
(3, 1, '28-AUG-2008', 1.05, 'USD', 'CAD', '28-AUG-2008', '28-AUG-2008', '28-AUG-2008'),
(4, 1, '28-AUG-2008', .68, 'USD', 'EUR', '28-AUG-2008', '28-AUG-2008', '28-AUG-2008'),
(5, 1, '28-AUG-2008', 1.16, 'USD', 'AUD', '28-AUG-2008', '28-AUG-2008', '28-AUG-2008'),
(6, 1, '28-AUG-2008', 7.81, 'USD', 'HKD', '28-AUG-2008', '28-AUG-2008', '28-AUG-2008');darylo wrote:
I have an application that is extracting data from one DB and updating a second DB based on this data (not a copy). I have the option of doing it as a single mass up date inserts such as the one below. My question is whether this is more efficient (purely in terms of redo log generation) then having discrete single row inserts. Single mass insert is much more efficient in terms of redo usage, and almost everything else.
{message:id=4337747}
Run1 - Single insert, Run2 - multiple inserts for same data.
Name Run1 Run2 Diff
STAT...Heap Segment Array Inse 554 13 -541
STAT...free buffer requested 222 909 687
STAT...redo subscn max counts 221 990 769
STAT...redo ordering marks 44 871 827
STAT...calls to kcmgas 46 873 827
STAT...free buffer inspected 133 982 849
LATCH.object queue header oper 625 2,624 1,999
LATCH.simulator hash latch 223 6,005 5,782
STAT...redo entries 1,258 100,643 99,385
STAT...HSC Heap Segment Block 555 100,014 99,459
STAT...session cursor cache hi 5 100,010 100,005
STAT...opened cursors cumulati 7 100,014 100,007
STAT...execute count 7 100,014 100,007
STAT...session logical reads 2,162 102,988 100,826
STAT...db block gets 1,853 102,780 100,927
STAT...db block gets from cach 1,853 102,780 100,927
STAT...recursive calls 33 101,092 101,059
STAT...db block changes 1,873 201,552 199,679
LATCH.cache buffers chains 7,176 507,892 500,716
STAT...undo change vector size 240,500 6,802,736 6,562,236
STAT...redo size 1,566,136 24,504,020 22,937,884 -
High redo, log.xml and alert log generation with streams
Hi,
We have a setup where streams and messaging gateway is implemented on Oracle 11.1.0.7 to replicated the changes.
Until recently there was no issue with the setup but for last few days there is an excessive amount of redo and log.xml and alert log generation, which takes up about 50gb for archive log and 20 gb for the rest of the files.
For now we have disabled the streams.
Please suggest the possible reasons for this issue.
Regards,
AnkitObviously, as no one here has access to the two files with error messages, log.xml and alert log, the resolution starts with looking into those files
and you should have posted this question only after doing this.
Now no help is possible.
Sybrand Bakker
Senior Oracle DBA -
Why do we need standby redo log on Primary database.
Hi Gurus,
I was going through the document in OBE,
http://www.oracle.com/technology/obe/11gr1_db/ha/dataguard/physstby/physstdby.htm
I have two queries:
1) I noticed the statement -
"Configure the primary database to receive redo data, by adding the standby logfiles to the primary. "
Why do we have to create standby redo log on a primary database?
2) There is another statement --
"It is highly recommended that you have one more standby redo log group than you have online redo log groups as the primary database. The files must be the same size or larger than the primary database’s online redo logs. "
Why do we need one additional standby redo log group than in Primary database.
Could anyone please explain to me in simple words.
Thanks
Cherrish VaidiyanHi,
1. Standby redo logs are used only when the database_role is standby, it is recommended to be added in primary also so that they can be used on role reversal, however during normal working standby redo logs will not be used at all on primary.
2. In case of 3 online redo log groups, it is recommended to use 4 standby redo log group this is in case if log switching is happening frequently on primary and all 3 standby redo logs are still not completely archived on the standby and 4th can be used here as there will be some delay on standby due to network or slowness of arch on standby.
Use of the standby redo log groups depends on the redo generation rate, you can see only 2 standby redo logs are getting used while you have 4 standby redo log groups, when the redo generation rate is less.
So it is recommended to have one more standby redo log group when redo generation rate is high and all of the existing standby redo log group are getting used.
Regards
Anudeep -
Oracle 10g R2 Database Redo Log Files
I had 3 redo log files, each of size 50 MB. i added 3 more redo log files, each of size 250 MB.
Database is running in archive mode, files are generating with different sizes like 44 MB and 240 MB, i need to know is this harm for database or not?
to make all archive redo log files generation of equal size what should i do?
Please guideWaheed,
When the redo log switch willbe happening,oracle would be asking archiver to log that into the archive file.So in case you have any parameters set to make the switch happen at certain time,depending on the activity of teh database,the archive file size may vary.There is no harm wit the different sizes of the files.What matters is the transaction informaiton contained in them not their size.
to make all archive redo log files generation of equal size what should i do?
As mentioned by Syed, you can make the switch happen at a defined interval which will not ensure but still will be a step to make the archive files of the same size.But I shall say you should bother more about making sure that the files are available rather than their size.
Aman.... -
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. -
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.... -
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 -
Hi,
Database Version: Oracle 11.1.0.6
Platform: Enterprise Linux 5
Can someone please tell me the troubleshooting steps_ in a situation where there is heavy inflow of archive log generation i mean, say around 3 files of around 50MB every minute and eating away the space on disk.
1) How to find out what activity is causing such heavy archive log generation? I can run the below query to find out the currently running sql queries with status;
select a.username, b.sql_text,a.status from v$session a inner join v$sqlarea b on a.sql_id=b.sql_id;
But is there any other query or a better way to find out current db activity in this situation.
Tried using DBMS_LGMNR Log Miner but failed because (i) utl_file_dir is not set in init param file (So, mining the archive log file on production is presently ruled out as I cannot take an outage)
(ii) alter database add supplemental log data (all) columns query takes for ever because of the locks. (So, cannot mine the generated archive log file on another machine due to DBID mismatch.)
2) How to deal with this situation? I read here in OTN discussion board that increasing the number of redo log groups or redo log members will help to manage this situation when there is lot of DML activity going on application side....But I didn't understand how it is going to help in controlling the rigorous archive logs generation
Edited by: user10313587 on Feb 11, 2011 8:43 AM
Edited by: user10313587 on Feb 11, 2011 8:44 AMHi,
Other than logminer, which will tell you exactly what the redo is by definition, you can run something like the following:
select value/((sysdate-logon_time) * 1440) redo_per_minute,s.sid,serial#,logon_time,value
from v$statname sn,
v$sesstat ss,
v$session s
where s.sid = ss.sid
and sn.statistic# = ss.statistic#
and name = 'redo size'
and value>0Then trace the "high" sessions above and it should jump out at you. If not, then run logmnr with something like...
set serveroutput on size unlimited
begin
dbms_logmnr.add_logfile(logfilename => '&log_file_name');
dbms_logmnr.start_logmnr(options => dbms_logmnr.dict_from_online_catalog + dbms_logmnr.no_rowid_in_stmt);
FOR cur IN (SELECT *
FROM v$logmnr_contents) loop
dbms_output.put_line(cur.sql_redo);
end loop;
end;
/Note you don't need utl_file_dir for log miner if you use the online catalog.
HTH,
Steve -
Archive log generation in every 7 minute interval
One of the HP Unix 11.11 hosts two databases uiivc and uiivc1. It is found that there is heavy archive log generation in every 7 minute in both databases. Redo log size is 100mb and configured with 2 members each on three groups for these databases.Version of the database is 9.2.0.8. Can anyone help me to find out how to monitor the redo log file contents which is filling up more frequently making more archived redo to generate (filling up the mount point)?
Current settings are
fast_start_mttr_target integer 300
log_buffer integer 5242880
Regards
ManojYou can try to find the sessions which are generating lots of redo logs, check metalink doc id: 167492.1
1) Query V$SESS_IO. This view contains the column BLOCK_CHANGES which indicates
how much blocks have been changed by the session. High values indicate a
session generating lots of redo.
The query you can use is:
SQL> SELECT s.sid, s.serial#, s.username, s.program,
2 i.block_changes
3 FROM v$session s, v$sess_io i
4 WHERE s.sid = i.sid
5 ORDER BY 5 desc, 1, 2, 3, 4;
Run the query multiple times and examine the delta between each occurrence
of BLOCK_CHANGES. Large deltas indicate high redo generation by the session.
2) Query V$TRANSACTION. This view contains information about the amount of
undo blocks and undo records accessed by the transaction (as found in the
USED_UBLK and USED_UREC columns).
The query you can use is:
SQL> SELECT s.sid, s.serial#, s.username, s.program,
2 t.used_ublk, t.used_urec
3 FROM v$session s, v$transaction t
4 WHERE s.taddr = t.addr
5 ORDER BY 5 desc, 6 desc, 1, 2, 3, 4;
Run the query multiple times and examine the delta between each occurrence
of USED_UBLK and USED_UREC. Large deltas indicate high redo generation by
the session. -
Desactivate writting to Redo Logs
Hi
i want my database to not writting Redo Logs.I have searched on the net and i found articles that speak about archiving and turning archive off (ALTER DATABASE noarchivelog)
but i have a very heavy activity .i don't want to decrease performance by writting those redo logs.
Thanks in advanceuser12019948 wrote:
Hi
i want my database to not writting Redo Logs.I have searched on the net and i found articles that speak about archiving and turning archive off (ALTER DATABASE noarchivelog)
but i have a very heavy activity .i don't want to decrease performance by writting those redo logs.
Thanks in advanceDatabase perdormance doesn't come down by writing to the redo log files and moreover, writing to the redo log files would be very important for recovery. Now, you can't disable the redo generation completely. What you can do is to go for a nologging clause which would generate a minimal redo .
HTH
Aman....
Maybe you are looking for
-
Permissions? Time Machine Migration MB to MBA
I'm struggling here, perhaps from my own ignorance, so all I'm looking for is a pointer on how to get myself out of this frustrating time wasting... New MacBook Air. Want to migrate content from MacBook. Thought I did enough online research to know h
-
Video imported all on one clip..
Video did not import into separate clips. Its all on one clip. How can I get imovie to make separate clips for editing? Original video is gone. Its on imovie6.
-
Integrating vendors master data
Hi Is there a way to display/do a report for two Vendors with different names with the same address, account number, vat no. etc. Example Vendor A was taken over by a new company and their name changed. They created a new Vendor AB and now they want
-
Reference Data of Customer from R3 to CRM
Hi Group, we downloaded ECC customers to CRM 5.0. now we have a situation where we want to see reference data of Customer: 1) Prev.aact no, 2) Buying Group in CRM. these feilds are maintained in ECC in "Company Code Data" of Customer Master un
-
How do you remove something ( Eg. an app) off of iCloud?
How do you remove something ( Eg. an app) off of iCloud?