SMON generating lot of redo

DB Version 10.2.0.4
OS HP-UX
Hello we are facing problem with wait event Redo Log space Wait
when i checked for the session which are generating lot of Redo i found SMON at the top..
Just couldn't understand what SMON would be doing so it is generating highest amount of Redo
Please Advise ..
Regards
Vinayak

I would use DBMS_LOGMNR package to see what kind of activity is performed. For details about this package see Oracle® Database PL/SQL Packages and Types Reference 10g Release 2 (10.2).
Kind regards,
Joze

Similar Messages

What would cause a lot of redo or logswitches in an instance with no users?

Hello all,
I've got a database instance that is set up as a 3 node RAC cluster. I don't think this is RAC related, but the database issues is causing RAC issues.
The instance has been set up, and later will be used to temporarily hold data while another box is being rebuilt. This instance has not had anything imported into it...there are no users connecting to it.
However, it seems to be generating a LOT of redo and archive log traffic. So much so..that overran the db_recovery_file_dest_size of 8GB.
I'd not been monitoring this instance like I said before....nothing is in it, and noone should be connecting to it...but it filled up the 8G..and then, started writing tons of logs to /u01/app/oracle/diag/rdbms/instance1/INSTANCE1_node3/trace/ saying it was full...and eventually filling up the /u01 filesystem..causing things to crash.
I fixed all this by deleting the alert logs to make room. I then did an RMAN job to move the archive logs to tape..and it came back up.
However, just an hour later...I see over 15% of the FRA is filled up again?!?!?
Any ideas on where to start to troubleshoot this? I don't know what is causing this thing to generate redo at all.....
Thanks in advance,
cayenne

I've got a database instance that is set up as a 3 node RAC clusterThat would mean 1 database with 3 instances.
Are all 3 instances writing a high volume of redo ? Or is it only one of the three instances ?
When you check for scheduled jobs in DBA_JOBS and DBA_SCHEDULER_JOBS, check all 3 instances.
Hemant K Chitale
http://hemantoracledba.blogspot.com

How Can I know what is causing a lot of Redo entries ?

Hi
My production database began yesterday to generate a lot of archives and I want to know what transactions are causing a lot of Redo entries ?
I guess it can be a process repeating something a lot times ( insert, deletes, updates, etc... )
Thanks for helping me

user2931261 wrote:
Hi
My production database began yesterday to generate a lot of archives and I want to know what transactions are causing a lot of Redo entries ?
I guess it can be a process repeating something a lot times ( insert, deletes, updates, etc... )
Thanks for helping meDBMS_LOGMNR will reveal DML that produces the REDO

Refraining from generating lots of TEMP data

hi gurus
I am currently doing a CTAS distinct from a big table. This operation is generating lots of TEMP data, usually going beyong my control. Is there a way to limit this?
thanks

'Distinct' clause means sorting internally and - especially in case of a big table - I think temporay tablespace usage is unavoidable. You can increase values for PGA_AGGREGATE_TARGET or SORT_AREA_SIZE (depending on database version) to get more sorting in memory, but there are physical memory limits.
Werner

NOLOGGING but still generating lot of logs!

I'm doing a bulk loading using 'sqlldr' with the DIRECT OPTION set to true. The table in question is set no NOLOGGING, yet, I'm getting a lot of redo (resulting in gigabytes of archived logs). The Force Logging option is set to FALSE.
I really have no clue where is my problem, but I hope someone can shed some light and help me out.

If you have any indexes on the table, this can result in redo generation. If you have not done so, you may want to use the 'skip_index_maintenance' parameter. This will mark any indexes as unusable. After the load has completed, you can rebuild the indexes in nolooging mode (alter index index_name rebuild nologging)

Off-heap backing maps seem to generate lots of garbage at insert..!?

