Wednesday, May 28, 2008

ORA-38856: Cannot mark instance UNNAMED_INSTANCE_2 (redo thread 2) as enabled

ORA-38856: Cannot mark instance UNNAMED_INSTANCE_2 (redo thread 2) as enabled

Example:

In the example below the error Occurred while performing an open resetlogs on a 10.2.0.3 Oracle Single Instance Database
Server prior to restoring an RMAN backup of and Oracle Database. The RMAN backup was taken from a RAC Database Server
and restored to a Single Instance Box.

SQL> alter database open resetlogs;

alter database open resetlogs
*
ERROR at line 1:
ORA-38856: cannot mark instance UNNAMED_INSTANCE_2 (redo thread 2) as enabled


Details:

ORA-38856: cannot mark instance UNNAMED_INSTANCE_2 (redo thread 2) as enabled.


Oracle bug, 4355382 ORA-38856: FAILED TO OPEN DATABASE WITH RESETLOGS WHEN USING RAC BACKUP, exists in the
Oracle 10g release 2.0 that affects backups taken from a RAC database. The problem is related to the number of threads
used by the source database and an expectation that the cloned database must have an identical number of threads.


Solution:

1. Set the following parameter in the auxiliary init.ora file: _ no_recovery_through_resetlogs=TRUE.

2. Open the database in resetlogs mode.

3. Remove _ no_recovery_through_resetlogs=TRUE from init.ora.

4. Restart database.



Tuesday, May 20, 2008

ORA-39014

ORA-39014: One or more workers have prematurely exited.

Example:

In the example below the Error Occurred while using data pump expdp to perform a full export on a database.

ORA-39014: One or more workers have prematurely exited.
ORA-39029: worker 1 with process name "DW01" prematurely terminated
ORA-31672: Message 31672 not found; No message file for product=RDBMS, facility=ORA; arguments: [DW01]
Job "SYSTEM"."SYS_EXPORT_FULL_05" stopped due to fatal error at 22:15:39
ORA-39014: One or more workers have prematurely exited.


Details:


This is an Oracle Bug 5879865 Oracle Release 10.2.0.4. Patch 5879865. Fixed in the 11g release.

The problem is due to the query that uses an EXISTS sub-query involving a non-mergeable view causes the core dump.

ORA-39014: One or more workers have prematurely exited.
ORA-39029: worker 1 with process name "DW01" prematurely terminated
ORA-31672: Message 31672 not found; No message file for product=RDBMS, facility=ORA; arguments: [DW01]
Job "SYSTEM"."SYS_EXPORT_FULL_05" stopped due to fatal error at 22:15:39
ORA-39014: One or more workers have prematurely exited.


Solution:

1. If available for your Platform Download Patch 5879865 to resolve this issue.

2. In the meantime, please use one of the following as a workaround:

* set both of the following in the init/spfile

o "_complex_view_merging" = false
o event="38066 trace name context forever, level 1" or level 2

OR

* set "_optimizer_cost_based_transformation"=off

ORA- Error Codes

OORA- Error Codes
ORA-39014 ORA-38856 ORA-00344
ORA-12520
ORA-06512
ORA-29707
ORA-01618
ORA-12514 ORA-31633
ORA-01031
ORA-38760

Tuesday, May 13, 2008

Periodic Job to Purge Perfstat Stats Pack Metrics

Periodic Job to Purge Perfstat Stats Pack Metrics


You can use the following procedure to setup a database job to periodically purge the statspack metrics within

the perfstat schema ever "x" number of days , this can be used as an alternative to sppurge to manage space within

the perfstat schema


As the Perfstat User run create the following procedure

CREATE OR REPLACE PROCEDURE PERFSTAT.USP_SNAPSPURGE (vDAYS NUMBER)

AS

vMIN_SNAP_ID NUMBER;

vMAX_SNAP_ID NUMBER;

vDBID NUMBER;

vDBNAME VARCHAR2(50);

vINST_NUM NUMBER;

vINST_NAME VARCHAR2(50);

vSTIME DATE;

vBTIME VARCHAR2(25);

vETIME VARCHAR2(25);

SQL_STMT VARCHAR2(200);

ERROR_NUM NUMBER;

ERROR_MSG VARCHAR2(500);

BEGIN

select min(snap_id),max(snap_id) into vMIN_SNAP_ID,vMAX_SNAP_ID

from STATS$SNAPSHOT

where snap_time <=(sysdate-vDAYS);

select dbid,name into vDBID,vDBNAME

from v$database;

select instance_number,instance_name into vINST_NUM,vINST_NAME

from v$instance;

select to_char(snap_time, 'YYYYMMDD HH24:MI:SS') into vBTIME

from stats$snapshot b

where b.snap_id = vMIN_SNAP_ID

and b.dbid = vDBID

and b.instance_number = vINST_NUM;

select to_char(snap_time, 'YYYYMMDD HH24:MI:SS') into vETIME

from stats$snapshot e

where e.snap_id = vMAX_SNAP_ID

and e.dbid = vDBID

and e.instance_number = vINST_NUM;

-- **** check variables **** ---

delete from stats$snapshot

where instance_number = vINST_NUM

and dbid = vDBID

and snap_id between vMIN_SNAP_ID and vMAX_SNAP_ID;

SQL_STMT:='alter session set hash_area_size=1048576';

execute immediate (SQL_STMT);

delete --+ index_ffs(st)

