Data Guard Bug, which patch to fix?

It seems as though there is a bug in the Data Guard configuration through the Enterprise Manager. As I'm going through the process of setting up a physical standby database it asks me to specify a working directory. I specify the directory on a disk that has 250GB of free disk space and when I press next it does not proceed. It gives me an error "Insufficient Disk Space".
I googled for a solution to the problem and the only thing that came up was someone that had the same problem. This person mentioned that it is a known bug (3895311).
Any help would be appreciated!
(This is an Oracle 10g install on a Windows 2003 server).

Great, the patch worked like a charm. I can now proceed. However, 2 steps after specifying a working directory on the primary database host, you have to specify a working directory on the standby database host. And again, I'm getting the "Insufficient Disk Space" bug (now on the standby database host). I applied the patch to the Management Agent ORACLE_HOME on the standby host, but it didn't work.
Should this have worked? Or is this another patch that I must get?
Thanks

Similar Messages

Question about a bug which should be fixed in the 10.2.0.4 patchset

Hi,
We have a 10.2.0.4 single instance database on Sun Solaris SPARC (64-bit) and have the same symptoms as described in Bug 4643723 (error codes and the stack trace are the same). That bug should be already fixed in 10.2.0.4 patchset.
Does anyone have experience on how to proceed in such cases - I mean, is making a SR on metalink an obvious action?
Is it possible that the patchset wasn't applied correctly although "opatch lsinventory" outputs that the "10g Release 2 Patchset 3 (10.2.0.4)" is installed and SYS.REGISTRY$HISTORY also contains a record of the upgrade. The upgrade from 10.2.0.1 to 10.2.0.4 was performed 6 months ago and the database was continuously up and runing till then.
Thanks for any answers

many bugs can have the same errors. Raise an SR.
Oracle Support will ask for an opatch lsinventory, and may ask you verify library versions, or relink.

Applying recommended patch bundles to a Data Guard environment.

I've learned that there are 3 recommended patch bundles for 10.2.0.4 Data Guard, as follows:
7937113 - 10.2.0.4 Data Guard Logical Recommended Patch Bundle #1
7936993 - 10.2.0.4 Data Guard Physical Recommended Patch Bundle #1
7936793 - 10.2.0.4 Data Guard Broker Recommended Patch Bundle #1
My question is this...should I apply the logical and physical patch bundles to the primary database as well?
Thanks,
Michael Anderson
OCP - Bank of the West

That's what I suspected. Now, in my environment, I could never conceive of a situation where I would switch roles between the primary and the logical standby database, so I would only apply the DG physical patch bundle to the primary database but not the DG Logical patch bundle. Agree?

Using Oracle EM 11g with Active Data Guard 11g

Has anyone installed Active Data Guard 11g with OEM 11g for an active-active state or know if there are any installation procedures with these two products? We will be installing these products this year. Thanks, Cathy

If you already have both servers configured in Grid Control as targets, it should be fairly easy to create a standby database on server B. OEM has Availability tab on your primary database Instance section should have "Data Guard" section which has "Setup and Manage" option. You follow through the wizard, and it will generate a standby database on server B. Then you can convert your standby db on server B to Active Read-only database by clicking few more buttons.
If you do not have these two servers configured on your Grid Control, that would be the first task.
We set up three standby databases using Grid Control 11g in our test boxes, and they worked very well. Our biggest problem was to actually installing the Grid Control, but once installed, everything was easy.

Applying patches to physical standby node(Data Guard 10.2.0.3)

Hello,
I have a data guard 10.2.0.3 environment (1 primary and 1 physical standby on a separate node) on solaris 10 and i want to document the procedure in applying patches to this environment.
I saw the article in Metalink Note 278641.1 which describes the procedure in applying a patchset to both nodes. It looks like both nodes need to be down before applying the oracle patchset.
Can we not apply the patches on only the standby while the primary stays up and running? My guess is you can't if the patches are significant i.e. it changes versions of the oracle binaries. But i want to confirm this.
Also, if we are applying solaris patches, i.e. nothing related to Oracle, we should be able to just apply them to the standby while keeping the primary up and running right?
The following has worked so far but i wanted to find some documentation that confirms it's ok.
1. shutdown oracle on standby node.
2. apply solaris patches...
3. restart oracle on standby node and put in managed recovery mode.
Any comments are appreciated.
Thanks.