I have been doing a lot of benchmarks of distributed caches with different backing maps. The results where partly positive (I hoped that partitioned (splitting) off-heap backing map would be almost as fast as a non-splitting on-heap backing map). For read and various types of queries this turned out to be mostly true (some queries were slightly slower - probably because they where performed per partition).
For inserts it does however sadly enough seem to be another story - already when using a non-splitting NIO backing map inserts seemed to generate a lot of garbage slowing the benchmark down significantly and when switching to a splitting NIO backing map this effect became so extreme that full GC occured more or less constantly on the cache nodes slowing execution down to almost a standstill :-(
Has anybody else tried this and seen the same results or do any of the Coherence developers have some theory?
To me it would seem like network-io to off-heap (using storage buffers allocated using nio just as the communication buffers!) should be at least as easy to perform without generating excessive garbage as to heap objects but since I dont know the internals of Coherence I cant say for sure if there are something that breaks this theory?
For me the main expected advantage with using off-heap rather than on-heap would have been REDUCED GC activity and shorter pauses but instead it seems like the result is the oposite - at least when doing inserts...
My example do not use (or need!) and secondary indexes (only performs get/put/lock/unlock) but each entry is locked before it is inserted and unlocked after (this is needed for the algorithm I am using as a benchmark) - as I have pointed out in another thread it is a pitty that no "lockAll" / unlockAll method calls exists (my benchmark is suffering a lot from all the lock/unlock remote calls) - the overhead for this is however nothing compared to the performance hit that comes from the all the GC...
I have tried to tune the GC in several ways but this has only to a very limited extent reduced the GC pauses length or the frequency of full-GC - it just seems like a LOT of garbage is generated for some reason...
The setings that so far was resulted in the least GC-overhead (still awfully bad though!) are -XX:+UseParallelGC -XX:+UseAdaptiveSizePolicy. I am using Coherence 3.5 GE and Sun JRE 1.6.0_14.
/Magnus
Edited by: MagnusE on Aug 10, 2009 3:01 PM

Thanks for ther info - I was indeed using different initial and max size in this experiment and seting them the same eased the problem (now I mostly get incremental rather than full GC messages). Insert do however still generate more GC activity than read (that seem to be more or less totally free from Java heap allocation / deallocation which is VERY good since read is so common!). Perhaps there is some more tweaking of the heap allocation/deallocation that can be done att the same time as you work on that bug you mentioned - it would really be nice with a NIO backing-map with close to zero Java heap usage for all primitive operations (read, insert, delete)!
/Magnus
Edited by: MagnusE on Aug 11, 2009 7:33 AM

Oracle oleDB generates lots of network traffic than Microsoft Oledb

Hi,
When calling the same stored proc. that returns a ref cursor, Oracle Oledb (1.34 MB) generates alot of network traffic than Microsoft Oledb (0.06 MB). The statistic is gathered using Windows 2000 Network Monitoring tools.
Calling the same stored proc. that returns a ref cursor
Oracle OleDB Microsoft Oledb
Byte Received: 1408026 (1.34 M) 71032 (0.06 M)
Byte Sent: 306468 (0.29M) 69914 ( 0.067M)
Frame: 1263 414
Network Utilization: 6%-14% 1%-3%
Anyone know why is this case?
Joe

When working with ADO and VB6, I looked at the database server with SQL Trace and found that each dynamic SQL statement was parsed twice per execution. REF CURSORs certainly require several network round-trips in order to retrieve schema information for the dataset to be created. This behaviour probably increases network load.
Unfortunately, I have not found any description of Oracle's OLEDB implementation. Hopefully, things will get better with the new, native OleDb data adapter.
/Armin
Previous post:
multiple parsing of SELECTs O/S : N/A POST: REPLY (W/QUOTE)
Author : Armin Type : N/A
Date : Apr 7, 2001 12:51 PT
System: OLEDB provider 8.1.7, server 8.1.7.
Our VB code dynamically assembles SELECT statements and fetches recordsets with ADO function Recordset::Open. SQL TRACE shows that those SELECTs are parsed twice per execution. SELECTs embedded in stored procedures are parsed only once during the SP's life time (but then the stored procedure call itself is parsed once per execution).
Parsing twice per execution consumes a lot of CPU. REF Cursors might reduce parsing but cause additional network roundtrips.
How could I reduce the parse count?

Finding which table generated how much redo

I'm wondering if we can find from any view that during this period a particular table generated how much amount of redo log , other than logminer ?
We have a particular application and want to know which tables are generating most of the redo.

from asktom
see
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:477221446020
and
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:366018048216
Nologging only affects very very specific operations. For exmaple, from the
alter index syntax statement in the SQL reference:
LOGGING|NOLOGGING
LOGGING|NOLOGGING specifies that subsequent Direct Loader (SQL*Loader) and
direct-load INSERT operations against a nonpartitioned index, a range or hash
index partition, or all partitions or subpartitions of a composite-partitioned
index will be logged (LOGGING) or not logged (NOLOGGING) in the redo log file.
In NOLOGGING mode, data is modified with minimal logging (to mark new extents
invalid and to record dictionary changes). When applied during media recovery,
the extent invalidation records mark a range of blocks as logically corrupt,
because the redo data is not logged. Therefore, if you cannot afford to lose
this index, you must take a backup after the operation in NOLOGGING mode.
If the database is run in ARCHIVELOG mode, media recovery from a backup taken
before an operation in LOGGING mode will re-create the index. However, media
recovery from a backup taken before an operation in NOLOGGING mode will not
re-create the index.
An index segment can have logging attributes different from those of the base
table and different from those of other index segments for the same base table.
That also explains why the truncate above generated redo -- The statement
"minimal logging (to mark new extents invalid and to record dictionary
changes)." explains where that redo comes from. The blocks that were truncated
were not logged HOWEVER the changes to the data dictionary itself were.
.