from stats$sqltext st

where (hash_value, text_subset) not in

(select --+ hash_aj full(ss) no_expand

hash_value, text_subset

from stats$sql_summary ss

where ( ( snap_id < vMIN_SNAP_ID

or snap_id > vMAX_SNAP_ID

)

and dbid = vDBID

and instance_number = vINST_NUM

)

or ( dbid != vDBID

or instance_number != vINST_NUM)

);

delete --+ index_ffs(sso)

from stats$seg_stat_obj sso

where (dbid, dataobj#, obj#) not in

(select --+ hash_aj full(ss) no_expand

dbid, dataobj#, obj#

from stats$seg_stat ss

where ( ( snap_id < vMIN_SNAP_ID

or snap_id > vMAX_SNAP_ID

)

and dbid = vDBID

and instance_number = vINST_NUM

)

or ( dbid != vDBID

or instance_number != vINST_NUM)

);

delete from stats$undostat us

where dbid = vDBID

and instance_number = vINST_NUM

and begin_time >= to_date(vBTIME, 'YYYYMMDD HH24:MI:SS')

and end_time <= to_date(vETIME, 'YYYYMMDD HH24:MI:SS');

-- delete from stats$undostat us

-- where dbid = vDBID

-- and instance_number = vINST_NUM

-- and begin_time < to_date(vBTIME, 'YYYYMMDD HH24:MI:SS')

-- and end_time > to_date(vETIME, 'YYYYMMDD HH24:MI:SS');

/* Delete any dangling database instance rows for that startup time */

delete from stats$database_instance di

where instance_number = vINST_NUM

and dbid = vDBID

and not exists (select 1

from stats$snapshot s

where s.dbid = di.dbid

and s.instance_number = di.instance_number

and s.startup_time = di.startup_time);

/* Delete any dangling statspack parameter rows for the database instance */

delete from stats$statspack_parameter sp

where instance_number = vINST_NUM

and dbid = vDBID

and not exists (select 1

from stats$snapshot s

where s.dbid = sp.dbid

and s.instance_number = sp.instance_number);

COMMIT;

EXCEPTION

WHEN OTHERS THEN

ROLLBACK;

ERROR_NUM := SQLCODE;

ERROR_MSG := substr(SQLERRM,1,100);

DBMS_OUTPUT.PUT_LINE(ERROR_NUM || ': ' || ERROR_MSG);

END;

/


You can call the above procedure as follows , for example to keep only the only last 30 days of metrics within the

perfstat schema:


SQL> exec PERFSTAT.USP_SNAPSPURGE(30);


As the Perstat User Setup a database job to periodically purge the stats pack schema , for example to purge the statspack

metrics every 31 days , keeping only 30 days worth of metrics:

DECLARE jobno number; BEGIN DBMS_JOB.SUBMIT(job => jobno, what =>

'PERFSTAT.USP_SNAPSPURGE (30);', next_date =>

to_date('14-May-2008 03:00:00 PM','dd-Mon-yyyy HH:MI:SS AM'),

interval => '/*31:Days*/ sysdate + 31'); END;

/



Monday, May 12, 2008

Error Code RMAN-20011: target database incarnation is not current in recovery catalog

RMAN-20011


RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of configure command at 05/12/2008 18:21:50

RMAN-06004: ORACLE error from recovery catalog database:

RMAN-20011: target database incarnation is not current in recovery catalog


Details:


The above error occurs when the Database target Incarnation is not current in the Recovery Catalog.


The incarnation of a database is a number that is used to identify a version of the database.
A database incarnation is created whenever you open the database with the RESETLOGS.

V$DATABASE_INCARNATION displays information about all database incarnations. Oracle creates
a new incarnation whenever a database is opened with the RESETLOGS option. Records about the
current and immediately previous incarnation are also contained in the V$DATABASE view.


To Reference the corresponding Incarnation information in the recovery catalog review the

RC_DATABASE_INCARNATION and RC_DATABASE views.


RC_DATABASE_INCARNATION lists information about all database incarnations registered in

the recovery catalog.


RC_DATABASE lists information about the databases registered in the recovery catalog.

It corresponds to the V$DATABASE view in your target database.


Solution:

Connect to the RMAN schema as rman user e.g.


$ sqlplus rman/rman@RMANREP

SQL> select DBID, NAME, DBINC_KEY, RESETLOGS_CHANGE#, RESETLOGS_TIME

from rc_database_incarnation where dbid=2131079213;

DBID NAME DBINC_KEY RESETLOGS_CHANGE# RESETLOGS

---------- -------- ---------- ----------------- ---------

2131079213 DATABASE 1274431 80473525 20-JUN-07

2131079213 DATABASE 1274433 80251948 18-JUN-07


Connect to the RMAN catalog from the target databse

$ rman catalog rman/rman@RMANREP target sys/manager@DATABASE

Reset the database to the latest incarnation

RMAN> reset database to incarnation 1274431;

database reset to incarnation 1274431


Resync the catalog

RMAN> resync catalog;

starting full resync of recovery catalog

full resync complete


Verify all changes

RMAN> list incarnation;

starting full resync of recovery catalog

full resync complete

List of Database Incarnations

DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time

------- ------- -------- ---------------- --- ---------- ----------

1274430 1274433 DATABASE 2131079213 PARENT 80251948 18-JUN-07

1274430 1274431 DATABASE 2131079213 CURRENT 80473525 20-JUN-07