Monday, August 27, 2012

ORA-00245: control file backup operation failed

If you are getting the error "ORA-00245: control file backup operation failed" in 11gR2 then the solution is to use the backup location which is a Shared Location (which can be seen by all Nodes within the Cluster) for any form of controlfile backups.

Here is the Metalink Notes (ID: 1472171.1) that describes about this New Feature in 11g Release 2 RAC Environment:

Excerpt from Metalinks for whom they do not have access to metalinks:


Oracle Server - Enterprise Edition - Version 11.2.0.1.0 and later
Information in this document applies to any platform.
This issue is only applicable to RAC database.

From 11gR2 onwards, the controlfile backup happens without holding the controlfile enqueue. For non-RAC database, this doesn't change anything. But for RAC database, due to the changes made to the controlfile backup mechanism in 11gR2, any instance in the cluster may write to the snapshot controlfile. Due to this snapshot controlfile need to be visible to all instances.

The snapshot controlfile MUST be accessible by all nodes of a RAC database, if the snapshot controlfile does not reside on a shared device error will be raised at the time of RMAN backup while taking snapshot of controlfile.

This applies to backing up controlfile using sqlplus / having autobackup of controlfile configured on non
shared location.



Description

1. In RAC environment controlfile autobackup fails with ora-0245
Autobackup of controlfile in RMAN is failing with error:
RMAN-571: ===========================================================
RMAN-569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-571: ===========================================================
RMAN-3009: failure of Control File and SPFILE Autobackup command on
ORA_DISK_1 channel at 10/27/2010 12:13:31
ORA-245: control file backup operation failed

2. In RAC environment, backup controlfile to non shared location fails
SQL> ALTER DATABASE BACKUP CONTROLFILE TO '/home/rac1122/test/control.bk' REUSE
*
ERROR at line 1:
ORA-245: control file backup operation failed

3. In RAC environment backing up standby controlfile to non shared location fails
SQL> alter database create standby controlfile as '/home/oracle/renostdbycntrl.ctl';
alter database create standby controlfile as
'/home/oracle/renostdbycntrl.ctl'
*
ERROR at line 1:
ORA-245: control file backup operation failed

4. In RAC environment copy current controlfile to '${DB_BACKUP_DIR}/rac_tnctv_control.bak';
channel ch1: starting datafile copy
copying current control file
RMAN-571: ===========================================================
RMAN-569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-571: ===========================================================
RMAN-3009: failure of backup command on 10/07/2011 11:36:42 channel at ch1
ORA-245: control file backup operation failed

5. In RAC environment, Rman backup fails if snapshot controlfile is not in shared location.
 RMAN-00571: ========================================================
RMAN-00569: ============ ERROR MESSAGE STACK FOLLOWS =============
RMAN-00571: =========================================================
RMAN-03009: failure of resync command on default channel at 03/13/2012 10:19:41
ORA-00245: control file backup operation failed

Occurrence

Only affect Real application Cluster (RAC ), 11.2 specific.

Symptoms

 In RAC environment any form of controlfile backup may fail with ORA-0245 if the location of the Snapshot Controlfile is not a shared location.
The backup of the controlfile actualy makes a backup of the SNAPSHOT controlfile. The Snapshot controlfile is created when the controlfile is about to be backed up.
The Snapshot controlfile is a read-consistent copy of the controlfile.

Workaround

It is changed behaviour which requires that the snapshot controlfile in a RAC environment, is on a shared location. 
1. Check the snapshot controlfile location:

RMAN> show snapshot controlfile name;
2. Configure the snapshot controlfile to a shared disk:
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/snapcf_.f';
Or in case of ASM use
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+/snapcf_.f';

Thursday, August 16, 2012

Wait event: kksfbc child completion

Noticed this wait event "kksfbc child completion" in one of our database when a client complained that the report which was generally taking few seconds is hung today for more than hours!!!

When looked into the sessions, found that this session is waiting on "kksfbc child completion".

This is confirmed bug "6795880 - Session spins / OERI after 'kksfbc child completion' wait - superceded [ID 6795880.8]"

Bug Description:


This fix has been superseded by bug:8575528.

A session may go into an infinite spin just after a wait
for 'kksfbc child completion'. The spin occurs with
a stack including kksSearchChildList -> kkshgnc where
kksSearchChildList loops forever.

This problem can also lead to internal error such as any of
ORA-600 [kksSearchChildList1], ORA-600 [kksSearchChildList2]
ORA-600 [kksSearchChildList3], ORA-600 [kkshgnc-nextchild]

Or Trace dumps on kksSearchChildList4 .

Note:
  This fix is disabled by default in 10g.
  To enable this fix you must explicitly set the following
  parameter for instance startup:
    "_cursor_features_enabled" = 10

Metalinks Info on this bug:


Bug 6795880  Session spins / OERI after 'kksfbc child completion' wait - superceded

 This note gives a brief overview of bug 6795880. 
 The content was last updated on: 05-APR-2011
 Click here for details of each of the sections below.

Affects:

Product (Component)Oracle Server (Rdbms)
Range of versions believed to be affectedVersions BELOW 11.2
Versions confirmed as being affected
Platforms affectedGeneric (all / most platforms affected)

 Note that this fix can cause / expose the problem described in Bug:8575528

 Note that this fix has been superceded by the fix in Bug:8575528 

Fixed:

This issue is fixed in

Symptoms:

Related To:



Wednesday, August 15, 2012

How to find RAC Cluster Name and Version?


Run cemutlo command under grid home to get Cluster info such as name and version.

Options:
        -n prints the cluster name
        -w prints the clusterware version in the following format:
                 ::

How to Install Oracle TEXT manually in 10gR2

OK, By Default Oracle TEXT (CTXSYS Schema) is installed in the database if DBCA is used.

In case if its missed out and need to install manually then dont panic as installing Oracle Text is too simple as showed below:

Step#1:
Connect to the database as SYS and run:

SQL> @?/ctx/admin/catctx.sql CTXSYS SYSAUX TEMP NOLOCK

Above, CTXSYS is the password and SYSAUX is the default tablespace for user CTXSYS and TEMP is the temp tablespace and NOLOCK specifies that this account is not locked.

This will create CTXSYS schema with all objects.

Step#2:

The next step is to install appropriate language-specific default preferences. There is script which creates language-specific default preferences for every language Oracle text supports in /ctx/admin/defaults directory, such as English(US), Danish(DK), Dutch(NL), Finnish(SF), French(F), German(D), Italian(IT), Portuguese(PT), Spanish(E), and Swedish(S). They are named in the form drdefXX.sql, where XX is the international license plate code.
To manually install US default preferences, for example, log into sqlplus as CTXSYS, and run 'drdefus.sql' as described below:

Connect as CTXSYS:

SQL> connect CTXSYS/password@your_DB
SQL> @?/ctx/admin/defaults/drdefus.sql

Step3#:
Grant CTXAPP Role to the developer who needs it along with any other EXECUTE Privs on CTXSYS Packages that are required.

Hope this helps.