Generating lots of archive logs

Hi Friends,
We have an EBS 11i on AIX 5L ...which has just been setup and ready for UAT...but the AppsDBA/Functional Consultant who didi it are not around anymore to ask for questiones. I just noticed the there are archive logs generated everyday...like 30 logs...when in fact the application is not being used. Is there concurrent programs
that has been setup to update data on a background process, just like recursive updating which is not really necessary. How do I check if there are updates being done.
Thanks a lot

Do not stop this concurrent program as it is used to synchronize the Workflow local tables with the user and role information stored in the product application tables until each affected product performs the synchronization automatically.
More details can be found in the following note:
Note: 171703.1 - 11.5.x: Implementing Oracle Workflow Directory Service Synchronization
https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=171703.1
Did you check the total size of the log files? I believe you should not be worried now until the system is delivered to the users, you can monitor the number of log files generated daily then and based on that start your investigation.

Lot of Redo log wait

Dear all,
In st04 I see Redo log wait is this a problem. Please suggest how to solve it
Please find the details.
Size (kB)                            14,352
Entries                          42,123,046
Allocation retries                    9,103
Alloc fault rate(%)                     0.0
Redo log wait (s)                       486
Log files (in use)                8 (   8 )
DB_INST_ID     Instance ID     1
DB_INSTANCE     DB instance name     prd
DB_NODE     Database node     A
DB_RELEASE     Database release     10.2.0.4.0
DB_SYS_TIMESTAMP     Day, Time     06.04.2010 13:07:10
DB_SYSDATE     DB System date     20100406
DB_SYSTIME     DB System time     130710
DB_STARTUP_TIMESTAMP     Start up at     22.03.2010 03:51:02
DB_STARTDATE     DB Startup date     20100322
DB_STARTTIME     DB Startup time     35102
DB_ELAPSED     Seconds since start     1329368
DB_SNAPDIFF     Sec. btw. snapshots     1329368
DATABUFFERSIZE     Size (kB)     3784704
DBUFF_QUALITY     Quality (%)     96.3
DBUFF_LOGREADS     Logical reads     5615573538
DBUFF_PHYSREADS     Physical reads     207302988
DBUFF_PHYSWRITES     Physical writes     7613263
DBUFF_BUSYWAITS     Buffer busy waits     878188
DBUFF_WAITTIME     Buffer wait time (s)     3583
SHPL_SIZE     Size (kB)     1261568
SHPL_CAQUAL     DD-cache Quality (%)     95.1
SHPL_GETRATIO     SQL area getratio(%)     98.4
SHPL_PINRATIO     SQL area pinratio(%)     99.9
SHPL_RELOADSPINS     SQLA.Reloads/pins(%)     0.0042
LGBF_SIZE     Size (kB)     14352
LGBF_ENTRIES     Entries     42123046
LGBF_ALLORETR     Allocation retries     9103
LGBF_ALLOFRAT     Alloc fault rate(%)     0
LGBF_REDLGWT     Redo log wait (s)     486
LGBF_LOGFILES     Log files     8
LGBF_LOGFUSE     Log files (in use)     8
CLL_USERCALLS     User calls     171977181
CLL_USERCOMM     User commits     1113161
CLL_USERROLLB     User rollbacks     34886
CLL_RECURSIVE     Recursive calls     36654755
CLL_PARSECNT     Parse count     10131732
CLL_USR_PER_RCCLL     User/recursive calls     4.7
CLL_RDS_PER_UCLL     Log.Reads/User Calls     32.7
TIMS_BUSYWT     Busy wait time (s)     389991
TIMS_CPUTIME     CPU time session (s)     134540
TIMS_TIM_PER_UCLL     Time/User call (ms)     3
TIMS_SESS_BUSY     Sessions busy (%)     0.94
TIMS_CPUUSAGE     CPU usage (%)     2.53
TIMS_CPUCOUNT     Number of CPUs     4
RDLG_WRITES     Redo writes     1472363
RDLG_OSBLCKWRT     OS blocks written     54971892
RDLG_LTCHTIM     Latching time (s)     19
RDLG_WRTTIM     Redo write time (s)     2376
RDLG_MBWRITTEN     MB written     25627
TABSF_SHTABSCAN     Short table scans     12046230
TABSF_LGTABSCAN     Long table scans     6059
TABSF_FBYROWID     Table fetch by rowid     1479714431
TABSF_FBYCONTROW     Fetch by contin. row     2266031
SORT_MEMORY     Sorts (memory)     3236898
SORT_DISK     Sorts (disk)     89
SORT_ROWS     Sorts (rows)     5772889843
SORT_WAEXOPT     WA exec. optim. mode     1791746
SORT_WAEXONEP     WA exec. one pass m.     93
SORT_WAEXMULTP     WA exec. multipass m     0
IEFF_SOFTPARSE     Soft parse ratio     0.9921
IEFF_INMEM_SORT     In-memory sort ratio     1
IEFF_PARSTOEXEC     Parse to exec. ratio     0.9385
IEFF_PARSCPUTOTOT     Parse CPU to Total     0.9948
IEFF_PTCPU_PTELPS     PTime CPU / PT elps.     0.1175
Regards,
Kumar