Hi
Did you get an answer for your question yet? I have the same problem with one of our databases. Would be very nice, if you could tell me.
Regards
Felix

Active data guard - patching

Hi Gurus,
I have primary db amsprd and active data guard amsprd_stby.
we are planning to apply application patches in amsprd. earlier we used to rely on rman backup for restore in case of any failures.
I would like to make use of standby as primary and keep the business up immediately after application patch failures.(to reduce the downtime - application failures are not having any rollback steps :-( - vendor product).
to achieve this,
before application patch application
do i have to just stop the log shipping?
or do i have to stop just log file apply?
what are the steps involved in case of primary applicaiton patching failures.
Thank you.

So the Application Patch may turn out as a "Logical Mistake" from the Database perspective.
One option would be to stop the Apply on the Standby Database. If your Application Patch was no good, you could do an "Immediate Failover" which will open the Standby immediately without applying the received redo first like an ordinary Failover would. You would have to create a new Standby Database on your Ex Primary site then.
Another option would be to turn on Flashback Logging on both sites. If your Application Patch was ok - nothing to do. If not, flashback both sites to before the App Patch. Look here for an example:
http://uhesse.wordpress.com/oracle-database-ha-architecture/2010/08/06/using-flashback-in-a-data-guard-environment/
Second option has the benefit that you do not delay an emergency failover, should your Primary incidentally get destroyed during the App Patch. Also, if you need to rewind the Logical Mistake, you do not need to recreate the Standby completely. If you are on 11gR2, you can even turn on/off Flashback Logging without having to restart:
http://uhesse.wordpress.com/2010/06/25/turning-flashback-database-on-off-with-instance-in-status-open/
Kind regards
Uwe Hesse
http://uhesse.wordpress.com

Goldengate from physical standby with Active data guard or from logical standby - which is better?

Hi,
We have Oracle 11.2.0.4 and are currently using Active Data Guard on a physical standby. My boss wants me to use Goldengate
to replicate several schema from Oracle to SqlSserver. She doesn't want to touch the Primary, which is in production. Would it be better
to setup a Logical standby for Goldendate to use, in addition to the Physical standby? Or will it be sufficient to use the Physical standby?
The application tables don't all have primary keys. I'm trying to decide if the Logical standby adds another layer of complexity or would
introduce delays in getting the data from Oracle to Sqlserver.
Thanks in advance,

Hi,
In this case I recommend you to use physical standby + Golden gate with ALO mode. You might have sligthly more trouble in logical standby. it means you might have more trouble at Goldengate's extract side.
You said
The application tables don't all have primary keys.
so you have to add keycols on replicat side.
I recommend you to add an index which should consist of keycols columns. it will be necessary for replicat performance.
Best Regards

Application of patches on oracle data guard 10g

Help!
I need apply the patch 9233832 on oracle 10.2.0.4 but I have configuration a pysical data guard. Considerations should I have to do? What steps should I follow?
Thanks.

Hello;
I have the steps in my notes will post back here - These :
Disable log shipping from the Primary
Shutdown Standby
Install patch software on Standby
Startup Standby in recovery mode (do NOT run any SQL at the standby)
Shutdown Primary
Install patch software on Primary
Run SQL for patch on the Primary
Re-enable log shipping
Monitor the redo apply from Primary This is pretty much the same for a CPU type patch or going from say 11.2.0.1 to 11.2.0.2. On Standby you just install the software and let the redo handle the rest.
Best Regards
mseberg
Edited by: mseberg on Mar 6, 2012 12:56 PM

So a number of my apps (ie., United, ES File Explorer, etc..), which worked a few days ago, are now crashing on start-up or shortly thereafter. Have you recorded this bug and is a fix forthcoming? Anxiously awaiting an update.

So a number of my apps (ie., United, ES File Explorer, etc..), which worked a few days ago, are now crashing on start-up or shortly thereafter. Have you recorded this bug and is a fix forthcoming? Anxiously awaiting an update.

There are a number of threads about this issue on the forum if you want to do a search. Basically, you need to uninstall the latest update to Android System Webview:
http://www.droid-life.com/2015/04/27/apps-crashing-android-system-webview/#more-166266

[svn:fx-trunk] 12972: Commit Catalyst-submitted patch for fixing up unicode path/ file names in ActiveX.

Revision: 12972
Revision: 12972
Author:   [email protected]
Date:     2009-12-15 15:27:40 -0800 (Tue, 15 Dec 2009)
Log Message:
Commit Catalyst-submitted patch for fixing up unicode path/file names in ActiveX.
QE notes: None.
Doc notes: None.
Bugs: SDK-24648
Reviewer: Alex & I
Tests run: checkintests
Is noteworthy for integration: Yes
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-24648
Modified Paths:
    flex/sdk/trunk/frameworks/projects/framework/src/mx/controls/SWFLoader.as

Dear Pallavi,
Very useful post!
I am looking for similar accelerators for
Software Inventory Accelerator
Hardware Inventory Accelerator
Interfaces Inventory
Customization Assessment Accelerator
Sizing Tool
Which helps us to come up with the relevant Bill of Matetials for every area mentioned above, and the ones which I dont know...
Request help on such accelerators... Any clues?
Any reply, help is highly appreciated.
Regards
Manish Madhav

Dgutil.pl line 99 ERROR when creating 11.2.0.3 data guard via GRID CONTROL

Oracle Grid Control 11g Release 1 (11.1.0.1.0)
(64bit)
Oracle Enterprise Linux Server release 5.4 x86_64
Oracle Database 11.2.0.3 (64bit)
1. Grid Control>Targets>Databases
2.Click on pc01prmy (Primary)
3.Availability > Data Guard > Setup and Manage
4.Add Standby Database
5.Create a new physical standby database.
Fails with message:
38706 at /u01/app/oracle/agent11g/sysman/admin/scripts/db/dg/dgutil.pl line 99.
I can create a standby with a rman script without problems, but via the Grid Control page fails.
Have you seen this before?

I contact Oracle Support on this issue, here are the details.
Generic Note
Hi Marcelo, the note you sited Creating Standby Database With Enterprise Manager Failing [ID 1400482.1
Says something a little different than what you tried.
You did RECOVER DATABASE for manual recover and the error says use backup control file.
For a standby to do manual recovery it's
*alter database recover standby database ;*
It may behave better.
But the note implies to just apply enough redo to have the standby consistent enough to turn on flashback.
This can be done by starting managed recovery and applying some redo log sequences.
So the flashback being turned on is too soon, but should have worked anyway. I think it would turn on managed recovery though.
This also happens since the job doesn't use dorecover since recovery can be done with managed recovery.
So most likely there isn't enough activity on the primary and the online redo has not been archived yet.
So some log switches on the primary will send enough redo to get consistent so you can turn on flashback and finish it.
*So why did it happen?*
Possibly
Bug 13250486 - ADD STANDBY DATABASE FOR TARGET WITH FLASHBACK ON FAILS WITH ERROR
Base bug 12923814 FLASHBACK AND ARL DELETION OPTIONS IGNORED IN ADD STANDBY DATABASE WIZARD
fixed in Grid Control 12.1c
There is currently no patch available for 11.1.0.1 Grid Control. We would have to open a bug to confirm you hit this in 11.1.0.1 and get a patch.
*A workaround would be to turn off flashback at the primary then try to create the standby.*
*Once the standby is created you can turn flashback back on for the primary and if required, the standby.*
You can try again to see, or finish the standby manually as I stated above.
I will still need the diagnostic information below.
Action Plan
=========
The product verion in this SR is for 12.1.0.1 Grid Control. I assume it should be 11.1 since you stated it is.
Grid Control job log that shows the errors.
alert logs from the primary and standby.
Please run these two diagnostic scripts and upload the output.
Script to Collect Data Guard Primary Site Diagnostic (Doc ID 241374.1)
Script to Collect Data Guard Physical Standby Diagnostic (Doc ID 241438.1)
Edited by: Marcelo Marques - ESRI on Mar 24, 2012 9:51 AM

Data Guard, Grid Control 11, GI 11gR2, and DB 10gR2

Hi,
I'm seeing a rather odd behavior, and I'm hoping someone else has already been through this and knows what I'm doing wrong.
I have an installation of Grid Control 11.1 (recently patched) which I am using to create Data Guard replication of some 10gR2 database instances. For some confusing reason, sometimes when I use the GC wizard to add the standby database, it creates the listener for the new database in the EM Agent's OH/network/admin/listener.ora. Other times, it creates it in the 10gR2 DB's OH/network/admin/listener.ora. When it does the former, creation of the standby DB seems to work fine, but when it does the latter, not so much.
If it matters, my primary DB is 10.2.0.4 on 10.2 grid infrastructure, and my standbys are 10.2.0.4 on GI 11.2.0.2.
I have applied the latest PSU to my agents, so they are all the same version, so I'm confused as to why this might be happening. Has anyone else seen this issue?
Thanks,
Bill

My recommendation would be to not use OEM Grid Control to create your standby.
Even when it is working properly ... it does not create what I would consider a good implementation. Just as I don't consider the vanilla installation of the Oracle database by the OUI (all control files and redo logs in the same directory with the datafiles) very good.
You'd be far better off hand crafting your standby using two listeners ... one for public and one for replication.

Data Guard - MRP stuck issues on a physical standby database

Hi,
Oracle 11.2.0.3 DG running. When i do a switchover the physical standby database has error with following error
ARC0: LGWR is actively archiving destination LOG_ARCHIVE_DEST_2
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance <primaryDB> - Archival Error
On standby DB
SQL>select process, thread#, sequence#, status from v$managed_standby where process='MRP0';
PROCESS THREAD# SEQUENCE# STATUS
MRP0 1 548 APPLYING_LOG
So according to Oracle support link i executed following
SQL>recover managed standby database cancel;
SQL>recover automatic standby database;
The above seems to resolve the issue. What is causing is this?

Hello again;
Those both look perfect. I combed through my notes and found nothing like this for your version.
Yes, I would open an SR since it appears you have done everything correct.
ORA-600 [3020] "Stuck Recovery" [ID 30866.1]
The "Known Bugs" section of the above has a few 11.2.0.3 entries.
Generally the MRP gets stuck because data Guard thinks there's a GAP, you run out of room in the FRA on the Standby, or redo logs are too small and the system is switching very fast.
Best Regards
mseberg
Later
Never asked you but this "log_archive_max_processes" can be set as high as 30.
Edited by: mseberg on Jul 16, 2012 8:01 PM
h2. Still later
Found this which is closer :
Bug 13553883 - Archiver stuck but no ORA-19xxx error in alert log (messages need changing) [ID 13553883.8]

Which patches should be applied

DB-Version: 11.2.0.2.0 ---- got from v$version
OS : SUNOS 5.10 sparc (this means 32 bit right?)
Two node Rac cluster
Hello guys, I have a bit of a situation with patch terminology. My manager came to me and told me that we had to find out which patches to be applied and after that we had to go to metalink and find out what patches are available for our systems.
so first off, I logged into one node, went to $ORACLE_HOME/Opatch/ and did the following "opatch lsinventory" and got the following information.
Now my question is, how do I use the following info to find out what other patches to be applied?
{code}
Oracle Interim Patch Installer version 11.2.0.3.3
Copyright (c) 2012, Oracle Corporation. All rights reserved.
Oracle Home       : /clu01/oracle/product/1120
Central Inventory : /clu01/oracle/oraInventory
   from           : /clu01/oracle/product/1120/oraInst.loc
OPatch version    : 11.2.0.3.3
OUI version       : 11.2.0.2.0
Log file location : /clu01/oracle/product/1120/cfgtoollogs/opatch/opatch2013-10-17_15-41-20PM_1.log
Lsinventory Output file location : /clu01/oracle/product/1120/cfgtoollogs/opatch/lsinv/lsinventory2013-10-17_15-41-20PM.txt
Installed Top-level Products (1):
Oracle Database 11g                                                  11.2.0.2.0
There are 1 products installed in this Oracle Home.
Interim patches (2) :
Patch 14727315     : applied on Sat Feb 16 16:34:03 EST 2013
Unique Patch ID: 15707185
Patch description: "Database Patch Set Update : 11.2.0.2.9 (14727315)"
   Created on 4 Jan 2013, 07:14:17 hrs PST8PDT
Sub-patch 14275621; "Database Patch Set Update : 11.2.0.2.8 (14275621)"
Sub-patch 13923804; "Database Patch Set Update : 11.2.0.2.7 (13923804)"
Sub-patch 13696224; "Database Patch Set Update : 11.2.0.2.6 (13696224)"
   Bugs fixed:
     13080778, 10114837, 10373381, 14461358, 10035737, 12737666, 11065646
     13769501, 12639234, 12586495, 10630870, 12880299, 9715581, 10218814
     9860769, 10332111, 15896431, 14263036, 10367188, 12830339, 14263073
     9651350, 12586489, 11683713, 14107388, 10097711, 12950644, 10113990
     12370722, 12586491, 12899768, 15896427, 9414040, 14613900, 9373370
     11724916, 13769503, 9578670, 10285022, 10399808, 11877623, 10248523
     12586493, 9972680, 10092858, 12546006, 12797765, 12586487, 13769509
     11830777, 10055063, 10648873, 10419984, 10077191, 11063191, 10220033
     11858315, 11061775, 9478199, 12649442, 12326708, 11708510, 10127360
     11734067, 10396041, 10190642, 13737746, 10396874, 10233732, 10209232
     12595561, 9956835, 11666137, 10061015, 9672816, 11695416, 9744252
     10620808, 9858539, 11694127, 11894889, 9382956, 10204358, 12713993
     10080579, 12764337, 11738259, 10084145, 10363186, 12670165, 10324294
     14107384, 10158493, 10155605, 10013177, 13343424, 11686968, 10013431
     14546575, 12586496, 11674485, 13476583, 9877980, 10126822, 10284570
     10329146, 10326338, 15896429, 11064851, 11063821, 12655433, 10314582
     10051315, 12326246, 10332589, 13467683, 10368698, 12586486, 9724970
     13769507, 11815753, 9905049, 10053725, 12834027, 10229886, 9869287
     9735237, 9896536, 12846268, 9912965, 12794305, 10022980, 14546673
     13503598, 11695285, 12595730, 13399435, 13343244, 14023636, 12371955
     12633340, 13257247, 10039731, 11674898, 13769505, 9824435, 6892311
     11841309, 10031806, 12894807, 11076894, 10170431, 12748240, 9965655
     12323180, 12531263, 10219583, 12417369, 12419331, 9539440, 10622001
     14107385, 10227288, 11867127, 10258337, 11814891, 10228393, 10621169
     9847634, 8547978, 15896435, 10159846, 10142857, 10187168, 10269503
     10395345, 12596444, 9564886, 10373013, 11785938, 10213073, 11827088
     10302581, 12569482, 10278372, 14546638, 9795214, 12397410, 9707965
     9443361, 10210507, 10126094, 10073683, 10172453, 11811073, 10230571
     12419321, 12656535, 10312847, 9943960, 10052141, 12408350, 13250244
     9903826, 12409916, 11056082, 10026601, 12420002, 8685446, 8223165
     9401552, 12780098, 10094823, 11716621, 12589039, 14390377, 10228151
     10623249, 10356513, 12345717, 11057263, 11856395, 11775474, 11670161
     15896433, 11924400, 14841437, 10094201, 10378005, 10115630, 9835264
     10422126, 10021111, 14258925, 11818335, 10281887, 11707302, 10140809
     10317487, 12586488, 10322959, 9727147, 10151017, 13386082, 11706168
     10245086, 14469008, 10205230, 10158965, 11937253, 11733179, 9829397
     10278773, 14107387, 11882425, 10419629, 12586494, 12337012, 12848798
     10388660, 9788588, 10239480, 6523037, 10417716, 9842573, 12879027
     11883472, 12586492, 10200404, 10232083, 12685431, 9881076, 14275621
     10157402, 9709292, 11830778, 14461357, 10207092, 12586490, 11800170
     9683047, 12391602, 14262913, 10417216, 10635701, 9869401, 10157249
     10131867, 13632725, 9970255, 14683459, 13468884, 15896428, 11830776
     10633840, 12976376, 11695333, 10200390, 10142909, 13326736, 10237773
     12366627, 7312717, 10019218, 11664046, 9233544, 12569737, 14107389
     13001379, 13099577, 10222719, 9873405, 11834448, 9819805, 11872103
     10165083, 13769502, 10193846, 10285394, 11715084, 12827726, 9375300
     14040433, 11723722, 10264696, 10264680, 13769508, 11842991, 12845115
     14473913, 9436324, 10358019, 10089333, 14741727, 14038791, 13550185
     10175192, 8672862, 10207551, 9956713, 12639177, 11853815, 14461356
     10180307, 10048701, 12828071, 10079168, 12423475, 13923804, 9771278
     10356782, 14127510, 13769506, 10229719, 12340939, 9966609, 11651810
     14035825, 9078442, 10137324, 13769504, 10219576, 12378147, 10217802
     10142788, 10129643, 12400751, 12539000, 11724984, 9735282, 10040921
     9591812, 9906422, 9746210, 12917230, 9770451, 10021022, 12846269
     10110863, 12579349, 11067567, 10411618, 11699057, 10425676, 13916709
     12635537, 14076523, 11707699, 9895207, 11890804, 10299224, 10018789
     14205448, 9926929, 11800854, 11866952, 14467061, 10384285, 10636231
     11069199, 11689702, 14624146, 10427260, 10324526, 13696224, 12543639
     11690639, 9285259, 10284838, 10082277, 9952554, 9470768, 15896430
     11785390, 10310299, 10412247, 12313857, 12431716, 14107386, 10102506
     10238786, 10132870, 10247152, 9953542, 14727315, 9572787, 15896434
     11800959, 13769510, 10052956, 12374212, 10040531, 15896432, 9681133
     10190172, 11878443, 10040035, 12620422, 10171273, 11893621, 10249791
     11788856, 11664719, 9748749, 13554409, 11889177
Patch 13696242     : applied on Sat Feb 16 16:19:11 EST 2013
Unique Patch ID: 14622431
Patch description: "Grid Infrastructure Patch Set Update : 11.2.0.2.6 (13696242)"
   Created on 2 Apr 2012, 05:03:14 hrs PST8PDT
   Bugs fixed:
     13696242, 10157506, 10178670, 10425672, 12311357, 12419353, 12827731
     13343447, 13653086, 9959110, 10374874, 10272615, 10314123, 10014392
     10089120, 10057296, 11692271, 9864003, 11775080, 13635562, 9916145
     12695202, 12593451, 10044622, 11705438, 10365625, 12767231, 9935308
     12399977, 11882456, 12421404, 12862012, 11744343, 12340700, 10056713
     10637741, 9939306, 9795321, 9902536, 10007185, 10376847, 10038791
     11741224, 12823479, 11655840, 10048487, 10322157, 11768599, 10260251
     10052721, 10028235, 10027079, 12412303, 10357258, 11664015, 11871469
     10045436, 10231906, 12722095, 10622973, 11724464, 9891341, 10072474
     10036834, 10029900, 9974223, 10161846, 10016083, 12597463, 9918485
     11781515, 10040647, 13332363, 12651595, 12345151, 11925641, 10069541
     10029119, 12709476, 10233159, 12332919, 9812956, 10036193, 10015210
     12424479, 12340501, 10621175, 9686152, 12556028, 12605690, 11877079
     8906163, 10111010, 12366642, 11777648, 10115514, 10104377, 10121931
     10057680, 10280665, 10078086, 9944948, 10146768, 10052529, 10011084
     10012319, 10073075, 10233811, 12720728, 10299006, 12426375, 10248739
     10236074, 10128191, 11071429, 10019726, 9975837, 10253630, 12615394
     10420872, 9949676, 11936945, 11820787, 10637483, 13036424, 13396479
     10379703, 12677816, 10157622, 11698552, 10385838, 10053985, 12718811
     10229297, 10425674, 9812970, 11828633, 12538907, 12359585, 11899801
     10083789, 12728585, 9876201, 10073372, 9963327, 10428946, 11077756
     10375649, 12398492, 9336825, 11682409, 10062301, 12767563, 12546712
     10018215, 10105195, 10419987, 13355549, 10071992, 11807012, 10634513
     9926027, 10103954, 12743755, 12406573, 10028343, 12425730, 11768055
     11866171, 10065216, 9907089, 9897335, 10190153, 11744313, 10175855
     12600343, 12422324, 10284828, 10028637, 10361177, 12800501, 9979706
     12950415, 10324594, 10015460, 11818524, 9971646, 11782423, 11654726
     9978765, 10398810, 11904778, 10397652, 13768473, 9915329, 10107380
     10110969, 10305361, 10331452, 10083009, 10631693, 10008467, 10048027
     10040109, 9944978, 10370797, 10033106, 12700217, 11840629, 10042143
     9978195, 10284693, 12639016, 10638381, 11839004, 9679401, 11663339
     10075643, 10057719, 11834289, 9458055, 10205290, 10124517, 12680491
     13334158, 11069614, 10165314, 9593552, 10168006
Rac system comprising of multiple nodes
Local node = hcs391chprpd301
Remote node = hcs391chprpd302
OPatch succeeded.
{code}

You are running 11.2.0.2   The current (latest) patchset level is 11.2.0.4   That requires an "out-of-place" upgrade -- i.e. by installing 11.2.0.4 in a seperate ORACLE_HOME and then running catupgrd.
However, before you do that, you should be upgrading your Grid Infrastructure (to 11.2.0.4)
Since an upgrade from 11.2.0.2 to 11.2.0.4 is significant, you should test your applications against 11.2.0.4 in a test environment first.
See Oracle Support notes
11.2.0.4 Patch Set - Availability and Known Issues (Doc ID 1562139.1)
and
Important Changes to Oracle Database Patch Sets Starting With 11.2.0.2 (Doc ID 1189783.1)
CPUs are documented here : http://www.oracle.com/technetwork/topics/security/alerts-086861.html
The latest CPU, for the October 2013 release, is the final CPU for 11.2.0.2   [See Oracle Support note "Patch Set Update and Critical Patch Update October 2013 Availability Document (Doc ID 1571391.1)"]. Subsequent CPUs will be released for 11.2.0.3 and 11.2.0.4
Some customers, to be safe, do not apply the latest patch "until it has stabilised". They might choose to be one patch level lower than the latest. For example, to be on 11.2.0.3 and the July 2013 CPU. Your organistation needs to have a Patch Management Policy that drives decisions on patching.
Hemant K Chitale

11.2 DB & Data Guard : ORA-16014 how to archive a sequence?

Hi,
I've installed 11.2 Oracle Database in my laptop with Oracle Enterprise Linux 5.3 and I have created two standby databases, orcl (primary) and orclstby (physical standby). I performed a switchover to orclstby and consequently, orclstby was the new primary and orcl the physical standby, I checked those values with SQLPlus executing the select database_role from v$database statement, so, there were no problems during the switchover.I also shutteddown and started both primary and stanby databases to check all was fine.
Today, I've tried to start the environment again and I've encountered the following problem during the startup of the primary database:
[oracle@mredon-es ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Wed Oct 21 17:34:21 2009
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 839282688 bytes
Fixed Size 2217992 bytes
Variable Size 507512824 bytes
Database Buffers 322961408 bytes
Redo Buffers 6590464 bytes
Database mounted.
ORA-03113: end-of-file on communication channel
Process ID: 5562
Session ID: 9 Serial number: 3
I've checked the newest log created and this is its content:
Dump file /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/log/orclstby_ora_5382.trc
*** 2009-10-21 17:34:30.467
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1
System name: Linux
Node name: mredon-es.us.oracle.com
Release: 2.6.18-128.el5
Version: #1 SMP Wed Jan 21 08:45:05 EST 2009
Machine: x86_64
Instance name: orclstby
Redo thread mounted by this instance: 0 <none>
Oracle process number: 0
Unix process pid: 5382, image: [email protected]
*** 2009-10-21 17:34:30.526
2009-10-21 17:34:30.457: [ default]utgdv:2:ocr loc file /etc/oracle/olr.loc cann
ot be opened. errno 2
2009-10-21 17:34:30.527: [ default]utgdv:2:ocr loc file /etc/oracle/ocr.loc cann
ot be opened. errno 2
I've searched in Metalink information about ocr.loc and olr.loc and they seem to be part of an Oracle RAC installation, I don't know why the database needs these files to start if I am using single instance...
Any idea would be kindly appreciated because I'm a bit confused and I don't really know what steps I am suppposed to take in order to solve this problem.
Thanks in advance.
Edited by: mredon on Oct 26, 2009 5:22 AM
Reason: title of the post changed

sorry for the delay, here is the alert log:
<msg time='2009-10-21T23:03:09.576+02:00' org_id='oracle' comp_id='rdbms'
client_id='' type='UNKNOWN' level='16'
host_id='mredon-es.us.oracle.com' host_addr='192.168.237.130' module='[email protected] (TNS V1-V3)'
pid='6582'>
<txt>Data Guard: version check completed
</txt>
</msg>
<msg time='2009-10-21T23:03:09.642+02:00' org_id='oracle' comp_id='rdbms'
client_id='' type='UNKNOWN' level='16'
host_id='mredon-es.us.oracle.com' host_addr='192.168.237.130' module=''
pid='6486'>
<txt>LGWR: STARTING ARCH PROCESSES
</txt>
</msg>
<msg time='2009-10-21T23:03:09.709+02:00' org_id='oracle' comp_id='rdbms'
msg_id='ksbrdp:3833:3697353022' type='NOTIFICATION' group='process start'
level='16' host_id='mredon-es.us.oracle.com' host_addr='192.168.237.130'
pid='6588'>
<txt>RSM0 started with pid=23, OS id=6588
</txt>
</msg>
<msg time='2009-10-21T23:03:09.831+02:00' org_id='oracle' comp_id='rdbms'
msg_id='ksbrdp:3833:3697353022' type='NOTIFICATION' group='process start'
level='16' host_id='mredon-es.us.oracle.com' host_addr='192.168.237.130'
pid='6590'>
<txt>ARC0 started with pid=24, OS id=6590
</txt>
</msg>
<msg time='2009-10-21T23:03:10.832+02:00' org_id='oracle' comp_id='rdbms'
client_id='' type='UNKNOWN' level='16'
host_id='mredon-es.us.oracle.com' host_addr='192.168.237.130' module=''
pid='6486'>
<txt>ARC0: Archival started
</txt>
</msg>
<msg time='2009-10-21T23:03:10.832+02:00' org_id='oracle' comp_id='rdbms'
client_id='' type='UNKNOWN' level='16'
host_id='mredon-es.us.oracle.com' host_addr='192.168.237.130' module=''
pid='6486'>
<txt>LGWR: STARTING ARCH PROCESSES COMPLETE
</txt>
</msg>
<msg time='2009-10-21T23:03:10.833+02:00' org_id='oracle' comp_id='rdbms'
client_id='' type='UNKNOWN' level='16'
host_id='mredon-es.us.oracle.com' host_addr='192.168.237.130' module=''
pid='6590'>
<txt>ARC0: STARTING ARCH PROCESSES
</txt>
</msg>
<msg time='2009-10-21T23:03:11.180+02:00' org_id='oracle' comp_id='rdbms'
client_id='' type='UNKNOWN' level='16'
host_id='mredon-es.us.oracle.com' host_addr='192.168.237.130' module='[email protected] (TNS V1-V3)'
pid='6582'>
<txt>ARCH: LGWR is scheduled to archive destination LOG_ARCHIVE_DEST_2 after log switch
</txt>
</msg>
<msg time='2009-10-21T23:03:11.183+02:00' org_id='oracle' comp_id='rdbms'
client_id='' type='UNKNOWN' level='16'
host_id='mredon-es.us.oracle.com' host_addr='192.168.237.130' module='[email protected] (TNS V1-V3)'
pid='6582'>
<txt>ARCH: LGWR is scheduled to archive destination LOG_ARCHIVE_DEST_1 after log switch
</txt>
</msg>
<msg time='2009-10-21T23:03:11.258+02:00' org_id='oracle' comp_id='rdbms'
client_id='' type='UNKNOWN' level='16'
host_id='mredon-es.us.oracle.com' host_addr='192.168.237.130' module='[email protected] (TNS V1-V3)'
pid='6582'>
<txt>Errors in file /u01/app/oracle/product/diag/rdbms/orclstby/orclstby/trace/orclstby_ora_6582.trc:
ORA-16014: log 1 sequence# 27 not archived, no available destinationsORA-00312: online log 1 thread 1: '/u01/app/oracle/product/oradata/orclstby/redo01.log'
</txt>
</msg>
<msg time='2009-10-21T23:03:11.263+02:00' org_id='oracle' comp_id='rdbms'
client_id='' type='UNKNOWN' level='16'
host_id='mredon-es.us.oracle.com' host_addr='192.168.237.130' module='[email protected] (TNS V1-V3)'
pid='6582'>
<txt>USER (ospid: 6582): terminating the instance due to error 16014 </txt>
</msg>
<msg time='2009-10-21T23:03:11.429+02:00' org_id='oracle' comp_id='rdbms'
msg_id='ksbrdp:3833:3697353022' type='NOTIFICATION' group='process start'
level='16' host_id='mredon-es.us.oracle.com' host_addr='192.168.237.130'
pid='6592'>
<txt>ARC1 started with pid=25, OS id=6592
</txt>
</msg>
<msg time='2009-10-21T23:03:12.728+02:00' org_id='oracle' comp_id='rdbms'
client_id='' type='UNKNOWN' level='16'
host_id='mredon-es.us.oracle.com' host_addr='192.168.237.130' module='[email protected] (TNS V1-V3)'
pid='6582'>
<txt>Instance terminated by USER, pid = 6582
</txt>
</msg>
I've marked in bold the errors which may be causing the problem, ¿what do you think?

Data Guard Bug, which patch to fix?

Similar Messages

Maybe you are looking for