Hi,
If the redo buffers are not large enough, the Oracle log-writer process waits for space to become available. This wait time becomes wait time for the end user. Hence this may cause perfromance problem at database end and hence need to be tuned.
The size of the redo log buffer is defined in the init.ora file using the 'LOG_BUFFER' parameter. The statistic 'redo log space requests' reflects the number of times a user process waits for space in the redo log buffer.
If the size of redo log buffer is not big enough causing this wait, recommendation is to increase the size of redo log buffer in such a way that the value of "redo log space requests" should be near to zero.
regards,
rakesh

How much Redo log is being generated by a user sesssion?

How can find which user session is creating the highest redolog entries and how much rego log is being generated?

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.
You use the first query when you need to check for programs generating lots of redo when these programs activate more than one transaction. The latter query can be used to find out which particular transactions are generating redo.

Expdp impdp - redo generation?

Friends...
Oracle 11gr2 SE
OS: Linux
I did tried to search in documentation but couldn't find answer.
I'm dropping some tables but before that exporting them for backup, db is in archivelog mode.
Before dropping tables, trying to find whether expdp job generates lots of redo or not since file system only have 20 GB of free space.
Question.
1. If I'm performing expdp of some tables with the size of 80 GB (table size.. index not included), does expdp will generate similar amount of redo or will it generate lots of redo?
2. Does impdp job also generate lots of redo or only during index creation in impdp?
thanks,
Mike

Export do NOT generate any redo. It's just dumping data into files in binary format. Very minimal redo just to maintain data export dump table but very very minimal. IF I have to guess no more than 1 MB.
Import does generate redo logs. Imports run 'Insert' statement behind the scenes and it does generate lot of redo logs. You can use sqlfile to create index definition and than run it manually with NOLOGGING which will reduce some redo. something like
impdp user/password exclude=indexes -- this will import everything but indexes.
impdp user/password include=index sqlfile=index.sql -- this will create a file called index.sql that will contain all of the create statements for the indexes

Unable to open 11g R2 database now after trying an RMAN restore

Hi my database is not opening now.
What I was trying was to restore the database on my new server from latest database taken from my old live server and applying it on my new 11g DB (new server-database already created)
old server-11.1.0.7.0-windows 2003 server 32 bit
new server-11.2.0.3.0-windows 2008 64 bit server
The steps i have done which caused this , (After everything was working fine, i did these foll.steps and now all messed up):
The oracle database on this new server was already 11.2.3.0 -it was not upgrade, i directly installed 11.2.0.3.0 on it + applied latest patches etc.
I took RMAN backup from old server 11.1.0.7.0 oracle database.
Copied this backup to to the new server flash recovery area &every step of the restore was working fine -
in nomount mode, restored the control file from autobackup-fine
in mount mode, catalogued the files-fine (Backup from old live,copied to new live)
I restored&Recovered the database until the latest archivelogs.
Until the above steps-all worked fine like a normal recovery steps.
Then I gave "alter database open resetlogs" in RMAN prompt, it gave out error and from that point onwards I am unable to open the database now.
Unfortunately, couldnt grab full screenshot of the error in RMAN but the error basically said that bootstrap failed and i have to open the database with the upgrade option?
Please see in alert log as well
ORA-00704: bootstrap process failure
ORA-39700: database must be opened with UPGRADE option
Following is the last lines from alert log:
[code]
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
Windows NT Version V6.1 Service Pack 1
CPU                 : 4 - type 8664, 4 Physical Cores
Process Affinity    : 0x0x0000000000000000
Memory (Avail/Total): Ph:3760M/8191M, Ph+PgF:9170M/16381M
VM name             : VMWare Version (6)
Using parameter settings in server-side spfile F:\APP\ORACLE\PRODUCT\11.2.0\DBHOME_1\DATABASE\SPFILEGEOP.ORA
System parameters with non-default values:
processes                = 150
memory_target            = 3728M
control_files            = "F:\ORACLE11G\ORADATA\GEOP\GEOP\CONTROL01.CTL"
control_files            = "F:\ORACLE11G\ORADATA\GEOP\GEOP\CONTROL02.CTL"
control_files            = "F:\ORACLE11G\ORADATA\GEOP\GEOP\CONTROL03.CTL"
db_block_size            = 8192
compatible               = "11.2.0.0.0"
log_archive_format       = "ARC%S_%R.%T"
db_recovery_file_dest    = "I:\oracle\flash_recovery_area"
db_recovery_file_dest_size= 45G
undo_tablespace          = "UNDOTBS1"
sec_case_sensitive_logon = FALSE
remote_login_passwordfile= "EXCLUSIVE"
db_domain                = ""
dispatchers              = "(PROTOCOL=TCP) (SERVICE=GEOPXDB)"
audit_file_dest          = "F:\APP\ORACLE\ADMIN\GEOP\ADUMP"
audit_trail              = "DB"
db_name                  = "GEOP"
open_cursors             = 300
diagnostic_dest          = "F:\APP\ORACLE"
Thu Dec 12 17:22:18 2013
PMON started with pid=2, OS id=3440
Thu Dec 12 17:22:18 2013
PSP0 started with pid=3, OS id=10252
Thu Dec 12 17:22:19 2013
VKTM started with pid=4, OS id=11684 at elevated priority
VKTM running at (10)millisec precision with DBRM quantum (100)ms
Thu Dec 12 17:22:19 2013
GEN0 started with pid=5, OS id=4528
Thu Dec 12 17:22:19 2013
DIAG started with pid=6, OS id=5652
Thu Dec 12 17:22:19 2013
DBRM started with pid=7, OS id=7676
Thu Dec 12 17:22:19 2013
DIA0 started with pid=8, OS id=5724
Thu Dec 12 17:22:19 2013
MMAN started with pid=9, OS id=6632
Thu Dec 12 17:22:19 2013
DBW0 started with pid=10, OS id=3572
Thu Dec 12 17:22:19 2013
LGWR started with pid=11, OS id=8876
Thu Dec 12 17:22:19 2013
CKPT started with pid=12, OS id=3748
Thu Dec 12 17:22:20 2013
SMON started with pid=13, OS id=8108
Thu Dec 12 17:22:20 2013
RECO started with pid=14, OS id=1932
Thu Dec 12 17:22:20 2013
MMON started with pid=15, OS id=7468
Thu Dec 12 17:22:20 2013
MMNL started with pid=16, OS id=8136
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 1 shared server(s) ...
ORACLE_BASE from environment = F:\app\oracle
Thu Dec 12 17:22:21 2013
ALTER DATABASE   MOUNT
Successful mount of redo thread 1, with mount id 3351347149
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE   MOUNT
Thu Dec 12 17:22:26 2013
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
parallel recovery started with 3 processes
Started redo scan
Completed redo scan
read 11 KB redo, 6 data blocks need recovery
Started redo application at
Thread 1: logseq 3, block 2, scn 59089613795
Recovery of Online Redo Log: Thread 1 Group 6 Seq 3 Reading mem 0
Mem# 0: F:\ORACLE11G\ORADATA\GEOP\GEOP\REDO06.LOG
Completed redo application of 0.01MB
Completed crash recovery at
Thread 1: logseq 3, block 24, scn 59089633817
6 data blocks read, 6 data blocks written, 11 redo k-bytes read
Read of datafile 'F:\ORACLE11G\ORADATA\GEOP\GEOP\TEMP01.DBF' (fno 201) header failed with ORA-01203
Rereading datafile 201 header failed with ORA-01203
Errors in file F:\APP\ORACLE\diag\rdbms\geop\geop\trace\geop_dbw0_3572.trc:
ORA-01186: file 201 failed verification tests
ORA-01122: database file 201 failed verification check
ORA-01110: data file 201: 'F:\ORACLE11G\ORADATA\GEOP\GEOP\TEMP01.DBF'
ORA-01203: wrong incarnation of this file - wrong creation SCN
File 201 not verified due to error ORA-01122
LGWR: STARTING ARCH PROCESSES
Thu Dec 12 17:22:27 2013
ARC0 started with pid=19, OS id=10876
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thu Dec 12 17:22:28 2013
ARC1 started with pid=24, OS id=10912
Thu Dec 12 17:22:28 2013
ARC2 started with pid=25, OS id=6652
Thu Dec 12 17:22:28 2013
ARC3 started with pid=26, OS id=9648
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
Thread 1 advanced to log sequence 4 (thread open)
ARC1: Becoming the 'no SRL' ARCH
ARC2: Becoming the heartbeat ARCH
Thread 1 opened at log sequence 4
Current log# 4 seq# 4 mem# 0: F:\ORACLE11G\ORADATA\GEOP\GEOP\REDO04.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
SMON: enabling cache recovery
Archived Log entry 64945 added for thread 1 sequence 3 ID 0xc7c27920 dest 1:
Errors in file F:\APP\ORACLE\diag\rdbms\geop\geop\trace\geop_ora_12260.trc:
ORA-00704: bootstrap process failure
ORA-39700: database must be opened with UPGRADE option
Errors in file F:\APP\ORACLE\diag\rdbms\geop\geop\trace\geop_ora_12260.trc:
ORA-00704: bootstrap process failure
ORA-39700: database must be opened with UPGRADE option
Error 704 happened during db open, shutting down database
USER (ospid: 12260): terminating the instance due to error 704
Instance terminated by USER, pid = 12260
ORA-1092 signalled during: ALTER DATABASE OPEN...
opiodr aborting process unknown ospid (12260) as a result of ORA-1092
Thu Dec 12 17:22:33 2013
ORA-1092 : opitsk aborting process
[/code]
Please please please let me know what steps should I do now to get my 11g database operational again?
Now when i am trying:
(SQL prompt)
[code]
>sqlplus "/ as sysdba"
SQL*Plus: Release 11.2.0.3.0 Production on Thu Dec 12 17:22:05 2013
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup open;
ORACLE instance started.
Total System Global Area 3891630080 bytes
Fixed Size                  2261120 bytes
Variable Size            2147487616 bytes
Database Buffers         1728053248 bytes
Redo Buffers               13828096 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-39700: database must be opened with UPGRADE option
Process ID: 12260
Session ID: 5 Serial number: 5
SQL> startup open upgrade;
SP2-0714: invalid combination of STARTUP options
SQL> startup upgrade;
ORA-24324: service handle not initialized
ORA-01041: internal error. hostdef extension doesn't exist
SQL> startup upgrade open;
SP2-0714: invalid combination of STARTUP options
SQL> alter database mount;
ERROR:
ORA-03114: not connected to ORACLE
SQL> shutdown immediate;
ORA-24324: service handle not initialized
ORA-01041: internal error. hostdef extension doesn't exist
SQL> startup nomount
ORA-24324: service handle not initialized
ORA-01041: internal error. hostdef extension doesn't exist
SQL>
[/code]

This is why you do backups both before and after doing other things.
So one way to do something like this:
Backup old db.
expdp old db.
Install new 11gR2, create database.
Back it up.
Turn off archivelog.
impdp
Turn on archivelog.
Back it up.
The general thought here is you would start over with the first new db backup if the imp didn't work, you turn off archiving to avoid generating lots of redo that would be for a recovery you would never do.
There is more than one way to do it (TIMTOWTDI), best way depends on details, including volume of data and platform changes. expdp/impdp has an over the network option if disk space is limited and network is fast.
I usually allow for several tries when going to a new box, since the new box will require testing anyways.

How to find a session with high archive logs

Any query, to see which active session is generating high archive logs in oracle 8i &9i and high rbs usage

Though, there is no direct option or view where you can get this information.
However, you may can find out the session which are generating lot of redo and undo. I guess, when the session has lot of redo & undo, definately, it contribution towards archive would be more.
You can query v$sess_io and v$session to findout the the session which is generating lot of redo. i.e. lot of block changes occuring.
SELECT s.sid, s.serial#, s.username, s.program, i.block_changes
FROM v$session s, v$sess_io i
WHERE s.sid = i.sid
ORDER BY 5 desc
Also query v$transaction and v$session to find out the session that is generating lot of undo information.
Jaffar
Message was edited by:
Syed Jaffar

Why size of archive log file increasing in merge clause

my database is running in archive log mode.
someone is running oracle merge statement. still it is running.
He will issue commit after the operation.
in that period redolog file increasing now.
my question is why size of archive log file increasing with redolog file.
i know that after commit archive log file should generate.(may be it is wrong).
please suggest........
Edited by: 855516 on Mar 13, 2012 11:18 AM

855516 wrote:
my database is running in archive log mode.
someone is running oracle merge statement. still it is running.
He will issue commit after the operation.
in that period redolog file increasing now.
my question is why size of archive log file increasing with redolog file.
i know that after commit archive log file should generate.(may be it is wrong). No this is not correct that after commit archive log will generate....You know merge statement causes the insert (if data not present already) or update if database is present.. Obviously these operation will generate lots of redo if the amount of data been processed is high.
If you feel that this operation is causing excessive of redo then root cause analysis should be done...
For that use Logminer (excellent tool to provide segment level breakdown of redo size). V$logmnr_contens has columns redo block and redo byte address associated with the current redo
change
There are some gudlines in order to reduce redos( which may vary in any environment)
1) check if there are unwanted indexes being used in tables which are refereed in merge. If yes then remove those could bring down the redo
2) Use global temporary tables to reduce redo (if there is a need to keep data only temporarily in a session)
3) Use nologging if possible (but see its implications)
Hope this helps

SMON generating lot of redo

Similar Messages

Maybe you are looking for